The application underlying this decision relates to allowing prospective users of a web service to access only parts of the available functionality to reduce resource consumption. However, the European Patent Office refused to grant a patent since claim 1 mainly addresses the implementation of a business decision. Here are the practical takeaways of the decision T 0909/14 (Web service without upfront storage/MICROSOFT) of June 3, 2022 of Technical Board of Appeal 3.5.01:
The application underlying the present decision mainly concerns optimizing the resource usage (e.g., server resources) of web services by limiting corresponding functionality based on a user’s account status (i.e., full or light/prospective). While a full user may make full use of the capabilities of the services due to corresponding allocated resources, a light user may only use certain (i.e., reduced) functionality of the service. The application addresses a situation in which a full user invites another (prospective) user to the web service. A light profile may be created for the prospective user allowing the prospective user to utilize a limited set of functionality via a simulated user interface. If the prospective user expresses the intent to fully utilize the web service capabilities, corresponding resources may be allocated on the server and the prospective user’s user interface will be updated accordingly. As a result, resources are only allocated for those types of users, who intent to make full use of the web service’s capabilities.
Fig. 5 of WO 2009/045757 A1
Here is how the invention is defined in claim 1 of the main request:
Claim 1 (Main Request)
“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).
Is it technical?
For assessing inventive step, the Board in charge started from prior art document D5, relating to sharing a service in which all users have accounts of a first type (i.e., full user). It was common ground that D5 only discloses the first part of the preamble (underlined part) and feature 4.
According to the Board, the main point of the dispute is:
“Whether discriminating between full users and prospective users with limited functionality is the solution to the technical problem of saving resources or a non-technical requirement that could be envisaged by the business person.”
The applicant argued:
“The key idea of discriminating between full users and prospective users with fewer resource came from technical considerations of saving server resources, for example storage space for document’s meta data and this could not be ascribed to the business person.”
Furthermore, the applicant argued:
“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 needs to explore the interface after the upgrade and, hence, energy consumption.”
The applicant concluded:
“Even if the creation of a group of prospective user with less functionality were part of the business scheme, it still would not have been obvious to reduce resources given to these users.”
However, the Board did not follow the applicant’s arguments. The Board referred to decision T 1463/11 (introduction of the notional business person) and stated:
“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.”
Accordingly, even if one would arrive at the feature based on technical considerations, the feature would still be deemed as non-technical. The Board concluded:
“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.”
With respect to the reduced resource usage, the Board stated that saving computer resources (e.g., storage space for metadata as argued by the applicant) is to be considered as technical. However, the Board argued that this is neither claimed nor disclosed in the application. In contrast, claim 1 only refers to saving resources on the server, which may also relate to limiting resources to reduce costs.
The Board also did not follow the applicant’s arguments regarding the alleged technical effect achieved by simulating the user interface and referred to the “broken technical chain fallacy” of T 1670/07. According to the Board, the simulation of the user interface relates to the presentation of information and is thus not based on any technical considerations.
As a result, the Board stated that the notional business person would have instructed the skilled person with implementing a non-technical business scheme based on the system of D5, which would have been obvious for the skilled person.
Therefore, the Board dismissed the appeal due to lack of inventive step.
You can read the whole decision here: T 0909/14 (Web service without upfront storage/MICROSOFT) of June 3, 2022.