European Case Law Identifier: | ECLI:EP:BA:2010:T120308.20101028 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Date of decision: | 28 October 2010 | ||||||||
Case number: | T 1203/08 | ||||||||
Application number: | 01300674.7 | ||||||||
IPC class: | G06F 9/46 G06F 17/60 G06F 17/30 |
||||||||
Language of proceedings: | EN | ||||||||
Distribution: | D | ||||||||
Download and more information: |
|
||||||||
Title of application: | Data transfer and synchronization system | ||||||||
Applicant name: | fusionOne, Inc. | ||||||||
Opponent name: | - | ||||||||
Board: | 3.5.01 | ||||||||
Headnote: | - | ||||||||
Relevant legal provisions: |
|
||||||||
Keywords: | Inventive step - use of universal format to enable synchroniser to work with data from different applications (No - routine design) | ||||||||
Catchwords: |
- |
||||||||
Cited decisions: |
|
||||||||
Citing decisions: |
|
Summary of Facts and Submissions
I. This appeal is part of a series of appeals (also including T 1262/08, T 1263/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. 01300674.7 according to the state of the file. In the communication forming the basis of the decision, the division considered inter alia that 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 that specified that the first data synchroniser transmitted "at least one data field type" in addition to the difference data. 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 tended to agree with the examining division that the previously claimed subject-matter lacked an inventive step and that the new feature lacked support and could 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 substantially amended main request.
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 request as submitted during the oral proceedings before the Board, this request being the sole request. At the end of the oral proceedings, the Chairman announced the decision.
X. Claim 1 of the sole request reads as follows:
"1. A data synchronization system for a first system having a plurality of data sources each with a data source format, and a second system having a plurality of data sources each with a data source format; comprising:
a first data synchronizer on the first system being configured
to map data from a data source format of first data source on the first system to a universal data format,
to determine, using the mapped data, difference information resulting from changes to the first data source on the first system, and
to transmit the determined difference information to an output;
a second data synchronizer on the second system being configured
to receive said difference information,
to apply the received difference information to generate change data for a second data source on the second system,
to map the generated change data from the universal format to a data source format of the second data source on the second system; and
to update the second data source on the second system with the mapped change data; and
a network for coupling the first system and the second system to allow communication between the first system and the second system when the first and second systems are physically remote from each other.
XI. The appellant argued essentially as follows:
The invention differed fundamentally from D5 in that an application interface at the client converted the data into a universal format before determining the difference information. 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 appeal complies with the requirements referred to in Rule 99(2) EPC and is therefore admissible.
The application
2. 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.
3. 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 using a data synchroniser, such as the generic one shown in Figure 9A in a first system that extracts the application data into an "application object" (AO) 910 and uses 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 52 to 53). The differences are output via a network to a similar data synchroniser in the second system, which receives the difference data and converts it to that system's application data format. Transmitting only data that has changed has the effect of reducing the required bandwidth and thus increasing the speed of the synchronisation (paragraph 35).
4. 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
5. At the oral proceedings the new representative explained that claim 1 of the substantially amended request was designed to define the essential differences over D5. In particular, to emphasise the fact that in the invention the data synchroniser in the first system immediately maps the application data into a generic or "universal" format (paragraph 51). The data synchroniser in the second system converts the data into the format of the corresponding applications.
6. Although the amended 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).
Inventive step
7. It is common ground that the synchroniser of claim 1 differs from that of D5 essentially by the above-mentioned immediate conversion into the "universal" format.
8. The application explains at paragraph 51 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.
9. 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 56 cases, e.g. for PDAs, where the AOS is not required.
10. 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.
11. 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.
12. 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.
13. In the Board's view, the examining division was correct to assert in the related case T 1263/08, where this feature was relevant, 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 87. 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.
14. 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.
15. In the Board's view, all the features of the first and second data synchronisers of claim 1 follow immediately from this inevitable use of a common data structure in the synchroniser program. The difference engine would calculate differences using data in this format and the second data synchroniser would perform the inverse operation.
16. 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.
17. 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.
18. 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.