KR100728076B1 - Method, apparatus, and system for synchronizing data providing for processing of an interrupted synchronization process - Google Patents

Abstract

 The present invention provides a method, a network device and a system to allow resumption of a previous incomplete synchronization session, in which case the previous incomplete synchronization session was suspended during its execution. In general, the resumption of the previous incomplete synchronization session is based on the following operations in accordance with an advanced concept. A communication connection for data synchronization between the first and second devices is established. The first and second devices each comprise a predefined set of data records to be synchronized. The first and second update identifiers are communicated between the first and second devices. The first update identifier defines a previous full synchronization session performed between the first and second devices and the second update identifier specifies a previous incomplete synchronization session performed between the first and second devices. Regulate. Synchronization related information is exchanged between the first and second devices.

Description

 Method, device and system for synchronizing of data providing for the handling of an interrupted synchronization process

1. Technical Field of the Invention

 The present invention relates to a method and apparatus for synchronizing data between a synchronization client device and a synchronization server device, and also synchronizing data to each synchronization device. More specifically, the present invention relates to a method and apparatus for synchronizing data, each of which enables improved handling of interrupts in an active synchronization process.

2. Description of related technical fields

 Synchronization of data is a known concept or technique for users, each having at least two different electronic devices in use and processing the same kind of data as such electronic devices. In general, synchronization occurs between a terminal device (eg, a mobile phone) and a server device (eg, an application in a local PC or a dedicated synchronization server). Data from terminals, such as portable computers, personal digital assistants, mobile phones, mobile stations, or pagers may be networked applications, applications on desktop computers, or applications that manage data storage in other wireless communication systems. It may be synchronized to a networked device operating as the synchronization servers represented, where the term “data storage” should be understood as broadly as possible, ie it will include any set of data. In particular, email application data and configurations as well as calendar data, contact data, data regarding device / application settings, are typically synchronized.

Synchronization has been based on the use of different manufacturer-specified protocols that are incompatible. This limits the use of the terminal or data type and often causes problems for the user. In mobile communications, it is particularly important to be able to retrieve and update data regardless of the application and the terminal used.

In order to improve the synchronization of application data, a language called the known synchronization generation language SyncML based on extensible markup language (XML) has been developed. By using a SyncML synchronization protocol that employs messages in SyncML format, data of an application can be synchronized between networked terminals and some kind of network server. The SyncML synchronization protocol works in both wireless and fixed networks and supports several transport protocols. The SyncML synchronization techniques presented above deal with the synchronization of data storage or databases, in particular.

Conventionally, by synchronizing data records at separate points in time to match, i.e., match, a set of two separate predetermined data records stored in different synchronization devices that manage and adopt different storage locations, i. The result is two sets of equivalent data records in both storage spaces at these separate points in time. In addition, the synchronization of data records performed at separate points in time is designated as a synchronization session. Synchronizing sets of data records may be obtained during this synchronization session by exchanging information, instructions and commands, causing the participating synchronization device to modify the stored sets of data records to match the data records set. Such modifications include adding data, removing data, appending data to current data, updating data, and the like. The exchange of required information and commands is performed by communicating between the synchronization devices one or more messages, each comprising a separate subset of the required information, the commands and commands necessary to perform the synchronization at the respective synchronization devices. For practical purposes. In addition, each of the one or more messages is acknowledged to indicate successful operation according to the message information contained therein.

Basically, the synchronization processes as described above may be performed by being processed in an overall synchronization process, which is also designated as slow synchronization, or an incremental synchronization process, which is also designated as normal or fast synchronization. During a synchronization session that performs a full or slow synchronization process, all of the predetermined sets of data records in both participating synchronization devices are matched. During a synchronization session that performs an incremental or fast synchronization process, each time point of the last completed synchronization session is logged to both participating synchronization devices, and the logged time points stored in both synchronization devices are modified only with modified data records. In case of a match, this logged time point is excluded from the synchronization process since it is selected for all other synchronizations. Thus, the change log can be maintained while adding or deleting the time points of the data records by the synchronization device logging the modifications. Alternatively, if so, the modification may be determined in other ways, such as by examining the modification of the time stamp of the records. The synchronization process, both so-called slow synchronization and so-called fast (normal) synchronization, are defined and used in the SyncML standard. Other types of synchronization processes are valid and used but their other synchronization processes can be reduced to the basic synchronization process described above.

When a record and / or group of records have been synchronized with another database, an acknowledgment is sent back to the sender of the record. Two basic ways of handling authorization may be implemented in a synchronization application. In the first embodiment, each successful synchronization of a data record or a batch of data records is preferably approved and logged by the synchronization devices with one or more such change logs. In the second embodiment, the authorization is processed at the end of the synchronization session, i.e. as soon as both synchronization devices indicate the appropriate closure and connected correspondingly adopted communication of the synchronization session. In addition, the update processing at the end of the synchronization session and the point in time of specifying the finally completed synchronization session are operated substantially simultaneously. If the synchronization session is performed with a slow synchronization process that takes into account the point in time of designating the last completed synchronization session, it is not explicitly required.

The first embodiment mainly deals with synchronization applications used to synchronize distributed databases with high speed connections with one another, for example, to maintain and ensure data purity. In this embodiment, the capacity requirements for processing change logs as well as the capacity requirements for storing and maintaining change logs for each data record, network bandwidth for exchanging the necessary grants are of less importance. In terms of synchronizing data stored in small electronic devices such as mobile phones, handhelds, personal digital assistants, communicators, and the like, storage capacity and processing power are used to store, maintain and process change logs for each data record. This is a hindrance and is limited to being inefficient and sometimes not possible. In addition, network traffic resulting from the necessary authorization is also unacceptable because it is expensive and time intensive in a mobile communication environment.

The second embodiment, wherein updating the time stamps and processing the approvals for those items is performed at the end of the session, is suitable for use in small electronic devices and is supported by the SyncML standard. Nevertheless, this embodiment raises the problem that no interruption of the currently performed synchronization session is provided. It is not possible to maintain synchronization information exchanged during a partially operated synchronization session, because the processing of updating and acknowledgment of time stamps (synchronization anchors) at the end of the synchronization session cannot be achieved due to interrupts. Because. Even if the approval of the data item is handled during the session, since the time stamps are updated only at the end of the session, the interrupt of slow synchronization results in the loss of preprocessed synchronization information. In both cases, the synchronization session must be completely repeated to ensure data purity. Depending on the amount of synchronization related information, that is, the number of data records to be synchronized, a very large number of messages are normally exchanged during a single synchronization session that includes several synchronization messages. For example, 400 of the 500 data records could be synchronized during the synchronization session and an interrupt occurs. All subsequent synchronization sessions of the 500 data records must be resynchronized independently of whether synchronization is operated as a fast or slow synchronization process.

 It is an object of the present invention to provide a method that allows resuming an interrupted synchronization session to avoid complete repetition of the interrupted synchronization session. The provision for resuming an interrupted synchronization session is configured such that high storage capacity, high processing power, high number of exchanged acknowledgments and high communication bandwidth are not all required. This method is suitable to be economically implemented in small electronic devices.

