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:
Key takeaways
Features, even if based on technical considerations, may be considered non-technical if they are devisable from a business decision.
A user interface simulation is considered as representation of information and thus non-technical.
The invention
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)
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.
More information
You can read the whole decision here: T 0909/14 (Web service without upfront storage/MICROSOFT) of June 3, 2022.