T 2413/10 (Database synchronization/NOKIA TECHNOLOGIES) 23-05-2016

1. The appeal complies with the provisions referred to in Rule 101 EPC and is therefore admissible.

2. The invention

2.1 The invention relates to synchronisation of databases storing application data on two devices, for example a portable client terminal and a network server, based on the SyncML ("Synchronized Markup Language") synchronisation protocol.

2.2 Paragraph [0005] of the background section of the published application explains that, in a synchronisation session in accordance with the SyncML protocol, a SyncML client terminal transmits to a SyncML server a message that includes the data that has changed since the last synchronisation. The server analyses the data, makes necessary changes, and transmits a message containing server modifications to the client.

2.3 As explained in paragraphs [0006] and [0007], the SyncML protocol includes a mechanism for verifying, during initialisation of a synchronisation session, whether the previous synchronisation session completed successfully. If it did not complete successfully, the synchronisation process must check all the data in the two databases and not just those fields that have changed since the last session. This is referred to as "slow synchronization".

2.4 This verification mechanism employs "synchronization anchors", which are strings describing synchronisation events in terms of, for example, the date and time. The "Last" anchor represents the last successful synchronisation event and the "Next" anchor represents the present synchronisation event. During initialisation, the client device transmits both its "Last" anchor and its "Next" anchor to the other device. If the client determines that, from its point of view, the present synchronisation completed successfully, it updates its "Last" anchor to the value of the "Next" anchor. Similarly, if the server determines that, from its point of view, synchronisation completed successfully, it stores the received "Next" anchor as the new "Last" anchor. During a subsequent synchronisation, the server verifies whether the previous synchronisation completed successfully from both the client's and the server's point of view by determining whether the stored "Last" anchor matches the received "Last" anchor.

2.5 Paragraph [0008] of the background section explains that the SyncML standard (more precisely version 1.0 of the standard as current at the priority date of the application; see paragraph [0006]) does not accurately define the moment at which the "Last" anchor is to be updated by client and server devices. A device implemented in accordance with the standard may update the "Last" anchor once all SyncML messages required by the SyncML protocol have been exchanged, but it may also first require the underlying network transport connection to have terminated without errors.

In the example depicted in Figure 2, the server updates its "Last" anchor once all SyncML messages have been interchanged, whereas the client waits until the underlying network transport connection terminates without errors. Since in this scenario the network transport connection does not terminate without errors, the client does not update its "Last" anchor. The "Last" anchor received from the client therefore does not match the server's "Last" anchor at the start of the second synchronisation session, resulting in "slow synchronization". Had the server not "unnecessarily" updated its "Last" anchor, but had it, like the client, waited for error-free termination of the network transport connection, neither of the "Last" anchors would have been updated and the second synchronisation session would not have resulted in "slow synchronization" (see the scenario depicted in Figure 6).

2.6 The invention therefore proposes updating, in both the client and the server, the "Last" anchor "if synchronization has been performed and after this the transport layer connection established for synchronization has been ended substantially properly", i.e. once all SyncML messages required by the SyncML protocol have been exchanged and the underlying network transport connection has been terminated without errors. See paragraph [0010].

3. Clarity and added subject-matter

Independent claim 1 of the sole main request corresponds essentially to a combination of claims 1 and 2 as originally filed with the following clarifications based on the original description:

- the two devices perform synchronisation in accordance with the SyncML protocol (paragraphs [0015] and [0021]);

- the update identifiers exchanged are "Last" and "Next" anchors (paragraphs [0018] and [0019]);

- the condition for the transport or logical data transmission connection to have "ended substantially properly" is specified as "in a manner after which no transport layer messages are waited for" (paragraph [0023]);

- if the condition for updating the "Last" anchor has not been fulfilled, the "Next" anchor is not updated (paragraph [0029]).

Dependent claims 2 to 5 are based on originally filed dependent claims 3 to 6. Independent claims 6 to 10 correspond to independent claim 1.

The Board is therefore satisfied that the claims comply with Articles 84 and 123(2) EPC.

4. Inventive step

4.1 Document D1, describing version 1.0 of the SyncML synchronisation protocol, is referred to in paragraph [0006] of the background section of the application and evidently served as the starting point for the invention. The Board agrees with the Examining Division that it represents the closest prior art, and the appellant has not contested this.

4.2 In sections 1.1, 1.2 and 2.2.1, document D1 discloses the "SyncML Framework" for synchronising databases storing application data of a client device and a server device. The framework employs the SyncML synchronisation protocol on top of a network transport connection such as HTTP, WSP or OBEX (see Figure 1).

4.3 A number of synchronisation types are listed in section 1.3 and discussed in sections 5, 5.5, 6, 6.3, 7, 7.5 and 8. During initialisation of a synchronisation session, the client specifies the desired synchronisation type (see section 4.1, first paragraph). Section 5.5 discusses the "slow sync" synchronisation type, which is a form of two-way synchronisation in which all items in one or more databases are compared with each other on a field-by-field basis. Slow sync is initiated when two devices synchronise with each other for the first time or when either the client or the server indicates a need for it.

