T 1745/20 (Extensible sync framework/MICROSOFT) 17-03-2022
Download und weitere Informationen:
Sync framework extensibility
Novelty - main request (yes)
Inventive step - main request
Inventive step - not rendered obvious by D3
Remittal - (yes)
Summary of Facts and Submissions
I. The appellant (applicant) filed an appeal against the decision of the examining division refusing European patent application No. 13771334.3, which was published as international application WO 2014/193458.
II. The examining division decided that the subject-matter of claims 1 to 4 and 7 to 9 of the main request lacked novelty and the subject-matter of claims 5, 6, 10 and 11 of the main request and of claim 1 of the auxiliary request lacked inventive step over the following document:
D3:|US 2004/0122897 A1, 24 June 2004.|
III. In its notice of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the claims of the main request or, in the alternative, of the auxiliary request.
The appellant further requested that oral proceedings be held in case the board did not decide in the written procedure that a patent could be granted on the basis of the main request.
IV. In a communication issued under Rule 100(2) EPC, the board informed the appellant of its intention to remit the case to the examining division for further prosecution. In response, the appellant agreed to remittal without oral proceedings before the board being held first.
V. Independent claim 1 of the main request reads as follows:
"A method of providing application integration for a sync framework executing on a computing device storing a first instance of a file, the computing device in communication via a network with a cloud, the cloud storing a second instance of the file, the method comprising:
responsive to updates to the first instance and the second instance of the file, maintaining synchronization (160), by the sync framework, between the first instance of the file and the second instance of the file,
the sync framework comprising an interface or API (application programming interface) to allow arbitrary applications executing on the computing device to communicate with the sync framework,
receiving (164) a sync-lock request via the interface or API from a first application executing on the computing device, the sync-lock request being associated with the file, and
responsive to the sync-lock request, providing (166) a sync-lock comprising temporarily relinquishing synchronization between the first and second instance of the file by the sync framework."
Claims 2 to 6 of the main request are, directly or indirectly, dependent on claim 1.
Independent claim 7 reads as follows:
"One or more computer-readable media storing instructions thereon that, when executed on a computing device, configure the computing device to perform a method according to one of the preceding claims."
Independent claim 8 reads as follows:
"A computing device comprising:
a storage device storing a sync engine (114), a plurality of applications, and an operating system (112), the operating system (112) comprising a file system (110) storing a plurality of files;
a processor to execute the sync engine (114), the operating system (112), and the file system (110);
the sync engine (114), when executing, automatically synchronizing the plurality of files with corresponding cloud versions of the plurality of files such that changes to the cloud versions synchronize to the plurality of files and changes to the plurality of files synchronize to the cloud versions; and
the sync engine (114), when executing, receiving requests from an application (118) to sync-lock a first file (104) of the plurality of files, and responding by stopping the synchronizing for the first file (104) for each of the requests, and resuming synchronizing for the file (104) when the application (118) initiates corresponding releases of the sync-locks."
Claims 9 to 11 are, directly or indirectly, dependent on claim 8.
VI. The text of the claims of the auxiliary request is not relevant to the outcome of this decision.
Reasons for the Decision
1. The application relates to an extensible framework for file synchronisation ("sync framework").
Main request
2. The invention as defined by claims 1, 7 and 8
2.1 Claim 1 is directed to a method of providing application integration for a sync framework.
The claim suggests that the sync framework is "executing on a computing device", but it is clear from Figure 1 and paragraph [020] of the published application that the framework is implemented in a distributed fashion by a number of "sync engines".
2.2 In normal operation, the sync framework maintains synchronisation between a first instance of a file stored in the computing device and a second instance of the file stored in the cloud in response to updates to the first and second instances.
2.3 When the sync framework receives, via an API of the framework, a "sync-lock request" associated with the file from an application executing on the computing device, it provides a "sync-lock" and temporarily relinquishes synchronisation between the two instances of the file.
2.4 Independent claim 7 is directed to one or more computer-readable media which are defined by reference to the preceding method claims.
2.5 Independent claim 8 defines a computing device which executes a sync engine that responds to "requests from an application to sync-lock a first file" by temporarily stopping the synchronisation for the first file until the application "initiates corresponding releases of the sync-locks".
3. Novelty and inventive step over document D3
3.1 Document D3 discloses a WebDAV repository 102 which is accessible via a network 120 by a plurality of client computing devices 106 and 108 (paragraphs [0040] and [0041]; Figure 1). The client computing devices are configured with integrated development environments (IDEs) 305 and repository adapter clients 306, which allow their users to collaborate on documents stored in the repository using a graphical user interface (GUI) (paragraphs [0042], [0056] and [0071]; Figures 2 and 3). A subset of these documents is stored in each client (paragraph [0072]). In response to change requests received from clients, both the documents stored in the repository and the documents stored in each client are updated (paragraphs [0073] to [0077]).
3.2 According to the contested decision, document D3 discloses temporarily relinquishing synchronisation in response to the receipt of a sync-lock request in paragraphs [0074] and [0078].
However, although these paragraphs do mention locks, there is no disclosure of the repository and the adapter clients relinquishing synchronisation between the various instances of a document. On the contrary, paragraphs [0074] and [0078] are part of the description of how synchronisation is achieved.
3.3 From points 1.7 and 1.8 of the reasons for the decision, it appears that the examining division considered that document D3 disclosed "temporarily relinquishing synchronisation" because it disclosed allowing two instances of a file to be edited locally and to be merged with the version in the repository later. However, if this were a correct reading of "relinquishing synchronisation", then the system described in document D3 would not "maintain synchronisation" to begin with.
3.4 In the board's view, the skilled reader of claims 1 and 8 understands that a successful sync lock request results in the sync framework temporarily excluding the file from its normal synchronisation activities.
In document D3, such "relinquishing" of synchronisation on request of a software application would make little sense. The only software application mentioned in document D3 is the IDE 305, and the synchronisation framework disclosed in document D3 is specifically designed to support the IDE application. The board therefore agrees with the appellant that relinquishing synchronisation would go against the spirit of the disclosure of document D3.
3.5 Hence, document D3 neither anticipates the subject-matter of the independent claims 1, 7 and 8 nor renders it obvious.
4. Remittal for further prosecution
4.1 In view of the above, the reasons for refusing the main request are incorrect.
4.2 According to the background section of the application, at the priority date cloud storage services existed which were closely integrated with the file systems of client computers and which allowed multiple instances of a file to exist in the cloud and on client computing devices. Such services employed a file synchronisation system to maintain synchronisation between the multiple instances of the file (see paragraph [001] of the published application).
The board notes that, starting from such prior art, there may well be reasons for an application running on a client computing system to desire particular files to be temporarily excluded from synchronisation by the file synchronisation system. Hence, such acknowledged prior-art cloud storage services appear to represent a more promising starting point for assessing inventive step of the present invention than document D3.
There is no indication in the file that the examining division has considered such prior art as a starting point for assessing inventive step. Moreover, no such documents appear to have been cited in the international search report.
4.3 Since the primary object of the appeal proceedings is to review the decision under appeal in a judicial manner (Article 12(2) RPBA 2020), in these circumstances special reasons within the meaning of Article 11 RPBA present themselves for remitting the case to the examining division for further prosecution on the basis of the main request (see decisions T 1966/16, Reasons 2.2; and T 731/17, Reasons 7.2 and 7.3).
Order
For these reasons it is decided that:
1. The decision under appeal is set aside.
2. The case is remitted to the examining division for further prosecution.