Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-10-23
2002-11-05
Coulter, Kenneth R. (Department: 2154)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C709S203000
Reexamination Certificate
active
06477543
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates generally to an update synchronization and/or transformation process between data in a client and replicas of the data in information management systems.
BACKGROUND
With the rapid advancement of semiconductor, storage and display technologies, handheld or mobile devices, which may only be occasionally connected to the network, have become increasingly popular. The ways that mobile devices such as 3Com's PALM PILOT™ are being used have also become very versatile. For example, a PALM PILOT™ user may have an e-mail application that is to be synchronized with a Lotus NOTES™ e-mail system in an office desktop. There may also be a stock quote application in the PALM PILOT™ which gets updated by synchronizing with a well-known stock quote site located in the Internet. There may also be a PALM PILOT™ expense application that is to be synchronized with home PC finance software. Therefore, it is quite possible that various handheld applications within one device need to synchronize with different applications in various information management systems (such as Lotus NOTES™, Microsoft EXCHANGE™, file systems, relational databases, object-oriented databases) running on networked computers. It is also possible that one handheld application (such as e-mail) has different versions for different handheld devices (e.g., PALM PILOT™, Sharp's ZAURUS™, Psion PLC's PSION™ and various other palmtop devices running Microsoft WINDOWS CE™).
Because handheld devices such as PALM PILOTs™ are typically only occasionally connected to the network with the connection lasting only a short time, it is critical that the synchronization processes between the applications in the handhelds and their counterparts in various networked computers be very efficient (so that the synchronization process can be successfully completed while the handhelds are connected to the network). With the handheld devices typically offering less CPU power and less memory for computation, the synchronization processes are usually not conducted inside the handheld devices.
Here, a computer hosting the replicas of data from handheld devices is called a replica host, or replica source. Because handheld devices generally have less computing power and memory than a replica host, the handheld devices typically conduct synchronization inside their replica hosts, which are desktop PCs. Typically, synchronization is first initiated by pushing a handheld device button (e.g., the HotSync button in a PALM PILOT™). Immediately after the button is pushed, a synchronization manager software in the replica host (e.g., PALM PILOT's™ HotSync Manager in the desktop personal computer (PC) takes over the synchronization process. In the case of a PALM PILOT™, the HotSync Manager conducts synchronization for a PALM PILOT™ application by executing an application-specific program (called Conduit in the PALM PILOT™) which synchronizes this application between the PALM PILOT™ and a desktop PC through application-specific logic. If multiple applications need to be synchronized, the HotSync Manager executes each of their corresponding Conduits in sequential order. Based on this approach, synchronization is always conducted between one PC and one handheld device. Simultaneous synchronization between multiple handheld devices and one PC is not available.
In general, conducting synchronization processes directly in the replica host is very limiting. The reason is that there may exist many applications (such as e-mail, calendar, address book) that each can be shared by many different handheld devices (e.g., PALM PILOT™, ZAURUS™, PSION™). Each application may require a different synchronization logic for each different device. To process synchronization for all applications and all devices properly, a replica host may need to install and manage many different versions of the synchronization processes in order to handle different handheld devices. Thus, conducting synchronization processes in the replica hosts creates a heavy burden in management of the different handheld devices and their synchronization processes. For many replica hosts, their most mission-critical task is not to synchronize with various handhelds, but to run as an information server such as a database server, a groupware server, or as a personal desktop computing device. Running synchronization on them therefore detracts from their mission-critical tasks.
A more efficient approach to management synchronization between multiple handheld devices and replica hosts is to deploy synchronization proxies (or synchronization (sync) servers, or synchronization proxy servers, or simply sync proxies) that maintain persistent network connections, to conduct synchronization on behalf of both the handhelds and the replica hosts (devices hosting the replicas also maintain a persistent network connection).
To synchronize, a handheld first establishes a network connection. Once connected, instead of making a direct connection to the targeted replica host for synchronization, it makes a synchronization request to a sync proxy. Upon receiving such a request, the sync proxy establishes a connection to the targeted replica host and starts the synchronization process by issuing input/output requests to both the handheld and its replica host. A straightforward design of the synchronization proxy is for the proxy to maintain all device-specific and application-specific synchronization programs that can handle all the handheld device types and all the information management system types hosted by the replica hosts. This means that each application must have an unique synchronization program written specifically for any combination between all the handheld device types and all the information management systems hosting the replicas of handheld data. For example, a synch proxy may maintain four different synchronization programs for an e-mail application in order to support both PALM PILOT™ and WINDOWS CE™ based handheld devices and both Microsoft EXCHANGE™ and Lotus NOTES™ e-mail systems for PCs. The first synchronization program is for synchronizing between PALM PILOT™ and EXCHANGE™, the second between PALM PILOT™ and Lotus NOTES™, the third between WINDOWS CE™ and EXCHANGE™, and the fourth between WINDOWS CE™ and Lotus NOTES™.
Another aspect of this straightforward design of the sync proxy is to allow the synchronization input/output interface between the synchronization proxy and a specific information management system hosting replicas of handheld data to be the same for different handheld devices. It is the sync proxy that handles the differences between handheld devices, not each replica host. The actual synchronization processes are conducted by the synchronization proxies. The role of both the handhelds and the replica hosts during synchronization is simply to respond to the synchronization input/output calls made by the synchronization proxy. These calls are typically in the form of adding, retrieving, deleting, and updating information. The computation burden and complexity of the synchronization logic for both handhelds and replica hosts therefore is much reduced.
One important feature of this straightforward sync proxy approach is that in order to properly synchronize between any applications for all device types and any information management systems for all replica hosts, a sync proxy must be able to invoke, during a synchronization task, a specific synchronization logic based on the target application, device, and the information management system. The current straightforward sync proxy approach accomplishes this by first restricting its support to a small number of applications, devices and information management systems to reduce the total number of synchronization logic variations required for proper synchronization; and by pre-configuring the synchronization logic as dynamically linkable (during synchronization runtime) codes stored in its disk memory. An important issue of such an approach is the difficulty in the management of all t
Huang Yun-Wu
Yu Philip Shi-lung
Coulter Kenneth R.
Dougherty Anne Vachon
Shofi David M.
LandOfFree
Method, apparatus and program storage device for a client... 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, apparatus and program storage device for a client..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method, apparatus and program storage device for a client... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2971307