Abstract: A system and method is described for resolving a conflict detected while synchronizing a first data object in a first store associated with a mobile device and a second data object in a second store associated with a server. Once the conflict is detected, properties of the first data object are compared with corresponding properties of the second data object. If the properties and the corresponding properties that differ are designated as mergeable properties, the properties and the corresponding properties are merged. Merging the properties involves sending a preferred state associated with each of the properties and the corresponding properties to the mobile device and the server for updating the first data object and second data object, respectively, when an initial state for the properties and the corresponding properties is different than the preferred state.

Abstract: Systems, methods, and computer program products for deleting objects from device stores without deleting corresponding objects from one or more synchronization partners. A device has a device sync module for each synchronization partner and each device sync module maintains tracking data. Alternatively, a single device sync module manages the tracking data of each synchronization partner. When an object does not meet parameters of a synchronization filter, a soft delete request is made to the wireless device. A sync manager receives the soft delete request and determines from the other device sync modules that have registered with the sync manager whether they continue to synchronize the object. If none of the other device sync modules protest, the object is deleted. If one of the device sync modules objects to the delete request, then the delete is denied. The tracking data for all of the device sync modules is appropriately modified.

Abstract: A method and system for synchronization of data stores is described. A synchronization initiator sends a sync key to a synchronization partner requesting to synchronize to some checkpoint. An integer is used as the sync key. When the sent sync key is zero the synchronization partner performs an initial synchronization. When the sent sync key is a value other than zero, the synchronization partner attempts to synchronize to the desired state. The value of the sync key is incremented only upon successful synchronization. A sync server can also include a sync key with change update notifications sent to a sync client, which the client can use to determine if the update notification is a valid update from the current sync state or is a delayed and obsolete update that should be discarded.

Abstract: A protocol for synchronizing data is provided. Additionally, a system and method of using the protocol are also provided. The protocol allows responses to be grouped with commands in a single XML document. It provides a command for requesting a single object be sent without requiring that all unsynchronized objects be sent. It provides a command for specifying how many objects at a time should be sent and a response that indicates that more objects are available to be sent. It provides a means for arbitrarily extending the protocol in application-specific ways. It provides a means for sending updates while requesting that no updates be sent back.

Abstract: A system and method is described for recovering from a failed synchronization session between a first data store and a second data store. Once a failed synchronization session is detected, a synchronization recovery process is performed. The synchronization recovery process includes creating an update manifest based on a sync request and on a synchronization state table. The synchronization state table is updated for each sync request initiating a synchronization session, whether the synchronization session succeeded or failed. The update manifest may include one or more objects and an update action associated with each of the objects. The update action may be identical to a current action specified in the sync request for the object, identical to a last action stored in the synchronization state table for the object, or different from both the current action and the last action. In general, the update action minimizes the likelihood of duplicate objects.

Abstract: Systems, methods, and computer program products for deleting objects from device stores without deleting corresponding objects from one or more synchronization partners. A device has a device sync module for each synchronization partner and each device sync module maintains tracking data. Alternatively, a single device sync module manages the tracking data of each synchronization partner. When an object does not meet parameters of a synchronization filter, a soft delete request is made to the wireless device. A sync manager receives the soft delete request and determines from the other device sync modules that have registered with the sync manager whether they continue to synchronize the object. If none of the other device sync modules protest, the object is deleted. If one of the device sync modules objects to the delete request, then the delete is denied. The tracking data for all of the device sync modules is appropriately modified.

Abstract: A system and method is described for resolving a conflict detected while synchronizing a first data object in a first store associated with a mobile device and a second data object in a second store associated with a server. Once the conflict is detected, properties of the first data object are compared with corresponding properties of the second data object. If the properties and the corresponding properties that differ are designated as mergeable properties, the properties and the corresponding properties are merged. Merging the properties involves sending a preferred state associated with each of the properties and the corresponding properties to the mobile device and the server for updating the first data object and second data object, respectively, when an initial state for the properties and the corresponding properties is different than the preferred state.

Abstract: Systems and methods for synchronizing a device and for ensuring that updates to the device occurring during synchronization are not re-synchronized to the synchronization partner. Generation identifiers (GIDs), which are updated each time a synchronization occurs, are assigned to objects in a store. When synchronization occurs, a sync client uses state information, which is used to indicate which generations have been synchronized, to determine which objects have changed since the last synchronization. The state information includes reserved write GIDs that are only used by a particular sync client that performs writes during a synchronization. Objects having a GID that matches a write GID are not synchronized because they were written by the sync client during the previous synchronization.

Abstract: A method and system for synchronization of data stores is described. A synchronization initiator sends a sync key to a synchronization partner requesting to synchronize to some checkpoint. An integer is used as the sync key. When the sent sync key is zero the synchronization partner performs an initial synchronization. When the sent sync key is a value other than zero, the synchronization partner attempts to synchronize to the desired state. The value of the sync key is incremented only upon successful synchronization. A sync server can also include a sync key with change update notifications sent to a sync client, which the client can use to determine if the update notification is a valid update from the current sync state or is a delayed and obsolete update that should be discarded.

Abstract: A system and method is described for translating events originally identified as “change” events in one replication protocol to “add” events in another replication protocol where appropriate. More particularly, a WebDAV-based system interacts with a non-WebDAV based system. On a first replication transaction between the two systems, a sync state table is created on an intermediate server or a server that facilitates communication between the two systems. The sync state table is linked to the non-WebDAV system for future replication transactions. The sync state table maintains a list of objects that have been sent to the non-WebDAV system in past replication transactions. Thereafter, for each replication transaction, a manifest of changes since the last replication transaction is transmitted from the WebDAV system to the intermediate server. The manifest includes information in accordance with the WebDAV protocol, i.e. without notice of “add” events.

