Secure authentication system and method

• US 9,792,611 B2
• Filed: 06/05/2015
• Issued: 10/17/2017
• Est. Priority Date: 05/15/2009
• Status: Active Grant

• Current Assignee: Visa International Service Association (Visa, Inc.)
• Original Assignee: Visa International Service Association (Visa, Inc.)
• Inventors: Hammad, Ayman, Faith, Patrick, Koganti, Krishna Prasad, Rewis, Ben, Louis, Brendan Xavier, Weller, Kevin, Dominguez, Benedicto Hernandez
• Primary Examiner(s): Lee, Michael G
• Assistant Examiner(s): Tardif, David
• Application Number:
  US14/732,294
• Publication Number:
  US 20150379515A1
• Time in Patent Office: 865 Days
• Field of Search: 235492
• 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/3674 involving authentication
• CPC Class Codes: G06Q 20/3821 Electronic credentials
• 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/409 Device specific authentication in transaction processing
• 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: G06Q 2220/00 Business processing using cryptography postage metering system using cryptography G06Q2250/05
• CPC Class Codes: G06Q 30/06 Buying, selling or leasing transactions
• CPC Class Codes: H04L 2209/56 Financial cryptography, e.g. electronic payment or e-cash
• 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/126 the source of the received data
• CPC Class Codes: H04L 9/0866 involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
• CPC Class Codes: H04L 9/321 involving a third party or a trusted authority
• 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
• CPC Class Codes: H04L 9/3273 for mutual authentication network architectures or network communication protocols for achieving mutual authentication in a packet data network H04L63/0869

Abstract

Methods and systems pertaining secure transaction systems are disclosed. In one implementation, a verification token is associated with a computer and can send user authentication data as well as a secure datum to a control server. The verification token may obtain the secure datum from a validation entity. The control server can validate the secure datum and authentication data and can generate a payer authentication response.

Claims

1. A method comprising:

sending, by a control server, a Purchase Authentication Page to a computer over a communications network, the Purchase Authentication Page having a user response posting field to receive a response from a user to authenticate the user;

receiving, by the control server, a returned Purchase Authentication Page from the computer over the communications network, the returned Purchase Authentication Page having a user response disposed in the user response posting field and a secure datum received from a verification token associated with the computer;

comparing, by the control server, at least a portion of the received user response to a stored user response to make a first determination of whether a match exists;

comparing, by the control server, the received secure datum to a stored secure datum to make a second determination of whether a match exists; and

generating, by the control server, a Payer Authentication Response message based on at least the first and second determinations.

2. The method of claim 1 wherein the secure datum was received by the verification token from a validation entity after the validation entity validates information received from the verification token.

3. The method of claim 1 wherein the secure datum is generated based on an identity of a merchant with which the user conducts a transaction, and a date or time of the transaction.

4. The method of claim 1 wherein the secure datum is generated based on an identifier associated with the verification token or an IP address of the computer.

5. The method of claim 1 wherein the verification token comprises a data processor and a computer readable medium comprising code, executable by the processor, for causing the verification token to read portable consumer device identification information from the portable consumer device, the portable consumer device being used by the user.

6. The method of claim 5 wherein the portable consumer device is a credit card.

7. The method of claim 1 wherein the control server is an access control server.

8. A control server comprising:

a processor; and

a computer readable medium, the computer readable medium comprising code, executable by the processor, for implementing a method comprising

sending, by a control server, a Purchase Authentication Page to a computer over a communications network, the Purchase Authentication Page having a user response posting field to receive a response from a user to authenticate the user,

receiving, by the control server, a returned Purchase Authentication Page from the computer over the communications network, the returned Purchase Authentication Page having a user response disposed in the user response posting field and a secure datum received from a verification token associated with the computer,

comparing, by the control server, at least a portion of the received user response to a stored user response to make a first determination of whether a match exists,

comparing, by the control server, the received secure datum to a stored secure datum to make a second determination of whether a match exists, and

generating, by the control server, a Payer Authentication Response message based on at least the first and second determinations.

9. The control server of claim 8 wherein the secure datum is generated based on at least two of an identity of a merchant with which the user conducts a transaction, a date or time of the transaction, an identifier associated with the verification token, and an IP address of the computer.

10. The control server of claim 8 wherein the secure datum was received by the verification token from a validation entity after the validation entity validates information received from the verification token.

11. The control server of claim 8, wherein the method further comprises:

receiving the secure datum from a validation entity before receiving the secure datum from the verification token.

12. A system comprising:

the control server of claim 8; and

the computer in communication with the control server.

13. The system of claim 12 further comprising:

a validation entity in communication with the computer.

14. A method comprising:

obtaining, by a control server, a risk assessment for a transaction;

generating and sending, by the control server, a Purchase Authentication Page to a computer with page display parameters that cause the Purchase Authentication Page to not be visible or to not be fully visible on a display of the computer if the risk assessment is below a threshold value; and

sending, by the control server, the Purchase Authentication Page to the computer with page display parameters that cause the Purchase Authentication Page to be visible on the display of the computer if the risk assessment is above the threshold value.

15. The method of claim 14 wherein the risk assessment is performed based upon data from a directory server.

16. The method of claim 14, wherein

the Purchase Authenticate Page is sent to the computer with display parameters which cause the Purchase Authentication Page to be in hidden form to a user on the computer.

17. The method of claim 14 further comprising:

receiving, by the control server, a secure datum from a verification token associated with the computer, wherein the secure datum is a 3-D secure datum.

18. The method of claim 14 further comprising:

receiving, by the control server, a secure datum from a verification token associated with the computer.

19. The method of claim 14 further comprising:

receiving, by the control server, a secure datum from a verification token associated with the computer.

20. The method of claim 19 wherein the verification token is in the form of a USB stick.