According to one embodiment of the present invention, a method is provided that allows resuming a previous incomplete synchronization session, wherein the previous incomplete synchronization session was interrupted during its operation. Resumption of a previous incomplete synchronization session is accomplished by the following operation.

A communication connection for the synchronization of data between the first device and the second device is established. The first device and the second device each comprise a set of data records to be synchronized. Traditionally, data records consist of a data store or database maintained by a corresponding application.

In one embodiment, the present invention provides a method for resuming interruption of a previous incomplete synchronization session related to the exchange of data between two devices. The method is characterized by sending an alert from the first device to the second device to resume a signal comprising information relating to a request to resume a previous incomplete synchronization session. An alert for resuming a signal may be a resumption session that can be inferred by the server, or at least a direct alert code directly indicating the signal, for example, an indication of a time stamp to be used for the session or It can be any other identification. The method is also characterized by the step of transmitting from the second device to the first device a status for an alarm signal indicating information relating to the type of sync to be executed. The information related to the state of the alert for the resume signal may include information that overrides the previous sync type of the previous incomplete synchronization session.

In an alternative embodiment of the invention, the first update identifier and the second identifier are communicated from the first device to the second device or from the second device to the first device. The direction of transmission depends on which device indicates the direction of resumption and synchronization of the previous incomplete synchronization session. The indicating device transmits both identifiers to the other. The first update identifier specifies that a previous complete synchronization session has been performed between the first device and the second device. The first update identifier was stored in the first device and the second device during the initialization of the previous complete synchronization session. In more detail, the value of the identifier is stored, but the name or storage location of the value may vary depending on the embodiment. In general, the first update identifier is the time stamp used to log the initialization time of the previous complete synchronization session. Alternatively, the identifier may be a monotonically increasing integer string, a document string, or a mixture thereof, which is generated at any numerical value, for example, regularly or at least to some extent or partially irregularly. According to the present invention, the second update identifier specifies a previous incomplete synchronization session that was performed between the first device and the second device. The second update identifier was stored in the first device and the second device during the initialization of the previous incomplete synchronization session. In general, the second update identifiers are similarly those used to indicate the initialization time of the previous synchronization session that was similarly time stamped or interrupted. However, in the prior art, the operation and use of the second update identifier are defined only during the synchronization session, not after the interruption or after the session is completed.

The method according to the invention has four steps for synchronization. The first step includes establishing a communication connection for synchronization of data between the first device and the second device, each of which includes a set of data to be synchronized. The second step includes transmitting the first update identifier and the second update identifier, wherein the first update identifier indicates that a previous complete synchronization event has been performed between the first device and the second device, The value was stored at least on the first device, the second update identifier indicates that a previous incomplete synchronization event was initiated between the first device and the second device, and the value of the second update identifier was stored on at least the first device. The third step includes retrieving or forming an indication of the data that was successfully synchronized during the previous incomplete synchronization event. The first step includes synchronizing data that was not successfully synchronized during a previous incomplete synchronization event using an indication, wherein (4) at least the first device, with the value of the second update identifier, Updating the value.

In addition, the method further comprises at least one of a group of information related to a previous incomplete synchronization event and comprising information about data previously successfully synchronized according to received synchronization related information. Transmitting information.

 The method may also include a comparison step performed on at least one of the first device and the second device, wherein the first comparison job is stored in the second device and the value of the first update identifier sent from the first device. Compares the values of the second update identifier of the first device and executes at least one of the following options:

1) if true in the second comparison, a synchronization step for the data including data between the first device and the second device and data not exchanged during the previously incomplete synchronization event.

2) if false in the second comparison, a synchronization step for the data including data between the first device and the second device and at least data synchronized during the previously incomplete synchronization event.

3) if false in the first comparison, a synchronization step for the data including data between the first device and the second device and data synchronized during the preceding full synchronization event.

4) If true in the first comparison, a synchronization step for the data including data between the first device and the second device and data not synchronized during the previous full synchronization event.

Performing the communication connection for synchronization may include transmitting an initial message to at least one of the first device and the second device instructing it to prepare to resume the incomplete synchronization that occurred earlier.

The synchronization may be based on a synchronization protocol conforming to the SyncML standard, and the first update identifier may be a LAST synchronization anchor. The second update identifier will be at least one of a NEXT synchronization anchor or a PAUSE synchronization anchor. In addition, the additional information related to the previously incomplete synchronization event may include a synchronization event session identifier (session ID), a synchronization message identifier (message ID), one or more identifiers of recognized data, and a data store for each of them. Will include at least one. Further, the additional information is stored in at least the first device before the transmission of the first update identifier and the second update identifier.

In this method, if an acknowledgment for the data or the message containing the data has been successfully received, the data is successfully synchronized and the acknowledgment indicates a positive or negative condition for the synchronization of the data or message.

The present invention also provides a software tool for synchronization, comprising a program portion for executing the steps of the method described above, which software tool is a computer program for execution on a processing device, a terminal device, a communication terminal device or a network device or the like. It is built in a computer program or a computer program product for synchronization between them.

The present invention also provides an apparatus for use in a network and capable of synchronizing data and having a storage medium, a communication interface, a means for restoring or creating and updating. The storage device predefines a set of data to be synchronized. The communication interface performs a communication connection for data synchronization with another terminal used in a network, communication with another network device for a first update identifier and a second update identifier, and data exchange with another network device. The first update identifier indicates a complete synchronization event with the other network device that occurred earlier, and the first update identifier is stored at least in the network device. The second update identifier indicates an incomplete synchronization event that occurred earlier, the second update identifier is stored at least on the network device, and the data includes data that was not synchronized during at least the earlier incomplete synchronization event. The restoring or generating means restores or generates an indication of the synchronized data during the previously incomplete synchronization event, the indication being stored in the network device. The synchronization means synchronizes the data according to the indication. The updating means updates the contents of the stored first update identifier and the contents of the stored second update identifier.

The communication interface may send supplementary additional information about the previously incomplete synchronization event. The additional information may include at least one of information on incomplete synchronization, information on recent successful exchange of synchronization related information, and information on data successfully synchronized according to received synchronization related information.

The apparatus may also comprise means for a comparison operation, in which the first operation compares the value of the first update identifier sent from the device with the value of the second update identifier stored in another device, and in the second comparison The value of the second update identifier transmitted from the one device is compared with the value of the second update identifier stored in the other device. Means for performing at least one of the foregoing options have been discussed above in connection with the present method.

The invention also provides a system for synchronization comprising a first network device and a second network device, wherein each device comprises components for performing the steps as discussed above in connection with the overall method and apparatus of the invention. Include.

The present invention will be described in more detail with reference to the accompanying drawings.

1 is a schematic diagram illustrating an example of electronic devices in which information synchronization may be performed;

2 is a flow chart showing a synchronization process sequentially including several messages exchanged between a synchronization client device and a synchronization server device according to an embodiment of the present invention;

FIG. 3A is similar to FIG. 2, and sequentially shows a synchronization process that is interrupted or stopped according to an embodiment of the present invention.

FIG. 3B is a flowchart sequentially showing a synchronization process of restarting the interrupted or stopped synchronization process of FIG. 3A according to an embodiment of the present invention; FIG.

