T 0909/14 (Web service without upfront storage/MICROSOFT) of 3.6.2022

Summary of Facts and Submissions

I. This appeal is against the decision of the examining division to refuse European patent application No. 08836617.4 for lack of inventive step (Article 56 EPC).

II. The examining division found that the independent claims according to the main request and first and second auxiliary requests then on file lacked an inventive step over a notorious networked data processing system. The decision mentioned five patent documents as disclosing an example of such a system, including US2006/242581 (D5).

The division argued, using the COMVIK approach, that the distinguishing features defined a non-technical administrative scheme, which would have been obvious to implement, once it had been given to the skilled person within the framework of the technical problem.

III. In the statement setting out the grounds of appeal, the appellant requested that the decision be set aside and a patent be granted on the basis of the refused requests.

IV. In a communication, the Board set out its preliminary opinion that the subject-matter of all requests lacked an inventive step over the disclosure of D5.

V. In a reply dated 2 September 2020, the appellant refiled the second auxiliary request as a new main request and filed a new auxiliary request. It also submitted further arguments in favour of inventive step.

VI. In the communication accompanying the summons to oral proceedings, the Board admitted the main request into the proceedings and informed the appellant that it intended to admit the auxiliary request. Furthermore, having analysed the appellant's arguments, the Board tended to consider that the main and auxiliary request lacked an inventive step over D5 (Article 56 EPC).

VII. Oral proceedings took place as a videoconference on 3 June 2022. The appellant's final requests were that the decision be set aside and a patent be granted on the basis of the main request or the auxiliary request, both filed with the reply dated 2 September 2020.

VIII. Claim 1 of the main request reads:

"A document sharing method of allocating resources for users of a service (102), the service providing an interface for a user having a first type of account on the service through which the user can perform first functions (506) related to documents associated with the user's own account and second functions (508) related to documents associated with accounts of other users, the first functions comprising creating at least one document by the user and the second functions comprising editing at least one document created and shared by another user wherein resulting edits are stored within the other user's account, the method comprising:

communicating (202) an invitation from a user of the service to a prospective user to access the service;

upon determining (204) that no account exists for the prospective user, automatically creating (208) an account of a second type for the prospective user based on information contained in the invitation, wherein the created account of the second type does not comprise resources on the server enabling the prospective user to create documents nor resources enabling the prospective user to perform the first functions, thereby reducing a cumulative amount of resources allocated to users of the service;

presenting (206) a prospective user interface (318) for the prospective user, the prospective user interface simulating (502) the user interface without enabling the prospective user to perform the first functions;

displaying (210), through the prospective user interface, documents managed by the user to enable the prospective user to access the documents;

offering (212), via the prospective user interface, to the prospective user an opportunity to utilize capabilities of the service comprising the first functions and the second functions; and

in response to the prospective user accepting the offer (214), creating (216) an account of the first type on the service for the prospective user, and presenting a modified user interface (308) for the prospective user, the modified user interface enabling the prospective user to perform the first functions and the second functions (220)."

IX. Claim 1 of the auxiliary request replaces:

- The penultimate feature with the following one:

"in response to the prospective user attempting to perform a first function, displaying (212), through the prospective user interface, a clickable component (316, 408) enabling the prospective user to request becoming a user having an account of the first type to utilize capabilities of the service comprising the first functions and the second functions"

- The wording "accepting the offer" in the last feature with "clicking the clickable component"

X. The appellant argued as follows:

The key-idea of discriminating between full users and prospective users with fewer resources came from technical considerations of saving server resources, for example storage space for documents' metadata and thus could not be ascribed to the business person. This motivation was clearly stated in the application's background section and should have been taken into account in the assessment of inventive step. The business requirement ended with how to save resources without impairing usability.

Presenting a prospective user with a simulated interface of a full user was technically motivated too. It allowed a prospective user to see the full user's interface from the beginning so that he did not need to explore its functionality from scratch after becoming a full user. This produced the technical effects of increasing the service usability and reducing the time the full user needed to explore the interface after the upgrade and, hence, energy consumption.

Even if the creation of a group of prospective users with less functionality were part of the business scheme, it still would not have been obvious to reduce resources given to these users. Rather, it would have been obvious to give the same resources to all users, but to disable some functionality for the prospective users. It was also unobvious in view of the business scheme to store edits to a shared document in association with the sharer's account. The obvious solution was rather to create a copy of this document for each editing user.

