WO2009112793A1 - Mobile payments - Google Patents

Mobile payments Download PDF

Info

Publication number
WO2009112793A1
WO2009112793A1 PCT/GB2009/000135 GB2009000135W WO2009112793A1 WO 2009112793 A1 WO2009112793 A1 WO 2009112793A1 GB 2009000135 W GB2009000135 W GB 2009000135W WO 2009112793 A1 WO2009112793 A1 WO 2009112793A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
payment
mobile terminal
unique identifier
payment token
server
Prior art date
Application number
PCT/GB2009/000135
Other languages
French (fr)
Inventor
Gerard Sherlock
John David Richard Pilkington
Paul Anthony Putland
Original Assignee
British Telecommunications Public Limited Company
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06QDATA PROCESSING SYSTEMS OR METHODS, SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL, SUPERVISORY OR FORECASTING PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Use of an alias or a single-use code

Abstract

A system for generating a payment token for conducting payments using a mobile terminal, said system comprising an application server and a payment server, said mobile terminal comprising an identity module, and wherein the application server is adapted for receiving at an application server a registration message, said first message comprising a telephone number associated with the identity module, for generating a unique identifier and storing the unique identifier with the telephone number, and for sending the unique identifier to the mobile terminal; the mobile terminal is adapted to generate and store a datablock comprising the unique identifier, and the datablock is secured using the subscriber identity associated with the identity module and a terminal identifier associated with the mobile terminal; and the payment server is adapted to validate a request for a payment token from the mobile terminal based on the unique identifier contained in the request, wherein the unique identifier is retrieved from the datablock stored in the mobile terminal.

Description

MOBILE PAYMENTS

Field of the Invention

This invention relates to a method of generating a payment token for payment transactions, in particular a method of generating a payment token for use by a mobile terminal, wherein the payment token is based on a generated unique identifier associated with the mobile terminal.

Background to the Invention

The credit and banking industry today is looking to exploit the near ubiquity of the mobile phone so that it might be used to make payments, typically for items having a small value such as at newsagents or at a vending machine. One method envisaged for making such a payment is through the use of "Near Field Communications" (NFC) payment systems. NFC is a short-range wireless communication technology that enables data to be exchanged between compatible devices over a short distance (about a decimetre). The technology is related to proximity-card and RFID technology.

In an NFC enabled mobile phone, a payment application is linked to a radio transmitter in the device, which enables small purchases to be made simply by passing the mobile phone in close proximity to an NFC payment terminal, such as a vending machine or other payment point.

The technology now being used in the UK for most credit card transactions is based on the smartcard technology commonly referred to as "Chip and PIN". This technology is used in many European countries, though other markets like the US may differ somewhat. In order for NFC to be used effectively for payments, the Chip and PIN would need to be adhered to. An NFC based transaction would be regarded as an off-line Chip and PIN transaction. Off-line transactions are usually limited both in value as well as in the number that can be made in succession. Typically, once a user has completed say five transactions "off-line", the card is required to make a standard Chip, and PIN payment where the PIN is entered in order to reset a counter on the card. While imposing this transaction limit is useful as a method of fraud protection, it also has a negative impact on the use of a mobile phone for contact-less payment applications using NFC. As the mobile phone cannot be used for a standard Chip & PIN transaction as it does not have a Chip and PIN smartcard, there is no existing way to reset the counters used for fraud management.

Summary of the Invention

It is the aim of embodiments of the present invention to solve some of the above problems and provide an improved payment system for mobile devices.

According to one aspect of the present invention, there is provided a method of generating a payment token for conducting payments using a mobile terminal, wherein said mobile terminal comprises an identity module, said method comprising the steps of: a) receiving at an application server a registration message, said first message comprising a telephone number associated with the identity module; b) generating by the application server a unique identifier and storing the unique identifier with the telephone number; c) sending the unique identifier to the mobile terminal, wherein the mobile terminal generates and stores a datablock comprising the unique identifier, and the datablock is secured using the subscriber identity associated with the identity module and a terminal identifier associated with the mobile terminal; and subsequently d) validating by a payment server a request for a payment token from the mobile terminal based on the unique identifier contained in the request, wherein the unique identifier is retrieved from the datablock stored in the mobile terminal.

Preferably, the method further comprises: e) using the unique identifier from the request to identify the telephone number associated therewith based on the unique identifier and telephone number stored by the application server. The method may also comprise generating a payment token and associating and storing the payment token with a user account at the payment server, wherein the user account comprises the telephone number of the mobile terminal.

The generated payment token may be transmitted by the payment server to the mobile .terminal, and the mobile terminal may store the payment token securely using the unique identifier.

Furthermore, the payment token may be used by the mobile terminal to conduct a contactless payment transaction with a point of sale terminal, said method further comprising transmitting the payment token to the point of sale terminal and onto the payment server, wherein upon receipt at the payment server, the payment token is validated by cross checking against the payment token stored with the user account at the payment server.

Preferably, the payment token is only valid for a fixed period of time following generation by the payment server. The payment token may also be valid for a predetermined number of contactless payment transactions only. Alternatively, the payment token is only valid for a predetermined total transaction amount.

The mobile terminal can make a request for a new payment token from the payment server, wherein said request comprising the unique identifier for identifying the mobile terminal.

