T 2453/16 (Synchronizing user revisions to a shared object/MICROSOFT LLC) of 31.1.2020

European Case Law Identifier: ECLI:EP:BA:2020:T245316.20200131
Date of decision: 31 January 2020
Case number: T 2453/16
Application number: 05112294.3
IPC class: G06F 17/30
G06Q 10/00
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 351 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: Method and system for synchronizing multiple user revisions to a shared object
Applicant name: Microsoft Technology Licensing, LLC
Opponent name: -
Board: 3.5.07
Headnote: -
Relevant legal provisions:
European Patent Convention Art 84
European Patent Convention Art 123(2)
RPBA2020 Art 011
RPBA2020 Art 012(2)
Keywords: Claims - clarity (yes)
Amendments - added subject-matter (no)
Remittal to the department of first instance
Catchwords:

-

Cited decisions:
T 1966/16
T 0731/17
Citing decisions:
T 2710/16

Summary of Facts and Submissions

I. The appeal lies from the decision of the Examining Division to refuse European patent application No. 05112294.3 for added subject-matter and lack of clarity of the independent claims of a main request and first, second, third and fourth auxiliary requests. The dependent claims of the main request were also considered to infringe Article 84 EPC.

II. In the statement of grounds of appeal, the appellant maintained the first to fourth auxiliary requests considered in the decision under appeal as main request and first to third auxiliary requests. It requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request or one of the first to third auxiliary requests.

III. In a communication accompanying the summons to oral proceedings, the Board expressed its preliminary opinion that the requests did not fulfil the requirements of Articles 84 and 123(2) EPC. The Board informed the appellant that it was inclined to remit the case to the department of first instance for further prosecution if the grounds for refusal of the decision under appeal were overcome.

IV. With a letter of reply, the appellant filed new claims according to a main request and first and second auxiliary requests. The appellant submitted that the patentability of the claims on file had been sufficiently assessed during the examination proceedings so that the cited prior art and the state of the file allowed the Board to continue with an assessment of novelty and inventive step.

V. Oral proceedings were held on 31 January 2020, during which the appellant amended the main request. At the end of the oral proceedings, the chairman pronounced the Board's decision.

VI. The appellant's final request was that the contested decision be set aside and that a patent be granted on the basis of the main request filed in the oral proceedings or the first or second auxiliary request, both auxiliary requests as filed by letter of 17 December 2019.

VII. Claim 1 of the main request reads as follows:

"A computer-implemented method for transitioning from an asynchronous communication mode to a synchronous communication mode for accessing a shared object (252, 264, 272), wherein

the asynchronous communication mode allows a revision of the shared object while being connected through a physical server, wherein revisions of the shared object by a client device are synchronized with the shared object on the physical server,

the synchronous communication mode allows a revision of the shared object while being connected through a peer-to-peer network formed by client devices, revisions to the shared object being instantly replicated to the client devices of the peer-to-peer network,

a peer group identifies users who are authorized to access the shared object, and a manifest file (254, 266) associated with the shared object includes a peer group identifier for the peer group where a version of the shared object is stored,

the method comprising the steps of:

accessing (900), by a client device (220), the shared object on a server (250) according to the asynchronous communication mode;

identifying, by the client device (220), a location of the manifest file based on a unique location identifier included in the accessed shared object;

retrieving (910), by the client device (220), the manifest file from the identified location, wherein the manifest file identifies the locations where any other versions and instances of the shared object are stored;

transitioning from the asynchronous communication mode to the synchronous communication mode by:

establishing (920) the peer-to-peer network (260) with any other client in the peer group that accesses a version or instance of the shared object identified by the manifest file when said any other client accesses a version or instance of the shared object identified by the manifest file, wherein the client device (220) is automatically connected to other clients that are accessing the shared object; and

disconnecting, by the client device (220), from the server (250) and continuing to access the shared object on the peer-to-peer network."

VIII. Claim 2 of the main request reads as follows:

"The computer-implemented method of Claim 1, further comprising:

updating the shared object in a cache of the client device (220), wherein

each client device locally stores the shared object in a corresponding cache (202, 212, 222, 232),

when a client device receives a revision from the peer-to-peer network (260), the client device updates the locally stored shared object in its cache."

IX. Claim 3 of the main request reads as follows:

"The computer-implemented method of Claim 2, wherein each revision to the shared object is associated with a global unique identifier and a time stamp, the time stamp identifying when the revision was made, the global unique identifier and the time stamp associated with each revision are used for synchronizing the revisions of the shared object."

X. Claim 4 of the main request defines "A computer-readable medium having computer-executable instructions for performing a method for transitioning from an asynchronous communication mode to a synchronous communication mode for accessing a shared object" including features corresponding to those of the method of claim 1.

XI. Claim 5 of the main request reads as follows:

"A system for transitioning from an asynchronous communication mode to a synchronous communication mode for accessing a shared object, wherein

the asynchronous communication mode allows a revision of the shared object while being connected through a physical server, wherein revisions of the shared object by a client device are synchronized with the shared object on the physical server,

