T 0801/20 (NFC mobile wallet processing system/PAYPAL) of 1.6.2023

Summary of Facts and Submissions

I. The appeal is against the examining division's decision to refuse the European patent application No. 15755379.3 for lack of inventive step (Article 56 EPC) over D1 (US 2013/311313 A1). The examining division held that the distinguishing features related to a non-technical method for making payments and that the implementation of this method in the system of D1 was straightforward.

II. 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 refused main or a new auxiliary request, both (re-)filed with the statement setting out the grounds of appeal. The auxiliary request essentially corresponded to the auxiliary request before the examining division. The appellant also requested oral proceedings if the Board was inclined to reject the main request.

III. In the communication accompanying the summons to oral proceedings, the Board set out its preliminary opinion that claim 1 of both requests did not involve an inventive step over D1.

IV. In a reply, the appellant informed the Board that it would not attend the oral proceedings and requested a decision based on the current state of the file. The Board thus cancelled the oral proceedings.

V. Claim 8 of the main request reads:

A method executed by a transaction management system, TMS, comprising:

receiving, from a mobile device operated by a user, a request to initiate transaction processing associated with a transaction involving said user; and

transmitting, to said mobile device, a checkout token for use with said transaction, said checkout token formatted for near field communication ("NFC") transmission from said mobile device to an NFC reader of a merchant system associated with said transaction;

creating a pending transaction record associated with the checkout token, which includes information identifying the user, in a transaction queue;

receiving, from said merchant system, a message containing (i) the checkout token received from the mobile device via an NFC communication session between the mobile device and the NFC reader, and (ii) details of a transaction involving said merchant and said user including a merchant identifier but not a transaction amount;

updating the pending transaction record with the details of the transaction by matching the message from the merchant and the pending transaction record using the checkout token;

transmitting payment accounts and information identifying the merchant for display by the mobile device;

receiving a transaction amount from said merchant system;

updating the pending transaction record using the transaction amount;

transmitting a message to the mobile device so that the display of the mobile device is updated to include the transaction amount as well as a list of available payment accounts that can be used in the transaction and information identifying the merchant;

receiving, from said mobile device, a transaction confirmation request message including a user selection of one of the available payment accounts; and

identifying, based on information from said transaction confirmation request message, an actual payment account corresponding to said user selection for use in completing said transaction.

VI. Claim 7 of the auxiliary request adds at the end of claim 8 of the main request "wherein said checkout token is or includes an identifier usable by said merchant system to route an authorization request message to at least one of said transaction management system and an entity associated with said transaction management system".

Reasons for the Decision

1. The invention

1.1 The invention concerns using near field communication (NFC) to make payments (page 1, third paragraph of the published application).

1.2 Looking at Figure 1, a user initiates a payment transaction by sending a transaction request from their NFC-enabled mobile device 102, such as a phone, to a transaction management system (TMS) 130. The TMS 130 then creates a pending transaction record and sends to the user's device an NFC-formatted transaction identifier ("checkout token"). The user passes the token to a merchant system 108, e.g. by tapping their phone on an NFC reader 104 (page 45, lines 4 to 25).

The merchant system 108 then submits a merchant transaction request to the TMS 130, which includes the checkout token and some transaction details. The TMS updates the pending transaction record and sends the transaction details to the user along with a list of available payment accounts from which the user can select. Once the TMS receives the user's selection, it completes the payment (page 45, line 22 to page 47, line 27).

1.3 An essential aspect of the claimed invention is that the merchant system transmits the transaction details to the TMS in two steps: the merchant's identifier is sent with the transaction request, while the transaction amount is sent later. This is because the transaction amount might not have been calculated yet when the merchant's transaction request is transmitted. The TMS also forwards the received pieces of transaction information to the user's mobile device in separate steps (page 38, line 19 to page 39, line 19).

2. Main request - inventive step

2.1 The examining division focused its assessment on independent method claim 8, and the Board sees no reason to depart from this choice.

2.2 It is common ground that claim 8 essentially differs from D1 in that:

(i) The merchant system transmits the transaction details to the TMS in two steps: first, it sends the merchant's identifier, and then the transaction amount. After each step, the TMS updates the pending transaction record and forwards the received information to the user.

(ii) The TMS sends a list of "available" payment accounts from which the user can select to complete the payment.

