FR3051613A1 - - Google Patents

Abstract

Methods, systems, and computer program products for securely exchanging a credit card token with an external computer, as part of the purchase of a product. The system includes one or more processors, a memory and a camera coupled with at least one processor. The system scans a first barcode using the camera. The first barcode is published on the screen of an external computer and indicates a plurality of payment parameters of the product. The system decodes the first barcode to extract the payment parameters. The system publishes the payment settings for display to a user. The system receives a first entry, the first entry indicating a credit card number for the purchase of the product, and a token corresponding to the number of the credit card is saved in the memory.

Description

SECURE EXCHANGE OF SENSITIVE DATA ON A NETWORK BASED ON BAR CODE AND TOKENS TECHNICAL FIELD

The invention generally relates to computers and computer software, and in particular methods, systems, and computer program products for securely exchanging sensitive data over a network.

CONTEXT

Because of the many possibilities for sensitive data, such as credit card data, to be compromised during a payment, it is imperative to use devices that comply with the industry standard. credit card data security (PCI-DSS) to reduce vulnerabilities and protect cardholder data. However, it can be extraordinarily difficult and expensive to comply with PCI-DSS. In an approach to protect sensitive data, substitution of the data by a token or alias can be used instead of the current credit card data. The token can be used instead of an individual's current credit card during a payment transaction. For example, a user may use his or her smartphone or other portable electronic device to adjust a product. Specifically, the user can download a software application on a smartphone. The user can then enter the credit card information and send the information over a network to a group of servers. In response to receiving the information associated with the user's credit card, the servers may generate a token corresponding to the credit card information of the user. Those skilled in the art will understand that tokens, in and of themselves, are meaningless and therefore can not be used alone. In addition, the generation of tokens can be less expensive and more secure than end-to-end encryption.

For example, third-party booking agents (i.e., travel agents), or travelers can use computer devices to create a travel reservation, which opens up opportunities for traveler's credit card data are compromised during payment. Sometimes a traveler may need, while traveling, to pay the travel reservation itself or any other incidental charges, such as baggage fees. That is, the traveler may need to pay on the spot, at an airport or in another place, such as a train station, for travel related expenses.

In addition to the difficulties mentioned above to protect the data of the cardholder, it will be noted that travelers may also be faced with other problems in trying to make a payment to confirm a travel reservation, in an airport or similar place. For example, using a smartphone to pay for a reservation can be problematic for the traveler when he is in a foreign country. This is because many cellular service providers may not provide such services in another country, or may charge very high roaming charges when the traveler is abroad . Thus, the acceptance of payments by travelers, even when their smartphone is not connected to a network, is a need. Moreover, it will be noted that it can also be inconvenient and tedious for a traveler to take his credit card out of his wallet which is in his pocket, especially if he is in a hurry and has a lot of luggage to wear while traveling. In the same way, it can also be inconvenient for a traveler to search his handbag to recover his credit card, especially if his hands are already taken by bags to carry during his journey. [0005] Thus, methods, Enhanced computer systems and program products are required to enable the secure exchange of sensitive data over a network. SUMMARY [0006] In one embodiment of the invention, a system for the secure exchange of a credit card token between a first computer and an external computer to purchase a product. The first computer includes one or more processors, a memory, and a camera coupled to at least one processor. The first computer scans the barcode using the camera. The first barcode is published on a display screen of the external computer and indicates a plurality of payment parameters for the payment of the product. The first computer decodes the first barcode to extract the payment parameters. The first computer publishes the payment settings for display to a user. The first computer receives a first entry in which the first entry indicates a credit card number for the purchase of a product, and a credit card token corresponding to the credit card number is stored in memory. In response to receiving the first input, the first computer generates a second barcode that contains the first encrypted payload data. The first encrypted payload data include the credit card token. The first computer publishes the second barcode for display, said second barcode being readable by an optical device of the external computer.

In some embodiments, the system further comprises a third computer and a Token vault in communication with the external computer. The external computer sends the second barcode to the third computer. In one embodiment, the third computer decodes the second barcode, validates the contents of the first encrypted payload data to obtain the credit card token, and retrieves an original credit card number from the chip vault. based on the credit card token. In some embodiments, the third computer communicates with a payment network to determine the validity of the original credit card number and, in response to the original credit card number being valid, the payment network authorizes the payment. payment of the product and sends an approval to the third computer. In some embodiments, the external computer receives approval from the third computer for payment of the product, generates a third barcode that contains a payment receipt for the product, and publishes the third barcode for display. The third barcode is scanned by the camera.

In some embodiments, the plurality of payment parameters includes at least a monetary amount, a specific type of currency on which the monetary amount is based, a product description and a payment reference in the form of an identifier ( ID).

In some embodiments, before the scanning of the first barcode by the camera, the first computer and a third computer are connected to a network, the first computer receives a second entry indicating the credit card number and , in response to receiving the second input, the first computer generates second payload encrypted data which conti nes the credit card number. In some embodiments, the first computer transmits on the network a card provisioning request including the second payload encrypted data, the third computer receives the card provisioning request on the network and, in response to receiving the Card provisioning request, the third computer decrypts the second encrypted payload data to obtain the credit card number. In some embodiments, the third computer sends the credit card number to a tokenization application and in response to receiving the credit card number, the tokenization application generates the credit card token. In some embodiments, the credit card token is stored in a token vault and is also transmitted by the third computer to the first computer via the network, and the first computer retains the credit card token in the form of a token vault. a digital print (hash) in memory. In some embodiments, the processors are part of a portable electronic device.