the synchronous communication mode allows a revision of the shared object while being connected through a peer-to-peer network formed by client devices, revisions to the shared object being instantly replicated to the client devices of the peer-to-peer network,

a peer group identifies users who are authorized to access the shared object, and a manifest file (254, 266) associated with the shared object includes a peer group identifier for the peer group where a version of the shared object is stored,

the system comprising:

a client device (220), said client device being adapted for accessing (900) the shared object on a server (250) according to the asynchronous communication mode;

said client device being adapted for identifying a location of the manifest file based on a unique location identifier included in the accessed shared object;

said client device being adapted for retrieving (910) the manifest file from the identified location, wherein the manifest file identifies the locations where any other versions and instances of the shared object are stored;

means for transitioning from the asynchronous communication mode to the synchronous communication mode by:

establishing (920) the peer-to-peer network (260) of the client device (220) with any other client in the peer group that accesses a version or instance of the shared object identified by the manifest file when said any other client accesses a version or instance of the shared object identified by the manifest file, wherein the client device (220) is automatically connected to other clients that are accessing the shared object; and

disconnecting the client device (220) from the server (250) and continuing to access the shared object on the peer-to-peer network."

XII. Claims 6 and 7 are dependent upon claims 5 and 6 and define subject-matter corresponding to that of claims 2 and 3, respectively.

XIII. The text of the auxiliary requests is not relevant to the outcome of the appeal in this case.

XIV. The appellant's arguments, where relevant to this decision, are addressed in detail below.

Reasons for the Decision

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

Invention

2. The invention concerns file sharing to allow multiple users to access the same file simultaneously. Simultaneous access to a file can be supported by giving editing privileges to one user and read-only access privileges to the other users. The invention is intended to overcome the inconvenience of an object being blocked for other users when a user is editing the object (see page 1, lines 4 to 20 of the description as originally filed).

In accordance with the invention, several users may access, revise and update a shared object simultaneously, and users may revise an object offline. Multiple user revisions to a shared object are synchronised when the shared object is available (page 1, lines 13 to 22; page 12, lines 13 to 17).

2.1 A shared object may be represented as a graph of linked nodes corresponding to portions of the object. Content containers may be defined as groups of nodes to represent parts of the shared object. Specific operations may then be performed on individual content containers (page 11, line 10 to page 12, line 29, Figure 3). Revised content containers are reconciled and merged into the shared object by following a set of rules (e.g. revisions by specific users or by a server take precedence) established by a merge algorithm. Revisions which are not synchronised are identified as conflicting and stored (page 14, lines 11 to 26). They may be displayed in a conflict page and solved by the user (page 2, line 27 to page 3, line 9; page 15, lines 18 to 27, Figure 4).

2.2 Each shared object is associated with a manifest file, which identifies the locations where other versions and instances of the shared object are stored within the system (page 9, lines 23 to 25). The manifest file is stored in a location identified by a unique location identifier. The unique location identifier may identify a file server, a shared area of a server, a web server or a peer group. A client retrieves the manifest file and may access a shared object locally from a cache, through a server or through a peer-to-peer network (page 10, lines 1 to 16). A peer-to peer network allows revisions to the shared object to be transferred between clients directly instead of through a web server (page 7, lines 28 to 30).

2.3 The client may seamlessly transition between synchronous and asynchronous communication such that users are not aware that the mode of communication has changed. A user may change location, and any available data-sharing transports (e.g., peer-to-peer networks, servers) are automatically identified (page 9, lines 11 to 22).

Main request

3. Clarity - Article 84 EPC

3.1 The clarity objections raised by the Board were overcome by amendment.

Claim 1 now clearly defines a method of transitioning from an asynchronous to a synchronous communication mode, where "the asynchronous communication mode allows a revision of the shared object while being connected through a physical server" and "the synchronous communication mode allows a revision of the shared object while being connected through a peer-to-peer network formed by client devices, revisions to the shared object being instantly replicated to the client devices of the peer-to-peer network".

The term "store" and the phrase "the revision is associated with a current version", which were considered unclear in the Board's preliminary opinion, are no longer used in the claims.

3.2 The clarity objections raised in the decision under appeal are not maintained.

In the decision under appeal, the Examining Division found that claim 1 of each of the requests did not clearly define the manifest file and how it functioned. As the manifest file pointed to versions located on the peer-to-peer network, it was unclear how it was generated and updated on the basis of the continuously changing versions of the object in the peer-to-peer network. Other clients had local versions of the shared file and thus also had local versions of the manifest file. Since the manifest file could be located anywhere, it was unclear whether the web server was actually part of the peer-to-peer network and could be "updated from the peer-to-peer network" or update the versions on the peer-to-peer network. Specifying that the manifest file included a peer group identifier did not overcome the clarity objections.