2.3 As regards feature (i), the appellant argued that an "amount" was technical as it represented a quantity. It was inconsistent to say that an amount was technical when it referred to a physical parameter, such as voltage, but non-technical when it referred to money. Furthermore, transmitting and receiving data to/from a device, as well as updating a data record, were all technical processes.

2.4 The Board notes that an amount is just a number and per se non-technical. Whether this number represents technical or non-technical data depends on the context. However, data alone - whether technical or not - does not convey technical character to the method that processes it. Method steps contribute to the technical character of the invention only if they contribute to the solution of a technical problem by providing a technical effect (e.g. T 154/04 - Estimating sales activity/DUNS LICENSING, point 20).

The technical effect achieved must go beyond the normal effects of implementing something on a computer (see e.g. G 3/08 - Programs for computers, point 13.5). In the Board's judgement, however, the receiving, transmitting and updating steps in claim 8 do not achieve such a further technical effect.

2.5 The appellant further argued that the two-step transmission and display of transaction details enabled the user to verify the merchant's identity while waiting for the transaction amount to be determined. Receiving transaction information piece by piece was easier for the user to process, saved time and reduced latency.

2.6 The Board does not find this argument convincing. Displaying information piece by piece or all at once is a matter of user preference. Some users may prefer to receive the merchant details in advance, others may prefer to see all relevant information together. Even if a user receives the merchant's identity beforehand, they may still choose to wait until all transaction details arrive before reviewing them. Thus, any effect the displayed information might have depends on the user and the user's reaction to this information. Such indirect effects cannot be considered when assessing inventive step (see e.g. T 1670/07 - Shopping with mobile device/NOKIA, point 11). Although displaying information piece by piece may make it easier to evaluate and, hence, lower the user's cognitive burden, this is not a technical effect (see e.g. T 1741/08 - GUI layout/SAP, point 2.1.6).

2.7 As regards feature (ii), the appellant argued that by providing a list of accounts that were suitable for the transaction, the system required less bandwidth and computing resources. This was because, on the one hand, non-usable accounts were not transmitted, and, on the other hand, the system did not have to process non-viable account selections.

2.8 The Board is not convinced that the effects identified by the appellant are achieved. According to the claim, the TMS transmits payment accounts to the user's mobile device twice: first, it transmits some unspecified payment accounts, and then, it transmits "a list of available payment accounts that can be used in the transaction". This double transmission is less efficient in terms of bandwidth and computing resources compared to transmitting all accounts once. Furthermore, the term "available" is too broad and unspecific to exclude any particular type of accounts.

In any case, the Board considers that it is a self-evident user requirement to restrict the selection to accounts that are suitable for the transaction at hand, for example, because they have enough money to cover the transaction amount or because they are accepted by the merchant.

2.9 For the reasons above, the Board considers that features (i) and (ii) define non-technical user requirements. Following the COMVIK approach (T 641/00 - Two identities/COMVIK, headnote 2), the objective technical problem can thus be formulated as how to implement these requirements in the system of D1. The claimed implementation is a straightforward automation that would be obvious to the person skilled in the art.

2.10 Accordingly, claim 8 of the main request does not involve an inventive step (Article 56 EPC).

3. Auxiliary request - inventive step

3.1 Claim 7 of the auxiliary request adds to claim 8 of the main request that the checkout token is or includes an identifier usable by the merchant system to route an authorisation request message to the transaction management system or an entity associated with it.

3.2 The Board agrees with the examining division that for the merchant system to send a message to the TMS, it must be able to identify that system. Hence, it is implicit in D1 that the merchant system receives an identifier usable to route the message to the TMS. Including this identifier as part of the checkout token is, in the Board's view, one of several obvious possibilities to send the identifier to the merchant.

3.3 The appellant argued that "packaging this information as a token can make the transaction more secure, by ensuring that the information to be transmitted is encapsulated and sent as a single entity".

The appellant, however, has not elaborated on this security effect and the Board cannot see why sending information as a single entity would be more secure than splitting up this information and sending it in several pieces.

3.4 Accordingly, claim 7 of the auxiliary request does not involve an inventive step (Article 56 EPC).

4. Since none of the requests on file is allowable, the appeal must be dismissed.

Order

For these reasons it is decided that:

The appeal is dismissed.