In another aspect, a method is disclosed for the secure exchange of a credit card token between a first computer and an external computer as part of the purchase of a product. a first barcode using a camera of a first computer in which the first barcode is published for display on a screen of the external computer, and the first barcode indicates a plurality of parameters payment of the product. The method further comprises decoding the first barcode, by the first computer, to extract the payment parameters. The method also includes the publication of the payment parameters by the first computer, for display on the screen of a user. The method further includes receiving a first entry by the first computer, wherein the first entry indicates a credit card number for the purchase of the product, and a credit card token, corresponding to the card number. credit, is saved in the memory of the first computer. In response to receiving the first input, the method includes generating, by the first computer, a second bar code containing the first payload encrypted data, wherein the first payload encrypted data includes the payload token. credit card. Finally, the method includes the publication of the second barcode for displaying on the screen of the first computer, wherein the second barcode is readable by means of an optical device of the external computer.

In some embodiments, the external computer sends the second barcode to a third computer via a network. The third computer decodes the second barcode, validates the contents of the first encrypted payload data to obtain the credit card token, and retrieves an original credit card number from a token vault based on the token. credit card. In some embodiments, the third computer sends a communication to a payment network. In response to receiving the communication, the payment network determines whether the original credit card number is valid. In response to the original credit card number being valid, the payment network authorizes the payment of the product via the payment network and sends an authorization to the third computer. In some embodiments, the third computer receives the authorization for the payment of the product, sends the authorization to the external computer via the network, generates a third barcode containing a payment receipt of the product and publishes the third code -barres for display by the external computer, wherein the third barcode is digitized by the camera of the first computer.

In some embodiments, the first computer and the third computer are connected to a network before scanning the first barcode by the first computer. The first computer receives a second entry indicating the credit card number and, in response to receiving the second entry, generates second payload encrypted data containing the credit card number. The first computer transmits a card provisioning request including the encrypted payload data via the network. The third computer receives the card provisioning request via the network and, in response to receiving the card provisioning request, decrypts the second encrypted payload data to obtain the credit card number. The third computer sends the credit card number to a tokenizing application of the third computer and, in response to receiving the credit card number, generates the credit card token using the tokenization application. In some embodiments, the third computer saves the credit card token in a vault of tokens and transmits the credit card token via the network. The first computer receives the credit card token from the system via the network and retains the credit card token as a digital fingerprint in the system memory. In some embodiments, the first computer is a portable electronic device.

In another aspect, a computer program product is provided for the secure exchange of a credit card token with an external computer as part of the purchase of a product. The computer program product includes a computer-readable, durable storage medium and program code recorded on the computer-readable, durable storage medium that, when executed by one or more processors, causes one or more processors to be digitized. a first barcode using a camera, wherein the first barcode is published for display on a screen of the external computer and the first barcode indicates a plurality of payment parameters of the product. The processors are also led to decode the first barcode to extract the payment parameters. Processors are then required to publish the payment parameters for display to a user. Then the processors are required to receive a first entry, in which the first entry indicates a credit card number for the purchase of the product and a credit card token corresponding to the credit card number is saved in the memory. In response to receiving the first input, the processors are then caused to generate a second bar code that contains the first encrypted payload data in which the first encrypted payload data includes the credit card token. Processors are also required to publish the second barcode for display. The second barcode is readable by an optical device of the external computer.

The preamble above is brief and simplified to allow a basic understanding of certain aspects of the systems and / or methods described herein. This summary is not an extensive overview of the systems and / or processes described herein. It does not claim to identify key or decisive elements, nor to define the extent of such systems and / or processes. Its sole purpose is to present some concepts in a simplified way as a preface to the more detailed description that is exposed later.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are an integral part of the specifications; they illustrate various embodiments of the invention and, together with the general description of the invention above and the detailed description of the embodiments given below, serve to explain the embodiments of the invention.

FIG. 1 is a schematic view of an exemplary operating environment for exchanging a credit card token in connection with the purchase of a product, wherein the operating environment includes a client device, a merchant system and a waiter.

FIG. 2 and a schematic view of an exemplary computer system of FIG. 1.

FIG. 3 is a schematic view of the client device shown in FIG. 1 being downloaded from a software application.

FIG. 4 is a schematic view of the client device and the trading system illustrated in FIG. 1, in which the client device and the merchant system can display unique barcodes.

DETAILED DESCRIPTION

[0020] Referring now to FIG. 1, an operating environment 10, in accordance with an embodiment of the invention, may include a client device 12, a merchant system 14 and one or more servers 16. As explained in more detail below, the server 16 may be in communication with a token vault 18 and a payment server 20. Those skilled in the art will understand that the token vault 18 is a secure server where the tokens and the corresponding principal account number ( Primary Account Number, or (PAN)) are kept securely. The PAN, which typically has between fourteen and sixteen digits, is a credit card number associated with the credit card of the account holder. The token vault 18 is the only component of the operating system 10 where the token can be mapped to obtain the PAN. On the other hand, it will also be noted that the token vault 18 meets the requirements of the industry standard for payment card data security (PCI-DSS). Each client device 12, each merchant system 14, and each server 16 may communicate through a network 26. The network 26 may include one or more private or public networks (eg, the Internet) that enable the exchange of data. data.