The Board does not maintain this objection. It is clear from claim 1 of the main request that the manifest file includes the peer group identifier (the peer group identifying users authorised to access the shared object) and locations where any other versions of the shared object are stored. The client device retrieves the manifest file before transitioning to the synchronous communication mode. Transitioning is performed by establishing the peer-to-peer network "with any other client in the peer group that accesses a version or instance of the shared object identified by the manifest file when said any other client accesses a version or instance of the shared object identified by the manifest file". In the synchronous mode, the client is disconnected from the server and continues to access the shared object on the peer-to-peer network, with all revisions being instantly replicated to the client devices in the peer-to-peer network.

It is therefore clear that the server is not part of the peer-to-peer network. The way the manifest file is generated and updated is not defined in the claim and is not part of the invention. However, the Board is of the opinion that the skilled person can devise different ways of generating and updating the manifest file. The manifest file is defined broadly but not in an unclear manner in claim 1 of the main request; the same applies to the corresponding independent claims.

The other terms considered unclear in the decision under appeal are no longer used in the claims.

3.3 Therefore, the Board is satisfied that the main request fulfils the requirements of Article 84 EPC.

4. Added subject-matter - Article 123(2) EPC

4.1 Claim 1 is based on the embodiment disclosed in the application as filed on page 21, lines 12 to 30 with reference to Figure 9, in combination with features described in other passages. In particular, the definitions of the asynchronous and synchronous communication modes can be directly and unambiguously derived from page 8, lines 3 to 16 and page 9, lines 11 and 12 of the description as originally filed. The feature specifying the automatic connection of the client device to other clients that are accessing the shared object finds support on page 10, lines 17 to 25.

Therefore, claim 1 of the main request and corresponding independent claims 4 and 5 satisfy the requirements of Article 123(2) EPC.

4.2 According to page 6, lines 5 and 6 and 19 to 21, the clients shown in Figure 2 include caches for locally storing a shared object, which are updated when the client device receives a revision. From page 7, lines 28 to 30 and page 9, lines 5 and 6, it is clear that the shared object in the local cache is updated when a client device receives a revision from the peer-to-peer network. Therefore, claims 2 and 6 comply with Article 123(2) EPC.

4.3 Dependent claim 3 specifies that a revision is associated with a global identifier and a time stamp used to for synchronising revisions. The features of claim 3 are disclosed on page 8, line 7 to page 9, line 10, and on page 19, lines 5 to 12. Therefore, claim 3 and corresponding claim 7 fulfil the requirements of Article 123(2) EPC.

Remittal

5. The main request satisfies Articles 84 and 123(2) EPC and therefore overcomes the grounds for refusal stated in the decision under appeal.

In the first-instance proceedings, the Examining Division did not assess inventive step of the subject-matter of the current claims, which differ significantly from the searched claims.

In its communication pursuant to Article 15(1) RPBA 2007, the Board expressed its intention to remit the case under such circumstances.

5.1 In its reply to the Board's preliminary opinion and at the oral proceedings, the appellant acknowledged that the decision under appeal did not assess the inventive step of the refused claims and of subject-matter corresponding to that of the new claims, but argued that that had been mainly due to the Examining Division's objections of added subject-matter and lack of clarity. The Examining Division had held that it was impossible to clearly specify the asynchronous and synchronous communication modes. However, patentability had been examined in previous communications and would have been discussed in the oral proceedings leading to the decision under appeal had it not been for those objections, as was illustrated by point 7 of the summary of facts and submissions in the contested decision. The applicant had provided arguments on patentability as confirmed by point 8. In addition, the subject-matter of the new claims had already been considered in the assessment of novelty and inventive step during the examination proceedings. The appellant's position was that the cited prior art and the state of the file allowed the Board to continue with an assessment of novelty and inventive step.

5.2 The Board does not find the appellant's arguments convincing. The appellant could have introduced the amendments submitted in the appeal proceedings at an earlier stage in order to clarify the synchronous and asynchronous communication modes and the transition between the modes. The novelty objection of the search opinion was raised against a much broader claim directed to a method for synchronising multiple user revisions to a shared object. That claim did not mention the synchronous and asynchronous communication modes nor a transition between the two modes, and its subject-matter had little in common with current claim 1. The first communication added a discussion of the manifest file. In the communication accompanying the summons to oral proceedings, the Examining Division merely referred to the search opinion and first communication, explaining that a reasoned detailed opinion concerning novelty and inventive step could not be provided at that stage due to the severe problems of lack of clarity and added subject-matter. Moreover, it is not clear whether the search covered the subject-matter of the present claims.

In order to decide on the questions of novelty and inventive step, the Board would thus have to consider those questions anew in both first- and last-instance proceedings and to effectively replace the Examining Division. That would be contrary to the primary object of the appeal proceedings, i.e. to review the decision under appeal in a judicial manner (Article 12(2) RPBA 2020). It follows that special reasons for remitting the case within the meaning of Article 11 RPBA 2020 present themselves (see also T 1966/16 of 20 January 2020, reasons 2.1 and 2.2, T 731/17 of 15 January 2020, reasons 7.3).

6. Accordingly, the Board decides to exercise its power under Article 111(1), second sentence, EPC and to remit the case for further prosecution.

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the department of first instance for further prosecution.

Quick Navigation