According to a second aspect of the present invention, there is provided a system for generating a payment token for conducting payments using a mobile terminal, said system comprising an application server and a payment server, said mobile terminal comprising an identity module, and wherein the application server is adapted for receiving at an application server a registration message, said first message comprising a telephone number associated with the identity module, for generating a unique identifier and storing the unique identifier with the telephone number, and for sending the unique identifier to the mobile terminal; the mobile terminal is adapted to generate and store a datablock comprising the unique identifier, and the datablock is secured using the subscriber identity associated with the identity module and a terminal identifier associated with the mobile terminal; and the payment server is adapted to validate a request for a payment token from the mobile terminal based on the unique identifier contained in the request, wherein the unique identifier is retrieved from the datablock stored in the mobile terminal.

Brief Description of the Drawings

For a better understanding of the present invention reference will now be made by way of example only to the accompanying drawings, in which:

Figure 1 is a network diagram of an arrangement in an example of the present invention;

Figure 2 is a message flow diagram illustrating a registration and payment token request process in an example of the present invention;

Figure 3 is a message flow diagram illustrating the use of a payment token for conducting a transaction in an example of the present invention.

Description of Preferred Embodiments

The present invention is described herein with reference to particular examples. The invention is not, however, limited to such examples.

Figure 1 illustrates a network 100 comprising a mobile terminal 102, a mobile network 112, an SMS gateway 1 16, a profile store 124, an application server 120, a payment server 126 and a point of sale (POS) terminal 128. The mobile terminal 102 may a mobile phone, smartphone, PDA or similar. The mobile terminal 102 can communicate with the mobile network 1 12 over communications link 110, which is a radio link in this example where the mobile network 1 12 is GSM, UMTS or similar cellular mobile network. For simplicity, individual components of the mobile network 1 12, such as base stations and gateways, have been omitted. In this example, the mobile network 112 is the home mobile network associated with the SIM 106 and mobile terminal 102.

The mobile terminal 102 includes a processor 104, which is used to control the operation of the device. The mobile terminal 102 also contains a data store 108, which can be used to store data such as phone numbers, photos and videos, as well as applications that can be run by the processor 104. The subscriber identity module (SIM) 106 in the mobile terminal 102 holds subscriber information, such as the international mobile subscriber identity (IMSI) which uniquely identifies the subscriber/user to the network. The mobile terminal 102 also has an associated international mobile equipment identity (IMEI), which is akin to a serial number for the device. The mobile terminal 102 also includes a near field communication (NFC) module 109, which provides the mobile terminal 102 with near field communication capabilities.

The mobile network 1 12 can communicate with the SMS gateway 116 over a fixed network connection 1 14. Similarly, the mobile network 1 12 can communicate with the application server 120 over a fixed network connection 122. The SMS gateway 1 16 and the application server 120 can also communicate with each other over a fixed network connection 1 18.

In this example, the SMS gateway 1 16 is operated by a third party and is able to receive and send SMS messages to the mobile network 1 12. The SMS gateway 1 16 effectively acts as an aggregator for SMS messages to and from the mobile network 112 (illustrated) and other mobile networks (not illustrated). Whilst not illustrated in Figure 1 , the mobile network 1 12 includes an SMS centre (SMSC), which is the interface between the SMS gateway 1 16 and the mobile network 112. Communications between the mobile terminal 102 and the mobile network 1 12 and within the mobile network 112 are inherently secure due to the security requirements under the GSM standards.

The application server 120 is also operated by a third party, which may or may not be the same as the operator of the SMS gateway 116, and can provide applications and services to the mobile terminal 102. At least some of these applications require the user to register the application before subsequent use of it. Services provided can include registration services, the operation of which will be described herein below.

Connected to the application server 120 is a profile store 124. The profile store 124 stores user profile information, such as identification numbers associated with the mobile terminal 102.

The network 100 also includes a payment server 126 connected to the mobile network 112. The payment server 126 is responsible for handling payment transactions conducted by the mobile terminal 102. A point of sale (POS) terminal 128 is also connected to the payment server 126. The POS terminal 128 and payment server 126 are connected over a suitable network connection, such as a private IP network.

The NFC module 109 in the mobile terminal 102 can communicate with the POS terminal 128 over short distances wirelessly, and can be used to conduct payment transactions assisted by a suitable application on the mobile terminal 102. For example, a user can make a purchase, and instead of using cash or a credit card to pay for the purchase, the payment can be made using the mobile terminal 102 in conjunction with the POS terminal 128.

The specific operation of the elements in Figure 1 in relation to supporting payment transactions between the mobile terminal 102 and the POS terminal 128 will now be described in more detail below with reference to the message flow diagrams of Figure 2 and 3. References in Figures 2 and 3 to the elements found in Figure 1 are made using like reference numerals.

Figure 2 illustrates the registration process for a payment application and subsequent obtaining of a payment token.

In step 200, the user equipment 102 already has an application installed in its memory 108. In this example, the application is a payment application that is capable of operating with the NFC module 109 to provide contactless payment functionality.

