Method for mapping, translating, and dynamically reconciling data between disparate computer platforms

Description Submit all comments and votes

REFERENCE TO MICROFICHE APPENDIX

A source code listing of the preferred embodiment of the invention is appended in the form of a fiche and 330 pages recorded on microfiche.

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

This invention relates to programs that share data across disparate computer applications and platforms, such as handheld computers and desktop computers.

Handheld computers typically weigh less than a pound and fit in a pocket. Handheld computers typically provide some combination of personal information management functions, database functions, word processing functions, and spreadsheet functions. Owing to the physical and memory size, and processing power limitations of the handheld computers, however, these applications are generally limited in functionality and differ in data content and usage from similar applications on desktop computers.

Many users of handheld computers also own a desktop computer used for applications that manage data similar to the data carried in the handheld computer. In such cases, the user normally would want the same data on the desktop computer as in the handheld computer. There are a number of programs that transfer data between handheld computers and desktop computers, but they all create desktop computer's data with no regard for prior contents. As a result, all updates that have been done to the desktop computer's data prior to the transfer are ignored.

Many desktop computer applications have their data stored in large, complex, proprietary formats. Data transfer to these applications usually cannot take place through file transfer, because the data comes from the handheld computer in a different format and usually is a subset of the data held on the desktop computer. In such cases, data can only be communicated to and from the desktop application by the use of a database manager or by use of dynamic inter-application communication techniques.

Many handheld and desktop programs work with database files. Database files have a file format, the set of rules by which data can be read from or written to the file. A database file is composed of records, some of which are data records with the data of interest to the application program and the user, and often some header records. Each data record is composed of fields, and each field has a name and a data format. Examples of data formats include 1-, 2-, and 4-byte integers, a 4-byte or 8-byte floating point number, or one or more ASCII text strings. In the case of multiple text strings in one field, the strings (or subfields) are separated by a special character such as tab or linefeed. Each data record of a file shares the same record structure: a record structure is described by the fields' names, data formats, and byte offsets in the record. The file format's rules include a description of the record structure of the constituent data records, the record structure for any header records and how these header records aid navigation to find specific data records and/or specific fields within those records, "hidden" key tags to help find a record, and any rules that application programs use to access a particular record and field.

Database files are managed by two broad classes of programs, database managers and other application programs. A database manager is a program for managing general databases, that is, database files whose record structure can be specified at creation time by the user. Database manager programs maintain data dictionary records as headers in the database file. These data dictionary records specify each field's name, start byte offset within the record, and data format. Examples of database manager programs include Paradox, dbase, and IBM Current.

Other database files are managed by special-purpose application programs. These programs work on databases of one specified record structure; this specification is embedded in the code of the program rather than in header records of the file. For instance, a telephone directory program may work on files with a 32-character name and a 10-character phone number. This record structure would have been encoded in a data structure declaration in the source of the program.

One or more of the fields of a database record structure are designated as the key, the "name" by which the record can be specified for reading or writing. Some database files, typically those for schedule application programs, have "range keys"--the key specifies start and end points in a 1-dimensional key space rather than a single point in the (possibly multi-dimensional) key space. Range keys may specify multiple intervals, for instance "9 AM to 10 AM every Monday until November 17." Where non-range keys must be unique--there cannot be two records with the same non-range key--range keys may overlap or even be exactly equal, though typically these are undesirable situations and should brought to the attention of the user.

Because handheld computers of the current generation are diskless, "files" in the classical sense do not exist on many of these handheld computers. Within this patent, the term file should be understood to include the memory-resident datasets of a handheld computer, and the serial bit stream format in which a handheld computer sends or receives data to/from another computer.

File copying and data conversion are long-standing problems in the art, and many solutions to different parts of the problem have been offered.

U.S. Pat. No. 4,966,809 describes a technique for sharing data among disparate platforms with differing data formats, but leaves unsolved the problems of sharing data among platforms that require different record structures or file formats (broader problems that include the data format problem as a constituent), and does not provide a method for a user of these disparate platforms to conveniently instruct his system about his environment so that the system will apply itself in that environment.

There are several file transfer programs for communicating between computers, including Organizer Link 2 from Sharp.RTM. Electronics, PC-Link for the Casio B.O.S.S..TM. from Traveling Software.RTM., HP95LX Connectivity Pack from Hewlett Packard, and 3 Link from Psion PLC. These file transfer programs do not provide the invention's user-specifiable field mapping of data nor dynamic reconciliation of data.

SUMMARY OF THE INVENTION

The current invention solves the problem of sharing data between disparate application programs by providing user-specifiable field mapping of data and dynamic reconciliation of conflicts.