Reasons for the Decision

1. Admissibility under Article 13(1) RPBA

The Board admitted the main request and the auxiliary request, filed on appeal, into the proceedings under Article 13(1) RPBA 2020. The reasons are that the main request corresponds to the refused second auxiliary request and the auxiliary request is a bona fide attempt to overcome the Board's new objections based on D5.

2. The invention

2.1 The invention concerns a web service enabling the creation, storage and sharing of documents (see published application page 1, lines 6 to 19). Such services are known from the prior art.

The key idea is to allow new (prospective) users of the service to access only part of the available functionality in order to reduce resources consumed (page 1, line 30 to page 2, line 13).

2.2 Claim 1 of the main request recites a method for creating and upgrading user accounts. The service's full users, having an account of the first type, may create their own documents and edit documents shared by others. By contrast, a prospective user, joining the service in response to an invitation from an existing user, gets an account of a second type not allowing him to create his own documents, but only to edit shared documents (page 12, lines 8 to 31).

The account of the second type is said to "not comprise resources on the server enabling the prospective user to create documents". The Board objected that the application does not set out what actual resources are saved on the server (page 6, lines 20 to 33). During the oral proceedings, the appellant explained that the saved resource was storage space for documents' names and metadata within the full user account.

The service creates for the full user and the prospective user different user interface websites, the prospective user's website "simulating" the full user's one. The appellant explained at the oral proceedings that, looking at Figures 3A and 3B, an example of simulating was displaying on the prospective user website 310 a "My Documents" folder 312, even though, unlike on the full user website 300, the folder was empty because the prospective user was not allowed to create documents (page 12, lines 26 to 31).

The prospective user can upgrade his status to the full user by accepting an offer to do so presented on the prospective user interface (page 5, lines 16 to 27).

2.3 Claim 1 of the first auxiliary request adds that in response to the prospective user attempting to create a document, a clickable component enabling the user to request the upgrade to the full user is displayed. For example looking at Figure 4B, the prospective user interface comprises a token "Add File" button 404, clicking upon which results in displaying a prompt and a further clickable button 408 enabling the user to upgrade (page 13, lines 21 to 28).

3. Main request, inventive step (Article 56 EPC)

3.1 The division started from a notorious data processing system comprising a plurality of networked computers. However, the Board prefers to start from D5 since it is concerned with a document sharing service, and hence closer to the claimed invention. In D5, all users have accounts of a first type.

It was common ground that the subject-matter of claim 1 differs from D5:

A) In that the web service enables a user to edit documents shared by another user, wherein the resulting edits are stored within the other user's account (end of opening part of claim 1).

B) By creating an account of second type for a prospective user, joining the service in response to an invitation from an existing user, wherein this account does not comprise resources on the server enabling the prospective user to create documents, thereby reducing a cumulative amount of resources allocated to users (first and second features of claim 1).

C) By presenting a prospective user interface simulating the full user interface without enabling the prospective user to create his own documents (third feature).

D) By offering to the prospective user an opportunity to upgrade his account via the prospective user interface (fifth feature).

E) By creating for the prospective user the account of the first type and presenting to him the full user interface enabling the creation of documents in response to him accepting the offer (sixth feature).

3.2 The main point of dispute in this appeal is whether discriminating between full users and prospective users with limited functionality is the solution to the technical problem of saving resources, as argued by the appellant (see section X, above), or a non-technical requirement that could be envisaged by the business person and thus part of the problem given to the skilled person under the COMVIK approach (see T 641/00 - Two identities/COMVIK) as argued by the

division.

3.3 Decision T 1463/11 - Universal merchant platform/CardinalCommerce, further refining the COMVIK approach, set out that in the assessment of inventive step, circumstances under which inventions are developed in the real world have to be ignored to a certain extent. It introduced the concept of the notional business person who may formulate business requirements to be implemented but will not include in them any technical matter. The notional business person is a legal fiction representing a shorthand for a separation of business considerations from technical ones. Using this legal fiction is the price paid for an objective assessment; a real inventor does not hold such considerations separately from one another (see reasons 14 to 16).