4 is a view showing an extract of an XML-coded synchronization message corresponding to an embodiment of the present invention and a synchronization process according to FIG. 3B;

5 is a simplified block diagram illustrating components including a synchronization client device and a synchronization server device according to an embodiment of the present invention;

FIG. 6 is a flowchart sequentially illustrating a synchronization process for restarting the synchronization process of FIG. 3A that is interrupted or stopped according to an embodiment of the present invention; FIG.

7 is a flowchart sequentially illustrating a synchronization process of restarting the synchronization process of FIG. 3A that is interrupted or stopped according to an embodiment of the present invention;

8 is a flowchart sequentially illustrating a synchronization process of restarting the synchronization process of FIG. 3A which is interrupted or stopped according to an embodiment of the present invention;

In the following, embodiments of the present invention are described without restricting the present invention to the point of view of a system supporting the SyncML synchronization standard. Information related to the SyncML standard can be obtained from the SyncML Initiative, which provides all the standard materials publicly. The same or similar parts, elements and / or operations in the drawings will use the same reference numerals.

1 is a schematic diagram illustrating an example of electronic devices in which information synchronization may be performed. For example, the specific datastore contents of a mobile terminal may differ from the datastore contents by a device providing a central repository of datastore contents that can be accessed by a designated device, such as several different mobile or fixed terminal devices. It must be harmonized. Typically, mobile terminals act as synchronization clients to synchronize or synchronize data associated with any given application with one or several datastores of dedicated server devices that centrally store data associated with that application. Perform. 1 illustrates a plurality of possible client devices and server devices capable of performing synchronization. Typically, the client devices are not only desktop computers (PCs) but also mobile phones 17 or PDAs (Personal Digital Assistants), mobile computers such as notebooks 15, electronic devices for storing digital data such as digital cameras, and the like. Further, the dedicated synchronization server apparatus may include a desktop computer 10, a dedicated network server 11 having a synchronization function and using it as a network synchronization application, and even a mobile computer such as a laptop running the synchronization server application. Although the concept of synchronization provided herein has been described in terms of a mobile terminal connected to a dedicated server device, the functionality of the client device is not limited to the mobile terminal as described above.

The synchronization process conforming to the SyncML protocol standard is performed over the appropriate logical communication connection. The logical communication connection may be provided by any communication network in which a transmission protocol employing a synchronization protocol is accepted. Suitable communication networks include wired-based serial networks such as Universal Serial Bus (USB) as well as local area networks (WLANs) or wide area networks (WANs) that can form the Internet and the company's intranet, or standardized serial communications (e.g., RS-232). Participating synchronization devices are also mobile networks that support Global System for Mobile communication (GSM) services and / or General Packet Radio Services (GPRS), third generation mobile communication networks such as Universal Mobile Telecommunication Systems (UMTS), and WLANs. ), A Bluetooth network, a wireless local loop (WLL), an infrared network (IrDA), and the like. Logical communication connection between participating synchronization devices may be provided through one of the above-described types, but also a dedicated network routing device that not only connects communication networks but also performs translation between data protocols of each communication network, if necessary. It can also be provided through a number of networks of the kind described above.

