JP4494970B2 - Method, apparatus, and system for synchronizing data in response to an interrupted synchronization process - Google Patents

Description

  The present invention relates to a method and apparatus for synchronizing data between a client apparatus to be synchronized and a server apparatus to be synchronized, and to the individual apparatuses to be synchronized. More particularly, the present invention relates to a data synchronization method and data processing apparatus that can better handle interruptions in an active synchronization process.

  Data synchronization is a concept or technique well known to users who use at least two electronic devices and process the same data with these electronic devices. In general, synchronization is performed between a terminal device (for example, a mobile phone) and a server device (for example, a local PC application or a dedicated synchronization server). Data from terminals (eg, portable computers, PDA terminals (personal digital assistants), mobile phones, mobile stations, pagers) is converted to networked devices that function as synchronization servers (eg, networked applications and desktops) Can be synchronized by a computer application) or by other management applications included in the data store of the communication system. Here, the term “data store” should be understood in the broadest possible way. That is, the term includes any data set. In general, what is synchronized is in particular calendar data, contract data, email application data, as well as device / application settings and configuration data.

  Synchronization is based on the use of special protocols that vary from manufacturer to manufacturer and are not compatible. This limits the type of terminal or data used, causing trouble for the user. Particularly in mobile communication, it is important that data can be collected and updated regardless of the terminal or application used.

  To improve the synchronization of application data, a language called SyncML, known as the synchronization markup language, was designed. It is based on an extensible markup language (XML). By using the SyncML synchronization protocol that uses SyncML format messages, data of any application can be synchronized between the networked terminal and any type of network server. The SyncML synchronization protocol works on both wireless and fixed networks and supports several transmission protocols. With the above SyncML synchronization technology, it is possible in particular to synchronize data stores or databases.

  Normally, the synchronization of data records is to reconcile two different predetermined data record sets stored in different storage locations (ie separate synchronization devices that manage and use that storage location), ie corresponding state Therefore, it is executed at a certain time. The result is two identical data record sets in both storage locations at that time. The synchronization of data recording at a certain time is also called a synchronization session. The synchronization of the data record set is done by exchanging information during such a synchronization session. Sending commands and commands to both synchronizers changes the data record set stored therein and harmonizes them. Such change operations include data addition, data movement, data addition to current data, data update, and the like. For the purpose of exchanging necessary information and commands, each synchronizer synchronizes one or more messages that contain all the information, commands, and commands required for harmony operation in a distributed manner. This is achieved by communicating between each other. Furthermore, when each of the one or more messages is authenticated, it is possible to know which operation was successful according to the message information contained therein.

  Basically, the above synchronization process can be handled and executed either by a full synchronization process (also called slow synchronization) or an incremental synchronization process (also called normal synchronization or fast synchronization). While a complete synchronization process or a slow synchronization process is being performed in a synchronization session, the entire set of predetermined data records of both devices involved in the synchronization is harmonized. While the sync session is running an incremental sync process or a fast sync process, both participating sync units record the time of the last completed sync session and that time recorded on both sync units Are matched, only data records changed after that time are selected for synchronization and all other data records are excluded from the synchronization process. Thus, the change log can be maintained by a synchronizer that records changes and adds or deletes the time of data recording. Alternatively, the change can be revealed by examining the record modification time stamp when there is a record change. Both synchronization processes, so-called slow synchronization and so-called fast (normal) synchronization, are defined and used in the SyncML standard. Still other types of synchronization processes are available and utilized, but these other types of synchronization processes can be reduced to the basic synchronization process described above.

  When one record and / or group of records is synchronized with another database, authentication is returned to the sender of that record. Two basic methods of handling authentication can be realized in synchronous applications. In the first implementation, each successful synchronization of a data record or group of data records is authenticated and recorded by the synchronizer, preferably as one or more change logs indicating it. In the second implementation, authentication is handled at the end of the synchronization session (ie, as soon as both synchronizers indicate that the synchronization session has been properly terminated) and the corresponding communication that will be used. Connected. Furthermore, the handling of authentication at the end of the synchronization session and the update of the time indicating the last completed synchronization session are processed substantially simultaneously. Obviously, when the synchronization session is executed in a slow synchronization manner, consideration of the time indicating the last completed synchronization session is unnecessary.

  In the first implementation method, data integrity is maintained and ensured mainly using, for example, a synchronization application used to connect and synchronize distributed databases with each other at high speed. In such an implementation, the capacity required to record and maintain the change log for each data record, as well as the processing power required to process the change log, are required to exchange the required authentication. The network bandwidth is also not very important. Considering the synchronization of data stored in small electronic devices (for example, mobile phones, mobile computers, PDAs, oscillators, etc.), the storage capacity and processing capacity are limited, so change logs for each data recording The operation of recording, maintaining and processing is a heavy burden and can only be done poorly and sometimes impossible. Furthermore, network traffic resulting from the required authentication is not accepted. This is because the mobile communication environment is costly and time consuming.

  The second implementation, in which time stamp updates and item authentication are handled at the end of a session, is suitable for use on small electronic devices and is supported by the SyncML standard. However, this implementation has the problem that no interruption of the currently running synchronization session is indicated. It is not possible to maintain synchronization information exchanged during a partially executed synchronization session. This is because the update of the time stamp (synchronization anchor) performed at the end of the synchronization session and the handling of authentication are not performed for interruption. Even if the authentication of the data item is handled during the session, the time stamp is only updated at the end of the session, so the synchronization information already processed is lost due to the late synchronization interruption. In both cases above, it is necessary to repeat the synchronization session to ensure data integrity. Depending on the amount of information involved in synchronization, i.e. the number of data records to be synchronized, a large number of messages are exchanged during a single synchronization session, which usually contains only a few synchronization messages Even there. For example, suppose 400 out of 500 data records could be synchronized during a single synchronization session, where an interruption occurred. In subsequent synchronization sessions, all 500 data records must be re-synchronized, regardless of whether the synchronization is performed in a fast or slow synchronization process.

  It is an object of the present invention to provide a method that can resume an interrupted synchronization session to avoid repeating the entire interrupted synchronization session. The facility for resuming an interrupted synchronization session is configured so that it does not require large storage capacity, large processing power, multiple authentications to be exchanged, and no wide communication bandwidth. This method is suitable for economically realizing small electronic devices.

  In one embodiment of the present invention, a method is provided that can resume a past incomplete synchronization session that was interrupted during operation. The resumption of the past incomplete synchronization session is realized by the following operation.

  A communication connection is established to synchronize data between the first device and the second device. The first device and the second device each have a data recording set to be synchronized. Typically, data records are housed in data storage devices or databases by corresponding applications.

  In one embodiment of the present invention, a method is provided for resuming a past incomplete synchronization that was interrupted with respect to data exchange between two devices. The method features the step of sending a restart warning signal from the first device to the second device including information relating to a request to restart a previous incomplete synchronization session. The resume warning signal is at least a direct alert code that directly indicates the resume session or a signal that can be estimated by the server (eg, an indication of the time stamp used in the session, or something else that identifies the session) can do. The method also includes the step of sending information about the type of synchronization to be performed from the second device to the first device as the state of the warning signal. Information regarding the state of the resume warning signal may include information that invalidates the synchronization type of the previous incomplete synchronization session.

  In another embodiment according to the present invention, the first update identifier and the second identifier are sent 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 is requesting to resume a previous incomplete synchronization session and the direction of synchronization. The device requesting the resume sends both identifiers to the other device. The first update identifier identifies a past complete synchronization session performed between the first device and the second device. The first update identifier is stored in the first device and the second device while initializing a past complete synchronization session. More specifically, although the value of the identifier is stored, the name or storage location of the value may vary depending on the implementation method. In general, the first update identifier is a time stamp used to record the start time of a past complete synchronization session. Alternatively, the identifier may be an arbitrary numerical value. For example, monotonically increasing integer strings, text strings, or mixtures thereof can be generated in order, or at least to some extent, i.e., partially generated randomly. According to the present invention, the second update identifier identifies a past incomplete synchronization session performed between the first device and the second device. The second update identifier is stored in the first device and the second device while initializing a previous incomplete synchronization session. In general, the second update identifier is also a time stamp or the like used to indicate the start time of an interrupted incomplete synchronization session. However, in the prior art, the behavior and use of the second update identifier is specified only during the synchronization session and not after the session is interrupted or terminated.

  The method of the present invention includes four synchronization steps. The first step includes establishing a communication connection to synchronize data between the first device and the second device, each of which has a data set to be synchronized. The second step includes an operation of transmitting the first update identifier and the second update identifier. The first update identifier represents a past complete synchronization session executed between the first device and the second device, and a value is stored in at least the first device. The second update identifier represents a past incomplete synchronization session started between the first device and the second device, and a value is stored at least in the first device. The third step involves recovering or forming an indication of data that has been successfully synchronized during a previous incomplete synchronization session. The fourth step uses this indicator to synchronize data that did not synchronize well during the past incomplete synchronization session; (4) at least the first device sets the value of the first update identifier to It includes an operation for updating with the value of the update identifier of 2.

  This method relates to past information that is related to an incomplete synchronization session and includes data that has been successfully synchronized according to the received synchronization related information, with additional information including at least one piece of information about the past incomplete synchronization. It also includes the step of transmitting information.