The client device 12 may, for example, be a digital tablet, a smartphone, or any other appropriate computer device. Note that since the end user traveling during a trip may possibly use the client device 12, the client device 12 may be a portable electronic device. That is, the size of the client device 12 is such that the client device 12 can be carried in the purse, a cabin bag, a wallet, or even in the traveler's pocket. As will be explained in detail below, an end user can use the client device 12 to confirm and set a travel reservation by accessing the merchant system 14. For example, the traveler can launch a browser application and use the browser application to make payment for a travel reservation. Note that the traveler can first download an application 27 to the memory of the client device 12 before the client device 12 is used to confirm and pay the travel reservation.

The client device 12 may include a camera 22 and a screen 24. The camera 22 is capable of capturing images. Furthermore, it will also be noted that the client device 12 is capable of recognizing and decoding barcodes captured by the camera 22. Examples of barcodes that can be captured by the camera 22 and decoded by the client device 12 include , without being limiting, QR codes. The screen 24 of the client device 12 may, for example, be a liquid crystal display (LCD) screen that electronically displays graphics, such as text, images, and animations.

The merchant system 14 may be associated with a specific supplier or travel suppliers. In one embodiment, the merchant system 14 may include a merchant application 28, an optical device 30, and a monitor 32. As will be explained in more detail below, the merchant application 28 may be used in conjunction with one another. with the client device 12 to allow the secure exchange of a credit card token in connection with the purchase of a product. It will be noted that the trading system 14 can also be mobile. In a non-limitative embodiment, the product may be a travel product such as, for example, air travel, train travel, ferry trip, hotel rooms, car rentals, tourism and other activities related to the trip. The product may also include not only travel products, but also other travel-related expenses such as, for example, baggage fees that may arise while traveling or upgrading an existing travel reservation. The optical device 30 may be any type of device for image capture such as, for example, a scanner or a web camera. Specifically, the merchant system 14 can recognize and decode the bar codes that are displayed on the screen 24 of the client device 12. The display 32 of the merchant system 14 may, for example, be an LCD that electronically displays graphs such as text, illustrations and animated images.

The server 16 may be in communication with the token vault 18 as well as with the payment server 20 via the network 26. The payment server 20 may be in communication with a payment network 34 and a payment service provider (PSP) 36 through the payment server 20. As explained in more detail below, the server 16 can retrieve an original credit card number from the token vault. 18 based on the credit card token. The server 16 may receive an authorization from the payment network 34 validating the number of the original credit card and confirm with the PSP 36 that the merchant system 14 is authorized to make a payment for the purchase of a particular product .

[0025] Referring now to FIG. 2, the client device 12, the merchant system 14 and the server 16 of the operating environment 10 may be implemented on one or more computing devices or systems, such as the exemplary computer system 40. The computer system 40 may include a processor 42, a memory 44, a mass storage device 46, an input / output (I / O) interface 48 and a human-machine interface (HMI) 50. The computer system 40 can also be operably coupled. to one or more external resources 52 via the network 26 or the I / O interface 48. The external resources may include, but not limited to, servers, databases, memory storage devices mass, peripheral devices, cloud network services, or any other appropriate computer resource that can be used with the computer 40.

The processor 42 may include one or more selected devices: microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, programmable gate networks, programmable logic devices, defined state machines, logic circuits, analog circuits, digital circuits, or any other device used to manipulate signals (analog or digital) based on the operating instructions stored in the memory 44. The memory 44 may include a single device or a plurality of memory devices, including, but not limited to, read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any another device capable of storing information. The mass storage device 46 may include data storage devices such as a hard disk, an optical disk, a tape drive, a volatile or nonvolatile solid state circuit, or any other device able to store information.

The processor 42 can operate under the control of an operating system 56 which resides in the memory 44. The operating system 56 can manage the computing resources so that the program code of the integrated computer in the form of one or more software applications, such as the application 58 which resides in the memory 44, may contain instructions executable by the processor 42. In one embodiment, the processor 42 may execute the application 58 directly and in this case the operating system 56 may be omitted. One or more data structures 60 may also reside in the memory 44 and may be used by the processor 42, the operating system 56 or the application 58 to store or manipulate data.

The I / O interface 48 can provide a machine interface that functionally couples the processor 42 to other devices and systems, such as the network 26 or the external resource 52. The application 58 can thus collaborate with the network. 26 or the external resource 52 by communicating via the I / O interface 48 to provide a variety of features, functions, software applications, processes, or modules comprising the embodiments of the I / O 48 interface. invention. The application 58 may also have program code executable by one or more external resources 52, or otherwise based on functions or signals provided by other systems or by network components external to the computer system 40. given almost infinite hardware and software configurations, it will be understood by those skilled in the art that the embodiments of the invention may include applications located externally to the computer system 40, distributed to multiple computers and other external resources 52, or provided by computer resources (hardware and software) such as a cloud service, provided as services via the network 26.

