HK1116959B - Updating a mobile payment device - Google Patents

Description

Updating a mobile payment device

Technical Field

The present invention relates to a system for updating a mobile payment device of a user via an unsecured network.

Background

In order to ensure good traffic flow for commuters when entering and leaving the transit system, ticketing for mass transit systems must be very efficient. One type of ticket is a reusable stored value card carried by a commuter for ticketing for all travel. To alleviate bottlenecks at entrance and exit doors, the card is contactless, which enables it to be quickly scanned as the commuter passes through the doors and billed when the commuter has completed his trip.

Although this bottleneck is solved, another problem arises in that the card is recharged at a top-up station. Typically, at a top-up station, the commuter inserts their card and pays via cash or credit/debit card to top up their card. Top-up stations are bulky because they must be able to securely store and dispense large amounts of cash. In subway stations, there is a severe shortage of space, and thus there are a limited number of top-up stations. Long queues that may form during rush hour periods not only delay commuters but also sometimes block intra-station traffic. A simple solution has been to place the charger outside the station. Commuters find this inconvenient and therefore infrequent use.

There is therefore a need to further improve the efficiency of mass transit systems.

In addition, most of the public have these cards, and therefore these cards can also be used in some countries for cashless payment for products and services at participating stores. However, these other uses have limited popularity because there remains the problem of conveniently finding a top-up station to top up their cards.

Disclosure of Invention

In a first preferred aspect, there is provided a method of updating a mobile payment device of a user via an insecure network, the mobile payment device storing value and enabling the user to perform cashless transactions with participating merchants, the method comprising:

transmitting identification information related to the mobile payment device to an authentication server;

authenticating the mobile payment device using the authentication server; and

selecting a transaction type and a transaction amount for the transaction;

wherein, the authentication includes:

sending the encrypted first message from the authentication server to the mobile payment device and sending the encrypted second message from the mobile payment device to the authentication server;

decrypting the encrypted first and second messages;

sending an encrypted third message based on the first message from the mobile payment device to the authentication server and an encrypted fourth message based on the second message from the authentication server to the mobile payment device;

decrypting the encrypted third and fourth messages; and

comparing the first message with the third message and the second message with the fourth message, wherein if they match, the identities of the mobile payment device and the authentication server are mutually authenticated to enable updating of the mobile payment device according to the transaction.

The method further comprises the initial steps of: placing the mobile payment device on or near a reading device to read identification information related to the mobile payment.

The method also includes establishing a communication link between the mobile payment device and the authentication server via a client application.

The client application may be downloaded to a client terminal of the user.

The client application may be an applet (applet) executing in an internet browser application.

The mobile payment device may be a contactless integrated chip card.

The mobile payment device may be a Contactless Smart Card (CSC).

Participating merchants may include public transportation authorities and retail stores.

The transaction type may be any one of the group consisting of a refund, a load on the mobile payment device, and an update to electronic data stored on the mobile payment device.

The communication between the authentication server and the mobile payment device may be via Application Protocol Data Unit (APDU) packets.

The method further comprises establishing communication between the authentication server and a bank host for debiting (debit) or crediting (credit) a bank account of the user in accordance with the transaction.

The unsecured network may be the internet, a metropolitan area network (WAN), or a Wide Area Network (WAN).

In a second aspect, there is provided a system for updating a mobile payment device of a user via an insecure network, the mobile payment device storing value and enabling the user to perform cashless transactions with participating merchants, the system comprising:

an authentication server for authenticating the mobile payment device;

a reading device for reading identification information from the mobile payment device;

a client terminal for transmitting the identification information to the authentication server via the network; and

a user interface that enables selection of a transaction type and a transaction amount for a transaction;

wherein, the authentication includes:

sending the encrypted first message from the authentication server to a mobile payment device and sending the encrypted second message from the mobile payment device to the authentication server;

decrypting the encrypted first and second messages;

sending an encrypted third message based on the first message from the mobile payment device

Sending to the authentication server and sending an encrypted fourth message based on the second message from the authentication server