The application can be provided in a number of different ways such as by downloading by the user or it can be preloaded on the device. One method of downloading the application is by texting a short code (a form of SMS message) from the mobile terminal 102 to a third party for the chosen service. This is received by the mobile network 1 12, which routes it to the relevant SMS gateway 120 for processing. The SMS gateway 120 processes the message and sends a WAP push message back to the mobile terminal 102. The WAP push message starts the web browser on the mobile terminal 102 directing the user to an appropriate application server for downloading the application.

Once the application is downloaded and installed on the mobile terminal 102, the user has to set-up an account and payment details with the payment server 126, and also has to register the application with the application server 120.

The account set-up in step 202 links the mobile terminal 102 to a user account that can be used to clear payments accrued by the payment application and associated NFC module 109. One way of setting up an account is for: the user to utilise the mobile terminal 102 or a PC to access a (secure) web portal associated with the payment server 16, where the user inputs various personal details such as name and address, as well as payment details such as credit card details, and also the mobile phone number (or MSISDN) of the mobile terminal 102 that the user intends to use for payments. These user details are stored by the payment server 126.

Aside from using a secure connection to the web portal, such as using a HTTPS connection, other security measures could be included. One such measure is to validate that the mobile terminal 102 details (the mobile number or MSISDN) being registered does belong to the user setting up the account. This can be done by sending a PIN to the mobile number provided in the account set up, and requiring that the PIN be input back into the account set-up process in order for the set up to be successful. Whilst the account set up has been described as a separate process that occurs after the payment application has been installed, in a further example, the payment application can instead be downloaded to the mobile terminal 102 following successful account set up. For example, the payment server can trigger the download of the payment application to the mobile terminal 102 specified during the account set up process.

After the payment application has been downloaded and stored on the mobile terminal 102, it is registered by the user. To register the payment application, the user first confirms various terms and conditions upon starting up the application for the first time. The payment application then generates a formatted SMS message containing details associated with the payment application being registered. The details may for example contain text to indicate that this is a first registration and an identifier for the application, version number etc. The SMS message is sent by the user equipment 102 to a short code number or similar number corresponding to the application server 124 in step 204.

The SMS message is transmitted via the mobile network 1 12 and SMS gateway 1 16 (not shown in Figure 2) to the application server 120. The mobile network 1 12 identifies the originator, the mobile terminal 102, of the SMS registration message and forwards the SMS message onto the SMS gateway 120. The SMS message forwarded, now includes the telephone number associated with the user equipment 102 added by the mobile network. This telephone number is more commonly referred to as the mobile subscriber ISDN (MSISDN) number. The MSISDN is added to the SMS message before it is forwarded to the application server 120 via the SMS gateway 1 16.

The application server 120 receives the SMS message and generates a unique user identifier, and stores it with the MSISDN received in the SMS in step 206. In a preferred example, the unique user identifier is a Universally Unique Identifier (UUID), through other similarly unique identifiers may be used. The UUID specification is described in more detail in RFC 4122. The UUID and MSISDN can be stored as a user profile at the profile store 124 as shown in step 207 and storage is confirmed in step 208. In a further example of the invention, the user profile containing the UUID and MSISDN may be sent in step 207a to the payment server 128 where it is stored locally for later use in payment processing. The operation of both arrangements where the user profile is saved at the profile store 124 and at the payment server 128 are described later herein below.

Once the user UUID and MSISDN have been stored, the application server 120 can encode the UUID into a text block. The UUID may be encrypted using a strong encryption method, where a unique key is used. The key is composed of hashing the MSISDN with a pseudo random generated number. The text block is preferably no more than 160 characters in length to match the size of an SMS message, though could be more than 160 characters. The encoded text block is sent as an SMS message back to the mobile terminal 102 by the application server 120 via the mobile network 112 in step 210.

The application server 120 uses the MSISDN obtained from the registration message in step 204 to send the text block back to the mobile terminal 102. This step enables the originating mobile terminal 102 to be verified as being genuine and avoid the situation where the user sends a registration SMS message with a tampered MSISDN, IMSI or similar to deceive the system. By using the present method, the mobile network 112 will ensure that the response is directed to the correct mobile terminal 102 associated with the MSISDN.

The mobile terminal 102 then decodes the received text block using the application to extract the UUID in step 212. The application remains running after the sending of the registration SMS in step 202 and waits for this return SMS from the application server 120. The application has a reverse algorithm for decoding the text block if it has been encoded. The application then stores the extracted UUID in a data block, which can be encrypted, in the memory 108 together the IMSI of the SIM 106 and the IMEI of the mobile terminal 102. The application includes an interface or similar that allows the application to interrogate the SIM 106 and the mobile terminal 102 for the IMSI and the IMEI respectively.

The registration process is now complete and the payment application can now use the UUID to obtain payment tokens from the payment server 128. The payment tokens are used to conduct payment transactions with the POS terminal 128 using the NFC module 109.

In step 214, the payment application makes a request for a payment token from the payment server 126. The request is made over a secure connection such as a HTTPS connection using SSL. The request for a payment token includes the

UUID stored on the mobile terminal 102. The request can be made automatically by the payment application if the payment application does not already have a valid payment token, which includes when the payment application is first initiated. Alternatively, the user can use the payment application to request a new payment token at any stage.