The HMI50 may be operatively coupled to the processor 42 of the computer system 40 in a known manner to allow a user to interact directly with the computer system 40. The HMI 50 may include video or alphanumeric displays, a touch screen, a speaker and any other visual and audio indicator capable of providing data to the user. The HMI 50 may also include input devices and controls such as an alphanumeric keypad, pointing device, keyboards, push buttons, control buttons, microphones, etc. capable of accepting commands or user inputs, and transmit them to the processor 42.

A database 50 may reside on the mass memory device 46, and may be used to collect and organize the data used by the various systems and modules described herein. The database 54 may include data and data structures that support them to store and organize the data. In particular, the database 54 may be arranged according to any organization or database structure including, but not limited to, a relational database, a hierarchical database, a networked database, or combinations of these. A database management system, as a computer software application that executes processor instructions 42, can be used to access information or data stored in records in database 54 in response to a request, when the request can be dynamically determined and executed by the operating system 56, the other applications 58, or one or more modules.

[0031] Referring now to FIG. 3, the client device 12 can download the application 27 into memory. Specifically, the client device 12 can connect an application server 70 via the network 26 and download the application 27 to the memory of the client device 12. As seen in FIG. 3, a public certificate (PubA certificate ) can be associated with the application 27. Once the application 27 has been downloaded successfully, an end user, such as a traveler, can create a password. The password may be required to access the application 27. In one embodiment, the password may be entered manually into the client device 12 using a keyboard (not shown). However, those skilled in the art will understand that other approaches can also be used to enter the password. In one embodiment, it may be necessary to enter the password twice to prevent erroneous entry. Once the password is created, the password can be kept as a fingerprint in the memory of the client device 12 for later use. Those skilled in the art will understand that the password hash is to create, from a variable length password, a fixed length cryptic password, based on the original variable length password.

The client device 12 can also generate a pair of asymmetric keys (PubP, PrivP). PubP is the public key and PrivP is a secret key. Asymmetric cryptography, also known as public key cryptography, is a cryptographic system that uses a pair of keys. In particular, the public key (PubP) can be widely disseminated and the secret key (PrivP) can have controlled access through the use of the password. The asymmetric keys are stored in the memory of the client device 12.

Once the application 27 and the asymmetric keys are stored in the memory of the client device 12, the end user can identify himself on the application 27. Specifically, the end user can identify himself on the application 27 and enter the password. If the hashed password entered by the user corresponds to the digital fingerprint previously saved in the memory of the client device 12, access to the PrivP secret key and access to subsequent transactions are granted. Specifically, the end user can now register one or more credit cards that can be used to purchase a product, for example an airline ticket, using the application 27. Each credit card is associated with a number credit card.

[0034] Referring now to FIG. 1, it will be noted that the client device 12 must be connected to the network 26 before the credit card is registered. The registration of a single credit card using the application 27 of the client device 12 is now explained. First, the end user may choose an option to register a new credit card number using the client device 12. For example, the end user may choose an option such as, for example, "Save a map "on a menu that is displayed on the screen 24 of the client device 12. The end user can then enter the credit card number and other credit card details using a However, it should be noted that other approaches can also be used to enter credit card information such as, for example, the real credit card taken into the picture. then its analysis using Optical Character Recognition (OCR) technology. Credit card details include, but are not limited to, an expiry date associated with the card, the name of the primary cardholder, the address of the primary cardholder, and the value of the card. verification of the credit card (CW) associated with the credit card. Once the end user has entered the credit card number and the details associated with the credit card, a credit card verification may be performed by the application 27 to confirm the expiration date. The application 27 can also execute a Luhn algorithm, which consists of a checksum formula, to verify that the credit card number does not have erroneous digits.

Once the credit card number and the details associated with the credit card are verified, the application 27 and the client device 12 can build encrypted payload data, designated as the payload data of the payload. provisioning of the card. Specifically, the application 27 of the client device 12 can obtain the public certificate PubA. The application 27 can then generate a symmetric key S1 and its associated initial vector II. The symmetric key S1 and the initial vector II can be concatenated and then signed by the secret key (PrivP) in order to obtain (SI, II) '*' p, in which the "" denotes that the value is signed. The application 27 can then concatenate the symmetric key SI, the initial vector II and (SI, Ι1) "'ρ, and then encrypt these values by using the public certificate PubA on the basis of an optical asymmetric encryption filling scheme ( Optical Asymmetric Encryption Padding, or [OAEP]) to obtain (SI, II, (SI, Ι1) "'ρ'α, or the' '" denotes that the value is encrypted.

The application 27 of the client device 12 can then sign the credit card number which is denoted herein as N, using the PrivP secret key to obtain the signature N * p. The credit card number N can then be concatenated with the signature N * p and encrypted with the symmetric key S1 to obtain (N, N * p) 'si. Finally, the application 27 of the client device 12 can concatenate the certificate of the public key PubP, the result being designated as certP, with (S 1,11, [SI, II] * p) "a and (N, N * p) »SI. The result gives the payload data for provisioning the card. The client device 12 may send the card provisioning payload data included in the card provisioning request to the server 16 via the network 26.