The authentication server sends to the mobile payment device;

decrypting the encrypted third and fourth messages; and

comparing the first message with the third message and the second message with the fourth message, wherein if they match, the identities of the mobile payment device and the authentication server are mutually authenticated, so that the reading device can update the mobile payment device according to the transaction.

The mobile payment device may be a contactless integrated chip card.

The mobile payment device may be a Contactless Smart Card (CSC).

The reading device may be a Universal Serial Bus (USB) type contactless card reader/writer.

In a third aspect, there is provided an applet for enabling a mobile payment device of a user to be updated via an insecure network, the mobile payment device storing value and enabling the user to perform cashless transactions with participating merchants, the applet comprising:

a user interface allowing the user to select a transaction type and a transaction amount for a transaction;

a server communication module for communicating with an authentication server for authenticating the mobile payment device; and

a device communication module for interfacing with a reading device for reading and updating the mobile payment device;

the server communication module facilitates authentication by: receiving an encrypted first message from the authentication server for decryption by the mobile payment device and an encrypted fourth message based on a second message from the authentication server for decryption by the mobile payment device;

the device communication module facilitates authentication by: sending the encrypted second message from the mobile payment device to the authentication server for decryption by the authentication server; sending an encrypted third message based on the first message from the mobile payment device to the authentication server for decryption by the authentication server;

wherein the first message is compared with the third message and the second message is compared with the fourth message, wherein if they match, the identities of the mobile payment device and the authentication server are mutually authenticated, so that the reading device can update the mobile payment device according to the transaction.

The applet may be a signed Java applet downloadable to a client terminal of the user.

The present invention advantageously provides users with the flexibility and ability to perform electronic services in a secure manner using their computers by using their mobile payment devices for cashless transactions.

Drawings

An example of the invention will now be described with reference to the accompanying drawings, in which:

FIG. 1 is a system architecture diagram of a system according to the present invention;

FIG. 2 is an illustration of an example of downloading an applet to a user's client terminal for interfacing between an authentication server and the user's card;

FIG. 3 is an illustration of an use case in which communication is established between an authentication server and a card;

FIG. 4 is a use case diagram of performing an update on a card; and is

Fig. 5 is a process flow diagram of an authentication process according to the present invention.

Detailed Description

FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, characters, components, data structures, that perform particular tasks or implement particular abstract data types. As will be appreciated by one skilled in the art, the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Referring to fig. 1 to 4, a system 10 for updating a contact free smart card (CSC) 5 of a user over the internet is provided. The CSC5 stores a value, that is, it contains a cash value for paying for the purchase. The CSC5 allows users to conduct cashless transactions with participating merchants in the cashless network. Participating merchants include public transportation authorities 50 and retail stores (such as zoos 60, movie theaters 70, and hospitals 80) accessible via their web servers. Typically, the user provides his CSC5 to the participating merchant for payment, the CSC5 is read, and the appropriate amount is deducted from the stored value of the CSC 5.

The system 10 includes: and an authentication server 20 connected to a USB type contactless card reader/writer 30 of a user's desktop or notebook computer 40. It is assumed that the appropriate driver for the card reader/writer 30 has been installed on the computer 40. The authentication server 20 authenticates the CSC 5. The authentication server 20 is operated by an e-service provider which also manages the distribution of the CSC5 in the marketplace and ensures that participating merchants are adequately supported in the cashless network. The electronic services include viewing the CSC5 details, viewing the CSC5 transaction history, the CSC5 recharge, the CSC5 refund, personalizing the CSC5, loyalty schemes, electronic ticket/coupon payments, viewing medical history, access logins, and scheduled appointments. Technical support is provided in hardware to the participating merchants to properly read/write to the user's CSC 5.

The card reader/writer 30 may be an ACR 120 contactless card reader manufactured by advanced card systems ltd based in hong kong. The reader/writer 30 reads the identification information from the CSC5 and writes to the CSC5 to update it. The wireless communication between the CSC5 and the reader/writer 30 is via ISO 14443-C Felica.

