T 1027/20 (Availability status/MICROSOFT TECHNOLOGY LICENSING) of 15.2.2023

Summary of Facts and Submissions

I. The appeal lies from the decision of the examining division to refuse European patent application No. 11832929.1, which was filed as international application published as WO 2012/050700.

The examining division decided that the subject-matter of the claims of the sole request lacked inventive step over the following prior-art document:

D1: S. Kim, "Java Web Start", September 2001, pages 1 to 14, XP002598525, retrieved on 30 August 2010 at URL:http://www.ibm.com/developerworks/java/library/j-webstart.

II. With the statement of grounds of appeal, the appellant submitted a set of claims of an auxiliary request. The appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the main request considered in the decision under appeal, or the auxiliary request filed with the grounds of appeal.

III. In a communication accompanying the summons to oral proceedings, the board introduced the following document into the proceedings:

D2: WO 2007/008996, published on 18 January 2007.

The board found it preferable to assess inventive step starting from document D2 rather than document D1.

The board expressed its preliminary opinion that the subject-matter of claim 1 of the main and auxiliary requests was not clearly defined and lacked inventive step over document D2. In addition, one of the deficiencies for lack of clarity could also translate in an objection under Article 83 EPC.

IV. With a letter dated 15 December 2022, the appellant filed a new set of claims replacing both claim requests on file.

V. Oral proceedings were held as scheduled. At the end of the oral proceedings, the Chair announced 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 set of claims 1 to 14 filed with the letter of 15 December 2022.

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

"A method of presenting to a user (52) of a client (12) on a device having a processor and a data store (32), availability statuses of objects (16) in a copy of an object set (14) in the client, the object set (14) being managed by a host storing a computing environment, wherein the data store (32) comprises a temporary data area and stores the copy of the object set (14) which comprises a set of objects (16) in a canonical location, wherein at least one object (16) of the copy of the object set (14) is associated with an object descriptor (58) that indicates an availability status (56) of the object (16) and wherein the availability status (56) of the object (16) includes one of an available status indicating that the object (16) has been fully synchronized, a relocating status, a requesting status, or a receiving status of the object (16) indicating that the object (16) has not been fully synchronized, the method comprising:

executing on the processor instructions configured to, upon receiving (76) a request from the user (52) to present an informative availability status (56) of the object (16):

upon determining (80, 84) that the object (16) is in the data store (32) in the canonical location for the object set (14), present (86) to the user (52) the available status indicating that the object (16) has been fully synchronized;

upon determining (80, 88) that the object (16) is not in the canonical location for the object set (14) but stored in the temporary data area of the data store (32), present (90) to the user (52) the relocating status;

upon determining (92, 96) that the object (16) is not in the temporary data area of the data store (32) and that the object (16) is being received from the host, present (98) to the user (52) the receiving status;

upon determining (92, 100) that the object (16) is not in the temporary data area of the data store (32) and that the object (16) is not being received from the host, present (102) to the user (52) the requesting status; and

upon determining an existence of a versioning conflict among two versions of the object (16) stored in the temporary data area and in the canonical location, presenting to the user (52) a versioning conflict status; and

update the object descriptor (58) upon detecting various events relating to the synchronization of the object (16)."

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

Reasons for the Decision

Application

1. The application concerns the presentation to a user of the availability status of objects in an object set, where the objects are synchronised among two or more clients (such as synchronisation services operating on two or more devices connected via a network) (see paragraphs [0004] and [0026] of the international publication). The object set may include objects such as files, data objects, database records, electronic mailboxes, applications, application settings or contacts in an address book. Relevant portions of the object set may be deployed to various devices (a "mesh" of devices) to promote a uniform computing environment across devices (paragraph [0017]).

Admissibility - sole request

2. In its preliminary opinion, the board raised objections of lack of clarity and insufficiency of disclosure which had not been raised before. In addition, the board introduced prior-art document D2 into the proceedings and considered that the subject-matter of claim 1 of both requests was not inventive over this newly introduced prior-art document. These are exceptional circumstances under Article 13(2) RPBA 2020 which justify admitting the new set of claims submitted in reply to the board's preliminary opinion. In view of this, the board decides to admit the new claim request into the appeal proceedings.

