Integration of Payment Capability into Secure Elements of Computers

• US 20120226582A1
• Filed: 03/02/2012
• Published: 09/06/2012
• Est. Priority Date: 02/24/2010
• Status: Active Grant

• Current Assignee: Visa International Service Association (Visa, Inc.)
• Original Assignee: Visa International Service Association (Visa, Inc.)
• Inventors: Hammad, Ayman
• Granted Patent: US 9,424,413 B2
• Time in Patent Office: Days
• US Class Current: 705/26.41
• CPC Class Codes: G06F 16/2457 with adaptation to user needs
• CPC Class Codes: G06F 21/34 involving the use of external additional devices, e.g. dongles or smart cards
• CPC Class Codes: G06F 2221/2129 Authenticate client device independently of the user
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/227 characterised in that multiple accounts are available, e.g. to the payer
• CPC Class Codes: G06Q 20/385 using an alias or single-use codes
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G06Q 20/401 Transaction verification
• CPC Class Codes: G06Q 20/42 Confirmation, e.g. check or permission by the legal debtor of payment
• CPC Class Codes: G06Q 20/425 using two different networks, one for transaction and one for security confirmation
• CPC Class Codes: H04L 2209/56 Financial cryptography, e.g. electronic payment or e-cash
• CPC Class Codes: H04L 63/0428 wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• CPC Class Codes: H04L 63/06 for supporting key management in a packet data network cryptographic mechanisms or cryptographic arrangements for key management H04L9/08
• CPC Class Codes: H04L 63/0853 using an additional device, e.g. smartcard, SIM or a different communication terminal cryptographic mechanisms or cryptographic arrangements for entity authentication involving additional secure or trusted devices H04L9/3234
• CPC Class Codes: H04L 63/102 Entity profiles
• CPC Class Codes: H04L 63/126 the source of the received data
• CPC Class Codes: H04L 63/1441 Countermeasures against malicious traffic countermeasures against attacks on cryptographic mechanisms H04L9/002
• CPC Class Codes: H04L 9/14 using a plurality of keys or algorithms
• CPC Class Codes: H04L 9/3234 involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token network architectures or network communication protocols for supporting authentication of entities using an additional device in a packet data network H04L63/0853

Abstract

Methods, secure elements, validation entities, and computer program products for effecting secure communication of payment information to merchants for Internet-based purchases. Payment information for a user'"'"'s real payment information is installed in a secure element of a computer, the payment information may comprise a pseudo PAN number for the portable consumer device provided by a validation entity. The secure element is shielded from the computer'"'"'s operating system to thwart hacker attacks. The user accesses the secure element to make a purchase. In response, the secure element contacts the validation entity with the pseudo account number, and in response obtains dynamic payment information that the secure element can used to effect the payment. The dynamic payment information comprises an account number that is different from the pseudo PAN, and which has at least one difference which respect to the user'"'"'s real payment information.

Claims

1. A method comprising:

receiving, at a secure element of a computer, a real account number and at least one of an expiration date, a card verification value, or a billing ZIP code of user-specific payment information;

obtaining an identifier for the secure element;

sending the received real account number, the received at least one of an expiration date, a card verification value, or a billing ZIP code, and the obtained identifier for the secure element to a validation entity;

receiving, in response, a pseudo account number from the validation entity, the received pseudo account number being different from the real account number of the user-specific payment information; and

storing, in a memory of the secure element, the received pseudo account number.

2. The method of claim 1, further comprising:

sending, from the secure element of a computer, a representation of the pseudo account number to a validation entity; and

receiving, in response, dynamic payment information from the validation entity, the received dynamic payment information having an account number that is different from the pseudo account number.

3. The method of claim 2, wherein sending the representation of the pseudo account number comprises generating the representation as a cryptogram based on the pseudo account number.

4. The method of claim 2, wherein sending the representation of the pseudo account number comprises generating the representation as a cryptogram based on the pseudo account number and the identifier for the secure element.

5. A computer program product embodied on a tangible non-transitory computer-readable medium to be executed by a secure element of a computer, the product comprising:

code that directs a data processor to receive a real account number and at least one of an expiration date, a card verification value, or a billing ZIP code of user-specific payment information;

code that directs a data processor to obtain an identifier for the secure element;

code that directs a data processor to send the received real account number, the received at least one of an expiration date, a card verification value, or a billing ZIP code, and the obtained identifier for the secure element to a validation entity;

code that directs a data processor to receive, in response, a pseudo account number from the validation entity, the received pseudo account number being different from the real account number of the user-specific payment information; and

code that directs a data processor to store, in a memory of the secure element, the received pseudo account number.

6. The computer program product of claim 5, further comprising:

code that directs a data processor to send, from the secure element of a computer, a representation of the pseudo account number to a validation entity; and

code that directs a data processor to receive, in response, dynamic payment information from the validation entity, the received dynamic payment information having an account number that is different from the pseudo account number.

