T 2040/14 (Providing prepaid gift cards to devices with or without NFC … of 12.2.2021

Summary of Facts and Submissions

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

II. The examining division found that the subject-matter of claim 1 of the main, and first and fourth auxiliary requests did not involve an inventive step over D2 (US-A-2008/0058014) combined with common general knowledge concerning SMS technology. The subject-matter of the second and third auxiliary requests did not involve an inventive step over the combination of D2 and D11 (US-A-2007/0087765).

III. In the statement setting out the grounds of appeal, the appellant requested that the decision be set aside and a patent be granted on the basis of the main or first to fourth auxiliary requests filed therewith. The main request corresponded to the refused main request. The auxiliary requests essentially corresponded to the refused auxiliary requests. The appellant also requested oral proceedings.

IV. In the communication accompanying the summons to oral proceedings, the Board expressed the preliminary view that none of the requests met the requirements of Article 56 EPC and that the third auxiliary request contained added subject-matter. The Board introduced the background document D12 (XP064121405) into the proceedings.

V. With a reply to the summons, the appellant filed a new third auxiliary request.

VI. During the oral proceedings before the Board, which took place by videoconference, the appellant filed a new main request replacing all the requests on file.

VII. The appellant's final requests were that the decision under appeal be set aside and a patent be granted on the basis of the set of claims filed as the final main request and the amended description filed during the oral proceedings before the Board.

VIII. Claim 1 reads:

A method for electronically delivering a prepaid card to a mobile device (114,116), the method comprising:

receiving, at a merchant server (108) from a sender device (102, 104, 106), purchase information related to the purchase of an electronic prepaid card, wherein the purchase information includes recipient information associated with a mobile device (114, 116) intended to receive the electronic prepaid card;

receiving, at an over the air (OTA) provisioning server (112) and from the merchant server (108), a provisioning request including electronic prepaid card information derived from the purchase information;

requesting, at the OTA provisioning server (112) and from a telecommunications operations server (110), the type of mobile device (114, 116) associated with the recipients mobile device number;

determining, using the mobile device type information provided by the telecommunications operations server (110), whether the mobile device (114, 116) is near field communications (NFC) enabled;

in response to determining that the mobile device (114,116) is NFC enabled:

establishing a communications link with a mobile device (114) associated with address data included in the electronic prepaid card information; and

provisioning the electronic prepaid card information on the mobile device (114) over the communications link via OTA communications, wherein the electronic prepaid card information includes personalization data that is used to generate a softcard prepaid card in the NFC enabled mobile device (114) and is transferrable from the mobile device (114) to a wireless device reader (118) via NFC; and

in response to determining that the mobile device (114,116) is not NFC enabled:

sending a prepaid card authorization code associated with the electronic prepaid card to a short message service (SMS) gateway (113); and

sending the prepaid card authorization code from the SMS gateway (113) to the non-NFC enabled mobile device (116).

IX. Claim 7 reads:

A system (100) for electronically delivering a prepaid card to a mobile device (114, 116), the system comprising:

a merchant server (108) for receiving purchase information from a sender device (102, 104, 106) related to the purchase of an electronic prepaid card and generating electronic prepaid card information, wherein the purchase information includes recipient information associated with a mobile device (114, 116) intended to receive the electronic prepaid card; and

an over the air (OTA) provisioning server (112) for receiving the electronic prepaid card information from the merchant server, communicating with a telecommunications operations server (110) to determine whether the mobile device (114, 116) associated with the recipients mobile device number is near field communications (NFC) enabled, and, in response to determining that the mobile device (114,116) is NFC enabled, establishing a communications link with a mobile device (114) associated with address data included in the prepaid card information, and provisioning the electronic prepaid card information on the mobile device (114) over the communications link via OTA communications, wherein the electronic prepaid card information includes personalization data that is used to generate a softcard prepaid card in the NFC enabled mobile device (114) and is transferrable from the mobile device (114) to a wireless device reader (118) via NFC)[sic] and, in response to determining that the mobile device (114, 116) is not NFC enabled, sending a prepaid card 5 authorization code associated with the electronic prepaid card to a short message service (SMS) gateway (113) and sending the prepaid card authorization code from the SMS gateway (113) to the non-NFC enabled mobile device (116).

X. Claim 13 reads:

A computer readable medium having stored thereon comprising[sic] computer executable instructions that when executed by a processor of a computer performing the method of any of claims 1 to 6.

XI. The appellant argued as follows.

In D2 the user requested that a soft card be provided to his own mobile phone. Since the user knew whether his phone was NFC enabled, there was no need for automatic determination of NFC capability. However, even assuming that the skilled person starting from D2 faced the problem of providing a prepaid card to a mobile phone of unknown type, he would not find in D2 any hints to request the information on the phone type as NFC enabled or otherwise from a server. Neither would he find hints to provide a card authorisation code in an SMS.

D2 taught that soft cards were provided to a mobile phone using a provisioning and payment application. Since the application was a prerequisite for launching the provisioning process, the skilled person would install it on the mobile phone, if not already present. The installed application would determine the mobile device's NFC capability and provide it to the card issuing system.

Unlike the above solution, requesting the information on the phone's NFC capability from a server was not obvious. D2 did not provide any teaching concerning checking mobile devices' hardware capabilities, let alone server-side checking of such capabilities. While D2 disclosed that the provisioning and payment application communicated with a provisioning configuration server to determine whether the mobile phone was authorised for receiving soft card data, this step did not involve checking the phone's hardware capabilities.

Furthermore, while sections 6.6 and 7.2.6 of D12 showed that the WAP push protocol envisaged quering for WAP clients' hardware capabilities, the WAP push framework did not contain a comprehensive database of hardware capabilities which could be used to provide information on NFC capabilities in the required manner.

Reasons for the Decision

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.

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 the order to grant a patent on the basis of the following documents:

- Claims 1 to 13 filed as the final main request during the oral proceedings before the Board,

- Description pages 1 to 15 (clean version) filed during the oral proceedings before the Board,

- Drawings as published.