object stores are used as building blocks to construct a system with variable complexity on a network. Typically, an object store comprises information (e.g., data) stored in object format, or objects. The objects and object stores are managed by an object version management mechanism that adapts to different object store types and optimizes resource consumption by each object store. Various data fields are used to indicate an object's version within an object store. version information is used to compare the states among matching object replicas in matching object stores. Utilizing both the object store based system and the object version management mechanism, a data synchronization protocol is developed. The data synchronization protocol is capable of adapting to different types of object stores and the characteristics of network connection media to optimize data synchronization.
|
1. A method for facilitating data synchronization, comprising the steps of:
(a) obtaining a list of encoding methods from a remote object store;
(b) extracting a first set of objects to be synchronized with said remote object store;
(c) packing said first set of objects, their associated identifiers and synchronization versions into a request synchronization message;
(d) sending said request synchronization message to said remote object store;
(e) receiving a response synchronization message from said remote object store, said response synchronization message indicating a number of updated objects at the remote object store; and
(f) resetting a corresponding set of synchronization versions to said updated objects.
5. A computer program product for facilitating data synchronization, comprising:
(a) logic code for obtaining a list of encoding methods from a remote object store;
(b) logic code for extracting a first set of objects to be synchronized with said remote object store;
(c) logic code for packing said first set of objects, their associated identifiers and synchronization versions into a request synchronization message;
(d) logic code for sending said request synchronization message to said remote object store;
(e) logic code for receiving a response synchronization message from said remote object store, said response synchronization message indicating a number of updated objects at the remote object store; and
(f) logic code for resetting a corresponding set of synchronization versions to said updated objects.
2. The method of
(1) checking object store replica information corresponding to said remote object store;
(2) sending a request message to said remote object store if any information is missing from said object store replica information;
(3) receiving a response from said remote object store; and
(4) registering said response in said object store replica information.
3. The method of
(1) updating objects based on said request synchronization message at said remote object store; and
(2) sending a response synchronization message providing a number of objects received and processed.
4. The method of
adding a field in said request synchronization message indicating whether said request synchronization message is a last request to said remote object store.
6. The computer program product of
(1) logic code for checking object store replica information corresponding to said remote object store;
(2) logic code for sending a request message to said remote object store if any information is missing from said object store replica information;
(3) logic code for receiving a response from said remote object store; and
(4) logic code for registering said response in said abject store replica information.
7. The computer program product of
(1) logic code for updating objects based on said request synchronization message at said remote object store; and
(2) logic code for sending a response synchronization message providing a number of objects received and processed.
8. The computer program product of
logic code for adding a field in said request synchronization message indicating whether said request synchronization message is a last request to said remote object store.
|
|||||||||||||||||||||||||||||||
This application claims priority to the provisional application entitled “Data Synchronization System Modeling and Optimization for Support of Disconnected Operation and High Data Availability,” filed on Feb. 2, 2000, bearing the ser. No. 60/179,761.
This application is also related to applications entitled “Apparatus and Methods for Optimizing Traffic Volume in Wireless Email Communications,” “Apparatus And Methods For Providing Coordinated And Personalized Application And Data Management For Resource-limited Mobile Devices,” and “Apparatus and Methods for Providing Personalized Application Search Results for Wireless Devices Based on User Profiles,” bearing Ser. Nos. 09/776,165, 09/776,594, and 09/776,593, respectively. These applications were filed on Feb. 1, 2001 and all claimed priority to the above provisional application bearing Ser. No. 60/179,761.
This invention relates to apparatus and methods for providing data synchronization. In particular, this invention relates apparatus and methods for providing data synchronization on a mobile device system.
Computer devices connected by a network are typically capable of sharing information. In a world wide network, such as the Internet, client computers or devices connected to the network are capable of accessing information stored in virtually any server computers connected to the network. Similarly, in a private network, such as an intranet, a computer connected to the network is typically capable of accessing information stored in other computers also connected to the network. Typically, fast access to data requires that the data be stored locally in a storage medium. For example, data can be stored in a hard drive, a computer disk, an IC/smart card, a re-writeable ROM, or a non-volatile RAM. Different data formats and management schemes may be employed by each of the storage media described above. For example, a database system, such as the Oracle 8 database system by Oracle, may be used to store data in relational tables or object tables.
As more resources are invested to construct mission-critical applications and services using theses networks, many enterprises can no longer risk possible failure that may occur in their networks. One way to protect losses resulting from network failure is to use redundant servers. Connection paths from end devices to the redundant servers are established to improve data availability. To be effective, however, the redundant servers require efficient data synchronization and data consistency maintenance to ensure data integrity and data availability. Further, an efficient data synchronization process has to be compatible across all platforms, operating systems, data formats, application supporting tools, and networks.
Thus, it is desirable to provide apparatus and methods for providing data synchronization in mobile device systems that overcome the above problems.
Object stores are used as building blocks to construct a system with variable complexity on a network. An object store is a software mechanism that is used to control data replication, synchronization, and maintain data persistence/consistency on a device. Typically, an object store comprises information (e.g., data) stored in object format, or objects. These objects can be replicated, compared, and updated quickly among different locations in the network. The objects and object stores are managed by an object version management mechanism that adapts to different object store types and optimizes resource consumption by each object store. In an exemplary embodiment, data fields, such as dirty bits, update sequence numbers, and/or version vectors, are used to indicate an object's version within an object store. Further, such version information is used to compare the states among matching object replicas in matching object stores. Utilizing both the object store based system and the object version management mechanism, a data synchronization protocol is developed. The data synchronization protocol is capable of adapting to different types of object stores and the characteristics of network connection media to optimize data synchronization. In an exemplary embodiment, the data synchronization protocol can be set on top of the HTTP, SMTP, TCP/IP, or other Internet protocols in a protocol stack and can support both synchronous and asynchronous modes of synchronization.
System structures that benefit from this invention include: primitive systems (i.e., one-to-one systems, client-server systems, and peer-to-peer systems) and multi-tier hierarchical systems/star-structured systems (i.e., systems that comprise of a combination of one or more of the primitive systems).
In general, there are three types of relational systems (or primitive systems) between devices, namely, the one-to-one system, the client-server system, and the peer-to-peer system. In a typical network, one or more of the primitive systems are involved.
Exemplary basic object stores include one-to-one object stores (each object store belongs to a one-to-one system and synchronizes with only one remote object store), client object stores (each object store belongs to a client-server system and synchronizes with only one remote object store serving as the server), server object stores (each object store belongs to a client-server system and synchronizes with all remote object stores acting as its client), peer-to-peer object stores (each object store belongs to a peer-to-peer system and synchronizes with all remote object stores acting as its peers), and read-only object stores (each object store allows applications to read objects and retrieves updates from one or more remote object stores).
Exemplary joint object stores include one-to-one to one-to-one object stores (each object store belongs to and joins two one-to-one systems), one-to-one to client object stores (each object store belongs to and joins a one-to-one system and a client-server system as a client in the client-server system), one-to-one to peer-to-peer object stores (each object store belongs to and joins a one-to-one system and a peer-to-peer system), client to client object stores (each object store belongs to and joins two client-server system as the client in both systems), client to server object stores (each object store belongs to and joins two client-server systems as a client in one system and a server in the other system), client to peer-to-peer object stores (each object store belongs to and joins a client-server system and a peer-to-peer system as a client at the client-server system), server to peer-to-peer object stores (each object store belongs to and joins a client-server system and a peer-to-peer system as a server in the client-server system), peer-to-peer to peer-to-peer object stores (each object store belongs to and joins two peer-to-peer systems), and generic joint object stores (each object store belongs to and links three or more primitive systems).
Generally, each object store has a unique name that is used for identification. Objects in an object store typically form a hierarchy. In one embodiment, at the root of the hierarchy is an object that declares three basic synchronization methods: setTo, reconcile, and reconcileWithDelete methods. These methods are called in turn during a data synchronization process. In an exemplary embodiment, the setTo method is called on a local object when a remote replica object of the local object is located and the remote replica object is more recently updated than the local object. The reconcile method is called on a local object when the remote replica object has an update conflict with data in the local object. The reconcileWithDelete method is called on a local object when the local object is updated and the remote replica object is deleted. In one embodiment, the reconcileWithDelete method is called on a replica object when the replica object is updated and the local object is deleted.
In an exemplary embodiment, an object store allows applications to insert, update, delete, or retrieve its objects among a set of distributed devices at the same time. In one embodiment, an object store also provides standard interfaces for transaction processing, remote replica registration, data synchronization, and storage media flush. Each device may have a replica of multiple object stores. Due to the possible number of data formats and management schemes among database systems, an interface between the database system and the object stores is used to map data between systems. In an exemplary embodiment, the interface may also support referential integrity, multi-thread transaction processing, and data locking.
In an exemplary embodiment, an object store is opened in one of two modes: shared access or exclusive access. In the shared access mode, multiple applications can open the same object store at the same time. In one embodiment, when multiple applications open an object store at the same time, each application is provided a unique handle. All handles of the same object store share the same set of objects located in the same memory space. In the exclusive access mode, as the name suggests, only one application can open an object store at a time; other applications attempting to open the same object store need to wait until the first application exits the object store before access is granted in sequence.
If a device is opening an object store for the first time, an empty object store is created and saved to the storage medium on the device. An empty object store is populated by different ways. In one embodiment, a local application on the device accessing the object store generates new objects and inserts them into the empty object store. In another embodiment, a subset or all of the objects in a corresponding object store on a remote device is replicated and placed into the empty object store.
A sync version is a meta object that is used to characterize an object's state relative to all other replica objects in a system. An object store and objects in the object store can both be associated to each other with one or more sync versions. Sync versions are created, updated, or deleted by object stores and such processes are transparent to the applications accessing the object stores. A sync version associated with an object indicates the object's state relative to replicas of the same object in a system. A sync version associated with an object store indicates the collective state of all the objects in the object store relative to all replicas of the object store in a system.
In an exemplary embodiment, a sync version can be implemented in one of three ways: dirty bit, update sequence number, and version vector. A dirty bit is a single bit that indicates whether an associated object is in a different state than the object's replica at another object store. When a dirty bit is set on, its associated object is assumed to be different than the object's remote replica. When a dirty bit is set off, its associated object is assumed to be the same as the object's remote replica. In an exemplary embodiment, a dirty bit is used only for object stores that synchronize with at most one remote object store replica.
An update sequence number is an integer that increments with time. Typically, update sequence numbers are generated by a central server and distributed to the central server's clients. An update sequence number associated with an object is used to compare an object replica to the object and to other replicas to determine the age of the object replica relative to the object and to the other replicas.
A version vector is a vector of a pair of indicators: replica-ID and time stamp. The replica-ID identifies an object store replica in a system. The time stamp is typically generated by an object store replica to indicate the last known time (not necessarily the actual last time) that the object store replica has updated at least one of its objects. A version vector is a variable length vector. Each version vector includes indicator pairs that correspond to the object store replicas that are known to have performed one update to at least one object associated with that object store replica. An exemplary management process for managing all objects of an object store is described below.
An object store typically has one or more remote object stores connected to it. To facilitate data synchronization between object stores, an object store creates and maintains an object store replica information object for each of its remote object stores. An object store replica information object that corresponds to a remote object store includes common fields, such as update data format(s) acceptable to the remote object store and a filter for determining the objects contained in the remote object store and non-common fields that are specific to each object store type. An object store is typically able to recognize and accept a set of update data formats. The types and names of the set of acceptable update data formats are generally predetermined and agreed upon among a set of object stores.
In a one-to-one object store, the sync version associated with each object in the object store is a dirty bit. Further, only one remote object store among the one-to-one object store, one-to-one to one-to-one object store, one-to-one to client object store, one-to-one to peer-to-peer object store, and generic joint object store can be registered as its replica. In a one-to-one object store, the store sync version (a dirty bit) is on if any of the sync versions (dirty bits) of the objects contained in the object store is on. The store sync version is off when the sync versions of all objects contained in the object store are off.
In a client object store, the sync version associated with each object in the object store is a combination of a dirty bit and an update sequence number. The update sequence number represents the version of an object when the client object store last synchronized with its server and the dirty bit indicates whether the object has been updated in the client object store since the last synchronization. Further, only one remote object store among the server object store, client to server object store, server to peer-to-peer object store, and generic joint object store can be registered as its replica. In a client object store, the dirty bit of the store version (a combination of dirty bit and update sequence number) is on if the sync version (a combination of dirty bit and update sequence number) of any of the objects contained in the object store is on. The dirty bit of the store sync version is off when the dirty bits of the sync versions of all objects contained in the object store are off. The update sequence number of the store version is equal to the greatest value of all the update sequence numbers of the sync versions of the objects contained in the object store.
In a server object store, the sync version associated with each object in the object store is an update sequence number. Further, a set of remote object stores among the client object store, one-to-one to client object store, client to client object store, client to server object store, client to peer-to-peer object store, and generic joint object store can be registered as its replicas. In a server object store, the store sync version (an update sequence number) is equal to the greatest value of all the sync versions (update sequence numbers) of the objects contained in the object store.
In a peer-to-peer object store, the sync version associated with each object in the object store is a version vector. Further, any unlimited number of remote object stores among the peer-to-peer object store, one-to-one to peer-to-peer object store, client to peer-to-peer object store, server to peer-to-peer object store, peer-to-peer to peer-to-peer to object store, and generic joint object store can be registered as its replicas. In a peer-to-peer object store, the store sync version (a version vector) is equal to the upper bound of all the sync versions (version vectors) of the objects contained in the object store.
In a read only object store, the sync version associated with each object in the object store is of a dynamic type depending on the remote replica(s) from which it receives updates. One or more remote object stores of any type can be registered as its replica(s).
In a one-to-one to one-to-one object store, two sync versions of dirty bits are associated to each object in the object store. Among the two sync versions associated with each object, one is used to synchronize with its replica in a first one-to-one system and the other is used to synchronize with its replica in a second one-to-one systems. Two remote object stores among the one-to-one object store, one-to-one to one-to-one object store, one-to-one to client object store, one-to-one to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a one-to-one to client object store, two sync versions are associated with each object in the object store. These two sync versions comprise a dirty bit and a combination of a dirty bit and an update sequence number. The first dirty bit indicates synchronization with the object's replica in a one-to-one system. The combination of a dirty bit and an update sequence number indicates synchronization with the object's server replica in a client-server system. A remote object store among the one-to-one object store, one-to-one to one-to-one object store, one-to-one to client object store, one-to-one to peer-to-peer object store, or generic joint object store and a remote object store among the server object store, client to server object store, server to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a one-to-one to peer-to-peer object store, two sync versions are associated with each object in the object store. These two sync versions comprise a dirty bit and a version vector. The dirty bit indicates synchronization with an object's replica in a one-to-one system. The version vector indicates synchronization with the object's replicas in a peer-to-peer system. A remote object store among the one-to-one object store, one-to-one to one-to-one object store, one-to-one to client object store, one-to-one to peer-to-peer object store, or generic joint object store and a set of remote object stores among the peer-to-peer object store, one-to-one to peer-to-peer object store, client to peer-to-peer object store, server to peer-to-peer object store, peer-to-peer to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a client to client object store, two sync versions are associated with each object in the object store. These two sync versions comprise two combinations of a dirty bit and an update sequence number. The first sync version indicates synchronization with the object's server replica in a first client-server system and the second sync version indicates synchronization with the object's server replica in a second client-server system. Two remote object stores among the server object store, client to server object store, server to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a client to server object store, two sync versions are associated with each object in the object store. These two sync versions comprise an update sequence number and a combination of a dirty bit and another update sequence number. The combination of a dirty bit and an update sequence number indicates synchronization with an object's server replica in a client-server system. The other update sequence indicates synchronization with an object's client replicas in another client-number server system. A remote object store among the server object store, client to server object store, or generic joint object store and a set of object stores among the client object store, one-to-one to client object store, client to client object store, client to server object store, client to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a client to peer-to-peer object store, two sync versions are associated with each object in the object store. These two sync versions comprise a combination of a dirty bit and an update sequence number and a version vector. The combination of a dirty bit and an update sequence number indicates synchronization with an object's server replica in a client-server system. The version vector indicates synchronization with an object's replicas in a peer-to-peer system. A remote object store among the server object store, client to server object store, server to peer-to-peer object store, or generic joint object store and a set of object stores among the peer-to-peer object store, one-to-one to peer-to-peer object store, client to peer-to-peer object store, server to peer-to-peer object store, peer-to-peer to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a server to peer-to-peer object store, two sync versions are associated with each object in the object store. These two sync versions comprise an update sequence number and a version vector. The update sequence number indicates synchronization with an object's client replicas in a client-server system. The version vector indicates synchronization with an object's replicas in a peer-to-peer system. A set of remote object stores among the client object store, one-to-one to client object store, client to client object store, client to server object store, client to peer-to-peer object store, or generic joint object store and a set of object stores among the peer-to-peer object store, one-to-one to peer-to-peer object store, client to peer-to-peer object store,server to peer-to-peer object store, peer-to-peer to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a peer-to-peer to peer-to-peer object store, two sync versions are associated with each object in the object store. These two sync versions comprise two version vectors. A first version vector indicates synchronization with an object's replicas in a first peer-to-peer system and a second version vector indicates synchronization with the object's replicas in a second peer-to-peer system. A set of remote object stores among the peer-to-peer object store, one-to-one to peer-to-peer object store, client to peer-to-peer object store, server to peer-to-peer object store, peer-to-peer to peer-to-peer object store, and generic joint object store can be registered as its replicas.
In a generic joint object store, three or more sync versions are associated with each object in the object store. In an exemplary embodiment, each sync version indicates synchronization with an object's replicas in a primitive system and the type of such a sync version is dependent on the type of primitive system and the role of the generic joint object store in the primitive system. A set of object store in accordance with the primitive systems linked by the generic joint object store can be registered as its replicas.
At time t4, the object Oi in object store C 30 is updated. Accordingly, the dirty bit SViC that is associated with the object Oi in the object store C 306 and the dirty bit SVC that is associated with the object store C 306 are set on. Next, at time t5, the object store C 306 initiates a data synchronization process with the joint object store B 302 by sending a synchronization request to the joint object store B 302. After receiving the synchronization request, the joint object store B 302 prepares for the synchronization by selecting the set of dirty bits SViBC and SVBC for the synchronization. The object store C 306 then sends the object Oi to the joint object store B 302 and after the joint object store B 302 receives the object Oi from the object store C 306, the dirty bits SViC and SVC at the object store C 306 are set off.
A concurrent update conflict regarding object Oi is detected at the joint object store B 302 and the conflict is resolved by merging the conflicting updates. As a result of the merge, the contents of the object Oi in the joint object store B 302 may be different than the object Oi at the object store A 304 and the object store C 306. If that is the case, the dirty bits SViBC and SVBC should remain on and the dirty bits SViAB and SVAB are set on. Next, the joint object store B 302 sends its version of object Oi to the object store C 306 for synchronization. After the synchronization is completed (e.g., at time t6), the dirty bits SBiBC and SBBC are set off. Finally, the joint object store B 302 initiates a data synchronization with the object store A 304 and sends its version of the object Oi, to the object store A 304. After the synchronization is completed, the dirty bits SViAB and SVAB are set off. As a result, the object Oi at all object stores 302, 304, and 306 are again consistent.
When designing a data synchronization protocol, various high level and low level issues should be considered. Exemplary high level issues include differential synchronization, fault tolerance, and subset filtering. Differential synchronization ensures that each object store only sends or receives updated objects to or from a replica when performing synchronization with the replica. Fault tolerance ensures that a failed synchronization process is restarted from the point of failure. Subset filtering allows efficient synchronization among object stores having different objects. For example, a subset of objects (i.e., ones that are relevant or irrelevant) is filtered at an object store before such synchronization occurs. In an exemplary embodiment, a subset filter is defined when an object store is created and then sent to that object store's replicas during the first synchronization process.
Exemplary low level issues include redundant update transmission, overhead reduction, and system/network adaptability. Redundant update transmission between object stores in a peer-to-peer system can be avoided by performing sync version comparisons at a destination object store. New transmission of objects already received at the destination object store is ignored. A user at a source object store may also obtain an exclusive access to a destination object store (or a subset of the objects in the destination object store) during a synchronization process to prevent redundant update transmissions from other object stores.
To reduce overhead, the sync versions of a source object store and a destination object store should be compared at the beginning of a synchronization process, such that if the source object store has an older (less recently updated) or equal sync version than the destination object store, the synchronization process is aborted. In addition, when the source object store and the destination object store are both compatible with certain data compression methods, such data compression methods should be employed, whenever possible during synchronization, to improve data traffic and reduce overhead.
Finally, system/network adaptability deals with determining packet sizes and flow control based on the underlying system or network capabilities to avoid data loss and achieve higher efficiency. For example, in a high speed network, larger packet size and faster data flow can be processed. In one embodiment, flow control is adaptively optimized based on system/network topology; that is, optimized based on the types of object stores involved in each synchronization process.
Generally, data synchronization protocol in accordance with the invention is configurable to run on TCP/IP, HTTP, or SMTP protocols. When the data synchronization protocol is run on the HTTP or SMTP protocols, objects and meta objects (i.e., sync version and object identification) are embedded serially in HTTP or SMTP format, respectively. Otherwise, in an exemplary embodiment, the data synchronization protocol is configured to run on the TCP/IP protocol by default.
In an exemplary embodiment, there are two types of messages being transmitted in a data synchronization protocol (DSP) process: DSP URLs and DSP sync messages. A DSP URL uniquely identifies an object store and may be used to establish connection between a source object store and a destination object store. An exemplary DSP URL is as follows:
In the exemplary DSP URL, strings in italics represent variable parameters. The “|” denotes a selection, the brackets enclose an option, and the parentheses enclose a set of selection list. If “http” or “smtp” is specified, the DSP will run on HTTP or SMTP; otherwise, the DSP will run on TCP/IP by default. The “objectstore-name” indicates the name of an object store for which this URL is specified (“the object store”). The “device-id” indicates the unique identification of the device where the object store resides. The “CREATE” parameter indicates that a new object store will be created on a remote device. The “EXCLUSIVE” parameter indicates that a destination object store is opened for exclusive access during synchronization with the object store; a synchronization process will block until a destination object store can be opened for exclusive access. If a “NOWAIT” parameter is used in addition to the “EXCLUSIVE” parameter, a synchronization process will automatically fail if a destination object store is already opened by another.
A DSP sync message is a data unit that is transmitted between object stores. Generally, there are two types of DSP sync messages: a request message and a response message. Exemplary fields included in a sync message are listed in Appendix A.
An exemplary sync message flow is illustrated in
In an exemplary embodiment, the DSP is adaptive to different network connection media and different system topologies. Further, the DSP is optimized for different synchronization modes. Different network connection media typically have different data transfer speed (bandwidth), latency (statistical length of time for a round-trip data transfer), and reliability (probability of accidental data loss or disconnection). In order to maximize resource utilization on a network, the size of each data packet to be transferred and data flow control should be determined based on the individual characteristics of each network connection medium.
In an exemplary embodiment, flow control of sync messages are determined based on synchronization mode, system topology, and user authentication. Exemplary sync message flows for various network systems are discussed in
The destination object store responds to the request sync message with required information and optionally with a list of encoding methods supported by the destination object store (step 708). The source object store then registers the received information in the object store replica information associated with the destination object store (step 710).
At the source object store, all objects whose dirty bits are on are extracted (step 712). These objects along with their IDs and dirty bits are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined by the destination object store (step 714). The source object store then sends a request sync message with these fields assigned to the specified values (step 716): isRequest—true; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncUpdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; encodingMethod <encoding method,. if any, used to encode extracted updates>; isLastRequest—true. In an exemplary embodiment, the appropriate values for clientURL, serverURL, and usableEncodingMethods are also provided in the request message if the request message is the first message sent from the source object store to the destination object store in the current synchronization process. The destination object store applies each of the received updates into the corresponding object (step 718), sets dirty bits associated with the updated objects and the object store accordingly (step 720), and sends a response sync message to the request sync message providing the number of updates that was received and successfully processed (step 722). In one embodiment, if the response sync message is the first message sent from the destination object store to the source object store in the current synchronization process, a value for the usableEncodingMethods field is also sent in the response sync message. Upon receipt of the response sync message, the source object store resets the dirty bits associated with the first n updates sent, where n is the value of the totalNumberOfSyncUpdatesReceived field enclosed in the response sync message that the source object store received from the destination object store (step 724). Next, the source object store purges off deleted objects whose dirty bits are off (step 726).
In an exemplary embodiment, the set of updates send by the source object store may be divided into more than one request sync message. In such a case, the last request sync message should contain the isLastRequest field set to “true” to indicate its status as the last request. Sending piecemeal update request sync messages is appropriate especially when a frequently disconnected wireless connection, such as a radio connection, is used.
If a request sync message is sent by the source object store, the destination object store responds to the request sync message with required information and optionally with the list of encoding methods supported by the destination object store (step 808). The source object store then registers the received information in the object store replica information associated with the destination object store (step 810).
At the source object store, all objects whose dirty bits are on are extracted (step 812). Object updates, associated object IDs, and sync versions (i.e., a sync version is a combination of a dirty bit and an update sequence number) are packed together and represented in a format acceptable to the destination object store and passable through the syncFilter defined by the destination object store (step 814). The source object store then sends a request sync message with these fields assigned to the specified values (step 816): isRequest—true; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncUpdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded.>; encodingMethod <encoding method, if any, used to encode extracted updates>; isLastRequest—true. In an exemplary embodiment, if the request sync message is the first message sent from the source object store to the destination object store in the current synchronization process (step 818), appropriate values for clientURL, ServerURL, and usableEncodingMethods are also provided in the request sync message (step 820). Upon receipt of the request sync message, the destination object store applies each received update into a corresponding object (step 822), updates the update sequence numbers associated with the updated objects and the object store (step 824), and sends a response sync message to the request sync message providing the number of updates that was received and successfully processed (step 826). If this response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 828), the value of the usableEncodingMethods field is also provided (step 830). Next, the destination object store saves each update sequence number associated with an updated object into the object store replica information associated with the source object store (step 832). This step prevents redundant update transmission from the destination object store to the source object store at a later time. After receiving the response sync message, the source object store resets the dirty bits associated with the first n updates sent, where n is the value of the totalNumberOfSyncUpdatesReceived field enclosed in the response sync message from the destination object store (step 834). Finally, the source object store purges off deleted objects whose dirty bits are off(step 836).
If the request sync message is sent by the source object store, the destination object store responds to the request sync message with required information and optionally with the list of encoding methods supported by the destination object store (step 908). The source object store registers the received information in the object store replica information associated with the destination object store (step 910). Next, the source object store removes saved update sequence numbers from the object store replica information that are less than or equal to the new update sequence number, which is the value of the storeVersion field included in the response from the destination object store (step 912).
The source object store extracts all objects whose update sequence numbers are greater than the update sequence number (step 914). These objects, the associated object IDs, and update sequence numbers are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined by the destination object store (step 916). In an exemplary embodiment, the update sequence number associated with any one of the objects should not be an update sequence number saved in the object store replica information. The source object store then sends a request sync message with these fields assigned to the specified values (step 918): isRequest—true; isAskedForStoreVersion—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are, if any, encoded>; encodingMethod <encoding method. if any used to encode extracted updates>; isLastRequest—true. In an exemplary embodiment, if the request sync message is the first message sent from the source object store to the destination object store in the current synchronization process (step 920), the appropriate values for clientURL, serverURL, and usableEncodingMethods are also provided in the request sync message (step 922). The destination object store applies each of the received updates to a corresponding object (step 924), sets the dirty bits associated with the updated objects sets and the update sequence number associated with the object store (step 926), and sends a response sync message to the request sync message with the update sequence number associated with the object store (step 928).
In an exemplary embodiment, if the response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 930), the value of the usableEncodingMethods field is also provided (step 932). After receiving the response sync message, the source object store registers the new update sequence number, which is the value of the storeVersion field enclosed in the response sync message, in the object store replica information associated with the destination object store (step 934). In one embodiment, the source object store evaluates or reevaluates the update sequence numbers among all remote object stores to determine a common update sequence number. A common update sequence number is the smallest update sequence number among the update sequence numbers associated with all remote replica information. Finally, the source object store removes old update sequence numbers from the object store replica information that are less than or equal to the new update sequence number received as the storeVersion in the response sync message, updates the object store replica information (step 936), and purges off deleted objects that have an update sequence number that is smaller than or equal to the common update sequence number (step 938).
The destination object store responds to the request sync message with the required information and optionally with a list of encoding methods supported by the destination object store (step 1006). Upon receiving the information, the source object store registers the information in the object store replica information associated with the destination object store (step 1008). At the source object store, all objects whose version vectors are newer than or conflicting with the version vector registered in the object store replica information associated with the destination object store are extracted (step 1010). These objects along with their IDs and version vectors are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined on the destination object store (step 1012). The source object store sends a request sync message with these fields assigned to the specified values (step 1014): isRequest—true; isAskedForStoreVersion—true; syncUpdates <extracted updates>; storeVersion <version vector associated with source object store>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are, if any, encoded>; Encodingmethod <encoding method, if any, used to encode extracted updates>; isLastRequest—true.
After receiving the request sync message, the destination object store applies each of the received updates to a corresponding object (step 1016), updates the version vectors associated with the object and the object store (step 1018), and sends a response sync message to the request sync message with the version vector associated with the object store (step 1020). The source object store then updates the version vector, which was received in the response sync message, in the object store replica information associated with the destination object store (step 1022). In one embodiment, the source object store evaluates or reevaluates the version vectors among all remote object stores and determines a common version vector. A common version vector is the version vector who contains the smallest time stamp among the version vectors associated with all remote replica information. Finally, the source object store purges off deleted objects whose version vectors are older than or equal to the common version vector (step 1024).
The destination object store checks if the object store replica information corresponding to the source object store contains the following information on the source object store: applyUpdateTypes and syncFilter (step 1104). If any of the information is missing from the object store replica information (step 1106), a request sync message is sent to ask for the missing information (step 1108). For example, if both of applyUpdateTypes and syncFilter are missing from the object store replica information, a sync message with these fields assigned to the specified values is sent: isRequest—true; isAskedForApplyUpdateTypes—true; isAskedForSyncFilter—true; usableEncodingMethods <encoding methods supported by destination object store>. Upon receipt of the request sync message from the destination object store, the source object store responds to the request sync message with the required information (step 1110). The destination object store then registers the received information in the object store replica information associated with the source object store (step 1112). Next, the destination object store extracts all objects whose dirty bits are on (step 1114). These objects, their IDs, and dirty bits are packed together and represented in an update type acceptable to the source object store and passable through the syncFilter defined by the source object store (step 1116). The destination object store then sends a response sync message with these fields assigned to the specified values (step 1118): isRequest—false; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncUpdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; Encodingmethod <encoding method, if any, used to encode extracted updates>. If the response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 1120), appropriate values for usableEncodingMethods are also provided in the response sync message (step 1122). After receiving the response sync message, the source object store applies each of the received updates to the corresponding object (step 1124), sets dirty bits associated with the updated objects and the object store (step 1126), and sends a response sync message to the received response sync message providing the number of updates that was received and successfully processed (step 1128). The destination object store then resets the dirty bits associated with the first n updates sent, where n is the value of the totalNumberOfSyncUpdatesReceived field in the response sync message from the source object store (step 1130). Finally, the destination object store purges off deleted objects whose dirty bits are off (step 1132). In general, the process described in
The sync message flow for pull-only, client-to-server synchronization in a client-server system is generally the reverse of the exemplary process described above in FIG. 8. Likewise, the sync message flow for pull-only, server-to-client synchronization in a client-server system is generally the reverse of the exemplary process described above in FIG. 9. The sync message flow for pull-only synchronization in a peer-to-peer system is generally the reverse of the exemplary process described above in FIG. 10.
The destination object store responds to the request sync message with required information and optionally with a list of encoding methods supported by the destination object store (step 1208). The source object store then registers the received information in the object store replica information associated with the destination object store (step 1210).
Next, the source object store extracts objects whose dirty bits are on (step 1212). These objects, their IDs, and dirty bits are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined on the destination object store (step 1214). The source object store then sends a request sync message with these fields assigned to the specified values (step 1216): isRequest—true; isAskedForTotalNumber ofSyncUpdatesReceived—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; isAskedForSyncUpdates—true; Encodingmethod <encoding method, if any, used to encode extracted updates>; isLastRequest—true. If the request is the first message sent from the source object store to the destination object store in the current synchronization process (step 1218), the appropriate values for clientURL, ServerURL, and usableEncodingMethods are also provided in the request sync message (step 1220). The destination object store applies each of the received updates to a corresponding object (step 1222) and sets dirty bits associated with the updated objects and the object store (step 1224). Next, the destination object store checks if the object store replica information corresponding to the source object store contains the following information on the source object store: applyUpdateTypes and syncFilter (step 1226). If any information is missing from the object store replica information (step 1228), a request sync message asking for the missing information is sent (step 1230). For example, if both of the applyUpdateTypes and syncFilter are missing from the object store replica information, a sync message with these fields assigned to the specified values is sent: isRequest—true; isAskedForApplyUpdateTypes—true; isAskedForSyncFilter—true; usableEncodingMethods <encoding methods supported by destination object store>. After receiving the request sync message, the source object store responds to the request sync message with the required information (step 1232). The destination object store then registers the received information in the object store replica information associated with the source object store (step 1234). Next, the destination object store extracts all objects whose dirty bits are on (step 1236). These objects, their IDs, and dirty bits are packed together and represented in an update type acceptable to the source object store and passable through the syncFilter defined by the source object store (step 1238). The destination object store then sends a response sync message with these fields assigned to the specified values (step 1240): isRequest—false; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; TotalNumberOfSyncUpdatesReceived <number of updates received and successfully processed by destination object store>; Encodingmethod <encoding method, if any, used to encode extracted updates>.
If the response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 1242), the appropriate values for usableEncodingMethods are also provided in the response sync message (step 1244). The source object store applies each of the received updates to a corresponding object (step 1246), sets dirty bits associated with the object and the object store (step 1248), and sends a response message to the received response sync message providing the number of updates that was received and successfully processed (step 1250). The source object store resets dirty bits associated with the first n updates sent, where n is the value of the totalNumberOfSyncUpdatesReceived field included in the response sync message received from the destination object store (step 1252). The source object store purges off deleted objects whose dirty bits are off (step 1254). Further, the destination object store resets dirty bits associated with the first m updates sent, where m is the value of the totalNumberOfSyncUpdatesReceived field included in the response sync message received from the source object store (step 1256). Finally, the destination object store purges off deleted objects whose dirty bits are off (step 1258).
After receiving the request sync message, the destination object store responds to the request sync message with the required information and optionally with a list of encoding methods supported by the destination object store (step 1308). The source object store then registers the received information in the object store replica information associated with the destination object store (step 1310). The source object store extracts objects whose dirty bits are on (step 1312). These objects, their IDs, and sync versions (i.e., a sync version is a combination of a dirty bit and an update sequence number) are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined by the destination object store (step 1314). The source object store then sends a request sync message with these fields assigned to the specified values (step 1316): isRequest—true; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; isAskedForSyncUpdates—true; Encodingmethod <encoding method, if any, used to encode extracted updates>; isLastRequest—true. If the request sync message is the first message sent from the source object store to the destination object store in the current synchronization process (step 1318), the appropriate values for clientURL, serverURL, and usableEncodingMethods are also provided in the request sync message (step 1320). The destination object store applies each of the received updates to a corresponding object (step 1322) and updates the update sequence numbers associated with the application object and the object store (step 1324). The destination object store then saves the update sequence number associated with an updated object into the object store replica information associated with the source object store (step 1326).
The destination object store checks if the object store replica information corresponding to the source object store contains the following information on the source object store: store Version, apply UpdateTypes, and syncFilter (step 1328). If any information is missing from the object store replica information (step 1330), a request sync message asking for the missing information is sent (step 1332). For example, if all of the storeVersion, applyUpdateTypes, and syncFilter are missing from the object store replica information, a sync message with these fields assigned to the specified values is sent: isRequest—true; isAskedForStoreVersion—true; isAskedForApplyUpdateTypes—true; isAskedForSyncFilter—true; usableEncodingMethods <encoding methods supported by source object store>.
After receiving the request sync message from the destination object store, the source object store responds to the request sync message with the required information (step 1334). The destination object store then registers the received information in the object store replica information associated with the source object store (step 1336). The destination object store removes saved update sequence numbers from the object store replica information that are less than or equal to the new update sequence number, which is the value of the storeVersion field included in the response sync message from the source object store (step 1338). The destination object store extracts objects whose update sequence numbers are greater than the new update sequence number (step 1340). These objects, their IDs, and update sequence numbers are packed together and represented in an update type acceptable to the source object store and passable through the syncFilter defined on the source object store (step 1342). In an exemplary embodiment, the update sequence number associated with any objects should not be an update sequence number saved in the object store replica information. Next, the destination object store sends a response sync message with these fields assigned to the specified values (step 1344): isRequest—false; isAskedForStoreVersion—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; totalNumberOfSyncUpdatesReceived <number of updates received and successfully processed by destination object store>; encodingMethod <encoding method, if any, used to encode extracted updates>.
If the response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 1346), the appropriate values for usableEncodingMethods is also provided in the response sync message (step 1348). The source object store applies each of the received updates to a corresponding object (step 1350), sets the dirty bit associated with the updated objects and the update sequence number associated with the object store (step 1352), and sends a response sync message to the received response sync message with the update sequence number associated with the source object store (step 1354). The source object store then resets the dirty bits associated with the first n updates it sent, where n is the value of the totalNumberOfSyncUpdates Received field included in the response sync message received from the destination object store (step 1356). Next, the source object store purges off deleted objects whose dirty bits are off (step 1358). The destination object store registers the new update sequence number in the object store replica information associated with the source object store (step 1360) and determines a common update sequence number. Finally, the destination object store removes saved update sequence numbers from the object store replica information that are less than or equal to the new update sequence number received as the storeVersion in the response sync message (step 1362) and purges off deleted objects whose update sequence numbers are less than or equal to the common update sequence number (step 1364).
Next, the destination object store checks if the object store replica information corresponding to the source object store contains the following information on the source object store: applyUpdateTypes and syncFilter (step 1426). If any information is missing from the object store replica information (step 1428), a request sync message asking for the missing information is sent (step 1430). For example, if both of the applyUpdateTypes and syncFilter are missing from the object store replica information, a sync message with these fields assigned to the specified values is sent: isRequest—true; isAskedForApplyUpdateTypes—true; isAskedForSyncFilter—true; usableEncodingMethods <encoding methods supported by source object store>. After receiving the request sync message, the source object store responds to the request sync message with required information (step 1432). The destination object store then registers the received information in the object store replica information associated with the source object store (step 1434).
Next, the destination object store extracts objects whose dirty bit are on (step 1436). These objects, their IDs, and sync versions are packed together and represented in an update type acceptable to the source object store and passable through the syncFilter defined on the source object store (step 1438). The destination object store then sends a response sync message with these fields assigned to the specified values (step 1440): isRequest—false; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are, if any, encoded>; storeVersion <Sync Version associated with destination object store>; encodingMethod <encoding method, if any, used to encode extracted updates>. If the response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 1442), an appropriate value of the usableEncodingMethods field is provided in the response sync message (step 1444). The source object store applies each of the received updates to a corresponding object (step 1446), updates the update sequence numbers associated with the updated objects and the object store (step 1448), and sends a response sync message to the received response sync message providing the number of updates that was received and successfully processed (step 1450). The source object store registers the new update sequence number, which the value of the storeVersion field enclosed in the response sync message from the destination object store, in the object store replica information associated with the destination object store (step 1452). The source object store then saves the update sequence number associated with each replaced object in the object store replica information associated with the destination object store (step 1454). In one embodiment, the source object store evaluates or reevaluates the update sequence numbers among all remote object stores to determine a common update sequence number. A common update sequence number is the smallest update sequence number among the update sequence numbers associated with all remote replica information. Finally, the source object store purges off deleted objects whose update sequence numbers are less than or equal to the common update sequence number (step 1456).
Next, the destination object store resets the dirty bits associated with the first n updates sent, where n is the value of the totalNumberOfSyncUpdatesReceived field included in the response sync message from the source object store (step 1458). The destination object store purges off the deleted objects whose dirty bits are off (step 1460).
Next, the source object store extracts objects whose version vectors are newer than or conflicting with the version vector registered in the object store replica information associated with the destination object store (step 1512). These objects, their IDs and version vectors are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined on the destination object store (step 1514). The source object store then sends a request sync message with these fields assigned to the specified values (step 1516): isRequest—true; isAskedForStoreVersion—true; syncupdates <extracted updates>; storeVersion <Sync Version associated with source object store>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted objects after they are encoded>; isAskedForSyncUpdates—true; encodingMethod—<encoding method, if any, used to encode extracted updates>; isLastRequest—true. The destination object store applies each of the received updates to a corresponding object (step 1518) and updates the version vectors associated with the application object and the object store (step 1520).
Next, the destination object store checks if the object store replica information corresponding to the source object store contains the following information on the source object store: applyUpdateTypes and syncFilter (step 1522). If any information is missing from the object store replica information (step 1524), a request sync message asking for the missing information is sent (step 1526). For example, if both of the applyUpdateTypes and syncFilter are missing from the object store replica information, a sync message with these fields assigned to the specified values is sent: isRequest—true; isAskedForApplyUpdateTypes—true; isAskedForSyncFilter—true. After receiving the request sync message, the source object store responds to the request sync message with the required information (step 1528). The destination object store then registers the received information in the object store replica information associated with the source object store (step 1530).
Next, the destination object store extracts objects whose version vectors are newer than or conflicting with the version vector registered in the object store replica information associated with the source object store (step 1532). These objects, their IDs, and version vectors are packed together and represented in an update type acceptable to the source object store and passable through the syncFilter defined by the source object store (step 1534). The destination object store then sends a response sync message with these fields assigned to the specified values (step 1536): isRequest—false; isAskedForStoreVersion—true; syncUpdates <extracted updates>; storeVersion <Sync Version associated with destination object Store>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; encodingMethod <encoding method, if any, used to encode extracted updates>. If the response sync message is the first message sent from the responding to the source object store in the current synchronization process (step 1538), an appropriate value of the usableEncodingMethods field is also provided in the response sync message (step 1540).
The source object store applies each of the received updates into a corresponding object (step 1542), updates the version vectors associated with the application object and the object store (step 1544), and sends a response sync message to the received response sync message with the sync version associated with the source object store (step 1546). The source object store updates the version vector from the destination object store in the object store replica information associated with the destination object store (step 1548). In one embodiment, the source object store evaluates or reevaluates the version vectors among all remote object stores to determine a common version vector. A common version vector is the version vector who has the smallest time stamp among the version vectors associated with all remote replica information. Finally, the source object store purges off deleted objects whose version vectors are older than or equal to the common version vector (step 1550).
Likewise, the destination object store updates the version vector from the source object store in the object store replica information associated with the source object store (step 1552). In one embodiment, the destination object store evaluates or reevaluates the version vectors among all remote object stores to determine a common version vector. A common version vector is the version vector who has the smallest time stamp among the version vectors associated with all remote replica information. Finally, the destination object store purges off deleted objects whose version vectors are older than or equal to the common version vector (step 1554).
The destination object store checks if the object store replica information corresponding to the source object store contains the following information on the source object store: applyUpdateTypes and syncFilter (step 1606). If any information is missing from the object store replica information (step 1608), a request sync message asking for the missing information is sent (step 1610). For example, if both of the applyUpdateTypes and syncFilter are missing from the object store replica information, a sync message with these fields assigned to the specified values is sent: isRequest—true; isAskedForApplyUpdateTypes—true; isAskedForSyncFilter—true; usableEncodingMethods <encoding methods supported by source object store>. After receiving the request sync message, the source object store responds to the request sync message with the required information (step 1612). The destination object store then registers the received information in the object store replica information associated with the source object store (step 1614).
Next, the destination object store extracts objects whose dirty bits are on (step 1616). These objects, their IDs, and dirty bits are packed together and represented in an update acceptable to the source object store and passable through the syncFilter defined on the source object store (step 1618). The destination object store then sends a response sync message with these fields assigned to the specified values (step 1620): isRequest—false; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncupdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are encoded>; encodingMethod <encoding method, if any, used to encode extracted updates>. If this response sync message is the first message sent from the destination object store to the source object store in the current synchronization process (step 1622), appropriate values for the applyUpdateTypes and syncFilter fields are provided if such information was inquired in the received request sync message (step 1624). The source object store applies each of the received updates to a corresponding application object (step 1626), sets the dirty bits for the updated object and the object store (step 1628), and sends a response sync message to the received response sync message providing the number of updates that was received and successfully processed (step 1630). The source object store registers the other information it received, if any, in the object store replica information associated with the destination object store (step 1632). The destination object store then resets the dirty bits associated with the first n updates sent, where n is the value of the totalNumberOfSyncUpdatesReceived field in the response sync message received from the source object store (step 1634). Next, the destination object store purges off deleted objects whose dirty bits are off (step 1636).
The source object store extracts objects whose dirty bits are on (step 1638). These objects, their IDs, and dirty bits are packed together and represented in an update type acceptable to the destination object store and passable through the syncFilter defined on the destination object store (step 1640). The source object store then sends a request sync message with these fields assigned to the specified values (step 1642): isRequest—true; isAskedForTotalNumberOfSyncUpdatesReceived—true; syncUpdates <extracted updates>; totalNumberOfSyncUpdates <number of extracted updates>; totalBytesOfSyncUpdates <size in byte of extracted updates after they are, if any encoded>; encodingMethod <encoding method, if any used to encode extracted updates>; isLastRequest—true. The destination object store applies each of the received updates to a corresponding object (step 1644), sets the dirty bits of the updated objects and the object store (step 1646), and sends a response sync message to the request sync message providing the number of updates that was received and successfully processed (step 1648). The source object store then resets the dirty bits associated with the first m updates sent, where m is the value of the totalNumberOfSyncUpdatesReceived field in the response sync message received from the destination object store (step 1650). Next, the source object store purges off deleted objects whose dirty bits are off (step 1652).
In general, the process described in
The foregoing examples illustrate certain exemplary embodiments of the invention from which other embodiments, variations, and modifications will be apparent to those skilled in the art. The invention should therefore not be limited to the particular embodiments discussed above, but rather is defined by the claims.
In an exemplary embodiment, a sync version message comprises on or more of the following fields:
| Patent | Priority | Assignee | Title |
| 10015237, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 10015241, | Sep 20 2012 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| 10021179, | Feb 21 2012 | Amazon Technologies, Inc | Local resource delivery network |
| 10027582, | Nov 17 2008 | Amazon Technologies, Inc. | Updating routing information based on client location |
| 10033627, | Dec 18 2014 | Amazon Technologies, Inc | Routing mode and point-of-presence selection service |
| 10033691, | Aug 24 2016 | Amazon Technologies, Inc | Adaptive resolution of domain name requests in virtual private cloud network environments |
| 10049051, | Dec 11 2015 | Amazon Technologies, Inc | Reserved cache space in content delivery networks |
| 10075551, | Jun 06 2016 | Amazon Technologies, Inc. | Request management for hierarchical cache |
| 10079742, | Sep 28 2010 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| 10091096, | Dec 18 2014 | Amazon Technologies, Inc | Routing mode and point-of-presence selection service |
| 10097398, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Point of presence management in request routing |
| 10097448, | Dec 18 2014 | Amazon Technologies, Inc | Routing mode and point-of-presence selection service |
| 10097566, | Jul 31 2015 | Amazon Technologies, Inc | Identifying targets of network attacks |
| 10110694, | Jun 29 2016 | Amazon Technologies, Inc | Adaptive transfer rate for retrieving content from a server |
| 10116584, | Nov 17 2008 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| 10135620, | Sep 04 2009 | AMAZON TECHNOLOGIS, INC. | Managing secure content in a content delivery network |
| 10153969, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 10157135, | Mar 31 2008 | Amazon Technologies, Inc. | Cache optimization |
| 10158729, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 10180993, | May 13 2015 | Amazon Technologies, Inc. | Routing based request correlation |
| 10200402, | Sep 24 2015 | Amazon Technologies, Inc. | Mitigating network attacks |
| 10205698, | Dec 19 2012 | Amazon Technologies, Inc | Source-dependent address resolution |
| 10218584, | Oct 02 2009 | Amazon Technologies, Inc. | Forward-based resource delivery network management techniques |
| 10225322, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 10225326, | Mar 23 2015 | Amazon Technologies, Inc | Point of presence based data uploading |
| 10225362, | Jun 11 2012 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| 10230819, | Mar 27 2009 | Amazon Technologies, Inc. | Translation of resource identifiers using popularity information upon client request |
| 10257307, | Dec 11 2015 | Amazon Technologies, Inc | Reserved cache space in content delivery networks |
| 10264062, | Mar 27 2009 | Amazon Technologies, Inc. | Request routing using a popularity identifier to identify a cache component |
| 10270878, | Nov 10 2015 | Amazon Technologies, Inc | Routing for origin-facing points of presence |
| 10305797, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 10348639, | Dec 18 2015 | Amazon Technologies, Inc | Use of virtual endpoints to improve data transmission rates |
| 10372499, | Dec 27 2016 | Amazon Technologies, Inc | Efficient region selection system for executing request-driven code |
| 10374955, | Jun 04 2013 | Amazon Technologies, Inc. | Managing network computing components utilizing request routing |
| 10447648, | Jun 19 2017 | Amazon Technologies, Inc | Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP |
| 10469355, | Mar 30 2015 | Amazon Technologies, Inc. | Traffic surge management for points of presence |
| 10469442, | Aug 24 2016 | Amazon Technologies, Inc. | Adaptive resolution of domain name requests in virtual private cloud network environments |
| 10469513, | Oct 05 2016 | Amazon Technologies, Inc | Encrypted network addresses |
| 10491534, | Mar 27 2009 | Amazon Technologies, Inc. | Managing resources and entries in tracking information in resource cache components |
| 10503613, | Apr 21 2017 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Efficient serving of resources during server unavailability |
| 10505961, | Oct 05 2016 | Amazon Technologies, Inc | Digitally signed network address |
| 10506029, | Jan 28 2010 | Amazon Technologies, Inc. | Content distribution network |
| 10511567, | Mar 31 2008 | Amazon Technologies, Inc. | Network resource identification |
| 10516590, | Aug 23 2016 | Amazon Technologies, Inc. | External health checking of virtual private cloud network environments |
| 10521348, | Jun 16 2009 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
| 10523783, | Nov 17 2008 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| 10530874, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 10542079, | Sep 20 2012 | Amazon Technologies, Inc. | Automated profiling of resource usage |
| 10554748, | Mar 31 2008 | Amazon Technologies, Inc. | Content management |
| 10574787, | Mar 27 2009 | Amazon Technologies, Inc. | Translation of resource identifiers using popularity information upon client request |
| 10592578, | Mar 07 2018 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Predictive content push-enabled content delivery network |
| 10601767, | Mar 27 2009 | Amazon Technologies, Inc. | DNS query processing based on application information |
| 10616179, | Jun 25 2015 | Amazon Technologies, Inc | Selective routing of domain name system (DNS) requests |
| 10616250, | Oct 05 2016 | Amazon Technologies, Inc | Network addresses with encoded DNS-level information |
| 10623408, | Apr 02 2012 | Amazon Technologies, Inc | Context sensitive object management |
| 10645056, | Dec 19 2012 | Amazon Technologies, Inc. | Source-dependent address resolution |
| 10645149, | Mar 31 2008 | Amazon Technologies, Inc. | Content delivery reconciliation |
| 10666756, | Jun 06 2016 | Amazon Technologies, Inc. | Request management for hierarchical cache |
| 10691752, | May 13 2015 | Amazon Technologies, Inc. | Routing based request correlation |
| 10728133, | Dec 18 2014 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| 10742550, | Nov 17 2008 | Amazon Technologies, Inc. | Updating routing information based on client location |
| 10771552, | Mar 31 2008 | Amazon Technologies, Inc. | Content management |
| 10778554, | Sep 28 2010 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| 10783077, | Jun 16 2009 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
| 10785037, | Sep 04 2009 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
| 10797995, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 10831549, | Dec 27 2016 | Amazon Technologies, Inc | Multi-region request-driven code execution system |
| 10862852, | Nov 16 2018 | Amazon Technologies, Inc | Resolution of domain name requests in heterogeneous network environments |
| 10931738, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 10938884, | Jan 30 2017 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Origin server cloaking using virtual private cloud network environments |
| 10951725, | Nov 22 2010 | Amazon Technologies, Inc. | Request routing processing |
| 10958501, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Request routing information based on client IP groupings |
| 11025747, | Dec 12 2018 | Amazon Technologies, Inc | Content request pattern-based routing system |
| 11075987, | Jun 12 2017 | Amazon Technologies, Inc. | Load estimating content delivery network |
| 11108729, | Sep 28 2010 | Amazon Technologies, Inc. | Managing request routing information utilizing client identifiers |
| 11115500, | Nov 17 2008 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| 11134134, | Nov 10 2015 | Amazon Technologies, Inc. | Routing for origin-facing points of presence |
| 11194719, | Mar 31 2008 | Amazon Technologies, Inc. | Cache optimization |
| 11205037, | Jan 28 2010 | Amazon Technologies, Inc. | Content distribution network |
| 11245770, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 11283715, | Nov 17 2008 | Amazon Technologies, Inc. | Updating routing information based on client location |
| 11290418, | Sep 25 2017 | Amazon Technologies, Inc. | Hybrid content request routing system |
| 11297140, | Mar 23 2015 | Amazon Technologies, Inc. | Point of presence based data uploading |
| 11303717, | Jun 11 2012 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| 11330008, | Oct 05 2016 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
| 11336712, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 11362986, | Nov 16 2018 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
| 11381487, | Dec 18 2014 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| 11451472, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 11457088, | Jun 29 2016 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
| 11461402, | May 13 2015 | Amazon Technologies, Inc. | Routing based request correlation |
| 11463550, | Jun 06 2016 | Amazon Technologies, Inc. | Request management for hierarchical cache |
| 11604667, | Apr 27 2011 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
| 11632420, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 11729294, | Jun 11 2012 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| 11762703, | Dec 27 2016 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
| 11811657, | Nov 17 2008 | Amazon Technologies, Inc. | Updating routing information based on client location |
| 11863417, | Dec 18 2014 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| 11909639, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 7401103, | Jul 31 2003 | Microsoft Technology Licensing, LLC | Replication protocol for data stores |
| 7440981, | Jul 31 2003 | Microsoft Technology Licensing, LLC | Systems and methods for replicating data stores |
| 7440985, | Jul 31 2003 | Microsoft Technology Licensing, LLC | Filtered replication of data stores |
| 7441049, | Apr 25 2002 | Oracle International Corporation | Simplified application object data synchronization for optimized data storage |
| 7464186, | Mar 28 2001 | Siebel Systems Inc. | Method and system for server synchronization with a computing device via a companion device |
| 7536419, | Nov 15 2005 | Microsoft Technology Licensing, LLC | Slave replica member |
| 7577691, | Aug 02 2006 | Microsoft Technology Licensing, LLC | Extending hierarchical synchronization scopes to non-hierarchical scenarios |
| 7606881, | Apr 25 2002 | Oracle International Corporation | System and method for synchronization of version annotated objects |
| 7693880, | May 06 2004 | Veritas Technologies LLC | Mirrored storage at the file system level |
| 7706822, | Aug 24 2005 | ARRIS ENTERPRISES LLC | Timing synchronization and beacon generation for mesh points operating in a wireless mesh network |
| 7739240, | Dec 09 2002 | Hewlett Packard Enterprise Development LP | Replication and replica management in a wide area file system |
| 7756825, | Jul 31 2003 | Microsoft Technology Licensing, LLC | Synchronization peer participant model |
| 7787489, | Oct 07 2002 | Oracle International Corporation | Mobile data distribution |
| 7818679, | Apr 20 2004 | Microsoft Technology Licensing, LLC | Method, system, and apparatus for enabling near real time collaboration on an electronic document through a plurality of computer systems |
| 7853722, | Apr 25 2002 | Oracle International Corporation | Simplified application object data synchronization for optimized data storage |
| 7890646, | Apr 27 2006 | Microsoft Technology Licensing, LLC | Synchronization orchestration |
| 7917607, | Dec 30 2005 | SAP SE | Software management systems and methods, including use of such systems and methods in a provider-tenant environment |
| 7930318, | Dec 30 2005 | SAP SE | Systems and methods for implementing a tenant space in a provider-tenant environment |
| 7933869, | Dec 29 2006 | SAP SE | Method and system for cloning a tenant database in a multi-tenant system |
| 8019808, | Aug 21 2003 | Microsoft Corporation | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| 8046424, | Aug 21 2003 | Microsoft Technology Licensing, LLC | Systems and methods for the utilization of metadata for synchronization optimization |
| 8069184, | Dec 29 2006 | SAP SE | Systems and methods to implement extensibility of tenant content in a provider-tenant environment |
| 8131739, | Aug 21 2003 | Microsoft Technology Licensing, LLC | Systems and methods for interfacing application programs with an item-based storage platform |
| 8166101, | Aug 21 2003 | Microsoft Technology Licensing, LLC | Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system |
| 8185495, | Feb 01 2008 | Microsoft Technology Licensing, LLC | Representation of qualitative object changes in a knowledge based framework for a multi-master synchronization environment |
| 8209437, | Sep 25 2008 | SPECTRUM PATENTS, INC | Personal information management data synchronization |
| 8238696, | Aug 21 2003 | Microsoft Technology Licensing, LLC | Systems and methods for the implementation of a digital images schema for organizing units of information manageable by a hardware/software interface system |
| 8250397, | Jan 08 2007 | Apple Inc. | N-way synchronization of data |
| 8266706, | Jan 26 2007 | Microsoft Technology Licensing, LLC | Cryptographically controlling access to documents |
| 8321374, | Jun 21 2005 | Apple Inc. | Peer-to-peer N-way syncing in decentralized environment |
| 8386646, | Apr 25 2002 | Oracle International Corporation | Simplified application object data synchronization for optimized data storage |
| 8539107, | Sep 25 2008 | SPECTRUM PATENTS, INC | Personal information management data synchronization |
| 8612700, | Oct 29 2010 | Veritas Technologies LLC | Method and system of performing block level duplications of cataloged backup data |
| 8635209, | Jun 21 2005 | Apple Inc. | Peer-to-peer syncing in a decentralized environment |
| 8719222, | Jun 27 2008 | Microsoft Technology Licensing, LLC | Synchronization and collaboration within peer-to-peer and client/server environments |
| 8769033, | Mar 03 2006 | Microsoft Technology Licensing, LLC | Identifying changes to media-device contents |
| 8782236, | Jun 16 2009 | Amazon Technologies, Inc | Managing resources using resource expiration data |
| 8887297, | Jul 13 2007 | Microsoft Technology Licensing, LLC | Creating and validating cryptographically secured documents |
| 8887298, | Jul 13 2007 | Microsoft Technology Licensing, LLC | Updating and validating documents secured cryptographically |
| 8924528, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Latency measurement in resource requests |
| 8930513, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Latency measurement in resource requests |
| 8930544, | Mar 31 2008 | Amazon Technologies, Inc. | Network resource identification |
| 8938526, | Sep 28 2010 | Amazon Technologies, Inc. | Request routing management based on network components |
| 8996664, | Mar 27 2009 | Amazon Technologies, Inc. | Translation of resource identifiers using popularity information upon client request |
| 9003035, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Point of presence management in request routing |
| 9003040, | Nov 22 2010 | Amazon Technologies, Inc. | Request routing processing |
| 9009286, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 9021127, | Nov 17 2008 | Amazon Technologies, Inc | Updating routing information based on client location |
| 9021128, | Jun 30 2008 | Amazon Technologies, Inc. | Request routing using network computing components |
| 9021129, | Nov 17 2008 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| 9026616, | Mar 31 2008 | Amazon Technologies, Inc. | Content delivery reconciliation |
| 9083675, | Mar 27 2009 | Amazon Technologies, Inc. | Translation of resource identifiers using popularity information upon client request |
| 9083743, | Mar 21 2012 | Amazon Technologies, Inc | Managing request routing information utilizing performance information |
| 9106701, | Sep 28 2010 | Amazon Technologies, Inc. | Request routing management based on network components |
| 9130756, | Sep 04 2009 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
| 9135048, | Sep 20 2012 | Amazon Technologies, Inc | Automated profiling of resource usage |
| 9154551, | Jun 11 2012 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| 9160703, | Sep 28 2010 | Amazon Technologies, Inc. | Request routing management based on network components |
| 9172674, | Mar 21 2012 | Amazon Technologies, Inc | Managing request routing information utilizing performance information |
| 9176894, | Jun 16 2009 | Amazon Technologies, Inc. | Managing resources using resource expiration data |
| 9185012, | Sep 28 2010 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| 9191338, | Sep 28 2010 | Amazon Technologies, Inc. | Request routing in a networked environment |
| 9191458, | Mar 27 2009 | Amazon Technologies, Inc. | Request routing using a popularity identifier at a DNS nameserver |
| 9208097, | Mar 31 2008 | Amazon Technologies, Inc. | Cache optimization |
| 9210235, | Mar 31 2008 | Amazon Technologies, Inc. | Client side cache management |
| 9237114, | Mar 27 2009 | Amazon Technologies, Inc | Managing resources in resource cache components |
| 9246776, | Oct 02 2009 | Amazon Technologies, Inc. | Forward-based resource delivery network management techniques |
| 9251112, | Nov 17 2008 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| 9253065, | Sep 28 2010 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| 9288153, | Aug 26 2010 | Amazon Technologies, Inc. | Processing encoded content |
| 9294391, | Jun 04 2013 | Amazon Technologies, Inc | Managing network computing components utilizing request routing |
| 9323577, | Sep 20 2012 | Amazon Technologies, Inc | Automated profiling of resource usage |
| 9332078, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 9391949, | Dec 03 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Request routing processing |
| 9407681, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Latency measurement in resource requests |
| 9407699, | Mar 31 2008 | Amazon Technologies, Inc. | Content management |
| 9444759, | Nov 17 2008 | Amazon Technologies, Inc. | Service provider registration by a content broker |
| 9451046, | Nov 17 2008 | Amazon Technologies, Inc. | Managing CDN registration by a storage provider |
| 9479476, | Mar 31 2008 | Amazon Technologies, Inc. | Processing of DNS queries |
| 9495338, | Jan 28 2010 | Amazon Technologies, Inc | Content distribution network |
| 9497259, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 9515949, | Nov 17 2008 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| 9525659, | Sep 04 2012 | Amazon Technologies, Inc | Request routing utilizing point of presence load information |
| 9544394, | Mar 31 2008 | Amazon Technologies, Inc. | Network resource identification |
| 9560130, | Sep 30 2010 | Microsoft Technology Licensing, LLC | Presenting availability statuses of synchronized objects |
| 9571389, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 9590946, | Nov 17 2008 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| 9608957, | Jun 30 2008 | Amazon Technologies, Inc. | Request routing using network computing components |
| 9621660, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 9628554, | Feb 10 2012 | Amazon Technologies, Inc. | Dynamic content delivery |
| 9712325, | Sep 04 2009 | Amazon Technologies, Inc. | Managing secure content in a content delivery network |
| 9712484, | Sep 28 2010 | Amazon Technologies, Inc.; Amazon Technologies, Inc | Managing request routing information utilizing client identifiers |
| 9734472, | Nov 17 2008 | Amazon Technologies, Inc. | Request routing utilizing cost information |
| 9742795, | Sep 24 2015 | Amazon Technologies, Inc | Mitigating network attacks |
| 9774619, | Sep 24 2015 | Amazon Technologies, Inc | Mitigating network attacks |
| 9787599, | Nov 17 2008 | Amazon Technologies, Inc. | Managing content delivery network service providers |
| 9787775, | Sep 28 2010 | Amazon Technologies, Inc. | Point of presence management in request routing |
| 9794216, | Sep 28 2010 | Amazon Technologies, Inc. | Request routing in a networked environment |
| 9794281, | Sep 24 2015 | Amazon Technologies, Inc | Identifying sources of network attacks |
| 9800539, | Sep 28 2010 | Amazon Technologies, Inc. | Request routing management based on network components |
| 9819567, | Mar 30 2015 | Amazon Technologies, Inc | Traffic surge management for points of presence |
| 9832141, | May 13 2015 | Amazon Technologies, Inc | Routing based request correlation |
| 9843634, | Sep 21 2006 | Samsung Electronics Co., Ltd. | Method and apparatus for synchronizing content directory service objects of universal plug and play media servers |
| 9887915, | Mar 31 2008 | Amazon Technologies, Inc. | Request routing based on class |
| 9887931, | Mar 30 2015 | Amazon Technologies, Inc | Traffic surge management for points of presence |
| 9887932, | Mar 30 2015 | Amazon Technologies, Inc | Traffic surge management for points of presence |
| 9888089, | Mar 31 2008 | Amazon Technologies, Inc. | Client side cache management |
| 9893957, | Oct 02 2009 | Amazon Technologies, Inc. | Forward-based resource delivery network management techniques |
| 9894168, | Mar 31 2008 | Amazon Technologies, Inc. | Locality based content distribution |
| 9912740, | Jun 30 2008 | Amazon Technologies, Inc. | Latency measurement in resource requests |
| 9929959, | Jun 04 2013 | Amazon Technologies, Inc. | Managing network computing components utilizing request routing |
| 9930131, | Nov 22 2010 | Amazon Technologies, Inc. | Request routing processing |
| 9954934, | Mar 31 2008 | Amazon Technologies, Inc. | Content delivery reconciliation |
| 9977811, | Sep 30 2010 | Microsoft Technology Licensing, LLC | Presenting availability statuses of synchronized objects |
| 9985927, | Nov 17 2008 | Amazon Technologies, Inc. | Managing content delivery network service providers by a content broker |
| 9992086, | Aug 23 2016 | Amazon Technologies, Inc | External health checking of virtual private cloud network environments |
| 9992303, | Nov 17 2008 | Amazon Technologies, Inc. | Request routing utilizing client location information |
| Patent | Priority | Assignee | Title |
| 5491800, | Dec 20 1993 | Apple Inc | Object-oriented remote procedure call networking system |
| 5613108, | Feb 24 1993 | Minolta Camera Kabushiki Kaisha | Electronic mail processing system and electronic mail processing method |
| 5632018, | Jan 18 1993 | Fujitsu Limited | Electronic mail system |
| 5771355, | Dec 21 1995 | Intel Corporation | Transmitting electronic mail by either reference or value at file-replication points to minimize costs |
| 5815663, | Mar 15 1996 | CHIARAMAIL, CORP | Distributed posting system using an indirect reference protocol |
| 5835727, | Dec 09 1996 | AMAZON COM, INC | Method and apparatus for controlling access to services within a computer network |
| 5835911, | Feb 08 1995 | Fujitsu Limited | Software distribution and maintenance system and method |
| 5887254, | Apr 26 1996 | Nokia Technologies Oy | Methods and apparatus for updating the software of a mobile terminal using the air interface |
| 5903723, | Dec 21 1995 | INCYTE PHARMACEUTICALS, INC | Method and apparatus for transmitting electronic mail attachments with attachment references |
| 5926624, | Sep 12 1996 | Audible, Inc | Digital information library and delivery system with logic for generating files targeted to the playback device |
| 5999932, | Jan 13 1998 | Symantec Corporation | System and method for filtering unsolicited electronic mail messages using data matching and heuristic processing |
| 6105063, | May 05 1998 | International Business Machines Corp.; IBM Corporation | Client-server system for maintaining application preferences in a hierarchical data structure according to user and user group or terminal and terminal group contexts |
| 6169909, | Jul 14 1997 | NEC Corporation | Mobile communication system with re-connect function for non-speech data communications |
| 6170060, | Oct 03 1997 | Audible, Inc | Method and apparatus for targeting a digital information playback device |
| 6182117, | May 31 1995 | Meta Platforms, Inc | Method and apparatus for workgroup information replication |
| 6199076, | Oct 02 1996 | PERSONAL AUDIO LLC | Audio program player including a dynamic program selection controller |
| 6263347, | Apr 28 1998 | NEC PERSONAL COMPUTERS, LTD | System for linking data between computer and portable remote terminal and data linking method therefor |
| 6339787, | Nov 30 1995 | Comtech EF Data Corporation | Apparatus and method for increasing speed in a network file/object oriented server/client system |
| 6412017, | Jul 01 1996 | Microsoft Technology Licensing, LLC | Urgent replication facility |
| 6430576, | May 10 1999 | Apple Inc | Distributing and synchronizing objects |
| 6477543, | Oct 23 1998 | Alibaba Group Holding Limited | Method, apparatus and program storage device for a client and adaptive synchronization and transformation server |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jan 31 2001 | PENG, LUOSHENG | DOONGO TECHNOLOGIES, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 011554 | /0014 | |
| Feb 01 2001 | Inno Path Software, Inc. | (assignment on the face of the patent) | / | |||
| Aug 09 2004 | DOONGO TECHNOLOGIES, INC | INNOPATH SOFTWARE, INC | CHANGE OF NAME SEE DOCUMENT FOR DETAILS | 015083 | /0148 | |
| Feb 24 2006 | INNOPATH SOFTWARE, INC | Silicon Valley Bank | SECURITY AGREEMENT | 017262 | /0479 | |
| Apr 04 2016 | Silicon Valley Bank | INNOPATH SOFTWARE INC | RELEASE BY SECURED PARTY SEE DOCUMENT FOR DETAILS | 038335 | /0886 | |
| Jun 07 2016 | INNOPATH SOFTWARE, INC | QUALCOMM TECHNOLOGIES, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 038943 | /0852 | |
| Sep 01 2016 | QUALCOMM TECHNOLOGIES, INC | Qualcomm Incorporated | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 039900 | /0760 |
| Date | Maintenance Fee Events |
| Feb 09 2009 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Mar 25 2013 | REM: Maintenance Fee Reminder Mailed. |
| Aug 09 2013 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Aug 09 2013 | M1555: 7.5 yr surcharge - late pmt w/in 6 mo, Large Entity. |
| Oct 25 2016 | ASPN: Payor Number Assigned. |
| Oct 25 2016 | RMPN: Payer Number De-assigned. |
| Jan 26 2017 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Aug 09 2008 | 4 years fee payment window open |
| Feb 09 2009 | 6 months grace period start (w surcharge) |
| Aug 09 2009 | patent expiry (for year 4) |
| Aug 09 2011 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Aug 09 2012 | 8 years fee payment window open |
| Feb 09 2013 | 6 months grace period start (w surcharge) |
| Aug 09 2013 | patent expiry (for year 8) |
| Aug 09 2015 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Aug 09 2016 | 12 years fee payment window open |
| Feb 09 2017 | 6 months grace period start (w surcharge) |
| Aug 09 2017 | patent expiry (for year 12) |
| Aug 09 2019 | 2 years to revive unintentionally abandoned end. (for year 12) |