In preferred embodiments, the invention features accepting data from a first computer application, and then mapping and translating the data to the formats expected by a second computer application. The user of the translation facility may explicitly specify the mapping of the data fields of the two applications' files. During the data transfer, the user may also choose to be informed of application-specific conflicts between data received from the first application and that already existing on the second platform. When a data conflict is encountered, the user may then opt to accept, ignore, or change the data before it is applied to the second application's files.

The invention can also be used to transfer, compare and reconcile data between any other pair of disparate platforms, even if the disparity is relatively minor, as for instance between a Paradox database manager and a dBase database manager running on the same IBM PC.

The invention provides an effective method of translating data between disparate computer platforms and a wide variety of applications, while ensuring that the data need only be entered once (and not duplicated).

The invention also ensures the integrity of the data imported to computer applications, through the process of conflict resolution (also known as data reconciliation).

In a first aspect, the invention features a method for an interactive user of a computer to dynamically reconcile the information of two database files. The method comprises the steps of choosing corresponding records from the two files, comparing the information of corresponding fields of these records, and allowing the user to decide how to change the data in one of the two files to bring them into agreement.

In preferred embodiments in which the records of the two files are named by range keys, as in an appointment schedule application, the method comprises determining if any schedule conflicts exist (either the time of an appointment has been changed in one of the two schedule databases, or there are two different appointments for conflicting times) and allowing the user to decide how to change the data in one of the two files to bring them into agreement.

The invention offers a solution to previously unsolved portions of the data translation problem, by providing means to translate data from one record structure to another.

In a second aspect, the invention features a method for translating computer data from a source record structure to a destination record structure. The invention offers translations that are new in the art, by translating between source and destination record structures that differ in field naming, field order, or one-to-many or many-to-one field correspondence. The method comprises the steps of establishing a mapping between the fields of the two record structures, and using that mapping to translate the data of a source file into the destination record structure.

The invention provides both a framework and a convenient user interface for tying together previous data translation techniques into a more broadly-applicable and easy-to-use system.

In a third aspect, the invention features a method for translating computer data from a source record structure to a different destination record structure. The method comprises the steps of first establishing a mapping between the fields of the two record structures by presenting the names of the fields of each of the record structures on a display, and allowing a user to specify the correspondence between pairs of fields. The actual translation of files then makes use of this mapping to translate the data of a file from the source record structure to the destination record structure.

Other features and advantages of the invention will be apparent from the following description of preferred embodiments, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a preferred embodiment of the invention.

FIG. 2 shows examples of the transfer and translation of data from handheld applications and computers to common record structures.

FIG. 3 shows examples of the transfer and translation of data from the common record structures to desktop applications and computers.

FIG. 4 shows an example of the detailed mapping of fields (specifying correspondence between handheld and desktop) between a handheld and desktop applications.

FIGS. 5A and 5B show a sample screen display which enables the user to specify the mapping or correspondence of field names between handheld and desktop applications and platforms.

FIG. 6 shows an application-specific reconciliation table used internally by the translation software to achieve data reconciliation.

FIG. 7 shows a sample screen display which notifies the user of conflicts between handheld and desktop data for reconciliation purposes.

FIG. 8 shows a sample screen display which notifies the user of conflicts between schedule data contained on the handheld and desktop applications and platforms.

FIG. 9 shows the field structure of the field mapping database.

FIG. 10 shows a sample field mapping database.

FIG. 11 shows an example of data translated between a handheld computer database and a desktop computer database.

DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

The preferred embodiment comprises several large programs with a number of steps that run on the desktop computer, and a small file transfer program that runs as a slave on programmable handheld computers. The major steps of the main program are:

1. Mapping of fields from desktop data formats to handheld data formats if required

2. Transfer of data from handheld to desktop

3. Translation of data to desktop format

4. Dynamic reconciliation of conflicts

The mapping step establishes correspondences between fields of pairs of files. On import, the transfer step brings the handheld data into the desktop computer. The translation step uses the rules provided by the mapping step to convert the handheld data in one format to desktop data in another format. The dynamic reconciliation step informs the user of conflicts in the data and allows him to make decisions about whether to accept the new data, ignore it, or change it. A menu driver is provided to select which handheld applications to translate to which desktop applications.

The preferred embodiment also provides the capability to export and translate data from the desktop computer to the handheld computer. In this case, the steps are:

1. Mapping of fields from desktop data formats to handheld data formats if required

2. Transfer of data from desktop to handheld

3. Translation of data to handheld format

Again, the above steps are under the control of a menu driver.