In response to the receipt of the card provisioning request, the server 16 can extract the provisioning payload data and then decrypt the provisioning payload data of the card to obtain the card number. Specifically, the server 16 may subsequently obtain the symmetric key SI, the initial vector II and (SI, II) * p, and decipher each of the values with a PrivA private certificate. The private certificate PrivA is the secret key associated with the public certificate PubA, and the public certificate PubA and the private certificate Priv A are generated before the application 27 is saved on the application server 70. The server 16 can then verify the signature of (SI, 11) '"p of the symmetric key SI and the initial vector II using the concatenated certificate of the public key certP, the server 16 can then obtain the credit card number N and N * p and decrypt these two values using the symmetric key S1, then the signature Ν '"p of the credit card number N can be verified using the concatenated certificate of the public key certP.

The server 16 can then send the credit card number N to a tokenization application74. The tokenization application74 can then generate a credit card token T based on the unique credit card number N. Those skilled in the art will understand that the tokens can not be used outside the context of a specific single transaction. with a specific trader. The tokenization application74 can then return the credit card token T to the server 16. The tokenization application 74 can also send the Token T and the unique number of the credit card N to the vault of Tokens 18. The vault of Tokens 18 is the only element included in the operating system 10 where the Token of the credit card T is mapped to the unique number of the credit card N.

In response to the receipt of the credit card token T from the tokenization application74, the server 16 can then generate a symmetric key S2 and its initial vector 12. In one embodiment, the symmetric key S2 is based on the advanced 128-bit encryption standard using encryption mode with data block chaining (AES 128 CBC). The server 16 can then concatenate the symmetric key S2 and the initial vector 12, and then sign the value with the private certificate PrivA to obtain (S2, 12) * a. The server 16 can then concatenate the symmetric key S2, the initial vector 12 and (S2,12) * A and encrypt them with the public key PubP on the basis of the filling scheme OAEP to obtain (S2,12, [S2, 12 ] * a) »p. The server 16 can then sign the Token of the credit card T with the private certificate PrivA to obtain a signed Token T * a- The server 16 can then concatenate the Token T with the Token signed T * a, and encrypt the two values with the symmetric key S2 to obtain (T, T * a) »sa. Finally, the server 16 can concatenate (S2,12, [S2, I2] * a) "p and (T, T * a)" sa. The resulting payload data is returned in a map provisioning response. 76 via the network 26 to the client device 12.

In response to the receipt of the card provisioning response 76, the application 27 of the client device 12 can verify the concatenated certificate PrivA private certificate, designated as certA, with personal identification number keys (PIN ). Those skilled in the art will understand that PIN keys are security mechanisms to resist piracy using fraudulent certificates. The application 27 of the client device 12 can then obtain the symmetric key S2, the initial vector 12 and the signature (S2, I2) * a and decrypt these values with the secret key PrivP. The application of the client device 12 can then check the signature (S2,12) * a of the symmetric key S2 and the initial vector 12 with the concatenated certificate of the private certificate certA. The application 27 of the client device 12 can then obtain the Token of the credit card T and the Token signed T * a and decrypt these values using the symmetrical key S2. Then, the application 27 of the client device 12 can verify the signed Token T * a Token of the credit card T with the concatenated certificate certA private certificate. Finally, after the verification of the Token signed T * A, the Token of the credit card T can be stored in the memory of the client device 12.

It will be noted that the client device 12 registers the card of the credit card T in its respective memory and that the card of the credit card can be used later during a payment transaction. If the end user travels and is in a foreign country or other location where cellular service is not available, or is expensive due to data roaming charges, the end user does not require network connectivity to make payment for a specific travel reservation, since the T token of the end user's credit card has already been stored in memory. In addition, note that more than one credit card token can be saved in memory on the client device 12, each credit card token corresponding to a single credit card. For example, with reference to FIG. 4, the client device 12 publishes the credit card number 80 on the screen 24. It will be noted that only the last four digits of the credit card numbers 80 are readable for the end user, and that the full number of the credit card is not kept in memory on the client device 12.

During his trip, the end user may need to pay a travel reservation and / or other incidental costs, such as, for example, excess baggage charges. In the exemplary embodiment shown in FIG. 4, the end user may need to pay excess baggage costs that cost 50 euros. However, it will be appreciated that the embodiment illustrated in FIG. 4 is purely exemplary in nature and that various other products and expenses may also be purchased. Now referring to both FIGS. 1 and 4, an agent may subsequently confirm that the end user wishes to pay for the product (eg, the fifty euros for excess baggage charges) by using one of the credit cards with a card token T Corresponding credit stored in memory on the client device 12. Once confirmed, the agent can then use a keypad or other input device of the merchant system 14 (not shown) to indicate that the end user wishes to pay the product using its client device 12.

In response to receiving an indication from the agent, the merchant application 28 of the merchant system 14 can send a request to the server 16 via the network 26. The request sent to the server 16 is for a barcode 82, or for payload data, indicating a plurality of the payment parameters relating to the product. In the exemplary embodiment illustrated in FIG. Bar code 82 is a QR code; however, it will be appreciated that other types of bar codes may also be generated. In one embodiment, the payment parameters may include, but are not limited to, a monetary amount due (e.g., fifty euros), a specific currency type upon which the monetary amount (e.g. Euro), a product description (eg excess baggage charge) and a payment reference identifier (ID).

