T 2040/14 (Providing prepaid gift cards to devices with or without NFC capability/ MasterCard International Incorporated) 12-02-2021

1. The invention

The invention concerns a method to enable users, referred to as senders, to purchase prepaid gift cards for the benefit of other "recipient" users (see originally filed application, page 2, lines 4 to 9; page 4, lines 22 to 26). A recipient obtaining a gift card is entitled to purchase goods to the amount associated with the card (page 10, lines 25 to 30 and page 11, lines 17 to 23).

A sender purchases a prepaid gift card from a card issuer. The issuer's system then provides the recipient's mobile phone with either a digital card, referred to as a soft card, which enables automatic wireless payments over an NFC connection, or an authorisation code entitling the recipient to receive a physical plastic card (page 4, lines 27 to 31). The type of card depends on whether the recipient's mobile phone has near field communication (NFC) capability or not (page 9, lines 9 to 14).

Looking at Figure 1, the functionality for purchasing and delivering prepaid gift cards is distributed among three servers: a merchant server 108, a telecommunications operations server 110 and an over-the-air server (OTA) provisioning server 112 (page 5, lines 15 to 17).

The merchant server hosts card generation functionality. Upon request, it provides to a sender's computer 104 a website to which the sender inputs information specifying a desired prepaid gift card including an amount of money to be placed on the card and a recipient's phone number (page 5, lines 1 to 10; page 12, lines 4 to 9). Based on this information, the merchant server generates prepaid card information including the card's number, its image, authorisation code and card personalisation information (page 8, lines 19 to 25; page 12, lines 18 to 25).

The OTA provisioning server is responsible for issuing soft cards and authorisation codes to recipients' mobile phones 114 and 116 (page 5, lines 24 to 29). The OTA provisioning server receives from the merchant server a request to issue a generated prepaid gift card. The request includes the recipient's mobile phone number and the prepaid card information (page 8, line 26 to 32 and page 12, line 26 to page 13, line 2). In order to determine whether a soft card or an authorisation code should be sent, the OTA provisioning server provides the telecommunications operations server with a recipient's mobile phone number and receives from it information indicating the mobile phone's type as NFC enabled or otherwise (page 9, lines 1 to 8). The telecommunications operations server, maintained by the wireless phone service provider, retrieves this information from a database associating mobile phone numbers with configuration information (page 9, lines 3 to 6).

If the recipient's mobile phone is not NFC enabled, the OTA provisioning server generates and sends it an SMS including a card authorisation code through an SMS gateway (page 13, lines 11 to 14). The recipient, having received the SMS, provides the authorisation code to a cashier at a point of sale. The cashier, having validated the code and the recipient's phone number, encodes the amount associated with the purchased gift card onto a plastic card and hands the plastic card over to the recipient who can subsequently use it for purchasing (page 11, lines 4 to 24).

If the mobile phone is NFC enabled, the OTA provisioning server establishes a secure connection with a prepaid card managing application, called wallet client, installed on the mobile phone and downloads soft card personalisation data, which is similar to Track 1 and Track 2 data of payment cards, onto the mobile phone (page 10, lines 4 to 11; page 14, lines 5 to 13).

2. Article 84 and 123(2) EPC

The Board is satisfied that the claims comply with the requirements of Articles 123(2) and 84 EPC.

3. Article 56 EPC, claim 1

3.1 For the purposes of assessing the disclosure of D2 claim 1 boils down to the following:

A sender device sends information about the desired card to a merchant server;

The merchant server sends an OTA provisioning request to an OTA provisioning server;

The OTA provisioning server asks a telecommunications operations server whether the recipient's device is NFC enabled;

If so, the card is provisioned on the mobile device over a communication link;

If not, a card authorisation code is send via SMS.

3.2 It is common ground that document D2 is the closest prior art and discloses a system for providing soft cards to mobile devices enabling wireless payments over an NFC connection.

3.3 The examining division considered that claim 1 differed from the embodiment shown in Figure 2 of D2 by (using their numbering at point 1 of the decision):

i/ii) The use of a merchant server;

iii) A telecommunications server determines whether the recipient's device is NFC enabled;

iv) The provisioning over the communication link is in response to determining that the device is NFC enabled;

v/vi/vii) Sending a card authorisation via SMS if the device is not NFC enabled;