The computer 40 communicates with the authentication server 20 via the internet. The authentication server 20 and the CSC5 must authenticate and verify each other's identity before allowing transactions and updates to the CSC5 to take place.

Referring to fig. 5, the authentication process 200 involves the authentication server 20 and the CSC5 each generating 201 a random number. A copy of the random number is temporarily stored for later comparison. The plaintext random number is encrypted 202 using a predetermined encryption algorithm. The encryption algorithm may be a private key (symmetric) encryption, such as Advanced Encryption Standard (AES) using a secret key of 128, 192, or 256 bits. The authentication server 20 sends 203 its encrypted random number via the computer 40 to the CSC5 by message. The CSC5 sends 203 its encrypted random number to the authentication server 20 by a message. When the messages are received by the CSC5 and the authentication server 20, the messages are opened and the random numbers contained in the messages are decrypted 204 by the decryption function of the predetermined encryption algorithm. Again, the random number is encrypted 205 by a predetermined encryption algorithm and sent 206 by message to the CSC5 and the authentication server 20, respectively. When these messages are received by the CSC5 and the authentication server 20, the messages are opened and the random numbers contained in the messages are decrypted 207 by the decryption function of the predetermined encryption algorithm. The random number received and decrypted by the CSC5 is compared 208 with the temporary copy generated earlier by the CSC 5. If there is a match, the identity of the authentication server 20 is verified towards the CSC 5. At this point, the authentication process is only partially successful. Similarly, the random number received and decrypted by the authentication server 20 is compared with a temporary copy generated earlier by the authentication server 20. If there is a match, the identity of the CSC5 is verified against the authentication server 20. When both identities are verified, the authentication is successfully completed 209 and the reader/writer 30 is allowed 210 to update the CSC 5.

Since the CSC5 typically has a limited storage capacity, the encryption algorithm is preferably small in size and not complex. To meet user friendliness, the authentication process is fast and efficient, and transparent to the user.

However, the authentication process is robust to withstand possible security breaches.

In a general case, referring to fig. 2, a user starts an internet browser application and inputs a URL address in order to access the authentication server 20. The user may also connect to the authentication server 20 via the dedicated web server 100 instead of initially accessing the authentication server 20 directly. In response to the HTTP request, the web server 100 provides the user with a web page providing instructions to the user indicating which applet to use their CSC5 to download the electronic service. The applet is digitally signed by a trusted party to ensure authenticity. Once the applet has been downloaded to the user's computer 40, a secure dialog box appears to request confirmation from the user for execution of the applet. When the applet is executed, it enters a power-up mode, detects and establishes a connection with the reader/writer 30.

Referring to fig. 3, after the applet has been downloaded and executed in a window of an internet browser, the user places the CSC5 on or near the card reader/writer 30 for reading. The identification information of the CSC5 is retrieved by the card reader/writer 30 and sent by the computer 40 to the authentication server 20. Based on the CSC5, the authentication process described earlier is performed. In one embodiment, the authentication process is performed using Application Protocol Data Unit (APDU) packets.

Referring to fig. 4, after successful authentication, all necessary connections have been established and the applet switches from power-up mode to service mode. The CSC5 is ready for reading and writing. The applet displays a screen that allows selection of the transaction type and transaction amount for the transaction using the CSC 5. For example, users wish to recharge their CSC 5. The user selects "top up" as the transaction type and enters "$ 10" as the transaction amount. The user also selects a payment mode (credit card in this example) and then enters a credit card number and expiration date. A message is constructed containing the transaction type, transaction amount, payment mode, and payment details of the user. The message is sent to the authentication server 20. Upon receiving the message, authentication server 20 deconstructs the message and forwards the payment details and transaction amount to the user's credit card issuing bank 90. When the issuing bank returns an approval for the accounting request, the authentication server 20 generates a "write" APDU packet and sends it via the computer 40 to update the CSC 5. Once the CSC5 has been updated with the added value, the transaction is complete. The user may then continue to use their CSC5, which CSC5 has an additional $10 stored value at the participating merchants.

