T 1263/08 (Synchronising databases I/FUSION ONE INC) of 28.10.2010

Summary of Facts and Submissions

I. This appeal is part of a series of appeals (also including T 1203/08, T 1262/08 and T 1266/08) from related applications that tackle the problems of synchronising information for a user having a PC and various portable devices, such as a laptop computer and a personal digital assistant (PDA), or mobile phone.

II. The present appeal is against the decision of the examining division to refuse the European patent application No. 01300681.2 according to the state of the file. In the communication forming the basis of the decision, the division considered that the feature of the "application interface" was an extension of subject-matter (Article 123(2) EPC) and that claim 1 lacked essential features (Article 84 EPC 1973). Notwithstanding these objections, it was considered that the synchronising device of claim 1 lacked an inventive step (Article 56 EPC 1973) over US-A-5 926 816 (D5), which the division introduced into the proceedings in the above-mentioned communication, and the skilled person's common general knowledge.

III. In the statement setting out the grounds of appeal, the appellant filed an amended claim 1 with a new feature relating to a "field mapping module". Concerning the "application interface", the appellant stated that this would be "clear to a person skilled in the art from reading the disclosure". The appellant also made an auxiliary request for oral proceedings.

IV. In the summons, dated 28 June 2010, the Board scheduled oral proceedings for all four related appeals on the 27 and 28 October 2010 with a reserve day on the subsequent day. In the communication, the Board summarised the issues to be discussed and, despite the terse reasoning in the grounds of appeal, tended to consider that the feature of the "application interface" was in fact adequately disclosed in the original application. The Board, however, tended to agree with the examining division that the previously claimed subject-matter lacked an inventive step and that the new feature did not add anything inventive.

V. In a letter, dated 23 September 2010, the representative informed the Board of the appointment of a new representative.

VI. In a letter, dated the same day, the new representative informed the Board that he was in the process of obtaining instructions from the appellant's US counsel and requested time to prepare written submissions in preparation for the oral proceedings. In a further letter, dated 27 September 2010, the representative requested a postponement of the oral proceedings in order to allow sufficient time to prepare and have written submissions approved.

VII. The Board did not allow the postponement because the reason was not considered to be a serious substantive reason in the sense of the "Notice of the Vice-President of Directorate-General 3 of the European Patent Office dated 16 July 2007 concerning oral proceedings before the boards of appeal of the EPO" (SE No. 3 OJ EPO 2007, 115) that might justify a change of date. Moreover, the Board pointed out that the summons had already been issued on 28 June 2010 which seemed to have given the appellant enough time for preparation.

VIII. In a reply, dated 1 October 2010, the appellant filed a main request, corresponding to the refused request, a substantially amended first auxiliary request, and a second auxiliary request, corresponding to that filed with the grounds of appeal.

IX. At the oral proceedings, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of a further amended first auxiliary request as submitted during the oral proceedings before the Board, this request being the sole request. All other requests were withdrawn. At the end of the oral proceedings, the Chairman announced the decision.

X. Claim 1 of the sole request reads as follows:

"A processing device (802-808) connectable to a network and having at least one application (812-818), the application including application data in an application data format in an application data store (822-828), the processing device comprising a device engine (862-868), wherein the device engine comprises:

an application interface (910) operable to extract application data of the application and to convert the application data from the application data format to a universal data format;

an application object store (920) operable to hold a representation of a previous state of the application data in the universal data format; and

a difference engine (950) operable

to calculate differences in data between the output of the application interface and the copy of the application data in the application object store and

to generate a first data package comprising set of difference information for output via the network to an external storage server (850) for storage in the universal data format."

XI. The appellant argued essentially as follows:

The examining division had alleged, without any supporting documentation, that the skilled person would have found or been provided with an available application programming interface (API) on a data format specification of an application that needed to be synchronised and that it would have been a routine matter to either implement interfaces to applications using the API or to the stored data.

The invention differed fundamentally from D5 in that an application interface at the client converted the data into a universal format. The previous values of the data were also stored in this format in the application object store and the difference was generated and output in this format.