In response to the receipt of a request from the merchant system 14, the server 16 can subsequently confirm with the PSP 36 that the merchant system 14 is authorized to make a payment using the bar code 82 If the merchant system 14 is authorized to make a payment using the bar code 82, the PSP 36 can then generate the bar code 82. The bar code 82 may be encoded with a temporary pair of asymmetric keys. The PSP 36 can then send an authorization to the server 16. The authorization includes the bar code 82. In response to receiving an authorization from the PSP 36, the server 16 can then send the barcode 82 via the network 26 to the merchant system 14. In response to receipt of the bar code 82, the application 28 of the merchant system 14 can publish the bar code 82 on the corresponding screen 24.

Once the bar code 82 is published on the screen 24 of the trading system 14, the end user can then position the client device 12 so that the camera 22 can scan the bar code 82. It will be noted that the end user has already identified himself on the application 27 of the client device 12 and has entered the password successfully. The client device 12 can then decode the bar code 82 in order to extract the payment parameters. The client device 12 can then publish the payment parameters on its screen 24. For example, as seen in FIG. 4, Payment parameters indicate that 50 € are required for the payment of excess baggage fees. The client device 12 can then publish the numbers of the credit cards 80 having corresponding credit card tokens saved in memory on the client device 12.

The end user can then select or enter the credit card number 80 to be used for the purchase of the product using the client device 12. In one embodiment, the end user can also use a Default credit card number 80, pre-selected at the time of payment, or more complex rules can be used for automatic selection of a specific credit card number. In the event that a single credit card number 80 has a corresponding credit card T token stored in memory, the end user may then simply need to confirm the use of the unique credit card number 80. response to receipt of a confirmation from the end user, the application 17 of the client device 12 can then generate another bar code 84. In the exemplary embodiment illustrated in FIG. 4, the bar code 84 is also a QR code; however, it will be appreciated that other types of bar codes may also be used. The bar code 84 includes other encrypted payload data. The generation of these encrypted payload data is described below.

The application 27 of the client device 12 can first generate a symmetric key S3 and its initial vector 13. The application 27 of the client device 12 can then concatenate both the symmetric key S3 and the initial vector 13 and sign the result with the secret key PrivP to obtain (S3,13) * p.

The symmetric key S3, the initial vector 13 and (S3,13) '"p can then be coded with the public certificate PubA on the basis of an OAEP filling scheme to obtain (S3,13, [S3,13] * p) "a. Application 27 of client device 12 may then construct payload data L. Specifically, payload data L may include (S3,13, [S3, I3] '" p) "a and the token T of the credit card. The payload data L is then signed with the secret key PrivP to obtain L * p. The payload data L and the signed payload data L * p are also signed with the symmetric key S3 to obtain (L, L ** P) 's3. Finally, the concatenated certificate of the public key certP, (S3,13, [S3,13] * P) "a and (L, L * p)" S3 are concatenated to create the encrypted payload data.

The application 27 of the client device 12 pept then publish the QR code 84 on the screen 24. Once the end user sees that the QR code 84 has been published on the screen 24 of the client device 12, the end user can then position the client device 12 so that the QR code 84 is read by the optical device 30 of the merchant system 14 using the visible light communication. The merchant system 14 can then send the QR code 84 or the QR code payload data via the network 26 to the server 16. The server 16 can then decode and validate the encrypted, payload data contained in the QR code 84. In particular, the server 16 can validate the encrypted payload data in order to obtain the credit card token T. It will be noted that the transaction can be canceled before the validation. Thus, no payment can be made using the end user's credit card.

The server 16 can validate the encrypted payload data by obtaining the symmetric key S3, the initial vector 13 and (S3, I3) '"p and decrypt these values using the PrivA private certificate. check the signature (S3,13) '"? of the symmetric key S3 and the initial vector 13 using the concatenated certificate of the public key certP to obtain the payload data L and the signed payload data L '* p. The signed data of the payload L "" are then verified by the concatenated certificate of the public key certP The validation of the encrypted payload data enables the server 16 to recover the number of the original credit card N of the vault. of chips 18.

Once the original credit card number has been recovered, the server 16 can then make a payment authorization to obtain authorization from the issuer of the credit card. Specifically, the server 16 may send a request via the network 26 to the payment network 34 to determine whether the credit card number N is valid and whether the credit card issuer agrees to the payment. The payment network 34 may return the authorization to the server 16 via the network 26. In response to the receipt of the payment authorization of the payment network, the server 16 can then send a response to the merchant system 14 via the network 26. The answer indicates that the credit card number N is valid and the payment has been confirmed by the credit card issuer.

In response to receiving the response from the server 16, the merchant system 14 can generate a payment receipt. In particular, the merchant application 28 of the merchant system 14 may generate a payment receipt that is contained in the barcode (not shown). The barcode can be published on the screen 32 of the merchant system 14. The end user can then position the client device 12 so that the camera 22 can scan the barcode published on the screen 32 of the merchant system 14 .