In this method, in at least one of the first device and the second device, the value of the first update identifier transmitted from the first device is stored in the second device in the first comparison. compared with the first value of the update identifier of the first device being; in the second comparison, the value of the second update identifier transmitted from the first device, is stored in the second device Compare with the value of the second update identifier of the first device that has the following options:
1) If a true value is generated by the second comparison, data including data that has not been exchanged during the previous incomplete synchronization session is transferred between the first device and the second device. Synchronizing step;
2) If a false value is generated by the second comparison, data between the first device and the second device contains at least data that was synchronized during the previous incomplete synchronization session. Synchronizing step;
3) If the first comparison generates a false value, synchronize the data containing the data synchronized during the past complete synchronization session between the first device and the second device Step;
4) If the first comparison produces a true value, the step of synchronizing the data that was not synchronized during the previous full synchronization session between the first device and the second device It also includes the step of performing at least one of them.

  The operation of establishing a communication connection for synchronization includes sending an initial message instructing at least one of the first device and the second device to resume past incomplete synchronization. Can be included.

  The synchronization is based on a synchronization protocol according to the SyncML standard, and the first update identifier is a LAST synchronization anchor. The second update identifier is at least one of the next sync anchor and the dormant sync anchor. In addition, additional information regarding past incomplete synchronization sessions includes synchronization session identifier (session ID), synchronization message identifier (message ID), authenticated data and one or more of each corresponding data store. Information on at least one of a group of identifiers can be included. Further, the additional information is stored at least in the first device before transmitting the first update identifier and the second update identifier.

  In this way, if the authentication of the data or the message containing the data is successfully received, the data is successfully synchronized, and the authentication is either successful or unsuccessful in synchronizing the data or message. Is shown.

  According to the present invention, a software tool for synchronization including a partial program group for executing all the steps of the above method, which is executed in any one of a processing device, a terminal device, a communication terminal device, and a network device Software tools implemented as computer programs and computer programs or computer program products for synchronization are also provided.

  The present invention also provides an apparatus that can be used in a network to synchronize data and includes a storage medium, a communication interface, a recovery element or forming element, a synchronization element, and an update element. The storage medium includes predetermined data sets that are synchronized with each other. The communication interface establishes a communication connection for the purpose of synchronizing data in another device used in the network, and communicates between the first update identifier and the second update identifier between the other network devices. And exchange data with that other network device. The first update identifier represents a past complete synchronization session performed using another network device and is stored at least in this network device. The second update identifier represents a past incomplete synchronization session and is stored at least in this network device. The data includes at least one data synchronized during a past incomplete synchronization session. The recovery element or forming element recovers or forms an indication stored in the network device for data synchronized during a previous incomplete synchronization session. The synchronization element synchronizes data according to the index. The update element updates the content of the stored first update identifier with the content of the stored second update identifier.

  The communication interface can be configured to transmit supplemental additional information regarding past incomplete synchronization sessions. This supplemental additional information includes at least one of the group consisting of information about previous incomplete synchronization sessions, information about the last successful exchange of synchronization related information, and information about data successfully synchronized according to received synchronization related information. One piece of information can be included.

