|Número de publicación||US20010014893 A1|
|Tipo de publicación||Solicitud|
|Número de solicitud||US 09/240,563|
|Fecha de publicación||16 Ago 2001|
|Fecha de presentación||29 Ene 1999|
|Fecha de prioridad||11 Ene 1995|
|También publicado como||US5684990, WO1996021898A1|
|Número de publicación||09240563, 240563, US 2001/0014893 A1, US 2001/014893 A1, US 20010014893 A1, US 20010014893A1, US 2001014893 A1, US 2001014893A1, US-A1-20010014893, US-A1-2001014893, US2001/0014893A1, US2001/014893A1, US20010014893 A1, US20010014893A1, US2001014893 A1, US2001014893A1|
|Inventores||David J. Boothby|
|Cesionario original||David J. Boothby|
|Exportar cita||BiBTeX, EndNote, RefMan|
|Citas de patentes (62), Citada por (22), Clasificaciones (8), Eventos legales (3)|
|Enlaces externos: USPTO, Cesión de USPTO, Espacenet|
 This invention relates to programs that synchronize databases.
 There are many situations in which it is important for a user to be able to synchronize databases among computers. For instance, many users have handheld computers, which typically weigh less than a pound, fit in a pocket, and provide some combination of personal information management functions, database functions, word processing functions, and spreadsheet functions. Many users of handheld computers also own desktop computers used for applications that manage databases similar to the databases carried in handheld computers. Typically the user adds data to the two computers independently, e.g., one enters data into the handheld computer when out at a customer site but enters data into the desktop computer when in the office. In such cases, the user normally would at some point want to synchronize the databases on the handheld and desktop databases, i.e., automatically review changes made to the databases on the two computers, and revise the data in both databases so that both have the same and most current data.
 Databases are collections of data organized as data records, each composed of a number of data fields. For example, in an address database, a very simple data record might be “John, Smith, Smith Co.”, where “John” is the information content of a FIRSTNAME field, “Smith” is the information content of a LASTNAME field, and “Smith Co.” is the information content of a COMPANYNAME field.
 Databases are managed by two broad classes of programs, database managers and special-purpose application programs (both referred to herein as database programs). A database manager is a program for managing general databases, that is, databases in which the structure of the data records can be specified at creation time by the user. Other databases are managed by special-purpose application programs, e.g., a telephone directory program of a handheld computer. Unlike the record structures of general databases, the record structures of these special-purpose databases typically are not specified by the user.
 There are generally two ways in which software can specify a record in these databases. One or more of the fields of a record can be designated as a key, with particular records being specified by the contents of the key (e.g., the above-mentioned address database might use the LASTNAME field as a key, so that records could be specified by the contents of that field). Records can also be specified using unique identification numbers (“unique IDs”), assigned by the database program at the time the record is created.
 There are known techniques for synchronizing databases, but they generally depend on the databases having been specially designed to facilitate synchronization. For example, Microsoft Schedule+ permits multiple Schedule+ databases to be synchronized, but this is only possible because Schedule+ was specially designed with synchronization in mind. Similarly, directory databases built in conformance with the CCITT X.500 international standard can be synchronized by virtue of conforming to this standard. One way in which synchronization is achieved in such products is by the use of unique IDs assigned when a record is created. During synchronization, the software is able to use the unique IDs to compare the contents of corresponding data records in the two databases (e.g., corresponding data records for the same dinner appointment can be compared even if the date, time, or description for the appointment has been changed in one or both databases).
 Another feature available for synchronizing databases specially designed for synchronization are not-yet-synchronized flags, which are set whenever a record is changed (e.g., when a dinner appointment is moved to a new date and time). If the software finds a discrepancy during synchronization, the program then checks each record's not-yet-synchronized flag and, if one flag is set and the other is not, the data in the record with the set flag prevails because it is assumed to be newer. If both flags are set, the data transfer program resorts to using a trump rule (e.g., handheld always prevails over desktop) or interacting with the user because the program does not have enough information to choose one over the other. After synchronization all of the flags are reset.
 Also available when databases have been specially designed for synchronization is a time-and-date-of-last-modification stamp for every record stored in the databases. Assuming sufficiently accurate synchronization of the time-and-date clocks of the computers running the databases, the synchronization program can always determine, even if both of the corresponding items have been changed since last synchronization, which change is the most recent, and assume that the more recent record prevails. But such time and date stamping of records will typically be impracticable owing to the scarcity of memory and file space, especially on a handheld computer.
 With databases not specially designed for synchronization, there has not heretofore been any practical technique for synchronization. It has been necessary to use either (1) brute force replacement of all of the records of one database with all of the records of the other (e.g., using software such as LapLink) or (2) a reconciliation technique developed by IntelliLink Corp., of Nashua, N.H. (described in U.S. patent application Ser. No. 07/867,167, filed on Apr. 10, 1992; incorporated by reference).
 IntelliLink's reconciliation technique uses key fields (e.g., the date and time of appointments in a calendar database) to establish a correspondence between records of the two databases, and then examines the records for differences (e.g., a different appointment description for the same date and time). The differences are reconciled either by invoking one or more trump rules (e.g., handheld always prevails over desktop) or by interacting with the user (e.g., by displaying the relevant mismatching information and asking the user to choose).
 An advantage of the reconciliation technique is its ability to handle disparate databases (e.g., databases with different data structures, designed for use with different application software and on different computer platforms). To do its job, the IntelliLink reconciliation technique does not require the presence of special synchronization-enabling features such as unique IDs, not-yet-synchronized flags, or time-and-date-of-last-modification stamps. It can work with databases of radically different design, by first translating the differently structured databases into a common intermediate format, and then using key fields to establish correspondence between records. Yet despite those advantages, and the fact that the reconciliation technique was a huge improvement over the brute force replacement technique that existed before it, reconciliation still falls short of real synchronization.
 One difficulty with the existing reconciliation technique is that unless a trump rule such as “handheld always prevails over desktop” is employed, the user is interrogated every time there is a data mismatch, and that interrogation necessarily takes up a lot of time.
 In addition, the reconciliation technique does not handle data deletions well, because it inherently assumes that if an item on one computer is empty and its corresponding item on the other computer is not, the empty item should be updated with the non-empty item. This means, e.g., that when a user deletes an appointment from a calendar database on one computer, that appointment could be restored during reconciliation, defeating the user's attempt to delete it.
 The invention makes possible synchronization of disparate databases, overcoming the shortcomings of the prior reconciliation technique. It does so by providing a status file which allows the synchronization program to determine if data records in one or more databases have been changed or deleted since the last synchronization, or whether new data records have been added.
 Preferably, the status file contains the data present in the two databases after the most recent synchronization. Corresponding sets of records are chosen from each of the two databases and from the status file, and a comparison is made of the information content of the records. Based on that comparison, updating decisions are made for each set of records, for example, decisions are made whether to select the information content of one database record over the information content of the other, and finally the selected information is written to the status file as well as the databases.
 The invention makes it possible to synchronize databases of radically different design, operating on different computer platforms. E.g., a calendar database proprietary to a particular handheld computer or personal digital assistant (PDA) can now be synchronized with a calendar database running on a user's desktop (e.g., Lotus organizer, or Microsoft Schedule+).
 With the invention, it becomes quite practical for a person to use both a PDA and a desktop calendar database in a group scheduling environment, i.e., one in which calendar databases are interconnected between users so that appointments may be added and deleted automatically. Now if an appointment is added or deleted on one database, for example, the user's desktop, the synchronization process of the invention can recognize that such has occurred and automatically update the other during a synchronization.
 Synchronization of disparate databases can be performed with much less user interaction than was necessary with the prior reconciliation technique. E.g., by applying a rule that newer database changes prevail over older changes, in connection with a preferred decision matrix, the user can allow synchronization to occur with minimal or no interaction.
 The invention permits databases that were specially designed for synchronization to be synchronized with databases that were not so designed. Embodiments of the invention can work with databases that provide time-and-date-of-last-modification stamps, not-yet-synchronized flags, or unique IDs, but also with databases that provide no such stamps, flags, or IDs.
 The invention also provides a backup function for information in a database because the status file can be used to reconstruct a complete, earlier version of the database.
 The invention may be used to synchronize two or more databases on the same computer or on different computers.
 Other features and advantages of the invention will be apparent from the following description of preferred embodiments, and from the claims.