7. The computer program product of claim 6, wherein the code that directs the data processor to send the representation of the pseudo account number comprises code that directs the data processor to generate the representation as a cryptogram based on the pseudo account number and the identifier for the secure element.

8. A secure element in a computer, the secure element comprising:

a tangible non-transitory computer-readable memory;

a data processor electrically coupled to the computer-readable memory; and

a computer program product according to claim 5 embodied on the computer-readable medium.

9. A method comprising:

receiving, at a validation entity server, a request from a secure element of a computer to provide a pseudo account number, the request including an identifier of the secure element, and a real account number and at least one of an expiration date, a card verification value, or a billing ZIP code of an instance of user-specific payment information;

applying at least one validation test pertaining to the received request;

sending, if the at least one validation test is passed, a pseudo account number to the secure element; and

storing the pseudo account number with an indication of at least the received real account number.

10. The method of claim 9, further comprising:

receiving, at the validation entity server, a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number and an identifier of a secure element;

applying at least one validation test pertaining to the received request; and

sending, if the at least one validation test is passed, dynamic payment information to the secure element.

11. The method of claim 9, further comprising:

receiving, at the validation entity server, a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number, an identifier of a secure element, and an identifier of a merchant;

applying at least one validation test pertaining to the received request; and

sending, if the at least one validation test is passed, dynamic payment information to a merchant indicated by the received merchant identifier.

12. The method of claim 9, further comprising:

receiving, at the validation entity server, a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number, an identifier of the secure element, and an identifier of a merchant;

applying at least one validation test pertaining to the received request;

sending, if the at least one validation test is passed, dynamic payment information to the secure element; and

sending, if the at least one validation test is passed, said dynamic payment information and an indication of the identity of the merchant to a payment processing network.

13. The method of claim 9, further comprising:

receiving, at the validation entity server, a request from a payment processing network to provide real payment information corresponding to an instance of dynamic payment information; and

providing the requested real payment information to the payment processing network.

14. A validation entity comprising:

a data processor;

a networking facility coupled to the processor;

a computer-readable medium coupled to the processor; and

a computer program product embodied on the computer-readable medium, the computer program product comprising;

code that directs the data processor to receive a request from a secure element of a computer to provide a pseudo account number, the request including an identifier of the secure element, and a real account number and at least one of an expiration date, a card verification value, or a billing ZIP code of an instance of user-specific payment information;

code that directs the data processor to apply at least one validation test pertaining to the received request for a pseudo account number;

code that directs the data processor to send, if the at least one validation test is passed, a pseudo account number to the secure element; and

code that directs the data processor to store the pseudo account number with an indication of at least the received real account number.

15. The validation entity of claim 14, wherein the computer program product further comprising:

code that directs the data processor to receive a request from a secure element of a computer to provide dynamic payment information, the request including a pseudo account number and an identifier of the secure element;

code that directs the data processor to apply at least one validation test pertaining to the received request for dynamic payment information; and

code that directs the data processor to send, if the at least one validation test is passed, dynamic payment information to the secure element.

16. The validation entity of claim 14, wherein the code that directs the data processor to apply at least one validation test pertaining to the received request for a pseudo account number comprises at least one of the following instructions:

instructions that direct the data processor to compare the receive identifier of the secure element against a database of valid identifiers to find a match; and

instructions that direct the data processor to compare the receive identifier of the secure element against a database of identifiers of secure elements involved in prior fraudulent activity.

17. The validation entity of claim 14, wherein the code that directs the data processor to apply at least one validation test pertaining to the received request for a pseudo account number comprises:

instructions that direct the data processor to obtain the real payment information for the received account number from a database or the bank that issued the user-specific payment information; and

instructions that direct the data processor to compare the received at least one of an expiration date, a card verification value, or a billing ZIP code to the real payment information for the received account number for a match.

18. The validation entity of claim 14, wherein the code that directs the data processor to apply at least one validation test pertaining to the received request for a pseudo account number comprises:

instructions that direct the data processor to access a database to determine the limit on the number of secure elements that has been placed on the received real account number;

instructions that direct the data processor to access a database to determine the current number of secure elements that have already been associated to the received real account number; and

instructions that direct the data processor to compare the current number to the limit to determine if and additional associate of a secure element would exceed the limit.

19. The validation entity of claim 15, wherein the code that directs the data processor to apply at least one validation test pertaining to the received request for a pseudo account number comprises at least one of the following instructions:

instructions that direct the data processor to compare the receive identifier of the secure element against a database of valid identifiers to find a match;

instructions that direct the data processor to compare the receive identifier of the secure element against a database of identifiers of secure elements involved in prior fraudulent activity; and

instructions that direct the data processor to access a database to obtain the record for the received pseudo account number, to obtain from the record the identifiers for all of the secure elements that have been previously associated with the received pseudo account number, and to compare the identifier for the secure element received in the request against each identifier in the accessed record for a match.