T 0801/20 (NFC mobile wallet processing system/PAYPAL) 01-06-2023

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.