Referring generally to the drawings, the disclosed system provides a convenient and user-friendly approach for the client device to communicate with the merchant system, even if the client device has little or no connectivity to a network. It should be noted that the traveler may not be able to connect to the Internet while traveling, especially when traveling to foreign countries or places in the world where network connectivity is limited or non-existent. Indeed, the disclosed system uses existing hardware on a client device (eg, the camera) to scan and decode a barcode that is published on the merchant system screen. The disclosed system provides a more efficient approach to the problem. traveler, allowing him to pay a travel reservation without the need for his physical credit card. In other words, travelers no longer need to look for their physical credit card, which can be hard to find, and noticeable when the traveler carries many bags while on the move. Finally, business cards, cards shared, loyalty points, or even virtual credit cards can also be used.

Generally the routines executed to implement the embodiments of the invention, whether implemented in the context of an operating system or a specific application, a component of a program , an object of a module or sequence of instructions, or even a subset thereof, may be referred to herein as "computer program code" or simply "program code." Program code typically includes computer readable instructions that reside at various times in various memory and storage devices in a computer and, when read and executed by one or more processors in a computer, bring the computer to perform the operations necessary to perform operations and / or elements specific to the implementation of various aspects of the embodiments of the invention. Computer-readable program instructions for carrying out the operations of the embodiments of the invention may be, for example, assembly language, or source code or object code written in combination with one or more several programming languages.

[0054] Various program codes described herein may be identified according to the application in which they are implemented in specific embodiments of the invention. However, it will be noted that any nomenclature of a particular program in the following is used solely for convenience; thus the invention can not be limited to a single use in any specific application identified and / or implied by said nomenclature. Moreover, in view of the generally infinite number of means by which computer programs can be organized according to subroutines, procedures, processes, modules, objects, and so on, as well as the various ways of affecting the functionalities of a program among various layers of software that are resident in a typical computer (eg, operating systems, libraries, program application interfaces [APIs], applications, short applications [applets], etc. .), it will be appreciated that the embodiments of the invention are not limited to the specific organization or assignment of the program features as described herein.

[0055] The program code implemented in any application / module described herein may be distributed individually or collectively as a computer program product in a variety of forms. In particular, the program code may be distributed using a computer readable storage medium having computer readable program instructions, allowing a processor to perform aspects of the embodiments of the invention.

Machine readable storage media being inherently non-transient, may include volatile and nonvolatile, removable and non-removable tangible media, implemented in any information storage method or technology, such as program instructions readable by machine, data structures, program modules, or other data. Computer readable storage media may also include RAMs, ROMs, EPROMs (read-only, programmable and erasable memory), flash memory, or any solid storage media technology, CD-ROM (portable compact disc with read-only memory), or any other optical storage, magnetic recording tapes, magnetic disk storage, or any other medium that can be used to store the desired information, and readable by a computer. A computer-readable storage medium can not be interpreted as "transient signals" per se (for example, radio waves or any other electromagnetic wave propagating through a transmission medium such as a waveguide, or signals electric cables transmitted by cable). The computer readable program instructions may be downloaded to a computer, another type of programmable data processing apparatus, or to any other machine-readable storage medium device, or to an external computer or to an external storage device via a network.

The computer readable program instructions, recorded on a computer readable medium, can be used to bring a computer, other types of programmable data processing apparatus, or other devices, to operate. a particular way, so that the instructions recorded on a computer-readable medium produce an article of manufacture comprising the instructions that implement the functions, actions and / or operations specified in the flowcharts, sequence diagrams, and / or blocks. The computer program instructions may be provided to one or more processors of a general purpose computer, a dedicated computer, or other programmable data processing apparatus for producing a machine, so that the instructions, when executed at using the processor (s), perform a series of calculations to implement the functions, actions, and / or operations specified in the flow charts, block diagrams, and / or block diagrams.

In certain other embodiments, the functions, actions, and / or operations specified in the flowcharts, sequence diagrams, and / or block diagrams may be repeatedly commanded, serially processed, and / or processed. at the same time in accordance with the embodiments of the invention. In addition, any flow chart, block diagram, and / or block diagram may include more or less blocks than those illustrated while remaining consistent with the embodiments of the invention.

The terminology used herein is intended to describe only particular embodiments and is not intended to limit the embodiments of the invention. In addition, the terms "includes", "include" and / or "including", when used in these specifications, specify the presence of characteristics, integers, stages, operations, elements, and / or components, but do not exclude the presence or addition of one or more characteristics, integers, steps, elements, components and / or groups, in that. Moreover, to the extent that the verb forms "includes", "having", "a", or variants, are used in the detailed description of the claims, these terms are meant to be inclusive in a manner similar to the verb "to understand".

Although the invention is illustrated by a description of various embodiments, and although these embodiments are described in great detail, it is not the intention of the applicant to restrict or limit, in any way, the scope of the claims herein to these details. Additional benefits and possible modifications will be readily apparent to those skilled in the art. The invention in a broader perspective is therefore not limited to the specific details, representative methods and apparatus, or the illustrations shown and described by way of example. Therefore, it is possible to move away from these details without departing from the spirit and scope of the applicant's general inventive concept.

Claims (15)