The following detailed description focuses on the mapping, transfer, and translation between the handheld computer and the desktop computer as well as the dynamic reconciliation of the data during translation. The mapping, transfer, and translation of the data from the desktop computer and the handheld computer is essentially identical except that there is no reconciliation, because the desktop data replaces the handheld data in the preferred embodiment owing to built-in constraints in most handheld computers.

FIG. 1 shows a HANDHELD COMPUTER 101 with applications PHONE 103, SCHEDULE 105, TODO 107, DATA 109, and MEMO 111 transferring data to a desktop computer using file transfer application HHCOMM 113. HHCOMM 113 is responsible for accepting the data from the handheld computer and translating it to the COMMON RECORD STRUCTUREs, which are defined by the preferred embodiment. The COMMON RECORD STRUCTUREs are then passed to DESKTOP COMPUTER 115 by transfer application DTCOMM 117 which utilizes DTXLT 119 inter-application communications or database manager facilities as appropriate to translate the data to formats accepted by desktop applications PERSONAL INFORMATION MANAGER 121, DATABASE MANAGER 123, SPREADSHEET PROGRAM 125, or WORD PROCESSING PROGRAM 127.

Before communicating with the desktop application, the user may specify the mapping of handheld and desktop application data for the PHONE 103 and DATA 109 applications by utilizing the mapping facilities of DTMAP 129. A default mapping is provided for the other applications.

The user may optionally request from DTRECON 131 that conflicts between the handheld and desktop data be reconciled dynamically, thereby giving the user the option of accepting, ignoring, or changing any conflicting data.

The mapping step of the program builds a set of rules that the translate step will use to translate data from one record structure to another. The mapping step must be run once for each pair of source-destination file formats where one of the files is a keyed database, such as PHONE 103 or DATA 109. The output of a mapping step is a mapping database that can be used for any number of translate steps in the future.

There are two steps to the mapping process: (1) Acquiring the field names and data format of each field of each of the two record structures; and (2) establishing a correspondence between the fields of the source structure and the destination structure. Once a mapping between two record structures is established, it is maintained in a field mapping database for use by the translation steps.

There are three methods by which field names and data formats can be acquired, each method described in more detail in following paragraphs.

Some files, notably including files managed by database manager programs, have data dictionary records as headers in the database file. These data dictionary records provide exactly the information required. For example, the Paradox Engine data access facility provides all field names for a Paradox database upon request in the preferred embodiment.

In a second method, the application program provides this information to the mapping facility through an inter-application communication facility. An inter-application communication facility is provided by some application programs so that other programs may read and write data files maintained by the application. In addition to the normal program start entry point, the application program's image has other entry points that provide services like "Tell me the names of all fields in your records," "Give me the data format for the field whose name is BUSINESS PHONE", " "Give me the next record key", "Give me the information of the CITY field for the record whose key is `John Jones`." Windows Dynamic Data Exchange (DDE) is an example of this type of inter-application communication facility which is used by the preferred embodiment with desktop computer applications such as IBM Current and Polaris PackRat.

When neither of these two methods are available to the mapping facility for acquiring an understanding of the record structure, then in a third method, a description of the record structure (or the handheld's byte-stream format) is brute force hard-coded in a way that makes the information available to the mapping and translation facilities. In some cases, the developer of the application publishes the file format. For instance, for the HP95LX handheld computer SCHEDULE application, the byte stream representation of the file's record structure is:

______________________________________ Date 3 1-byte integers Start Time 2-byte integer End Time 2-byte integer Alarm 1-byte integer Description 27-byte ASCII string Note 429-byte ASCII string ______________________________________

The preferred embodiment provides hard-coded record descriptors for the PHONE 103, SCHEDULE 105, TODO 107, DATA 109, and MEMO 111 applications provided by each of the supported handheld computers. In some cases the field names are obtained from the actual field names in the handheld computer's implementation and used as the field names for the target application. An example of this would be the DATA application in the programmable Psion Series 3 handheld computer.

In a fourth method contemplated by the inventor but not implemented in the current embodiment, a data dictionary of the record structure can be coded into a text file, and the mapping step can read and interpret this text file much as it reads and interprets a database's data dictionary.

Once the mapping facility has acquired an understanding of the fields of each of the two record structures, the next step is to establish the actual field mappings--for instance, to establish a correspondence between a PHONE 103 field of file format 1 and a FAX NUMBER 307 field of file format 2, and to determine the data conversion rule for mapping a datum of field PHONE to a datum of field FAX NUMBER 307, for instance "convert 3 2-byte integers to 10 ASCII characters." This is accomplished by a user, who is presented with a list of all the fields of each of the two record structures, and then asked to select corresponding names.

It is sometimes preferable to not provide a mappi