FIG. 1 illustrates both a handheld and a desktop computer, and shows, diagrammatically, a database and data records for each.
FIG. 2 shows a handheld database, status file, desktop database, and temporary workspace of a preferred embodiment of the invention.
FIG. 3 is a flowchart of the preferred embodiment.
 FIGS. 4-6 are three sections of a flowchart showing the preferred embodiment in more detail.
 Shown in FIG. 1 are two computers on which disparate databases reside, a database 7 in a handheld computer 1 and a database 11 in a desktop computer 3. Synchronization depends on knowledge of: (1) how records 5 in one database 7 correspond to records 9 in the other 11 and (2) the history of updates in each database. For correspondence, the synchronization program relies on the basic translation and mapping capabilities of the prior IntelliLink reconciliation technique (e.g., as described in U.S. patent application Ser. No. 07/867,167, filed on Apr. 10, 1992, referred to earlier).
 The synchronization program is typically run repeatedly over time. E.g., the user may choose to run synchronization daily, weekly, or on an irregular “as needed” basis.
 When conflicts are detected during synchronization (i.e., differences in the content of key fields), they may be resolved automatically or interactively, depending on user preference. The user may select among different automatic rules, including:
 1. Always propagate deletions even if that means deleting a recently changed item.
 2. Let handheld changes override desktop changes.
 3. Let desktop changes override handheld changes.
 4. Keep both versions and no longer attempt to reconcile them.
 5. Leave the conflict unresolved.
 If a conflict is to be resolved interactively, the user is presented with a dialog box that allows the user to select one of these rules.
 Since it is possible that a user may enter the same new information into both the handheld and the desktop computer, the synchronization program checks for this possibility in order to avoid duplication of data. The program compares all new desktop records with all new handheld records, and, when matches are found, the matches are assumed to correspond to one another.