In D5, the comparison was made in the format in which it was stored, i.e. that of the tables shown in the figures. D5 stated at column 3, lines 31 to 34 that the current and previous versions were "identical copies" of the tables. There was no suggestion of a comparison in a different format, and this would have gone against the teaching of the document.

The invention enabled a modular and more flexible system for synchronising.

If a new device were to have been added to the system of D5, the skilled person would not have considered a universal format, but would have provided a new difference engine operating on the data in the format of the new device.

Reasons for the Decision

Admissibility of the appeal

1. The first of the examining division's objections in the communication on which the decision was based, was for added subject-matter (Article 123(2) EPC). The division considered at point 2.1 that there was no basis in the originally filed application for "an application interface, interpreting the application readable record format for the difference engine" in the last feature of claim 1. At point 2.3 the division then found an "application interface" on pages 5 and 6 of the originally filed application (paragraphs 15 and 18 of the published application) and raised the objection that the claim lacked essential features (Article 84 EPC 1973). Finally, at points 3.3 to 3.10 they found that the feature was, in fact, the only distinction over D5 and argued that it did not involve an inventive step (Article 56 EPC 1973). In appeal, the appellant gives a rather terse treatment of the first two objections in the grounds of appeal, merely alleging that such an interface would be "clear to a person skilled in the art from reading the disclosure".

2. As it stands, such a reasoning would normally not meet the criteria for admissibility, which require that the grounds of appeal contain a reasoned statement that enables the Board to understand why this aspect of the decision might be incorrect without first having to make extensive investigations of its own (see Case Law of the Boards of Appeal of the European Patent Office, 6th edition 2010, section VII.E.7.6.1). However, considering the above-mentioned subsequent discussion of this feature in the decision under appeal and the fact that the passages cited by the examining division itself explicitly disclose some kind of application interface that handles data to and from the difference engine, the Board was able to verify the appellant's claim relatively easily. The Board therefore judges that the appeal complies with the requirements referred to in Rule 99(2) EPC and is therefore admissible.

The application

3. The basic idea of synchronisation as shown in Figure 8 of the published application is that if the user changes application data (822-828) associated with various applications (812-818) in one of his devices (802-808), this change must be propagated to the corresponding application data in the other devices.

4. An important aspect of the invention as defined in the original and present claims is that when application data is to be synchronised, only the items that have changed are transmitted instead of the entire data. This is achieved as shown in Figure 9A by extracting the application data into an "application object" (AO) 910 and using a delta module 950 to calculate the difference between the current value of the AO and the value at the time of the last synchronisation as stored in the AO store (AOS) 920 (paragraphs 56 to 57). The differences are output to the storage server 850. Transmitting only data that has changed has the effect of reducing the required bandwidth and thus increasing the speed of the synchronisation (paragraph 39).

5. D5 discloses a general purpose system for synchronising databases. This operates essentially in the same way as the invention, namely by transmitting only modifications detected in the client data since the last synchronisation by comparing the data with a "before-image" (column 2, lines 12 to 22). Thus D5 discloses the main aspect of the invention, which is what led the examining division to refuse the application under Article 56 EPC 1973, correctly, in the Board's view.

Requests in appeal

6. At the oral proceedings the new representative explained that claim 1 of the substantially amended first auxiliary request was designed to define the essential differences over D5. In particular, to emphasise the fact that in the invention the "application object" (AO) 910 is specific to the user applications in each user device and immediately maps their data into a generic or "universal" format (paragraph 55). The data in the AOS and the differences are also stored in this format (paragraph 58).

7. Although these claims were filed late in the proceedings, the Board admits them because they are clearly a serious attempt to meet the outstanding objections without introducing any further objections and there was a good reason for the lateness, namely that the representative only took over the case at short notice and there was no postponement of oral proceedings (see above). After a lengthy discussion of all the requests, the representative made the first auxiliary request the sole request.

Inventive step

8. It is common ground that the synchroniser of claim 1 differs from that of D5 essentially by the above-mentioned immediate conversion and subsequent processing in the "universal" format.

9. The application explains at paragraph 55 that these features have the effect of enabling the synchroniser to work with data from different applications using the same basic structure for the difference engine, store and difference packaging, only requiring a specific application interface for each. The representative suggested that this solved the problem of providing a more flexible system.