Claim 1 - interpretation

3. Claim 1 specifies a method of presenting to a user of a client system the availability status of objects in a copy of an object set in the client. The object set is managed by a host "storing a computing environment". The client has a data store. The data store comprises a temporary data area, where an object is stored temporarily during synchronisation before being relocated to a "canonical location". The data store stores the synchronised copy of the objects of the object set in the canonical location (see also paragraphs [0020] and [0021] of the description).

According to the description on page 15, lines 14 to 18, a host may be another client and/or device, including an object server, hosting an object.

3.1 At least one object of the copy of the object set is associated with an "object descriptor" that indicates the "availability status" of the object. The claimed method includes a step of updating the object descriptor upon detecting various events relating to the synchronisation of the object.

3.2 The availability status of the object (in the client) includes one of an "available status" indicating that the object has been fully synchronised, a "relocating status", a "requesting status", or a "receiving status" of the object indicating that the object has not been fully synchronised.

3.3 Upon receiving a request from the user to present "an informative availability status of the object", instructions are executed to present to the user:

(a) the available status indicating that the object has been fully synchronised, upon determining that the object is in the data store in the canonical location for the object set;

(b) the relocating status, upon determining that the object is not in the canonical location for the object set but stored in the temporary data area of the data store;

(c) the receiving status, upon determining that the object is not in the temporary data area of the data store and that the object is being received from the host;

(d) the requesting status, upon determining that the object is not in the temporary data area of the data store and that the object is not being received from the host; and

(e) a versioning conflict status, upon determining that a versioning conflict exists among two versions of the object stored in the temporary data area and in the canonical location.

Inventive step - claim 1

4. Document D2 discloses solutions to providing a single view of data in a networked computer system with distributed storage (title, paragraph [01]). The system displays lists of data files, with indications of the data title, storage size and type of data file (paragraph [51], Figure 7D). In order to be able to access and use data from "multiple computers, clients or other machines for business, personal or other uses", the user may choose data objects to be synchronised. For example, the user may choose the sets of files "MY MUSIC" and "MY PHOTOGRAPHS" of Figure 9 to be synchronised. Those files may be stored locally in two or more devices and may be automatically synchronised by the system (paragraphs [54] to [58]).

Therefore, document D2 discloses a system including a client on a device having a processor and a data store, and a host (e.g. another client) storing versions of objects of an object set, those stored objects being automatically synchronised between systems.

In the method of D2, objects are displayed to the user, where locally "unavailable content may be displayed with a dotted border and/or in a semi-transparent manner" (paragraph [50], Figure 7B). Therefore, upon determining that an object is stored locally in a file location, which corresponds to a "canonical location", the available status is presented to the user (in that the content is not displayed "with a dotted border and/or in a semi-transparent manner"). This corresponds to feature (a) of claim 1.

Since the host of D2 is an operational computer system, the host can be considered to store a "computing environment" within the meaning of claim 1, which does not further specify the "computer environment" or its use in the claimed method.

4.1 File system logs kept in clients in the system of D2 store information about the synchronised files including "not merely date-stamp information indicating the most recent editing, downloading or accessing of a file, but further information such as file size, file type, information regarding previous versions or transmissions of a file" (paragraph [0061]). The "sync engine" in a first device accesses the file system logs of a second device in order to examine "the state, behavior or history of the files and other content on the participating machine". The sync engine then performs the necessary operations, e.g. transfers files from one device to another, or changes the stored location of, synchronised files in order to ensure that the same version of a given file is maintained in the first and second devices, and other participating machines (paragraphs [60] to [62], Figure 9).

Therefore, the system of D2 determines the availability status of an object, including whether it is available and fully synchronised in the (local) data store (status (a) above), or unavailable, by accessing "object descriptors" in the form of a file system log, and it performs operations which cause the object status to change. Since in the system of D2 a version of the file is transferred to the local client to achieve the synchronisation, the object status can be a "requesting status" or a "receiving status" (status (c) or (d)).

