T 0737/14 (Authorisation system / SECOREN) 09-07-2019
Download and more information:
AUTHORISATION SYSTEM
Inventive step - authorisation of the access terminal rather than the user
Inventive step - (no
Inventive step - part of the business scenario)
I. This appeal is against the decision of the examining division to refuse the application No. 08709562.6 (published as WO 2008/104788 A2) on the ground that the subject-matter of claims 1, 7, 10, and 14 lacked an inventive step (Article 56 EPC).
II. The decision of the examining division referred, inter alia, to document D1 (WO 03/098563 A).
III. In the statement setting out the grounds of appeal the appellant requested that the decision to refuse the application be set aside and that a patent be granted on the basis of the claims considered by the examining division in the decision under appeal.
IV. Claim 1 reads:
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.
V. Claim 7 defines the access terminal, and claim 10 the authorisation server. Claim 14 defines a method in a system corresponding to the one in claim 1.
VI. The appellant's arguments can be summarised as follows:
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.
D1 was directed towards a system in which a user carried out an Internet transaction. D1 had nothing to do with pre-paid cards or any scenario in which the access terminals had any status in the transaction. As such, it was an inappropriate starting point for assessing inventive step under the problem solution approach.
Even taking D1 as a starting point, the skilled person would not have considered authorising the access terminal. In the context of D1, it simply did not make sense to identify the terminal as the terminal was irrelevant to the transaction.
VII. In a letter dated 2 May 2018, the appellant requested accelerated processing of the appeal, on the ground that the appellant envisaged infringement proceedings in respect of any patent granted on the basis of the application. The Board acceded to the appellant's request for acceleration.
VIII. The Board arranged for oral proceedings to be held. In a communication accompanying the summons to oral proceedings, the Board set out its preliminary view that the subject-matter of claims 1, 7, 10 and 14 lacked an inventive step, albeit for different reasons than those provided in the decision.
IX. The appellant replied that it would not attend the oral proceedings. No additional arguments were made.
X. The Board held oral proceedings in the appellant's absence. It was announced that the decision would be delivered in writing.
1. Background
1.1 The invention concerns an authorisation system for authorising a transaction on an account. Looking at 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.
1.2 The independent claims do not define what sort of transaction is processed by the system. As it turned out, this caused some difficulties in the assessment of the invention, both in examination and appeal proceedings.
2. The decision under appeal
2.1 The examining division saw the invention basically as a conventional transaction processing system running a "generic three party transaction authorisation protocol" involving a trusted third party. In such a system, the third party typically receives two messages; one from the account owner and one from the the party that performs the transaction settlement. To prevent fraudulent transactions, the third party authorises the transaction only if it is confirmed by the account owner.
2.2 D1 discloses (Figure 1) such a transaction processing system, for online shopping. The customer sends a purchase request 1, including credit card details, to an e-retailer. The e-retailer forwards the credit card details 2 to a credit card issuer who checks them and returns an authorisation 3. The e-retailer then sends a message 4 to a web site administered by a third party. The message comprises sufficient information to identify the customer. In order to authorise the purchase, the customer must log on 5 to the authorisation web site using a password. Once the customer has logged on, a message 6 is sent from the authorisation web site to the e-retailer. Alternatively (Figure 2), it is the credit card issuer, that, in the same way, uses the authorisation website to make sure that the transaction is not a fraudulent one.
2.3 The examining division found that the customer's terminal in D1 corresponded to the access terminal in claim 1, and that the combination of the credit card issuer and the e-retailer mapped to the account server. The authorisation website in D1 was equated with the authorisation server in claim 1. As a result, the examining division identified the following differences between the invention in claim 1 and D1:
a) The access terminal in claim 1 had a token reader for inputting the credit card data.
b) 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.
2.4 The examining division considered that it would have been obvious to use a reader to input the credit card data. Thus, feature a) did not provide an inventive step. The Board agrees with this finding. Also, since feature a) has no synergy with feature b), it is justified to assess the two features separately.
2.5 Concerning feature b), 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". Alternatively, it could be seen as an obvious security measure, on top of the identification of the user.
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, whether as an alternative to the identification of the user, or as an additional measure. As the appellant argued, the access terminal simply does not play any role in this scenario.
3. The transaction scenario in the invention
3.1 It is clear that the transaction scenario in the invention is crucial to the question of inventive step because this sets the framework of the technical problem given to the skilled person to solve (see e.g. T 1463/11 - Universal merchant platform/CARDINALCOMMERCE, points 12 and 13). In the communication, the Board raised the question what that scenario was in view of the widely different embodiments disclosed in the application. The appellant neither replied, nor attended the oral proceedings. Thus, the Board has to find a reasonable interpretation based on the examples in the application.
3.2 The claims cover the example of the transaction scenario, in which the access terminal is used to load money onto a custom pre-paid credit card. Also, the appellant's arguments in the grounds of appeal focus on this scenario.
3.3 According to the description, a customer who wants to load money onto a pre-paid card goes to a conventional point-of-sale system (access terminal) and swipes the card (see page 10, lines 5 to 11). The customer also presents funds, corresponding to the amount that he wants to load onto the card, to the point-of-sale system that acts as an agent.
The point-of-sale system requests that the credit card issuer or processor credit the pre-paid card with the specified amount. This corresponds to the claimed first transaction request to the account server. The account server redirects the details of the swipe to a third party computer system for authorisation (lines 32 to 34). This corresponds to the claimed third transaction request to the authorisation server. The point-of-sale system also transmits details of the transaction and identification of the access terminal to the third party computer system (page 11, lines 6 to 11). This corresponds to the second transaction request to the authorisation server.
3.4 At first glance, it may appear that the third party is there just to authorise the agent on behalf of the credit card issuer/processor (account server). However, the description goes on to state (page 11, lines 11 to 15):
"In this embodiment, when a user presents funds to an agent, no transfer of funds occurs between the agent and the credit card issuer or processor, but funds are instead provided by the third party to the credit card issuer. The funds are then reimbursed by the agent to the third party in due course. The authorisation process can be used to ensure that only transactions from trustworthy agents are processed."(Board's emphasis)
In the Board's assessment, this means that the role of the third party is actually to guarantee the money vis-à-vis the credit card issuer. In other words, the third party is not only acting as the authorisation server, but also as a financial middleman between the agent and the credit card issuer/processor. It follows that, since the third party needs to recover the funds from the agent, it has to trust the agent. The description suggests that this idea allows a third party to offer a new type of financial service using existing point-of-sale systems (page 11, lines 2 and 3) without requiring a bank account (lines 16 and 17).
4. Inventive step
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. The failure to reflect all aspects of the business method in the problem to be solved led the examining division to argue unconvincingly that the inconvenient distinguishing feature of authorising the access terminal was an alternative whose choice was governed by unspecified business constraints.
4.3 Instead, 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.
4.4 Furthermore, as already concluded in point 2.4 above, the skilled person would have provided the terminal with a card reader for reading the card data.
4.5 Thus, the Board judges that subject-matter of claim 1 lacks an inventive step (Article 56 EPC).
For these reasons it is decided that:
The appeal is dismissed.