T 0909/14 (Web service without upfront storage/MICROSOFT) 03-06-2022

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).