Electrical computers and digital processing systems: multicomput – Distributed data processing – Client/server
Reexamination Certificate
2000-09-20
2004-02-03
Harrell, Robert B (Department: 2142)
Electrical computers and digital processing systems: multicomput
Distributed data processing
Client/server
C704S008000
Reexamination Certificate
active
06687736
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention pertains generally to software application programs requiring multiple language support. More particularly this invention is directed to an improved system and method for providing multiple language support to an application having a remote language database.
2. The Prior Art
Application programs that are expected to be used by persons speaking different languages require multiple language support. This requirement falls on all applications having any type of user interface, from older character-cell based user interfaces to the most current graphical display user interfaces. In each case, there will be text displayed that must be in the language of the user. In some cases multiple languages will be in use at the same time.
Initially application programs were rewritten for each target language. This solution required a separate code base for each target language. Having multiple code bases for a single application creates problems. Considerable logistical complexity is created when there are multiple code bases. Multiple code bases also create significant maintenance problems because of the coordination and propagation of changes between multiple parallel development efforts. The separate code base solution proved prohibitively expensive for continuing multilingual distribution of applications.
The next solution in providing multilingual support avoided the multiple code base problems by introducing a single code base with different software modules that contained language text strings. Text strings, and other variables used by the program, are all placed in one location. This location, a separate module and often a separate file, gets compiled into the final program and contains text strings for all the places in the user interface that have textual portions in the display. Files containing variables needed during the execution of a program are sometime called environmental files, and generally contain data that is expected to be changed during the life of the program with more frequency than the code base. Depending on the application text strings where kept in separate modules, files, or with other data in environmental files.
In the case of providing different language support, modules would include text strings from one or more languages that are to be used in the user interface, or could have a different language module for each supported language. These files are then built-in to the application program by being part of the program build, or being in the complied version of the program. Thus, the application is built using specified language modules or files whose contents may vary depending on the compiled program's target audience.
The physical topology of computer systems used for the two multilingual support solutions just discussed were the large, centralized computers predominant one to two decades ago. In such installations there would be a computer or set of computers in a centralized location, examples being IBM 360s or CDC Cyber 6000s. User interface equipment consisted of hardwired terminals, coupled with the central computers using MUXes and similar equipment. As a result of the physical architecture, all the software on this system is colocated with the central computer or computers. Everything from the operating system to the application is on one machine or a closely coupled set of machines in close physical proximity with dedicated high-speed system interconnects.
As network technology matured typical system topology evolved, changes began occurring in typical systems topologies, especially at the front-end connections to the traditional computer rooms. There was still a central computer or cluster of computers which typically had a relatively large amount of secondary storage, including any databases, connected directly to the centralized computers. Example computers would include mainframes such as DEC VAX 8000 series or IBM 390 series, or “midi” machines such as DEC VAX 6000-series. The significant changes were occurring at the system's front-end. Terminals were now typically connected through a LAN rather than through dedicated terminal connections. An example of such a connection is DEC's LAT protocol running on an Ethernet-based LAN. In addition small local LANs having a relatively small number of individual systems, mostly IBM PC's or clones running some version of MS-DOS, were connected through the LANs to the centralized systems. Applications were typically terminal emulators with character-cell based applications, or with very limited graphics.
The physical system topology just discussed had the property of maintaining large or complex application programs on the central computer systems because the smaller systems didn't have the computing capability nor the storage capability to run larger applications. Networks were relatively slow, and the user interfaces where virtually all character-cell based.
Referring again to multilingual support for software that was evolving along with the hardware, the use of a single code base with language modules took care of the maintenance problems found with multiple code bases. Other limitations still existed, however. When language modules are compiled into an application, changes to the language files require recompiling and reinstalling the program. Thus when changes occurred the program would have to be stopped, perhaps uninstalled, and the newly compiled version installed. In addition to being a fair amount of work for the system administrators, this necessitated periods of time when the application wasn't available (“down-time”). Down-time was expected, even if barely tolerated, when most applications ran on main-frames inside of computer centers. The issue became increasingly problematic as the availability of smaller, individualized, local systems came into increasingly common use. As more machines were being used by people not disciplined or tolerant in the ways of the centrally controlled main-frames with their scheduled downtimes, users pushed for no down time. No down-time is often characterized by the system's availability in hours (up to 24) and days (up to 7); no down-time corresponds to all-hours, all-days availability or 24×7 availability.
At the same time, application developers were making increasing use of databases to support multilingual applications. This meshed with the increasing need for 24×7 availability for applications having multilingual capabilities. Using a database allows the application to stay up regardless of what was happening to the database. It allows for changes to be made to the database independently from the running application, and allowed very substantial changes to made to the data stored in data bases without affecting the running application. If a switch-over from one set of data to another was needed, it could be accomplished in a few minutes rather than the hours re-installing the application might take.
Using databases in conjunction with an application requiring multilingual support provided the kind of functionality and availability not found in previous solutions, and is presently in use. With the growth of the internet such support is even more critical now, as there can be dynamic requests for different languages (in the past there would typically be one language used per session) within a single page or session, and availability of application available on the internet must be as close to 24×7 as technology can get.
The physical topology of a typical system that corresponds to the distributed multilingual support just described is shown in FIG.
1
. It developed in parallel with the propagation of client-server applications and the tremendous expansion in the internet. The terminals used with centralized system topologies are no longer present. Instead, a client application is running on a client computer system shown as systems
100
and
102
, or client a device shown as
104
and
106
. Client machines are those known and standa
Cisco Technology Inc.
Harrell Robert B
Sierra Patent Group Ltd.
LandOfFree
Localization support method for software applications with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Localization support method for software applications with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Localization support method for software applications with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3318662