T 1392/20 (User device configured to function as PoS terminal/HILLOA) of 15.7.2025

Summary of Facts and Submissions

I. This appeal is against the examining division's decision to refuse European patent application No. 15714898.2 for lack of inventive step (Article 56 EPC).

II. The examining division held the subject-matter of claim 1 of all requests to be obvious in view of the skilled person's common general knowledge, illustrated inter alia by the following document:

D4: Keith Mayes ET AL: "Smart Cards, Tokens, Security and Applications", 7 January 2008 (2008-01-07), Springer US, XP055500061, ISBN 978-0-387-72197-2.

III. In the statement of grounds of appeal, the appellant requested that the decision be set aside and a patent be granted on the basis of the refused main request or one of the refused first to third auxiliary requests.

IV. In a communication under Rule 100(2) EPC, the Board expressed its preliminary view that claim 1 of none of the requests appeared to involve an inventive step over D4.

V. By letter of 30 November 2023, the appellant filed a new first auxiliary request, renumbered the previous auxiliary requests, and submitted arguments in support of inventive step.

VI. In the communication accompanying the summons to oral proceedings, the Board maintained its preliminary opinion on lack of inventive step.

VII. During the oral proceedings, the appellant filed a new main request with amended claims 1 and 14. This request was subsequently replaced at 13:20 hours by a further main request, which amended dependent claim 8 and deleted independent method claim 14. All previous requests were withdrawn.

VIII. Claim 1 of the sole request reads:

A remote transaction processing system including plurality of user devices, a payment service host, and a first data store, the first data store including a user device profile for each of the plurality of user devices, each user device profile including routing data for routing communications to the respective user device;

the payment service host being arranged to receive payment requests for each of a plurality of merchants for payment for a transaction initiated at their respective merchant website,

wherein, upon receiving a payment request designating a user device for a transaction with one of the merchants, the payment service host is arranged to retrieve a Point-of-Sale, PoS, configuration profile corresponding to the merchant and retrieve the user device profile from the first data store corresponding to the designated user device, the payment service host being arranged to communicate a PoS configuration dependent on the PoS configuration profile and on payment information on the transaction including the amount to the user device in dependence on the routing data,

the user device including a secure element in which a PoS terminal application is executed and a payment card reader, the user device being arranged to receive the PoS configuration for the transaction with the merchant, configure the PoS terminal application in dependence on the PoS configuration and to communicate with a payment card via the payment card reader for payment of the transaction with the PoS terminal application to thereby act as the merchant's PoS terminal on the user device for the transaction with the merchant and complete a payment transaction, whereby the payment transaction is sent back to the payment service host.

Reasons for the Decision

1. The invention

1.1 The invention concerns online payments ([0001] of the published application).

1.2 Typically, when making online payments, customers are required to provide their payment card data to the merchant, which poses a risk of fraud. On the one hand, customers may use stolen card data, which is a risk for the merchant. On the other hand, dishonest merchants may misuse the card data, which is a risk for the customer, [0003], [0004]. To address these issues, the invention suggests configuring a user device, such as a smartphone, to function as the merchant's point-of-sale (PoS) terminal.

1.3 Looking at Figure 5 or 6, a user initiates (2) a payment transaction at a merchant's website by providing an identifier of their user device. The merchant forwards (3) the identifier to a payment service host operated for example by an acquiring bank. The host retrieves a PoS configuration profile specific to the merchant and sends (4) a corresponding PoS configuration to the user device based on routing data stored in a user device profile. The user device configures a payment application according to the received PoS configuration and reads (5) a payment card using a card reader before processing the transaction, [0051] to [0056] and [0091] to [0099].

2. Admittance, Article 13(2) RPBA

2.1 The Board admitted the new request into the proceedings under Article 13(2) RPBA, as it found that exceptional circumstances were present.

2.2 These arose from the inventive step reasoning in the decision under appeal. The examining division relied on the skilled person's common general knowledge in the field of NFC-enabled mobile phones, with eight documents cited merely as illustrative examples. However, the use of vague terms like "standard NFC payment" and "standard OTA", along with broad references to entire chapters or sections, made it difficult for both the appellant and the Board to understand what the examining division actually considered to form part of this common knowledge and how it mapped to the claim features. As a result, a meaningful discussion on inventive step was only possible during the oral proceedings before the Board. The inventive step and clarity objections raised at that stage directly triggered the filing of the new request.

2.3 In the Board's view, these are cogent reasons justifying the existence of exceptional circumstances within the meaning of Article 13(2) RPBA.