In a similar manner, other transaction types may be utilized including refunds to the user's bank account, online payments for e-commerce, and recent transaction activity by the CSC 5.

Although a CSC5 has been described, it is envisaged that other mobile payment devices are possible, including contact and contactless integrated chip cards.

While applets have been described, dynamic web pages may also be user interfaces. To ensure security, Secure Sockets Layer (SSL) may be used to encrypt web pages transmitted over the internet.

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (15)

1. A method of updating a mobile payment device of a user via a non-secure computer network, the mobile payment device storing value and enabling the user to perform a cashless transaction with a participating merchant, the method comprising:

transmitting identification information related to the mobile payment device to an authentication server;

authenticating the mobile payment device using the authentication server via the unsecured computer network; and

selecting a transaction type and a transaction amount for the transaction;

wherein, the authentication includes:

sending the encrypted first message from the authentication server to the mobile payment device and sending the encrypted second message from the mobile payment device to the authentication server;

decrypting the encrypted first and second messages;

sending an encrypted third message based on the first message from the mobile payment device to the authentication server and an encrypted fourth message based on the second message from the authentication server to the mobile payment device;

decrypting the encrypted third and fourth messages;

comparing the first message with the third message and the second message with the fourth message, wherein if they match, the identities of the mobile payment device and the authentication server are mutually authenticated to enable updating of the mobile payment device according to the transaction; and

establishing a communication link between the mobile payment device and the authentication server via a client application downloaded from the authentication server to the user's client terminal upon authentication.

2. The method of claim 1, further comprising the initial steps of: placing the mobile payment device on or near a reading device to read identification information related to the mobile payment.

3. The method of claim 1, wherein the client application is an applet executing in an internet browser application.

4. The method of claim 1, wherein the mobile payment device is a contactless integrated chip card.

5. The method of claim 4, wherein the mobile payment device is a Contactless Smart Card (CSC).

6. The method of claim 1, wherein the participating merchants include public transportation authorities and retail stores.

7. The method of claim 1, wherein the transaction type is any one of the group consisting of a refund, a load on the mobile payment device, and an update to electronic data stored on the mobile payment device.

8. The method of claim 1, wherein the communication between the authentication server and the mobile payment device is via Application Protocol Data Unit (APDU) packets.

9. The method of claim 1, further comprising establishing communication between the authentication server and a bank host to debit or credit a bank account of the user in accordance with the transaction.

10. The method of claim 1, wherein the unsecured network is the internet, a metropolitan area network (WAN), or a Wide Area Network (WAN).

11. A system for updating a user's mobile payment device via a non-secure computer network, the mobile payment device storing value and enabling the user to perform cashless transactions with participating merchants, the system comprising:

an authentication server for authenticating the mobile payment device via the non-secure computer network;

a reading device for reading identification information from the mobile payment device;

a client terminal for transmitting the identification information to the authentication server via the network; and

a user interface that enables selection of a transaction type and a transaction amount for a transaction;

wherein, the authentication includes:

sending the encrypted first message from the authentication server to the mobile payment device and sending the encrypted second message from the mobile payment device to the authentication server;

decrypting the encrypted first and second messages;

sending an encrypted third message based on the first message from the mobile payment device to the authentication server and an encrypted fourth message based on the second message from the authentication server to the mobile payment device;

decrypting the encrypted third and fourth messages;

comparing the first message with the third message and the second message with the fourth message, wherein if they match, the identities of the mobile payment device and the authentication server are mutually authenticated, so that the reading device can update the mobile payment device according to the transaction; and

establishing a communication link between the mobile payment device and the authentication server via a client application downloaded from the authentication server to the user's client terminal upon authentication.

12. The system of claim 11, wherein the mobile payment device is a contactless integrated chip card.

13. The system of claim 12, wherein the mobile payment device is a Contactless Smart Card (CSC).

14. The system of claim 13, wherein the reader device is a Universal Serial Bus (USB) type contactless reader/writer.

15. The method of claim 3, wherein the applet is a signed Java applet downloadable to the user's client terminal.