Comparison device, the comparison of the first time, the value of the first update identifier transmitted from the first device, the first value of the update identifier of the first device stored in the second device In the second comparison, the value of the second update identifier transmitted from the first device is compared with the value of the second update identifier of the first device stored in the second device. An element can also be provided. This element performs at least one of the options described above with respect to the method of the invention.

  In accordance with the present invention, a first network device and a second network device are provided, each device having elements for performing similar steps as described above with respect to the method and apparatus of the present invention as a whole. An included synchronization system is also provided.

  The invention is explained in more detail by means of embodiments with reference to the accompanying drawings.

  In the following, embodiments of the present invention will be described with respect to a system that supports the SyncML synchronization standard, but the present invention is not limited to such a system. Information about the SyncML standard can be obtained from the SyncML initiative, which publishes all standard documents. The same reference numbers are used for the same or equivalent parts and / or elements and / or operations shown.

  FIG. 1 is a schematic diagram of a specific group of electronic devices that synchronize information with each other. For example, the predetermined content of the data store of the mobile terminal is from a specified device (eg, some other mobile terminal and / or a central storage device that stores the contents of the data store and can be accessed from a fixed terminal) It will be harmonized with the contents of the provided data store. Conventionally, a mobile terminal functions as a sync client, and data related to a predetermined application running on the sync client is provided from one or more dedicated server devices that mainly store data related to the application. Harmonize or synchronize with the contents of the data store. FIG. 1 shows a plurality of client devices and server devices that can be synchronized with each other. In general, the client device is a mobile station, for example, a mobile phone 17, a personal digital assistant (PDA), a portable computer such as a notebook personal computer 15, an electronic device such as a digital camera 16 that stores digital data, a desktop -Fixed terminals such as computers (PC). Furthermore, as the dedicated synchronization server device, a fixed terminal (desktop computer 10, dedicated network server 11 (for example, using its synchronization capability as a networked synchronization application) is possible, and a portable computer (for example, synchronization) (Notebook computers running server applications, etc. 12) The concept of synchronization was explained using a mobile terminal connected to a dedicated server device, but the client device functions are limited to the above mobile terminals. There is no.

  A corresponding synchronization process according to the SyncML protocol standard is established through a suitable communication connection. The logical communication connection is realized by using a transport protocol adapted to the synchronization protocol in an arbitrary communication network. Suitable communication networks include not only local area networks (LAN) and wide area networks (WAN), which can include the Internet and corporate intranets, but also serial networks based on radio (for example, universal serial bus (USB) ) And standardized serial communication (for example, RS-232) The involved synchronization devices can also be connected through a wireless communication network, for example, mobile communication supporting a mobile network. Global System (GSM) service and / or General Packet Radio Service (GPRS), 3rd generation mobile communication networks (eg General Mobile Communication System (UMTS) network), Wireless Local Area Network (WLAN) ), Narrow range wireless communication networks (eg Bluetooth network, wireless local loop (WLL)) Infrared network (IrDA), etc. Not only can the logical communication connection between the involved synchronization devices be provided from a single communication network of the type described above, but also the communication networks connected to each other, if necessary, It can also be provided from several networks of the type described above connected together by a dedicated network routing device that translates between the data protocols of the respective networks used.

  With regard to the SyncML protocol standard and the SyncML synchronization protocol standard, and therefore also with respect to the SyncML device management protocol standard, the SyncML device management protocol is realized at the head of an appropriate protocol according to the type of communication network to be used. Suitable protocols that can implement the SyncML synchronization protocol at the beginning are Hypertext Transfer Protocol (HTTP), Wireless Application Protocol (WAP) standard wireless session protocol (WSP), and cable connections (eg, Universal Serial Bus (USB)) Or RS-232), or the Object Exchange Protocol (OBEX), which is used for narrow-range wireless communication connections (Bluetooth), or for infrared connections (IrDA) A Transport Control Protocol / Internet Protocol (TCP / IP) stack provided by an e-mail protocol (eg, Simple Mail Transfer Protocol, SMTP).

  Transfers at lower layers include short message SMS (short message service) or other signaling transmission methods (eg USSD; unstructured supplementary service data), circuit-switched data call, packet-switched data transfer service It can be executed according to a subordinate network using a pager message service, a message through a cell broadcast, or the like.

  In the future, the term data store will be understood as broadly as possible. That is, any data set provided from the accessed data storage device is included in this term. In particular, the data set is relevant to a particular application and meets application-specific conditions (eg data such as calendar application, directory application, contact application (eg vcard application), email application, etc.) Configure. In addition, any data set can be in the form of one or more databases that contain data records that provide the data to be accessed. Further, the term data store is intended to include network data services or networked services. That is, as with the data store, all data sets provided by the networked service being accessed are included. Typically, a network service is based on a data store that contains the contents of the data store related to a particular service.

  The following sequence diagram shows an operation sequence according to an embodiment of the present invention. The operation sequence shown here is merely an example, and is not limited thereto. Other embodiments based on similar or related operation sequences are possible.

  FIG. 2 is a time sequence diagram of a synchronization process according to one embodiment of the present invention, showing several messages exchanged between a synchronizing client device and a synchronizing server device.

  A SyncML synchronization session is conceptually divided into so-called SyncML packages. The SyncML package is simply a conceptual framework for one or more SyncML messages that are physically exchanged between the devices to be synchronized and are required to carry a collection of synchronization information and commands. Not all SyncML packages are involved in any type of synchronization given by the SyncML standard. The exact number of SyncML messages depends on the amount of information transmitted.

  A rough overview of the SyncML package is given in the list below. A detailed description can be obtained from the SyncML standard document.

  Package 0-Start synchronous message. The client device can receive a given message (so-called “notification” or “warning”) even though it has not been requested, and can instruct the receiving device to establish a reverse connection to initiate a synchronization session. . Note that the same effect as receiving a notification can be achieved in other ways.

  Package 1-Initialization from client device to server device. One or more initialization messages are sent. Initialization messages include, for example, client device information (device identifier, etc.), client device properties, client authentication, synchronization type, database identification to synchronize data records, stored last anchor, new next An anchor etc. are mentioned.

  Package 2-Initialization from server device to client device. One or more initialization messages are sent. Examples of the initialization message include server device information (device identifier, etc.), server device properties, server authentication, response information and status information regarding information included in one or more client initialization messages, and the like.

  Packages 1 and 2 are part of the initialization phase. The following packages 3-6 are part of the synchronization phase of the synchronization message.

  Package 3-Client to server synchronization. One or more client synchronization messages are sent. Client synchronization messages include, for example, client data changes (i.e. any changes to the client database data identified during synchronization initialization). In the case of a fast synchronization process, only data records that have changed since the last synchronization session (last anchor) are reported. In the case of a slow synchronization process, all data records are reported.

  Package 4-Server to client synchronization. One or more server synchronization messages are sent. Server synchronization messages include, for example, information about the server analyzing changes to client data sent and server data changes (ie any changes to server database data identified during synchronization initialization). is there. In the case of a fast synchronization process, only data records that have changed since the last synchronization session (final anchor) are reported. In the case of a slow synchronization process, all data records are reported.

  Package 5-Data update status, map operations. One or more data update status messages are sent. Data update status messages include, for example, information on data update (synchronization due to server changes) results, and map operations (tables) for mapping local unique identifiers (LUIDs) and global unique identifiers (GUIDs). Can be mentioned. A local unique identifier is an identifier assigned to a data record and is locally unique on the client side (ie, for one device and one application). A data record can be identified by a local unique identifier. The global unique identifier is an identifier assigned to the data record and is locally unique on the server side.

  Package 6-Map authentication. One or more map authentication messages are sent. Examples of the map authentication message include authentication for notifying the client device of one or more data update status messages from the server.

  Depending on what synchronization information and commands are included in the client message or server message, a client message according to package 3 can generate a server response message according to package 4 and vice versa.

  Since each message of the synchronization message includes a session identifier (session ID), the message can be associated with one independent synchronization session. Since each message includes a message identifier (message ID), it is possible to prevent the exchanged messages from being arranged incorrectly in the client device and the server device. In addition, the last message for each package type includes a final indicator that indicates that it is the last one.

  The synchronization process consists of what information (which data record) is synchronized (slow synchronization or fast synchronization, i.e., the total number of data records after a predetermined time or only changes), and which device (client device, server device). A distinction is also made according to which of the two devices performs synchronization and from which device synchronization is initiated. Synchronization types include, for example, two-way synchronization, slow synchronization, one-way synchronization from the client only, refresh synchronization from the client only, one-way synchronization from the server only, refresh synchronization from the server only, and synchronization that the server warns. Is possible.

  The enumerated synchronization type names themselves describe the synchronization process and are easy to understand. A more detailed explanation can be found in the SyncML standard document.

  For example, the time sequence diagram and synchronization process shown in FIG. 2 is based on a fast bi-directional synchronization type, but the present invention includes other types of synchronization. Client 100 synchronizes with server 110. According to the above description of the package sequence, the illustrated synchronization session is configured with an initialization phase 210 followed by a synchronization phase, each phase including several synchronization messages. All synchronization messages contain the same session ID (not shown).

  In the initialization stage 210 of the client 100 and server 110, both devices exchange device information (device identifier, etc.), device properties, and device authentication information. The client 100 further defines the type of synchronization (here, fast bidirectional synchronization type) and reports the stored last (LAST) anchor and the newly defined next (NEXT) anchor to the server 110. The server 110 compares the final anchor sent from the client 100 with the corresponding value stored in the server 110, and when the received final anchor matches the stored final anchor, fast synchronization is possible. To match the final anchor and the next anchor. The state (content) of the next anchor is not defined in the server 110 until the client 100 sends this newly defined state (indicated by the “?” Symbol) (prior art, ie the traditional two-way synchronization process). Does not give a special value to that state). If the anchors do not match, a warning for slow synchronization is sent to the client 100. The information exchange in the initialization stage 210 is performed by a first operation 200 meaning a client initialization message corresponding to a package type 1 message and a first operation 201 meaning a server initialization message corresponding to a package type 2 message. It is shown. Both messages represented by operations 200 and 201 contain the same message ID1.

  After the initialization phase 210 is completed, the client 100 prepares for synchronization 211. That is, the data record changed according to the last anchor received is identified. The client synchronization message (package 3 type message) shown in operation 203 includes the first batch (here, 5 of the 10 changes identified) relating to the client changes. Note that client changes include the contents of commands and / or data. Commands specifically include add, update, delete, etc. These are combined with the data contents to synchronize the respective data records. In addition, the message further includes status information regarding past server initialization messages. Server 110 receives the first client synchronization message, analyzes the received client changes, resolves conflicts that may arise from the client changes, and processes the client changes (operation 212). The corresponding server synchronization message (package type 4 message) indicated in operation 204 includes authentication of client changes and information regarding the status of the analysis / synchronization process and is sent to the client. Both the client synchronization message indicated by operation 203 and the server synchronization message indicated by operation 204 can be identified by a common message ID (here, message ID2). However, it should be understood that the message numbers may differ from those shown above. In fact, the only purpose of numbering messages is to ensure that each device has a consistent message number. That is, the numbering at the client and server does not even need to match.

  The next client synchronization message (package type 3 message) shown in operation 206 contains a second batch of client changes (here, the remaining 5 out of a total of 10 changes identified). . The client sync message further includes a final indicator indicating that it is the last client sync message containing client changes. Server 110 receives this final client sync message, analyzes the received client changes, resolves any conflicts that may arise from the client changes, processes the client changes, and includes a final indicator The server changes (identified taking into account the server's final anchor) are prepared (operation 212). The corresponding server synchronization message (package type 4 message) indicated in operation 207 includes server change items, authentication of client change items, and information regarding the status of the analysis / synchronization process, and is transmitted to the client. According to the synchronization session shown in FIG. 2, a single server synchronization message is sufficient to send all identified server changes to the client, and this message also includes the final indicator. In operation 214, the server change received by the client 100 is processed. Both messages shown in operations 206 and 207 contain the same message ID3.

  Next, the client update status message (package 5 type message) indicated by operation 208 is sent to the server 110. This client update status message includes authentication information and synchronization status information due to server changes. Then, if necessary, a map operation is also sent to the server 110 that processes the data record map table for assigning local unique identifiers and global unique identifiers. Finally, although not shown, the server 110 may respond to a client update status message that includes one or more map authentication messages (package 6 type messages).

  Finally, the communication connection over which the synchronization session and the synchronization message of this session are communicated is closed. If no error is detected regarding the termination of the synchronization session and the communication connection, the contents of the next anchor defined at the beginning of the synchronization session are stored. This assignment is performed at operation 215 on the client 100 side and at operation 216 on the server side (actually the server may not call the final anchor, but the value stored in the anchor is Next anchor value sent by the client). The next fast synchronization process is thus possible.

  Data record changes made on the client or server side during the synchronization process by specifying the next anchor at the beginning of the synchronization session and assigning the contents of the next anchor to the final anchor after the synchronization session has been properly terminated Note that collisions due to are prevented. Note also that the contents of the final anchor and the next anchor shown illustrate exactly how they are used. For practical reasons, the final anchor and the next anchor are usually composed of or derived from date values and time values. With such a configuration, it is possible to generate a final anchor and a next anchor without ambiguity.

  FIG. 3a is a time sequence diagram of a synchronization process according to an embodiment of the invention similar to FIG. The synchronization session shown in FIG. 3a is the same as that shown in FIG. That is, the initial conditions, operations 200 to 204, and operations 210 to 212 are executed in the same manner. Correspondingly, in the operations shown in FIG. 3a, the operations common to those in FIG. 2 are given the same reference numerals.

  In FIG. 3a, the initialization stage and corresponding initialization messages of the client 100 and the server 110 are omitted. Operation 203 related to the first client synchronization message (package 3 type) containing the first 5 of the 10 client changes, and the first server synchronization message (package 4) containing status information corresponding to the client change The operation 204 regarding the type message) is shown.

  In operation 205, synchronization is interrupted or stopped. A break or stop can occur for several reasons. To name just a few of these, sync sessions are suspended because of user interaction, user initiatives, lack of power on the client 100 or server 110 (eg due to insufficient battery or accumulator capacity), communication connection failures ( For example, due to lack of coverage in the wireless communication network or interference in communication connection).

  In order to allow the synchronization session to be resumed according to one embodiment of the present invention, the client 100 and server 110 record information regarding the incomplete synchronization session. This information for resuming an incomplete synchronization session includes at least the final anchor and the next anchor of the client 100, and the final anchor and the next anchor are recorded in both the client 100 and the server 110. In addition, this information may include the session ID of the incomplete synchronization session, the last message ID that was properly transmitted and received authentication by the client 100, and one or more unique data record identifiers. That is, during the incomplete synchronization session, the local unique identifier or global unique identifier of the data record due to such a change is transmitted and the transmission is authenticated.

  Instead of using the next anchor to record the time at which the incomplete synchronization session began, a new anchor (eg, a PAUSE anchor) is defined and used specifically to resume the incomplete synchronization session. The concept of the present invention will be described below 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 a new dormant anchor, the term next anchor can simply be replaced by a dormant anchor.

  FIG. 3b is a time sequence diagram of the synchronization process according to one embodiment of the present invention for resuming the interrupted or stopped synchronization process of FIG. 3a.

  Resuming a synchronization session is initiated by a new initialization message (type 1 package) operation 250 that includes a warning command sent from the client 100 to the server 110 to resume a previous incomplete synchronization session described with reference to Figure 3a. Is done. This new initialization message includes at least one final anchor and the next anchor recorded by the interruption of a previous incomplete synchronization session (operation 205 of FIG. 3a). The server receives these final and next anchors from the client and compares them with the final and next anchors recorded by the server itself. Note that when compared to the synchronization session shown in FIG. 2 and its counterpart shown in FIG. 3a, the next anchor has a well-defined state and content on the server side.

  At least one of the client 100 and the server 110 may command, initiate, or execute any one of the following four options, depending on whether the final anchor matches the next anchor: it can.

  1) If the received and recorded final anchor matches and the received and recorded next anchor also matches, server 110 indicated in operation 251 including at least one final anchor and the next anchor for authentication Confirm incomplete synchronization session resumption (fast resumption of synchronization) by sending server initialization message (type 2 package). This confirmation to allow resumption may be based on further information regarding the incomplete synchronization session to be resumed (as indicated by operation 205 in FIG. 3a). For example, the session ID recorded for an incomplete synchronization session and / or the message ID recorded for the last message sent properly is referenced during the recorded anchor verification operation.

  2) If the received and recorded final anchor matches but the next received and recorded anchor does not match, a (normal) fast synchronization session of the type shown in FIG. 2 is commanded by the server. The next anchor mismatch prevents the incomplete synchronization session restart described with reference to FIG. 3a.

  3) If the last anchor received and recorded does not match, but the next anchor received and recorded matches, the server is instructed to resume the slow synchronization session. This resumption of the slow synchronization session is not shown in FIG. 3b. In short, synchronization-related information is exchanged by resuming a slow synchronization session, and it becomes possible to synchronize all predetermined data records to be synchronized. However, synchronization related information that is successfully synchronized and synchronized during the incomplete synchronization session shown in FIG. 3a is excluded from the late restart synchronization session.

  4) If the last received and recorded anchor does not match and the next received and recorded anchor does not match, neither the fast synchronization session nor the slow synchronization session can be resumed. Also, fast synchronization is not possible. To establish a properly synchronized state between both participating devices, run a full version of a slow synchronization session (already described; not shown in Figure 3b) that includes all data records to be synchronized There is a need.

  The following description is based on the assumption that the first case (the case where the last anchor received and recorded matches the next anchor received and recorded) is correct. This case is also shown in FIG. 3b, which shows the last anchor and next anchor status (values) recorded by both client 100 and server 110. The server 110 transmits a server initialization message (package 2 type) shown in operation 251 including at least the final anchor and the next anchor for authentication.

  As described with respect to operation 205 of FIG. 3a, additional log information regarding an incomplete synchronization session is stored upon interruption. As already explained, this information can include at least one session ID for an incomplete synchronization session, a message ID for the last message sent properly, and one or more unique data record identifiers. . That is, during the incomplete synchronization session, the local unique identifier or global unique identifier of the data record due to such a change is transmitted and the transmission is authenticated. Since the information provided by the local unique identifier may not be sufficient, the database identifier may have to be stored in addition to the local unique identifier. By combining the local unique identifier and the accompanying database identifier, the corresponding data record referenced by the local unique identifier is determined (without ambiguity). The database identifier can be a uniform resource locator (URI) as known in the prior art.

  With the last anchor and next anchor and information stored for the incomplete synchronization session, the state when the previous incomplete synchronization session was interrupted can be recovered (re-established). With this type of reconfiguration, now shown in FIG. 2 which represents a complete synchronization session, shown as operations 206-208, the same synchronization session is interrupted after the transmission of the synchronization message by operation 204 (FIGS. 2 and 3a). Thus, it is possible to generate a message that is incomplete in FIG. 3a.

  The new client and server initialization messages indicated at operations 250 and 251 also include information necessary to establish the synchronization session described with reference to operations 200 and 201 shown in FIG.

  This specification assumes that the conditions for resuming an incomplete synchronization session are met, the incomplete synchronization session has been reconfigured, and the client 100 can perform the method according to one embodiment of the present invention. . The client synchronization message (package 3 type) indicated by operation 252 corresponds to the second client synchronization message indicated by operation 206 in FIG. The client sync message thus contains the last 5 of the 10 changes and a final indicator that indicates that this message is the last client sync message of the current sync session. Further, since the message number, i.e., the message ID, is tailored to the current resume sync session, the client sync message of FIG. 3b follows the previous message ID1 for the initialization message (shown by operations 250 and 251). Message ID2. (It is important to note that sessions with other types of message numbers are also included within the scope of the present invention.)

  Server 110 responds to the client synchronization device and transmits a server synchronization message (package 3 type) indicated by operation 253 (which corresponds to the second client synchronization message indicated by operation 206 in FIG. 2). This server synchronization message includes server changes, authentication of client changes, and information about the status of the analysis and synchronization process. According to the synchronization session shown in FIG. 2, a single server synchronization message is sufficient to send all identified server changes to the client, and this message also includes the final indicator. Both messages indicated by operations 252 and 253 contain the same message ID2.

  Next, the client update status message (package 5 type message) indicated by operation 254 is sent to the server 110. This client update status message includes authentication information and synchronization status information due to server changes. If necessary, a map operation is also sent to the server 110 where the data record map table is processed and assigned a local unique identifier and a global unique identifier. This client update status message corresponds to the client update status message shown in operation 208 described with reference to FIG. Finally, although not shown, the server 110 may respond to a client update status message that includes one or more map authentication messages (package 6 type messages).

  Finally, the synchronization session is terminated, and the communication connection through which the synchronization message of this session is communicated is also terminated. If no error is detected regarding the termination of the synchronization session and communication connection, the content of the next anchor defined at the beginning of the synchronization session is assigned to the final anchor. This assignment is executed in operation 260 on the client 100 side and in operation 261 on the server 110 side. The next fast synchronization process is thus possible. Specifying the next anchor at the beginning of a synchronization session and assigning the contents of the next anchor to the final anchor after the synchronization session has ended properly results from a change in data recording on the client or server side during the synchronization process Note that collisions are prevented. Note also that the contents of the final anchor and the next anchor shown illustrate exactly how they are used. For practical reasons, the final anchor and the next anchor are usually composed of or derived from date values and time values. With such a configuration, it is possible to generate a final anchor and a next anchor without ambiguity.

  Note also that changes related to data recording after an incomplete synchronization session and before resuming the synchronization session are not considered while resuming the incomplete synchronization session. The resume synchronization session brings the state of the data record or the state of the data store containing the data record as if the incomplete synchronization session was successfully completed. Therefore, the next anchor representing the synchronization session time stamp is not updated while initializing the resume synchronization session. Changes that occur after an incomplete sync session can be synchronized by starting a sync session after starting a successful resume sync session. In particular, since the last anchor stored in the client 100 and the server 110 is updated and valid, a fast synchronization session can be started.

  The authentication described in the context of an embodiment of the present invention should be interpreted as any type of response to data received from the other device, in which the data or message is well synchronized. The state which went and the state which does not go are included. In general, authentication confirms a record update, but authentication can also include information about a failed operation, for example, caused by a missing record. However, such error handling is not the subject of the present invention, but it is left to the method of handling the error in some way. However, an error should not prevent the session from being resumed. That is, the session must be resumed when the data item is first authenticated, regardless of whether the data item has previously had an error.

  FIG. 4 is an excerpt of an XML encoded synchronization message in the synchronization process according to one embodiment of the present invention shown in FIG. 3b.

  Select industry standard extensible markup language (XML) to specify synchronization messages that synchronize devices and applications for easy and interoperable use (plaintext or wireless binary XML (wireless application Binary technology used in the protocol)). SyncML is designed to fit into the memory capacity of all common mobile devices, both in static code and runtime execution space. To reduce the memory required to store messages and reduce the resources required to process and send the data, the data is typically used, especially using binary coded Extensible Markup Language (WBXML) Code it.

  SyncML contains a well-defined set of messages (as shown above) represented as XML documents or multipurpose Internet mail extension (MIME) entities. The display specification specifies an XML document type description (DTD) that enables display of all information (data, metadata, commands) necessary to perform synchronization. The synchronization specification specifies a SyncML message that matches the DTD so that the SyncML client and SyncML server can exchange additional information, deletion information, update information, or other state information.

  Other DTDs specify the display of information about the device (eg memory capacity) and the display of various types of meta-information (eg security credentials). SyncML messages are based on the container concept defined by the display protocol. Each SyncML message includes a SyncML header section and a SyncML body section. The SyncML header section contains routing, session, authentication, and message information, while the SyncML body section contains a variety of well-defined synchronization data that each form a sub-container (eg status information, synchronization commands) Is included.

  The coding based on XML shown in FIG. 4 is an excerpt of an example in which the SyncML message, which is the client synchronization message of the operation 252 described with reference to FIG. The illustrated XML-based code includes a SyncML header section that extends from line 3 to line 9 and a SyncML body section that extends from line 10 to line 57.

  Lines 1 and 2 contain common information regarding the XML encoding used, common information regarding character encoding used for text display, and SyncML version information.

  Each SyncML header contains document type definition version information (VerDTD, line 4), SyncML protocol version information (VerProto, line 5), and ambiguity that is valid for and belongs to that synchronization session. The session identifier (session ID, 6th line) assigned to all synchronization messages without a message and the message identifier of the next synchronization message received by each receiving synchronization device will increase in number so that the number will increase. Contains the message identifier (MsgID, line 7). In addition to the above-mentioned elements of the SyncML header described as specific examples, optional elements and required elements are also included in the SyncML header.

  The SyncML body section contains several independent logical subsections. The first status information subsection extends from the 11th line to the 19th line. This first status information subsection is associated with the reference address to which the data record to be synchronized is addressed. In particular, the target reference (TargetRef, line 16) specifies the international mobile device identifier (IMEI) addressed by the client (mobile communication device here), while the source reference (SourceRef, line 17). ) Defines a uniform resource identifier (URI) addressed by a server (here, a networked server device accessible via HTTP (Hypertext Transfer Protocol)). Further access to individual data records and data storage devices is based on this reference address information. Further, any number of other status information subsections may be included. This is indicated by a second status information subsection that spans lines 20-22. For example, authentication is encoded as status information.

  The SyncML body section further includes a synchronization subsection. This synchronization subsection is further divided. An example includes a change indicated by the client regarding the addition of a contact. Line 26 contains the relative address path of the client contact database, while line 29 contains the relative address path of the server contact database. The relative address path relates to the address to the reference destination. The meta subsection, which extends from line 31 to line 36, contains additional meta information regarding data records (contacts) added to the contact database in the server. The subsections extending from line 37 to line 51 contain additional instructions and the contents of the corresponding contact data. In line 40, the data format regarding the contents of the data in lines 46 to 48 is defined as the x-vcard metatype, and the corresponding data contents are included in lines 46 to 48. Yes. The local unique identifier (LUID) used to uniquely refer to this contact within the client is contained in line 44. Furthermore, an arbitrary number of other synchronization information subsections may be included. This is indicated by another synchronization information subsection ranging from line 52 to line 54.

  The Final instruction contained in line 56 informs the server that this example client synchronization message is the last message containing client changes to be reported to the server for synchronization.

  The above method according to an embodiment of the present invention for resuming a past incomplete synchronization session can be implemented in various ways in a client device and a server device. The specific example shown below is based on the SyncML standard, where each element has enhanced functions and capabilities to operate in accordance with one embodiment of the present invention.

  FIG. 5 is a schematic block diagram according to one embodiment of the present invention relating to elements included in a server device to be synchronized with a client device to be synchronized. FIG. 5 shows a server 110 representing a network device that provides a networked synchronization service. A networked 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 cause the client 100, which is a networked device, to perform data synchronization with other applications represented by the one or more client applications 102. One or more data storage elements 111 (eg, one or several databases) store data records that are handled by one or more server applications 112 and synchronized with the client. The server 110 and the client 100 are connected through a communication network transport. The selection of a communication network suitable for connecting the client 100 and the server 110 has already been illustrated and described with reference to FIG.

  One or more server applications 112 utilize a data synchronization protocol embodied as a synchronization server engine 113, which is an element or process on the server 110. The data synchronization protocol is presented to the communication network by client applications that access the provided synchronization server network services and resources. The sync server agent 115 provides an interface for the sync server engine 113 to access and communicate with the network, and at the same time manages its access and communication and synchronizes data with the client 100 and one or more client applications 102 Enable operation. The synchronization agent 115 performs interface functions and communications by involving the synchronization interface 116 (eg, an application program interface (API) for the synchronization adapter 117) and the synchronization adapter 117. The synchronization adapter 117 is an element or process on the server 110 and theoretically communicates with the synchronization adapter 107 that is a client side partner. In short, the synchronization adapter 117 includes one or more server applications 112 that provide a data synchronization service between the server 110 and the client 100, and one or more client applications 102 that access and use the data synchronization service. It plays an important role in establishing and maintaining network communication connections between them.

  On the client side, one or more client applications 102 include one or more data storage elements 101 that store data records that can be accessed by the one or more client applications 102, and are synchronized client agents. 105, the synchronization interface 106, and the synchronization adapter 107 are used to access the provided server synchronization service. The sync client agent 105 enables communication to perform data synchronization operations with the server 110 and one or more server applications 112. The synchronization interface 106 is, for example, an application program interface (API) for the synchronization adapter 107 as in the above case.

  The above method according to one embodiment of the present invention falls within the conceptual element framework shown above with respect to server 110 and client 100. To that end, for example, one or several code sections containing instructions for performing an embodiment of a method for resuming an incomplete synchronization session are implemented in the synchronization client agent 105 and the synchronization server agent 115. To do. According to this embodiment, when a synchronization session is interrupted, information necessary for resuming the interrupted synchronization session is recorded or stored in the client 100 and the server 110.

  FIGS. 6-8 illustrate another embodiment of the method of the present invention for resuming a past incomplete synchronization session in which data exchange between two devices has been interrupted. This method is characterized in that a restart warning signal including information relating to a request for restarting a previous incomplete synchronization session is sent from the first device to the second device. As specifically shown, the first device is a client and the second device is a server. This method is also characterized in that information on the type of synchronization to be performed is sent from the second device to the first device as the state of the warning signal. Information regarding the state of the resume warning signal may include information for accepting a resume session or information that invalidates a past incomplete synchronization session type. If the past sync type is disabled, the server sends a command to the client that uses another sync type. The “next” anchor or second update identifier may or may not be updated if synchronization is interrupted. If the “next” anchor is updated after an interruption or during a pause, it will likely be possible to synchronize the changed data item during the interruption, thus making it more user friendly.

  In FIG. 6, in step 302, the client sends a restart warning signal to the server. In step 304, the server responds to the warning signal condition and returns an indication to the client indicating that the session can be resumed. In step 306, the client uses the type of past sync session that was interrupted (eg, fast sync or slow sync) to exchange the remaining client data. The synchronization session is terminated by steps 308 and 310 similar to steps 253 and 254 described above with respect to FIG. 3b. These steps include both resuming the sync session and determining the sync type of the interrupted past sync session. When the client sends a resume warning code, the server acknowledges resumption of the session and sends the appropriate warning code contained in the warning element for the corresponding data store on the server side. The client must use this warning code to resume the synchronization session. In this way, it is not necessary to memorize the type of synchronization on the client side when the session is interrupted.

  In addition, the scope of the present invention includes embodiments in which the client can send a restart alert whenever an interruption occurs. This is applicable even if the client has received the status of all items and there are no more new or changed items to send during the resume session. In other words, if the transport was not interrupted elegantly or properly, the client needs to request a resume rather than start a new synchronization session. By doing so, the server can only send items that did not get status.

  FIG. 7 shows the cancellation of the resume session by the server. In this case, since the client resume request in step 302 is not accepted by the server, the server may, for example, state 508 (refresh synchronization) or state 509 (another synchronization type) in step 320, or any other suitable for the same purpose. Can then invalidate past sync types by sending the appropriate sync type in the form of a warning code 201 (slow sync) or 2XX (for another sync type). In step 322, the client uses the synchronization type specified by the server and sends all items, not just the five remaining data items. The scope of the present invention is not limited to the case where the number of status codes is a specific value. Embodiments in which the status code is another value are also conceivable.

  FIG. 8 shows the resumption of a slow synchronization session. If the client resume request is sent to the server as a warning and the resume is accepted by the server, a “warning for resume” state 200 (OK) is sent in step 330. The server also sends a warning 201 contained in a warning element for the corresponding data store on the server side. This is similar to that described for determining the synchronization type in FIG. But warning 201 here means slow sync, and the client will initiate a full slow sync, so how to distinguish between a slow sync resume and a forced full slow resume restart. It is important to pay attention to what you do. The client can distinguish between slow sync restart and full slow sync restart by looking at the status code sent in response to the "warning for restart" at step 330. Code 200 means slow sync resumption (another way is to send a status code of all the different sync types, for example, instead of 200 authenticating that the resume session is OK) 508 means slow synchronization of the full version. A full version of slow synchronization can be achieved by sending a status (requested refresh) 508 in response to the warning 201 above after a warning to resume. In this way, it can be seen that the client cannot resume the previously interrupted slow sync and must start from the beginning using the full version of the slow sync. This does not imply the start of a new synchronization session, but may do so if necessary.

  According to another embodiment, it is possible to provide an additional warning code indicating "warning warning". This provides a way to gracefully interrupt the synchronization session. Resume follows the steps described in the first part of this specification. This warning code is only useful for providing an elegant means of interrupting a synchronization session that is usually initiated by the user. When such a warning is received by the second device, it can respond to the warning with a status code. The first device can then infer whether it can also go into “sleep mode”. Of course, the “last” update identifier is not updated. Either the first device or the second device can later send an instruction to the other device to resume the dormant synchronization session. For example, the first device can send a message containing a resume warning signal to the second device, which allows both devices to resume the paused synchronization.

  It will be apparent to those skilled in the art that as the technology advances, the idea of the present invention can be implemented in many other ways. Therefore, the present invention and its embodiments are not limited to the above examples, but can be modified within the scope of the claims.