With regard to the SyncML Protocol Standard, SyncML Synchronization Protocol, and SyncML Device Management Protocol Standard, the SyncML Device Management Protocol is built on the appropriate protocol according to the type of communication network adopted. Appropriate protocols on which the SyncML synchronization protocol can be constructed include HTTP (Hyper Text Transfer Protocol), WSP (Wireless Session Protocol) standard, cable connections such as USB or RS-232, near radio frequency (Bluetooth) or infrared ( OBEX (OBject EXchange protocol), TCP / IP (Transport Control Protocol / Internet Protocol) stack, and transport layer provided by an email protocol (for example, SMTP: Simple Mail Transfer Protocol) used for IrDA.

The transport at the lower layer is via an underlying network, for example SMS or other signaling type of transport (e.g., USSD: unstructed supplementary service data), circuit switched data transmission, packet switched data transmission service. And a paging message service, a message transmitted through cell broadcasting, and the like.

 Note that the term datastore here should be interpreted as broadly as possible and encompasses any dataset of data storage to be accessed. In particular, data sets associated with a particular application, such as data such as calendar applications, directory applications, address book applications (eg vcard applications), email applications, etc., will be organized to meet the unique requirements of the application. In addition, any dataset may be organized into one or more databases containing data records providing data for access. Furthermore, the term datastore should be interpreted to encompass any dataset similar to the datastore provided by each of the network data services or networked services, for example, the network service to be accessed. In general, network services are based on datastores having content associated with a particular service.

 The following sequence diagrams illustrate operation sequences according to embodiments of the methods of the present invention. The sequences of actions depicted are merely exemplary and not limiting. Further implementations based on similar or related operating sequences are also possible.

2 illustrates a chronological sequence diagram of a synchronization process including several messages exchanged between a synchronous client device and a synchronous server device in accordance with an embodiment of the present invention.

SyncML sync sessions are conceptually limited to so-called SyncML packages. The SyncML packages are merely a conceptual framework for one or more SyncML messages that are physically exchanged between the synchronous devices and are required to convey a set of sync information and instructions. Not all SyncML packages are included in any type of synchronization provided by the SyncML standard. The exact number of SyncML messages depends on the amount of information conveyed.

A schematic overview of the SyncML packages is described in the following list. A detailed description can be obtained from the SyncML standard documents.

Package 0-start of the sync message. The client device may receive unsolicited messages, so-called “notifications” or “warnings,” instructing the receiving device to establish a back connection to initiate a synchronous session. Note that the same effect on receiving the notification can be caused in different ways.

Package 1-Initialization from client device to server device. For example, client device information (device identifiers, etc.), client device characteristics, client authentication, sync type, identification information of databases to which data records are synchronized, last stored anchor, new next anchor, etc. One or more initialization messages are sent.

Package 2-Initialization from server device to client device. For example, one or more initialization messages are sent that include server device information (such as device identifiers), server device characteristics, server authentication, response to information contained in one or more client initialization messages, and status information.

Package 1 (Pkg # 1) and Package 2 (Pkg # 2) are part of the initialization step. The next package 3 (Pkg # 3) to package 6 (Pkg # 6) is part of the synchronization phase of the synchronization message.

Package 3-Synchronization from client to server. For example, one or more client sync messages are sent that include client data changes, i.e. any changes to the data of the client databases identified in the sync initialization. In the case of a fast sync process, only data records that have changed since the previous sync session (last anchor) are reported, while in the slow sync process all data records are reported.

Package 4-Synchronization from Server to Client. One or more server sync messages are sent that contain information on the client's analysis of, for example, transmitted client data changes and also server data changes, ie any changes to the data of the server databases identified in the synchronous initialization. do. In the case of a fast sync process, only data records that have changed since the previous sync session (last anchor) are reported, and in the slow sync process all data records are reported.

Package 5-Data Update Status, Map Behavior. For example, map operations (tables for mapping information about the results of data updates (synchronization due to server changes), a local unique identifier (LUID) and a global unique identifier (GUID)) One or more data update status messages are sent. The local unique identifier is the identifier assigned to the data record and is locally unique on the client side, ie per device and application. The local unique identifier allows identifying a data record. The global unique identifier is the identifier assigned to the data record and is locally unique on the server side.

Package 6-Map Positive Response. One or more map acknowledgment messages are sent, for example, including acknowledgments informing the client device of receipt of one or more data update status messages by the server.

Depending on the client message or the instructions and synchronization information contained in the server message, respectively, the client message by package 3 may cause a server response message by package 4 and vice versa.

Each message in the sync message includes a session identifier (session ID) so that the messages can be assigned to a separate sync session. Each message includes a message identifier (message ID) such that mismatches of messages exchanged at the client device and the server device are respectively prevented. Moreover, each last message of each package type includes a final indicator to indicate that this is the last.

The synchronization process involves what type of information (which data records) are synchronized (slow or fast synchronization, i.e. the total number of data records or only changes since a certain point in time), at which device (s) (the client device or The synchronization is further distinguished by whether synchronization is performed at the server device or both devices and from which device synchronization is initiated. The type of synchronization may be, for example, bidirectional synchronization, low speed synchronization, unidirectional synchronization from a client only, refresh synchronization from a client only, unidirectional synchronization from a server only, refresh synchronization from a server only and server alert synchronization.

The designations of the listed types of syncs themselves describe the sync process and are easily understandable. See the SyncML standard document for more details.

By way of example, the chronological sequence diagram and the synchronization process shown in FIG. 2 are each based on a fast bidirectional synchronization type, although the scope of the present invention includes other synchronization types. The client 100 is synchronized with the server 110. According to the above description of the package sequence, the described synchronous session consists of an initialization phase 210 followed by a synchronization phase, each including several synchronization messages. All sync messages contain the same session ID (not shown).

During the initialization step 210 of the client 100 and the server 110, both devices exchange device information (device identifiers, etc.), device characteristics, and device authentication information. The client 100 further defines the type of synchronization (here fast bidirectional synchronization type) and reports to the server 110 the last anchor stored and the newly defined next anchor. The server 110 compares the last anchor sent by the client 100 with a corresponding value stored in the server 110 and the last when the stored and received last anchors match to allow fast synchronization. Observe the anchor and the next anchor above. The state (content) of the next anchor is not defined at the server 110 (indicated by a "?" Sign) until the moment the client 100 sends the newly defined anchor (by conventional technology, I.e. the bidirectional synchronous process of the prior art does not provide any particular value for it). If the anchors do not match, a slow sync is alerted to the client 100. The exchange of information during the initialization step 210 is illustrated by a first operation 200 referencing a client initialization message corresponding to package 1 and a second operation 201 referring to a server initialization message corresponding to package 2 message. . Both messages referenced by operations 200 and 201, respectively, contain the same message ID 1 (Msg # 1).

After completion of the initialization step 210, the client 100 prepares for the synchronization 210, i.e., identifies the changed data records according to the last anchor received. The client sync message (package 3 message type) referenced by operation 203 includes client changes in the first batch, here 5 of the 10 identified changes in total. It may be noted that client changes include instructions and / or data content. The instructions, complete with data content for synchronizing each data record, include all of the above additions, updates, deletions, and the like. In addition, the message further includes status information according to a previous server initialization message. The server 110 receives the first client sync message, analyzes the received client changes, resolves possible conflicts arising from the client changes and processes the client changes (operation 212). A corresponding server synchronization message (package 4 message type) referenced by operation 204 is sent to the client, including the status information of the analysis and synchronization process and client change acknowledgments. Both the client sync message referenced by operation 203 and the server sync message referenced by operation 204 are identifiable by a common message ID, where message ID 2 (Msg # 2). However, it should be noted that the message numbering may deviate from that provided above. Indeed, the only purpose to be exploited by the message numbering is that each device has a consistent view of the message numbers, ie the numbering towards the client and the server need not even match.

The next client sync message (package 3 message type) referenced by operation 206 includes client changes in the second batch, the remaining 5 of the total 10 identified changes here. The client sync message additionally includes a final indicator indicating that this is the last client sync message containing client changes. The server 110 receives the last client sync message, analyzes the received client changes, resolves possible conflicts arising from the client changes, processes the client changes and causes the client (because of the final identifier) Prepare server changes to be sent to 100 (identified in consideration of the last anchor of the server) (operation 212). A corresponding server sync message (package 4 message type) referenced by operation 207 that includes server changes, client change acknowledgments, and status information of the analysis and sync process is sent to the client. According to the sync session shown in FIG. 2, a single server sync message is sufficient to send all identified server changes to the client such that the message additionally contains a final indicator. In operation 214 the client 100 processes the received server changes. Both messages referenced by operations 206 and 207, respectively, contain the same message ID 3 (Msg # 3).

The client update status message (package 5 message type) referenced by operation 208 that includes synchronization status information and acknowledgment response information due to the server changes is subsequently forwarded to the server 110 and, if necessary, the server 110. Map operations to the data record map table that assigns local unique identifiers and global unique identifiers. Finally and not shown, the client update status message may be responded by the server 110 with one or more map acknowledgment messages (package 6 message type).

In conclusion, the synchronous session and the communication connection through which the synchronous messages of the session are delivered are closed. If no error is detected regarding the completion of the synchronization session and the communication connection, the content of the next anchor defined at the start of the synchronization session is stored. The assignment is performed at the client 100 in operation 215 and performed at the server in operation 216 (in fact, the server may not call the anchor last, but nevertheless the value stored in the anchor is stored by the client. Value of the next anchor sent). Thus, the next high speed synchronous process is possible.

Defining the next anchor at the start of a synchronous session and assigning the next anchor content to the last anchor after proper completion of the synchronous session avoid collisions due to changes in data records on the client side or server side during the synchronous process. It is noted that. It can additionally be noted that the contents of the last anchors and the next anchors shown are merely for teaching their use. For practical purposes the last anchors and the next anchors usually contain or are obtained with date values and time values, or they are other types of numerical values. This type of configuration can ensure to create each of the ambiguous last and next anchors.

FIG. 3A illustrates an chronological sequence diagram of a synchronous process similar to FIG. 2 and is suspended or stopped in accordance with an embodiment of the present invention. The sync session shown in FIG. 3A will be the same as that presented with reference to FIG. 2, ie the initial states, operations 200-204 and operations 210-212, are performed in the same manner. Similarly, the operations shown in FIG. 3A and each of the operations shown in FIG. 2 and common to FIG. 3A are referred to by the same reference numerals.

In FIG. 3A, the initialization step and corresponding initialization messages of the client 100 and the server 110 are omitted. The operation 203 of referring to a first client synchronization message (package 3 type) that includes the first 5 of 10 client changes and the operation 204 of referencing the first server synchronization message (package 4 message type) of the It is shown to contain state information corresponding to client changes.

In operation 205 the synchronization is stopped or stopped. Interruption or interruption can be caused for several reasons, for example the synchronous session may result in user interaction, user origination, for example, the power of client 100 or server 110 due to lack of battery or battery capacity. Loss, for example, loss of communication connection due to loss of coverage in a wireless communication network, interrupted due to interference in the communication interface to provide only a choice of possible reasons.

In order to allow for resumption of a synchronous session according to an embodiment of the inventive method, the client 100 and the server 110 record information about an incomplete synchronous session. The information for allowing resumption of the incomplete sync session includes at least the next anchor and at least the last anchor at the client 100, recorded at both the client 100 and the server 110.

 This information may also be the session ID of the incomplete synchronous session, the message ID of the last message suitably sent and the client 100 received the acknowledgment, and one or more unique data record identifiers, i.e., local unique identifiers or sent. The transmission may include globally unique identifiers of data records according to modifications identified during an incomplete synchronization session.

Alternatively, instead of employing the next anchor to log when the incomplete sync session started, a new anchor, for example a PAUSE anchor, is defined and specifically used to resume an incomplete sync session. Are employed. Hereinafter, the present invention is described with reference to the following anchors, but the concept of the present invention is not limited thereto. In order to adapt the following description to the new PAUSE anchor, the term following anchor is simply replaced by the term PAUSE anchor.

FIG. 3B illustrates a sequence diagram over time of a sync session performed in an incomplete sync session where FIG. 3A is interrupted or interrupted in accordance with an embodiment of the present invention.

Referencing a new initialization message (package 1 type) containing an alert command indicating to the server 110 the intention of the client 100 to resume the previous incomplete sync session described above with reference to FIG. 3A. Resume synchronization session is initiated by 250. This new initialization message includes at least the next anchor and the last anchor logged according to the interruption of the previous incomplete synchronization session (step 205 of FIG. 3A). The server receives the last anchor and the next anchor from the client and compares them with the last and next anchors logged by them. Note that, compared to the synchronous session shown in FIG. 2 and the similar synchronous session shown 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 server 110 may command, initiate or perform any of the following four different options depending on whether the last anchor matches and / or the next anchor matches. .

1) if the last anchor received and logged and the next anchor received and logged match, include at least the last anchor and the next anchor for a response and refer to step 251 to send a server initialization message (package 2 type) Confirm resumption of incomplete synchronization sessions (resuming fast synchronization). Resumption grant confirmation may be further based on additional information regarding the incomplete sync session being resumed (see step 205 of FIG. 3A). For example, the logged session ID of the incomplete synchronous session described above and / or the logged message ID of the last message sent suitably are taken into account during the checking phase of the logged anchors.

2) If the last anchor received and logged matches but the next anchor received and logged does not match, a (general) fast sync session of the kind indicated with reference to FIG. 2 is commanded by the server. The next anchor that does not match indicates the resumption of the incomplete sync session described with reference to FIG. 3A.

3) If the last anchor received and logged does not match but the next anchor received and logged matches, a resume slow sync session is commanded by the server. This resume slow sync session is not shown in FIG. 3B. Briefly, a resume slow sync session exchanges sync related information that allows to synchronize all predefined data records to be synchronized. However, this sync related information is excluded from the resume slow sync session successfully exchanged and synchronized during the incomplete sync session shown in FIG. 3A.

4) If neither the last anchor received and logged and the next anchor received and logged do not match, neither a resume fast sync session nor a resume slow sync session can be initiated. In addition, high speed synchronization is not possible. In order to be synchronized, a full slow synchronization session (as described above; not shown in FIG. 3B), including the exchange of all predefined data records, must be performed to establish a suitable synchronization state between the participating devices.

The following description is based on the assumption that the first case (when the last anchor received and logged and the next anchor received and logged match) is correct. This case is also shown in FIG. 3B, which shows the status (value) of the last and next logged anchors of both client 100 and server 110. The server 110 sends a server initialization message (package 2 type) that includes at least the last anchor and the next anchor for the response and refers to step 251.

As described in connection with step 205 shown in FIG. 3A, additional log information regarding incomplete sync sessions is logged at the time of interruption. As described above, this information may include the session ID of an incomplete synchronous session, the message ID of the last message suitably transmitted and the client 100 has received an acknowledgment, and one or more unique data record identifiers, ie local unique identifiers or transmitted. The transmission may include at least one of the globally unique identifiers of the data records according to the change identified during the incomplete synchronization session. Note that the information provided by the local unique identifiers may not be sufficient and the database identifiers may be logged in addition to the local unique identifiers. The combination of the local unique identifier and the associated database identifier allows (obviously) to determine the corresponding data record referenced by the local unique identifier. The database identifiers may be a uniform resource locator (URI) known in the art.

Stored information about the last stored anchor, the next stored anchor, and the incomplete sync session allows to save (reset) the state of the previous incomplete sync session upon interruption. This kind of reconfiguration is referred to by steps 206-208 shown in FIG. 2 representing a complete synchronous session, and is a synchronous message that represents the same synchronous session but is referenced by step 204 (FIGS. 2 and 3A). Allows to generate messages that are not incomplete in FIG. 3A due to an interrupt after the transmission of.

Both the new client message and the server initialization message referenced by steps 250 and 251 also include the information needed to establish a synchronous session as described with reference to steps 200 and 201 shown in FIG. do.

Here, assume that the conditions for resuming an incomplete synchronous session have been met and that the incomplete synchronous session has been reconfigured so that the client 100 can be performed in accordance with an embodiment of the method of the present invention. The client sync message (package 3 type) referenced by step 252 corresponds to the second client sync message referenced by step 206 shown in FIG. Thus, the client sync message includes the last five of the ten changes and the final instructor to indicate that this message is the last client sync message of the current sync session. In addition, message numbering, i.e., the message ID, is adapted to the current resume synchronization session, so that the client synchronization message of FIG. 3B is the previous message ID of the initialization messages (referred to by steps 250 and 251). (1) It has the following message ID (2). (It is important to note that the scope of the present invention is intended to include other types of message numbering sessions.)

The server 110 responds to the client synchronization device by sending a server synchronization message (package 3 type) referred to by step 253 corresponding to the second client synchronization message referred to by step 206 shown in FIG. do. The server synchronization message includes server change, client change response and status information of synchronization processing and analysis. In accordance with the sync session shown in FIG. 2, a single server sync message is sufficient to send all identified server changes to the client such that the message additionally contains a final indicator. All of the messages referenced by steps 252 and 253 each contain the same message ID 2.

Client referenced by step 254 including synchronization status information and response information to the server 110 processing the data record map table that assigns local unique identifiers and global unique identifiers, if necessary, due to map behavior and server changes. An update status message (package 5 message type) is communicated to the server 110. This client update status message also corresponds to the client update status message referenced by step 208 described with reference to FIG. 2. Finally, although not shown, the client update status message may be responded by the server 110 with one or more map acknowledgment messages (package 6 message type).

Finally, the synchronous session and the communication connection to which the synchronous message of this session is sent are terminated. If no error is detected regarding the end of the synchronous session and the communication connection, the anchor next to the content defined at the start of the synchronous session is assigned to the last anchor. This assignment is performed at the client 100 at step 260 and at server 110 at step 261. Thus, the next fast synchronous process is operable. Note that the definition of the next anchor at the start of a synchronous session and the assignment of the next anchor content to the last anchor after the proper end of the synchronous session prevents conflicts due to changes in data records on the client side or server side during the synchronization process. . It may further be noted that the content of the last anchor and the next anchor shown indicates its use. For practical purposes, the last anchor and the next anchor may generally be derived from or constructed from date values and time values. This kind of configuration can ensure to produce explicit last and next anchors, respectively.

It is also noted that changes to data records after an incomplete sync session and before a resume sync session are not considered during the resumption of an incomplete sync session. The resume sync session sets the state of the data store containing the data record or data record as if an incomplete sync session was successfully completed. For this reason, the next anchor that represents the time stamp of the sync session is not updated during the initialization of the resume sync session. Changes that occur after an incomplete synchronous session can be synchronized by initiating a synchronous session after a successful resume synchronous session, particularly since the last anchor stored in client 100 and server 110 is updated and valid. Can be.

Acknowledgments described in the context of embodiments of the present invention are translated into some sort of response to data received from other purposes, including the positive or negative status of the data or message's motivation. Typically, the acknowledgment confirms the update of the record, but can also carry information of unsuccessful actions due to, for example, a record not found. Nevertheless, the handling of such errors is not of interest to the present invention and it is left to the implementation to handle the errors anyway. However, the occurrence of the error should not prevent the resumption of the session. That is, the session must be resumed at the first unauthorized data item regardless of whether there was an error in the previous data item.

4 illustrates an excerpt of an XML-encoded sync message according to the synchronization process shown in FIG. 3B in accordance with an embodiment of the present invention.

In order to ensure an easy and jointly available implementation, an industry-standard extensibility generation language (XML) was chosen to specify a synchronous message that synchronizes the device and application (plain text or wireless binary XML, adopted by the wireless application protocol). Using binary technology). SyncML is designed within the memory capacity of all common mobile devices in static code and run-time execution space. In particular, binary coded extensible markup language (WBXML) is commonly used to encode data in order to reduce the memory required to store messages and the resources required to process and deliver the data.

SyncML includes a well-defined set of messages (as shown above) expressed as an XML document or as a multipurpose internet mail extension (MIME) entity. An exemplary specification specifies an XML document type description (DTD) that allows for the presentation of all the information needed to perform synchronization, including data, metadata and commands. The synchronization specification specifies SyncML messages that conform to the DTD to allow SyncML clients and SyncML servers to exchange additions, deletions, updates, and other status information.

Other DTDs define the display of information about the device (such as memory capacity) and the display of various types of meta-information (such as security credentials). SyncML messages are conceptually based on the container concept as defined by the presentation protocol. Each SyncML message includes a SyncML header section and a SyncML body section. The SyncML header contains routing, session, authentication, and message information, and the SyncML body section contains well-defined synchronization data that includes synchronization instructions and status information, each of which forms a sub-container.

The XML-based encoding shown in FIG. 4 is an excerpt of an exemplary plain text encoding of a SyncML message according to the client sync message referenced by step 252 described with reference to FIG. 3B. The illustrated XML-based encoding includes a SyncML header from line 3 to line 9 and a SyncML body from line 10 to line 57.

Lines 1 and 2 contain SyncML version information and common information about the character encoding and XML-encoding employed for the text representation.

Each SyncML header contains a document type definition version information (VerDTD, line 4), SyncML protocol version information (VerProto, line 5), and a session identifier (SessionID, line 6) valid for one sync session to assign all explicit sync messages belonging to it. ), And a message identifier (MsgID, line 7) that is incremented so that each receive synchronization device subsequently receives a sync message with an increasing message identifier number. By way of example, the components, additional options, and required components of the SyncML header described above are included in the SyncML header.

