US20010039629A1 - Synchronization process negotiation for computing devices - Google Patents
Synchronization process negotiation for computing devices Download PDFInfo
- Publication number
- US20010039629A1 US20010039629A1 US09/877,553 US87755301A US2001039629A1 US 20010039629 A1 US20010039629 A1 US 20010039629A1 US 87755301 A US87755301 A US 87755301A US 2001039629 A1 US2001039629 A1 US 2001039629A1
- Authority
- US
- United States
- Prior art keywords
- synchronization
- record
- data set
- value
- capabilities
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
Definitions
- the present invention relates generally to synchronization of data—that is, the process of taking two different stores of data (“data stores”), comparing them to identify differences, and applying changes to one or both to make them identical. More particularly, the present invention relates to a methodology for negotiating the synchronization process that is to occur among two or more computing devices, in a data-processing or computing environment.
- some devices e.g., PCs
- a server computer e.g., an Internet server which stores information for the user.
- the user would, of course, like the information on the server computer to participate in the synchronization so that the server also remains synchronized.
- Example 1 A synchronization or “sync” engine communicating with a fairly primitive device may have to obtain a complete copy of the data store from the device, do the comparison, and then re-write the entire data store back to the device.
- Example 2 The same sync engine, when communicating with a higher-level device, may be able to send a request to the other (target) device for all changes to the data store that were made after the last sync date. The target device will then transmit only those changes, reducing the amount of data that is transmitted and the time required for synchronization.
- Example 1 indicates a primitive synchronization process, where a synchronization engine must communicate with a primitive device (e.g., one not including any native support for synchronization). In such a case, the synchronization engine must follow a resource-intensive (and typically slow) process. First, the synchronization engine requests the entire data store from the device and then proceeds to determine what differences exist in the data store by comparing it to a previously-stored copy of the data store. After applying any necessary changes (i.e., for creating a data store that is synchronized according to user-specified configuration), the synchronization engine must now transmit the entire copy back to the primitive device.
- a primitive device e.g., one not including any native support for synchronization.
- the synchronization engine must follow a resource-intensive (and typically slow) process.
- the synchronization engine requests the entire data store from the device and then proceeds to determine what differences exist in the data store by comparing it to a previously-stored copy of the data store. After applying any necessary changes (i.
- the synchronization driver is tied to a specific device; it cannot be effectively re-used from one device to another.
- the device-specific driver soon becomes obsolete, since it does not support newer versions of the very same device for which it was specifically designed.
- the present invention provides a methodology for “synchronization process negotiation”—that is, negotiating between two or more devices exactly what synchronization process (protocol) is to be employed to effect synchronization of the devices.
- the methodology which is adaptable to existing synchronization protocols, takes into account the actual synchronization capabilities or built-in support (if any) of each device whose data is to be synchronized (e.g., by a synchronization engine).
- the present invention may be implemented by adapting a given synchronization protocol (which itself may be one of a variety of types) to include a “negotiation phase” at the beginning of the synchronization, during which the devices involved will exchange information about the capabilities of one or more devices. Once this negotiation phase has been completed, the synchronization can then proceed in a manner that is most efficient for the features available.
- the present invention itself is actually independent of any particular literal protocol, as it may be incorporated into a variety of different synchronization protocols, as well as different devices or different communication (message transport) layers. Therefore, the focus of the present convention is, instead, on the adaptation of a synchronization protocol to incorporate a basic mechanism for negotiating the synchronization process before synchronization begins, thereby governing how synchronization proceeds.
- the present invention operates by introducing the ability for a synchronization system's engine (sync engine) to query the client or target device about a particular attribute and to find out what the device's capabilities are in that respect.
- the individual attributes for a client are communicated as synchronization parameters, in attribute/value pair form.
- the present invention introduces a “RECORD_FILTERING” parameter, which may be communicated from the client back to the synchronization engine, to allow the synchronization engine to determine what the client's capabilities are with respect to filtering records from synchronization.
- the parameter may be set to one of the following values:
- Headers include a modification time (time stamp) for each record.
- CHANGE_TRACKING ⁇ NONE
- NONE indicates that the device or client has no ability to determine if something has changed in its data store.
- CRC indicates a CRC value for each record;
- TIMESTAMP indicates a modification time for each record; and
- CHANGE_COUNTER indicates a change count value for each record.
- Clients which cannot support a “SINCE_X” access method must either transmit their entire data store or transmit headers.
- the sync engine will need to request the desired records from the device. For example, if the synchronization engine has determined, based on a comparison of CRC values, that a particular record has changed, the synchronization engine needs a means to request that record from the device. Different devices will provide different levels of access and different types of access to their records, however. Therefore, a third parameter is required for specifying what type of access is provided.
- the device can only transmit and receive the entire data store as a block; it is not possible to request or submit individual records.
- the device provides “unique IDs” for each record, and the sync engine can request and submit individual records using these IDs. Unique IDs are guaranteed to be unique within a particular data store, and the association between a record and its ID is never broken.
- a methodology of the present invention for synchronizing a first data set residing on a first device with a second data set residing on a second device may be summarized as follows.
- a communication link is established between the two devices; this step may be performed in a conventional manner, such as connecting the two devices via a serial cable or via a local area network (LAN).
- LAN local area network
- the exchange of information about synchronization capabilities may be extended to be bilateral or mutual in nature (or multilateral, in the case of three or more devices), such that the second device also communicates its synchronization capabilities back to the first device.)
- a synchronization protocol may be selected for synchronizing the respective data sets of the two devices. Therefore, synchronization of the first and second data sets proceeds using the selected synchronization protocol, so that the synchronization process is performed in a manner optimized for the available synchronization capabilities (e.g., of the first device).
- FIG. 1A is a block diagram of a computer system in which the present invention may be embodied.
- FIG. 1B is a block diagram of a software system of the present invention for controlling operation of the computer system of FIG. 1A.
- FIGS. 2 A-E present flow charts illustrating the overall method steps employed for synchronization process negotiation.
- Data set synchronization may, for convenience of description, be divided into two types: content-oriented and record-oriented.
- Content-oriented synchronization correlates data set records based on the values of user-modifiable fields. Value correlation requires semantic (or at least advanced syntactic) processing that the human brain is very good at and computers are not. For example, a record in one data set with a name field valued “Johann S. Bach” and a record in a second data set with a name field valued “J. S. Bach” could possibly refer to the same real-world person. A human being might arrive at this conclusion by correlating associated data (addresses) or drawing upon external information (e.g., Bach is an unusual name in the U.S.). Creating program logic or code with the ability to make these types of decisions is computationally very expensive.
- Record-oriented synchronization correlates data set records by assuming that each record can be uniquely identified throughout its lifetime. This unique identifier is usually implemented as a non-modifiable, hidden field containing a “Record ID”. Record-oriented synchronization algorithms usually require maintaining a mapping from one set of record IDs to another. In a preferred embodiment, the system employs record-oriented synchronization.
- Record-oriented synchronization is conceptually simple and may be summarized as follows.
- a and B refer to two data sets which have a synchronization relationship.
- the rules are assumed to be symmetrical.
- a and B must track similar types of data (e.g., if A is an address book, then B must be an address book).
- a record modified in A will modify the corresponding record in B.
- the actual synchronization logic in synchronization systems often needs to make processing decisions based on comparing the time at which past events occurred. For example, it is necessary to know if a record was modified before or after the last synchronization transaction. This requires recording the time of various events.
- a “time stamp” value may be employed for this purpose.
- data sets involved in synchronization support time stamps, or can be supplied with suitable time stamps, in a conventional manner. In conjunction with the usage of time stamps to compare the relative timing of record creation or modification, the clocks on the respective devices may themselves be synchronized.
- a synchronization system will typically transform records from one application-usage-schema set to another application-usage-schema set, such as transforming from a Starfish Sidekick® card file for business contacts to a corresponding PalmPilotTM data set.
- another application-usage-schema set such as transforming from a Starfish Sidekick® card file for business contacts to a corresponding PalmPilotTM data set.
- there is a one-to-one relationship between records in these two data sets that is, between the source and target data sets. If this is not the case, however, the component of the system that interacts with a non-conforming data set may include logic to handle this non-conformance.
- the record transformations themselves are a combination of field mappings and conversions from a source record to a target record.
- Exemplary types of field mappings include, for instance, the following:
- Null Source field has no equivalent field in the target data set and is ignored during synchronization.
- One-to-Many Map one field in the target data set to many fields in the source data set, such as parse a single address line to fields for number, direction, street, suite/apartment, or the like.
- exemplary field conversions may be defined as follows:
- Size Source field may be larger or smaller in size than the target field.
- Type Data types may be different, such as float/integer, character vs. numeric dates, or the like.
- a field's values may be limited to a known set. These sets may be different from target to source and may be user defined.
- the methodology of the present invention for negotiating a particular synchronization process is largely independent of any given synchronization process or synchronization engine. Instead, the methodology of the present invention operates to allow devices participating in a synchronization process to select a specific type of process (or synchronization path of execution for a given synchronization engine), based on the capabilities of one or more of the participating devices.
- the present invention may be embodied on an information processing system such as the system 100 of FIG. 1A, which comprises a central processor 101 , a main memory 102 , an input/output (I/O) controller 103 , a keyboard 104 , a pointing device 105 (e.g., mouse, pen device, or the like), a screen or display device 106 , a mass storage 107 (e.g., hard disk, removable floppy disk, optical disk, magneto-optical disk, flash memory, or the like), one or more optional output device(s) 108 , and an interface 109 .
- a real-time system clock is included with the system 100 , in a conventional manner.
- the various components of the system 100 communicate through a system bus 110 or similar architecture.
- the system 100 may communicate with other devices through the interface or communication port 109 , which may be an RS- 232 serial port or the like.
- Devices which will be commonly connected to the interface 109 include a network 151 (e.g., LANs or the Internet), a laptop 152 , a handheld organizer 154 (e.g., the REXTM organizer, available from Franklin Electronic Publishers of Burlington, N.J.), a modem 153 , or the like.
- a network 151 e.g., LANs or the Internet
- a laptop 152 e.g., a laptop 152
- a handheld organizer 154 e.g., the REXTM organizer, available from Franklin Electronic Publishers of Burlington, N.J.
- modem 153 e.g., the like.
- program logic (implementing the methodology described below) is loaded from the storage device or mass storage 107 into the main memory 102 , for execution by the processor 101 .
- the user enters commands through the keyboard 104 and/or pointing device 105 , which is typically a mouse, a track ball, or the like.
- the computer system displays text and/or graphic images and other data on the display device 106 , such as a cathode-ray tube or an LCD display.
- a hard copy of the displayed information, or other information within the system 100 may be obtained from the output device 108 (e.g., a printer).
- the computer system 100 includes an IBM PC-compatible personal computer (available from a variety of vendors, including IBM of Armonk, N.Y.) running Windows 9x or Windows NT (available from Microsoft Corporation of Redmond, Wash.).
- the system 100 is an Internet, intranet, or other type of network server and receives input from, and sends output to, a remote user via the interface 109 according to standard techniques and protocols.
- a computer software system 120 is provided for directing the operation of the computer system 100 .
- Software system 120 which is stored in system memory 102 and on storage 107 (e.g., disk memory), includes a kernel or operating system (OS) 140 and a windows shell 150 .
- OS operating system
- One or more application programs 145 such as client application software or “programs” may be “loaded” (i.e., transferred from storage 107 into memory 102 ) for execution by the system 100 .
- System 120 includes a user interface (UI) 160 , preferably a Graphical User Interface (GUI), for receiving user commands and data and for producing output to the user. These inputs, in turn, may be acted upon by the system 100 in accordance with instructions from operating system module 140 , windows module 150 , and/or client application module(s) 145 .
- the UI 160 also serves to display the user prompts and results of operation from the OS 140 , windows 150 , and application(s) 145 , whereupon the user may supply additional inputs or terminate the session.
- OS 140 and windows 150 together comprise Microsoft Windows software (e.g., Windows 9x or Windows NT).
- Windows 9x or Windows NT Microsoft Windows software
- the methodology of the present invention may be embodied on a single device for synchronizing or reconciling multiple data sets present on that device, the present invention will instead typically be embodied in an environment including two or more computing or information-storing devices, which are occasionally or continually connected.
- a client e.g., hand-held or portable “organizer” device 154 , laptop computer 152 , or the like
- a synchronization engine residing on a “host” or “server” computer (e.g., computer system 100 ).
- the synchronization engine itself is constructed to effect reconciliation or synchronization among two or more data sets, according to user-specified conditions or criteria.
- a synchronization engine see e.g., commonly-owned application Ser. No. 09/136,212, filed Aug. 18, 1998, the disclosure of which has previously been incorporated by reference.
- the present invention is not limited to any particular synchronization engine or hardware configuration but, instead, may be advantageously employed in any environment requiring and capable of supporting synchronization of two or more data stores.
- the laptop computer 152 may serve as the “server” with both the computer system 100 and the organizer device 154 serving as “clients.”
- clients which device functions as a “client” (or multiple devices functioning as “clients”) and which device functions as a “server,” is largely an arbitrary choice.
- the use of “client” and “server” distinctions is in fact not even applicable. Therefore, although the distinction of a particular device being a “client” and another device being a “server” is useful as a framework for presenting exemplary synchronization scenarios for application of the present invention, the present invention itself actually requires no such distinction.
- the means for communication may be one of a variety of communication means, including serial link (e.g., RS 232 wired link), parallel link, infrared link, wireless (cellular) link, or the like.
- serial link e.g., RS 232 wired link
- parallel link e.g., parallel link
- infrared link e.g., infrared link
- wireless (cellular) link e.g., wireless (cellular) link
- the present invention is independent of communication means, so long as synchronization messages can eventually be transmitted and received, whether in a synchronous or asynchronous manner. Instead, what is required is an interface to the underlying synchronization protocol (whatever that protocol may be), so that there exists some means of initiating a synchronization session which is adapted to include a negotiation phase of the present invention, as described below.
- the interface would be implemented in program code existing at the target device and complementary program code existing at the synchronization engine, so that the two may exchange messages or commands (including parameter information) in the format specified by the particular synchronization protocol.
- the synchronization protocol should, however, at least allow the exchange of attribute information, so that synchronization attributes of the target device may be communicated to the synchronization engine.
- the present invention introduces into a given synchronization protocol (which itself may be one of a variety of types) a “negotiation phase” at the beginning of the synchronization, during which the devices involved will exchange information about the capabilities of one or more devices.
- the capabilities of the client device are the limiting factor for synchronization, so that the negotiation phase may proceed by only including enumeration of the client's capabilities.
- the synchronization can then proceed in a manner that is most efficient for the features that are available.
- the present invention itself is actually independent of any particular literal protocol, as it may be incorporated into a variety of different synchronization protocols, as well as different devices or different communication (message transport) layers. Therefore, the focus of the present convention is, instead, on the adaptation of a synchronization protocol to incorporate a basic mechanism for negotiating the synchronization process before synchronization begins, thereby governing how synchronization proceeds.
- step 1 three different ways exist that a sync engine can figure out what has changed on the client:
- Sync Anchor refers to a value, such as a time stamp or a change counter (e.g., value incremented each time a record is changed), that allows one to determine whether a record has changed since a particular point in time, usually since last synchronization. This is a value which is associated with a particular record and is changed whenever the record is changed. The sync engine can then compare this value to a previously stored value to detect that changes have been made.
- the present invention introduces the ability for the synchronization engine to query the client or target device about a particular attribute, to find out what the device's capabilities are in that respect.
- the approach is adaptable to a variety of different synchronization engines, including for example the synchronization engine described by application Ser. No. 09/136,212).
- the present invention introduces a “RECORD_FILTERING” parameter, to allow the synchronization engine to determine what the client's capabilities are with respect to these three processes (i.e., with respect to filtering records from synchronization).
- the parameter may be set to one of the following values:
- NONE indicates that the client does not provide any record filtering functionality (i.e., process #1 above); the client can only give the entire data store.
- HEADERS indicates that the client can provide record headers (i.e., process #2 above).
- the client cannot pick out what has changed, but it can provide a snapshot summary that is smaller than all of the data (from which the synchronization engine can then determine changes).
- SINCE_X indicates that the client can provide records as of a particular “Sync Anchor” value, where X indicates a time stamp or change counter value.
- the client is capable of providing records which have changed from a particular value (e.g., time stamp value for a particular date and time) given by the synchronization engine.
- Headers include a CRC (cyclic redundancy checking) value for each record.
- Headers include a modification time (time stamp) for each record.
- Headers include a change counter for each record.
- CHANGE_TRACKING indicates what the device's capabilities are in terms of knowing what has changed. This parameter may be set to one of the following values:
- CHANGE_TRACKING ⁇ NONE
- NONE indicates that the device or client has no ability to determine if something has changed in its data store.
- CRC indicates a CRC value for each record;
- TIMESTAMP indicates a modification time for each record; and
- CHANGE_COUNTER indicates a change count value for each record.
- Clients which cannot support a “SINCE_X” access method must either transmit their entire data store or transmit headers.
- the sync engine will need to request the desired records from the device. For example, if the synchronization engine has determined, based on comparison of CRC values that a particular record has changed, the synchronization engine needs a means in order to request that record from the device. Different devices will provide different levels of access and different types of access to their records, however. Therefore, a third parameter is required for specifying what type of access is provided.
- the types of record access that devices can support include the following:
- the device can only transmit and receive the entire data store as a block; it is not possible to request or submit individual records.
- the device provides “static index” access to the records (i.e., there are a fixed number of record storage “slots”, and the sync engine can request and submit records based on this slot number.
- the records may move to different slots in between synchronizations, so there is no lasting fixed correlation between a slot number and a record).
- the device provides “unique IDs” for each record, and the sync engine can request and submit individual records using these IDs. Unique IDs are guaranteed to be unique within a particular data store, and the association between a record and its ID is never broken.
- BLOCK record access indicates that the device can only give access to the entire set or “block” of records (i.e., the entire data store); this is the most primitive type of record access.
- STATIC record access indicates a static index mechanism. For example, a Motorola StarTac® phone provides 99 slots for storing phone numbers. A synchronization engine can request, for instance, the contents of slot #5. There is, however, no association between the slot number and the value stored (i.e., record contents), and in fact the phone can shuffle the records around at its discretion.
- UNIQUE indicates that each record within the data store is represented by a unique ID, within the scope or context of that particular data store. Here, the relationship between the unique identifier and the record is fixed or permanent. This level of record access allows the synchronization engine to get and put an individual record, based on the ID.
- the synchronization engine can use the parameters to control the synchronization process and to pick a synchronization process that is optimized for a particular target device.
- the sync engine is able to query the device for its synchronization capabilities using these three basic parameters, therefore, it becomes possible for the sync engine to proceed with a method of synchronization that is appropriate to the capabilities of the device. This is perhaps best illustrated by way of example, using the following for synchronization processes.
- CHANGE_TRACKING CRC
- This synchronization session demonstrates exchange (e.g., synchronization protocol-based dialog) in which the target device is capable of knowing which records to send to the server, based on the last sync time communicated during login.
- the server performs synchronization (including, conflict resolution) after receiving all client changes.
- the server may be configured to perform synchronization or at least some degree of conflict resolution upon receipt of each client record (i.e., process does not wait until receipt of all client records before commencing).
- FIGS. 2 A-E present flow charts illustrating the overall method steps employed for synchronization process negotiation.
- the respective devices establish a communication link (i.e., establish communication link between target device(s), client(s), and synchronization engine).
- the devices exchange acknowledgments for initiating synchronization protocol.
- the devices begin synchronization negotiation by eliciting the synchronization capabilities of the target device(s). This occurs, for instance, by transmitting a request from the synchronization engine to the client for synchronization parameters or attributes of the client.
- the client transmits synchronization parameters indicating the client's capabilities.
- such parameters or attributes include: (1) whether records are filtered (RECORD_FILTER parameter), (2) what type of change tracking (e.g., time stamp or change value) is provided at the client (CHANGE_TRACKING parameter), and (3) what level of record access is afforded by the client (RECORD_ACCESS parameter). Based on the transmitted parameter values, the synchronization engine will select an optimal synchronization process or strategy.
- processing at this point depends on the actual values set in the parameters. In other words, how the synchronization process proceeds from this point on depends, at least in part, on the synchronization capabilities (if any) of the client: a synchronization protocol is selected that allows optimization of the synchronization process, based on client capabilities.
- the processing logic applied by the method at this point is summarized by step 205 . In the event that record filtering is set to “none”, change tracking is set to “none”, and record access is set to “block”, the method proceeds to steps to 211 - 213 (case instance or condition A).
- the synchronization engine obtains the complete data store (step 211 ), performs synchronization locally (step 212 ), and then replaces the entire data store (step 213 ), as shown in FIG. 2B.
- record filtering is set to “none”
- change tracking is set to “none”
- record access is set to “static” or “unique”
- the method proceeds to steps to 221 - 223 (case condition B).
- the synchronization engine obtains the complete data store (step 221 ), performs synchronization locally (step 222 ), but then only replaces the affected records (step 223 ), as shown in FIG. 2C.
- the method proceeds to steps to 231 - 234 (case condition C).
- the synchronization engine obtains a summary of all records which includes per record change-tracking information (step 231 ), fetches only the changed records (step 232 ), performs synchronization locally (step 233 ), and then replaces only the affected records (step 234 ), as shown in FIG. 2D.
- step 241 the synchronization engine requests only the changed records from the target device (step 241 ), performs synchronization locally (step 242 ), and then only replaces the affected records (step 243 ), as shown in FIG. 2E. After conclusion of the proper case condition invocation, the method is done.
- the synchronization engine proceeds with synchronization in a manner selected to optimize the process, based on the capabilities of the particular target device participating in synchronization.
- the ability of the client to facilitate the process is utilized based on the recognition by the synchronization engine that the client is able to assist in the process.
- the synchronization engine adapts to the capabilities of each individual client, even though each client itself may have a degree of support for synchronization that is quite different than that of other clients. In effect, both the client and the synchronization engine “negotiate” as to the best synchronization process to use. Synchronization then proceeds based on the negotiated or agreed-upon synchronization protocol (which itself can be any one of a number of synchronization protocols).
- the present invention allows a sync engine to effect synchronization among a variety of different devices in a manner that is optimal for the capabilities of each particular device. In this fashion, the amount of traffic (information) over the communication link may be minimized. This is particularly important in configurations having slow communication links (e.g., serial cable link) and/or large amounts of data. Additionally, the amount of work which the synchronization engine must do is minimized. All told, the present invention solves the previously-described problem that exists with these present-day approaches employing a “hard-wired” protocol approach: a synchronization protocol may be negotiated between or among an arbitrary set of devices, such that an optimal synchronization protocol is selected for those devices.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A methodology providing “synchronization process negotiation” is described. Synchronization process negotiation is the methodology of negotiating between two or more devices exactly what synchronization process (protocol) is to be employed to effect synchronization of the devices. The methodology, which is adaptable to existing synchronization protocols, takes into account the actual synchronization capabilities or built-in support (if any) of each device whose data is to be synchronized (e.g., by a synchronization engine). The methodology may be implemented by adapting a given synchronization protocol (which itself may be one of a variety of types) to include a “negotiation phase” at the beginning of the synchronization, during which the devices involved will exchange information about the capabilities of one or more devices. The individual attributes for a client are communicated as synchronization parameters in attribute/value pair form. Once this negotiation phase has been completed, the synchronization can then proceed in a manner that is most efficient for the features available.
Description
- The present application claims the benefit of priority from and is related to the following commonly-owned U.S. provisional application: application Ser. No. 60/122,592, filed Mar. 3, 1999. The disclosure of the foregoing application is hereby incorporated by reference in its entirety, including any appendices or attachments thereof, for all purposes. The present application is also related to the following commonly-owned U.S. patent applications, the disclosures of which are hereby incorporated by reference in their entirety, including any appendices or attachments thereof, for all purposes: application Ser. No. 09/020,047, filed Feb. 6, 1998, and entitled Methods for Mapping Data Fields from One Dataset to Another in a Data Processing Environment; application Ser. No. 09/136,215, filed Aug. 18, 1998, and entitled System and Methods for Synchronzng Two or More Data Sets; application Ser. No. 09/136,212, filed Aug. 18, 1998, and entitled Data Processing Environment with Methods Providing Contemporaneous Synchronization of Two or More Clients; and application Ser. No. 08/923,612, filed Sep. 4, 1997, and entitled System and Methods for Synchronzng Information Among disparate datasets.
- A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
- The present invention relates generally to synchronization of data—that is, the process of taking two different stores of data (“data stores”), comparing them to identify differences, and applying changes to one or both to make them identical. More particularly, the present invention relates to a methodology for negotiating the synchronization process that is to occur among two or more computing devices, in a data-processing or computing environment.
- With each passing day, there is ever increasing interest in providing synchronization solutions for connected computing devices, particularly information appliances. These “appliances” appear in the form of electronic devices including, but not limited to, cellular phones, pagers, other hand-held devices (e.g., REX™, PalmPilot™ and Windows™ CE devices), personal computers (PCs) of all types and sizes, and Internet or intranet access devices (e.g., PCs or embedded computers running, for example, Java virtual machines or browsers or Internet Protocol (IP) handlers).
- These devices, and the software applications running on these devices, do not communicate particularly well with one another and are typically not designed with data synchronization in mind. Therefore, a problem exists as to how one integrates information—such as calendaring, scheduling, and contact information—among disparate devices and software applications. Consider, for instance, a user who has his or her appointments on a desktop PC at work, but also has a notebook computer at home, and a battery-powered, hand-held device for use in the field. What the user really wants is for the information (e.g., appointments) in each device to remain synchronized with corresponding information in all devices in a convenient and transparent manner. Still further, some devices (e.g., PCs) are typically connected at least occasionally to a server computer (e.g., an Internet server which stores information for the user). The user would, of course, like the information on the server computer to participate in the synchronization so that the server also remains synchronized.
- An early approach to maintaining consistency between data sets was to import or copy one data set on top of another. This simple “one-way” approach, which overwrites a target data set without any attempt at reconciling any differences, is inadequate for all but the simplest of applications. Not unexpectedly, more sophisticated synchronization techniques were developed. In particular, techniques were developed for synchronization of exactly two data sets by attempting to reproduce in each data set the changes found in the other data set since a previous synchronization. A detailed review of different synchronization techniques can be found in the Background section of commonly-owned application Ser. No. 08/923,612, filed Sep. 4, 1997, and entitled System and Methods for Synchronizing Information Among Disparate Datasets, the disclosure of which is hereby incorporated by reference in its entirety, including any appendices or attachments thereof, for all purposes.
- Today, a variety of approaches exist for synchronizing information residing on multiple computing or information-storing devices. Consider, for instance, the task of synchronizing respective data sets or “data stores” residing on a given pair of devices. Here, the particular synchronization process employed depends on the capabilities of the individual devices. Consider, for instance, the following two examples:
- Example 1: A synchronization or “sync” engine communicating with a fairly primitive device may have to obtain a complete copy of the data store from the device, do the comparison, and then re-write the entire data store back to the device.
- Example 2: The same sync engine, when communicating with a higher-level device, may be able to send a request to the other (target) device for all changes to the data store that were made after the last sync date. The target device will then transmit only those changes, reducing the amount of data that is transmitted and the time required for synchronization.
- Each example will be reviewed in turn.
- Example 1 indicates a primitive synchronization process, where a synchronization engine must communicate with a primitive device (e.g., one not including any native support for synchronization). In such a case, the synchronization engine must follow a resource-intensive (and typically slow) process. First, the synchronization engine requests the entire data store from the device and then proceeds to determine what differences exist in the data store by comparing it to a previously-stored copy of the data store. After applying any necessary changes (i.e., for creating a data store that is synchronized according to user-specified configuration), the synchronization engine must now transmit the entire copy back to the primitive device.
- Example 2 indicates a higher-level synchronization process, in which the synchronization engine communicates with a device having at least some degree of support for synchronization. Support might include, for example, the ability of the device to transmit to the synchronization engine any new or modified records as of a certain date. Typically, the level of synchronization support is due in part to what is stored in the data store, the type of program functionality (i.e., software features) that is available, and the processing power that is available for the synchronization interface (to that device). Beyond the disparate levels of synchronization illustrated by the preceding examples, a variety of other possible levels exist, each one taking advantage of the features of a particular device to get the most efficient synchronization possible.
- A problem exists with these present-day approaches, however. In order for two devices to synchronize together (i.e., participate in a synchronization session), they have to have some means of communication—that is, a “synchronization protocol”. With existing solutions, however, a “hard-wired” protocol (i.e., one supporting only a particular device, such as a Palm Pilot device) is employed. As a result, the protocol employed is specific to the needs and features of a particular device, at the expense of not supporting other devices. From the perspective of the software developer, one creates a device-specific “accessor” (i.e., driver capable of accessing data) for a particular target device, with the requirement that the developer knows the particular synchronization capabilities of the target device beforehand. The problem with such an approach, however, is that the synchronization driver is tied to a specific device; it cannot be effectively re-used from one device to another. As the target device itself typically undergoes revision, the device-specific driver soon becomes obsolete, since it does not support newer versions of the very same device for which it was specifically designed.
- Recently, some attempts have been made to create generalized synchronization protocols. However, instead of handling a variety of different device synchronization-support levels, these protocols assume some particular level of synchronization support, and only devices capable of that level of support can be synchronized. Here, such a protocol attempts to provide some degree of reuse by adopting a common denominator for target devices using that protocol. This approach is also problematic. Quite simply, if a device does not meet the common denominator, it is completely shut out from use of the protocol, despite the fact that the device may actually include some degree of built-in synchronization support (which could have been used to optimize synchronization). In other words, the approach has no capability to support those devices which, although not adhering completely to the specified protocol, have at least some intermediate level of synchronization support. Therefore, the approach is only an incremental improvement over the above-described single-device protocol.
- What is needed are systems and methods that support a generalized synchronization protocol, yet do so in a manner which is adaptable to the capabilities of a particular target device. In such a case, the target device is not required to have a particular degree of synchronization support in order to use the protocol. Instead, the protocol allows the synchronization process to proceed in the most efficient manner possible, given the level of synchronization support provided by the target device, whatever level that might be. The present invention fulfills this and other needs.
- The present invention provides a methodology for “synchronization process negotiation”—that is, negotiating between two or more devices exactly what synchronization process (protocol) is to be employed to effect synchronization of the devices. The methodology, which is adaptable to existing synchronization protocols, takes into account the actual synchronization capabilities or built-in support (if any) of each device whose data is to be synchronized (e.g., by a synchronization engine).
- More particularly, the present invention may be implemented by adapting a given synchronization protocol (which itself may be one of a variety of types) to include a “negotiation phase” at the beginning of the synchronization, during which the devices involved will exchange information about the capabilities of one or more devices. Once this negotiation phase has been completed, the synchronization can then proceed in a manner that is most efficient for the features available. The present invention itself is actually independent of any particular literal protocol, as it may be incorporated into a variety of different synchronization protocols, as well as different devices or different communication (message transport) layers. Therefore, the focus of the present convention is, instead, on the adaptation of a synchronization protocol to incorporate a basic mechanism for negotiating the synchronization process before synchronization begins, thereby governing how synchronization proceeds.
- In internal system operation, the present invention operates by introducing the ability for a synchronization system's engine (sync engine) to query the client or target device about a particular attribute and to find out what the device's capabilities are in that respect. The individual attributes for a client are communicated as synchronization parameters, in attribute/value pair form. For example, the present invention introduces a “RECORD_FILTERING” parameter, which may be communicated from the client back to the synchronization engine, to allow the synchronization engine to determine what the client's capabilities are with respect to filtering records from synchronization. The parameter may be set to one of the following values:
- RECORD_FILTERING={NONE|HEADERS|SINCE_X}
- NONE indicates that the client does not provide any record filtering functionality (i.e., similarly to Example 1 above); the client can only give the entire data store. HEADERS indicates that the client can provide record headers. Here, the client cannot pick out what has changed, but it can provide a snapshot summary that is smaller than all of the data (from which the synchronization engine can then determine changes). SINCE_X indicates that the client can provide records as of a particular “Sync Anchor” value, where X indicates a time stamp or change counter value (i.e., similarly to Example 2 above). Here, the client is capable of giving records which have changed from a particular value (e.g., time stamp value for a particular date and time) given by the synchronization engine.
- In the event that the client can provide headers, the sync engine needs to know what sort of information to expect in those headers in order to perform synchronization. Possibilities include the following:
- 1. Headers include a CRC (cyclic redundancy checking) value for each record.
- 2. Headers include a modification time (time stamp) for each record.
- 3. Headers include a change counter for each record.
- These three options are reflected in a “CHANGE_TRACKING” parameter, which indicates what the device's capabilities are in terms of knowing what has changed. This parameter may be set to one of the following values:
- CHANGE_TRACKING={NONE|CRC|TIMESTAMP|CHANGE_COUNTER}
- NONE indicates that the device or client has no ability to determine if something has changed in its data store. CRC indicates a CRC value for each record; TIMESTAMP indicates a modification time for each record; and CHANGE_COUNTER indicates a change count value for each record.
- Clients which cannot support a “SINCE_X” access method must either transmit their entire data store or transmit headers. For such clients, the sync engine will need to request the desired records from the device. For example, if the synchronization engine has determined, based on a comparison of CRC values, that a particular record has changed, the synchronization engine needs a means to request that record from the device. Different devices will provide different levels of access and different types of access to their records, however. Therefore, a third parameter is required for specifying what type of access is provided.
- The types of record access that devices can support include the following:
- 1. The device can only transmit and receive the entire data store as a block; it is not possible to request or submit individual records.
- 2. The device provides “static index” access to the records (i.e., there are a fixed number of record storage “slots”, and the sync engine can request and submit records based on this slot number. The records may move to different slots in between synchronizations, so there is no lasting fixed correlation between a slot number and a record).
- 3. The device provides “unique IDs” for each record, and the sync engine can request and submit individual records using these IDs. Unique IDs are guaranteed to be unique within a particular data store, and the association between a record and its ID is never broken.
- These three options are reflected in a “RECORD_ACCESS” parameter, which may take one of the following values:
- RECORD_ACCESS={BLOCK|STATIC|UNIQUE}
- BLOCK record access indicates that the device can only give access to the entire set or “block” of records (i.e., the entire data store); this is the most primitive type of record access. STATIC record access indicates a static index mechanism. UNIQUE indicates that each record within the data store is represented by a unique ID, within the scope or context of that particular data store (or, if desired, globally unique). Here, the relationship between the unique identifier and the record is fixed or permanent. This level of record access allows the synchronization engine to get and put an individual record, based on the ID.
- A methodology of the present invention for synchronizing a first data set residing on a first device with a second data set residing on a second device may be summarized as follows. At the outset, a communication link is established between the two devices; this step may be performed in a conventional manner, such as connecting the two devices via a serial cable or via a local area network (LAN). This allows the second device to query the synchronization capabilities of the first device, by transmitting a request to the first device for the specific synchronization capabilities of the first device. In response to this request, the first device transmits back to the second device information indicating the specific synchronization capabilities of the first device. (If desired, the exchange of information about synchronization capabilities may be extended to be bilateral or mutual in nature (or multilateral, in the case of three or more devices), such that the second device also communicates its synchronization capabilities back to the first device.) Now, based on the given synchronization capabilities of the first device, a synchronization protocol may be selected for synchronizing the respective data sets of the two devices. Therefore, synchronization of the first and second data sets proceeds using the selected synchronization protocol, so that the synchronization process is performed in a manner optimized for the available synchronization capabilities (e.g., of the first device).
- FIG. 1A is a block diagram of a computer system in which the present invention may be embodied.
- FIG. 1B is a block diagram of a software system of the present invention for controlling operation of the computer system of FIG. 1A.
- FIGS.2A-E present flow charts illustrating the overall method steps employed for synchronization process negotiation.
- The following description will focus on the presently-preferred embodiment of the present invention, which is operative in an environment typically including a variety of computing or information-storing devices (e.g., desktop computers, server computers, and portable computing devices), that are occasionally or permanently connected to one another where synchronization support is desired. For purposes of discussion, the following description will present examples in which it will be assumed that there exists a “server” or “synchronization (“sync”) engine” which has one data store locally, and a “client’ or remote device which has a second data store to be synchronized. The present invention, however, is not limited to any particular environment or device. In particular, a client/server distinction is neither necessary to the invention nor even necessarily desirable, but is used to provide a framework for discussion. The focus of the following description, therefore, is not focused on a particular synchronization/hardware configuration (as the present invention may be advantageously applied to a variety of disparate configurations). Instead, the following description will focus on the application of synchronization negotiation or dialog among two or more devices, which may be configured in a variety of hardware configurations (e.g., according to the particular needs of the user). Therefore, the following description is for the purposes of illustration and not limitation.
- Brief Overview of Synchronization
- A. Introduction
- Many software applications, such as personal productivity applications like Starfish Sidekick® and Lotus® Organizer, have sets of data or “data sets” (e.g., address books and calendars). Consider, for instance, a user scenario where an account executive needs to coordinate contacts and events with other employees of the XYZ corporation. When traveling, the executive carries a laptop PC with Starfish Sidekick® installed. At home, she and her husband use Lotus® Organizer to plan their family's activities. When on family outings, the account executive carries her PalmPilot™ hand-held organizer. As the foregoing illustrates, a user often needs a means for synchronizing selected information from the data sets his or her applications rely upon. The account executive would not want to schedule a business meeting at the same time as a family event, for example.
- Conventionally, the process of synchronizing or reconciling data sets has been a binary process—that is, two logical data sets are synchronized at a time. Any arbitrary synchronization topology will be supported. Here, the system guarantees synchronization stability and the avoidance of undesirable side effects (cascading updates, record duplication, or the like). Data sets do not need to be directly connected but, instead, can be connected via a “store-and-forward” transport, such as electronic mail.
- B. Synchronization design
- 1. Synchronization Type
- Data set synchronization may, for convenience of description, be divided into two types: content-oriented and record-oriented. Content-oriented synchronization correlates data set records based on the values of user-modifiable fields. Value correlation requires semantic (or at least advanced syntactic) processing that the human brain is very good at and computers are not. For example, a record in one data set with a name field valued “Johann S. Bach” and a record in a second data set with a name field valued “J. S. Bach” could possibly refer to the same real-world person. A human being might arrive at this conclusion by correlating associated data (addresses) or drawing upon external information (e.g., Bach is an unusual name in the U.S.). Creating program logic or code with the ability to make these types of decisions is computationally very expensive.
- Record-oriented synchronization correlates data set records by assuming that each record can be uniquely identified throughout its lifetime. This unique identifier is usually implemented as a non-modifiable, hidden field containing a “Record ID”. Record-oriented synchronization algorithms usually require maintaining a mapping from one set of record IDs to another. In a preferred embodiment, the system employs record-oriented synchronization.
- Record-oriented synchronization is conceptually simple and may be summarized as follows. In the rules below, A and B refer to two data sets which have a synchronization relationship. The rules are assumed to be symmetrical.
- 1. A and B must track similar types of data (e.g., if A is an address book, then B must be an address book).
- 2. A record created in A, will create a record in B.
- 3. A record modified in A, will modify the corresponding record in B.
- 4. If record A1 has been modified in A and the corresponding record B1 has been modified in B, the record with the latest time stamp (also, “timestamp”) takes precedence.
- The rules presented above reduce the occurrence of undesirable side effects with a network of synchronized data sets.
- 2. Time Stamps
- The actual synchronization logic in synchronization systems often needs to make processing decisions based on comparing the time at which past events occurred. For example, it is necessary to know if a record was modified before or after the last synchronization transaction. This requires recording the time of various events. A “time stamp” value may be employed for this purpose. Typically, data sets involved in synchronization support time stamps, or can be supplied with suitable time stamps, in a conventional manner. In conjunction with the usage of time stamps to compare the relative timing of record creation or modification, the clocks on the respective devices may themselves be synchronized.
- 3. Record Transformations
- During synchronization, a synchronization system will typically transform records from one application-usage-schema set to another application-usage-schema set, such as transforming from a Starfish Sidekick® card file for business contacts to a corresponding PalmPilot™ data set. Typically, there is a one-to-one relationship between records in these two data sets, that is, between the source and target data sets. If this is not the case, however, the component of the system that interacts with a non-conforming data set may include logic to handle this non-conformance.
- The record transformations themselves are a combination of field mappings and conversions from a source record to a target record. Exemplary types of field mappings include, for instance, the following:
- 1. Null Source field has no equivalent field in the target data set and is ignored during synchronization.
- 2. One-to-One Map exactly one field in the target data set to one field in the source data set.
- 3. One-to-Many Map one field in the target data set to many fields in the source data set, such as parse a single address line to fields for number, direction, street, suite/apartment, or the like.
- 4. Many-to-One Map several fields in the target data set to one field in the source data set, such as reverse the address line mapping above.
- Similarly, exemplary field conversions may be defined as follows:
- 1. Size Source field may be larger or smaller in size than the target field.
- 2. Type Data types may be different, such as float/integer, character vs. numeric dates, or the like.
- 3. Discrete Values A field's values may be limited to a known set. These sets may be different from target to source and may be user defined.
- It is often the case that there are significant differences in the number, size, type, and usage of fields between two data sets in a synchronization relationship. The specification of transformations is typically user-configurable, with the underlying system providing defaults.
- With an understanding of the basic process of synchronizing information or computing devices, the reader may now better appreciate the teachings of the present invention for providing improved synchronization methodology for synchronizing an arbitrary number of devices (i.e., synchronization clients), as described in further detail below. As will be noted in further detail below, however, the methodology of the present invention for negotiating a particular synchronization process is largely independent of any given synchronization process or synchronization engine. Instead, the methodology of the present invention operates to allow devices participating in a synchronization process to select a specific type of process (or synchronization path of execution for a given synchronization engine), based on the capabilities of one or more of the participating devices.
- This allows the synchronization process to be optimized based on the built-in synchronization support of the participating devices.
- System Hardware and Software
- The present invention may be embodied on an information processing system such as the
system 100 of FIG. 1A, which comprises acentral processor 101, amain memory 102, an input/output (I/O)controller 103, akeyboard 104, a pointing device 105 (e.g., mouse, pen device, or the like), a screen ordisplay device 106, a mass storage 107 (e.g., hard disk, removable floppy disk, optical disk, magneto-optical disk, flash memory, or the like), one or more optional output device(s) 108, and aninterface 109. Although not shown separately, a real-time system clock is included with thesystem 100, in a conventional manner. The various components of thesystem 100 communicate through asystem bus 110 or similar architecture. In addition, thesystem 100 may communicate with other devices through the interface orcommunication port 109, which may be an RS-232 serial port or the like. - Devices which will be commonly connected to the
interface 109 include a network 151 (e.g., LANs or the Internet), alaptop 152, a handheld organizer 154 (e.g., the REXTM organizer, available from Franklin Electronic Publishers of Burlington, N.J.), amodem 153, or the like. - In operation, program logic (implementing the methodology described below) is loaded from the storage device or
mass storage 107 into themain memory 102, for execution by theprocessor 101. During operation of the program (logic), the user enters commands through thekeyboard 104 and/orpointing device 105, which is typically a mouse, a track ball, or the like. The computer system displays text and/or graphic images and other data on thedisplay device 106, such as a cathode-ray tube or an LCD display. A hard copy of the displayed information, or other information within thesystem 100, may be obtained from the output device 108 (e.g., a printer). In a preferred embodiment, thecomputer system 100 includes an IBM PC-compatible personal computer (available from a variety of vendors, including IBM of Armonk, N.Y.) running Windows 9x or Windows NT (available from Microsoft Corporation of Redmond, Wash.). In a specific embodiment, thesystem 100 is an Internet, intranet, or other type of network server and receives input from, and sends output to, a remote user via theinterface 109 according to standard techniques and protocols. - Illustrated in FIG. 1B, a
computer software system 120 is provided for directing the operation of thecomputer system 100.Software system 120, which is stored insystem memory 102 and on storage 107 (e.g., disk memory), includes a kernel or operating system (OS) 140 and awindows shell 150. One ormore application programs 145, such as client application software or “programs” may be “loaded” (i.e., transferred fromstorage 107 into memory 102) for execution by thesystem 100. -
System 120 includes a user interface (UI) 160, preferably a Graphical User Interface (GUI), for receiving user commands and data and for producing output to the user. These inputs, in turn, may be acted upon by thesystem 100 in accordance with instructions fromoperating system module 140,windows module 150, and/or client application module(s) 145. TheUI 160 also serves to display the user prompts and results of operation from theOS 140,windows 150, and application(s) 145, whereupon the user may supply additional inputs or terminate the session. In the preferred embodiment,OS 140 andwindows 150 together comprise Microsoft Windows software (e.g., Windows 9x or Windows NT). Although shown conceptually as a separate module, the UI is typically provided by interaction of the application modules with the windows shell and theOS 140. - Although the methodology of the present invention may be embodied on a single device for synchronizing or reconciling multiple data sets present on that device, the present invention will instead typically be embodied in an environment including two or more computing or information-storing devices, which are occasionally or continually connected. For purposes of the discussion which follows, therefore, it is convenient to consider an embodiment of the present intention in a client/server-like system having a client (e.g., hand-held or portable “organizer”
device 154,laptop computer 152, or the like) in communication with a synchronization engine residing on a “host” or “server” computer (e.g., computer system 100). The synchronization engine itself is constructed to effect reconciliation or synchronization among two or more data sets, according to user-specified conditions or criteria. For a description of the details construction and operation of a synchronization engine, see e.g., commonly-owned application Ser. No. 09/136,212, filed Aug. 18, 1998, the disclosure of which has previously been incorporated by reference. - The present invention is not limited to any particular synchronization engine or hardware configuration but, instead, may be advantageously employed in any environment requiring and capable of supporting synchronization of two or more data stores. For example, the
laptop computer 152 may serve as the “server” with both thecomputer system 100 and theorganizer device 154 serving as “clients.” Hence, for purposes of the present invention, which device functions as a “client” (or multiple devices functioning as “clients”) and which device functions as a “server,” is largely an arbitrary choice. And in instances where the present invention is employed to support peer-to-peer configurations, the use of “client” and “server” distinctions is in fact not even applicable. Therefore, although the distinction of a particular device being a “client” and another device being a “server” is useful as a framework for presenting exemplary synchronization scenarios for application of the present invention, the present invention itself actually requires no such distinction. - Additionally, the means for communication may be one of a variety of communication means, including serial link (e.g.,
RS 232 wired link), parallel link, infrared link, wireless (cellular) link, or the like. The present invention is independent of communication means, so long as synchronization messages can eventually be transmitted and received, whether in a synchronous or asynchronous manner. Instead, what is required is an interface to the underlying synchronization protocol (whatever that protocol may be), so that there exists some means of initiating a synchronization session which is adapted to include a negotiation phase of the present invention, as described below. Typically, the interface would be implemented in program code existing at the target device and complementary program code existing at the synchronization engine, so that the two may exchange messages or commands (including parameter information) in the format specified by the particular synchronization protocol. The synchronization protocol should, however, at least allow the exchange of attribute information, so that synchronization attributes of the target device may be communicated to the synchronization engine. - Synchronization Process Negotiation
- A. Overview
- The present invention introduces into a given synchronization protocol (which itself may be one of a variety of types) a “negotiation phase” at the beginning of the synchronization, during which the devices involved will exchange information about the capabilities of one or more devices. Typically, the capabilities of the client device are the limiting factor for synchronization, so that the negotiation phase may proceed by only including enumeration of the client's capabilities. Once this negotiation phase has been completed, the synchronization can then proceed in a manner that is most efficient for the features that are available. The present invention itself is actually independent of any particular literal protocol, as it may be incorporated into a variety of different synchronization protocols, as well as different devices or different communication (message transport) layers. Therefore, the focus of the present convention is, instead, on the adaptation of a synchronization protocol to incorporate a basic mechanism for negotiating the synchronization process before synchronization begins, thereby governing how synchronization proceeds.
- B. Synchronization Processes
- From the perspective of a synchronization engine, a given synchronization process may be divided into the following basic steps (using the above-described client/server framework for discussion):
- 1. Figure out what records have changed on the client (i.e., target device).
- 2. Reconcile those changes with the local data store.
- 3. Update the client data store appropriately.
- How these three steps are actually performed varies significantly from one client to another, depending upon the capabilities of the underlying device. For instance, as previously illustrated in Example 1 and Example 2 above, the task of figuring out what records have changed on the client varies considerably, depending on capabilities of the client. Therefore, of particular interest herein is the process to be used for these steps that is negotiated in the “negotiation phase” before synchronization begins.
- With regard to step 1 above, three different ways exist that a sync engine can figure out what has changed on the client:
- 1. Download the entire data store and compare to a previously stored copy (slowest).
- 2. Download a set of record “headers” (e.g., containing time stamp or signature/checksum information) which can be compared to a previous copy to determine what has changed. This approach is faster than #1, since less information is transmitted.
- 3. Ask the device to transmit all the records which have changed since a particular “Sync Anchor” value (fastest). Here, Sync Anchor refers to a value, such as a time stamp or a change counter (e.g., value incremented each time a record is changed), that allows one to determine whether a record has changed since a particular point in time, usually since last synchronization. This is a value which is associated with a particular record and is changed whenever the record is changed. The sync engine can then compare this value to a previously stored value to detect that changes have been made.
- The present invention introduces the ability for the synchronization engine to query the client or target device about a particular attribute, to find out what the device's capabilities are in that respect. (As previously described, the approach is adaptable to a variety of different synchronization engines, including for example the synchronization engine described by application Ser. No. 09/136,212). Given the above ways in which a synchronization engine can determine what has changed on a client, the present invention introduces a “RECORD_FILTERING” parameter, to allow the synchronization engine to determine what the client's capabilities are with respect to these three processes (i.e., with respect to filtering records from synchronization). The parameter may be set to one of the following values:
- RECORD_FILTERING={NONE|HEADERS|SINCE_X}
- NONE indicates that the client does not provide any record filtering functionality (i.e.,
process # 1 above); the client can only give the entire data store. HEADERS indicates that the client can provide record headers (i.e., process #2 above). Here, the client cannot pick out what has changed, but it can provide a snapshot summary that is smaller than all of the data (from which the synchronization engine can then determine changes). SINCE_X indicates that the client can provide records as of a particular “Sync Anchor” value, where X indicates a time stamp or change counter value. Here, the client is capable of providing records which have changed from a particular value (e.g., time stamp value for a particular date and time) given by the synchronization engine. - In the event that the client can provide headers, the sync engine needs to know what sort of information to expect in those headers in order to perform synchronization. Possibilities include the following:
- 1. Headers include a CRC (cyclic redundancy checking) value for each record.
- 2. Headers include a modification time (time stamp) for each record.
- 3. Headers include a change counter for each record.
- These three options are reflected in a “CHANGE_TRACKING” parameter, which indicates what the device's capabilities are in terms of knowing what has changed. This parameter may be set to one of the following values:
- CHANGE_TRACKING={NONE|CRC|TIMESTAMP|CHANGE_COUNTER}
- NONE indicates that the device or client has no ability to determine if something has changed in its data store. CRC indicates a CRC value for each record; TIMESTAMP indicates a modification time for each record; and CHANGE_COUNTER indicates a change count value for each record.
- Clients which cannot support a “SINCE_X” access method must either transmit their entire data store or transmit headers. For such clients, the sync engine will need to request the desired records from the device. For example, if the synchronization engine has determined, based on comparison of CRC values that a particular record has changed, the synchronization engine needs a means in order to request that record from the device. Different devices will provide different levels of access and different types of access to their records, however. Therefore, a third parameter is required for specifying what type of access is provided.
- The types of record access that devices can support include the following:
- 1. The device can only transmit and receive the entire data store as a block; it is not possible to request or submit individual records.
- 2. The device provides “static index” access to the records (i.e., there are a fixed number of record storage “slots”, and the sync engine can request and submit records based on this slot number. The records may move to different slots in between synchronizations, so there is no lasting fixed correlation between a slot number and a record).
- 3. The device provides “unique IDs” for each record, and the sync engine can request and submit individual records using these IDs. Unique IDs are guaranteed to be unique within a particular data store, and the association between a record and its ID is never broken.
- These three options are reflected in a “RECORD_ACCESS” parameter, which may take one of the following values:
- RECORD_ACCESS={BLOCK|STATIC|UNIQUE}
- BLOCK record access indicates that the device can only give access to the entire set or “block” of records (i.e., the entire data store); this is the most primitive type of record access. STATIC record access indicates a static index mechanism. For example, a Motorola StarTac® phone provides 99 slots for storing phone numbers. A synchronization engine can request, for instance, the contents of slot #5. There is, however, no association between the slot number and the value stored (i.e., record contents), and in fact the phone can shuffle the records around at its discretion. UNIQUE indicates that each record within the data store is represented by a unique ID, within the scope or context of that particular data store. Here, the relationship between the unique identifier and the record is fixed or permanent. This level of record access allows the synchronization engine to get and put an individual record, based on the ID.
- B. Example Utilizing Parameter Information
- Based on the just-described three synchronization-negotiation parameters of the present invention, the synchronization engine can use the parameters to control the synchronization process and to pick a synchronization process that is optimized for a particular target device. When the sync engine is able to query the device for its synchronization capabilities using these three basic parameters, therefore, it becomes possible for the sync engine to proceed with a method of synchronization that is appropriate to the capabilities of the device. This is perhaps best illustrated by way of example, using the following for synchronization processes.
- Consider the following four synchronization processes, with their corresponding parameter values:
- Synchronization Attribute Parameters:
- RECORD_FILTERING=NONE
- CHANGE_TRACKING=NONE
- RECORD_ACCESS=BLOCK
- Optimal Synchronization Process Available:
- (a) Obtain complete data store;
- (b) Perform sync locally; and
- (c) Replace entire data store.
- Synchronization Attribute Parameters:
- RECORD_FILTERING=NONE
- CHANGE_TRACKING=NONE
- RECORD_ACCESS=STATIC|UNIQUE
- Optimal Synchronization Process Available:
- (a) Obtain complete data store;
- (b) Perform sync locally; and
- (c) Replace only affected records.
- Synchronization Attribute Parameters:
- RECORD_FILTERING=HEADERS
- CHANGE_TRACKING=CRC|TIMESTAMP|CHANGE_COUNTER
- RECORD_ACCESS=UNIQUE
- Optimal Synchronization Process Available:
- (a) Obtain a summary of all records which includes per-record change-tracking information;
- (b) Fetch only the changed records;
- (c) Perform sync; and
- (d) Replace only affected records.
- Synchronization Attribute Parameters:
- RECORD_FILTERING=SINCE_X
- CHANGE_TRACKING=TIMESTAMP|CHANGE_COUNTER
- RECORD_ACCESS=UNIQUE
- Optimal Synchronization Process Available:
- (a) Request only the changed records from the device;
- (b) Perform sync; and
- (c) Replace only the affected records.
- The following illustrates an exemplary communication session for such a case.
TABLE 1 EXEMPLARY COMMUNICATION SESSION Client Server Notes: Login LoginResponse Request Sync Attributes Return Sync Attributes RequestChangesSinceX UpdateRecord UpdateRecord LastRecordSent AckLastRecordSent Perform synchronization at server DeleteRecord InsertRecord UpdateRecord LastRecordSent AckLastRecordSent UpdateMap (optional details) LastMapSent AckLastMapSent Logout - This synchronization session demonstrates exchange (e.g., synchronization protocol-based dialog) in which the target device is capable of knowing which records to send to the server, based on the last sync time communicated during login. Here, the server performs synchronization (including, conflict resolution) after receiving all client changes. Alternatively, the server may be configured to perform synchronization or at least some degree of conflict resolution upon receipt of each client record (i.e., process does not wait until receipt of all client records before commencing).
- C. Methodology summarized
- FIGS.2A-E present flow charts illustrating the overall method steps employed for synchronization process negotiation. In
step 201, the respective devices establish a communication link (i.e., establish communication link between target device(s), client(s), and synchronization engine). Instep 202, the devices exchange acknowledgments for initiating synchronization protocol. Instep 203, the devices begin synchronization negotiation by eliciting the synchronization capabilities of the target device(s). This occurs, for instance, by transmitting a request from the synchronization engine to the client for synchronization parameters or attributes of the client. As indicated bystep 204, in response to this request, the client transmits synchronization parameters indicating the client's capabilities. In the currently-preferred embodiment, such parameters or attributes include: (1) whether records are filtered (RECORD_FILTER parameter), (2) what type of change tracking (e.g., time stamp or change value) is provided at the client (CHANGE_TRACKING parameter), and (3) what level of record access is afforded by the client (RECORD_ACCESS parameter). Based on the transmitted parameter values, the synchronization engine will select an optimal synchronization process or strategy. - Processing at this point depends on the actual values set in the parameters. In other words, how the synchronization process proceeds from this point on depends, at least in part, on the synchronization capabilities (if any) of the client: a synchronization protocol is selected that allows optimization of the synchronization process, based on client capabilities. The processing logic applied by the method at this point is summarized by
step 205. In the event that record filtering is set to “none”, change tracking is set to “none”, and record access is set to “block”, the method proceeds to steps to 211-213 (case instance or condition A). In such a case, the synchronization engine obtains the complete data store (step 211), performs synchronization locally (step 212), and then replaces the entire data store (step 213), as shown in FIG. 2B. In the event that record filtering is set to “none”, change tracking is set to “none”, and record access is set to “static” or “unique”, the method proceeds to steps to 221-223 (case condition B). Here, the synchronization engine obtains the complete data store (step 221), performs synchronization locally (step 222), but then only replaces the affected records (step 223), as shown in FIG. 2C. - Continuing with the other case conditions, in the event that record filtering is set to “headers”, change tracking is set to “CRC”, or “timestamp” or “change counter”, and record access is set to “unique”, the method proceeds to steps to231-234 (case condition C). In such a case, the synchronization engine obtains a summary of all records which includes per record change-tracking information (step 231), fetches only the changed records (step 232), performs synchronization locally (step 233), and then replaces only the affected records (step 234), as shown in FIG. 2D. In the event that record filtering is set to “since X change” tracking, change tracking is set to “time stamp” or “change counter”, and record access is set to “static” or “unique”, the method proceeds to steps to 241-243 (case condition D). Here, the synchronization engine requests only the changed records from the target device (step 241), performs synchronization locally (step 242), and then only replaces the affected records (step 243), as shown in FIG. 2E. After conclusion of the proper case condition invocation, the method is done.
- The above demonstrates that, based on synchronization parameter combinations, the synchronization engine proceeds with synchronization in a manner selected to optimize the process, based on the capabilities of the particular target device participating in synchronization. The ability of the client to facilitate the process is utilized based on the recognition by the synchronization engine that the client is able to assist in the process. Here, in contrast to hard-wired approaches in prior art systems, the synchronization engine adapts to the capabilities of each individual client, even though each client itself may have a degree of support for synchronization that is quite different than that of other clients. In effect, both the client and the synchronization engine “negotiate” as to the best synchronization process to use. Synchronization then proceeds based on the negotiated or agreed-upon synchronization protocol (which itself can be any one of a number of synchronization protocols).
- D. Conclusion
- By providing a mechanism to access basic synchronization parameters, the present invention allows a sync engine to effect synchronization among a variety of different devices in a manner that is optimal for the capabilities of each particular device. In this fashion, the amount of traffic (information) over the communication link may be minimized. This is particularly important in configurations having slow communication links (e.g., serial cable link) and/or large amounts of data. Additionally, the amount of work which the synchronization engine must do is minimized. All told, the present invention solves the previously-described problem that exists with these present-day approaches employing a “hard-wired” protocol approach: a synchronization protocol may be negotiated between or among an arbitrary set of devices, such that an optimal synchronization protocol is selected for those devices.
- While the invention is described in some detail with specific reference to a single preferred embodiment and certain alternatives, there is no intent to limit the invention to that particular embodiment or those specific alternatives. Thus, the true scope of the present invention is not limited to any one of the foregoing exemplary embodiments but is instead defined by the appended claims.
Claims (42)
1. In a data processing environment, a method for synchronizing a first data set residing on a first device with a second data set residing on a second device, the method comprising:
establishing a communication link between said first and second devices;
transmitting from the second device to the first device a request for synchronization capabilities of the first device;
in response to said request, transmitting from the first device to the second device information indicating said synchronization capabilities of the first device;
based on said synchronization capabilities of the first device, selecting a synchronization protocol for synchronizing said first and second data sets; and
performing synchronization of said first and second data sets using said selected synchronization protocol, wherein said synchronization is performed in a manner optimized for the synchronization capabilities of the first device.
2. The method of , wherein said communication link comprises a wireless link.
claim 1
3. The method of , wherein said communication link comprises a wired link.
claim 1
4. The method of , wherein said first and second devices are only occasionally connected via said communication link.
claim 1
5. The method of , wherein said first and second devices are persistently connected via said communication link.
claim 1
6. The method of , wherein said request for synchronization capabilities of the first device comprises a communication message requesting synchronization parameters from the first device.
claim 1
7. The method of , wherein said synchronization parameters comprise attribute/value pairs indicating synchronization capabilities of the first device.
claim 6
8. The method of , wherein said synchronization parameters include a record filtering parameter indicating what capability the first device has for filtering records from synchronization.
claim 6
9. The method of , wherein said record filtering parameter can express a value of “none” to indicate that the first device has no record filtering capability.
claim 8
10. The method of , wherein said record filtering parameter can express a value indicating that the first device has the capability of providing record headers for records of the first data set.
claim 8
11. The method of , wherein said record filtering parameter can express a value indicating that the first device has the capability of providing only those records of the first data set which meet a particular condition.
claim 8
12. The method of , wherein said particular condition comprises a synchronization anchor value against which records are tested.
claim 11
13. The method of , wherein said synchronization anchor value comprises a time stamp value.
claim 12
14. The method of , wherein said synchronization anchor value comprises a change counter value.
claim 12
15. The method of , wherein said change counter value comprises a value incremented each time a particular record is changed, thereby allowing a device to determine whether a change has occurred to the particular record.
claim 14
16. The method of , wherein said synchronization parameters include a change tracking parameter indicating what type of information the first device provides when transmitting record headers.
claim 6
17. The method of , wherein said change tracking parameter comprises a selected one of a cyclic redundancy checking (CRC) value, a time stamp value, and a change counter value.
claim 16
18. The method of , wherein said synchronization parameters include a record access parameter indicating what level of access the first device provides to other devices.
claim 6
19. The method of , wherein said record access parameter comprises a value indicating that the first device can only give access to the entire first data set.
claim 18
20. The method of , wherein said value indicating that the first device can only give access to the entire first data set comprises a “block” value.
claim 19
21. The method of , wherein said record access parameter comprises a value indicating that the first device can give access to individual records of the first data set through a static index mechanism.
claim 18
22. The method of , wherein said value indicating that the first device can give access to individual records of the first data set through a static index mechanism comprises a “static” value.
claim 21
23. The method of , wherein said record access parameter comprises a value indicating that the first device can give access to individual records of the first data set using a unique identifier for each record.
claim 18
24. The method of , wherein said value indicating that the first device can give access to the individual records of the first data using a unique identifier for each record comprises a “unique” value.
claim 23
25. The method of , wherein said value indicating that the first device can give access to the individual records of the first data using a unique identifier indicates that the first device allows other devices to get and put an individual record, based on an ID that is unique to that record .
claim 23
26. The method of , each unique identifier for records of the first device is a selected one of an identifier that is unique within the scope of the first device and an identifier that is globally unique.
claim 23
27. A method for synchronizing a first device having a first data set with a second device having a second data set, the method comprising:
selectively connecting the first device to a second device, for establishing communication between the two devices;
negotiating a synchronization process for synchronizing said first and second data sets by performing substeps of:
sending a request from the second device to the first device for synchronization capabilities of the first device;
in response to said request, transmitting from the first device to the second device synchronization parameters conveying the synchronization capabilities of the first device; and
based on said synchronization parameters received from the first device, selecting a synchronization process for synchronizing said first and second data sets; and
performing synchronization of said first and second data sets using said selected synchronization process.
28. The method of , wherein synchronization parameters indicate that the first device provides no record filtering, provides no change tracking, and provides block record access, and wherein said synchronization step is performed by:
claim 27
(a) transmitting from the first device to the second device an entire copy of the first data set;
(b) performing synchronization locally at the second device, using said copy of the first data set; and
(c) once said copy of the first data set has been synchronized, replacing the first data set of the first device with the copy of the first data set which has been synchronized at the second device.
29. The method of , wherein synchronization parameters indicate that the first device provides no record filtering, provides no change tracking, and provides record access using either a static index or a unique record identifier, and wherein said synchronization step is performed by:
claim 27
(a) transmitting from the first device to the second device an entire copy of the first data set;
(b) performing synchronization locally at the second device, using said copy of the first data set; and
(c) once said copy of the first data set has been synchronized, replacing only those records of the first data set of the first device that are affected by the synchronization.
30. The method of , wherein said synchronization parameters indicate that the first device provides record filtering using record headers, provides change tracking, and provides record access using a unique record identifier, and wherein said synchronization step is performed by:
claim 27
(a) transmitting from the first device to the second device a summary of the first data set, which includes per record change-tracking information;
(b) based on said change-tracking information, transmitting from the first device to the second device a copy of only those records of the first data set which have changed;
(c) performing synchronization locally at the second device, using said copy of only those records of the first data set which have changed; and
(d) once said copy of the first data set has been synchronized, replacing each record of the first data set of the first device that is affected by the synchronization, using the unique record identifier for each record.
31. A synchronization system comprising:
a communication link between a first data set from a first device with a second data set from a second device;
a synchronization engine for enumerating particular synchronization capabilities of devices and for performing synchronization between data sets;
a synchronization interface capable of responding to said synchronization engine, for transmitting from the first device information indicating the particular synchronization capabilities of the first device; and
whereupon said synchronization engine selects a particular synchronization process for synchronizing said first and second data sets, based on the particular synchronization capabilities of the first device, and thereafter performs synchronization of said first and second data sets using said selected synchronization process.
32. The system of , wherein said communication link is a selected one of a wireless communication link and a wired communication link.
claim 31
33. The system of , wherein said wireless communication link comprises a cellular phone link.
claim 32
34. The system of , wherein said wired communication link comprises a serial RS232 communication link.
claim 32
35. The system of , wherein said communication link comprises a selected one of a synchronous communication link and an asynchronous communication link.
claim 31
36. The system of , wherein said synchronization interface resides, at least in part, at said first device.
claim 31
37. The system of , wherein said synchronization interface supports communication of synchronization commands and parameters between said first and second devices.
claim 31
38. The system of , wherein said information indicating the particular synchronization capabilities of the first device comprises synchronization parameters.
claim 31
39. The system of , wherein said synchronization parameters comprise attribute/value pairs indicating synchronization capabilities of the first device.
claim 38
40. The system of , wherein said synchronization parameters include a record filtering parameter indicating what capability the first device has for filtering records from synchronization.
claim 38
41. The system of , wherein said synchronization parameters include a change tracking parameter indicating what type of information the first device can provide by transmitting only record headers.
claim 38
42. The system of , wherein said synchronization parameters include a record access parameter indicating what level of access the first device provides to other devices.
claim 38
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/877,553 US20010039629A1 (en) | 1999-03-03 | 2001-06-08 | Synchronization process negotiation for computing devices |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12259299P | 1999-03-03 | 1999-03-03 | |
US09/287,546 US6247135B1 (en) | 1999-03-03 | 1999-04-06 | Synchronization process negotiation for computing devices |
US09/877,553 US20010039629A1 (en) | 1999-03-03 | 2001-06-08 | Synchronization process negotiation for computing devices |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/287,546 Continuation US6247135B1 (en) | 1999-03-03 | 1999-04-06 | Synchronization process negotiation for computing devices |
Publications (1)
Publication Number | Publication Date |
---|---|
US20010039629A1 true US20010039629A1 (en) | 2001-11-08 |
Family
ID=26820701
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/287,546 Expired - Lifetime US6247135B1 (en) | 1999-03-03 | 1999-04-06 | Synchronization process negotiation for computing devices |
US09/877,553 Abandoned US20010039629A1 (en) | 1999-03-03 | 2001-06-08 | Synchronization process negotiation for computing devices |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/287,546 Expired - Lifetime US6247135B1 (en) | 1999-03-03 | 1999-04-06 | Synchronization process negotiation for computing devices |
Country Status (1)
Country | Link |
---|---|
US (2) | US6247135B1 (en) |
Cited By (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040024683A1 (en) * | 2001-09-21 | 2004-02-05 | Michal Morciniec | Apparatus and method of communicating changes in states of contractual responsibilities |
US7072911B1 (en) * | 2001-07-27 | 2006-07-04 | Novell, Inc. | System and method for incremental replication of changes in a state based distributed database |
WO2006115521A1 (en) * | 2005-04-22 | 2006-11-02 | Microsoft Corporation | System and method for peer to peer synchronization of files |
US20070150895A1 (en) * | 2005-12-06 | 2007-06-28 | Kurland Aaron S | Methods and apparatus for multi-core processing with dedicated thread management |
US20070186001A1 (en) * | 2006-02-07 | 2007-08-09 | Dot Hill Systems Corp. | Data replication method and apparatus |
US20080072003A1 (en) * | 2006-03-28 | 2008-03-20 | Dot Hill Systems Corp. | Method and apparatus for master volume access during colume copy |
US20080177957A1 (en) * | 2007-01-18 | 2008-07-24 | Dot Hill Systems Corp. | Deletion of rollback snapshot partition |
US20080177954A1 (en) * | 2007-01-18 | 2008-07-24 | Dot Hill Systems Corp. | Method and apparatus for quickly accessing backing store metadata |
US20080256311A1 (en) * | 2007-04-11 | 2008-10-16 | Dot Hill Systems Corp. | Snapshot preserved data cloning |
US20080256141A1 (en) * | 2007-04-11 | 2008-10-16 | Dot Hill Systems Corp. | Method and apparatus for separating snapshot preserved and write data |
US20080281877A1 (en) * | 2007-05-10 | 2008-11-13 | Dot Hill Systems Corp. | Backing store re-initialization method and apparatus |
US20080281875A1 (en) * | 2007-05-10 | 2008-11-13 | Dot Hill Systems Corp. | Automatic triggering of backing store re-initialization |
US20080320258A1 (en) * | 2007-06-25 | 2008-12-25 | Dot Hill Systems Corp. | Snapshot reset method and apparatus |
US20090119349A1 (en) * | 2007-11-07 | 2009-05-07 | International Business Machines Corporation | Methods and Computer Program Products for Efficient Conflict Detection in a Replicated Hierarchical Content Repository Using Replication Anchors |
US20100100590A1 (en) * | 2008-10-21 | 2010-04-22 | Palay Andrew J | Always ready client/server data synchronization |
WO2010048329A1 (en) * | 2008-10-21 | 2010-04-29 | Google Inc. | Search based specification for data synchronization |
EP2204964A1 (en) * | 2007-12-12 | 2010-07-07 | Huawei Technologies Co., Ltd. | Method and device for realizing data synchronization |
US20100172454A1 (en) * | 2007-06-13 | 2010-07-08 | Koninklijke Philips Electronics N.V. | Synchronization protocol |
US20110078332A1 (en) * | 2009-09-25 | 2011-03-31 | Poon Roger J | Method of synchronizing information across multiple computing devices |
US20150269217A1 (en) * | 2008-07-22 | 2015-09-24 | International Business Machines Corporation | Embedded change logging for data synchronization |
Families Citing this family (252)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
US6560700B1 (en) * | 1998-11-17 | 2003-05-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Protocol for synchronizing parallel processors in a mobile communication system |
US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media appliance system and method |
US6496873B1 (en) * | 1999-05-21 | 2002-12-17 | International Business Machines Corporation | Real time device driver interface apparatus and method therefor |
DE19934787B4 (en) * | 1999-07-27 | 2004-08-05 | T-Mobile Deutschland Gmbh | Method for automatically adapting the data to be transmitted from a data providing device to a data retrieving device to the capabilities of this terminal |
US6393434B1 (en) * | 1999-09-14 | 2002-05-21 | International Business Machines Corporation | Method and system for synchronizing data using fine-grained synchronization plans |
JP3963417B2 (en) * | 1999-11-19 | 2007-08-22 | 株式会社東芝 | Communication method and electronic device for data synchronization processing |
US6748403B1 (en) * | 2000-01-13 | 2004-06-08 | Palmsource, Inc. | Method and apparatus for preserving changes to data |
US7035878B1 (en) | 2000-01-25 | 2006-04-25 | Fusionone, Inc. | Base rolling engine for data transfer and synchronization system |
US8620286B2 (en) | 2004-02-27 | 2013-12-31 | Synchronoss Technologies, Inc. | Method and system for promoting and transferring licensed content and applications |
US6671757B1 (en) | 2000-01-26 | 2003-12-30 | Fusionone, Inc. | Data transfer and synchronization system |
US6694336B1 (en) | 2000-01-25 | 2004-02-17 | Fusionone, Inc. | Data transfer and synchronization system |
US8156074B1 (en) | 2000-01-26 | 2012-04-10 | Synchronoss Technologies, Inc. | Data transfer and synchronization system |
US6871140B1 (en) * | 2000-02-25 | 2005-03-22 | Costar Group, Inc. | System and method for collection, distribution, and use of information in connection with commercial real estate |
US6820088B1 (en) * | 2000-04-10 | 2004-11-16 | Research In Motion Limited | System and method for synchronizing data records between multiple databases |
US6988141B1 (en) | 2000-05-17 | 2006-01-17 | Ricoh Company, Ltd. | Method and system of remote diagnostic, control and information collection using a dynamic linked library of multiple formats and multiple protocols with restriction on protocol |
US6944651B2 (en) * | 2000-05-19 | 2005-09-13 | Fusionone, Inc. | Single click synchronization of data from a public information store to a private information store |
US6810408B1 (en) * | 2000-05-31 | 2004-10-26 | International Business Machines Corporation | Method and apparatus for controlling cascading e-mail distribution |
US6470329B1 (en) * | 2000-07-11 | 2002-10-22 | Sun Microsystems, Inc. | One-way hash functions for distributed data synchronization |
US7895334B1 (en) | 2000-07-19 | 2011-02-22 | Fusionone, Inc. | Remote access communication architecture apparatus and method |
US6925476B1 (en) | 2000-08-17 | 2005-08-02 | Fusionone, Inc. | Updating application data including adding first change log to aggreagate change log comprising summary of changes |
US6718348B1 (en) * | 2000-08-25 | 2004-04-06 | Telefonaktiebolaget Lm Ericsson (Publ) | Non-time dependent synchronization of databases |
WO2002033593A1 (en) | 2000-10-16 | 2002-04-25 | Aether Systems, Inc. | Run-time engine implemented on a computing device allowing synchronization of records during application execution |
US20090132316A1 (en) * | 2000-10-23 | 2009-05-21 | Costar Group, Inc. | System and method for associating aerial images, map features, and information |
US20020056075A1 (en) * | 2000-11-06 | 2002-05-09 | Andrew Hamilton | System for a run-time engine capable for pager capable remote device |
US20020055939A1 (en) * | 2000-11-06 | 2002-05-09 | Joseph Nardone | System for a configurable open database connectivity conduit |
US7587446B1 (en) | 2000-11-10 | 2009-09-08 | Fusionone, Inc. | Acquisition and synchronization of digital media to a personal information space |
US7062486B2 (en) * | 2000-12-05 | 2006-06-13 | International Business Machines Corporation | Method, system and program product for enabling authorized access and request-initiated translation of data files |
US7818435B1 (en) | 2000-12-14 | 2010-10-19 | Fusionone, Inc. | Reverse proxy mechanism for retrieving electronic content associated with a local network |
US8615566B1 (en) | 2001-03-23 | 2013-12-24 | Synchronoss Technologies, Inc. | Apparatus and method for operational support of remote network systems |
US7275116B1 (en) | 2001-07-30 | 2007-09-25 | Western Digital Ventures, Inc. | Mobile terminal synchronizing components of a document separately |
US7725584B1 (en) | 2001-07-30 | 2010-05-25 | Western Digital Ventures, Inc. | Using multiple communication channels to synchronize a mobile terminal based on data type |
US6658260B2 (en) * | 2001-09-05 | 2003-12-02 | Telecommunication Systems, Inc. | Inter-carrier short messaging service providing phone number only experience |
US6894804B2 (en) * | 2001-10-03 | 2005-05-17 | Toshiba Tec Kabushiki Kaisha | Method to dynamically perform document layout functions |
US7430605B2 (en) * | 2001-10-03 | 2008-09-30 | Toshiba Tec Kabushiki Kaisha | Method of printer accounting management |
US7571126B2 (en) * | 2001-10-03 | 2009-08-04 | Toshiba Corporation | System and method for document processing operation accounting |
US7265858B2 (en) * | 2001-10-03 | 2007-09-04 | Kabushiki Kaisha Toshiba | Method and system to access address books |
GB2387001B (en) * | 2001-10-22 | 2005-02-02 | Apple Computer | Intelligent interaction between media player and host computer |
US20030167318A1 (en) * | 2001-10-22 | 2003-09-04 | Apple Computer, Inc. | Intelligent synchronization of media player with host computer |
WO2003058483A1 (en) | 2002-01-08 | 2003-07-17 | Seven Networks, Inc. | Connection architecture for a mobile network |
US7133152B2 (en) * | 2002-02-28 | 2006-11-07 | Kabushiki Kaisha Toshiba | Post RIP paper conversion |
JP4279499B2 (en) * | 2002-03-01 | 2009-06-17 | シャープ株式会社 | Information processing device |
US7164492B2 (en) * | 2002-03-07 | 2007-01-16 | Kabushiki Kaisha Toshiba | Automatic facsimile document resizing |
US7245392B2 (en) * | 2002-03-08 | 2007-07-17 | Kabushiki Kaisha Toshiba | Method for generating a fax cover page |
US7346616B2 (en) * | 2002-03-20 | 2008-03-18 | Extended System, Inc. | Synchronizing data shared between two devices independent of any other devices that may also share the data |
US8126889B2 (en) | 2002-03-28 | 2012-02-28 | Telecommunication Systems, Inc. | Location fidelity adjustment based on mobile subscriber privacy profile |
US8290505B2 (en) | 2006-08-29 | 2012-10-16 | Telecommunications Systems, Inc. | Consequential location derived information |
US7426380B2 (en) | 2002-03-28 | 2008-09-16 | Telecommunication Systems, Inc. | Location derived presence information |
US8918073B2 (en) | 2002-03-28 | 2014-12-23 | Telecommunication Systems, Inc. | Wireless telecommunications location based services scheme selection |
US8027697B2 (en) | 2007-09-28 | 2011-09-27 | Telecommunication Systems, Inc. | Public safety access point (PSAP) selection for E911 wireless callers in a GSM type system |
US9154906B2 (en) | 2002-03-28 | 2015-10-06 | Telecommunication Systems, Inc. | Area watcher for wireless network |
US9715500B2 (en) | 2004-04-27 | 2017-07-25 | Apple Inc. | Method and system for sharing playlists |
US7680849B2 (en) * | 2004-10-25 | 2010-03-16 | Apple Inc. | Multiple media type synchronization between host computer and media device |
US7827259B2 (en) * | 2004-04-27 | 2010-11-02 | Apple Inc. | Method and system for configurable automatic media selection |
US8150937B2 (en) | 2004-10-25 | 2012-04-03 | Apple Inc. | Wireless synchronization between media player and host device |
US9412417B2 (en) | 2002-04-05 | 2016-08-09 | Apple Inc. | Persistent group of media items for a media device |
US7797446B2 (en) * | 2002-07-16 | 2010-09-14 | Apple Inc. | Method and system for updating playlists |
US7324857B2 (en) * | 2002-04-19 | 2008-01-29 | Gateway Inc. | Method to synchronize playback of multicast audio streams on a local network |
US11337047B1 (en) | 2002-05-21 | 2022-05-17 | M2M Solutions Llc | System and method for remote asset management |
GB0211644D0 (en) | 2002-05-21 | 2002-07-03 | Wesby Philip B | System and method for remote asset management |
US7956272B2 (en) * | 2002-07-30 | 2011-06-07 | Apple Inc. | Management of files in a personal communication device |
US7166791B2 (en) | 2002-07-30 | 2007-01-23 | Apple Computer, Inc. | Graphical user interface and methods of use thereof in a multimedia player |
US20040044799A1 (en) * | 2002-09-03 | 2004-03-04 | Nokia Corporation | Method, device and system for synchronizing of data providing for the handling of an interrupted synchronization process |
FI114750B (en) * | 2002-10-29 | 2004-12-15 | Nokia Corp | Synchronizing data |
US8468126B2 (en) | 2005-08-01 | 2013-06-18 | Seven Networks, Inc. | Publishing data in an information community |
US7917468B2 (en) | 2005-08-01 | 2011-03-29 | Seven Networks, Inc. | Linking of personal information management data |
US7853563B2 (en) | 2005-08-01 | 2010-12-14 | Seven Networks, Inc. | Universal data aggregation |
WO2005010715A2 (en) | 2003-07-21 | 2005-02-03 | Fusionone, Inc. | Device message management system |
US7051623B2 (en) * | 2003-07-28 | 2006-05-30 | Easco Hand Tools, Inc. | Pawl-less ratchet wrench |
US7440981B2 (en) * | 2003-07-31 | 2008-10-21 | Microsoft Corporation | Systems and methods for replicating data stores |
US7401103B2 (en) * | 2003-07-31 | 2008-07-15 | Microsoft Corporation | Replication protocol for data stores |
US7424293B2 (en) | 2003-12-02 | 2008-09-09 | Telecommunication Systems, Inc. | User plane location based service using message tunneling to support roaming |
US7260186B2 (en) | 2004-03-23 | 2007-08-21 | Telecommunication Systems, Inc. | Solutions for voice over internet protocol (VoIP) 911 location services |
US20080126535A1 (en) | 2006-11-28 | 2008-05-29 | Yinjun Zhu | User plane location services over session initiation protocol (SIP) |
US20080090546A1 (en) | 2006-10-17 | 2008-04-17 | Richard Dickinson | Enhanced E911 network access for a call center using session initiation protocol (SIP) messaging |
US7437484B2 (en) | 2003-12-29 | 2008-10-14 | International Business Machines Corporation | Method for optimizing synchronization |
US7673083B2 (en) * | 2004-04-27 | 2010-03-02 | Apple Inc. | Method and system for controlling video selection and playback in a portable media player |
US7526588B1 (en) | 2004-04-27 | 2009-04-28 | Apple Inc. | Communication between an accessory and a media player using a protocol with multiple lingoes |
US7529872B1 (en) | 2004-04-27 | 2009-05-05 | Apple Inc. | Communication between an accessory and a media player using a protocol with multiple lingoes |
US7441062B2 (en) * | 2004-04-27 | 2008-10-21 | Apple Inc. | Connector interface system for enabling data communication with a multi-communication device |
US20050240680A1 (en) * | 2004-04-27 | 2005-10-27 | Jose Costa-Requena | Method and apparatus for a life management server |
US8117651B2 (en) * | 2004-04-27 | 2012-02-14 | Apple Inc. | Method and system for authenticating an accessory |
US7529870B1 (en) | 2004-04-27 | 2009-05-05 | Apple Inc. | Communication between an accessory and a media player with multiple lingoes |
US6944636B1 (en) * | 2004-04-30 | 2005-09-13 | Microsoft Corporation | Maintaining time-date information for syncing low fidelity devices |
BRPI0406388A (en) | 2004-04-30 | 2006-02-07 | Microsoft Corp | Maintaining time and date information to sync low fidelity devices |
ES2585353T3 (en) | 2004-05-12 | 2016-10-05 | Synchronoss Technologies, Inc. | Advanced contact identification system |
US9542076B1 (en) | 2004-05-12 | 2017-01-10 | Synchronoss Technologies, Inc. | System for and method of updating a personal profile |
US8797926B2 (en) | 2004-06-04 | 2014-08-05 | Apple Inc. | Networked media station |
US10972536B2 (en) | 2004-06-04 | 2021-04-06 | Apple Inc. | System and method for synchronizing media presentation at multiple recipients |
US20070110074A1 (en) | 2004-06-04 | 2007-05-17 | Bob Bradley | System and Method for Synchronizing Media Presentation at Multiple Recipients |
US8443038B2 (en) | 2004-06-04 | 2013-05-14 | Apple Inc. | Network media device |
US8261246B1 (en) | 2004-09-07 | 2012-09-04 | Apple Inc. | Method and system for dynamically populating groups in a developer environment |
US7113128B1 (en) | 2004-10-15 | 2006-09-26 | Telecommunication Systems, Inc. | Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas |
US7629926B2 (en) | 2004-10-15 | 2009-12-08 | Telecommunication Systems, Inc. | Culled satellite ephemeris information for quick, accurate assisted locating satellite location determination for cell site antennas |
US6985105B1 (en) | 2004-10-15 | 2006-01-10 | Telecommunication Systems, Inc. | Culled satellite ephemeris information based on limiting a span of an inverted cone for locating satellite in-range determinations |
US7411546B2 (en) | 2004-10-15 | 2008-08-12 | Telecommunication Systems, Inc. | Other cell sites used as reference point to cull satellite ephemeris information for quick, accurate assisted locating satellite location determination |
US7441271B2 (en) | 2004-10-20 | 2008-10-21 | Seven Networks | Method and apparatus for intercepting events in a communication system |
US8010082B2 (en) | 2004-10-20 | 2011-08-30 | Seven Networks, Inc. | Flexible billing architecture |
US7706781B2 (en) | 2004-11-22 | 2010-04-27 | Seven Networks International Oy | Data security in a mobile e-mail service |
FI117152B (en) | 2004-12-03 | 2006-06-30 | Seven Networks Internat Oy | E-mail service provisioning method for mobile terminal, involves using domain part and further parameters to generate new parameter set in list of setting parameter sets, if provisioning of e-mail service is successful |
US7962448B2 (en) * | 2004-12-17 | 2011-06-14 | International Business Machines Corporation | Optimizing a three tiered synchronization system by pre-fetching and pre-formatting synchronization data |
US7634519B2 (en) * | 2004-12-17 | 2009-12-15 | International Business Machines Corporation | Bypassing an intermediate synchronization server of a three tiered synchronization system |
US11314378B2 (en) | 2005-01-07 | 2022-04-26 | Apple Inc. | Persistent group of media items for a media device |
US7958441B2 (en) * | 2005-01-07 | 2011-06-07 | Apple Inc. | Media management for groups of media items |
US7823214B2 (en) * | 2005-01-07 | 2010-10-26 | Apple Inc. | Accessory authentication for electronic devices |
US7752633B1 (en) | 2005-03-14 | 2010-07-06 | Seven Networks, Inc. | Cross-platform event engine |
US7353034B2 (en) | 2005-04-04 | 2008-04-01 | X One, Inc. | Location sharing and tracking using mobile phones or other wireless devices |
US8438633B1 (en) | 2005-04-21 | 2013-05-07 | Seven Networks, Inc. | Flexible real-time inbox access |
US7796742B1 (en) | 2005-04-21 | 2010-09-14 | Seven Networks, Inc. | Systems and methods for simplified provisioning |
US7493351B2 (en) * | 2005-05-05 | 2009-02-17 | International Business Machines Corporation | Rapid integration mechanism for directory based applications |
US20060259521A1 (en) * | 2005-05-16 | 2006-11-16 | Anthony Armenta | Interface for synchronization of documents between a host computer and a portable device |
US20060288036A1 (en) * | 2005-06-17 | 2006-12-21 | Microsoft Corporation | Device specific content indexing for optimized device operation |
WO2006136660A1 (en) | 2005-06-21 | 2006-12-28 | Seven Networks International Oy | Maintaining an ip connection in a mobile network |
US8660573B2 (en) | 2005-07-19 | 2014-02-25 | Telecommunications Systems, Inc. | Location service requests throttling |
US8069166B2 (en) | 2005-08-01 | 2011-11-29 | Seven Networks, Inc. | Managing user-to-user contact with inferred presence information |
US7783993B2 (en) * | 2005-09-23 | 2010-08-24 | Palm, Inc. | Content-based navigation and launching on mobile devices |
US9282451B2 (en) | 2005-09-26 | 2016-03-08 | Telecommunication Systems, Inc. | Automatic location identification (ALI) service requests steering, connection sharing and protocol translation |
US7825780B2 (en) | 2005-10-05 | 2010-11-02 | Telecommunication Systems, Inc. | Cellular augmented vehicle alarm notification together with location services for position of an alarming vehicle |
US8467320B2 (en) | 2005-10-06 | 2013-06-18 | Telecommunication Systems, Inc. | Voice over internet protocol (VoIP) multi-user conferencing |
US7907551B2 (en) | 2005-10-06 | 2011-03-15 | Telecommunication Systems, Inc. | Voice over internet protocol (VoIP) location based 911 conferencing |
US8015319B2 (en) * | 2005-10-27 | 2011-09-06 | Huawei Technologies Co., Ltd. | Method, system, client and server for implementing data sync |
TWI287744B (en) * | 2005-11-22 | 2007-10-01 | Inst Information Industry | Method and system for discover capabilities of communication device |
US7650367B2 (en) * | 2006-01-13 | 2010-01-19 | Tekelec | Methods, systems, and computer program products for detecting and restoring missing or corrupted data in a distributed, scalable, redundant measurement platform database |
US8150363B2 (en) | 2006-02-16 | 2012-04-03 | Telecommunication Systems, Inc. | Enhanced E911 network access for call centers |
US8059789B2 (en) | 2006-02-24 | 2011-11-15 | Telecommunication Systems, Inc. | Automatic location identification (ALI) emergency services pseudo key (ESPK) |
US7769395B2 (en) | 2006-06-20 | 2010-08-03 | Seven Networks, Inc. | Location-based operations and messaging |
US7899450B2 (en) | 2006-03-01 | 2011-03-01 | Telecommunication Systems, Inc. | Cellular augmented radar/laser detection using local mobile network within cellular network |
US7471236B1 (en) | 2006-03-01 | 2008-12-30 | Telecommunication Systems, Inc. | Cellular augmented radar/laser detector |
US9167553B2 (en) | 2006-03-01 | 2015-10-20 | Telecommunication Systems, Inc. | GeoNexus proximity detector network |
KR100782858B1 (en) * | 2006-04-11 | 2007-12-06 | 삼성전자주식회사 | Method and apparatus for synchronizing contents of home network devices |
US7890646B2 (en) * | 2006-04-27 | 2011-02-15 | Microsoft Corporation | Synchronization orchestration |
US8208605B2 (en) | 2006-05-04 | 2012-06-26 | Telecommunication Systems, Inc. | Extended efficient usage of emergency services keys |
US8073984B2 (en) | 2006-05-22 | 2011-12-06 | Apple Inc. | Communication protocol for use with portable electronic devices |
US7415563B1 (en) | 2006-06-27 | 2008-08-19 | Apple Inc. | Method and system for allowing a media player to determine if it supports the capabilities of an accessory |
US20080016248A1 (en) * | 2006-07-14 | 2008-01-17 | George Tsirtsis | Method and apparatus for time synchronization of parameters |
US7577691B2 (en) * | 2006-08-02 | 2009-08-18 | Microsoft Corporation | Extending hierarchical synchronization scopes to non-hierarchical scenarios |
US7558894B1 (en) | 2006-09-11 | 2009-07-07 | Apple Inc. | Method and system for controlling power provided to an accessory |
WO2008057477A2 (en) | 2006-11-03 | 2008-05-15 | Telecommunication Systems, Inc. | Roaming gateway enabling location based services (lbs) roaming for user plane in cdma networks without requiring use of a mobile positioning center (mpc) |
US8850140B2 (en) | 2007-01-07 | 2014-09-30 | Apple Inc. | Data backup for mobile device |
US20080168185A1 (en) * | 2007-01-07 | 2008-07-10 | Robbin Jeffrey L | Data Synchronization with Host Device in Accordance with Synchronization Preferences |
US8631088B2 (en) | 2007-01-07 | 2014-01-14 | Apple Inc. | Prioritized data synchronization with host device |
US10083184B2 (en) * | 2007-01-07 | 2018-09-25 | Apple Inc. | Widget synchronization in accordance with synchronization preferences |
US8050386B2 (en) | 2007-02-12 | 2011-11-01 | Telecommunication Systems, Inc. | Mobile automatic location identification (ALI) for first responders |
US8611542B1 (en) * | 2007-04-26 | 2013-12-17 | Netapp, Inc. | Peer to peer key synchronization |
US8824686B1 (en) * | 2007-04-27 | 2014-09-02 | Netapp, Inc. | Cluster key synchronization |
US8805425B2 (en) | 2007-06-01 | 2014-08-12 | Seven Networks, Inc. | Integrated messaging |
US8693494B2 (en) | 2007-06-01 | 2014-04-08 | Seven Networks, Inc. | Polling |
US20090043867A1 (en) * | 2007-08-06 | 2009-02-12 | Apple Inc. | Synching data |
US8046369B2 (en) | 2007-09-04 | 2011-10-25 | Apple Inc. | Media asset rating system |
US8185087B2 (en) | 2007-09-17 | 2012-05-22 | Telecommunication Systems, Inc. | Emergency 911 data messaging |
US7929530B2 (en) | 2007-11-30 | 2011-04-19 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
US9130963B2 (en) | 2011-04-06 | 2015-09-08 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
US8364181B2 (en) | 2007-12-10 | 2013-01-29 | Seven Networks, Inc. | Electronic-mail filtering for mobile devices |
US9002828B2 (en) | 2007-12-13 | 2015-04-07 | Seven Networks, Inc. | Predictive content delivery |
US8793305B2 (en) | 2007-12-13 | 2014-07-29 | Seven Networks, Inc. | Content delivery to a mobile device from a content service |
US8181111B1 (en) | 2007-12-31 | 2012-05-15 | Synchronoss Technologies, Inc. | System and method for providing social context to digital activity |
US8107921B2 (en) | 2008-01-11 | 2012-01-31 | Seven Networks, Inc. | Mobile virtual network operator |
US8862657B2 (en) | 2008-01-25 | 2014-10-14 | Seven Networks, Inc. | Policy based content service |
US20090193338A1 (en) | 2008-01-28 | 2009-07-30 | Trevor Fiatal | Reducing network and battery consumption during content delivery and playback |
US7747784B2 (en) | 2008-03-04 | 2010-06-29 | Apple Inc. | Data synchronization protocol |
AU2011253726B2 (en) * | 2008-03-04 | 2012-07-26 | Apple Inc. | Synchronization server process |
US7991740B2 (en) * | 2008-03-04 | 2011-08-02 | Apple Inc. | Synchronization server process |
US8787947B2 (en) | 2008-06-18 | 2014-07-22 | Seven Networks, Inc. | Application discovery on mobile devices |
US8078158B2 (en) | 2008-06-26 | 2011-12-13 | Seven Networks, Inc. | Provisioning applications for a mobile device |
US8068587B2 (en) | 2008-08-22 | 2011-11-29 | Telecommunication Systems, Inc. | Nationwide table routing of voice over internet protocol (VOIP) emergency calls |
US8208853B2 (en) | 2008-09-08 | 2012-06-26 | Apple Inc. | Accessory device authentication |
US8238811B2 (en) | 2008-09-08 | 2012-08-07 | Apple Inc. | Cross-transport authentication |
US8112537B2 (en) * | 2008-09-29 | 2012-02-07 | Apple Inc. | Trickle sync protocol |
US7941410B2 (en) * | 2008-09-30 | 2011-05-10 | Microsoft Corporation | Method and system of managing conflicts for a set of synchronized folders |
US8909759B2 (en) | 2008-10-10 | 2014-12-09 | Seven Networks, Inc. | Bandwidth measurement |
EP2347395A4 (en) | 2008-10-14 | 2016-11-02 | Telecomm Systems Inc | Location based proximity alert |
US8892128B2 (en) | 2008-10-14 | 2014-11-18 | Telecommunication Systems, Inc. | Location based geo-reminders |
US9301191B2 (en) | 2013-09-20 | 2016-03-29 | Telecommunication Systems, Inc. | Quality of service to over the top applications used with VPN |
US8867485B2 (en) | 2009-05-05 | 2014-10-21 | Telecommunication Systems, Inc. | Multiple location retrieval function (LRF) network having location continuity |
US8255006B1 (en) | 2009-11-10 | 2012-08-28 | Fusionone, Inc. | Event dependent notification system and method |
US8327029B1 (en) * | 2010-03-12 | 2012-12-04 | The Mathworks, Inc. | Unified software construct representing multiple synchronized hardware systems |
US9043731B2 (en) | 2010-03-30 | 2015-05-26 | Seven Networks, Inc. | 3D mobile user interface with configurable workspace management |
WO2012005769A1 (en) | 2010-07-09 | 2012-01-12 | Telecommunication Systems, Inc. | Location privacy selector |
US8336664B2 (en) | 2010-07-09 | 2012-12-25 | Telecommunication Systems, Inc. | Telematics basic mobile device safety interlock |
CA2806548C (en) | 2010-07-26 | 2015-03-31 | Seven Networks, Inc. | Distributed implementation of dynamic wireless traffic policy |
GB2495066B (en) | 2010-07-26 | 2013-12-18 | Seven Networks Inc | Mobile application traffic optimization |
US8838783B2 (en) | 2010-07-26 | 2014-09-16 | Seven Networks, Inc. | Distributed caching for resource and mobile network traffic management |
CA2806527A1 (en) | 2010-07-26 | 2012-02-09 | Seven Networks, Inc. | Mobile network traffic coordination across multiple applications |
EP2635973A4 (en) | 2010-11-01 | 2014-01-15 | Seven Networks Inc | Caching adapted for mobile application behavior and network conditions |
WO2012060995A2 (en) | 2010-11-01 | 2012-05-10 | Michael Luna | Distributed caching in a wireless network of content delivered for a mobile application over a long-held request |
WO2012060997A2 (en) | 2010-11-01 | 2012-05-10 | Michael Luna | Application and network-based long poll request detection and cacheability assessment therefor |
US8943428B2 (en) | 2010-11-01 | 2015-01-27 | Synchronoss Technologies, Inc. | System for and method of field mapping |
WO2012061430A2 (en) | 2010-11-01 | 2012-05-10 | Michael Luna | Distributed management of keep-alive message signaling for mobile network resource conservation and optimization |
US9060032B2 (en) | 2010-11-01 | 2015-06-16 | Seven Networks, Inc. | Selective data compression by a distributed traffic management system to reduce mobile data traffic and signaling traffic |
US8843153B2 (en) | 2010-11-01 | 2014-09-23 | Seven Networks, Inc. | Mobile traffic categorization and policy for network use optimization while preserving user experience |
US9330196B2 (en) | 2010-11-01 | 2016-05-03 | Seven Networks, Llc | Wireless traffic management system cache optimization using http headers |
US8484314B2 (en) | 2010-11-01 | 2013-07-09 | Seven Networks, Inc. | Distributed caching in a wireless network of content delivered for a mobile application over a long-held request |
US8204953B2 (en) | 2010-11-01 | 2012-06-19 | Seven Networks, Inc. | Distributed system for cache defeat detection and caching of content addressed by identifiers intended to defeat cache |
WO2012071384A2 (en) | 2010-11-22 | 2012-05-31 | Michael Luna | Optimization of resource polling intervals to satisfy mobile device requests |
CA2798523C (en) | 2010-11-22 | 2015-02-24 | Seven Networks, Inc. | Aligning data transfer to optimize connections established for transmission over a wireless network |
US8688087B2 (en) | 2010-12-17 | 2014-04-01 | Telecommunication Systems, Inc. | N-dimensional affinity confluencer |
US8942743B2 (en) | 2010-12-17 | 2015-01-27 | Telecommunication Systems, Inc. | iALERT enhanced alert manager |
WO2012087353A1 (en) | 2010-12-22 | 2012-06-28 | Telecommunication Systems, Inc. | Area event handling when current network does not cover target area |
WO2012094675A2 (en) | 2011-01-07 | 2012-07-12 | Seven Networks, Inc. | System and method for reduction of mobile network traffic used for domain name system (dns) queries |
WO2012141762A1 (en) | 2011-02-25 | 2012-10-18 | Telecommunication Systems, Inc. | Mobile internet protocol (ip) location |
GB2517815A (en) | 2011-04-19 | 2015-03-04 | Seven Networks Inc | Shared resource and virtual resource management in a networked environment |
CN102761567A (en) * | 2011-04-26 | 2012-10-31 | 中国移动通信集团广东有限公司 | Information synchronization method, information synchronization engine and information synchronization agent |
WO2012149221A2 (en) | 2011-04-27 | 2012-11-01 | Seven Networks, Inc. | System and method for making requests on behalf of a mobile device based on atomic processes for mobile network traffic relief |
WO2012149434A2 (en) | 2011-04-27 | 2012-11-01 | Seven Networks, Inc. | Detecting and preserving state for satisfying application requests in a distributed proxy and cache system |
WO2013015995A1 (en) | 2011-07-27 | 2013-01-31 | Seven Networks, Inc. | Automatic generation and distribution of policy information regarding malicious mobile traffic in a wireless network |
US8649806B2 (en) | 2011-09-02 | 2014-02-11 | Telecommunication Systems, Inc. | Aggregate location dynometer (ALD) |
US9479344B2 (en) | 2011-09-16 | 2016-10-25 | Telecommunication Systems, Inc. | Anonymous voice conversation |
WO2013048551A1 (en) | 2011-09-30 | 2013-04-04 | Telecommunication Systems, Inc. | Unique global identifier for minimizing prank 911 calls |
US9313637B2 (en) | 2011-12-05 | 2016-04-12 | Telecommunication Systems, Inc. | Wireless emergency caller profile data delivery over a legacy interface |
US9264537B2 (en) | 2011-12-05 | 2016-02-16 | Telecommunication Systems, Inc. | Special emergency call treatment based on the caller |
EP2789137A4 (en) | 2011-12-06 | 2015-12-02 | Seven Networks Inc | A system of redundantly clustered machines to provide failover mechanisms for mobile traffic management and network resource conservation |
US8934414B2 (en) | 2011-12-06 | 2015-01-13 | Seven Networks, Inc. | Cellular or WiFi mobile traffic optimization based on public or private network destination |
US9277443B2 (en) | 2011-12-07 | 2016-03-01 | Seven Networks, Llc | Radio-awareness of mobile device for sending server-side control signals using a wireless network optimized transport protocol |
WO2013086455A1 (en) | 2011-12-07 | 2013-06-13 | Seven Networks, Inc. | Flexible and dynamic integration schemas of a traffic management system with various network operators for network traffic alleviation |
EP2792188B1 (en) | 2011-12-14 | 2019-03-20 | Seven Networks, LLC | Mobile network reporting and usage analytics system and method using aggregation of data in a distributed traffic optimization system |
WO2013090834A1 (en) | 2011-12-14 | 2013-06-20 | Seven Networks, Inc. | Operation modes for mobile traffic optimization and concurrent management of optimized and non-optimized traffic |
US8861354B2 (en) | 2011-12-14 | 2014-10-14 | Seven Networks, Inc. | Hierarchies and categories for management and deployment of policies for distributed wireless traffic optimization |
US8984591B2 (en) | 2011-12-16 | 2015-03-17 | Telecommunications Systems, Inc. | Authentication via motion of wireless device movement |
WO2013103988A1 (en) | 2012-01-05 | 2013-07-11 | Seven Networks, Inc. | Detection and management of user interactions with foreground applications on a mobile device in distributed caching |
US9384339B2 (en) | 2012-01-13 | 2016-07-05 | Telecommunication Systems, Inc. | Authenticating cloud computing enabling secure services |
WO2013116856A1 (en) | 2012-02-02 | 2013-08-08 | Seven Networks, Inc. | Dynamic categorization of applications for network access in a mobile network |
WO2013116852A1 (en) | 2012-02-03 | 2013-08-08 | Seven Networks, Inc. | User as an end point for profiling and optimizing the delivery of content and data in a wireless network |
US8688174B2 (en) | 2012-03-13 | 2014-04-01 | Telecommunication Systems, Inc. | Integrated, detachable ear bud device for a wireless phone |
US9544260B2 (en) | 2012-03-26 | 2017-01-10 | Telecommunication Systems, Inc. | Rapid assignment dynamic ownership queue |
US9307372B2 (en) | 2012-03-26 | 2016-04-05 | Telecommunication Systems, Inc. | No responders online |
US8812695B2 (en) | 2012-04-09 | 2014-08-19 | Seven Networks, Inc. | Method and system for management of a virtual network connection without heartbeat messages |
US10263899B2 (en) | 2012-04-10 | 2019-04-16 | Seven Networks, Llc | Enhanced customer service for mobile carriers using real-time and historical mobile application and traffic or optimization data associated with mobile devices in a mobile network |
US9338153B2 (en) | 2012-04-11 | 2016-05-10 | Telecommunication Systems, Inc. | Secure distribution of non-privileged authentication credentials |
US9116971B2 (en) | 2012-05-08 | 2015-08-25 | Softframe, Inc. | Data synchronization using a composite change clock |
US9411783B2 (en) | 2012-07-12 | 2016-08-09 | Adobe Systems Incorporated | Method and apparatus for selective synchronization of a display layout |
WO2014011216A1 (en) | 2012-07-13 | 2014-01-16 | Seven Networks, Inc. | Dynamic bandwidth adjustment for browsing or streaming activity in a wireless network based on prediction of user behavior when interacting with mobile applications |
WO2014028712A1 (en) | 2012-08-15 | 2014-02-20 | Telecommunication Systems, Inc. | Device independent caller data access for emergency calls |
US9208346B2 (en) | 2012-09-05 | 2015-12-08 | Telecommunication Systems, Inc. | Persona-notitia intellection codifier |
US9161258B2 (en) | 2012-10-24 | 2015-10-13 | Seven Networks, Llc | Optimized and selective management of policy deployment to mobile clients in a congested network to prevent further aggravation of network congestion |
US9456301B2 (en) | 2012-12-11 | 2016-09-27 | Telecommunication Systems, Inc. | Efficient prisoner tracking |
US20140177497A1 (en) | 2012-12-20 | 2014-06-26 | Seven Networks, Inc. | Management of mobile device radio state promotion and demotion |
US9271238B2 (en) | 2013-01-23 | 2016-02-23 | Seven Networks, Llc | Application or context aware fast dormancy |
US8874761B2 (en) | 2013-01-25 | 2014-10-28 | Seven Networks, Inc. | Signaling optimization in a wireless network for traffic utilizing proprietary and non-proprietary protocols |
US8750123B1 (en) | 2013-03-11 | 2014-06-10 | Seven Networks, Inc. | Mobile device equipped with mobile network congestion recognition to make intelligent decisions regarding connecting to an operator network |
US8983047B2 (en) | 2013-03-20 | 2015-03-17 | Telecommunication Systems, Inc. | Index of suspicion determination for communications request |
US9015062B2 (en) * | 2013-06-20 | 2015-04-21 | Aol Advertising Inc. | Systems and methods for cross-browser advertising ID synchronization |
US9065765B2 (en) | 2013-07-22 | 2015-06-23 | Seven Networks, Inc. | Proxy server associated with a mobile carrier for enhancing mobile traffic management in a mobile network |
US9408034B2 (en) | 2013-09-09 | 2016-08-02 | Telecommunication Systems, Inc. | Extended area event for network based proximity discovery |
US9516104B2 (en) | 2013-09-11 | 2016-12-06 | Telecommunication Systems, Inc. | Intelligent load balancer enhanced routing |
US9479897B2 (en) | 2013-10-03 | 2016-10-25 | Telecommunication Systems, Inc. | SUPL-WiFi access point controller location based services for WiFi enabled mobile devices |
US10417254B2 (en) * | 2016-02-01 | 2019-09-17 | Vmware, Inc. | Intelligent content synchronization between content libraries |
US10783929B2 (en) | 2018-03-30 | 2020-09-22 | Apple Inc. | Managing playback groups |
US11297369B2 (en) | 2018-03-30 | 2022-04-05 | Apple Inc. | Remotely controlling playback devices |
US10993274B2 (en) | 2018-03-30 | 2021-04-27 | Apple Inc. | Pairing devices by proxy |
US10614857B2 (en) | 2018-07-02 | 2020-04-07 | Apple Inc. | Calibrating media playback channels for synchronized presentation |
CN116319835B (en) * | 2023-05-10 | 2023-08-25 | 鹏城实验室 | Data synchronization method, device, equipment and storage medium based on federal range |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5897640A (en) * | 1994-08-08 | 1999-04-27 | Microsoft Corporation | Method and system of associating, synchronizing and reconciling computer files in an operating system |
US5974238A (en) * | 1996-08-07 | 1999-10-26 | Compaq Computer Corporation | Automatic data synchronization between a handheld and a host computer using pseudo cache including tags and logical data elements |
US5884325A (en) * | 1996-10-09 | 1999-03-16 | Oracle Corporation | System for synchronizing shared data between computers |
US6006274A (en) * | 1997-01-30 | 1999-12-21 | 3Com Corporation | Method and apparatus using a pass through personal computer connected to both a local communication link and a computer network for indentifying and synchronizing a preferred computer with a portable computer |
-
1999
- 1999-04-06 US US09/287,546 patent/US6247135B1/en not_active Expired - Lifetime
-
2001
- 2001-06-08 US US09/877,553 patent/US20010039629A1/en not_active Abandoned
Cited By (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7072911B1 (en) * | 2001-07-27 | 2006-07-04 | Novell, Inc. | System and method for incremental replication of changes in a state based distributed database |
US7149725B2 (en) * | 2001-09-21 | 2006-12-12 | Hewlett-Packard Development Company, L.P. | Apparatus and method of communicating changes in states of contractual responsibilities |
US20040024683A1 (en) * | 2001-09-21 | 2004-02-05 | Michal Morciniec | Apparatus and method of communicating changes in states of contractual responsibilities |
WO2006115521A1 (en) * | 2005-04-22 | 2006-11-02 | Microsoft Corporation | System and method for peer to peer synchronization of files |
US20070150895A1 (en) * | 2005-12-06 | 2007-06-28 | Kurland Aaron S | Methods and apparatus for multi-core processing with dedicated thread management |
US20110087792A2 (en) * | 2006-02-07 | 2011-04-14 | Dot Hill Systems Corporation | Data replication method and apparatus |
US20070186001A1 (en) * | 2006-02-07 | 2007-08-09 | Dot Hill Systems Corp. | Data replication method and apparatus |
US20070185973A1 (en) * | 2006-02-07 | 2007-08-09 | Dot Hill Systems, Corp. | Pull data replication model |
US20110072104A2 (en) * | 2006-02-07 | 2011-03-24 | Dot Hill Systems Corporation | Pull data replication model |
US8990153B2 (en) | 2006-02-07 | 2015-03-24 | Dot Hill Systems Corporation | Pull data replication model |
US20090327568A1 (en) * | 2006-02-07 | 2009-12-31 | Dot Hill Systems Corporation | Data Replication method and apparatus |
US7783850B2 (en) | 2006-03-28 | 2010-08-24 | Dot Hill Systems Corporation | Method and apparatus for master volume access during volume copy |
US20080072003A1 (en) * | 2006-03-28 | 2008-03-20 | Dot Hill Systems Corp. | Method and apparatus for master volume access during colume copy |
US7831565B2 (en) | 2007-01-18 | 2010-11-09 | Dot Hill Systems Corporation | Deletion of rollback snapshot partition |
US20080177954A1 (en) * | 2007-01-18 | 2008-07-24 | Dot Hill Systems Corp. | Method and apparatus for quickly accessing backing store metadata |
US20080177957A1 (en) * | 2007-01-18 | 2008-07-24 | Dot Hill Systems Corp. | Deletion of rollback snapshot partition |
US8751467B2 (en) | 2007-01-18 | 2014-06-10 | Dot Hill Systems Corporation | Method and apparatus for quickly accessing backing store metadata |
US8656123B2 (en) | 2007-04-11 | 2014-02-18 | Dot Hill Systems Corporation | Snapshot preserved data cloning |
US20090307450A1 (en) * | 2007-04-11 | 2009-12-10 | Dot Hill Systems Corporation | Snapshot Preserved Data Cloning |
US7716183B2 (en) | 2007-04-11 | 2010-05-11 | Dot Hill Systems Corporation | Snapshot preserved data cloning |
US7975115B2 (en) | 2007-04-11 | 2011-07-05 | Dot Hill Systems Corporation | Method and apparatus for separating snapshot preserved and write data |
US20080256141A1 (en) * | 2007-04-11 | 2008-10-16 | Dot Hill Systems Corp. | Method and apparatus for separating snapshot preserved and write data |
US20080256311A1 (en) * | 2007-04-11 | 2008-10-16 | Dot Hill Systems Corp. | Snapshot preserved data cloning |
US8001345B2 (en) | 2007-05-10 | 2011-08-16 | Dot Hill Systems Corporation | Automatic triggering of backing store re-initialization |
US20080281875A1 (en) * | 2007-05-10 | 2008-11-13 | Dot Hill Systems Corp. | Automatic triggering of backing store re-initialization |
US20080281877A1 (en) * | 2007-05-10 | 2008-11-13 | Dot Hill Systems Corp. | Backing store re-initialization method and apparatus |
US7783603B2 (en) | 2007-05-10 | 2010-08-24 | Dot Hill Systems Corporation | Backing store re-initialization method and apparatus |
US20100172454A1 (en) * | 2007-06-13 | 2010-07-08 | Koninklijke Philips Electronics N.V. | Synchronization protocol |
US8666008B2 (en) * | 2007-06-13 | 2014-03-04 | Koninklijke Philips N.V. | Synchronization protocol |
US20080320258A1 (en) * | 2007-06-25 | 2008-12-25 | Dot Hill Systems Corp. | Snapshot reset method and apparatus |
US8200631B2 (en) | 2007-06-25 | 2012-06-12 | Dot Hill Systems Corporation | Snapshot reset method and apparatus |
US8204858B2 (en) | 2007-06-25 | 2012-06-19 | Dot Hill Systems Corporation | Snapshot reset method and apparatus |
US20090119349A1 (en) * | 2007-11-07 | 2009-05-07 | International Business Machines Corporation | Methods and Computer Program Products for Efficient Conflict Detection in a Replicated Hierarchical Content Repository Using Replication Anchors |
EP2204964A4 (en) * | 2007-12-12 | 2011-04-13 | Huawei Tech Co Ltd | Method and device for realizing data synchronization |
US20100241764A1 (en) * | 2007-12-12 | 2010-09-23 | Huawei Technologies Co., Ltd. | Method and apparatus for synchronizing data |
EP2204964A1 (en) * | 2007-12-12 | 2010-07-07 | Huawei Technologies Co., Ltd. | Method and device for realizing data synchronization |
US20150269217A1 (en) * | 2008-07-22 | 2015-09-24 | International Business Machines Corporation | Embedded change logging for data synchronization |
US9495407B2 (en) * | 2008-07-22 | 2016-11-15 | International Business Machines Corporation | Embedded change logging for data synchronization |
US20100100590A1 (en) * | 2008-10-21 | 2010-04-22 | Palay Andrew J | Always ready client/server data synchronization |
US8965954B2 (en) | 2008-10-21 | 2015-02-24 | Google Inc. | Always ready client/server data synchronization |
WO2010048329A1 (en) * | 2008-10-21 | 2010-04-29 | Google Inc. | Search based specification for data synchronization |
US9367599B2 (en) | 2008-10-21 | 2016-06-14 | Google Inc. | Search based specification for data synchronization |
EP3318992A1 (en) * | 2008-10-21 | 2018-05-09 | Google LLC | Search based specification for data synchronization |
US20110078332A1 (en) * | 2009-09-25 | 2011-03-31 | Poon Roger J | Method of synchronizing information across multiple computing devices |
Also Published As
Publication number | Publication date |
---|---|
US6247135B1 (en) | 2001-06-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6247135B1 (en) | Synchronization process negotiation for computing devices | |
US6275831B1 (en) | Data processing environment with methods providing contemporaneous synchronization of two or more clients | |
US7792794B2 (en) | N-way synchronization of computer databases | |
US6625621B2 (en) | System and methods for a fast and scalable synchronization server | |
US7707175B1 (en) | Single ended synchronization agents | |
US8255359B2 (en) | System and methods for asynchronous synchronization | |
US7269664B2 (en) | Network portal system and methods | |
US6393434B1 (en) | Method and system for synchronizing data using fine-grained synchronization plans | |
US6477545B1 (en) | System and methods for robust synchronization of datasets | |
KR100343823B1 (en) | Method, Apparatus and Program Storage Device for a Client and Adaptive Synchronization and Transformation Server | |
US6449622B1 (en) | System and methods for synchronizing datasets when dataset changes may be received out of order | |
US20070190978A1 (en) | System and Methodology for Extending Enterprise Messaging Systems to Mobile Devices | |
US20020156798A1 (en) | System and methods for synchronizing datasets using version indicators to detect obsolete changes | |
US20020133535A1 (en) | Identity-centric data access | |
JP2005535947A (en) | System and method for accessing different types of back-end data stores | |
US20050050142A1 (en) | Method and framework for transaction synchronization | |
US8521875B2 (en) | Identity for data sources | |
Almeida et al. | Getting started with data warehouse and business intelligence | |
US7613835B2 (en) | Generic API for synchronization | |
WO2004023345A1 (en) | System and method for dynamically mapping dynamic multi-sourced persisted ejbs | |
CN101610225B (en) | Method, system and device for synchronous processing | |
US6948001B1 (en) | Modular software method for independent storage nodes | |
Carreton et al. | Software abstractions for mobile RFID‐enabled applications | |
JP5157551B2 (en) | Object linkage system, object linkage method and program | |
JP2003006394A (en) | Computer for cooperating workflow and computer system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: STARFISH SOFTWARE, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FEAGUE, ROY W.;REEL/FRAME:012043/0691 Effective date: 20010731 |
|
STCB | Information on status: application discontinuation |
Free format text: EXPRESSLY ABANDONED -- DURING EXAMINATION |