When the payment server 126 receives the request, it uses the UUID provided, as a way of determining the authenticity and identity of the mobile terminal 102 making the request. In step 216, the UUID is compared to the UUID stored in the user profiles at the payment server 126 as a result of step 207a. Alternatively, if the payment server 126 does not have locally stored copies of user profiles, then a request is made to the profile store 124 in step 217, and the profile store 124 checks the UUID against the stored profiles and returns the MSISDN associated with the UUID in step 218. If the test on the UUID fails at any stage (UUID not found), then the payment token request is rejected, and a message can be sent back to the mobile terminal 102 to re-register the payment application in order to obtain a new UUID (steps 204 to 212).

Once the payment server 126 has the MSISDN of the mobile terminal 102, further checks can be made before a payment token is issued. For example, a check can be made against the account set up in step 202 to determine if the account is not blocked, has sufficient credit, or whether the credit card details are still valid. If the required tests are passed, then the payment server 126 can generate and store a payment token in step 220. Like the UUID tests, if any of the payment tests fail, then a message can be sent back to the mobile terminal 102 to perform the account set-up again (step 202).

The precise format of the payment token is not explored in detail here. However, the payment token is used for completing payment transactions by ensuring the authenticity of the user and for guaranteeing payment for the transaction. The payment token may be a unique alphanumeric string, code block or similar, and may also be encrypted to prevent tampering. Preferably, the payment token is stored against the account details, including the MSISDN, associated with the mobile terminal 102.

The payment token is then sent by the payment server 126 to the mobile terminal 102 in step 222 over the same secure connection. The payment token is stored by the payment application together the IMSI of the SIM 106 and the IMEI of the mobile terminal 102. The payment token is preferably encrypted using the IMSI and/or IMEI to ensure that if the SIM is swapped or the mobile terminal 102 is tampered with, then the clear payment token cannot be obtained. This prevents fraudulent use of the payment application, for example should the mobile terminal 102 be lost and the (blocked) SIM swapped for another SIM, the IMSI of the new SIM would not match that used to encrypt the payment token. In a further example, the payment token could be secured more simply by the payment application requiring that the correct IMSI and/or IMEI to be present before the payment token is released for use.

Alternatively, the payment token is secured using the UUID instead of the IMSI/IMEI. Thus, only a correctly validated UUID is required for obtaining the clear payment token. The payment token would thus be either encrypted using the UUID or simply stored/associated with the UUID.

Figure 3 illustrates the use of the payment token for a contactless payment between the mobile terminal 102 and the POS terminal 128. When the user makes a purchase, the user places the mobile terminal 102 near the POS terminal 128 to initiate a contactless transaction. The NFC module 109 allows the mobile terminal 102 to communicate using radio frequencies with the POS terminal 128 over short ranges. Thus, in step 300 when a payment is to be made, for example following a purchase of some goods, the POS terminal 128 is activated and the user places the mobile terminal 102 near the POS terminal 128 to initiate payment. An RF communication link between the two devices is established, which triggers the payment application in the mobile terminal 102 to proceed with conducting the transaction.

Several tests are preferably performed first to ensure that neither the SIM nor the mobile terminal 102 has changed since the initial registration. This may occur if the SIM 106 has been replaced, either genuinely by the user if a new SIM has been issued, or fraudulently if the mobile terminal 102 has been stolen and the original SIM blocked for example. The tests will also highlight potential tampering with the key components of the UUID and/or payment token.

Thus, in step 302, the UUID is tested by decrypting the data block in which the UUID is stored and checking the stored IMSI and IMEI with the IMSI and IMEI retrieved directly from the current SIM 106 and mobile terminal 102 respectively. The payment application can interrogate the SIM 106 and the mobile terminal 102 to obtain the IMSI and IMEI respectively. If the IMSI and IMEI are verified, then the application can assume that the UUID in the data block is valid and correct for the IMSI/IMEI combination as verified. However, if the test fails, then the application can be set to terminate the payment process and optionally delete the data block and restart the registration process outlined in Figure 2. If at any stage the UUID test fails, then the application can inform the user that there has been a registration failure, and the transaction cannot be completed, and also prompt the user to re-register to get a new UUID.

If the test of the UUID is passed, then the payment token is retrieved in step 304. However, in the situation where the payment token is also encrypted or stored with reference to the IMSI and/or IMEI, then a similar test to the UUID test in step 302 is performed to retrieve the clear payment token. Or in the alternative arrangement where the payment token is secured using the UUID, a correct UUID obtained from step 302 will be needed to release the payment token. The payment token secured by the UUID (in step 224) can be done by direct encryption using the UUID as a key, or more simply by the application requiring a matching UUID before the payment token is released.

Once the clear payment token is retrieved, it is transmitted to the POS terminal 128 by way of the NFC module 109 in step 306. The POS terminal 128 then uses a secure channel, such as an SSL connection, to the payment server 126. This channel will typically be over some private network rather than the mobile network 112 or the Internet. A payment request is then sent to the payment server 126 from the POS terminal 128 in step 308, where the request includes the payment token, the transaction payment amount, and other transaction identifiers required for transaction identification and logging.