FIG. 2 shows the data structure of a preferred embodiment. There are three databases: handheld database N, desktop database V, and status file P. In this embodiment, the handheld database has unique IDs that identify its records, but the desktop database has no such IDs, and its records are identified through the use of key fields. The handheld records are mapped to desktop records using a key field or set of key fields. For example, in a telephone database, the mapping could be done using the LASTNAME field as the key field. This makes it possible to achieve a correspondence between the handheld IDs and the desktop key fields. For example, a handheld record with an ID of “A987” ends up associated with a desktop record identified by the key field LASTNAME=“Smith”.
 The following descriptions assume that all of the corresponding records of the handheld database and the desktop database have already been mapped using such existing methods. The records in the status file are identified using IDs originating in the handheld database. FIGS. 2-6 use the following abbreviations: P for status file, N for handheld computer database, V for desktop computer database, and S for synchronization workspace.
 The synchronization workspace S is a temporary memory workspace used by the synchronization program. The workspace S maintains several pieces of information for each record in the database, including a handheld-ID, a CRC value, and status indicators providing handheld-status and desktop-status. The handheld-ID is a unique ID identifying each record in the handheld database. The CRC value identifies a desktop record, and is obtained using a well-known algorithm that maps a unique variable-length string of data to a nearly unique integer of shorter, fixed length. E.g., if the key fields used to identify a desktop record are Firstname, Lastname, and Company Name, then the CRC value would be a short, fixed length integer derived from a string such as “John, Smith, Smith Co.” Methods of comparing strings of data are well-known in the art; this embodiment uses a method in which first the CRC values of strings are computed and compared; if the CRC values match, the full strings are then compared directly.
 Handheld-status and desktop-status generally indicate the status of the handheld and desktop data records with respect to corresponding records in the status file. For example, a previously synchronized item that has since been changed in the handheld computer but is unchanged in the desktop would have handheld-status set to CHANGED and desktop-status set to UNCHANGED. Since handheld records are correlated first, before desktop records, the meaning of handheld-status is slightly different from the meaning of desktop-status. Handheld-status describes handheld records relative to status file records only. Desktop-status, on the other hand, describes desktop records relative to status file records and any new handheld records.
 The status file P, which is saved after a synchronization and used as input to the next synchronization, is a file containing one record per pair of synchronized handheld and desktop records. Each status file record (each line in file P in FIG. 2) is a simple unconflicted record, i.e., is identified by only one set of key fields or IDs. Due to prior mapping of handheld records to desktop records, the use of only one set presents no problem with respect to the other set. In this embodiment, status file records are identified by handheld-IDs, but in the case where there are no IDs in either database, the status file records could be identified by a key field from one database.