10. In addition to the above-mentioned features, D5 acknowledges at column 9, lines 52 to 57 the problem of working with heterogeneous database products and states that this "requires a general purpose technique". D5 explains that the use of a "before-image" is such a general purpose technique because not all database products have logging capabilities, i.e. enable detection of differences. The present invention appears also to have been shaped by this consideration since the description contemplates at paragraph 60 cases, e.g. for PDAs, where the AOS is not required.

11. D5 also mentions at the end at column 27, lines 47 to 54 that its teaching is also applicable to object-oriented representations of data where a class has the properties equivalent to that of a table in a relational database. Although the appellant played down this aspect of the disclosure as not providing any direct suggestion to use a universal format, the Board considers that the skilled person would be led to this using common general knowledge and routine design skills.

12. This is because when the skilled person reads D5 as a whole, he would realise, if he did not know already, that the disclosed "before-image" technique of synchronising data between different data base systems could be implemented in an object-oriented language. Since the emphasis in object-oriented programming is on re-usability and modularity, he would have this at the back of his mind as well.

13. Thus in the Board's view the problem of providing a flexible synchroniser based on D5 would immediately translate into the practical problem of how to implement the technique of D5 in an object-oriented language.

14. In the Board's view, the examining division was correct to assert that it is conventional programming practice in complex systems that interact with proprietary products such as databases to write a common program that uses the product manufacturers' interfaces (APIs). These are the "traditional" APIs actually mentioned in the application at paragraph 91. Indeed without such interfaces it would scarcely be possible to access the applications' data at all without having recourse to each program's source code, which of course manufacturers are reluctant to release and would involve a lot of work. In short, the API's job is to transfer data to and from the database.

15. Thus in any practical implementation, the skilled person would have to access the data from the different applications using the respective APIs. It is the programmer's job to integrate the data provided by the APIs into the data structures of his own program; he is not bound to any particular data structure and indeed must design some structure to be able to use the data at all. For a single program designed to be used with different database products, it is self evident that there can only be one such structure and that this would be different from at least some of the product's own internal structures. Thus, in the Board's view as soon as the data has been extracted via the API and stored in the data structure of the synchronising program it is already in a "universal" format in the sense that this format must accommodate, or be extensible to accommodate, all of the data items that may be present in the systems to be synchronised.

16. In the Board's view, the remainder of the features of claim 1 follow immediately from this inevitable use of a common data structure in the synchroniser program. The methods that use the APIs to extract the data would form an "application interface". The object used to store the "before-image" would be an "application object store" storing data in the "universal" data format, i.e. the format defined by the program object's representation of the data. The difference engine would calculate differences between the output of the application interface and the copy in the application object store. These differences would still be in the "universal" format and would most obviously be sent to the server in this format.

17. The representative argued that in D5 the difference operation was taken at the level of the structure of the tables and so there was no need or suggestion to convert to a universal format first. However, in the Board's view, a dogged attempt to stick with the concept of tables does not take full account of the disclosure of D5 or the skilled person's common general knowledge as explained above. In particular, once the decision has been taken to represent the data (i.e. the tables) as objects, the argument must be translated to mean that the difference operation must be taken at the level of the objects. However, as pointed out above it is not practical to consider operating directly on the objects of each database application because these are not generally available to the programmer of a third party system; the APIs are used to access the data.

18. The representative also argued that even if the skilled person were to use APIs to access the applications' data, he would still provide a separate difference engine for each application appropriate to its structure and store the before-image data in the application itself in its own structure. The Board agrees that this is at least a technically meaningful alternative, but its existence does not imply that the other involves an inventive step. The choice of storing the before-image in the application program or in the synchroniser program is a design decision that would depend on the circumstances, such as memory availability. Moreover, in the Board's view, the principle of modularity would lead the skilled person to provide as many common modules as possible so that a single difference engine and store is the more realistic solution.

19. Accordingly, the Board judges that the subject-matter of claim 1 does not involve an inventive step (Article 56 EPC 1973), so that the appeal must be dismissed.

ORDER

For these reasons it is decided that:

The appeal is dismissed.