A system for securely exchanging a credit card token between a first computer and an external computer for the purchase of a product, the system comprising: the external computer; the first computer with one or more processors, a camera coupled to one or more processors, and a memory coupled to one or more processors, the memory storing data including a database and a program code which, when executed by one or more processors, causes the system to: scan the first barcode using the camera, wherein the first barcode is published on a display screen of the external computer and the first barcode indicates a plurality of payment parameters of the product; decode the first barcode to extract the payment parameters; Publish payment settings for viewing to the user receive a first entry, in which the first entry indicates a credit card number for the purchase of a product and a credit card token corresponding to the credit card number, is stored in the memory; in response to receiving the first input, generating a second barcode that contains the first encrypted payload data, wherein the first payload encrypted data includes the credit card token and issuing the second barcode for display in which the second barcode is readable by an optical device of the external computer. The system of claim 1 further comprising: a third computer in communication with the external computer in which the external computer is configured to send the second barcode to the third computer; and a token vault in communication with the third computer; wherein the third computer is configured to decode the second barcode, to validate the contents of the encrypted payload data to obtain the credit card token and to retrieve a number from an original credit card in the vault of tokens based on the credit card token. The system of claim 2 wherein the third computer is configured to communicate with a payment network to determine whether the original credit card number is valid, and in response to the original credit card number. valid, the payment network authorizes the payment of the product and sends an authorization to the third computer. The system of claim 3 wherein the external computer is configured to receive the payment authorization for the product from the third computer, to generate a third barcode that contains a payment receipt for the product, and to publish the third barcode for display, wherein the third barcode is digitized using the camera. The system of claim 1 wherein the first computer and a third computer are connected to a network prior to the scanning of the first barcode by the camera, wherein the first computer is configured to: receive a second input indicating the number credit card; generating second payload encrypted data which contains the credit card number, in response to receiving the second input; transmitting a card provisioning request including the second encrypted payload data via the network, wherein the third computer is configured to: receive the card provisioning request over the network, decrypt the second encrypted payload times, in response upon receipt of a card provisioning request, to retrieve the credit card number, send the credit card number to a tokenization application, and wherein, in response to receipt of the card number of credit, the tokenization application generates a credit card token The system of claim 5 wherein the credit card token number is stored in a vault of tokens and is also transmitted via the network of the third computer to the first computer, and wherein the first computer is configured to hold the token of the credit card in memory in the form of a digital fingerprint. The system of any one of claims 1 to 6 wherein one or more processors are part of a mobile electronic device. A method for securely exchanging a credit card token between a first computer and an external computer as part of the purchase of a product, the method comprising: digitizing a first barcode by a camera of a first computer, wherein the first barcode is published on a display screen of the external computer and the first barcode indicates a plurality of payment parameters of the product; decoding the first barcode, by the first computer, to extract the payment parameters; the publication by the first computer of the payment parameters for display to the user; receiving, by the first computer, a first entry, in which the first entry indicates a credit card number for the purchase of a product and the saving in the memory of the first computer of a credit card token; credit corresponding to the number of the credit card; in response to receiving a first input, generating by the first computer, a second barcode which contains first encrypted payload data, wherein the first encrypted payload data includes the card token credit ; and publishing by the first computer the second barcode for display, wherein the second barcode is readable by an optical device of the external computer. 9. The method of claim 8 further comprising: sending on the network, by the external computer, a second barcode to a third computer; decoding the second barcode by the third computer; validating the contents of the first encrypted payload data by the third computer to obtain the credit card token; and retrieving, by the third computer, an original credit card number of a token vault, based on the credit card token 10. The method of claim 9 further comprising: sending, by the third computer, a communication to a payment network; in response to the receipt of the communication, the payment network determines the validity of the number of the original credit card; in response to the original credit card number being valid, the payment network authorizes payment for the product via the payment network; and sending, via the payment network, an authorization to the third computer. 11. The method of claim 10 further comprising: receiving, by the third computer, the authorization for the payment of the product; sending the authorization via the network to the external computer; the generation by the external computer of a third barcode which contains a payment receipt for the product; and publishing, by the external computer, the third barcode for display, wherein the third barcode is digitized by the camera of the first computer. The method of claim 8 further comprising: prior to scanning the first barcode by the first computer, connecting the first computer and the third computer to the network; receiving, by the first computer, a second entry indicating the credit card number; in response to receiving the second input, generating, by the first computer, second encrypted payload data containing the credit card number; transmitting, by the first computer, a card provisioning request including the second encrypted payload data via the network; the receipt by the third computer of the card provisioning request from the network; and in response to receiving the card provisioning request, decrypting, by the third computer, second encrypted payload data to retrieve the credit card number; sending, by the third computer, the credit card number to a tokenization application; and. in response to the reception of the credit card number, the generation, by the tokenization application, of the credit card token. 13. The method of claim 12 further comprising: the backup by the third computer, the credit card token in a vault of tokens; the transmission by the third computer of the credit card token on the network; receiving on the network, by the first computer, the credit card token; and registering the credit card token, in the form of a digital fingerprint, in the memory of the first computer. The method of any one of claims 8 to 13 wherein the first computer is a portable electronic device. 15. A computer program product for the secure exchange of a credit card token with an external computer as part of the purchase of a product, the computer program product comprising: portions / program code means / instructions recorded on a computer readable medium for implementing the steps of the method according to any one of claims 8 to 14 when said program is running on a computer.