3.4 Under the CardinalCommerce approach, the test used in deciding on technicality of a feature is whether the notional business person could have come up with it. This boils down to determining whether there would have been at least one way to devise it without technical considerations. If so, it does not have technical character and may form part of the requirement specification regardless of what alternative ways of arriving at it were disclosed in the application or were conceivable.

3.5 This result, although unfortunate for an applicant who did actually arrive at the feature via the technical path, is not unique to the business-related exclusion.

As noted in G1/19 - Pedestrian simulation (see end of section 82), another example would be methods for treatment of the human body which have both patentable non-therapeutic and therapeutic uses falling within the exception to patentability under Article 53(c) EPC (see, for example, T 1635/09, OJ EPO 2011, 542, Reasons, points 3 and 5, where the claims could not be limited to a non-therapeutic method because the therapeutic elements and the non-therapeutic elements of the claimed use were inseparably associated with each other).

3.6 In the present case, the Board judges that providing limited functionality for some users, such as not enabling the creation of documents, is a business decision which need not be based on technical considerations. There are apparent business reasons for doing it, for example charging the full user a higher subscription fee than the prospective user.

Furthermore, the Board judges that the notional business person knows that providing users with functionality utilises "resources" in general terms and limiting these resources might reduce costs. Accordingly, the notional business person seeking to reduce costs would have required that the prospective user not be given unnecessary resources. At this point nothing technical is going on yet.

By contrast, the decision as to which computer resources to save is a technical implementation issue which is up to the skilled person. However, the only implementation feature claimed is that the saved resources are on the server. While the appellant argued that the saved resource was storage space for document metadata, this is neither claimed nor disclosed in the application.

3.7 Concerning "simulating" the full user interface, the Board judges that including in the user interface a feature which is useless without an account upgrade, for example an empty document container, relates to the presentation of information and is not based on any technical considerations. The appellant's argument attempting to prove that this part of the solution derives technical character from effects produced when the user operates the upgraded user interface is not convincing. In addition to being speculative, it is a typical example of the "broken technical chain fallacy" in the sense of T 1670/07 - Shopping with mobile device/NOKIA, reason 11.

3.8 The Board judges that the notional business person would have tasked the skilled person with implementing a non-technical business scheme in the system of D5, wherein:

- There are two user categories: full users and prospective users. Unlike the full user, the prospective user may not create documents and is not given resources required for doing it.

- A new user, joining the service in response to an invitation from its existing user, becomes the prospective user. He can upgrade his status to the full user at a later point, if he accepts an offer to do so.

- A visual container for documents created by a user is presented to the prospective users and the full users, but the prospective users' container is empty.

- Both the full and the prospective users can modify a document shared with them by another user such that the sharing user sees the modifications made.

3.9 The Board judges that starting from the disclosure of D5 and seeking to implement the above scheme, the skilled person would have found the claimed implementation obvious.

The following implementation features follow directly from the scheme:

- Providing functionality for editing shared documents. - Automatically creating a prospective user interface, which does not enable the prospective user to create documents, but comprises an empty container for created documents.

- Displaying in this interface, a prompt suggesting an account upgrade and triggering the upgrade in response to the user accepting the prompt, wherein the account upgrade entails creating the full user account and replacing the prospective user interface with the full user one.

Furthermore, the Board judges that not allocating to the prospective user resources on the server, which are required for creating documents, would have been obvious.

3.10 Concerning the argument that the skilled person would have rather considered disabling functionality, the Board cannot see why allocating a resource, e.g. server memory, and disabling it is more obvious than not giving this resource in the first place.

3.11 Concerning the argument that the skilled person would have rather created a copy of the document for each user editing it, the business scheme requires that a document sharer see modifications made and the most obvious way of implementing this is to store the changes in association with his account.

3.12 Hence, claim 1 lacks an inventive step (Article 56 EPC).

4. Auxiliary request, inventive step (Article 56 EPC)

4.1 The Board judges that claim 1 of the auxiliary request adds nothing of inventive merit. Providing a token element for adding documents and displaying a clickable upgrade prompt when it is selected is an obvious implementation of the business requirement that an upgrade to the full user should be offered when the prospective user attempts to create a document.

4.2 Hence, claim 1 of the auxiliary request lacks an inventive step (Article 56 EPC).

Order

For these reasons it is decided that:

The appeal is dismissed.