FIG. 3 shows the synchronization process. The previous status file is read (step 200). This gives a list of records. The first time that synchronization is run, no previous status file exists, in which case step 200 produces an empty list of records.
 Synchronization begins with the program retrieving records from the handheld database and comparing them to the records in the status file (step 205). For every handheld record, the synchronization program takes note of the record's status, i.e., whether a corresponding status file record exists, and if so, whether the handheld record has been changed. If there are new handheld records, i.e., records in the handheld database that are not in the status file (e.g., new telephone number entries in a telephone database, or new appointments in a calendar database), the synchronization program retains these new handheld records for use in subsequent steps.
 Next, the synchronization program (step 210) retrieves records from the desktop database and compares them to the records in the status file and the new handheld records. For every desktop record, the synchronization program takes note of the record's status, i.e., whether a corresponding status file record exists, and if so, whether that record has changed in the desktop database. If there are new desktop records, i.e., records in the desktop database that are neither in the status file nor among the new handheld records, the synchronization program takes note of these new desktop records for subsequent steps.
 After this comparing step, the synchronization program (step 215) uses a decision matrix to generate a To-Do list of actions to be taken with respect to the records in the handheld database and the desktop database. The decision matrix takes as inputs the status with respect to the status file, i.e., CHANGED, UNCHANGED, NEW, or ABSENT, of each record in each record set and outputs a To-Do list action item for each record set. For example, if the status of a handheld record is UNCHANGED and the status of its corresponding desktop record is CHANGED, then the decision matrix output action item is to update the handheld record and the status file record to match the desktop record.
 Finally, the synchronization program (step 220) goes through the To-Do list and performs updates to the desktop database, handheld database, and status file. If any of the updates to the desktop and handheld databases are unsuccessful, the synchronization program refrains from making these updates to the status file, so that the synchronization program will retry the update at the next synchronization.
 FIGS. 4-6 show the synchronization process in more detail. The information in status file P is copied into synchronization workspace S (step 300). Arrays of handheld-IDs, CRCs, and status indicators are created and populated in workspace S (step 305). All status indicators are initialized with handheld-status set to ABSENT and desktop-status set to ABSENT. Subsequent processing steps will change these status indicators to other values if the corresponding records still exist in handheld database N or desktop database V or both.
 Handheld records are loaded, one by one, into workspace S. In this loading process, incoming handheld records are correlated with pre-existing status file records using the handheld-ID as the correlation key (step 310). When a match of IDs is found, all mapped fields of the handheld record and status file record are compared (step 315). If all fields match exactly, handheld-status is set to UNCHANGED (step 320), but otherwise handheld-status is set to CHANGED (step 330). If handheld-status is set to CHANGED, all data from the handheld record is stored in workspace S alongside the data from the corresponding status file record. No further “conflict resolution” action is taken at this point in the procedure.
 If there is no status file record with the same handheld-ID as the incoming handheld record, the incoming handheld record is stored in workspace S (step 325). For this incoming handheld record, its handheld-ID is retained, the CRC of its key fields is computed and stored for later use in a possible match to a desktop record, and its status indicators are set as follows: handheld-status is set to NEW and desktop-status is set to ABSENT.
 Steps 310-335 are repeated for all handheld records (step 335).
 Once the last handheld record is processed, correlation of handheld records with status file records is complete. From this point on in this procedure the term handheld record refers only to any record in workspace S for which handheld-status is set to NEW.
 Desktop records are loaded, one by one, into workspace S (FIG. 5). For each desktop record, first an unused exact match is sought. An unused exact match is a status file record or new handheld record wherein all fields match those of the desktop record (step 340) and desktop-status is set either to ABSENT or CHANGED (step 345). If such a match record is found with desktop-status set to ABSENT (step 350), desktop-status is simply updated to UNCHANGED (step 360). However, if such a match record is found with desktop-status set to CHANGED, this means that there is more than one desktop record that maps to the match record. It also means that when a previous desktop record was loaded, it was identified, using key field matching as described below, as a partial match for this handheld or status file record. Now the partial match is replaced with the present desktop record, desktop-status is set to UNCHANGED, and then the partial match is run through the key field search again (step 385).
 If no unused exact match is found, then a key field match is sought (step 355). The key field match must also be unused, i.e., the status file record or handheld record found must also have a desktop-status that is set to ABSENT (step 365). If such a match is found, desktop-status is set to CHANGED and all of the data in the desktop record is stored alongside the data of the match (375). No further “conflict resolution” action is taken at this point in time because this desktop record could eventually be replaced if an exact match is later found for this handheld or status file record, as described above in step 385. If no unused key field match is found, a new record is created in workspace S with handheld-status set to ABSENT and desktop-status set to NEW (385).
 Steps 340-385 are repeated for all desktop records (step 370).
 Once all desktop records are exhausted, workspace S is scanned from top-to-bottom and decisions are made, using the decision matrix of Table 1, about how to resolve any conflicts, either interactively or non-interactively (FIG. 6, step 390). The decisions are not implemented immediately but rather are held as actions items in a To-Do list.