4.2 If the sync engine of D2 detects a version conflict between two instances of a file (e.g., an older file is being prepared to overwrite a newer version of that same file), the version management logic may present the user with a dialogue or query to resolve that conflict (paragraph [65]).

Therefore, document D2 discloses the step of performing an examination of the data store to determine a versioning conflict among two versions of the object and presenting to the user a "versioning conflict status", as in status (e) of claim 1.

4.3 However, document D2 does not explicitly disclose a relocation status, determining the status based on a temporary location of the object and presenting a receiving or requesting status to the user. Therefore, the subject-matter of claim 1 differs from the method of document D2 in that upon determining each of the conditions expressed in (b), (c) and (d) above, the method presents to the user the relocating, receiving and requesting status, respectively.

4.4 As for the "relocation status" and the corresponding "relocation" stage of the underlying synchronisation process, at the priority date of the application, it had been common practice to download files to a temporary location, for example for decompression, before moving or "installing" them to the destination directory.

At the oral proceedings, the appellant did not contest that the synchronisation process underlying the claimed method, which includes the "relocation" stage, was obvious. The inventive aspect was the presentation of the availability statuses of objects to the user.

4.5 Presentation of information is as such not patentable in view of Article 52(2)(d) and (3) EPC. Features relating to presentation of information are to be taken into account for inventive step only to the extent that they interact with technical features of the claimed invention to produce a technical effect.

4.6 The appellant submitted that the distinguishing features relating to the presentation of the availability status had to be considered technical, since the information provided to the user related to the technical status of the synchronisation process. At the very least, these functions were related to technical considerations such as the technical status of the synchronisation.

The appellant argued that distinguishing features (b), (c) and (d) achieved the technical effect of providing a user with information as to why a synchronisation process had not yet been completed, as was described in paragraph [0022] of the application. This was in contrast to prior-art teachings such as D2, which merely provided information that a synchronisation process was incomplete.

According to the appellant, the relocating, receiving or requesting statuses helped the user understand in which portion of the transmission path the object was currently stopped. The user could then identify problems occurring during the synchronisation.

The appellant formulated the objective technical problem solved by claim 1 as being that of providing a method for enabling a user to monitor progress of a synchronisation process of an object between two computing devices.

The appellant argued that the identification of the three stages of the synchronisation, relocating, receiving and requesting, was already inventive. Document D2, which only distinguished two stages, provided no pointer to the claimed solution. It would not have been obvious for the skilled person to arrive at the claimed solution, which was thus inventive.

4.7 The board recognises that the synchronisation of an object in the context of claim 1 is a technical process involving the transmission of data from the host to the temporary data area of the client and then to the canonical location, and that informing the user about the progress of a technical process is in principle a technical problem (see T 528/07, Reasons 3.3 to 3.5; T 1670/07, Reasons 12 and 13). This principle has not changed with decision G 1/19 of the Enlarged Board. This decision rules that measurements, including indirect measurements, have technical character since they are based on an interaction with physical reality at the outset of the measurement method. Moreover, measurements are of a technical nature regardless of what use is made of the results (G 1/19, reasons 85, 86 and 99).

4.8 However, as already discussed at the oral proceedings, at the priority date of the present application it was standard practice to display information indicating the status of a process, for example using progress indicator bars showing the status of a downloading process. Moreover, the method of document D2 already presents to the user information concerning whether an object is synchronised or not (see paragraph [50] and point 4. above).

4.9 In view of the above, it would have been obvious for the skilled person to synchronise the object by downloading it to a temporary location before storing it in the "canonical location", thereby arriving at the three stages "relocating", "receiving" and "requesting" of the synchronisation process. It would then be straightforward for the skilled person to extend the presentation of document D2 to include one of the three non-synchronised statuses "relocating", "receiving" and "requesting". The board is thus of the opinion that it would have been obvious for the skilled person to add the distinguishing features to the method of document D2.

4.10 Therefore, claim 1 does not satisfy the requirements of Article 56 EPC for lack of an inventive step.

Concluding remarks

5. Since the sole request on file is not allowable, the appeal is to be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.