Late binding tokens

• US 8,060,448 B2
• Filed: 05/28/2002
• Issued: 11/15/2011
• Est. Priority Date: 05/30/2001
• Status: Active Grant

• Current Assignee: Thomas C. Jones
• Original Assignee: Thomas C. Jones
• Inventors: Jones, Thomas C.
• Primary Examiner(s): Agwumezie; Charles C
• Application Number:
  US10/156,734
• Publication Number:
  US 20020184149A1
• Time in Patent Office: 3,458 Days
• Field of Search: 705/64, 705/65, 705/66, 705/67, 705/75, 705/76, 705/50, 709/219
• US Class Current: 705/65
• CPC Class Codes: G06Q 20/105 involving programming of a portable memory device, e.g. IC cards, "electronic purses"
• CPC Class Codes: G06Q 20/12 specially adapted for electronic shopping systems
• CPC Class Codes: G06Q 20/367 involving electronic purses or money safes
• CPC Class Codes: G06Q 20/3674 involving authentication
• CPC Class Codes: G06Q 20/401 Transaction verification
• CPC Class Codes: G06Q 30/04 Billing or invoicing

Abstract

A system for verifying intent in a card not present transaction is provided. The system includes a late binding token that is distributable to consumers without necessarily being bound to an account. The system also includes a client software that locates a token server configured to facilitate managing and communicating with the late binding token. The system also includes a protocol concerning how to build a verifiably secure structured proposal that carries an offer to the consumer through the client software.

Claims

1. A late binding token system, comprising:

a token server of an issuer, the token server communicating with a network;

a merchant server communicating with the network;

an account server, storing information for a consumer, communicating with the network;

a physical late binding token, from the issuer, including a locator code initially binding the late binding token to only the token server when the consumer receives the physical late binding token, and including a memory for storing a public/private key pair;

a client software communicating with the late binding token server and at least one of the merchant server and the account server for verifying the bindings of the physical late binding token with the token server, the merchant server and the account server, the consumer communicating with at least one of the merchant server and the account server via the client software to perform a transaction;

first software associated with the late binding token and executable by said client software for retrieving said locator code from said physical late binding token for establishing communication between said client software and the token server via the network, the first software verifying the physical late binding token to the token server; and

second software, provided to said client software via the network, for binding the consumer to the account server, for transactions between the client software, the merchant server, the account server, the late binding token, and the token server;

wherein the second software binds the token to the account server only after the first software verifies the late binding token with the token server; and

wherein if the token server has previously verified the late binding token and if the late binding token has been previously bound to the account server, the token server requests payment from the account server to the merchant server while only disclosing selected information of the consumer to the merchant server.

2. The system of claim 1, where the client software comprises:

a first logic for receiving a token server communication logic;

a second logic for receiving a structured proposal to present to a consumer;

a third logic for securely displaying the structured proposal to the consumer;

a fourth logic for recognizing an indicia of consumer acceptance of an offer in a displayed structured proposal;

a fifth logic for hashing a structured proposal and an indicia of consumer acceptance into an unsigned hash to transmit to the late binding token; and

a sixth logic for providing an unsigned hash to the late binding token and receiving a signed hash from the token.

3. The system of claim 2, comprising:

a seventh logic for bundling one or more of an unsigned hash, an indicia of consumer acceptance, a signed hash, a late binding token identifier, and a client software identifier into a bundle; and

an eighth logic for digitally signing a bundle.

4. The system of claim 1, where the late binding token comprises:

a first token logic for communicating with the client software;

a second token logic for digitally signing an unsigned hash received from the client software; and

wherein the memory stores at least one of, a token server URL, and the public/private key pair.

5. The system of claim 1, where the token server comprises:

one or more token server communication logics associated with one or more late binding token types; and

a first token server logic for selectively transmitting one or more token server communication logics to a client software in response to a download request from the client software.

6. The system of claim 5, comprising:

a second token server logic for receiving a digitally signed bundle from the client software; and

a third token server logic for determining a security assurance level of the digitally signed bundle.

7. The system of claim 1, comprising:

a structured proposal protocol that specifies at least one of, the format of a structured proposal, the content of a structured proposal, the size of a structured proposal, fields required for a structured proposal, an encryption technique for encrypting a structured proposal, and a structured proposal schema.

8. The system of claim 7, comprising a structured proposal generator that compiles a merchant offer into a structured proposal that can be received by the client software.

9. The system of claim 7, where a structured proposal comprises a digital merchant trademark.

10. The system of claim 1, comprising a verifier for determining a security assurance level of a digitally signed bundle.

11. The system of claim 10, the verifier comprising a first verifier logic for determining whether a consumer has sufficient funds to complete a transaction associated with the digitally signed bundle.

19. The system of claim 1, wherein the merchant server communicates with the token server for requesting payment authorization from the account server to complete the transaction.

21. The system of claim 1, wherein the second software binds the token to the account without altering the token.

12. A method for securely indicating verifiable consumer intent to enter into a transaction, comprising:

receiving a physical late binding token of an issuer, the late binding token including a memory for storing a public/private key pair communicating with a network and including a locator code initially binding the late binding token to only an associated token server of the issuer when a consumer receives the late binding token;

verifying the bindings of the physical late binding token via a client software communicating with the token server and at least one of a merchant server, a consumer, an account server storing information for the consumer, and the late binding token;

communicating with the merchant server via the client software to perform a consumer transaction;

executing a first software, associated with the late binding token, for retrieving the locator code from the late binding token for establishing a communication link between the physical late binding token and the token server, via the network, initially binding the physical late binding token to the token server, and verifying the late binding token to the token server;

providing a second software to the client software via the network, for binding the consumer to the account server for transactions between the client software, the merchant server, the account server, the late binding token, and the token server, to create respective bindings between the late binding token and at least one of the consumer and the account server;

verifying that the offering from the merchant was correctly displayed to the user via the second software, only after the first software verifies the late binding token with the token server; and

if the display of the offering from the merchant was successfully verified, verifying that the input from the user was correctly communicated to at least one of the merchant server or the account server while only disclosing selected information of the consumer to the merchant.

13. The method of claim 12, where the transaction is a card not present transaction.

14. The method of claim 12, comprising:

receiving a structured proposal that comprises an offer to enter into a transaction;

displaying the structured proposal to a consumer, where the structured proposal is displayed in a secure window; and

determining whether the consumer accepts the offer.

15. The method of claim 12, comprising:

binding the late binding token to one or more items to make a bound token.

16. The method of claim 15, where the items include at least one of, a credit account, a debit account, a merchant account, a frequent flyer account;

and a prepaid account.

17. The method of claim 15, comprising:

hashing a structured proposal and an indicia of consumer acceptance of an offer into an unsigned hash;

providing the unsigned hash to the token; and

receiving a digitally signed hash from the token.

18. The method of claim 17, comprising:

bundling the unsigned hash, the digitally signed hash, and one or more identifiers associated with at least one of, the token, and the second software into a bundle;

digitally signing the bundle; and

providing the signed bundle to a bundle verifier.

20. The method of claim 12, further including:

transmitting a payment request from the merchant server to the token server for requesting payment authorization from the account server to complete the transaction.