The SyncML body contains several logical and independent subsections. The first state information subsection extends from line 11 to line 19. The first state information subsection relates to the reference addressing of the data records to be synchronized. In particular, the target reference (TargetRet, line 16) defines an international mobile equipment identifier (IMEI) that addresses the client, in this case the cellular communication device, and the source reference (line 17) is the server, In this case, a uniform resource identifier (URI) for defining a networked server device accessible through a hypertext transfer protocol (HTTP) is defined. In addition, addressing of individual data records and data stores is based on the reference address information. Any number of additional state information subsections may also be included, indicated by the second state information subsections extending from line 20 to line 22. For example, the acknowledgment is encoded as status information.

 The SyncML body session further includes a synchronization subsession, wherein the synchronization subsection is further subdivided. For example, client display changes regarding the addition of contacts. Line 26 contains the relative addressing path of the client's contact database, but line 29 contains the relative addressing path of the server's contact database. The relative addressing paths are relative to the reference addressing mentioned above. The meta subsections from line 31 to line 36 contain additional meta-information about the data record (contact) to be added to the server's contact database. The subsections from line 37 to line 51 contain additional instructions and corresponding contact data content. In line 40, the data format of the content data in lines 46 through 48 is defined as an x-vcard meta-format, but the corresponding data content is contained in lines 46 through 48. The local unique identifier (LUID) used to uniquely refer to this contact on the client side is contained in line 44. Any number of additional synchronization information subsections may also be included, indicated by additional synchronization information subsections from line 52 to line 54.