It is the schematic of the specific electronic device group which can synchronize information mutually. FIG. 4 is a time sequence diagram of a synchronization process according to an embodiment of the present invention, showing several messages exchanged between a client device to be synchronized and a server device to be synchronized. FIG. 3 is a time sequence diagram of a synchronization process according to an embodiment of the invention similar to FIG. FIG. 3b is a time sequence diagram of the synchronization process according to one embodiment of the present invention for resuming the interrupted or stopped synchronization process of FIG. 3a. 4 is an excerpt of an XML encoded synchronization message in the synchronization process according to one embodiment of the present invention shown in FIG. FIG. 3 is a schematic block diagram of elements included in a server device to be synchronized with a client device to be synchronized according to an embodiment of the present invention. FIG. 3b is a time sequence diagram of the synchronization process according to one embodiment of the present invention for resuming the interrupted or stopped synchronization process of FIG. 3a. FIG. 3b is a time sequence diagram of the synchronization process according to one embodiment of the present invention for resuming the interrupted or stopped synchronization process of FIG. 3a. FIG. 3b is a time sequence diagram of the synchronization process according to one embodiment of the present invention for resuming the interrupted or stopped synchronization process of FIG. 3a.

Claims (22)

A method for synchronizing data between a first device and a second device, comprising:
Causing the first device and the second device to resume a past incomplete synchronization session that was interrupted with respect to data exchange between the first device and the second device;
Sending the first device to the second device a resume notification signal that includes information about a request to resume a previous incomplete synchronization session;
The second device sending information about the type of synchronization to be performed to the first device as the state of the notification signal so that the type of synchronization performed by the first device can be determined;
Including methods.   The method of claim 1, wherein the state of the notification signal includes information for accepting a resume session.   The method of claim 1, wherein the information regarding the state of the notification signal includes information that invalidates a synchronization type of a past incomplete synchronization session.   The method of claim 1, wherein the information related to the resume request includes information recorded about an interruption of an incomplete synchronization session in the past that enables the incomplete synchronization session in the past to be resumed.   5. The method of claim 4, further comprising causing each device to record information recorded regarding past incomplete synchronization session interruptions.   A first update that includes information about a past complete synchronization session performed between the first device and the second device in information recorded about the interruption of the previous incomplete synchronization session; The method of claim 4, comprising: an identifier; and a second update identifier that includes information about a previous incomplete synchronization session performed between the first device and the second device. .   The step of comparing the update identifier information recorded in one device with the update identifier information recorded in the other device and resuming a past incomplete synchronization session based on the comparison result is further included. The method according to claim 4.   8. The method of claim 7, further comprising utilizing a separate synchronization method to resume a previous incomplete synchronization session in response to the comparison result.   The method of claim 6, wherein the first update identifier is a final anchor and the second update identifier is a next anchor or a dormant anchor.   The separate synchronization method resumes incremental synchronization when the last anchor information received and recorded for previous incomplete sync session interruptions matches and the next anchor information received and recorded also matches. The method according to claim 8, wherein the method is an operation.   When the last anchor information received and recorded for a previous incomplete synchronization session interruption matches, but the next anchor information received and recorded does not match, the separate synchronization method starts incremental synchronization. The method according to claim 8, wherein the operation is started from.   The separate synchronization method resumes full synchronization when the last anchor information received and recorded for a previous incomplete synchronization session break does not match, but the next anchor information received and recorded matches. The method according to claim 8, wherein the operation is performed.   When the last anchor information received and recorded for a previous incomplete synchronization session break does not match, and the next anchor information received and recorded does not match, the separate synchronization method starts with full synchronization. The method according to claim 8, wherein the operation is started from.   8. The recorded information also includes a session ID of a previous incomplete synchronization session, a message ID of the last message properly transmitted, and one or more unique record identifiers. the method of.   8. The method of claim 7, comprising sending a command from the second device to the first device to resume a previous incomplete synchronization session based on the recorded information. A first device;
A system comprising a second device,
The first device transmits a restart notification signal including information on a request for resuming a previous incomplete synchronization session suspended with respect to data exchange between the first device and the second device. One or more modules configured to be sent to
The second device is configured to send information on the type of synchronization to be executed to the first device as the state of the notification signal so that the type of synchronization to be executed by the first device can be determined. System comprising one or more modules. A method for synchronizing data between a first device and a second device, comprising:
With respect to data exchange between the first device and the second device, the first device sends a resume notification signal including information on a resume request for a suspended incomplete synchronization session. Sending to other devices,
Receiving information on the type of synchronization to be performed from the second device at the first device as the state of the notification signal so that the type of synchronization to be performed by the first device can be determined;
Having a method. A first device comprising:
Constructed to send a resume notification signal to the second device, including information regarding a resume request for a suspended previous incomplete synchronization session for data exchange between the first device and the second device One or more modules,
One or more modules configured to receive information about the type of synchronization to be executed from the second device as the state of the notification signal so that the type of synchronization to be executed by the first device can be determined When,
A device comprising: A method for synchronizing data between a first device and a second device, comprising:
With respect to data exchange between the first device and the second device, a restart notification signal including information related to a request for restarting a past incomplete synchronization session that has been interrupted is transmitted to the first device. Receiving from the device;
The second device sending information about the type of synchronization to be performed to the first device as the state of the notification signal so that the type of synchronization performed by the first device can be determined;
Having a method. A computer program including a program code section group for executing the steps of the method according to claim 19 , wherein the computer program is executed by any one of a processing device, a terminal device, a communication terminal device, and a network device. program. A computer-readable storage medium containing the computer program according to claim 20 . A second device comprising:
As for data exchange between the first device and the second device, a resumption notification signal including information relating to a resumption request of a suspended past incomplete synchronization session is received from the first device. One or more configured modules;
One or more modules configured to send information about the type of synchronization to be performed to the first device as the state of the notification signal so that the type of synchronization to be performed by the first device can be determined; ,
A device comprising:

Images