The European Patent Office refused to grant a software patent on a method and system of authorisation of an access terminal rather than a user. Here are the practical takeaways of the decision T 0737/14 (Authorisation system / SECOREN) of 9.7.2019 of Technical Board of Appeal 3.5.01:
The invention concerns an authorisation system for authorising a transaction on an account.
The invention recognised that existing commercial outlets, which were equipped with terminals able to read card details, could be used for loading money onto a pre-paid card with little effort or expense.
In this new scenario, there was no need for the card owner to register themselves with the system handling the authorisation of the pre-paid cards. Instead, trust was established based on the access terminal being authorised to carry out such transactions.
As shown in Figure 7, there are three entities in this system: an access terminal 100, an account server 120, and an authorisation server 140. The access terminal sends a first transaction request 204 to the account server that forwards this, as the third transaction request 208, to the authorisation server. The access terminal also sends a second transaction request 206, including a terminal identifier, to the authorisation server. Based on the transaction data, the authorisation server determines whether the access terminal is authorised to enable the transaction, and sends the response 210 to the account server that carries out the transaction on the account.
Here is how the invention is defined in claim 1 of the sole request:
An authorisation system comprising:
an authorisation server (140);
an account server (120) for storing account data relating to a plurality of accounts;
an access terminal (100), including:
a token reader (106) for inputting token data from a selected one of a plurality of tokens, the token data identifying one of the plurality of accounts; and input means (108) for inputting transaction data;
- wherein the access terminal (100) is operable: to receive token data from the token reader (106) and to receive transaction data from the input means (108); to transmit to the account server (120) a first transaction request containing the token data and the transaction data; and to transmit to the authorisation (140) server a second transaction request including access terminal identification data identifying the access terminal;
- the account server (120) is operable to receive the first transaction request; to process the token data to generate account identification data, the account identification data being associated with a portion of the account data; and to transmit a third transaction request to the authorisation server, the third transaction request including the transaction data;
- the authorisation server (140) is operable to receive the second transaction request and to receive the third transaction request; to process the transaction data and the access terminal identification data to determine whether the access terminal (100) is authorised to enable the transaction; and, if applicable, to transmit to the account server (120) an authorisation request to indicate that the access terminal is authorised; and
- in response to receipt of the authorisation request from the authorisation server, the account server (120) is operable to process the transaction data and to modify the account data associated with the account identification data in dependence on the processing.
Is it patentable?
Although the invention concerns inter alia a business idea, claim 1 also includes technical means. Therefore, there was no discussion whether the claim 1 as a whole is patent-eligible.
During the proceedings, D1 was considered as the closest prior art. The key distinguishing feature from claim 1 over D1 was found to be:
- The authorisation server in claim 1 determined, based on access terminal identification data, whether the access terminal (rather than the user) was authorised to enable the transaction.
The examining division argued that the identification of the access terminal rather than the user was a well known alternative available to the skilled person, and that the choice was “governed by business constraints”.
The assessment of the examining division was found not convincing by the Board:
2.6 The examining division did not say what the business constraints were. That is unfortunate, because the business constraints are key in this case. The Board does not see any technical reason, given the on-line purchasing scenario in D1, why the skilled person would have identified the access terminal…
The Board took a further analysis of the underlying transaction scenario in the invention:
4.1 The Board takes the view that the pre-paid scenario, including the relationship between the point-of-sale/agent, the credit card issuer/processor, and the third party, is a business idea. According to decision T 641/00 – Two identities/COMVIK, this type of subject-matter cannot contribute to inventive step. Instead, as mentioned above, it is considered to be part of the problem that the skilled person has to solve.
4.2 In the Board’s view this case is a good example of why the proper application of the COMVIK approach requires a thorough analysis of the business constraints when formulating the problem to be solved before investigating what the skilled person would have done to solve it. …
4.3 …, the skilled person should have been given the problem of implementing a business model on the conventional transaction processing system, as exemplified in D1, in which the third party carries the financial risk and needs to safeguard itself from fraud and recover the funds from the agent. The skilled person would have assigned the necessary technical means, namely an access terminal at the side of the agent, an account server at the side of the credit card issuer/processor, and an authorisation server that carries out the task of the third party. The functions performed by those entities in claim 1 follow directly from the business scenario. Since the third party needs to safeguard itself, rather than the agent, from fraud, the skilled person would realise that the third party has to authorise the agent. Performing the authorisation based on the terminal identifier of the access terminal would have been an obvious implementation.
In the end, the Board concluded that claim 1 lacks an inventive step over D1. The appeal was thus dismissed and the patent application was finally refused.
You can read the whole decision here: T 0737/14 (Authorisation system / SECOREN) of 9.7.2019.
Maggie is a patent engineer at BARDEHLE PAGENBERG. She specializes in software patents in Europe both from a prosecution and litigation point of view.