Method and apparatus for transferring data base information

United States Patent [19]

Oswald et al.

Illlllllllllllllllllllllllll

US005442783A

[ii] Patent Number: 5,442,783

[45] Date of Patent: Aug. 15,1995

[54] METHOD AND APPARATUS FOR TRANSFERRING DATA BASE INFORMATION

[75] Inventors: Gary J. Oswald, Elk Grove Village;

Mark Banghart, Carpentersville;
Michael E. Burke, Lake Zurich, all of
111.

[73] Assignee: Motorola, Inc., Schaumburg, 111.
[21] Appl. No.: 126,003
[22] Filed: Sep. 24,1993

Cellular Mobile Radio Market" Telephony, Aug. 1982, pp. 28-29, 32, 34.

Betteridge et al, "Versatile, Multi-featured Mobile Systems Take to the Road" Telephony, Aug. 1982, pp. 29, 36, 40.

"Message Handling Systems: Presentation Transfer Syntax and Notation" Fascicle VII.7-RecX.409 pgs. 62-69 and 95-97.

Primary Examiner—Kevin A. Kriess
Assistant Examiner—Dennis M. Butler
Attorney, Agent, or Firm—Val Jean F. Hillman

Related U.S. Application Data

[63] Continuation of Ser. No. 468,400, Jan. 22, 1990, abandoned.

[51] Int. C1.6 G06F 17/00; G06F 17/30

[52] U.S. CI 395/600; 395/500;

364/282.1; 364/282.4; 364/284; 364/284.4;

364/DIG. 1

[58] Field of Search 395/200, 500, 600;

364/282.1, 282.4, 284, 284.4

[56] References Cited

U.S. PATENT DOCUMENTS

4,205,371 5/1980 Feather 395/600

4,259,549 3/1981 Stehman 379/216

4,442,321 4/1984 Stehman 379/220

4,531,186 7/1985 Knapman 395/600

4,553,205 11/1985 Porchia 395/375

4,604,686 8/1986 Reiter et al 364/200

4,691,278 9/1987 Iwata 395/375

4,829,554 5/1989 Barnes et al 379/58

4,908,759 3/1990 Alexander, Jr. et al 395/600

4,975,830 12/1990 Gerpheide et al 364/200

5,187,787 2/1993 Skeen et al 395/600

OTHER PUBLICATIONS Bob Dargent, "AURORA System Lights the way in

[57] ABSTRACT

The present invention discloses a method of maintaining forward and backwards compatibility between various software releases, utilizing different database information and structures. During database transfers the initiating, master, processor requests a responding, slave, process to first provide a description of the slave's database language. Next, the master processor compares the slave's database language description to that of its own. From this comparison, the master develops a working language. The working language is then sent to the slave processor, and thereafter used by both processors when transferring database information. This method supports the update and transfer of database records pursuant to the installation of new software releases. Alternatively, this technique supports the transfer of database information between processors that have dissimilar database structures. In either scenario, the disclosed method of database transfer is software release independent, avoids the need of complex conversion programs, and has greatly enhanced overall information throughput.

8 Claims, 2 Drawing Sheets

In computer systems that employ distributed networks where database information is frequently transferred, there exists the need to maintain both forward and backwards compatibility among the various software releases generated during a systems lifetime. Ex- 20 amples of computer systems utilizing distributed networks are Local Area Networks (LANs) and Wide Area Networks (WANs). In these computing environments, forward compatibility describes the relationship between a progression of software releases, whereby 25 installation of a new software release does not compromise the fitness, form, or function achieved under previous software versions. In essence, the new software performs like the old, despite the inclusion of additional features. Backwards compatibility is achieved when the 30 reinstallation of a previous software version does not render the system inoperable.

This same need arises in computer systems that employ redundant database information which is either compared or exchanged. One such example is a tele- 35 phony computer designed to perform the switching of customer calls. An example is the Motorola Electronic Mobile Exchange (EMX) family of cellular switches. These include the Motorola EMX 100, 250, 500, and 2500 switch families which support cellular radiotele- 40 phone services in several major metropolitan markets. The interested party may receive full system/hardware descriptions on such devices by contacting Motorola's Cellular Publishing Services at 1501 W. Shure Drive Shure Drive, Arlington Heights, 111. 60004 and request- 45 ing Instruction Manuals 68P8105196E-99E, 68P81052E-54E and 68P81056E for the EMX 100-500 Family of Switches or Instruction Manuel 68PO9201A07-A for the EMX2500 electronic switch all of which are incorporated herein by reference. 50

Simply stated, a telephony computer is nothing more than a large switch that employs sophisticated software capable of managing and directing multiple customer calls per second. In this effort, it is necessary to develop a comprehensive customer database capable of report- 55 ing the various telephone subscribers, their individual accounts, and various service features. Presently, most of the customer database information is of a static nature; not subject to frequent change and therefore suitable for storage in backup form. With the expansion of 60 customized telephone services, however, a growing portion of the database information is dynamic.

Unlike static, dynamic information is customer generated, subject to certain alteration, and therefore totally unsuitable for hard copy storage. Typical examples of 65 dynamic information include the programmable automatic redial, call forwarding, busy transfer, no answer transfer, or voice mailbox telephone options. While this

personalized information is not maintained in hard copy form, it is extremely valuable to the average system subscriber and therefore must be jealously safeguarded during database transfers if quality phone service is to be provided.

In this effort to insure quality service, EMX computers employ a redundant or secondary switch that is a duplication of the primary switch, and capable of continuing service if the primary is ever disabled. During normal operation, the primary and secondary customer databases are frequently compared. These subscriber audits are performed in order to assure primary and secondary database equivalence. In addition, it is quite common for telephony computers to perform subscriber file transfers, wherein the subscriber information residing in one computer is transferred to a different computer. Another frequently performed operation is subscriber feature preservation. This is the process whereby dynamic database information is updated and transferred to the secondary switch the instant the primary becomes disabled. In each of these operations, the existence of forward and backwards compatibility is imperative in order to assure the proper handling and transfer of the appropriate database records. This is especially true for the transfer of dynamic information which is constantly changing and for which there is no hard copy backup.

Forward and backwards compatibility is normally achieved on an individual software release basis. It will be appreciated by those skilled in the art that a typical software update may include the correction of an old software version or the addition of new system features. Each enhancement, however, requires altering the database records supporting the capture of the obsolete or newly acquired information. Such changes present a considerable challenge to the programmer attempting to implement forward and backwards compatibility, because communication between differing database structures may result in the loss of important information. In the telephone business, lost information represents an intolerable breach in the quality of service.

For example, assume an original software release version 1.0 is supported by customer database #1, which contains several records each having elements A, B, and C. The updated release of this software is version 2.0 which is supported by customer database #2. Database #2 also contains several records, however, these records contain elements A, B, and D. During the forward transfer of database #1 information into database #2, it is understood that the software associated with database #2 will disregard the information found in element C. Likewise, during the backwards transfer of database #2 information into database #1, the software associated with database #1 will not comprehend the information found in element D. Ultimately, this unrecognized data must be discarded by the software. Of note, the greater the difference between the subject databases and the more software releases to be encountered, the more complicated system software must be in order handle these inconsistencies and maintain compatibility.

Previous approaches suggest downloading the entire existing database, undesired records and all, and relying upon complex conversion programs capable of converting the original database to a format capable of being passed to the new database. While these programs are entirely capable of discarding obsolete records or ignoring the presence of new records, compatibility will