When the payment server 310 receives the payment token, the payment token is checked against the payment tokens stored in step 220 in order to determine the account against which the payment is to be posted. The account associated with the payment token may also include payment parameters such as counters for the number of times the current payment token has been used (a transaction count), and a total transaction amount accrued against the present payment token. In step 312, these parameters are adjusted accordingly. Each of these parameters may have a limit or threshold above which the transaction will be rejected, as a result of which the payment application would have to request a new payment token by repeating steps 214 to 224. Typically, the number of transactions would be set to 5, which matches that for the standard for off-line Chip and PIN transactions. Other parameters could include a validity period, where after a certain period of time, the payment token is no longer valid, requiring a new payment token for payment transactions.

If the user account has sufficient credit and has not been blocked for any reason, and the thresholds for the number of transactions or amount has not been exceeded, then the transaction can be approved. The account details are updated to reflect the transaction amount, and a payment approval message is sent back to the POS terminal 128 from the payment server 126 over a secure connection.

The POS terminal 128 receives the payment approval message and indicates that the transaction has been approved in step 316. This may be in the form of a displayed message or a visual indicator such as a green light. The POS terminal 318 also sends an approval response message back to the mobile terminal 102 in step 320. The mobile terminal 102 then updates its internal parameters, which mirror those maintained by the payment server 126 in step 312. Thus, any of the transaction count, transaction amount totals, and validity period can be updated. The payment process is now complete.

If at anytime the payment application in the mobile terminal 102 determines that the payment counters for transaction number and/or amount are at the threshold or exceeds the threshold, then a new payment token (with new counters) is requested by the mobile terminal 102. The request for a new payment token follows the same process as steps 214 to 224. This "refresh" of the payment token can also be performed periodically even when the thresholds have not been reached to ensure that the payment application always has a new payment token to allow the user as many transactions as possible before another refresh. This refresh is particularly useful if the payment token as an associated validity period after which the token is invalid (for example, a payment token may only be valid for a period of 3 days following generation). If the application determines that the validity period has or is about to shortly expire, a new payment token request can be made.

Furthermore, the user's account can be blocked at any stage if for example the account is no longer in credit or if the credit card used to pay the account is no longer valid for example. If this happens, then when the payment server 126 checks the payment token, it will find that the token matches an account (note, payment token stored against account in step 220) that is blocked. The payment server thus rejects the payment request. In another example, a payment token having a specific or higher value can be requested in step 214 for one off transactions of a higher value. In order to complete this process, a re-registration may be requested first in order to confirm the mobile terminal 102 identity (the MSISDN) by requesting a new UUID (steps 204 to 212).

In summary, examples of the present- invention utilise the inherently secure framework provided by the mobile network operator to provision a UUID that is associated with a user and his device. In particular, it is the security of the SMS mechanism that ensures the security of this invention. The UUID can then be used as a device identifier in issuing and managing payment tokens for payment transactions.

Whilst the download of an application and subsequent registration are described with reference to the same SMS gateway 1 16 and application server 120 as those used in subsequent provision of services, the examples are equally applicable to the use of separate gateways and servers for each process.

In general, it is noted herein that while the above describes examples of the invention, there are several variations and modifications which may be made to the described examples without departing from the scope of the present invention as defined in the appended claims. One skilled in the art will recognise modifications to the described examples.

Claims

1. A method of generating a payment token for conducting payments using a mobile terminal, wherein said mobile terminal comprises an identity module, said method comprising the steps of: a) receiving at an application server a registration message, said first message comprising a telephone number associated with the identity module; b) generating by the application server a unique identifier and storing the unique identifier with the telephone number; c) sending the unique identifier to the mobile terminal, wherein the mobile terminal generates and stores a datablock comprising the unique identifier, and the datablock is secured using the subscriber identity associated with the identity module and a terminal identifier associated with the mobile terminal; and subsequently d) validating by a payment server a request for a payment token from the mobile terminal based on the unique identifier contained in the request, wherein the unique identifier is retrieved from the datablock stored in the mobile terminal.
2. A method according to claim 1 , further comprising: e) using the unique identifier from the request to identify the telephone number associated therewith based on the unique identifier and telephone number stored by the application server.
3. A method according to claim 1 or 2, further comprising generating a payment token and associating and storing the payment token with a user account at the payment server, wherein the user account comprises the telephone number of the mobile terminal.
4. A method according to claim 3, wherein the generated payment token is transmitted by the payment server to the mobile terminal, and the mobile terminal stores the payment token securely using the unique identifier.
5. A method according to claim 4, wherein the payment token is used by the mobile terminal to conduct a contactless payment transaction with a point of sale terminal, said method further comprising transmitting the payment token to the point of sale terminal and onto the payment server, wherein upon receipt at the payment server, the payment token is validated by cross checking against the payment token stored with the user account at the payment server.
6. A method according to claim 5, wherein the payment token is only valid for a fixed period of time following generation by the payment server.
7. A method according to claim 5, wherein the payment token is only valid for a predetermined number of contactless payment transactions.
8. A method according to claim 5, wherein the payment token is only valid for a predetermined total transaction amount.
9. A method according to any preceding claim, wherein the mobile terminal makes a request for a new payment token from the payment server, said request comprising the unique identifier for identifying the mobile terminal.
10. A system for generating a payment token for conducting payments using a mobile terminal, said system comprising an application server and a payment server, said mobile terminal comprising an identity module, and wherein the application server is adapted for receiving at an application server a registration message, said first message comprising a telephone number associated with the identity module, for generating a unique identifier and storing the unique identifier with the telephone number, and for sending the unique identifier to the mobile terminal; the mobile terminal is adapted to generate and store a datablock comprising the unique identifier, and the datablock is secured using the subscriber identity associated with the identity module and a terminal identifier associated with the mobile terminal; and the payment server is adapted to validate a request for a payment token from the mobile terminal based on the unique identifier contained in the request, wherein the unique identifier is retrieved from the datablock stored in the mobile terminal.
PCT/GB2009/000135 2008-03-14 2009-01-19 Mobile payments WO2009112793A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB0804803A GB0804803D0 (en) 2008-03-14 2008-03-14 Mobile payments
GB0804803.5 2008-03-14

