Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
  • G06F16/275—Synchronous replication
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F15/00—Digital computers in general; Data processing equipment in general
  • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
  • G06F15/163—Interprocessor communication
  • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F12/00—Accessing, addressing or allocating within memory systems or architectures

Definitions

• the present invention relates to a method and a device, respectively, for synchronizing of data between a synchronizing client device and a synchronizing server device and further to the respective synchronizing devices. More particular, the present invention relates to a method and a device for synchronizing of data, respectively, allowing for improved handling of an interruption of an active synchronization process.
• the synchronization of data is a well known concept or technique for users, respectively, having at least two different electronic devices in use and processing the same kind of data with these electronic devices, hi general, synchronization takes place between a terminal device (e.g., a mobile phone) and a server device (e.g., an application in a local PC or a dedicated synchronization server).
• Terminals such as portable computers, PDA terminals (personal digital assistant), mobile phones, mobile stations or pagers
• networked devices acting as synchronization servers being represented by networked applications, applications of desktop computers or with other managing applications of data stores of telecommunications systems, wherein the term "data store" should be understood as broad as possible, i.e. shall cover arbitrary sets of data, h particular data of a calendar, data of contacts, data of e-mail applications as well as data relating to device/application settings and configurations are typically synchronized.
• Synchronization has been based on the use of different manufacturer-specific protocols which are incompatible. This restricts the use of terminal or data types and often causes troubles to the user, m mobile communication, in particular, it is important that data can be retrieved and updated regardless of the terminal and application used.
• synchronization markup language SyncML To improve synchronization of application data, a language known and referred to as synchronization markup language SyncML has been designed, which is based on the extensible markup language (XML).
• XML extensible markup language
• SyncML synchronization protocol which employs messages in the SyncML format, data of any application can be synchronized between networked terminals and a network server of any kind.
• the SyncML synchronization protocol works both in wireless and in fixed networks and supports several transmission protocols.
• the above presented SyncML synchronization technology addresses in particular the synchronization of data stores or databases, respectively.
• a synchronization of data records is performed at a distinct point in time in order to harmonize, i.e. to bring into correspondence, two distinct predefined sets of data records stored at different storage places, i.e. at different synchronizing devices managing and employing the storage places, resulting in two equivalent sets of data records at both storage places at this distinct point in time.
• the synchronization of data records performed at a distinct point in time is further designated as a synchronization session.
• the synchronization of the sets of data records is obtained during such a synchronization session by exchanging information, instructions and commands allowing both participating synchronizing devices for modifying their stored sets of data records resulting in a harmonization of them, wherein such modification operations comprises adding of data, removing of data, appending data to current data, updating of data and the like.
• the exchange of required information and commands is for practical purposes carried out by communicating between the synchronizing devices one or more messages each containing a distinct subset of the total required information, instructions and commands necessary to perform the harmonizing at each synchronizing devices.
• each of the one or more messages is acknowledged in order to indicate successful operation in accordance with its message information contained therein.
• synchronization processes as described above can be handled and performed in either a full synchronization process also designated as slow synchronization or an incremental synchronization process also designated as normal or fast synchronization, respectively.
• a full or slow synchronization process respectively, all predefined sets of data records in both participating synchronizing devices are harmonized.
• a point in time of the last completed synchronization session is logged in both participating synchronizing devices and in case the logged point in time stored in both synchronizing devices matches only data records being modified since this logged point in time are selected for synchronization all other are excluded from the synchronization process.
• a change log may be maintained by the synchronizing devices logging the modification, adding or deleting point of time of data records.
• the modifications may be determined in another manner such as investigating the modification time stamps of the records, if such exist.
• Both synchronization processes i.e. the so-called slow and the so-called fast (normal) synchronization are defined and used in the SyncML standard. Further types of synchronization processes are available and used but these further synchronization processes can be reduced to the aforementioned basic synchronization processes.
• each successful synchromzation of a data record or a batch of data records is acknowledged and logged by the synchronizing devices preferably in such one or more change logs
• the acknowledgements are handled at the end of a synchronization session, i.e. as soon as both synchronizing devices indicate a proper closing of the synchronization session and the corresponding employed communication connected.
• the handling of the acknowledgements at the end of a synchronization session and the updating of a point in time specifying the last completed synchronization session is operated substantially at the same time.
• the synchronization session is carried out in the way of a slow synchronization process taking into account the point in time specifying the last completed synchronization session is obviously not required.
• the first implementation primarily addresses synchronization applications used for synchronizing for example distributed databases with high-speed connection to each other in order to maintain and ensure data integrity.
• the capacity requirements of storing and maintaining change logs for each data record, the requirement of processing capability for processing the change logs as well as the requirement of network bandwidth for exchanging necessary acknowledgements are of minor importance, hi view of synchronizing data stored in small electronic device such as mobile phones, handhelds, personal digital assistants, communicators and the like the storage capacity and processing power are limited such that storing, maintaining and processing of change logs for each data record is cumbersome, inefficient and sometimes not even possible.
• the network traffic resulting from the required acknowledgements is not acceptable as it is also expensive and time-intensive in mobile communication environments.
• the second implementation wherein the updating of time stamps and handling the acknowledgements for the item is carried out at the end of the session, is suitable for use in small electronic devices and supported by the SyncML standard. Nevertheless, this implementation raises the problem that an interruption of a currently performed synchronization session is not provided for.
• the maintaining of the synchronization information exchanged during a partially operated synchronization session is not possible since, the updating of the time stamps (synchronization anchors) and the handling of the acknowledgements at the end of the synchronization session is not achieved due to the interruption.
• the synchronization session has to be repeated completely in order to ensure data integrity.
• an even huge number of messages are exchanged during a single synchronization session normally comprising several synchronization messages.
• 400 data records of 500 data records may have been synchronized during a synchronization session and an interruption occurs.
• all of the 500 data records have to synchronized again independent of whether the synchronization is operated as either a fast or a slow synchronization process.
• the object of the invention is to provide a method allowing for resuming an interrupted synchronization session in order to avoid a complete repetition of the interrupted synchronization session.
• the provision for resuming an interrupted synchronization session is constructed such that neither high storage capacities, high processing power, high number of interchanged acknowledgements nor high communication bandwidth are required.
• the method is suitable to be implemented in a small electronic device in an economic way.
• a method allowing for resuming a preceding incomplete synchronization session is provided, wherein the preceding incomplete synchronization session has been interrupted during its operation.
• the resuming of the preceding incomplete synchronization session is achieved by the following operations.
• a communication connection for synchronization of data between a first device and a second device is established.
• the first device and a second device comprise each a set of data records to be synchronized.
• data records are organized in a data storage or a database maintained by a corresponding application.
• the present invention provides a method for resuming an interruption of a previous incomplete synchronization session related to an exchange of data between two devices. The method features the step of sending from the first device to the second device an alert for resuming signal containing information related to a request for the resumption of the previous incomplete synchronization session.
• the alert for resuming signal may at least be a direct alert code or the like directly indicating a resume session or a signal that is deductable by the server, e.g., indication of the time stamps to be used in the session or some other identification of the session.
• the method also features the step of sending from the second device to the first device a status for the alert signal indicative of information related to a sync type to be carried out.
• the information related to the status of the alert for resume signal may include information for overriding an earlier sync type of the previous incomplete synchronization session.
• a first update identifier and a second identifier are communicated either from the first device to the second device or from the second device to the first device.
• the direction of transmission depends on what device indicates the resuming of the preceding incomplete synchronization session and the direction of the synchronization.
• the indicating device transmits both identifiers to the other one.
• the first update identifier specifies a preceding complete synchronization session having been performed between the first device and the second device.
• the first update identifier has been stored in the first device and the second device during an initialization of the preceding complete synchronization session. More specifically, the value of the identifier is stored, but the name or storage place of the value may vary according to the implementation.
• the first update identifier is a time stamp used for logging the initiation time of the preceding complete synchronization session.
• the identifier can be any numerical value, for example a monotonically increasing numeric integer string, a text string, or a mixture of these, created in an orderly fashion or at least to some degree or part randomly.
• the second update identifier specifies a preceding incomplete synchronization session having been performed between the first device and the second device.
• the second update identifier has been stored in the first device and the second device during an initialization of the preceding incomplete synchronization session.
• the second update identifier is analogously also a time stamp or such used for indicating the initiation time of the preceding synchronization session that was interrupted.
• the behavior and use of the second update identifier is defined only during a synchronization session, but not after an interruption or a completion of a session.
• the method according to the present method has four steps for synchronizing.
• a first step includes establishing a communication connection for synchronization of data between a first device and a second device each comprising a set of data to be synchronized.
• a second step includes transmitting a first update identifier and a second update identifier, the first update identifier denoting a preceding complete synchronization event having been performed between the first device and the second device, a value of the first update identifier having been stored at least in the first device, the second update identifier denoting a preceding incomplete synchronization event having been started between the first device and the second device, a value of the second update identifier having been stored at least in the first device.
• a third step includes retrieving or forming an indication of data that has been successfully synchronized during the preceding incomplete synchronization event.
• the first step includes using the indication, synchronizing data that has not been successfully synchronized during the preceding incomplete synchronization event; and (4) at least in the first device, updating the value of the first update identifier with said value of the second update identifier.
• the method may also include a step of transmitting additional information relating to the preceding incomplete synchronization event and comprising at least one information out of a group comprising information about the preceding incomplete synchronization, and information about data successfully synchronized in accordance with received synchronization related information.
• the method may also include a step that is performed in at least one of the first device and the second device of comparing, in a first comparison, a value of the first update identifier transmitted from the first device with a value of the second update identifier of the first device stored in the second device; and of comparing, in a second comparison, a value of the second update identifier transmitted from the first device with a value of the second update identifier of the first device stored in the second device, as well as carrying out at least one of the following options:
• the step of establishing a communication connection for synchronization may include transmitting an initial message instructing at least one of the first device and the second device to prepare for resuming the preceding incomplete synchronization.
• the synchronization may be based on a synchronization protocol in accordance with the SyncML standard, the first update identifier being a LAST synchronization anchor.
• the second update identifier may be at least one of a NEXT synchronization anchor and a PAUSE synchronization anchor.
• the additional information relating to the preceding incomplete synchronization event may include at least one information out of a group of a synchronization event session identifier (session ID), a synchronization message identifier (message ID), and one or more identifiers of acknowledged data and their respective data store.
• the additional information has been stored at least in the first device before transmitting the first and second update identifiers. hi the method, data has been successfully synchronized if the acknowledgement for the data or the message containing the data has been successfully received, and the acknowledgement indicates either a positive or a negative status of the synchronization of the data or the message.
• the invention also provides a software tool for synchronizing, comprising program portions for carrying out the steps of the aforementioned method, wherein the software tool is for being implemented in a computer program for being executed on a processing device, a terminal device, a communication terminal device or a network device, as well as a computer program or computer program product for synchronizing the same.
• the invention also provides a device for use in a network and capable of synchronizing data having a storage medium, a communication interface, a retrieving or a forming component and an updating component.
• the storage medium has predefined sets of data to be synchronized.
• the communication interface establishes a communication connection for synchronization of data to another device for use in a network, for communicating a first update identifier and a second update identifier with the other network device and for exchanging data with the other network device.
• the first update identifier denotes a preceding complete synchronization event having been performed with the other network device, the first update identifier having been stored at least in the network device.
• the second update identifier denotes a preceding incomplete synchromzation event, the second update identifier having been stored at least in the network device, wherein the data comprises at least data that has not been synchronized during the preceding incomplete synchronization event.
• the retrieving or a forming component retrieves or forms an indication of data that has been synchronized during the preceding incomplete synchronization event, the indication having been stored in the network device.
• the synchronizing component synchronizes data in accordance with the indication.
• the updating component updates contents of the first update identifier stored with contents of the second update identifier stored.
• the communication interface may be adapted for transmitting supplementary additional information relating to the preceding incomplete synchronization event.
• the additional information may include at least one information out of a group comprising information about the preceding incomplete synchronization, information about a last successful exchange of synchronization related information and information about data successfully synchronized in accordance with received synchronization related information.
• the device may also include a component for comparing, such that, in a first comparison a value of the first update identifier transmitted from the device with a value of the second update identifier of the device stored in the other device, and, in a second comparison, a value of the second update identifier transmitted from the first device with a value of the second update identifier of the device stored in the other device.
• the component for carrying out at least one of the aforementioned options discussed above in relation to the method.
• the invention also provides a system for synchronizing, comprising a first network device and a second network device, wherein each device includes elements for performing steps similar to that discussed above in relation to the overall method and device of the invention.
• FIG. 1 shows a schematic diagram illustrating a set of exemplary electronic devices between which synchronization of information is operable
• Fig. 2 shows a chronological sequence diagram of a synchronization process comprising several messages exchanged between a synchronizing client device and a synchronizing server device according to an embodiment of the invention
• Fig. 3 a shows a chronological sequence diagram of a synchronization process analogously to
• FIG. 2 shows a chronological sequence diagram of a synchronization process resuming the interrupted or stopped synchronization process of Fig. 3a according to an embodiment of the invention
• Fig. 4 shows an excerpt of a XML-coded synchronization message in accordance with the synchronization process illustrated in Fig. 3b and according to an embodiment of the invention
• Fig. 5 shows a schematic block diagram illustrating components comprised by a synchronizing client device and a synchronizing server device according to an embodiment of the invention
• Fig. 6 shows a chronological sequence diagram of a synchronization process resuming the interrupted or stopped synchronization process of Fig. 3 a according to an embodiment of the invention
• Fig. 7 shows a chronological sequence diagram of a synchronization process resuming the interrupted or stopped synchronization process of Fig. 3 a according to an embodiment of the invention.
• Fig. 8 shows a chronological sequence diagram of a synchronization process resuming the interrupted or stopped synchronization process of Fig. 3 a according to an embodiment of the invention.
• Fig. 1 shows a schematic diagram illustrating a set of exemplary electronic devices between which synchronization of information is operable.
• a certain data store content of for example a mobile terminal shall be harmonized with data store content provided by designated devices for example offering a central storage of this data store content to be accessible by means of several different mobile and/or stationary terminals.
• mobile terminals act as synchronization clients harmonizing or synchronizing data relating to certain predefined applications running on these synchronization clients with the contents of a data store or several data stores provided by dedicated server devices centrally storing the application related data.
• Fig. 1 illustrates a plurality of possible client devices and server devices operable with the synchronization operation.
• client devices are mobile stations like mobile phones 17 or personal digital assistants (PDA), mobile computers like notebooks 15, electronic devices storing digital data like digital cameras 16 as well as stationary terminals like desktop computers (PC).
• dedicated synchronization server devices maybe stationary terminals like desktop computers 10, dedicated network servers 11 e.g. operating their synchronization capability as networked synchronization applications or even mobile computers like notebooks 12 e.g. running synchronization server applications.
• client device functionality is not limited to mobile terminals as described above although the presented concept of synchronization is described in view of mobile terminals connected to dedicated serving devices.
• a corresponding synchronization process in accordance with the SyncML protocol standard is established via an appropriate logical communication connection.
• the logical communication connection is provided by any communication networks in combination with transport protocols to which the synchronization protocol is adapted.
• a suitable communication network may be a local area network (LAN) or a wide area network (WAN) which may comprise the internet and an intranet of a company but also wire-based serial networks such as universal serial bus (USB) or standardized serial communication (e.g. RS- 232).
• the participating synchronization devices may be also connected via a wireless communication network such as a mobile network supporting global system for mobile communication (GSM) services and/or supporting general packet radio services (GPRS), a third generation mobile communication network such as a universal mobile telecommunication system (UMTS) network, a wireless local area network (WLAN), short range radio communication network, such as a Bluetooth network, wireless local loop (WLL) or an infrared network (IrDA).
• GSM global system for mobile communication
• GPRS general packet radio services
• UMTS universal mobile telecommunication system
• WLAN wireless local area network
• short range radio communication network such as a Bluetooth network
• WLL wireless local loop
• IrDA infrared network
• the logical communication connection between the participating synchronization devices may be provided by a single communication network of the aforementioned type but also may be provided by several communication networks of the aforementioned types interconnected by dedicated network routing devices interconnecting communication networks connections and, if necessary, translating between data protocols of the respective employed communication networks.
• the SyncML device management protocol is implemented on the top of appropriate protocols in accordance with the type of employed communication network.
• Appropriate protocols on which top the SyncML synchronization protocol can be implemented are the hyper text transfer protocol (HTTP), the wireless session protocol (WSP) of the wireless application protocol (WAP) standard, the object exchange protocol (OBEX) used for cable connections, such as universal serial bus (USB) or RS-232, for short-range radio frequency connections (Bluetooth) or for infrared connections (IrDA), the transport control protocol/internet protocol (TCP/IP) stack and on top of the transport layer service which is offered by the e-mail protocol (e.g. simple mail transfer protocol, SMTP).
• HTTP hyper text transfer protocol
• WSP wireless session protocol
• OBEX object exchange protocol
• USB universal serial bus
• RS-232 for short-range radio frequency connections
• IrDA infrared connections
• TCP/IP transport control protocol/internet protocol
• TCP/IP transport control protocol/internet protocol
• Transfer at the lower layer can be performed according to the underlying network using e.g. short messages SMS (short message service) or other signaling type transmission methods (e.g. USSD; unstructured supplementary service data), circuit-switched data calls, packet-switched data transfer services as well as paging message service, messages provided via cell broadcast and the like.
• SMS short message service
• USSD unstructured supplementary service data
• circuit-switched data calls e.g. USSD; unstructured supplementary service data
• packet-switched data transfer services e.g. USSD; unstructured supplementary service data
• packet-switched data transfer services as well as paging message service
• messages provided via cell broadcast and the like e.g. short messages SMS (short message service) or other signaling type transmission methods (e.g. USSD; unstructured supplementary service data), circuit-switched data calls, packet-switched data transfer services as well as paging message service, messages provided via cell broadcast and the like.
• the arbitrary set(s) of data can be organized in one or more databases including data records providing data to be accessed.
• data store shall be understood as covering network data services or networked service(s), respectively, i.e. as covering arbitrary set(s) of data provided by networked service(s) to be accessed similar to data store(s).
• networks services are based on data stores having a specific service related data store content.
• sequence diagrams depict operational sequences according to embodiments of the methods of the present invention. The depicted sequences of operations are just illustrative and not limiting thereto. Further realizations based on similar or related operational sequences are also possible.
• Fig. 2 shows a chronological sequence diagram of a synchromzation process comprising several messages exchanged between a synchronizing client device and a synchronizing server device according to an embodiment of the invention.
• SyncML synchronization session are conceptually bounded into so called SyncML packages.
• the SyncML packages is simply a conceptual framework for one or more SyncML messages that are physically exchanged between the synchronizing devices and that are required to convey a set of synchronization information and commands. Not all SyncML packages are involved in any of the types of synchronization provided by the SyncML standard. The exact number of the SyncML messages depends on the amount of information to be conveyed. A coarse overview of the SyncML packages is described in the following list. A detailed description can be obtained from the SyncML standard documents.
• a client device can receive unsolicited messages, so-called “notifications” or “alerts”, instructing to cause the receiving device to establish a back connecting for initiating a synchronization session. Note that an identical effect to receiving a notification can be caused in other ways.
• Package 1 - initialization from client device to server device One or more initialization messages are transmitted for example comprising: client device information (device identifier etc.), client device properties, client authentication, type of synchronization, identifications of databases of which data records are to be synchronized, stored LAST anchor, new NEXT anchor, etc.
• Package 2 initialization from server device to client device.
• One or more initialization messages are transmitted for example comprising: server device information (device identifier etc.), server device properties, server authentication, response and status information about information comprised in one or more client initialization messages.
• Packages 1 and 2 are part of the initialization phase.
• the following packages 3 to 6 are part of the synchronization phase of the synchromzation message.
• One or more client synchronization messages are transmitted for example comprising: client data modifications, i.e. any changes to the data of the client databases identified in the synchronization initialization, etc. hi the case of a fast synchronization process, only data records that have been modified since the previous synchronization session (LAST anchor) are reported, in the case of a slow synchronization process all data records are reported.
• client data modifications i.e. any changes to the data of the client databases identified in the synchronization initialization, etc.
• One or more server synchronization messages are transmitted for example comprising: information about the server's analysis of transmitted client data modifications, and also server data modifications, i.e. any changes to the data of the server databases identified in the synchronization initialization, etc. hi the case of a fast synchronization process, only data records that have been modified since the previous synchronization session (LAST anchor) are reported, in the case of a slow synchronization process all data records are reported.
• server data modifications i.e. any changes to the data of the server databases identified in the synchronization initialization, etc.
• Package 5 - Data update status, map operation One or more data update status messages are transmitted for example comprising information about the results of data update (synchronization due to server modifications), map operations (table) for mapping local unique identifier (LUID) and global unique identifier (GUID), etc.
• a local unique identifier is an identifier assigned to a data record and being locally unique on the client side, i.e. per device and application. The local unique identifier allows for identifying a data record.
• a global unique identifier is an identifier assigned to a data record and being locally unique on the server side.
• One or more map acknowledgement messages are transmitted for example comprising acknowledgements informing the client device of receiving one or more data update status messages by the server, etc.
• a client message in accordance with package 3 may cause a server response message in accordance with package 4 and vice verse depending on the synchronization information and commands contained in the client message or the server message, respectively.
• Each message of a synchronization message contains a session identifier (session ID) such that the messages can be associated to a distinct synchronization session.
• Each message contains a message identifier (message ID) such that misalignments of exchanged messages at the client device and at the server device is prevented, respectively.
• each last message of each package type contains a final indicator to indicate that this is the last one.
• the synchronization process is further distinguished by what kind of information (which data records) is to be synchronized (a slow or a fast synchronization, i.e. total number of data records or only modifications since a distinct point in time), in which device(s) (in either the client device or the server device or in both devices) synchronization is performed and from which device synchronization is initiated.
• the type of synchronization can be e.g. two-way sync, slow sync, one-way sync from client only, refresh sync from client only, oneway sync from server only, refresh sync from server only and server alerted sync.
• the chronological sequence diagram and the synchronization process shown in Fig.2 are based on a fast two-way synchronization type, respectively, although the scope of the invention is intended to include other synchronization types.
• a client 100 synchronizes with the server 110.
• the depicted synchronization session consists of an initialization phase 210 followed by the synchronization phase each comprising several synchronization messages. All synchronization messages contain a same session ID (not depicted).
• both devices exchange device information (device identifiers etc.), device properties, device authentication information.
• the client 100 further defines the type of synchronization (herein fast two-way synchronization type) and reports the LAST anchor stored and a NEXT anchor newly defined to the server 110.
• the server 110 compares the LAST anchor transmitted by the client 100 with a corresponding value stored in the server 110 and conforms the LAST anchor and the NEXT anchor if the stored and received LAST anchors match to allow for fast synchronizing.
• the state (content) of the NEXT anchor is undefined (by the prior art, i.e.
• the information exchange during the initialization phase 210 is illustrated by a first operation 200 referring to a client initialization message corresponding to a package 1 message and a second operation
• a client synchronization message (package 3 message type) referred to by operation 203 contains a first batch of client modifications, herein five modifications of a total often identified modifications.
• client modifications include commands and/or data content.
• the commands comprise above all an add, update, delete, etc. which are completed with data content to synchronize a respective data record. Additionally, this message further contains status information in accordance with the previous server initialization message.
• the server 110 receives this first client synchronization message, analyzes the received client modifications, solves possible conflicts emerging from the client modifications and processes the client modifications (operation 212).
• a corresponding server synchromzation message (package 4 message type) referred to by operation 204 is transmitted to the client containing client modification acknowledgements and status information of the analyze and synchronization processing.
• Both the client synchronization message referred to by operation 203 and the server synchronization message referred to by operation 204 are identifiable by a common message ID, herein message ID 2.
• message ID 2 a common message ID
• the message numbering may deviate from what has been presented above. Indeed, the only purpose to be served by the message numbering is that each device has a consistent view of the message numbers, i.e., the numbering towards the client and the server do not even have to match.
• a following client synchronization message (package 3 message type) referred to by an operation 206 contains a second batch of client modifications, herein remaining five modifications often total identified modifications.
• This client synchronization message contains additionally a final indicator indicating that this is the last client synchronization message containing client modifications.
• the server 110 receives this last client synchronization message, analyzes the received client modifications, solves possible conflicts emerging from the client modifications, processes the client modifications and due to the final indicator prepares (identified under consideration of the server's LAST anchor) server modifications to be transmitted to the client 100 (operation 212).
• a corresponding server synchronization message (package 4 message type) referred to by an operation 207 is transmitted to the client containing server modifications, client modification acknowledgements and status information of the analyze and synchronization processing, h accordance with the synchronization session depicted in Fig. 2, a single server synchronization message is sufficient for transmitting all identified server modifications to the client such that this message additionally contains a final indicator.
• the client 100 processes the received server modifications. Both messages referred to by operations 206 and 207, respectively, contain the same message ID 3.
• a client update status message (package 5 message type) referred to by operation 208 is subsequently conveyed to the server 110 containing acknowledge information and synchronization status information due to the server modifications and if necessary map operations to the server 110 processing the data record map table assigning local unique identifiers and global unique identifiers. Finally and not depicted the client update status message may be responded by the server 110 with one or more map acknowledgement messages (package 6 message type).
• the synchronization session and the communication connection through which the synchronization messages of this session are communicated are closed, hi the case where no error is detected regarding the finalizing of the synchronization session and the communication connection, the content of the NEXT anchor defined at the beginning of the synchronization session stored .
• This assignment is performed at the client 100 in an operation 215 and at the server in an operation 216 (in fact, the server may not call the anchor LAST, but nevertheless, the value stored to the anchor is the value of the NEXT anchor sent by the client).
• the server may not call the anchor LAST, but nevertheless, the value stored to the anchor is the value of the NEXT anchor sent by the client).
• the defining of the NEXT anchor at the beginning of a synchronization session and the assigning of the NEXT anchor content to the LAST anchor after a proper finalization of the synchronization session prevent conflicts due to modification of data records on the client side or server side during the synchronization process.
• the content of the depicted LAST anchors and NEXT anchors are just to enlighten their usage.
• the LAST anchors and the NEXT anchors are normally composed of or derived from a date value and a time value, or they are numerical values of other kind. This kind of composing may ensure to generate an unambiguous LAST and NEXT anchors, respectively.
• Fig. 3a shows a chronological sequence diagram of a synchronization process analogously to Fig. 2 and being interrupted or stopped according to an embodiment of the invention.
• the synchronization session depicted in Fig. 3 a shall be identical to this one presented with reference to Fig. 2, i.e. the initial conditions, the operations 200 - 204 and the operations 210 - 212 are performed in the same way.
• the operations depicted in Fig. 3a and the respective operations depicted in Fig. 2 and common with Fig. 3a are referenced by the same reference numerals.
• the initialization phase and the corresponding initialization messages of the client 100 and the server 110 are omitted.
• the operation 203 referring to the first client synchromzation message (package 3 type) containing the first 5 of 10 client modifications and the operation 204 referring to the first server synchronization message (package 4 message type) is shown containing status information corresponding to the client modifications.
• an operation 205 the synchronization is interrupted or stopped. An interruption or stop can be caused due to several reasons, for example the synchronization session is stopped on user interaction, on user initiative, on power loss of the client 100 or server 110 e.g. due to lack of battery or accumulator capacity, on loss of the communication connection e.g. due to loss of coverage in radio communication networks, due to interference in the communication connections only to present a selection of possible reasons.
• the client 100 and the server 110 log information relating to the incomplete synchronization session.
• This information allowing for resuming the incomplete synchronization session comprises at least the LAST anchor and NEXT anchor at least in the client 100 which are logged in both the client 100 and the server 110.
• this information can also comprise a session ID of the incomplete synchronization session, a message ID of the last message properly transmitted and for which the client 100 has received an acknowledgement, and one or more unique data record identifiers, i.e. local unique identifiers or global unique identifiers of data records according to those modifications have being transmitted and transmissions of those have being acknowledged during the incomplete synchronization session.
• a new anchor e.g. a PAUSE anchor
• a PAUSE anchor is defined and employed especially to be used for resuming an incomplete synchronization session.
• inventive concept is described with reference to the NEXT anchor but not limiting the inventive concept thereto.
• PAUSE anchor is simply to be replaced by the term PAUSE anchor.
• Fig. 3b shows a chronological sequence diagram of a synchronization session carrying on the interrupted or stopped incomplete synchronization session of Fig. 3a according to an embodiment of the invention.
• the resuming synchronization session is initiated by an operation 250 referring to a new initialization message (package 1 type) comprising an alert command indicating the intend of the client 100 to the server 110 so as to resume the previous incomplete synchronization session described above with reference to Fig. 3 a.
• This new initialization message contains at least the LAST anchor and the NEXT anchor which have been logged in accordance with the interruption of the previous incomplete synchronization session (operation 205 in Fig. 3 a).
• the server receives these LAST anchor and the NEXT anchor from the client and compares them with those LAST anchor and the NEXT anchor logged by itself. It shall be noted that in comparison to the synchronization session presented in Fig. 2 and its analogy presented in Fig. 3a the NEXT anchor has a well defined state and content on the server side, respectively.
• At least one of the client 100 and/or the server 110 may either command, initiate or carry out any one of the following four different options depending on whether either the LAST anchors match and/or whether the NEXT anchors match, as follows: 1) hi case the received and the logged LAST anchors and the received and the logged NEXT anchors match, the server 110 confirms the resuming of the incomplete synchronization session (resuming fast synchronization) by transmitting a server initialization message (package 2 type) referring to operation 251 and containing at least the LAST anchor and NEXT anchor for acknowledgement. The confirmation for allowing for resuming may be based additionally on further information relating to the incomplete synchronization session to be resumed (refer to operation 205 in Fig. 3a). For example, the aforementioned logged session ID of the incomplete synchronization session and/or logged a message ID of the last message properly transmitted are consulted during the examination operation of the logged anchors.
• a resuming slow synchronization session is commanded by the server. This resuming slow synchronization session is not depicted in Fig. 3b. In short, the resuming slow synchronization session exchanges synchronization related information which allow to synchronize all data records predefined for being synchronized.
• the server 110 transmits a server initialization message (package 2 type) referring to operation 251 and containing at least the LAST anchor and NEXT anchor for acknowledgement.
• this information may comprise at least one of a session ID of the incomplete synchromzation session, a message ID of the last message properly transmitted and one or more unique data record identifiers, i.e. local unique identifiers or global unique identifiers of data records according to those modifications have being transmitted and transmissions of those have being acknowledged during the incomplete synchronization session.
• unique data record identifiers i.e. local unique identifiers or global unique identifiers of data records according to those modifications have being transmitted and transmissions of those have being acknowledged during the incomplete synchronization session.
• the information provided by local unique identifiers may not be sufficient and data base identifiers may have to be logged supplementary to the local unique identifiers.
• the combination of a local unique identifier and the associated data base identifier enables to determine (unambiguously) a corresponding data record referenced by the local unique identifier.
• the data base identifiers may be uniform resource locators (URI) as known in the art.
• the stored LAST anchor, the stored NEXT anchor and the stored information relating to the incomplete synchronization session allow for restoring (re-establishing) the state of the previous incomplete synchronization session at the moment of interruption. This kind of reconstruction allows now for generating the messages referred to by the operations 206 - 208 shown in Fig. 2, illustrating a complete synchronization session, and missing in Fig. 3a, illustrating the same synchronization session but incomplete due to the interruption after the transmission of the synchronization message referred to by operation 204 (Fig 2 and Fig. 3a).
• Both the new client initialization message and the server initialization message referred to by operations 250 and 251 comprise also information necessary for establishing a synchronization session such as described with reference to operations 200 and 201 shown in Fig. 2.
• the client synchronization message (package 3 type) referred to by operation 252 corresponds to the second client synchronization message referred to by operation 206 illustrated in Fig. 2.
• the client synchronization message comprises accordingly the last 5 of 10 modifications and the final instructor to indicate that this message is the last client synchronization message of the current synchronization session.
• the message numbering i.e. the message ID
• the client synchronization message in Fig. 3b has a message ID 2 subsequent to the previous message
• ID 1 of the initialization messages (referred to by operating 250 and operation 251). (It is important to note that the scope of the invention is intended to include other types of message numbering sessions.)
• the server 110 responds to the client synchronization device by transmitting a server synchronization message (package 3 type) referred to by operation 253, corresponding to the second client synchronization message referred to by operation 206 illustrated in Fig. 2.
• This server synchronization message contains server modifications, client modification acknowledgements and status information of the analyze and synchronization processing, hi accordance with the synchronization session depicted in Fig. 2, a single server synchronization message is sufficient for transmitting all identified the server modifications to the client such that this message additionally contains a final indicator.
• Both messages referred to by operations 252 and 253, respectively, contain the same message ID 2.
• a client update status message (package 5 message type) referred to by an operation 254 is subsequently conveyed to the server 110 containing acknowledge information and synchronization status information due to the server modifications and if necessary map operations to the server 110 processing the data record map table assigning local unique identifiers and global unique identifiers.
• This client update status message corresponds also and accordingly to the client update status message referred to by the operation 208 described with reference to Fig. 2.
• the client update status message may be responded to by the server 110 with one or more map acknowledgement messages
• the defining of the NEXT anchor at the beginning of a synchronization session and the assigning of the NEXT anchor content to the LAST anchor after a proper finalization of the synchronization session prevent conflicts due to modification of data records on the client side or server side during the synchronization process.
• the content the depicted LAST anchors and NEXT anchors are just to enlighten their usage.
• the LAST anchors and the NEXT anchors are normally composed of or derived from a date value and a time value. This kind of composing may ensure to generate an unambiguous LAST and NEXT anchors, respectively.
• the modifications occurred after an incomplete synchronization session can be synchronized by initiating a synchronization session after a successful resuming synchronization session, especially, a fast synchronization session can be initiated since the LAST anchor stored in the client 100 and the server 110 are updated and valid.
• acknowledgements that have been described in the context of the embodiments of the invention are to be interpreted to be any kind of responses to data received from the other end, including either a positive or a negative status of the synchronization of the data or the message.
• an acknowledgement would confirm the updating of a record, but an acknowledgement may also carry information of an unsuccessful operation, e.g., caused by a non-found record.
• the handling of such errors is not an issue of the invention, but it is left up to the implementation to take care of the errors somehow.
• the occurrence of errors should not interfere with the resumption of the session, that is, the session should resume at the first unacknowledged data item irrespective of whether there have been errors in the data items before it.
• Fig. 4 shows an excerpt of a XML-coded synchronization message in accordance with the synchronization process illustrated in Fig. 3b and according to an embodiment of the invention.
• XML industry-standard extensible markup language
• SyncML has been designed within the memory capacity of all common mobile devices both in static code and run-time execution space.
• WBXML binary coded extensible markup language
• WBXML binary coded extensible markup language
• the SyncML contains a set of well-defined messages (as shown above) being represented as XML documents or as multipurpose internet mail extension (MIME) entities.
• the representation specification specifies an XML document type description (DTD) which allow the representation of all information requires to perform synchronization including data, metadata and commands.
• the synchronization specification specifies the SyncML messages that conform to the DTD in order to allow a SyncML client and SyncML server to exchange additions, deletion, updates and other status information.
• DTDs define the representation of information on the device (such as memory capacity) and of various types of meta-information (such as security credentials).
• SyncML messages are conceptually based on a container concept as defined by the representation protocol.
• the each SyncML messages contains a SyncML header section and a SyncML body section.
• the SyncML header contains routing, session, authentication and message information, whereas the SyncML body section contains various well-defined synchronization data comprising status information and synchronization commands, each forming a sub-container.
• the XML-based coding presented in Fig. 4 is an excerpt of an example plain text coding of a SyncML message in accordance with the client synchronization message referred to by operation 252 described with reference to Fig 3b.
• the depicted XML-based coding contains the SyncML header section extending from line 3 to line 9 and the SyncML body section extending from line 10 to line 57.
• Line 1 and line 2 contain common information on the XML-coding employed and the character encoding used for textual representation and the SyncML versioning information.
• Each SyncML header contains a document type definition versioning information
• the SyncML body contains several logical and independent subsection.
• a first status information subsection extends from line 11 to line 19.
• This first status information subsection relates to the reference addressing of the data records to be synchronized, hi particular, the target reference (TargetRef, line 16) defines an international mobile equipment identifier (IMEi) for addressing the client, in this case a cellular communication device, whereas the source reference (SourceRef, line 17) defines a uniform resource identifier (URI) for addressing the server, in this case a networked server device accessible via HTTP (hypertext transfer protocol). Further addressing of individual data records and data storage is based on this reference address information.
• IMEi international mobile equipment identifier
• URI uniform resource identifier
• An arbitrary number of further status information subsection can also be comprised which is indicated by the second status information subsection extending from line 20 to line 22.
• acknowledgments are coded as status information.
• the SyncML body section contains further a synchronization subsection which is further subdivided.
• a client indicated modification concerning an addition of an contact is comprised.
• Line 26 contains the relative addressing path of the contacts database of the client whereas line 29 contains the relative addressing path of the contacts database of the server.
• the relative addressing paths are relative to the reference addressing described above.
• the Meta subsection extending from line 31 to line 36 contains additional meta-information about the data record (the contact) to be added to the contact database in the server.
• the subsection extending form line 37 to line 51 contains the adding instruction and the corresponding contact data content.
• the data format of the content data in line 46 to line 48 is defined as x-vcard meta-type, whereas the corresponding data contents is contented in line 46 to line 48.
• a local unique identifier (LUID) used for uniquely referencing this contact in the client is comprised in line 44.
• An arbitrary number of further synchronization information subsection can further be comprised which is indicated by an further synchronization information subsection extending from line 52 to line 54.
• the comprised Final instruction in line 56 indicates to the server that this example client synchronization message is the last message containing client modifications to be reported to the server for synchronizing.
• the aforementioned method for resuming an preceding incomplete synchronization session can be implemented in a client device and a server device in various ways.
• the following implementation is an example implementation being based on a SyncML standard implementation in which components have an enhanced functionality and capability in order to be additionally adapted to operate in accordance with an embodiment of the invention.
• Fig. 5 shows a schematic block diagram illustrating components comprised by a synchronizing client device and a synchronizing server device according to an embodiment of the invention.
• Fig. 5 depicts a server 110 representing a network device offering a networked synchronization service.
• the networked synchronization service is represented by one or more server applications 112 and corresponding associated one or more data storage components 111.
• One or more server applications 112 provide the data synchronization with other applications being represented by one or more client applications 102 of the client 100 being a networked device.
• the one or more data storage components 111 host data records for handling by the one or more server applications 112 and hence for synchronization with the client, wherein the one or more data storage components 111 are for example one or several databases.
• the server 110 and the client 100 are connected over a communication network transport. A selection of suitable communication networks for connecting client 100 and server 110 has been presented and discussed with reference to Fig. 1.
• the one or more server applications 112 uses a data synchronization protocol implemented as a synchronization server engine 113 being a component of or a process on the server 110.
• the data synchronization protocol is manifested on the communication network by client applications accessing the provided synchronization server network service and resources, respectively.
• a synchromzation server agent 115 interfaces and manages the access and the communication of the synchronization server engine 113 to the network and enables communication of data synchronization operations with the client 100 and the one or more client applications 102, respectively.
• the synchronization agent 115 performs the interfacing and communicating by involving a synchronization interface 116 and a synchronization adapter 117, wherein the synchronization interface 116 is for example an application program interface (API) to the synchronization adapter 117.
• the synchronization adapter 117 is a component of or a process on the server 110, respectively, which communicates conceptually with a counterpart synchronization adapter 107 on the client side.
• the synchronization adapter 117 is above all responsible for establishing and maintaining network communication connections between server 110 and client 100, i.e. between the one or more server applications 112 providing data synchronization service and the one or more client applications 102 accessing and employing this data synchronization service.
• the one or more client applications 102 with one or more associated data storage components 101 storing data records to be accessible by the one or more client applications 102 use a synchronization client agent 105, the synchronization interface 106 and the synchronization adapter 107 to access the provided server synchronization service.
• the synchronization client agent 105 enables communication of data synchronization operations with the server 110 and the one or more server applications 112, respectively.
• the synchronization interface 106 represents for example analogously an application program interface (API) to the synchronization adapter 107.
• API application program interface
• the aforementioned method according to an embodiment of the invention is included in the above presented conceptual component framework of the server 110 and the client 100 for example by implementing one or several code sections in the synchromzation client agent 115 and the synchronization server agent 105, wherem the one or several code sections comprise instructions which at execution of them perform an embodiment of the method for resuming an incomplete synchronization session.
• This way of implementation ensures that in case of an interruption of a synchronization session required information for resuming this interrupted synchronization session are logged or stored in the client 100 and the server 110.
• Figs. 6-8 show an alternative embodiment of a method for resuming an interruption of a previous incomplete synchronization session related to an exchange of data between two devices according to the present invention.
• the method features the step of sending from the first device to the second device an alert for resuming signal containing information related to a request for the resumption of the previous incomplete synchronization session.
• the first device is the client
• the second device is the server.
• the method also features the step of sending from the second device to the first device a status for the alert signal indicative of information related to a sync type to be carried out.
• the information related to the status of the alert for resume signal may include information for accepting a resume session or overriding an earlier sync type of the previous incomplete synchronization session.
• the server commands the client to use a different sync type.
• 'Next' Anchor or Second update identifier may or may not be updated if the sync is interrupted. If the 'Next' anchor is updated after the interruption or, during the pause, this allows synchronizing the probably modified data items during the interruption thus allowing a better user-experience.
• Fig. 6 in step 302 the client sends the alert for resuming signal to the server.
• the server replies with the status for alert signal back to the client containing an indication that the resumption of the session is O.K. hi step 306, the client uses the previous interrupted sync session's sync type (e.g.
• the synchronization session is complete with steps 308, 310, which are similar to steps 253, 254 discussed above in relation to Fig. 3b. In the aforementioned steps, both the resuming of the sync session and determining the sync type of previous interrupted sync session are included.
• the server agrees to resume the session and sends the appropriate alert code in the Alert element for the corresponding server-side datastore. The client must utilize this alert code to resume the sync session. This avoids storage of the sync type on client-side when the session gets interrupted.
• the scope of the invention is intended to include embodiments such that whenever an interruption occurs the client should send an alert for resume. This is applicable even if the client had received statuses for all items and has no more new or modified items to send in the resume session. In other words, if the transport was not disconnected elegantly or properly, then the client must request for resume instead of starting a new sync session. By doing so, this allows the server to send only the items that didn't get statuses. Fig.
• step 7 shows an overriding of the resume session by the server:
• the client's request for resume in step 302 is not acceptable by the server so the server can override the earlier sync type by sending, for example, a Status 508 (Refresh Sync) in step 320 or Status 509 (Another Sync type) , or any other appropriate code for the same purpose, followed by the appropriate Sync type in Alert code 201 (slow-sync) or 2XX (for another sync-type), respectively.
• the client uses the sync type specified by the server and sends all items, not only the remaining 5 data items.
• the scope of the invention is not intended to be limited to any specific status code numbers. Embodiments are envisioned using other status code numbers.
• Fig. 8 shows a resuming of a slow-sync session.
• the client's request for resume by alerting the server and if the resume is acceptable by the server, a 200 Status (OK) is sent on the 'Alert for Resume' in step 330.
• the server additionally, sends an alert 201 in the Alert element for the corresponding server-side datastores. This is similar to that discussed above in relation to Fig. 6, in relation to the determining of the sync type; however, it is important to note how to differentiate between the resuming of a slow-sync vs a forceful full slow-sync as an Alert 201 currently means a slow-sync and the client would start a full slow-sync.
• the client can decide by looking at the status code send to 'Alert for Resume' in step 330.
• a 200 code would mean a resume slow-sync (the alternative is to have status codes for all different sync types, e.g., sending 220 instead of 200 to acknowledge that starting a resume session is OK), and a 508 code would mean full slow-sync.
• a full slow-sync can be achieved by sending 508 Status (refresh required) on the Alert for Resume followed by the Alert 201 - refer to above.
• the 'LAST' update identifier is not updated.
• the first or the second device can later send an indication to the other device to resume the paused synchronization session.
• the first device may send a message containing an alert for resume signal to the second device, whereby the devices may continue the synchronization that was paused.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Hardware Design (AREA)
• Databases & Information Systems (AREA)
• Software Systems (AREA)
• Mathematical Physics (AREA)
• Computing Systems (AREA)
• Data Mining & Analysis (AREA)
• Telephonic Communication Services (AREA)
• Computer And Data Communications (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (2)

Applications Claiming Priority (5)

Related Child Applications (2)

Publications (2)

Family

ID=31980974

Family Applications (1)

Country Status (9)

Families Citing this family (18)

Citations (1)

Family Cites Families (3)

• 2003
  • 2003-09-03 KR KR1020057003718A patent/KR100728076B1/ko active IP Right Grant
  • 2003-09-03 AU AU2003255972A patent/AU2003255972A1/en not_active Abandoned
  • 2003-09-03 EP EP03793961A patent/EP1540503A4/de not_active Ceased
  • 2003-09-03 WO PCT/IB2003/003737 patent/WO2004023233A2/en active Application Filing
  • 2003-09-03 MX MXPA05002408A patent/MXPA05002408A/es active IP Right Grant
  • 2003-09-03 CA CA002497525A patent/CA2497525A1/en not_active Abandoned
  • 2003-09-03 JP JP2004533728A patent/JP4494970B2/ja not_active Expired - Lifetime
  • 2003-09-03 TW TW092124270A patent/TWI231426B/zh not_active IP Right Cessation
• 2005
  • 2005-03-02 EG EGNA2005000037 patent/EG23768A/xx active

Patent Citations (1)

Non-Patent Citations (4)

Also Published As

Similar Documents

Legal Events