Abstract: A method and system for processing notifications is described. Notifications are tagged based on a synchronization state between the sender and receiver of the notification. The receiver processes the tagged notification based on a comparison between the tagged value and the current state of its synchronization with respect to the sender of the notification. When the tagged value is current with respect to the current synchronization value and a synchronization is not in process, the notification is processed. When the tagged value is stale with respect to the current synchronization state the notification is discarded. If the notification is out-of-date with respect to the current state of synchronization the notification may be queued for later processing or discarded.

Abstract: Systems and methods for synchronizing a device and for ensuring that updates to the device occurring during synchronization are not re-synchronized to the synchronization partner. Generation identifiers (GIDs), which are updated each time a synchronization occurs, are assigned to objects in a store. When synchronization occurs, a sync client uses state information, which is used to indicate which generations have been synchronized, to determine which objects have changed since the last synchronization. The state information includes reserved write GIDs that are only used by a particular sync client that performs writes during a synchronization. Objects having a GID that matches a write GID are not synchronized because they were written by the sync client during the previous synchronization.

Abstract: Systems and methods for synchronizing a device and for ensuring that updates to the device occurring during synchronization are not re-synchronized to the synchronization partner. Generation identifiers (GIDs), which are updated each time a synchronization occurs, are assigned to objects in a store. When synchronization occurs, a sync client uses state information, which is used to indicate which generations have been synchronized, to determine which objects have changed since the last synchronization. The state information includes reserved write GIDs that are only used by a particular sync client that performs writes during a synchronization. Objects having a GID that matches a write GID are not synchronized because they were written by the sync client during the previous synchronization.

Abstract: An application program is configured to communicate with a particular type of peripheral through a computer serial port. During times when no device is connected, the application program monitors the serial port to detect when a new device is connected. The application program then determines whether the peripheral of the type with which the application program is designed to communicate. If it is not, the application program displays a prompt, offering to relinquish the serial port for use by another program.

Abstract: A system and method is described for resolving a conflict detected while synchronizing a first data object in a first store associated with a mobile device and a second data object in a second store associated with a server. Once the conflict is detected, properties of the first data object are compared with corresponding properties of the second data object. If the properties and the corresponding properties that differ are designated as mergeable properties, the properties and the corresponding properties are merged. Merging the properties involves sending a preferred state associated with each of the properties and the corresponding properties to the mobile device and the server for updating the first data object and second data object, respectively, when an initial state for the properties and the corresponding properties is different than the preferred state.

Abstract: A protocol for synchronizing data is provided. Additionally, a system and method of using the protocol are also provided. The protocol allows responses to be grouped with commands in a single XML document. It provides a command for requesting a single object be sent without requiring that all unsynchronized objects be sent. It provides a command for specifying how many objects at a time should be sent and a response that indicates that more objects are available to be sent. It provides a means for arbitrarily extending the protocol in application-specific ways. It provides a means for sending updates while requesting that no updates be sent back.

Abstract: A method and system for processing notifications is described. Notifications are tagged based on a synchronization state between the sender and receiver of the notification. The receiver processes the tagged notification based on a comparison between the tagged value and the current state of its synchronization with respect to the sender of the notification. When the tagged value is current with respect to the current synchronization value and a synchronization is not in process, the notification is processed. When the tagged value is stale with respect to the current synchronization state the notification is discarded. If the notification is out-of-date with respect to the current state of synchronization the notification may be queued for later processing or discarded.

Abstract: A method and system for synchronization of data stores is described. A synchronization initiator sends a sync key to a synchronization partner requesting to synchronize to some checkpoint. An integer is used as the sync key. When the sent sync key is zero the synchronization partner performs an initial synchronization. When the sent sync key is a value other than zero, the synchronization partner attempts to synchronize to the desired state. The value of the sync key is incremented only upon successful synchronization. A sync server can also include a sync key with change update notifications sent to a sync client, which the client can use to determine if the update notification is a valid update from the current sync state or is a delayed and obsolete update that should be discarded.

Abstract: A system and method is described for recovering from a failed synchronization session between a first data store and a second data store. Once a failed synchronization session is detected, a synchronization recovery process is performed. The synchronization recovery process includes creating an update manifest based on a sync request and on a synchronization state table. The synchronization state table is updated for each sync request initiating a synchronization session, whether the synchronization session succeeded or failed. The update manifest may include one or more objects and an update action associated with each of the objects. The update action may be identical to a current action specified in the sync request for the object, identical to a last action stored in the synchronization state table for the object, or different from both the current action and the last action. In general, the update action minimizes the likelihood of duplicate objects.

Abstract: A system and method is described for translating events originally identified as “change” events in one replication protocol to “add” events in another replication protocol where appropriate. More particularly, a WebDAV-based system interacts with a non-WebDAV based system. On a first replication transaction between the two systems, a sync state table is created on an intermediate server or a server that facilitates communication between the two systems. The sync state table is linked to the non-WebDAV system for future replication transactions. The sync state table maintains a list of objects that have been sent to the non-WebDAV system in past replication transactions. Thereafter, for each replication transaction, a manifest of changes since the last replication transaction is transmitted from the WebDAV system to the intermediate server. The manifest includes information in accordance with the WebDAV protocol, i.e. without notice of “add” events.