Publications (1)

Publication Number Publication Date
WO2009112793A1 true true WO2009112793A1 (en) 2009-09-17

Family

ID=39328165

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2009/000135 WO2009112793A1 (en) 2008-03-14 2009-01-19 Mobile payments

Country Status (2)

Country Link
GB (1) GB0804803D0 (en)
WO (1) WO2009112793A1 (en)

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011141838A1 (en) * 2010-05-11 2011-11-17 Telefonaktiebolaget L M Ericsson (Publ) Mtc service activation
WO2012141495A2 (en) 2011-04-11 2012-10-18 Samsung Electronics Co., Ltd. Apparatus and method for providing a transaction service
EP2587430A1 (en) * 2011-10-31 2013-05-01 NCR Corporation Customer identification with automated transactions
WO2013084145A2 (en) 2011-12-05 2013-06-13 Rozen Limor System and method for enabling monetary transactions
WO2013138195A1 (en) * 2012-03-15 2013-09-19 Qualcomm Incorporated System and method for managing payment in transactions with a pcd
WO2013138194A1 (en) * 2012-03-15 2013-09-19 Qualcomm Incorporated System and method for managing payment in transactions with a pcd
WO2014014526A1 (en) * 2012-07-19 2014-01-23 Bank Of America Corporation Mobile transactions using authorized tokens
WO2014016619A1 (en) * 2012-07-26 2014-01-30 Highgate Labs Limited Two device authentication mechanism
WO2014027287A1 (en) * 2012-08-14 2014-02-20 Cardplus Oy Issuance, obtaining and utilization of personalized digital end user credentials for use in electronic transactions performed with a mobile device
FR3000823A1 (en) * 2013-01-04 2014-07-11 St Microelectronics Sa Method for securing banking transaction carried out between e.g. mobile phone, and server, involves recovering identifier from image information for continuing transaction, without transmission of identifier on communication channel
US20140337230A1 (en) * 2011-12-01 2014-11-13 Sk C&C Co., Ltd. Method and system for secure mobile wallet transaction
WO2015013548A1 (en) 2013-07-24 2015-01-29 Visa International Service Association Systems and methods for interoperable network token processing
CN104603809A (en) * 2012-04-16 2015-05-06 盐技术股份有限公司 Systems and methods for facilitating a transaction using a virtual card on a mobile device
US9043609B2 (en) 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
WO2015084486A1 (en) * 2013-12-06 2015-06-11 Apple Inc. Provisioning and authenticating credentials on an electronic device
EP2786327A4 (en) * 2011-12-02 2015-08-05 Onsun Oy Electronic payment system
EP2798580A4 (en) * 2011-12-29 2015-09-23 Intel Corp Method and system for managing multiple electronic user wallet data cards
EP2836971A4 (en) * 2012-04-13 2015-11-25 Mastercard International Inc Systems, methods, and computer readable media for conducting a transaction using cloud based credentials
WO2015188949A1 (en) * 2014-06-13 2015-12-17 Giesecke & Devrient Gmbh Methods and devices for conducting payment transactions
WO2015193629A1 (en) * 2014-06-18 2015-12-23 Validsoft Uk Limited Detecting porting or redirection of a mobile telephone number
EP2870789A4 (en) * 2012-07-09 2016-01-20 Intel Corp Systems and methods for enabling secure transactions with mobile devices
WO2015162276A3 (en) * 2014-04-24 2016-03-24 Vodafone Ip Licensing Limited Secure token implementation
EP2981939A4 (en) * 2013-04-05 2016-04-27 Visa Int Service Ass Systems, methods and devices for transacting
WO2016065390A1 (en) * 2014-10-31 2016-05-06 In4Ma Pty Ltd Electronic money, method of producing electronic money and transaction method using electronic money
EP2997532A4 (en) * 2013-05-15 2016-05-11 Visa Int Service Ass Mobile tokenization hub
EP3021273A1 (en) * 2014-11-14 2016-05-18 Orange Method for securing a transaction between a mobile terminal and a server of a service provider via a platform
CN105871910A (en) * 2016-05-31 2016-08-17 宇龙计算机通信科技(深圳)有限公司 ESIM combined registering method and related equipment and system
WO2017055373A1 (en) * 2015-09-28 2017-04-06 Touchtech Payments Limited Transaction authentication platform
EP2973278A4 (en) * 2013-03-15 2017-07-19 First Data Corporation Remote secure transactions

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004040494A1 (en) * 2002-10-31 2004-05-13 Rocomo Co.,Ltd Method for issuing instant mobile card using wireless network and accounting it using short distance communication
US20050156026A1 (en) * 2004-01-16 2005-07-21 Angana Ghosh EMV transactions in mobile terminals
WO2006023839A2 (en) * 2004-08-18 2006-03-02 Mastercard International Incorporated Method and system for authorizing a transaction using a dynamic authorization code
GB2438756A (en) * 2005-12-16 2007-12-05 Innovision Res & Tech Plc Communications devices comprising near field RF communicators
WO2008002979A2 (en) * 2006-06-29 2008-01-03 Solidus Networks, Inc. Method and system for providing biometric authentication at a point-of-sale via a mobile device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004040494A1 (en) * 2002-10-31 2004-05-13 Rocomo Co.,Ltd Method for issuing instant mobile card using wireless network and accounting it using short distance communication
US20050156026A1 (en) * 2004-01-16 2005-07-21 Angana Ghosh EMV transactions in mobile terminals
WO2006023839A2 (en) * 2004-08-18 2006-03-02 Mastercard International Incorporated Method and system for authorizing a transaction using a dynamic authorization code
GB2438756A (en) * 2005-12-16 2007-12-05 Innovision Res & Tech Plc Communications devices comprising near field RF communicators
WO2008002979A2 (en) * 2006-06-29 2008-01-03 Solidus Networks, Inc. Method and system for providing biometric authentication at a point-of-sale via a mobile device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"EMV Mobile Contactless Payment: Technical Issues and Position Paper" INTERNET CITATION, [Online] 1 October 2007 (2007-10-01), pages 1-37, XP007908266 Retrieved from the Internet: URL:http://www.emvco.com/mobile.aspx> [retrieved on 2009-04-20] *
SMART CARD ALLIANCE: "Proximity Mobile Payments: Leveraging NFC and the Contactless Financial Payments Infrastructure A Smart Card Alliance Contactless Payments Council White Paper" INTERNET CITATION, [Online] 1 September 2007 (2007-09-01), page complete, XP007906262 Retrieved from the Internet: URL:http://www.smartcardalliance.org> [retrieved on 2008-11-07] *