3. Amendments, Article 123(2) EPC

3.1 The amendments in claim 1 are supported by the application as filed, for example paragraphs [0020], [0022], [0023], [0044], [0064], and [0071]. The amendment introduced on appeal, concerning the completion of a payment transaction and its transmission to the payment service host, finds basis in paragraphs [0056], [0086], and [0106].

3.2 Accordingly, the requirements of Article 123(2) EPC are fulfilled.

4. Inventive step, Article 56 EPC

4.1 The Board considers that, among the documents cited in the appealed decision, D4 represents the closest prior art, as it is the only document that suggests using a user device, namely the user's mobile phone, as a card reader in the context of online transactions, with the aim of addressing the typical problems associated with card-not-present payments (see sections 5.4 to 5.6, in particular page 132).

4.2 However, unlike claim 1, the user's phone in D4 functions as a token reader: during a transaction on the merchant's website, the user is prompted to present their card to the phone, which reads the card and generates a dynamic code. This code must then be manually entered by the user into the website, which forwards it to a verification host (corresponding to the claimed payment service host) for authentication (see Figure 5.6). In other words, the phone supports user/card authentication, but does not act as a Point-of-Sale (PoS) terminal capable of completing the payment transaction by directly communicating with the payment service host.

4.3 Accordingly, claim 1 differs in that:

1) The payment service host receives a payment request identifying a specific user device for a transaction with the merchant and retrieves a corresponding user device profile, which includes routing data for communication with that device.

2) The payment service host retrieves a PoS configuration profile associated with the merchant and sends a corresponding PoS configuration to the user device based on the routing data.

3) The user device configures a PoS terminal application within a secure element based on the received PoS configuration, enabling it to act as the merchant's PoS terminal and complete the payment transaction by communicating directly with the payment service host.

4.4 The examining division considered the PoS configuration profile to represent a set of business rules or preferences defined by the merchant. They also held that deploying such preferences to the user device as in features 1) to 3) was a straightforward implementation of a non-technical business requirement on a generally known payment system architecture.

4.5 The Board takes a different view. While the abstract goal of avoiding the transmission of card data to the merchant may come from the business person, features 1) to 3) define a specific technical solution for achieving it. In particular, the payment service host is configured to retrieve a PoS configuration associated with the merchant and to send it to the user device, which then configures a secure application accordingly. This enables the user device to read card data and communicate directly with the payment service host to complete the transaction.

These steps involve modifying the existing system infrastructure, including how the user device is configured and integrated into the payment flow. Such changes require technical knowledge of the system architecture and fall within the expertise of the technically skilled person - not the business person, who may define the desired business objective but lacks the competence to specify the structural and functional changes needed to implement it (T 1463/11 - Universal merchant platform/CardinalCommerce, T 1749/14 - Mobile personal point-of-sale terminal/MAXIM, point 5).

The Board therefore concludes that features 1) to 3) contribute to the technical character of the invention and must be assessed for obviousness in light of the prior art.

4.6 The appellant argued that features 1) to 3) enhanced security by ensuring that the card data was sent directly from the user device to the payment service host, thereby bypassing the merchant.

The Board is not convinced that this results in a security advantage over D4. In D4, a unique dynamic code is generated from the card data by a cryptographic module for each transaction (see sections 5.5 and 5.6 of D4). Since the merchant receives only this code, the card data likewise remain protected from the merchant.

4.7 Thus, features 1) to 3) rather provide an alternative online transaction system in which the user's payment card data are not shared with the merchant.

Starting from D4, the Board does not see how the skilled person would arrive at the solution of claim 1. While the Board agrees with the examining division that the remote provisioning of software on user devices was generally known at the priority date, there is no apparent reason, except in hindsight, to change the user device's functionality so that it acts as a PoS terminal directly completing the transaction.

For these reasons, the Board judges that claim 1 involves an inventive step over D4.

4.8 For completeness, the Board notes that none of the other documents cited in the appealed decision suggest configuring a user device to act as the merchant's PoS terminal. Therefore, claim 1 is inventive also over these documents.

5. Accordingly, the Board concludes that claim 1 of the main request involves an inventive step (Article 56 EPC).

Order

For these reasons it is decided that:

1. The decision under appeal is set aside.

2. The case is remitted to the examining division with an order to grant a patent on the basis of:

- claims 1 to 13 of the main request, filed at 13:20 hours at the oral proceedings on 15 July 2025,

- description and drawings to be adapted.