The final command contained in line 56 notifies the server that the client synchronization message of this example is the final message that includes client changes to be reported to the server for synchronization.

The aforementioned method for resuming a previous incomplete synchronization session according to an embodiment of the present invention may be implemented in client and server devices in a number of ways. The following implementations are implementations based on the SyncML standard implementation with elements having enhanced functionality and capabilities to be further suitable for operating in accordance with one embodiment of the present invention.

5 is a block diagram schematically illustrating elements included by a synchronous client device and a synchronous server device according to an embodiment of the present invention. 5 is a diagram illustrating a server 110 representing a network device providing a network synchronization service. The network synchronization service is represented by one or more server applications 112 and corresponding one or more data storage elements 111. One or more server applications 112 provide data synchronization functionality and other applications are represented by one or more client applications 102 of client 100 that is a network device. The one or more data storage elements 111 host data records for manipulation by the one or more server applications 112 and consequently for synchronization with a client, in this case the one or more data storage elements. 111 is for example one or several databases. The server 110 and the client 100 are connected via a communication network transmission. Selection of suitable communication networks for client 100 and server 110 has been provided and mentioned with reference to FIG. 1.

The one or more server applications 112 use a data synchronization protocol implemented as a synchronization server engine 113, which is an element of the server 110 or a process that takes place on the server 110. The data synchronization protocol is specified through the communication network by client applications that each access the provided synchronization server network service and resources. The synchronization server agent 115 interfaces and manages the access and communication of the synchronization server engine 113 to the network and communicates data synchronization operations with the client 100 and each of the one or more client applications 102. Make it possible. The synchronization agent 115 performs the interfacing and communication by including a synchronization interface 116 and a synchronization adapter 117, in which case the synchronization interface 116 is an application for the synchronization adapter 117, for example. It is a program interface (API). The synchronization adapter 117 is each an element of the server 110 or a process performed on the server 110 and conceptually communicates with a corresponding synchronization adapter 107 on the client side. The synchronization adapter 117 is, among other things, one or more server applications 112 that provide data synchronization services between the server 110 and the client 100 and one or more client applications that access and use these synchronization services. Have the ability to fulfill the obligation to establish and maintain network communication connections between the servers 102.