Cited By (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8995336B2 (en) 2010-05-11 2015-03-31 Telefonaktiebolaget L M Ericsson (Publ) MTC service activation
WO2011141838A1 (en) * 2010-05-11 2011-11-17 Telefonaktiebolaget L M Ericsson (Publ) Mtc service activation
WO2012141495A2 (en) 2011-04-11 2012-10-18 Samsung Electronics Co., Ltd. Apparatus and method for providing a transaction service
EP2697760A2 (en) * 2011-04-11 2014-02-19 Samsung Electronics Co., Ltd. Apparatus and method for providing a transaction service
EP2697760A4 (en) * 2011-04-11 2014-11-19 Samsung Electronics Co Ltd Apparatus and method for providing a transaction service
EP2587430A1 (en) * 2011-10-31 2013-05-01 NCR Corporation Customer identification with automated transactions
US20140337230A1 (en) * 2011-12-01 2014-11-13 Sk C&C Co., Ltd. Method and system for secure mobile wallet transaction
EP2786327A4 (en) * 2011-12-02 2015-08-05 Onsun Oy Electronic payment system
EP2788937A4 (en) * 2011-12-05 2015-09-09 Limor Rozen System and method for enabling monetary transactions
WO2013084145A2 (en) 2011-12-05 2013-06-13 Rozen Limor System and method for enabling monetary transactions
EP2798580A4 (en) * 2011-12-29 2015-09-23 Intel Corp Method and system for managing multiple electronic user wallet data cards
WO2013138194A1 (en) * 2012-03-15 2013-09-19 Qualcomm Incorporated System and method for managing payment in transactions with a pcd
US9092776B2 (en) 2012-03-15 2015-07-28 Qualcomm Incorporated System and method for managing payment in transactions with a PCD
WO2013138195A1 (en) * 2012-03-15 2013-09-19 Qualcomm Incorporated System and method for managing payment in transactions with a pcd
EP2836971A4 (en) * 2012-04-13 2015-11-25 Mastercard International Inc Systems, methods, and computer readable media for conducting a transaction using cloud based credentials
EP2842092A4 (en) * 2012-04-16 2016-01-20 Salt Technology Inc Systems and methods for facilitating a transaction using a virtual card on a mobile device
CN104603809A (en) * 2012-04-16 2015-05-06 盐技术股份有限公司 Systems and methods for facilitating a transaction using a virtual card on a mobile device
EP2870789A4 (en) * 2012-07-09 2016-01-20 Intel Corp Systems and methods for enabling secure transactions with mobile devices
US9043609B2 (en) 2012-07-19 2015-05-26 Bank Of America Corporation Implementing security measures for authorized tokens used in mobile transactions
WO2014014526A1 (en) * 2012-07-19 2014-01-23 Bank Of America Corporation Mobile transactions using authorized tokens
WO2014016619A1 (en) * 2012-07-26 2014-01-30 Highgate Labs Limited Two device authentication mechanism
WO2014027287A1 (en) * 2012-08-14 2014-02-20 Cardplus Oy Issuance, obtaining and utilization of personalized digital end user credentials for use in electronic transactions performed with a mobile device
FR3000823A1 (en) * 2013-01-04 2014-07-11 St Microelectronics Sa Method for securing banking transaction carried out between e.g. mobile phone, and server, involves recovering identifier from image information for continuing transaction, without transmission of identifier on communication channel
EP2973278A4 (en) * 2013-03-15 2017-07-19 First Data Corporation Remote secure transactions
EP2981939A4 (en) * 2013-04-05 2016-04-27 Visa Int Service Ass Systems, methods and devices for transacting
EP2997532A4 (en) * 2013-05-15 2016-05-11 Visa Int Service Ass Mobile tokenization hub
US9978062B2 (en) 2013-05-15 2018-05-22 Visa International Service Association Mobile tokenization hub
EP3025293A1 (en) * 2013-07-24 2016-06-01 Visa International Service Association Systems and methods for communicating risk using token assurance data
US9996835B2 (en) 2013-07-24 2018-06-12 Visa International Service Association Systems and methods for communicating token attributes associated with a token vault
WO2015013548A1 (en) 2013-07-24 2015-01-29 Visa International Service Association Systems and methods for interoperable network token processing
EP3025293A4 (en) * 2013-07-24 2017-03-29 Visa International Service Association Systems and methods for communicating risk using token assurance data
WO2015013522A1 (en) 2013-07-24 2015-01-29 Visa International Service Association Systems and methods for communicating risk using token assurance data
EP3025292A4 (en) * 2013-07-24 2017-03-29 Visa International Service Association Systems and methods for interoperable network token processing
EP3025292A1 (en) * 2013-07-24 2016-06-01 Visa International Service Association Systems and methods for interoperable network token processing
RU2669081C2 (en) * 2013-07-24 2018-10-08 Виза Интернэшнл Сервис Ассосиэйшн Systems and methods for interoperable network token processing
WO2015084486A1 (en) * 2013-12-06 2015-06-11 Apple Inc. Provisioning and authenticating credentials on an electronic device
WO2015162276A3 (en) * 2014-04-24 2016-03-24 Vodafone Ip Licensing Limited Secure token implementation
WO2015188949A1 (en) * 2014-06-13 2015-12-17 Giesecke & Devrient Gmbh Methods and devices for conducting payment transactions
WO2015193629A1 (en) * 2014-06-18 2015-12-23 Validsoft Uk Limited Detecting porting or redirection of a mobile telephone number
WO2016065390A1 (en) * 2014-10-31 2016-05-06 In4Ma Pty Ltd Electronic money, method of producing electronic money and transaction method using electronic money
FR3028646A1 (en) * 2014-11-14 2016-05-20 Orange Method for securing a transaction between a mobile terminal and a server of a service provider by a platform intermediate
EP3021273A1 (en) * 2014-11-14 2016-05-18 Orange Method for securing a transaction between a mobile terminal and a server of a service provider via a platform
WO2017055373A1 (en) * 2015-09-28 2017-04-06 Touchtech Payments Limited Transaction authentication platform
CN105871910A (en) * 2016-05-31 2016-08-17 宇龙计算机通信科技(深圳)有限公司 ESIM combined registering method and related equipment and system

Also Published As

Publication number Publication date Type
GB0804803D0 (en) 2008-04-16 application

Similar Documents

Publication Publication Date Title
US8346672B1 (en) System and method for secure transaction process via mobile device
US20130226799A1 (en) Authentication process for value transfer machine
US20090281947A1 (en) Method and system for mobile commerce
US20120123868A1 (en) System and Method for Physical-World Based Dynamic Contactless Data Emulation in a Portable Communication Device
US20080305774A1 (en) Method and System for Extending the Use and/or Application of Messaging Systems
Schwiderski-Grosche et al. Secure mobile commerce
US20150180836A1 (en) Cloud-based transactions methods and systems
US20020032661A1 (en) Method for the authorization of transactions
US20140279556A1 (en) Distributed authenticity verification for consumer payment transactions
US20120089514A1 (en) Method of authentication
US20080040285A1 (en) Method And System For Authorizing A Transaction Using A Dynamic Authorization Code
US20030055738A1 (en) Method and system for effecting an electronic transaction
US20110191244A1 (en) Secured Transaction System
US20110137804A1 (en) System and method for approving transactions
US20110191252A1 (en) Secured Point-Of-Sale Transaction System
US8577336B2 (en) System and method for transaction authentication using a mobile communication device
US20110258443A1 (en) User authentication in a tag-based service
US20100010932A1 (en) Secure wireless deposit system and method
US20090328144A1 (en) Mobile application registration
US20020126845A1 (en) Method for performing short-range wireless transactions between an hybrid wireless terminal and a service terminal over an interface for short-range wireless access and corresponding service terminal
US20060095290A1 (en) System and method for authenticating users for secure mobile electronic gaming
US20070138261A1 (en) Enhancing bank card security with a mobile device
WO2000031699A1 (en) Method of, and apparatus for, conducting electronic transactions
US20100106649A1 (en) System And Method For Authorizing Transactions Via Mobile Devices
US20150004934A1 (en) Express mobile device access provisioning methods, systems, and apparatus

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09719138

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09719138

Country of ref document: EP

Kind code of ref document: A1