Method for mapping, translating, and dynamically reconciling data
Contents
1. 2 715 513 5 293 627 A 3 1994 Kato et al 713 503 5 301 313 A 4 1994 Terada et al 707 4 5 315 709 A 5 1994 Alston Jr et al 707 6 5 323 314 A 6 1994 Baber et al 705 8 5 327 555 A 7 1994 Anderson 2 707 201 5 333 252 A 7 1994 Brewer III et al 715 506 5 333 265 A 7 1994 Orimo et al 709 201 5 333316 A 7 1994 Champagne et al 707 8 5 339 392 A 8 1994 Risberg et al 345 762 5 355 476 A 10 1994 Fukumura 707 1 5 375 234 12 1994 Davidson et al 2 707 202 5 396 612 A 3 1995 Huh etal 714 49 5 412 801 A 5 1995 De Remer et al 714 20 5 421 012 A 5 1995 Khoyi et al 2 709 107 5 444 851 A 8 1995 Woest 709 222 5 463 735 A 10 1995 Pascucci et al 709 222 5 475 833 A 12 1995 Dauerer et al 2 707 201 5 511 188 A 4 1996 Pascucci et al 707 203 5 519 606 A 5 1996 Frid Nielsen et al 364 401 5 745 712 A 4 1998 Turpin et al 345 763 OTHER PUBLICATIONS Adly et al A Hierarchical Asynchronous Replication Pro tocol for Large Scale Systems Computer Laboratory Cam bridge University United Kingdom Computer Science Department Alexandria University Egypt undated All I need is a miracle computer aided educational pack ages Small Wonders Coastal Associates Publishing L P Mar 1992 Alonso et al Database Sys2. Handheld Data NUMBER 212 111 3333 PC Data Business Phone 212 111 2222 uem ee areal FIG 7 Schedule Update Handheld Data Announcement Date Start Time Time PC Data Meeting with Jim Date Start Time End Time 02 26 92 09 00AM 10 00AM ignore FIG 8 U S Patent Name HH Type HH Application DT Application DT File Name HH File Name Record Number HH Field Name DT Field Name Multiple Field flag Feb 21 1995 Sheet 7 of 8 5 392 390 MAPPING Database Fields Data Format 06 15 25 64 64 15 25 Number of HH Fields Field Type Number of Keys Data format codes Ann N Psion DATA Psion DATA Psion DATA Psion DATA Psion DATA Psion DATA 04 N Description Handheld make model Handheld Application Name Desktop Application Name Name of Desktop database file Name of Handheld database file Unique record id Name of the Handheld field and subfield number Field Name within DT File Name Indicator that HH logical field has multiple physical fields Number of real Handheld Fields Field type of Desktop Field Number of fields in Desktop database key A string of length nn An integer A boolean true false value FIG 9 MAPPING Database for FIG 4 DTApp Paradox Paradox Paradox Paradox Paradox Paradox HHFidNam DTFidNam MultFid On f
3. It is certified that error appears in the above indentified patent and that said Letters Patent is hereby corrected as shown below FIG 4 QUANITY should be QUANTITY FIG 11 RECONCILLIATION should be kRE CONCILIATION Column 2 line 41 after should insert be Column 3 line 46 schdule should be schedule Column 9 line 1 after bytes insert Column 16 line 16 intensive should be interactive Signed and Sealed this Seventh Day of July 1998 BRUCE LEHMAN Attest Attesting Officer Commissioner of Patenis and Trademarks UNITED STATES PATENT AND TRADEMARK OFFICE CERTIFICATE OF CORRECTION PATENT 5 392 390 DATED February 21 1995 INVENTOR S Keith Crozier It is certified that error appears in the above identified patent and that said Letters Patent is hereby corrected as shown below Column 2 line 53 U S Pat No 4 966 809 should be U S Pat 4 956 809 Signed and Sealed this Thirteenth Day of October 1998 BRUCE LEHMAN Aftesting Officer Commissioner of Patents and Trademarks US005392390C1 a EX PARTE REEXAMINATION CERTIFICATE 5343rd United States Patent Crozier US 5 392 390 C1 Apr 18 2006 10 Number 45 Certificate Issued 54 METHOD FOR MAPPING TRANSLATING AND DYNAMICALLY RECONCILING DATA BETWEEN DISPARATE COMPUTER PLATFORMS 75 Inventor Keith Crozier Act
4. Joint Claim Construction and Prehearing Statement Extended Systems Second Supplemental Preliminary Inval idity Contentions Re Reexamination Requests for the 390 664 and 529 Patents Pumatech Inc s Opening Claim Construction Brief Dec laration of Marc David Peters in Support of Pumatech Inc s Opening Claim Construction Brief Extended Systems Inc s Responsive Claim Construction Brief Declaration of Jordan Trent Jones in Support of Extended Systems Inc s Responsive Claim Construction Brief Supplemental Decalaration of Marc David Peters in Support of Pumatech Inc s Reply Claim Construction Brief Pumatech s Revised Proposed Claim Construction Order Pumatech Inc s Reply Claim Construction Brief Statement of Recent Decision Pumatech s Proposed Claim Construction Order Synchrologic s Preliminary Invalidity Contentions Larson et al A Theory of Attribute Equivalence in Data bases with Application to Schema Integration IEEE Trans actions on Software Engineering vol 15 No 4 Apr 1989 Mannino et al Matching Techniques in Global Schema Design IEEE 1984 Sheth et al A Tool for Integrating Conceptual Schemas and User Views IEEE 1988 Webster s Ninth New Collegiate Dictionary 1986 pp 114 436 440 462 573 597 620 717 906 963 979 989 1000 1053 1130 1142 1152 1162 1166 Wiederhold Gio Database Design Second Edition McGraw Hill Book Company 1983 p 2 Extended Syst
5. 1995 Staten csInStep middleware lets Newton talk to PIMs Concierge Software LC s csInStep Brief Article Product Announcement Brief Article Information Access Com pany 1995 Baum Designing Moble applications A new approach needed for on the road systems InfoWorld Media Group 1994 Parkinson Remote users get in sync with office files News Analysis Information Access Company 1994 cited by examiner US 5 392 390 2 EX PARTE patent matter printed in italics indicates additions made REEXAMINATION CERTIFICATE to the patent ISSUED UNDER 35 U S C 307 AS A RESULT OF REEXAMINATION IT HAS BEEN s DETERMINED THAT THE PATENT IS HEREBY AMENDED AS The patentability of claims 2 5 9 and 11 is confirmed INDICATED BELOW Matter enclosed in heavy brackets appeared in the Claims 1 3 4 and 10 are cancelled patent but has been deleted and is no longer a part of the
6. ALARM 217 DESCRIPTION 219 This table is searched for each incoming appointment to determine if there is a conflict in scheduling between the incoming appointment and all existing appointments in the desk top schedule For example if an appointment from the handheld computer had a DATE 211 of Dec 15 1991 a START TIME 213 of 10 00AM and an END TIME 215 of 11 30AM the SCHEDULE MAP TABLE 601 would indicate to the preferred embodiment that there is a conflict with the second appointment in the SCHED ULE MAP TABLE 601 which shows an appointment on Dec 15 1991 from 11 00AM to 1 00PM All times are converted to a 24 hour format to ease comparison If an appointment shows an identical DATE 211 START TIME 213 END TIME 215 and DESCRIP TION 219 there is no conflict and the incoming ap pointment is ignored The preferred embodiment of the SCHEDULE RECONCILIATION facility creates a SCHEDULE MAP TABLE 601 by requesting all appointments for today and the future from the desktop schedule applica tion For example the preferred embodiment utilizes Windows 3 0 s Dynamic Data Exchange facility to request all schedule items from the desktop personal information manager Polaris PackRat This results in a complete evaluation of all existing appointments in the desktop schedule The resultant data are then used to build the SCHEDULE MAP TABLE 601 in the mem ory of the desktop computer The SCHEDULE MAP TABLE 601 an example of which is shown i
7. COMPUTER PERSONAL INFORMATION MANAGER COMMON FORMAT 200 NAME 67 DESCRIPTION 119 TRANSLATION DTXLT DATABASE 1297 MAPPING A A R USER DATA 1 339 DTMAP pata 2341 USER N_ 343 13153 RECONCILIATION USER DATA N DTRECON SPREADSHEET 125 34 USER DATA 1 ERDATA 2 v947 USER DATA N 349 WORD PROCESSOR 127 DESCRIPTION 351 TEXT 353 FIG 3 U S Patent Feb 21 1995 Sheet 4 of 8 5 392 390 HANDHELD COMPUTER DESKTOP COMPUTER DATABASE MANAGER FIELD 3 LINE 3 4 ITEM FIELD 3 LINE 4 PRICE FIG 4 SCHEDULE MAP TABLE 601 DATE START END ALARM DESCRIPTION 12121991 1000 12151991 110 U S Patent TEL HandHeld Fields NAME NUMBER ADDRESS LINE 1 ADDRESS LINE 3 ADDRESS LINE 4 ADDRESS LINE 5 ADDRESS LINE 6 ADDRESS LINE 7 ADDRESS LINE 8 TEL HandHeld Fields NAME NUMBER ADDRESS LINE 1 ADDRESS LINE 3 ADDRESS LINE 4 ADDRESS LINE 5 ADDRESS LINE 6 ADDRESS LINE 7 ADDRESS LINE 8 Feb 21 1995 Sheet 5 of 8 5 392 390 Field Mapping PARADOX Field Mapping E FIG 5A PARADOX Field Mapping CUSTNAME CUSTNO ITEM ORDDATE PRICE Remove Add Field New Field Name Field Mapping PARADOX Field Mapping CUSTNAME CUSTNO ITEM ORDDATE PRICE PARADOX Field Mapping Add Field New Field Name FIG 5B U S Patent Feb 21 1995 Sheet 6 of 8 5 392 390 Field Update Key Field Name Name John Jones
8. Name specifies the name of handheld database file such as C for the name of the file to be used by the PHONE applica tion on the HP95LX Record Number specifies the unique record id of the record in the MAPPING data base which is required by the preferred embodiment for record uniqueness from a processing standpoint HH Field Name specifies the name of the handheld field and subfield number for each mapping record such as ADDRESS DT Field Name specifies the field name within DT File Name such as BUSINESS PHONE Multiple Field flag is an indicator that HH Field Name is a member of a group of multiple fields to be mapped to from a single physical field Number of HH Fields specifies the number of real handheld fields in the handheld computer which is information needed by the preferred embodiment manually provided in the preferred embodiment Field Type specifies the field type of DT Field Name such as A025 for ASCII 25 5 392 390 9 bytes Number of Keys specifies the number of fields in the desktop database manager s database The MAPPING database is created using an off the Shelf database manager in the preferred embodiment it is Paradox or C Tree At MAPPING database creation time the above fields are defined Each handheld appli cation is introduced to the MAPPING database by manually entering the HH Type HH Application DT Application
9. Record Number HH Field Name Multiple Field Number of HH Fields and Number of Fields fields DT File Name and HH File Name are created dynamically during map ping by the preferred embodiment For some desktop applications such as Polaris PackRat the DT Field Name and Field Type are manually entered into the MAPPING database For some other desktop applica tions such as Paradox the Paradox Engine can be used to query a Paradox database to provide the DT Field Name and Field Type Pseudocode for the specification of field mapping of data between the handheld computers and the desktop computer is shown in TABLE 1 The code implement ing this is on pages 60 65 of the microfiche appendix TABLE 1 Pseudocode for Specification of Field Mapping of Data between Handheld and Desktop Applications Open MAPPING database Display handheld field names IF mapping previously specified Display previous desktop field mappings DO UNTIL user presses OK button IF user specifies a handheld field to re map Display desktop fields which are eligible for mapping Ask user for desktop field to map Update desktop field table for specified handheid field Display new desktop field mapping END IF IF user specifies Cancel Exit END DO UNTIL user presses OK button Write new MAPPING database 114 115 The preferred embodiment allows the use of one to many field mappings and many to one field
10. and writing said twice translated fields to said output file 3 The method of claim 1 wherein the information of said first and second files is read from each of said files by a technique selected from techniques comprising a calling an inter application communication facil ity b running a database manager or 5 392 390 17 c running an application program for managing said first file as a slave and directing said application program to provide said information 4 The method of claim 3 further comprising the step of determining for each of said first and second files which of said techniques to use for said reading 5 The method of claim 1 further comprising the step of storing a map in the memory of a computer said map describing the range fields of the records of one of 10 said first and second files wherein said comparing step comprises comparing the range fields of the records of the other said file to the range keys described by said map 6 The method of claim 1 wherein said first file and said second file are of different record structures the method further comprising the steps of translating the information of the records of said first file into the record structure of said second file 15 20 25 30 35 45 50 55 65 18 7 method of claim 1 wherein said first and said second file are of different record structures the method further comprising the steps of tra
11. from among the steps comprising adding a record to one of said first and second files modifying a record of one of said first and second files wherein said choosing and comparing steps comprise determining if any of the following conditions ex ist a there exists a second record of said second file with a time range inexactly overlapping the time range of a first record of said first file b there exists a second record of said second file with a time range equal to the time range of a first record of said first file and the information in at least one other field of said first record differs from corresponding information of said second record 2 The method of claim 1 wherein said first and sec ond files have different record structures wherein prior to said comparing the information of said first and second records is translated to a com mon record structure different from the record structures of said first and second files the transla tion of said first record producing a first translated record and translation of said second record pro ducing a second translated record and wherein said comparing is between at least one field of said first translated record and correspond ing fields of said second translated record and wherein said writing comprises translating the information of said fields of said first translated record to the record structure of said output file thereby producing twice translated fields
12. in TABLE 4 Establish communication with the desktop application DO UNTIL last desktop Schedule has been queried Read desktop schedule item Add desktop schedule item to SCHEDULE MAP TABLE 601 END DO for each iteration of TABLE 4 Step 111 115 Look up handheld record s date and time range in SCHEDULE MAP TABLE 601 IF an item exists with overlapping date and time IF the description is different Ask the user to select Accept Ignore or Change IF the user changes the handheld date or time Restart DO UNTIL IF the user selects Accept Add the item to the desktop END IF END IF END IF END IF 107 108 109 110 111 112 113 114 115 116 117 TABLE 5 expands on the reconciliation section of TABLE 4 which describes the translation process for the SCHEDULE 105 application First the existing appointments in the desktop computer are requested from the desktop SCHEDULE 105 application The SCHEDULE MAP TABLE 601 is built based on those appointments This is done before any translation takes place Then each appointment from the handheld com puter is evaluated based on DATE 211 START TIME 213 END TIME 215 and DESCRIPTION 219 to determine if any overlapping time exists If there is any overlap and the DATE 211 START TIME 213 END TIME 215 and DESCRIPTION 219s are not exactly equal the user is queried for resolution The resultant appointments are stored on the desktop via either a database manager or inter application com munica
13. mappings One to many means that a single text field in the hand held application s data file can contain several pieces of data delimited by special characters which will be translated to multiple fields in the desktop applications data file Many to one means that the reverse transla tion will take place The one to many and many to one relationships are accomplished in the preferred embodiment by specify ing multiple mapping records in the MAPPING data base for a single field in either the handheld computer or the desktop application These records are marked specially as multiple field mappings for the translation process Multiple string fields are noted in the hard coded description of the record structure method 3 Future implementations will allow the user to specify that a field has multiple subfields on a point and click menu In the preferred embodiment the user is presented with a screen as shown in FIG 5 which displays the selections available for mapping If the user wishes to establish mappings from the handheld ADDRESS 205 209 field in the PHONE 103 application to a desk top Paradox database with fields such as TITLE 309 COMPANY 311 STREET 313 CITY STATE 315 and ZIP 317 he is presented with subfields ADDRESS 15 20 25 30 35 45 50 55 60 65 10 Linel 205 ADDRESS Line2 207 ADDRESS LineN 209 fields for mapping He then selects the subfield of ADDRESS Linel 205 by cl
14. 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 desk top 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 trans lation step uses the rules provided by the mapping step to convert the handheld data in one format to desktop 5 392 390 5 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 capabil ity to export and translate data from the desktop com puter to the handheld computer In this case the steps a
15. 03 SCHEDULE 105 TODO 107 DATA 109 and MEMO 111 These formats generally are determined by the hardware characteristics of the handheld computer They are hard coded into the preferred embodiment for each handheld computer PHONE 103 and DATA 109 are similar and provide for a single keyed indexed data base with multiple subfields allowed in non indexed fields Examples of the COMMON RECORD STRUC TUREs 300 are shown in FIG 2 for applications PHONE 103 SCHEDULE 105 TODO 107 DATA 109 and MEMO 111 FIG 3 shows an example of translation of data be tween the COMMON RECORD STRUCTURE 200 containing DATA RECORD1 361 DATA RE CORD2 363 DATA RECORDn 367 to various desktop applications such as a PERSONAL INFOR MATION MANAGER 121 containing PERSON 371 data fields NAME 301 BUSINESS PHONE 303 HOME PHONE 305 FAX NUMBER 307 TITLE 309 COMPANY 311 STREET 313 CITY STATE 315 ZIP 317 and NOTES 319 APPOINTMENT 373 data fields DATE 321 START TIME 323 END TIME 325 ALARM 327 and DESCRIPTION 329 and TODO 375 data fields DESCRIPTION 331 PRI ORITY 333 DUE DATE 335 and DETAIL 337 FIG 3 also shows the DTMAP 129 function which provides field mapping for a DATABASE MAN AGER 123 The user of the preferred embodiment is allowed to specify the destination field that corresponds to each field in the handheld application database As the translation takes place the fields are mapped ac cording to the user specification into the
16. 6 102 106 179 187 203 206 and 237 246 of the microfiche appen dix 5 392 390 11 TABLE 2 Pseudocode for Translating PHONE 103 or DATA 109 files Read MAPPING database Build mapping structure for translation DO UNTIL last handheld input record has been read Read handheld input record DO FOR each handheld input field Perform translations such as conversion from handheld computer binary format to 12 hour ASCII AM PM format specific to each handheld computer Build output field or multiple fields when there are multiple mapping records per field one to many END DO FOR each input field Write output record END DO UNTIL all input data records have been read 101 102 103 104 105 106 107 108 109 110 In Step 102 of TABLE 2 the mapping structure is an internal data structure presenting the information needed for translation from the MAPPING database containing the name format mapping and multiple field mapping characteristics of each field The process of building these data structures is accomplished by reading the MAPPING database and storing its data in the structure for reference during the translation The structure is an internal image of the MAPPING data base built to facilitate processing in the preferred em bodiment Step 105 through 108 iterates through records in the mapping structure Step 105 is performed for each field of the handheld computer s data Each handheld computer has its own format for
17. C to Palmtop IntelliLink lets New Wave users transfer files InfoWorld Jun 3 1991 Saltor et al Suitability of data models as canonical models for federated databases Universitat Politecnica de Catalu nya Spain undated Satyanarayanan Coda A Highly Available File System for a Distributed Workstation Environment School of Com puter Science Carnegie Mellon University undated Satyanarayanan Fundamental Challenges in Mobile Com puting School of Computer Science Carnegie Mellon University undated Sherman Information Technology What Software Should I Use to Organize My Life undated Schilit et al The ParcTab Mobile Computing System Xerox Palo Alto Research Center California undated SPI Database Software Technologies Record Displays Record 2 Serial No TDB0291 0094 and Record 4 Serial No iets0901 0073 undated User manual for PC Link for the B O S S and the PC Link for the B O S S Traveling Software Inc pp 62 82 por tion 1989 Wiederhold et al Consistency Control of Replicated Data in Federated Databases IEEE pp 130 132 Jul 12 1990 Extended Systems Preliminary Invalidity Contentions Extended Systems First Supplemental Preliminary Invalid ity Contentions Extended Systems Inc s Preliminary Claim Constructions and Preliminary Identification of Extrinsic Evidence Patent Local Rule 4 2 Preliminary Claim Constructions and Extrinsic Evidence
18. ER 123 SPREADSHEET PROGRAM 125 or WORD PROCESSING PROGRAM 127 Before communicating with the desktop application the user may specify the mapping of handheld and desk top 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 con flicting 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 Ac quiring 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 struc ture and the destination structure Once a mapping between two record structures is established it is main 10 20 25 30 45 50 55 65 6 tained a field mapping database for use by the transla tion steps There are three metho
19. MANAGER 123 which contains an earlier ver sion of the data in the handheld computer The pre ferred embodiment s code for this is on pages 110 111 and 246 248 of the microfiche appendix TABLE 3 Pseudocode for Reconciliation of Data for DATA 109 Application occurs for each record during Translation Step 105 108 in TABLE 2 Query desktop application for existence of handheld record key in desktop database IF there is a desktop record with the same key DO UNTIL all fields in the handheld record are checked based on mapping BEGIN IF the handheld and desktop fields are unequal Ask user to pick the handheld field the desktop field or wishes to change the handheld data and use the changed data IF user wishes to change the handheld data Update handheld field with changes ELSE IF user selects handheld data 101 102 103 104 105 106 107 108 5 392 390 13 TABLE 3 continued Pseudocode for Reconciliation of Data for DATA 109 Application occurs for each record during Translation Step 105 108 in TABLE 2 Update desktop field with handheld data END IF END IF END DO ELSE create a desktop record from the handheld data END IF 109 110 111 112 113 114 115 Step 101 utilizes either a database manager query or an inter application communication facility to deter mine if there is a record in the target application with the same key Steps 102 and 103 may involve translating the infor mation of both recor
20. United States Patent m9 Crozier DIANA US005392390A 3j Patent Number 4 Date of Patent 5 392 390 Feb 21 1995 54 METHOD FOR MAPPING TRANSLATING AND DYNAMICALLY RECONCILING DATA BETWEEN DISPARATE COMPUTER PLATFORMS 75 Inventor Keith Crozier Acton Mass 73 Assignee IntelliLink Corp Nashua N H 21 Appl No 867 167 22 Filed Apr 10 1992 GO6F 15 62 52 U S Cl 395 161 58 Field of Search 395 144 145 148 149 395 153 161 200 364 419 1 419 14 419 17 56 References Cited U S PATENT DOCUMENTS 4 807 182 2 1989 Queen 4 956 809 9 1990 George et al 5 142 619 8 1992 Webster III 5 251 291 10 1993 Malcolm 5 261 045 11 1993 Scully et al 395 161 OTHER PUBLICATIONS Automatically Synchronized Objects Research Dis closure 29261 p 614 Aug 1988 Cobb et al Paradox 3 5 Handbook 3rd Edition Ban tam 1991 pp 803 816 Alfieri The Best Book of WordPerfect Version 5 0 Hayden Books 1988 pp 153 165 and 429 435 IntelliLink Brochure 1990 User manual for PC Link for the B O S S and the PC Link for the B O S S Traveling Software Inc 1989 User Manual for Connectivity Pack for the HP 95LX Hewlett Packard Company 1991 Organizer Link II Operation Manual Sharp Electronics Corporation Open Network Com
21. and IntelliLink connect HP 95LX with HP NewWave IntelliLink for the HP NewWave product announcement HP Professional Aug 1991 HP announces expanded memory version of palmtop PC introduces 1 Megabyte HP 95LX and 1 Megabyte memory cards Business Wire Inc Mar 4 1992 Imielinski Mobile Computing DataMan Project Perspec tive Rutgers University undated IntelliLink 2 2 the software connection from desktop to palmtop Software Review IntelliLink 2 2 Evaluation PC Magazine Apr 28 1992 IntelliLink transfers palmtop PC data communications software from IntelliLink Inc brief article Product Announcement PC Week Nov 18 1991 Jacobs et al A Generalized Query by Example Data Manipulation Language Based on Database Logic IEEE Transactions on Software Engineering vol SE 9 No 1 Jan 1983 Kistler et al Disconnected Operation in the Coda File System School of Computer Science Carnegie Melon University Pennsylvania undated Kumar et al Log Based Directory Resolution in the Coda File System School of Computer Science Carnegie Melon University Pennsylvania undated Madnick et al Logical Connectivity Application Requirements Architecture and Research Agenda MIT System Sciences 1991 Hawaii Int Conf vol 1 IEEE Jun 1991 Meckler Corporation Palmtop to desktop linkage soft ware Database Searcher Jun 1992 Noble et al A Research Status Report
22. apestry Communications of the ACM vol 35 No 12 pp 61 70 Dec 1992 Now Up to Date Version 2 0 User s Guide Now Software Inc 1992 An Introduction to DataPropagator Relational Version 1 IBM Corporation 1993 Data Propagator Relational Guide Release 1 IBM Corpo ration May 1994 DataPropagator Relational Guide Release 2 IBM Corpora tion Dec 1994 DataPropagator NonRelational MVS ESA Version 2 Utili ties Guide IBM Corporation Jul 1994 DPROPR Planning and Design Guide IBM Corporation Nov 1996 DataPropagator Relational Capture and Apply 400 Version 3 IBM Corporation Jun 1996 DataPropagator Relational Capture and Apply for OS 400 Version 3 IBM Corporation Nov 1996 Newton Connection Utilities User s Manual for the Macin tosh Operating System Apple Computer Inc 1996 Newton Connection Utilities User s Manual for Windows Apple Computer Inc Newton Connection Utilities User s Manual for Macintosh Apple Computer Inc US 5 392 390 Page 4 Newton Backup Utility User s Guide for the Windows Operating System Apple Computer Inc 1995 Newton Backup Utility User s Guide for the Macintosh Operating System Apple Computer Inc 1995 Newton Utilities User Manual Apple Computer Inc 1995 FileMaker Pro Server Administrator s Guide Claris Corpo ration 1994 Connectivity Pack User s Guide for the HP 200LX and the HP 100LX Hewlett Packard Lotus cc Mail Relea
23. ause 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 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 re cord structure is described by the fields names data formats and byte offsets in the record The file format s 10 15 20 25 30 35 40 45 50 55 65 2 rules include description of the record structure of the constituent data records the record structure for any header records and how these header records aid navi gation to find specific data r
24. ble to the mapping facility for acquiring an understanding of the record structure then in a third method a descrip tion 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 appli cation the byte stream representation of the file s re cord 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 imple mentation 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 hand held 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
25. desktop appli cation database FIG 4 shows an example of field mapping between an application s data 109 FIELD1 401 FIELD2 403 FIELDS 405 FIELD4 407 FIELDS 409 of a HAND HELD COMPUTER 101 and a database manager application s data CUSTOMER NAME 413 CUS TOMER NUMBER 415 ORDER DATE 417 QUANTITY 419 ITEM 421 and PRICE 423 of a DESKTOP COMPUTER 115 20 25 30 35 45 50 55 65 8 FIG 5 shows an example of the preferred embodi ment s screen display which allows the user to specify field mapping In this example the translation is be tween a handheld computer s TEL database and the PARADOX database In FIG 5a the user has selected a handheld field from the TEL column such as AD DRESS LINEA and a desktop field from the PARA DOX column in this case QTY The selection is made by clicking a mouse or trackball or other pointer de vice on the two respective field names In FIG 58 the mapping between these two fields is completed de noted by the field name from the desktop database dis played in the middle mapping column next to the field name from the handheld database The mapping is stored in a MAPPING database which is referenced during the translation operation The MAPPING database will be used during the translation process to determine where data from each field of the source application record is to be stored in the target application record Each record of the MAP PING database describ
26. ds 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 data base manager programs have data dictionary records as headers in the database file These data dictionary re cords provide exactly the information required For example the Paradox Engine data access facility pro vides all field names for a Paradox database upon re quest in the preferred embodiment In a second method the application program pro vides 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 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 exam ple of this type of inter application communication fa cility 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 availa
27. ds into a common record structure dissimilar to the record structures of both files This translation may involve data format conversion of the fields but the information of the fields the meaning of the fields as interpreted under the record structure rule s is preserved In this case steps 107 and 109 involve another translation of the information into the correct record structure for writing to the handheld or desktop The preferred embodiment also performs translation from the desktop computer to the handheld computer utilizing techniques similar to TABLE 2 TABLE 2 describes the translation process for a keyed database Some applications such as the SCHED ULE 105 application do not have unique keys and have special characteristics In this case a different transla tion process is required For example in the preferred embodiment a single input record can generate multiple output records such as repeating appointments A re peating appointment typically is daily weekly monthly etc until a specified date and with a descrip tion for instance Branch Office Meeting every Mon day at 10 30 for the next two years Pseudocode for typical translation of data between the handheld application and the desktop application for the SCHEDULE 105 application is shown in TABLE 4 The preferred embodiment s code imple menting this is on pages 97 102 174 179 and 232 237 of the microfiche appendix TABLE 4 Pseudocode for Translati
28. e specific data item such as an appointment telephone book entry or memo entry already exists on the desktop computer application or platform the user is optionally notified of the conflict and given the opportunity to replace the existing data ignore the incoming data or modify the incoming data The criteria for determining the existence of conflicts is disclosed for updating schedule information and keyed databases 11 Claims 8 Drawing Sheets Microfiche Appendix Included 4 Microfiche 330 Pages DESKTOP COMPUTER PERSONAL INFORMATION MANAGER DATA BASE MANAGER SPREADSHEET MANAGER WORD PROCESSING MANAGER U S Patent Feb 21 1995 Sheet 1 of 8 5 392 390 DESKTOP COMPUTER 115 HANDHELD COMPUTER 7 101 103 PERSONAL INFORMATION PHONE MANAGER 105 DATA BASE MANAGER SCHEDULE 107 TO DO SPREADSHEET MANAGER Zzzoorr 109 DATA 111 WORD PROCESSING MANAGER FIG 1 U S Patent Feb 21 1995 Sheet 2 of 8 5 392 390 fus 115 DESKTOP HANDHELD COMPUTER COMPUTER PHONE ve 201 20 205 20 209 4 ADDRESS LINE SCHEDULE 105 COMMUN COMMUNICATIONS ICATIONS amp TRANSLATION HHCOMM DTCOMM TO DO 107 221 22 113 M 225 COMMON FORMAT 200 T 237 DATA DATA RECORD 2 39 2274 FIELD 1 DATA RECORD 3 41 2294 FIELD 2 2 DATA RECORD N 4243 2314 FIELD 11 MEMO 23394 DESCRIPTION 2354 TEXT FIG 2 U S Patent Feb 21 1995 Sheet 3 of 8 5 392 390 DESKTOP
29. ecords 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 manag ing general databases that is database files whose re cord structure can be specified at creation time by the user Database manager programs maintain data dictio nary 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 data bases of one specified record structure this specifica tion 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 charac ter 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 struc ture 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 key
30. ed to two separate computers different and inevitably conflicting up dates may be applied to the two separate copies of the data The user will often update the schedule he carries in his handheld computer and the user s secretary may make changes to the desktop computer s data while the user is away Dynamic reconciliation allows the user of the hand held computer to make changes to the handheld com puter while away from the desktop computer and dis cover the effect of these changes when returning to the 10 15 45 50 55 65 12 desktop computer The dynamic reconciliation runs on the desktop computer during the translation process from the handheld computer to the desktop computer and usually includes mapping of files of different for mats FIG 3 also shows the DTRECON 131 Desktop Reconciliation function which provides optional dy namic reconciliation of application specific conflicts between incoming handheld data and existing desk top data with capabilities to accept ignore or change incoming data If a record from the handheld computer has a key which matches a record in the desktop com puter each handheld field of the record is compared to each desktop field If they are different the user is queried for resolution FIG 11 shows an example of data for a database manager s database in FIG 4 In this case when a trans lation takes place from the handheld computer database of user DATA 109 wit
31. ems Final Invalidity Contentions Oct 10 2003 Defendant and Cross Complainant Extended Systems Inc s Identification of Prior Art Publications Pursuant to Patent L R 3 3 a Oct 17 2003 Defendant and Cross Complainant Extended Systems Inc s Amended Identification of Prior Art Publications Pursuant to Patent L R 3 3 a Oct 31 2003 Expert Report of John P J Kelly Ph D Oct 24 2003 IntelliLink for Windows User s Guide Version 3 0 Intel liLink Corporation 1993 Database Subsetting Tool Introduction to DST and DST Designer s Guide Syware Inc 1993 Sarin Robust Application Design in Highly Available Distributed Databases Proc 5 Symp Reliability in Dis tributed Software and Database Systems pp 87 94 Jan 13 15 1986 Los Angeles Distributed Management of Replicated Data Final Report Computer Corporation of America Oct 9 1984 Sarin et al Overview of SHARD A System for Highly Available Replicated Data Computer Corporation of America Apr 8 1988 SRI Int l Network Reconstitution Protocol RADC TR 87 38 Final Technical Report Jun 1987 Danberg A Database Subsetting Tool patent application Apr 12 1993 Lamb et al The Objectstore Database System Commu nications of the ACM vol 34 No 10 pp 50 63 Oct 1991 TT Interchange Time Technology AVG Sales amp Marketing Ltd 1995 Goldberg et al Using Collaborative Filtering to Weave an Information T
32. es all or part of the mapping of a single field of a handheld application s data file In the case where a single field in the source database is to be mapped to multiple fields in the target database multi ple records will appear in the MAPPING database for that target field with the multiple field flag set to TRUE Because the mappings in the MAPPINGs data base are bi directional i e the mappings are applicable both for handheld computer to desktop computer and desktop computer to handheld computer the appear ance of multiple records in the MAPPING database with the multiple field flag can cause multiple fields from a source database to be combined in a single field in a target database For instance the example of FIG 5 shows a case where one field in the handheld applica tion ADDRESS can be mapped to eight fields in the desktop application by specifying mapping for AD DRESS LINEI through ADDRESS LINES FIG 9 shows the fields for the MAPPING database HH Type specifies the handheld make model such as the Sharp Wizard HP95LX Palmtop Computer the Casio B O S S and the Psion Series 3 HH Applica tion specifies the handheld application name such as PHONE SCHEDULE or MEMO DT Application specifies the desktop application name such as Pack Rat or dBASE DT File Name specifies the name of the desktop database file such as C N SE2N AD DRESS DB for the Sidekick 2 0 PHONE ADDRESS application HH File
33. es use of this mapping to translate the data of a file from the source record struc ture 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 applica tions FIGS 5a and 55 show sample screen displays which enable the user to specify the mapping or correspon dence 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 plat forms FIG 9 shows the field structure of
34. etermining the existence of conflicts is disclosed for updating schedule information and keyed databases DESKTOP COMPUTER PERSONAL INFORMATION MANAGER PROCESSING MANAGER US 5 392 390 Page 2 U S PATENT DOCUMENTS 4 875 159 A 10 1989 Cary et al 707 203 4 939 689 A 7 1990 Davis et al 707 102 4 980 844 A 12 1990 Demjanenko et al 702 56 5 065 360 A 11 1991 Kelly 708 142 5 124 912 A 6 1992 Hotaling et al 705 9 5 134 564 A 7 1992 Dunn et al 705 33 5 136 707 A 8 1992 Block et al 707 201 5 155 850 A 10 1992 Janis et al 707 202 5 170 480 A 12 1992 Mohan et al 2 707 201 5 187 787 A 2 1993 Skeen et al 709 314 5 197 000 3 1993 Vincent 705 8 5 201 010 A 4 1993 Deaton et al 382 7 5 210 868 A 5 1993 Shimada et al 707 5 5 220 540 A 6 1993 Nishida et al 368 41 5 228 116 A 7 1993 Harris et al 706 50 5 237 678 A 8 1993 Kuechler et al 707 5 5 251 151 A 10 1993 Demjanenko et al 702 56 5 261 094 A 11 1993 Everson et al 707 201 5 272 628 A 12 1993 Koss 715 503 5 276 876 1 1994 Coleman et al 709 104 5 278 978 A 1 1994 Demers et al 707 101 5 278 982 A 1 1994 Daniels et al 707 202 5 283 887 A 2 1994 Zachery
35. facility has acquired an under standing of the fields of each of the two record struc tures the next step is to establish the actual field map 5 392 390 7 pings for instance to establish a correspondence be tween 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 ASCH charac ters 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 mapping directly from the source application s file format to the destination application s file format but to provide mappings from the source format to a COMMON RE CORD STRUCTURE 200 and a mapping from the COMMON RECORD STRUCTURE 200 to the desti nation format This case is most typical when one or 10 both of the file formats are in the third brute force cate gory The COMMON RECORD STRUCTURE 200 is typically chosen from one of the application programs record structures For instance in the case of handheld computer PHONE 103 files the program translates all PHONE 103 databases into the format used by the Sharp Wizard handheld computer The COMMON RECORD STRUCTURES 300 are defined by the pre ferred embodiment for applications PHONE 1
36. for Adaptation for Mobile Data Access School of Computer Science Carn egie Melon University undated PackRat PIM gets older and wiser with Release 4 0 PIM update sports enhanced interface greater ease of use InfoWorld Dec 23 1991 Palmtop PCs power by the ounce Hardware Review overview of six evaluations of palm top computers includes related articles on Editor s Choices suitability to task ratings impressions by individual users evaluation PC Magazine Jul 1991 Pen based PCs ready for prime time includes related article on comparison of operating systems list of vendors of pen based products PC Computing Nov 1991 Petersen et al Bayou Replicated Database Services for World wide Applications Computer Science Laboratory Xerox Palo Alto Research Center California undated US 5 392 390 Page 3 Product comparison Atari Portfolio Casio Executive BOSS HP 95LX Poget PC Psion series 3 Sharp Wizard InfoWorld Dec 16 1991 Ratner et al The Ward Model A Replication Architecture for Mobile Environments Department of Computer Sci ence University of California undated Reiher et al Reconciliation Based Replica tion for Mobile Computers UCLA undated Reiher et al Resolving File Conflicts in the Ficus File System Department of Computer Science University of California undated Riding the NewWave from P
37. h fields FIELD1 401 FIELD2 403 FIELDS 405 FIELD4 407 and FIELDS 409 and a desktop computer application s data CUSTOMER NAME 413 CUSTOMER NUMBER 415 ORDER DATE 417 QUANTITY 419 ITEM 421 and PRICE 423 conflicts would result during the translation of handheld data records 2 and 5 because their FIELD3L2 QTY and FIELD3L3 PRICE fields are different for the same key which is FIELD1 CUST NAME The user would be prompted to choose whether to accept the data from the handheld com puter The preferred embodiment allows the user to be op tionally notified during translation if any of the existing data in the desktop application are different from the data in the handheld application FIG 7 shows an ex ample of the preferred embodiment s screen display which allows the user to decide what to do about con flicts In this case the key field is Name If a record exists in the desktop application with the same Name the data in each field in the desktop is compared with the data from the handheld If the data in any given field is different the user may accept the update to the field ignore it or edit part or all of the incoming data in the record and write it to the desktop application s file Note that the final result may be to update some fields of the desktop record and not others An example of an application specific technique is documented in TABLE 3 for the import of handheld computer DATA 109 to a desktop computer DATA BASE
38. han the other A difference conflict is detected when the two range keys are exactly the same the appointments begin and end at the same time but the text describing the appoint ment differs in the two databases A third kind of dis crepancy arises when a range key in one database has no overlapping range key in the other database for in stance an appointment was added in one schedule data base but not the other FIG 8 shows an example of the preferred embodi ment s screen display which allows the user to decide what to do about conflicts In this case the SCHED ULE MAP TABLE 601 has been searched to deter mine if there is an appointment during any of the time between 9 00AM and 10 00AM There was an appoint ment named Announcement from 9 30AM until 10 30AM The user may accept the new appointment ignore it or change the time or date of the incoming appointment and accept If the data is changed it will be re checked for conflicts against the SCHEDULE MAP TABLE 601 Pseudocode for typical application specific reconcili ation of data between the handheld computers and the desktop computer for the SCHEDULE 105 application is shown in TABLE 5 The preferred embodiment s implementation of this is on pages 101 177 178 235 and 284 288 of the microfiche appendix TABLE 5 Pseudocode for Reconciliation of Data for SCHEDULE 105 Application Steps 106 117 of TABLE 5 occur for each record during Translation Step 111 115
39. icking on the ADDRESS Linel 205 and selects the desktop target field TITLE 309 He then selects the subfield of AD DRESS Line2 207 by clicking on the ADDRESS Line2 207 and selects the desktop target field COM PANY 311 The process is repeated for each handheld subfield and desktop target field The above process results in six records in the MAP PING database the first maps ADDRESS 1 205 to TITLE 309 ADDRESS Line2 207 to COMPANY 311 ADDRESS Line3 to STREET 313 ADDRESS Line4 to CITY 315 ADDRESS Line5 to STATE 315 and ADDRESS 1 to ZIP 317 Special coding in the preferred embodiment handles the CITY STATE pairing These records will be used by the translation process to map the six subfields in the AD DRESS field of each record from the handheld com puter to the six desktop fields in each target record in the desktop computer The first step in the use of the mapping and transla tion facilities described is to copy data from a desktop computer to a handheld or vice versa FIG 2 shows a handheld computer application HHCOMM 113 transferring PHONE 103 data fields NAME 201 NUMBER 203 ADDRESS 205 etc SCHEDULE 105 data fields DATE 211 START TIME 213 END TIME 215 ALARM 217 and DE SCRIPTION 219 TODO 107 data fields PRIORITY 221 DUE DATE 223 and DESCRIPTION 225 DATA 109 data fields FIELDI1 227 FIELD2 229 FIELDn 231 and MEMO 111 data fields DESCRIP TION 233 and TEXT 235 to desk
40. its application data files The data translations of step 106 are hard coded into the translation facility of the pre ferred embodiment for each pair of source and destina tion data formats as discussed earlier for the HP95LX handheld computer An example is the conversion of the three single byte integer fields in the HP95LX date to an ASCII formatted date of mm dd yyyy The year byte in the HP95LX format is number of years since 1900 so 1900 must be added to the single byte integer which has a maximum value of 255 In these data format conversions the source bits differ from the desti nation bits but the information the meaning of those bits in the context of the record structure rules is the same Step 107 iterates through records in the mapping structure for fields in the handheld computer which have multiple field mapping characteristics In this case multiple mapping records will exist in the mapping structure one for each subfield If a field in the source file has been mapped to multiple fields in the destina tion the splitting occurs by recognizing tabs as subfield separators in the first file Conversely if several fields in the source map to a single field in the destination the strings of the source fields are catenated together into the destination field with tab separators The danger presented by the above described trans fer and translation facilities is the classic consistency problem Once data has been copi
41. k Wh FIELD1 CUSTNAME N FIELD2 CUSTNO N FIELD3L1 ITEM Y FIELD3L2 Y FIELD3L3 PRICE Y FIELD3L4 ORDDATE Y FIG 10 U S Patent Handheld Computer Data Rec 1 of UN Feb 21 1995 Sheet 8 of 8 RECONCILLIATION OF HANDHELD DATA and DESKTOP DATABASE MANAGER TRANSLATION 5 392 390 FIELD1 FIELD2 FIELDSL1 FIELD3L2 FIELDSLS FIELD3L4 Ajax 201 Brown 306 Dillard 443 Sheraton 617 Avis 023 Desktop Computer Data Fan 10 Heater 2 Toaster 8 Phone 100 Ashtray 20 Rec CUSTNAME CUSTNO ORDDATE 1 0 201 Brown 306 Dillard 443 Sheraton 617 Avis 023 2 3 92 10 3 2 92 4 2 12 92 5 2 27 92 100 3 10 92 80 FIG 11 100 125 75 5000 100 ITEM Fan Heater Toaster Phone Ashtray 2 3 92 2 9 92 2 12 92 2 27 92 2 15 92 PRICE 100 250 75 5000 400 5 392 390 1 METHOD FOR MAPPING TRANSLATING AND DYNAMICALLY RECONCILING DATA BETWEEN DISPARATE COMPUTER PLATFORMS REFERENCE TO MICROFICHE APPENDIX A source code listing of the preferred embodiment of the invention is appended in the form of 328 pages re corded 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 Trade mark Office file or records but otherwise reserves all co
42. lumn 9 line 1 after bytes insert Column 9 lines 22 23 delete The code implementing this is on pages 60 65 of the microfiche appendix UNITED STATES PATENT AND TRADEMARK OFFICE CERTIFICATE OF CORRECTION PATENT 5 392 390 Page 2 of 2 DATED February 21 1995 INVENTOR S Keith Crozier It is certified that error appears in the above indentified patent and that said Letters Patent is hereby corrected as shown below Column 10 lines 65 68 delete The code implementing this in the preferred embodiment is on pages 65 66 102 106 179 187 203 206 and 237 246 of the microfiche appendix Column 12 lines 51 53 delete The preferred embodiment s code for this is on pages 110 111 and 246 248 of the microfiche appendix Column 13 lines 42 44 delete The preferred embodiment s code implementing this is on pages 97 102 174 179 and 232 237 of the microfiche appendix Column 15 lines 27 29 delete The preferred embodiment s implementation of this is on pages 101 177 178 235 and 284 288 of the microfiche appendix Column 16 line 16 intensive should be interactive Signed and Sealed this Sixth Day of June 1995 Attest VS ence igs BRUCE LEHMAN Commissioner of Patents and Trademarks Attesting Officer UNITED STATES PATENT AND TRADEMARK OFFICE CERTIFICATE OF CORRECTION PATENTNO 5 392 390 DATED gt February 21 1995 INVENTOR S Keith Crozier
43. n FIG 6 is used for comparison during the translation of sched ule data from the handheld computer Another method of querying schedule information from a handheld computer involves running the sched ule application as a slave of the schedule reconciliation program The reconciliation program issues requests to the schedule application and the schedule application presents the appointments one by one to the reconcili ation program The SCHEDULE RECONCILIATION facility then requests each appointment from the handheld schedule application by whatever access method is provided by the handheld application and compares each appointment obtained from the handheld to the SCHEDULE MAP TABLE If the handheld appoint ment is a repeating appointment then it is expanded into multiple records as far into the future as specified by the repeating appointment record This can result in multiple records being produced in the destination file as the image of a single repeating appointment record in the source file Schedule conflicts or more generally conflicts be tween two records with range keys can be of two kinds either an inexact overlap conflict or a difference conflict An inexact overlap conflict is when two range keys overlap but are not exactly the same for instance 5 392 390 15 an appointment in the handheld s schedule database overlaps an appointment in the desktop s schedule data base but one begins or ends earlier t
44. n 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 trans lating 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 reconcili ation In a first aspect the invention features a method for an interactive user of a computer to dynamically recon cile the information of two database files The method comprises the steps of choosing corresponding records from the two files comparing the information of corre sponding 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 determin ing if any schdule conflicts exist either the time of an appointment has been changed in one of the two sched ule 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 inve
45. ndated Continued Primary Examiner Raymond J Bayerl 57 ABSTRACT Traditionally it has been difficult to share data among diverse computer applications and platforms because of underlying differences in data formats Although the mean ing or purpose of the data may be similar or identical for example two appointments entered using separate computer applications the differences in data formats required by the various computer applications and platforms renders such sharing difficult A method is disclosed for the translation of dissimilarly formatted data between disparate computer applications and platforms The method also provides for the dynamic reconciliation of conflicts in the data for example two appointments scheduled at the same time based on both the content of the data and on specific preferences indicated by the user of the translation facility First the data is translated to a common format based on the user specified mapping of data fields identifying hand held and desktop fields to be translated and considering the characteristics of the handheld or desktop computer application Then if the specific data item such as an appointment telephone book entry or memo entry already exists on the desktop com puter application or platform the user is optionally notified of the conflict and given the opportunity to replace the existing data ignore the incoming data or modify the incoming data The criteria for d
46. nslating the information of said first and second files into a common record structure different from the record structure of said first or second file 8 The method of claim 1 wherein said allowing step results in multiple records written to said second file as an image of a single record from said first file 9 The method of claim 1 wherein the output of said method is written to an output file distinct from said first and second files 10 The method of claim 1 wherein said time range fields represent event times in a calendar 11 The method of claim 10 wherein said first and second calendar databases represent the calendars of the same individual stored in different application pro grams UNITED STATES PATENT AND TRADEMARK OFFICE CERTIFICATE OF CORRECTION PATENT NO 5 392 390 Page 1 of 2 DATED February 21 1995 INVENTOR S Keith Crozier It is certified that error appears the above indentified patent and that said Letters Patent is hereby corrected as shown below On the title page In column 2 line 31 amp 32 delete the reference to Microfiche Appendix Included 4 Microfiche 330 Pages FIG 4 QUANITY should be QUANTITY FIG 11 RECONCILLIATION should be RECONCILIATION Column 1 delete the paragraphs referencing the microfiche appendix lines 6 16 Column 2 line 41 after should insert Column 3 line 46 schdule should be schedule Co
47. nt so that the system will apply itself in that environ ment There are several file transfer programs for communi cating between computers including Organizer Link 2 from Sharp Electronics PC Link for the Casio B O S S TM from Traveling Software HP95LX Connectivity Pack from Hewlett Packard and 3 Link from Psion PLC These file transfer programs do not 5 392 390 3 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 provid ing 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 map ping 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 appli cation s files The invention can also be used to transfer compare and reconcile data betwee
48. ntion offers a solution to previously un solved portions of the data translation problem by pro viding means to translate data from one record struc ture 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 inven tion offers translations that are new in the art by trans lating 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 con venient user interface for tying together previous data 10 20 25 35 40 45 50 55 60 65 4 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 struc ture to a different destination record structure The method comprises the steps of first establishing a map ping 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 mak
49. on MA US 73 Assignee Pumatech Inc San Jose CA US Reexamination Request No 90 006 545 Feb 12 2003 Reexamination Certificate for Patent No 5 392 390 Issued Feb 21 1995 Appl No 07 867 167 Filed Apr 10 1992 Certificate of Correction issued Jun 6 1995 Certificate of Correction issued Jul 7 1998 Certificate of Correction issued Oct 13 1998 51 Int Cl G06F 3 00 2006 01 G06F 17 60 2006 01 52 US CL ien 715 751 715 963 715 971 707 201 707 104 1 705 9 58 Field of Classification Search 715 751 715 963 968 971 733 709 205 707 10 707 104 1 201 203 705 9 8 See application file for complete search history 56 References Cited U S PATENT DOCUMENTS 4 162 610 A 7 1979 Levine ee 368 41 4 432 057 A 2 1984 Daniell et al 707 8 4 807 154 A 2 1989 Scully et al 345 751 4 807 155 A 2 1989 Cree et al 345 733 4 817 018 A 3 1989 Cree et al 345 751 4 819 156 A 4 1989 DeLorme et al 714 15 4 819 191 A 4 1989 Scully et al 345 751 4 827 423 A 5 1989 Beasley et al 700 96 4 831 552 A 5 1989 Scully et al 2 345 751 4 866 611 A 9 1989 Cree et al 364 300 Continued OTHER PUBLICATIONS Adly HARP A Hierarchical Asynchronous Replication Protocol for Massively Replicated Systems Computer Laboratory Cambridge University United Kingdom u
50. on of SCHEDULE 105 files Open handheld file obtained from handheld application Establish communication with the desktop application utilizing inter application communication or a database manager as appropriate DO UNTIL last handheld record has been processed IF the handheld record is a repeating appointment DO UNTIL ali repeating appointments are created Create desktop appointment record END DO END IF Translate appointment data IF the user requested notification of conflicts Check SCHEDULE MAP TABLE 601 for conflict IF conflict exists Ask the user to accept ignore change record END IF END IF END DO 114 115 116 Some applications such as the SCHEDULE 105 ap plication have possibly non unique range keys rather than the unique point keys assumed in the reconciliation process of TABLE 3 In this case the preferred imple mentation utilizes a special technique which performs Un 10 15 20 25 30 45 55 65 14 reconciliation based upon the date and time of appoint ments This type of reconciliation is not field by field as in a keyed database it is based on the entire information of the appointment record being evaluated and com pared to the existing overall schedule on the desktop The technique requires a SCHEDULE MAP TABLE 601 which contains all existing appointments in the SCHEDULE 105 data An example of data in the SCHEDULE MAP TABLE 601 is shown in FIG 6 DATE 211 START TIME 213 END TIME 215
51. puting Technical Overview HANDHELD COMPUTER H H c o M M Sun Technical Report Microsystems Inc pp 1 32 1987 Zahn et al Network Computing Architecture pp 1 11 19 31 87 115 117 133 187 199 201 209 1990 Primary Examiner Mark K Zimmerman Assistant Examiner N Kenneth Burraston Attorney Agent or Firm Fish amp Richardson 57 ABSTRACT Traditionally it has been difficult to share data among diverse computer applications and platforms because of underlying differences in data formats Although the meaning or purpose of the data may be similar or identi cal for example two appointments entered using sepa rate computer applications the differences in data for mats required by the various computer applications and platforms renders such sharing difficult A method is disclosed for the translation of dissimilarly formatted data between disparate computer applications and plat forms The method also provides for the dynamic rec onciliation of conflicts in the data for example two appointments scheduled at the same time based on both the content of the data and on specific preferences indi cated by the user of the translation facility First the data is translated to a common format based on the user specified mapping of data fields identifying hand held and desktop fields to be translated and considering the characteristics of the handheld or desktop computer application Then if th
52. pyright 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 typi cally provide some combination of personal information management functions database functions word pro cessing 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 applica tions on desktop computers Many users of handheld computers also own a desk top 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 be tween 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 bec
53. re 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 hand held 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 reconcili ation 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 applica tion HHCOMM 113 HHCOMM 113 is responsible for accepting the data from the handheld computer and translating it to the COMMON RECORD STRUC TUREs which are defined by the preferred embodi ment The COMMON RECORD STRUCTURES are then passed to DESKTOP COMPUTER 115 by trans fer application DTCOMM 117 which utilizes DTXLT 119 inter application communications or database man ager facilities as appropriate to translate the data to formats accepted by desktop applications PERSONAL INFORMATION MANAGER 121 DATABASE MANAG
54. s 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 9AM to 10AM every Monday until Nov 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 genera tion are diskless in the classical sense do not exist on many of these handheld computers Within this pa tent 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 com puter 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 shar ing 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 environ me
55. se 2 Lotus Development Corporation 1991 1993 User s Guide Lotus Organizer Release 1 0 Lotus Develop ment Corporation 1992 FileMaker Pro User s Guide Claris Corporation 1990 1992 Poesio et al Metric Constraints for Maintaining Appoint ments Dates and Repeated Activities Slater Newton s Legacy 3COM and Microsoft Battle for Market Share Apple Newton 3Com Palm III Microsoft Palm size PC peronal digital assistants Product Informa tion Information Access Company 1998 Negrino ACT 2 5 1 ACT for Newton 1 0 UMI Inc 1996 Zilber Toy story personal digital assistants Product Infor mation Information Access Company 1996 Wingfeld Desktop to Newton connectivity UMI Inc 1996 Now Software Announces Updated Synchronization Soft ware for Newton 2 0 Devices Now Synchronize Simulta neously Updates MessagePad Now Up to Date amp Con tact Business Wire Inc 1995 Claris Ships FileMaker Pro 3 0 for Macintosh and Win dows Business Wire Inc 1995 Alsop Distributed Thinking Realizing the gravity of its PDA problems Apple has drawn me back to Newton InfoWorld Media Group 1995 Rubin Now Software stays in sync Now Synchronize file synchronization software for Macs and Newton PDAs Software Review EvaluationBrief Article Information Access Company 1995 Now Calender Scheduler Contact Mgr for Mac Update Post Newsweek Business Information Inc
56. tem Issues in Nomadic Com puting Matsushita Information Technology Laboratory New Jersey undated Bishop et al The Big Picture Accessing information on remote data management system UNIX Review vol 7 No 8 p 38 7 Aug 1989 Bowen Achieving Throughput and Functionality in a Common Architecture TheDatacycle Experiment IEEE p 178 Dec 1991 Dayton FRx extends reporting power of Platinum Series IBM Desktop Software s line of accounting software PC Week vol 8 No 5 p 29 2 Feb 4 1991 Demers et al The Bayou Architecture Support for Data Sharing Among Mobile Users Computer Science Labora tory Xerox Palo Alto Research Center California undated Froese File System Support for Weakly Connected Opera tion pp 229 238 undated Guy Ficus A Very Large Scale Reliable Distributed File System Technical Report CSD 910018 Computer Sci ence Dept UCLA Technical Report Jun 3 1991 Guy et al Implementation of the Ficus Replicated File System appeared in Procs Of the Summer USENIX Conf Anaheim CA pp 63 71 Jun 1 1990 Hammer et al An Approach to Resolving Semantic Het erogeneity in a Federation of Autonomous Heterogeneous Database Systems Computer Science Department Univer sity of Southern California undated Hammer et al Object Discovery and Unification in Fed erated Database Systems University of Southern Califor nia undated HP
57. tion facility 5 10 15 20 25 30 35 45 30 55 60 65 16 The discussion of the preferred embodiment concen trated on the mapping transfer and reconciliation of data from a handheld computer to a desktop The same techniques can be applied to map transfer and reconcile data from a desktop to a handheld between two desk top computers or between handheld computers or between applications on the same computer Because each model of handheld computer is slightly different in the way it communicates with a desktop the preferred embodiment includes a small communciations component 113 of FIG 1 that must be customized to each handheld computer Many other embodiments of the invention are within the following claims What is claimed is 1 A method for an intensive user of a computer to dynamically reconcile the information of a first calen dar database file and a second calendar database file the method comprising the steps of choosing a first record from said first file and a corre sponding second record from said second file said choosing comprising comparison of corresponding time range fields of said records comparing the information of at least one field of said first record to the information of at least one corre sponding field of said second record and allowing said user after a comparison in which a difference between said fields is discovered to decide based on said comparison
58. top computer appli cation DTCOMM 117 which reads and translates the handheld computer data to the COMMON RECORD STRUCTURE 200 containing DATA RECORDI 237 DATA RECORD2 239 DATA RECORDn 243 Once the mapping has been specified and the data transferred the translation may take place The transla tion process for PHONE 103 and DATA 109 handheld data to database manager databases is controlled by the MAPPING database Each record represents a field or subfield of the handheld computer s data The mapping is performed to fields in the desktop application s data base based on the field names of the desktop s applica tion The MAPPING database for the data in FIG 4 Would contain records as shown in FIG 10 In this case FIELDI data from the handheld would be mapped to the CUSTNAME field of the desktop application FIELD2 data from the handheld would be mapped to CUSTNO FIELD3L1 data would be mapped to ITEM FIELD3L2 data would be mapped to QTY FIELD3L3 data would be mapped to PRICE and FIELD3L4 data would be mapped to ORDDATE In this mapping FIELD3 of the handheld computer is a multiple field mapping FIELD3 has four subfields which are mapped to four fields in the desktop com puter database Pseudocode for typical application specific transla tion of keyed PHONE 103 or DATA 109 files between handheld applications and desktop applications is shown in TABLE 2 The code implementing this in the preferred embodiment is on pages 65 6
Download Pdf Manuals
Related Search