On the client side, one or more client applications 102, along with one or more related data storage elements 101, store data records such that the one or more client applications 102 are accessible. The synchronization client agent 105, the synchronization interface 106, and the synchronization adapter 107. The synchronization client agent 105 enables communication of data synchronization operations with the server 110 and each of the one or more server applications 112. The synchronization interface 106 similarly represents an application program interface (API) for the synchronization adapter 107, for example.

The method according to an embodiment of the present invention mentioned above is implemented in the server 110 and the client provided above, for example by implementing one or several code sections in the synchronization server agent 105 and the synchronization client agent 115. Included within the conceptual element framework of 100, wherein the one or more sections of code include instructions for performing one embodiment of a method of resuming an incomplete synchronization session at runtime. This implementation ensures that when the synchronization session is interrupted, the necessary information for resuming this interrupted synchronization session is logged or stored in the client 100 and the server 110.

6 through 8 are diagrams showing a variant embodiment of the method for resuming a previous incomplete synchronization session relating to data exchange between two devices according to the present invention. The method is characterized by sending a resume signal alert from the first device to the second device, the resume signal alert comprising information regarding the request for resuming the previous incomplete synchronization session. For example, as shown, the first device is a client and the second device is a server. The method also features transmitting a status from the second device to the first device for an alert signal indicative of information regarding the type of synchronization to be performed. The information about the resume signal alert condition may include information for approving a resume session or overriding a previous synchronization type of the previous incomplete synchronization session. If the previous synchronization type is overridden, the server instructs the client to use a different synchronization type. The 'Next' anchor or the second update identifier may or may not be updated if synchronization is interrupted. If the 'Next' anchor is updated after a break or during a pause, this allows for a better user experience, perhaps by allowing synchronization of changed data items during the break.

In step 302 of Figure 6, the client sends a resume signal alert to the server. In step 304, the server responds back to the client with an alert signal state that includes an indicator indicating that the resumption of the session has been approved. In step 306, the client uses the synchronization type of the previous interrupted synchronization session (e.g., fast or slow synchronization) and exchanges the remaining client data. The synchronization session is completed through steps 308 and 310, which are similar to the steps 253 and 254 mentioned above in connection with FIG. 3B. In the above mentioned steps, both the resumption of the synchronization session and the determination of the synchronization type of the previously interrupted synchronization session are included. Once the client has sent a Resume Alert Code, the server agrees to resume the session and sends an alert code appropriate for the Alert element for the corresponding server-side datastore. The client must use this alert code to resume the synchronization session. This avoids storing the synchronization type on the client side if the session is interrupted.

Moreover, the scope of the present invention is intended to include embodiments in which the client should send a resume alert whenever an outage occurs. This may apply even if the client no longer has new or changed items to send in the resume session after receiving the status for all items. In other words, if the transmission was not effective or properly intercepted, the client should request resumption instead of initiation of a new synchronization session. By doing so, this allows the server to send only those items that did not obtain states.

7 illustrates overriding of a resume session by the server. In such a case, the client's resume request in step 302 is not approved by the server so that the server can either enter state 508 (Refresh Sync) or state 509 in step 320, for example. (By sending a different sync type) or by sending another suitable code for the same purpose, then by sending the appropriate sync type of alert code 201 (slow-sync) or 2XX (for another sync type) respectively. You can override the synchronization type. In step 322, the client uses the synchronization type defined by the server and sends all items, not just the remaining five data items. It is intended that the scope of the invention be not limited to any particular status code numbers. It is contemplated that embodiments will use other status code numbers.

8 is a diagram illustrating resumption of a slow synchronization session. The clients request resumption by providing an alert to the server and if the resumption is approved by the server, a 200 status (approval) is sent via an 'Alert for Resume' in step 330. The server further sends an alert 201 to an alert element for corresponding server-side datastores. This is similar to that mentioned above in connection with FIG. 6 with respect to the determination of the synchronization type. However, it is important to note how to distinguish between slow synchronization and the resumption of powerful full slow synchronization since alert 201 currently stands for slow synchronization and the client will initiate a full slow synchronization. To distinguish between slow synchronization and resumption of full slow synchronization, the client may determine by examining the status code sent to the 'Alert for Resume' in step 330. 200 code means resumption of slow synchronization (variant example has status codes for all other synchronization types sending 220 instead of 200 to confirm that the initiation of the resumption session has been approved), and 508 code is fully It will mean slow synchronization. Full slow synchronization can be achieved by sending a 508 state (regeneration required) via a resume alert followed by alert 201-see above. This will allow the client to know that a previously interrupted slow sync cannot be resumed, but instead a full slow sync should be used from the start. This does not mean initiation of a new synchronization session, but may result in such performance if necessary.

According to another embodiment, it is possible to have additional alert codes to indicate 'Alert for Pause'. In other words, this will provide an effective way to abort the synchronization session. Resumption will be made in accordance with the steps previously mentioned herein. This alert code will only help to achieve an effective means for stopping a synchronization session that is usually initiated by the user. When such an alert is received by the second device, it can respond to the alert by a status code, thereby deducing whether the first device can also go into a 'pause mode'. Of course, the 'last' update identifier is not updated. The first device or the second device may send an indicator to the other device indicating that it will resume the later stopped synchronization session. For example, the first device may send a message to the second device that includes a resume signal alert, thereby continuing the stopped synchronization of the devices.

It will be apparent to those skilled in the art that as the technology improves, advanced concepts may be implemented in different and broader ways. Accordingly, the invention and its embodiments are not limited to the examples mentioned above but may vary within the scope of the claims.

Claims (31)

