Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1999-09-14
2002-05-21
Shah, Sanjiv (Department: 2172)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06393434
ABSTRACT:
BACKGROUND
1. Technical Field
The present invention relates generally to the field of data synchronization and, in particular to the update synchronization process between data in one computer processing device and their replicas in another computer processing device, with data transmission enabled by a wired or wireless computer network.
2. Background Description
The data synchronization process, or the sync process, refers to the computation process that brings different database replicas of an application (e.g., a calendar application, an address book application, a relational database table) into a synchronized state. For the purposes of the present invention, a synchronized state can be either a consistent state or an identical state. A consistent state between multiple database replicas of an application means that the final differences between these replicas are caused by the user's choice and, therefore, are anticipated by the user.
For example, a user may synchronize the Address Book application in his Palm Pilot with his Lotus Notes system in his personal computer (PC). Typically, the user may choose the option to synchronize the two Address Book replicas into an identical state. This means that all the information which participates in the sync process from one replica is also properly represented in the other replica. It is to be noted that not every item in an application from one device may participate in the sync process. For example, some items in a Lotus Notes Address Book record may not have corresponding items in a Palm Pilot's Address Book application. Hence they do not participate in the sync process and are irrelevant to the resulting sync state. We also note that the same information may be represented by different storage or syntactical formats in various systems. For example, the dates “May 20, 1999” in one device and “May 20, 1999” in another device represent the same date though their physical appearances are different.
As an alternative to achieving an identical state as a result of synchronization, the user may choose the option to synchronize two items to a consistent state. For example, in synchronizing the E-mail application between the Palm Pilot and the Lotus Notes, the user may specify that only new e-mail items from the Palm Pilot are to be transmitted to the Lotus Notes system whereas new e-mail items from the latter are not to be sent to the former during the current sync process. Such a situation may occur when the user is in a hurry to send an e-mail composed in the Palm Pilot through the Lotus Notes, and the full two-way sync process may be too long to wait for.
With respect to the above example, the database replicas of the two e-mail systems may not be in an identical state after synchronization because new e-mail items may exist in the Lotus Notes but not in the Palm Pilot. But if all new e-mail items from the Palm Pilot are properly represented in the Lotus Notes, the two replicas are in a consistent state as their differences are the results of the user's choice. It is to be noted that a consistent state can be brought to be an identical state later by a sync process with the user choosing a two-way complete sync.
An important issue in data synchronization is the handling of conflicts. A conflict occurs when the same record represented in multiple database replicas has, since the last sync process, been independently modified in such a way that, among all replicas, no single version of this record can be determined to be more current than any others. For example, the phone number of an Address Book record (e.g., in the record for John Doe) has been independently changed in both the Palm Pilot and the Lotus Notes since the user last synchronized the two systems. Suppose at least one of the systems (e.g., the Palm Pilot) does not support a reliable time-stamp that records exactly when a record is modified. When the user synchronizes the two systems again, if the two new phone numbers for John Doe from each of the two systems are different, then the sync process cannot determine if either number is more current than the other number. The two versions of the same record (that of John Doe) therefore create a conflict.
Those skilled in the art will appreciate that conflicts may not be caused by independent updates alone (referred to as the update-update conflict). Deleting a record in a system (e.g., the Palm Pilot) may also cause a conflict if a replica of this record has been updated independently in another system (e.g., Lotus Notes) since the two systems last synchronized (referred to as the delete-update conflict or update-delete conflict).
Thus, for the sync process to bring multiple replicas of the same information into a synchronized state, the sync process should detect whether there exist conflicts among these replicas, and, if so, then the sync process should resolve these conflicts. Typically, the sync process performs the preceding steps (detecting and resolving conflicts) by invoking specialized conflict resolution procedures to handle conflicts.
Prior art in conflict handling during data synchronization can be generally categorized into three approaches. The first approach allows the user or the administrator of the system to specify some record-based (or coarse-grained) default actions for an application when conflicts occur. For example, the user (or the administrator) can configure the system such that if an update conflict occurs while synchronizing the Address Book application between the Palm Pilot and the Lotus Notes, then the updated record from the former always overrides that from the latter (or vice versa). The set of actions for resolving conflicts typically include: (1) updates from one system always override updates from the other system, or vice versa (for update-update conflict); (2) updates always override deletes, or vice versa (for update-delete conflict); and (3) rename (change the identity of) the record of one system, or vice versa (for update-update conflict).
In the first approach, the sync process typically treats each record (such as, for example, an Address Book record, a Calendar record, a Expense Application record, and so forth) as an atomic unit and does not have knowledge of the detailed formats inside these records. Therefore, we call this approach coarse-grained because the conflict resolution actions always involve the whole record (e.g., the entire Address Book record for John Doe) and not the more detailed information inside each record (e.g., the last name, phone number, zip code for John Doe). This approach is generally referred to as the default-setting approach.
The second approach allows for fine-grained handling of conflict by way of the sync process. In particular, while synchronizing an application, an executable code (referred to as a plug-in) developed specifically for this application is loaded and executed. All the details in synchronizing data from different replicas such as retrieving data, inserting data, updating data, detecting conflicts, and resolving conflicts are handled in this plug-in. The plug-in for an application may be developed by the developer of the application, and not the developer of the synchronization system. For example, the plug-in (also referred to as the “conduit”) for synchronizing the E-mail application between the Palm Pilot and the Lotus Notes is developed by the Lotus Notes organization that supplies the Lotus Notes E-mail application, and not by the Palm Pilot organization that supplies the synchronization system called HotSync. Because the application developers have full knowledge of the data format of their application, the plug-in they develop for their application can manipulate detailed information inside each record for synchronization or conflict resolution. This approach is generally referred to as the plug-in approach.
The third approach is similar to the first approach in that the sync process provides record-based conflict resolution settings to handle conflicts. However, this approach differs in that these settings
Huang Yun-Wu
Pollak Roger A.
Ponzo John L.
F. Chau & Associates LLP
Shah Sanjiv
LandOfFree
Method and system for synchronizing data using fine-grained... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for synchronizing data using fine-grained..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for synchronizing data using fine-grained... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2907042