TABLE 1 Decision Matrix Handheld- Desktop- # Status Status To Do 1 UNCHANGED UNCHANGED Nothing. 2 UNCHANGED CHANGED Update handheld database N and workspace S to match desktop database V. 3 UNCHANGED ABSENT Delete record from handheld database N and workspace S. 4 CHANGED UNCHANGED Update desktop database V and workspace S to match handheld database N. 5 CHANGED CHANGED If changes are independent, update handheld database N, workspace S, and desktop database V; otherwise use a conflict resolution (CR) dialog with the user or apply an automatic rule. 6 CHANGED ABSENT Resolve CHANGE vs. DELETE conflict, either via CR dialog or by applying an automatic rule. 7 ABSENT UNCHANGED Delete record from desktop database V and workspace S. 8 ABSENT CHANGED Resolve CHANGE vs. DELETE conflict, either via CR dialog or by applying an automatic rule. 9 ABSENT ABSENT Delete record from workspace S (it has already been deleted from handheld database N and desktop database V). 10 ABSENT NEW Add record to handheld database N and workspace S. 11 NEW ABSENT Add record to desktop database V and workspace S. 12 NEW UNCHANGED Add record to workspace S (synchronizing identical items here). 13 NEW CHANGED Resolve conflict, either via CR dialog or by applying an automatic rule. (Note that this case is semantically different from case #5, so different automatic rules may apply, but the CR dialog may be the same.)
 All updates in the To-Do list for desktop database V are attempted (step 405). If a particular update, i.e., an ADD, CHANGE, or DELETE, is successful (step 395), the same update is also performed on the corresponding record in workspace S (step 400).
 Next, all updates in the To-Do list for handheld database N are attempted (step 420). If a particular update is successful (step 410), the same update is also performed on the corresponding record in S (step 415).
 Finally, all records with both handheld-status and desktop-status set to ABSENT are deleted from workspace S (step 425). This reduces workspace S down to a minimum size so that it contains only the information that must be stored as the new status file for the next synchronization.
 Other embodiments of the invention are within the following claims. For example, whereas the embodiment described above synchronized a database with records identified by IDs with another with records identified by key fields, the invention also works with databases in which both databases have only records identified by key field, and with databases that provide time-and-date-of-last-modification stamps, not-yet-synchronized flags, or unified or non-unified IDs (as well as with databases that provide no such stamps, flags, or IDs).
 The invention is also not limited to use with a combination of a handheld computer and a desktop computer (although it is particularly advantageous for such an environment). The invention may be used to synchronize data of two or more desktop computers, two or more notebook computers, two or more handheld computers, or any combination of microcomputers, minicomputers, mainframe computers, or other computers. The invention may also be used to synchronize two or more databases on the same computer.
 The invention may also be used to synchronize more than two databases. This can be accomplished, for example, by running the synchronization program multiple times, each time synchronizing a new database to an already-synchronized database. For example, in order to synchronize databases A, B, C, and D, the synchronization program could be run first on A and B, then A and C, then A and D; or first on A and B, then B and C, then C and D, etc. Separate status files would be maintained for each pair.
 What is claimed is:
|Patente citada||Fecha de presentación||Fecha de publicación||Solicitante||Título|
|US4162610 *||31 Dic 1975||31 Jul 1979||Levine Alfred B||Electronic calendar and diary|
|US4432057 *||27 Nov 1981||14 Feb 1984||International Business Machines Corporation||Method for the dynamic replication of data under distributed system control to control utilization of resources in a multiprocessing, distributed data base system|
|US4807154 *||29 Ene 1987||21 Feb 1989||International Business Machines Corporation||Method for developing automatic replies in an interactive electronic calendaring system|
|US4807155 *||29 Ene 1987||21 Feb 1989||International Business Machines Corporation||Electronic calendaring method for confirmation of resource availability during event calendaring|
|US4817018 *||29 Ene 1987||28 Mar 1989||International Business Machines Corporation||Electronic calendaring method which provides for automatic assignment of alternates in requested events|
|US4819156 *||13 Jun 1986||4 Abr 1989||International Business Machines Corporation||Database index journaling for enhanced recovery|
|US4819191 *||29 Ene 1987||4 Abr 1989||International Business Machines Corporation||Electronic calendaring method to establish calendar floating triggers for calendared events and processes|
|US4831552 *||29 Ene 1987||16 May 1989||International Business Machines Corporation||Method for concurrently displaying entries from a plurality of different electronic calendars based on interactively entered non-temporal criteria|
|US4939689 *||9 Abr 1987||3 Jul 1990||Crowninshield Software, Inc.||Outline-driven database editing and retrieval system|
|US5043871 *||26 Mar 1987||27 Ago 1991||Hitachi, Ltd.||Method and apparatus for database update/recovery|
|US5124912 *||15 May 1987||23 Jun 1992||Wang Laboratories, Inc.||Meeting management device|
|US5134564 *||19 Oct 1989||28 Jul 1992||Dunn Eric C W||Computer aided reconfiliation method and apparatus|
|US5170480 *||25 Sep 1989||8 Dic 1992||International Business Machines Corporation||Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time|
|US5197000 *||15 May 1991||23 Mar 1993||International Business Machines Corporation||Method of scheduling meetings|
|US5201010 *||19 May 1992||6 Abr 1993||Credit Verification Corporation||Method and system for building a database and performing marketing based upon prior shopping history|
|US5204958 *||27 Jun 1991||20 Abr 1993||Digital Equipment Corporation||System and method for efficiently indexing and storing a large database with high data insertion frequency|
|US5220540 *||12 Feb 1992||15 Jun 1993||Sharp Kabushiki Kaisha||Data processing apparatus with schedule creation, prioritization, display and control functions|
|US5261094 *||8 Abr 1991||9 Nov 1993||International Business Machines Corporation||Asynchronous replication of data changes by distributed update requests|
|US5276876 *||16 May 1990||4 Ene 1994||International Business Machines Corporation||Registration of resources for commit procedures|
|US5321832 *||22 May 1990||14 Jun 1994||Hitachi, Ltd.||System of database copy operations using a virtual page control table to map log data into physical store order|
|US5323314 *||31 Dic 1991||21 Jun 1994||International Business Machines Corporation||Method and system for graphic representation of meeting parameters in a data processing system|
|US5379418 *||30 Sep 1993||3 Ene 1995||Hitachi, Ltd.||Highly reliable online system|
|US5392390 *||10 Abr 1992||21 Feb 1995||Intellilink Corp.||Method for mapping, translating, and dynamically reconciling data between disparate computer platforms|
|US5412801 *||17 Ene 1990||2 May 1995||E-Net||Gap recovery for off-site data storage and recovery systems|
|US5421012 *||20 May 1993||30 May 1995||Wang Laboratories, Inc.||Multitasking computer system for integrating the operation of different application programs which manipulate data objects of different types|
|US5434994 *||23 May 1994||18 Jul 1995||International Business Machines Corporation||System and method for maintaining replicated data coherency in a data processing system|
|US5448718 *||20 Abr 1992||5 Sep 1995||International Business Machines Corporation||Method and system for time zero backup session security|
|US5455945 *||19 May 1993||3 Oct 1995||Vanderdrift; Richard||System and method for dynamically displaying entering, and updating data from a database|
|US5519606 *||21 Ene 1992||21 May 1996||Starfish Software, Inc.||System and methods for appointment reconciliation|
|US5530853 *||6 Mar 1995||25 Jun 1996||International Business Machines Corportaion||Method for filtering items in a computer application program container object using filter data for related entries in a container object of another application program|
|US5530861 *||28 Nov 1994||25 Jun 1996||Hewlett-Packard Company||Process enaction and tool integration via a task oriented paradigm|
|US5530939 *||29 Sep 1994||25 Jun 1996||Bell Communications Research, Inc.||Method and system for broadcasting and querying a database using a multi-function module|
|US5557518 *||28 Abr 1994||17 Sep 1996||Citibank, N.A.||Trusted agents for open electronic commerce|
|US5561798 *||7 Jun 1995||1 Oct 1996||International Business Machines Corporation||Computer program product and program storage device for improving data recovery performance|
|US5574902 *||2 May 1994||12 Nov 1996||International Business Machines Corporation||Efficient destaging of updated local cache pages for a transaction in a multisystem and multiprocess database management system with a high-speed shared electronic store|
|US5581753 *||28 Sep 1994||3 Dic 1996||Xerox Corporation||Method for providing session consistency guarantees|
|US5581754 *||7 Dic 1994||3 Dic 1996||Xerox Corporation||Methodology for managing weakly consistent replicated databases|
|US5588147 *||14 Ene 1994||24 Dic 1996||Microsoft Corporation||Replication facility|
|US5621795 *||27 Dic 1994||15 Abr 1997||Pitney Bowes Inc.||System and method for fault tolerant key management|
|US5623540 *||5 Oct 1994||22 Abr 1997||Siemens Rolm Communications, Inc.||PBX data retrieval and reporting system and method|
|US5640561 *||6 Jun 1995||17 Jun 1997||International Business Machines Corporation||Computerized method and system for replicating a database using log records|
|US5649195 *||22 May 1995||15 Jul 1997||International Business Machines Corporation||Systems and methods for synchronizing databases in a receive-only network|
|US5649196 *||9 Nov 1995||15 Jul 1997||Legent Corporation||System and method for distributed storage management on networked computer systems using binary object identifiers|
|US5659741 *||17 Abr 1995||19 Ago 1997||Stuart S. Bowie||Computer system and method for storing medical histories using a carrying size card|
|US5671407 *||7 Dic 1994||23 Sep 1997||Xerox Corporation||Application-specific conflict detection for weakly consistent replicated databases|
|US5699517 *||17 May 1996||16 Dic 1997||Hitachi, Ltd.||Information processing equipment for selecting as information data of a message to be sent one program having a score greater than a threshold value|
|US5704029 *||23 May 1994||30 Dic 1997||Wright Strategies, Inc.||System and method for completing an electronic form|
|US5737539 *||28 Oct 1994||7 Abr 1998||Advanced Health Med-E-Systems Corp.||Prescription creation system|
|US5754306 *||5 Sep 1995||19 May 1998||Hewlett-Packard Company||System and method for a communication system|
|US5790974 *||29 Abr 1996||4 Ago 1998||Sun Microsystems, Inc.||Portable calendaring device having perceptual agent managing calendar entries|
|US5799072 *||4 Mar 1996||25 Ago 1998||Callmanage||Telecommunications call management system|
|US5819274 *||6 Jun 1997||6 Oct 1998||Xcellenet, Inc.||Methods, systems and computer program products for transferring files from a data processing server to a remote/mobile data processing node|
|US5877760 *||6 Jun 1996||2 Mar 1999||Mitsubishi Denki Kabushiki Kaisha||User interface for synchronously and independently scrolling windows|
|US5926824 *||14 Nov 1995||20 Jul 1999||Canon Kabushiki Kaisha||System and method for retrieving a document by inputting a desired attribute and the number of areas in which the attribute occurs as a retrieval condition|
|US5956508 *||7 Abr 1997||21 Sep 1999||International Business Machines Corporation||Creation of manageable management collections using filters|
|US6018303 *||10 Nov 1998||25 Ene 2000||Visnet Ltd.||Methods and means for image and voice compression|
|US6272074 *||1 Jul 1997||7 Ago 2001||Oracle Corporation||Method and apparatus for generating recurring events in a calendar/schedule system|
|US6321236 *||3 Ago 1999||20 Nov 2001||Arkona, Inc.||Distributing database differences corresponding to database change events made to a database table located on a server computer|
|US6449640 *||19 Jun 1998||10 Sep 2002||International Business Machines Corporation||Web server with unique identification of linked objects|
|US6516327 *||24 Sep 1999||4 Feb 2003||International Business Machines Corporation||System and method for synchronizing data in multiple databases|
|US6678715 *||27 Ago 1999||13 Ene 2004||Kabushiki Kaisha Toshiba||Systems and apparatus for switching execution of a process in a distributed system|
|US20020156798 *||9 Abr 1999||24 Oct 2002||Larue Chris||System and methods for synchronizing datasets using version indicators to detect obsolete changes|
|Patente citante||Fecha de presentación||Fecha de publicación||Solicitante||Título|
|US7130914 *||12 Dic 2001||31 Oct 2006||Nec Corporation||Database synchronization system and method|
|US7231408 *||24 Jul 2002||12 Jun 2007||Nokia Corporation||Data recovery in a distributed system|
|US7366743||2 Ago 2005||29 Abr 2008||Colligo Networks Inc.||Synchronous peer-to-peer multipoint database synchronization|
|US7617537 *||10 Nov 2009||Sony Corporation||Communication system and its method and communication apparatus and its method|
|US7640273 *||8 Sep 2006||29 Dic 2009||Sap Ag||Business intelligence data reconciliation system|
|US7650367 *||27 Ene 2006||19 Ene 2010||Tekelec||Methods, systems, and computer program products for detecting and restoring missing or corrupted data in a distributed, scalable, redundant measurement platform database|
|US7818435||14 Dic 2000||19 Oct 2010||Fusionone, Inc.||Reverse proxy mechanism for retrieving electronic content associated with a local network|
|US7895334||19 Jul 2000||22 Feb 2011||Fusionone, Inc.||Remote access communication architecture apparatus and method|
|US7966285||19 Mar 2008||21 Jun 2011||Ionaphal Data Limited Liability Company||Synchronous peer-to-peer multipoint database synchronization|
|US8250056 *||15 Oct 2009||21 Ago 2012||Dearborn John S||Web-based decision matrix display|
|US8341116 *||15 Mar 2002||25 Dic 2012||Verizon Business Global Llc||Systems and methods for updating an LDAP|
|US8359337 *||9 Dic 2009||22 Ene 2013||Ingenix, Inc.||Apparatus, system and method for member matching|
|US8473543 *||6 Jul 2009||25 Jun 2013||Microsoft Corporation||Automatic conflict resolution when synchronizing data objects between two or more devices|
|US8874503 *||15 Jul 2002||28 Oct 2014||Jmw Productivity, Llc||Method, system and apparatus for organizing information for managing life affairs|
|US20020073109 *||12 Dic 2001||13 Jun 2002||Nec Corporation||Database synchronization system and method|
|US20020138489 *||15 Mar 2002||26 Sep 2002||Trivedi Prakash A.||Systems and methods for updating an LDAP|
|US20040186842 *||23 Jul 2003||23 Sep 2004||Darren Wesemann||Systems and methods for providing access to data stored in different types of data repositories|
|US20040192260 *||18 Feb 2004||30 Sep 2004||Seiko Epson Corporation||Data backup system and data backup method, wearable computer, mail transmission system, image-information transmission system, and data backup program|
|US20050141367 *||31 Ene 2005||30 Jun 2005||Sony Corporation||Communication system and its method and communication apparatus and its method|
|US20100174688 *||8 Jul 2010||Ingenix, Inc.||Apparatus, System and Method for Member Matching|
|US20110004702 *||6 Ene 2011||Microsoft Corporation||Automatic conflict resolution|
|CN102265277A *||1 Jun 2011||30 Nov 2011||华为技术有限公司||数据存储系统的操作方法和装置|
|Clasificación de EE.UU.||1/1, 707/E17.032, 707/E17.005, 707/999.201|
|Clasificación cooperativa||G06F17/30581, Y10S707/99954|
|30 Jul 2001||AS||Assignment|
Owner name: PUMATECH, INC., CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:PUMA TECHNOLOGY, INC.;REEL/FRAME:012025/0783
Effective date: 20001220
|12 Mar 2004||AS||Assignment|
Owner name: INTELLISYNC CORPORATION, CALIFORNIA
Free format text: CHANGE OF NAME AS REFLECTED IN CERTIFICATE OF OWNERSHIP AND MERGER;ASSIGNOR:PUMATECH, INC.;REEL/FRAME:015083/0806
Effective date: 20040217
|7 Dic 2005||AS||Assignment|
Owner name: INTELLILINK CORP., NEW HAMPSHIRE
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BOOTHBY, DAVID J.;REEL/FRAME:017099/0683
Effective date: 19950125
Owner name: PUMA TECHNOLOGY, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTELLILINK CORP.;REEL/FRAME:017099/0690
Effective date: 19970402