In a method of resuming a previous incomplete synchronization session interruption with respect to data exchange between two devices, Sending from the first device to the second device a signal resume signal alert comprising information related to the request to resume the previous incomplete synchronization session. The method of claim 1, further comprising transmitting a status of an alert signal indicative of synchronization type related information to be performed from the second device to the first device. 3. The method of claim 2, wherein the state of the alert signal includes information that overrides a previous sync type of a previous incomplete sync session. 4. The method of any one of claims 1 to 3, wherein the information associated with the request includes information logged according to the suspension of the previous incomplete synchronization session, which enables resumption of the previous incomplete synchronization session. How to. 5. The method of claim 4, further comprising storing the logged information on each device in response to a previous incomplete synchronization session abort. 5. The method of claim 4, wherein the information logged according to the previous incomplete synchronization session abort includes a first update identifier that includes information about a previous full synchronization session performed between the two devices, And a second update identifier comprising information about an incomplete synchronization session of the < RTI ID = 0.0 >. The method of claim 4, wherein Comparing update identifier information logged in one device with update identifier information logged in another device; And And resuming a previous incomplete synchronization session suspension based on the comparison result. The method of claim 7, wherein Using different synchronization methods for resuming the suspension of a previous incomplete synchronization session according to the comparison result. 7. The method of claim 6, wherein the first update identifier is a LAST anchor and the second update identifier is a next or pause anchor. 10. The method of claim 9, wherein the different synchronization methods include fast resumption synchronization when the received and logged LAST and NEXT anchor information matches according to a previous incomplete synchronization session abort. Way. 10. The method of claim 9, wherein the different synchronization methods match restart and general synchronization when the LAST anchor information received and logged according to a previous incomplete synchronization session abort, but does not match the received and logged NEXT anchor information. starting normal synchronization). 10. The method of claim 9, wherein the different synchronization methods do not match received and logged LAST anchor information according to a previous incomplete synchronization session abort, and when the received and logged NEXT anchor information matches, slow resume synchronization (slow). resumption synchronization). 10. The method of claim 9, wherein the different synchronization methods include complete slow resume synchronization when the received and logged LAST and LAST anchor information do not match according to a previous incomplete synchronization session abort. . 8. The method of claim 7, wherein the logged information also includes the session ID of a previous incomplete synchronization session, the message ID of the last message sent correctly, and one or more unique record identifiers. 8. The method of claim 7, including the step of the second device instructing the first device to resume a previous incomplete synchronization session based on the logged information. In the synchronization method, Establishing a communication connection for data synchronization between a first device and a second device each having a data set to be synchronized; A first update identifier that indicates a previous full synchronization event that was performed between the first device and the second device, the value of which is stored at least in the first device, and the previous start between the first device and the second device; Transmitting a second update identifier indicative of an incomplete synchronization event of and whose value is stored at least in the first device; Restoring or creating an indicator of data that was successfully synchronized during the previous incomplete synchronization event; Synchronizing, using the indicator, data that was not successfully synchronized during the previous incomplete synchronization event; And Updating at least the value of the first update identifier and the value of the second update identifier at the first device. The method of claim 16, Transmit additional information including at least one information from a group associated with the previous incomplete synchronization event and having information on the previous incomplete synchronization, and information on data successfully synchronized according to the received synchronization related information. And further comprising the step of: The method of claim 16, wherein in at least one of the first device and the second device, As a first comparison, comparing a value of the first update identifier sent from the first device with a value of a second update identifier of the first device stored in the second device; As a second comparison, comparing the value of the second update identifier sent from the first device with the value of the second update identifier of the first device stored in the second device; Performing at least one of the following options: If the second comparison results in a match, synchronizing data between the first device and the second device, the data including data that was not exchanged during the previous incomplete synchronization event; If the second comparison results in an inconsistent value, synchronizing data between the first device and the second device, the data including at least data that was synchronized during the previous incomplete synchronization event; If the first comparison results in an inconsistent value, synchronizing data between the first device and the second device, the data including data that was synchronized during the previous full synchronization event; And If the first comparison results in a match, synchronizing data that was not synchronized during the previous full synchronization event between the first device and the second device. The method of claim 16, wherein establishing a communication connection for synchronization comprises: Sending an initial message to at least one of the first device and the second device, the initial message instructing the user to prepare to resume the previous incomplete synchronization. 17. The method of claim 16, wherein the synchronization is based on a synchronization protocol according to the SyncML standard, and wherein the first update identifier is a LAST synchronization anchor. 21. The method of claim 20, wherein the second update identifier is at least one of a NEXT synchronization anchor and a PAUSE synchronization anchor. 21. The method of claim 20, wherein the additional information related to the previous incomplete synchronization event comprises: a synchronization event session identifier (session ID), a synchronization message identifier (message ID), and one or more grant data identifiers and their respective datastores. And at least one piece of information in groups). 23. The method of claim 22, wherein the additional information is stored in at least the first device prior to transmitting the first and second update identifiers. 17. The method of claim 16, wherein the data is successfully synchronized when an acknowledgment for the data or an acknowledgment for the message containing the data is successfully received, wherein the acknowledgment is positive for the motivation of the data or the message. Or to indicate a negative condition. delete delete  A computer-readable storage medium storing a computer program product comprising a program code section executed in a processing device, a terminal device, a communication terminal device or a network device for carrying out the method of claim 16. In a device used in a network and capable of data synchronization, A storage medium having predetermined data sets to be synchronized; When the data contains data that was not synchronized at least during a previous incomplete synchronization event, establish a communication connection to another device used in the network for synchronization of the data, and perform a previous complete operation with the other network device. (complete) communicate with the other network device a first update identifier indicating a synchronization event and at least a second update identifier stored in the network device and at least a second update identifier stored in the network device and at least another A communication interface for exchanging data with a network device; A recovery or generation element for recovering or generating an indicator stored in the network device as an indicator of data that was synchronized during the previous incomplete synchronization event; A synchronization element for synchronizing data, according to the indicator; And And an update element for updating the stored contents of the first update identifier and the stored contents of the second update identifier. The method of claim 28, The communication interface is configured to transmit supplemental side information in association with the previous incomplete synchronization event, The additional information includes information on a successful last exchange of synchronization related information among groups including information about the previous incomplete synchronization, and information on data successfully synchronized according to at least one of received synchronization related information. Device characterized in that. The method according to any one of claims 28 and 29,  In a first comparison, the value of the first update identifier sent from the device is compared with the value of the second update identifier of the device stored in another device, and as a second comparison, the first update sent from the first device. 2 The following options are compared by comparing the value of the update identifier with the value of the second update identifier of the device stored in the other device. If the second comparison results in a matched value, synchronizing data between the device and the other device, the data including data that was not exchanged during the previous incomplete synchronization event; If the second comparison results in an inconsistent value, synchronizing data between the device and the other device, the data including data that was at least synchronized during the previous incomplete synchronization event; If the first comparison results in an inconsistent value, synchronizing data between the device and the other device, the data including at least data that was synchronized during the previous full synchronization event; And And if the first comparison results in a matched value, further comprising at least one of an option to synchronize data that was not synchronized during the previous full synchronization event between the device and the other device. Device. In a synchronization system comprising a first network device and a second network device, The first network device comprises: a storage medium having predetermined data sets to be synchronized; Establish a communication connection to the second network device used in the network for synchronization of data, communicate a first update identifier and a second update identifier to the second network device, and exchange data with the second network device. A communication interface for; A recovery or generation element for recovering or generating an indicator stored in the network device as an indicator of data that was synchronized during the previous incomplete synchronization event; A synchronization element for synchronizing data, according to the indicator; And an update element for updating contents of the stored first update identifier and contents of the stored second update identifier. The second network device comprises: a storage medium having predetermined data sets to be synchronized; Establish a communication connection to the first network device used in the network for synchronization of data, communicate the stored first update identifier and the second update identifier to the first network device, and communicate data with the first network device. A communication interface for exchanging; A synchronization element for synchronizing data according to the indicator; An update element for updating content of the stored first update identifier and content of the stored second update identifier; And comparing, as a first comparison, a value of the first update identifier transmitted from the first network device with a value of the first update identifier stored in the second network device, and as a second comparison, the first network. An element for comparing a value of the second update identifier sent from the device with a value of the second update identifier of the device stored in the second network device, The first update identifier indicates a previous full synchronization event performed with the second network device and is stored in at least one network device, and the second update identifier indicates a previous incomplete synchronization event performed with the second network device. Is stored in at least one network device, The data comprises data that was not synchronized during at least the previous incomplete synchronization event if the comparison resulted in identical identifiers, and wherein the exchanged information is based on the indicator.

Images