4.4 Section 2.2.1 explains that the protocol employs "Last" and "Next" synchronisation anchors, which are sent during initialisation of a synchronisation session. The "Last" anchor describes the last synchronisation event, and the "Next" anchor describes the current synchronisation event from the point of view of the sending device.

4.5 In the example discussed in Section 2.2.1.1 and shown in Figure 3, the sending device is the SyncML client, which transmits a "Last" anchor and a "Next" anchor to the SyncML server. At the start of the first synchronisation session, the server stores a "client sync event" anchor, which matches the value of the "Last" anchor received from the client. Because they match, slow sync is not initiated. After completion of the first session, the server updates its "client sync event" anchor to the contents of the "Next" anchor received from the client.

In this example, the persistent storage of the client is reset between the end of the first synchronisation session and the beginning of the second synchronisation session. The "Last" anchor transmitted by the client to the server at the start of the second synchronisation session (now set to "Empty") consequently does not match the "client sync event anchor" stored in the server (now set to the contents of the "Next" anchor received during the first synchronisation session). As a result, the server initiates slow sync.

4.6 The "client sync event anchor" stored on the server is hence the "Last anchor stored in the second device" of claim 1. Once the synchronisation session is finished (i.e. "synchronization has been performed"), the client and server update their respective "Last" anchors to the contents of the "Next" anchor transmitted from the client to the server during initialisation of the session. That "Next" anchor is hence stored for the duration of the session (and thus "temporarily") at both devices.

Since the "Last" anchor serves to identify the last (successful) synchronisation, the skilled person understands that it is not updated to the contents of the "Next" anchor if the synchronisation session is not completed successfully.

4.7 Document D1 does not specify in detail how the client and server are to determine whether the synchronisation session has been successfully completed. Since the client can only "see" its side of the synchronisation session, the determination of "successful completion" must be made on the basis of the messages it has sent and received (in addition to any internal error conditions), and the same applies to the server. The reader of document D1 understands that, at the least, a synchronisation session is not considered to have been completed until a device has received all SyncML messages as defined by the SyncML protocol.

4.8 Claim 1 defines for both devices participating in a synchronisation session the condition for updating the "Last" anchors for both devices participating in a synchronisation session as "if synchronization has been performed and after this said logical data transmission connection has been ended properly in a manner after which no transport layer messages are waited for". This feature is the only distinguishing feature and indicates more precisely that, from the point of view of a device participating in a synchronisation session, the session is considered to have been successfully completed when not only all expected SyncML messages have been received, but also all transport layer messages.

4.9 The Board notes that, from a technical point of view, a device participating in a SyncML synchronisation session could instead consider the session to have been successfully completed once it has sent the last SyncML message it is supposed to send and has received the last SyncML message it is supposed to receive even if the underlying transport layer connection has not yet been terminated (and possibly will only terminate with a timeout error).

This approach is in fact advantageous if the network connection happens to break down after all SyncML messages have been sent and received but before the last transport layer message has been received: both participating devices will update their "Last" anchors and the next synchronisation session will not trigger a slow sync. On the other hand, if the network connection happens to break down after the last SyncML message has been sent but before it has been received, one device will update its "Last" anchor and the other will not, resulting in an unnecessary slow sync during the next session. In this case, waiting for the transport layer connection to close before updating the "Last" anchor as proposed by claim 1 would reveal to the device sending the last SyncML message that the other device probably did not receive it, and neither device would update its "Last" anchor.

4.10 In other words, multiple implementations for detecting "successful completion" of the synchronisation session are possible, and the claimed one is not necessarily better or worse than others in the sense of being inherently more likely to prevent an unnecessary slow sync.

In the Board's view, the objective technical problem solved by the invention over document D1 is therefore merely that of providing an implementation for detecting "successful completion" of the synchronisation session.

4.11 Faced with this problem, the skilled person would consider any suitable implementation suggested by the prior art or his common general knowledge, and any such implementation would in principle have to be regarded as obvious; in the absence of a specific technical advantage, a particular reason for selecting the claimed implementation would not be necessary (see Case Law of the Boards of Appeal, 7th edition 2013, I.D.9.18.7).

However, in the present case no prior art is available suggesting the claimed approach, and the Board is not convinced that the skilled person, starting from document D1, on the basis of his common general knowledge alone would consider transport-layer events when implementing the detection of the "successful completion" of a synchronisation session. Indeed, document D1 is primarily concerned with communication at the (SyncML) session layer.

4.12 The Board therefore considers that the subject-matter of independent claim 1 and of corresponding independent claims 6 to 10 involves an inventive step. By virtue of their dependency on claim 1, the same applies to the subject-matter of claims 2 to 5. The sole main request hence meets the requirements of Articles 52(1) and 56 EPC.

5. Since the sole main request complies with the provisions of the EPC, the appeal is to be allowed.