viii) Receiving the purchase information from a sender device.

The division considered that the technical aspects of using SMS technology were commonplace. The remaining differences, in particular the use of a separate sender device, were considered to be obvious implementations of business-driven non-technical aspects.

3.4 In appeal, the Board considered that using separate sender and recipient devices was not just an incidental feature, but an essential feature of the invention which should be considered when determining the starting point for inventive step. Thus the Board preferred to start from the embodiment in D2 relating to WAP push provisioning of prepaid cards which deploys separate sender and recipient devices.

According to this embodiment, a user wishing to obtain a soft card corresponding to his plastic prepaid card, calls the card issuer by phone and provides a mobile phone number and the plastic card data ([57]). After validating the user's credentials, a provisioning issuer server, corresponding to the OTA server in claim 1, sends a WAP push message to the mobile phone ([59]). Having received the message, the mobile phone starts a provisioning and payment application installed on it ([59]). This application establishes a secure connection to the provisioning issuer server and the server downloads the soft card data to the mobile phone ([60] and [61]).

Starting from this embodiment, the sender device (feature viii, above) is no longer a distinguishing feature.

3.5 The Board judges that the background to this invention, namely that a delivered card is requested by one user for the benefit of another user, is a business aspect which is according to the COMVIK approach given to the skilled person as a non-technical requirement specification within the framework of the above objective technical problem.

It is probably also true that recognising that providing prepaid soft card personalisation data to mobile phones that can use it and providing authorisation codes to ones that cannot is also a non-technical aspect. This is in effect the situation in T 1503/12; granny would not send her grandson a Ybox game for his Xbox console - see points 4.6 and 4.7.

Thus, the technical problem is to implement the dual provisioning process on a user's mobile phone.

3.6 Although the Board considers that the second embodiment of D2 is a better starting point, in the end it does not really matter which embodiment one starts from. The Board agrees with the appellant and judges that the solutions of adapting D2 to use a telecommunications operations server to determine whether a mobile device is NFC enabled (feature iii, above) and to send a card authorisation via SMS if the device is not NFC enabled (features v/vi/vii, above) are not obvious over either embodiment.

3.7 It might well be obvious to check whether a mobile phone is NFC enabled in order to decide whether the soft card personalisation data or the card authorisation code should be provided.

However, the Board agrees with the appellant that the obvious solution would be to obtain this information from the provisioning and payment application which, if not already present, would need to be installed on the mobile phone. In fact, using this application for provisioning card data is the key aspect of D2's teaching ([11] and [23]).

3.8 The Board also agrees with the appellant that while D2 discloses a provisioning configuration server, storing configuration information for multiple card issuers ([26]), and implicitly that the push proxy gateway is used (see D12, points 5 and 6), there is no hint to adapt any of these servers to provide upon request information on whether a mobile phone is NFC enabled.

D2 discloses that the provisioning and payment application communicates with the provisioning configuration server to verify whether the mobile phone is authorised for obtaining soft card data ([42]). The Board agrees, however, with the appellant's reading of D2 and accepts that this step does not involve obtaining from the server information on the phone's hardware capabilities; the only information obtained is an indication that the phone was authorised for receiving soft card data.

Also, the general teaching in D12 that the push proxy gateway may be queried for capabilities of WAP clients (sections 6.6. and 7.2.6), is not a strong enough hint to obtain from the push gateway specific information concerning the phone's NFC capability.

3.9 As for providing the card authorisation code in an SMS, the Board judges that the skilled person would rather provide the code using the provisioning and payment application installed on the mobile phone in the NFC capability determination stage.

The Board considers that providing sensitive card data in an SMS instead of downloading it securely using the provisioning and payment application runs against the key teaching of D2 and the skilled person would not do it without a hint in prior art. However, D2 does not give such a hint and actually teaches away from the claimed solution. Paragraph [23] states that the provisioning and payment application's payment functionality is actually not essential for the disclosed subject-matter which rather relates to its provisioning functionality. The skilled person would derive from this that the authorisation code should be downloaded using the provisioning and payment application, even if it cannot be used for wireless payments.

4. For these reasons, the Board judges that the subject-matter of claim 1 involves an inventive step.

5. The subject-matter of claims 7 and 13 involves an inventive step for the same reasons.