|Publication number||USRE40444 E1|
|Application number||US 10/622,058|
|Publication date||Jul 29, 2008|
|Filing date||Jul 17, 2003|
|Priority date||Dec 29, 1998|
|Also published as||EP1017030A2, EP1017030A3, US6327578|
|Publication number||10622058, 622058, US RE40444 E1, US RE40444E1, US-E1-RE40444, USRE40444 E1, USRE40444E1|
|Original Assignee||International Business Machines Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (39), Non-Patent Citations (11), Referenced by (42), Classifications (15), Legal Events (12)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a reissue application for U.S. Pat. No. 6,327,578 issued Dec. 4, 2001 on U.S. Ser. No. 09/221,869 filed Dec. 29, 1998.
The invention disclosed broadly relates to computer networks and more particularly relates to electronic commerce.
Electronic commerce is projected to grow at a high rate and this will have a significant impact on the financial industry. Estimates for 1998 are 700 million dollars worth of total revenues. Further growth promises $1 trillion by 2010. No financial institution will be left unaffected by the rapid growth of electronic commerce. One obstacle that can inhibit this growth, however, is the lack of secure electronic payments. Consumers and merchants are wary of transmitting their payment information over open networks such as the Internet and this caution affects the interest of merchants and financial institutions.
The technology of electronic commerce has adopted a number of terms that need to be defined in order to discuss the prior art and the invention. A short glossary of such terms follows.
The prior art SET Secure Electronic Transaction™ (trademark and service mark owned by SET Secure Electronic Transaction LLC) protocol has been developed as a method to secure bankcard transactions over public networks. SET is an open standard, multi-party protocol for conducting secure bankcard payments over the Internet. SET provides message integrity, authentication of all financial data, and encryption of sensitive data.
SET is a 3-party protocol involving a cardholding consumer, a merchant, and a payment gateway operating on behalf of the acquiring bank, as shown in FIG. 1. When a consumer is ready to buy something from a merchant on the internet using a credit or debit card, the consumer's computer 102 sends a consumer payment request over internet path 120 to the merchant's computer 104, in a first step. The merchant's computer 104 forwards the consumer's payment request over internet path 122 during a second step to an acquirer gateway 106 operating on behalf of the acquirer bank 108. The acquirer gateway 106 passes the consumer's payment request to the acquirer bank 108 over a private network path 122′. The acquirer bank 108 sends the consumer's payment request to the card issuing bank 112 over the private network path 124 to check whether the consumer's credit or debit card account is active and sufficient for the proposed transaction with the merchant. The issuing bank 112, as the card issuer, authorizes the transaction in a message sent over private path 126 to the acquiring bank 108. The acquiring bank 108 sends the transaction authorization over private path 128′ to the acquirer gateway 106, signing the message with the acquiring bank's digital signature. The acquirer gateway 106 forwards it over the internet path 128 to the merchant, authorizing the merchant to proceed with the transaction. Once the merchant has received the transaction authorization from the acquirer gateway 106, the merchant completes the sales transaction with the consumer. Then later, the merchant sends a message over internet path 142 to the acquirer gateway 106 to capture the transaction and get paid. The acquirer gateway then sends a payment message over path 144 to the merchant. The acquiring bank 108 may participate in some or all of the payment steps over private network paths 142′ and 144′. Then, at the end of the business day, the acquiring bank will settle accounts with the issuing bank 112 over the private network.
Some implementors of SET are providing “thin” wallets, where all or some of the wallet function are implemented in server systems rather than in consumer-controlled machines. Where the wallet servers are run by issuing banks, it would be desirable to have the wallet serves directly authorize transactions before they are submitted to merchants. This would save the time and complexity required when the merchants obtain authorization from issuers through the merchant's acquiring banks. It would also be desirable to expand the cardholder authentication methods supported by the SET protocol, to enable an issuer to independently choose alternate authentication mechanisms without changing the acquiring gateway. As with any system, it would also be desirable to simplify the SET protocol in order to enable its easier implementation and to improve its overall performance.
The invention disclosed herein is a method, system, program, and method of doing business for electronic commerce that expands the role of a “thin” consumer's wallet by providing issuers with an active role in each payment. This is achieved by adding an issuer gateway and moving the credit/debit card authorization function from the merchant to the issuer. This enables an issuer to independently choose alternate authentication mechanisms without changing the acquirer gateway. It also results in a significant reduction in complexity, thereby improving the ease of implementation and overall performance.
The method of the invention includes the step of sending from a consumer's computer a start message over an internet network to a merchant's computer. The merchant's computer then replies to the consumer's computer with a merchant message including a wallet initiation message, a merchant digital signature, and a digital certificate from an acquiring bank. The wallet initiation message includes a payment amount, an order description, a timestamp, and a nonce. This starts a consumer's wallet program in the consumer's computer in response to the wallet initiation message. The consumer's computer then sends over the internet network some consumer identity and authentication information, such as a userid and user password, plus the merchant message, to an issuer gateway operating on behalf of an issuing bank.
The issuer gateway verifies the merchants signature to prove that the consumer is dealing with the actual merchant and validates the merchant's certificate and the acquirer's certificate to prove that the merchant and issuer share a common financial arrangement. The issuer gateway then verifies that the consumer's account is active and has sufficient funds and/or credit to support the payment amount. The issuer gateway then pre-authorizes payment by sending over the internet network an authorization token, an issuer's digital certificate, the wallet initiation message, and a reference value representing the consumer's credit or debit card number. The authorization token includes the payment amount, order description, timestamp, a random nonce plus a merchant identifier and the reference to the consumer's credit or debit card number. The issuer gateway signs the authorization token. This information can be sent either to the consumer or to the merchant to fulfill the order description. If sent to the consumer, the consumer forwards the authorization token to the merchant. The merchant verifies the issuer's signature, issuer's digital certificate, and authorization token contents to validate that the payment is authorized by the issuer.
Once the merchant has received the authorization token from the issuer gateway, the merchant completes the sales transaction with the consumer. Then later, the merchant sends a message, including the reference value representing the consumer's card number, over the internet to an acquirer gateway operating on behalf of an acquirer bank, to capture the transaction and get paid. The acquiring bank will settle accounts with the issuing bank over a private network by sending a settlement message that includes the reference to the consumer's card number. The issuing bank will convert the reference value into the consumer's card number and apply the transaction amount to the consumer's balance in his credit card or deposit account.
If the transaction is later disputed, the merchant can prove that the issuer authorized the payment by producing a copy of the authorization token. The combination of the issuer's signature on the authorization token, the issuer's digital certificate, and the contents of the authorization token provide undeniable proof that the issuer authorized the payment.
If privacy is desired, the communication among the consumer wallet, issuer gateway, and merchant can be protected via the Secure Socket Layer (SSL) protocol.
SET was designed for both Web and email use. The start and wallet initiation messages described above would not be used in an email implementation, however, the rest of the invention would not change. The contents of the wallet initiation message in an email implementation comes from another source, such as a CD-ROM, in which case, it could not be signed.
In this manner, a “thin” wallet is enabled for the consumer in an electronic commerce protocol that is significantly simpler than the SET protocol, and that pre-authorizes payments thereby improving overall performance and enabling greater flexibility for issuer in the authentication of cardholders.
Another feature of the invention is providing a financial institution's digital certificate containing a network address or URL that identifies the network location of the financial institution contacted via an internet network as part of a payment protocol. This can be applied to both the issuing bank and the acquiring bank. Many other features of the invention are also disclosed.
The acquiring bank's digital certificate can contain a network address or URL that identifies the network location of the acquiring bank contacted via an internet network as part of a payment protocol.
The issuer gateway 214 verifies the merchant's signature to prove that the consumer is dealing with the actual merchant and validates the merchant's certificate and the acquirer's certificate to prove that the merchant and issuer share a common financial arrangement. The issuer gateway 214 then verifies that the consumer's account is active and has sufficient funds and/or credit to support the payment amount. Then, as shown in
The issuing bank's digital certificate can contain a network address or URL that identifies the network location of the issuing bank contacted via an internet network as part of a payment protocol.
Once the merchant 204 has received the authorization token 254 from the issuer gateway 214, the merchant 204 completes the sales transaction with the consumer 202. Then later, the merchant 204 sends a capture request message 256 over path 242, including the reference number 252′ representing the consumer's card number, over the internet to an acquirer gateway 206 operating on behalf of an acquirer bank 208, to capture the transaction and get paid. The acquiring bank 208 will settle accounts with the issuing bank 212 over a private network shown in
If the transaction is later disputed, the merchant 204 can prove that the issuer 212 authorized the payment by producing a copy of the authorization token 254. The combination of the issuer's signature on the authorization token, the issuer's digital certificate, and the contents of the authorization token provide undeniable proof that the issuer authorized the payment.
If privacy is desired, the communication among the consumer wallet, issuer gateway, and merchant can be protected via the Secure Socket Layer (SSL) protocol.
The invention can be applied to both the internet World Wide Web and to email use. The start message 220 and wallet initiation messages 222 described above would not be used in an email implementation, however, the rest of the invention would not change. The contents of the wallet initiation message in an email implementation comes from another source, such as a CD-ROM, in which case, it could not be signed.
In this manner, a “thin” wallet is enabled for the consumer in an electronic commerce protocol that is significantly simpler than the SET protocol, and that pre-authorizes payments, thereby improving overall performance and enabling greater flexibility for issuer in the authentication of cardholders.
The invention includes the use of a variety of methods to perform authentication of the consumer with the issuer gateway 214. Examples include a userid and a password, an ATM debit card number and PIN, a smart card's account number and a symmetric Message Authentication Code (MAC), a smart card's account number and asymmetric digital signature, a consumer's digital signature and digital certificate, a consumer's a user account number and a symmetric MAC or asymmetric digital signature , a user account number and an asymmetric digital signature, or a consumer's biometric signal. This wide choice of authentication methods between the consumer and the issuer gateway is possible because issuers have an active role in each payment. This enables an issuer to independently choose alternate authentication mechanisms without changing the acquirer gateway.
The resulting invention has many advantages. It fits well with server-based (thin) wallets (which would operate in the issuer gateways). It separates the authentication technology used between the consumer and issuing bank from the remainder of the payment protocol. It permits each issuing bank to determine how it will authenticate its consumers (e.g. userid/password, symmetric or asymmetric keys with or without digital certificates or smart cards, other security hardware). It avoids the use of digital certificates for consumers. It pre-authorizes payments, eliminating the cost and delay of real-time authorization through the private network between the acquirer and the issuer. It reduces overhead for merchant and payment gateway, since payments are authorized before they reach the merchant, and since much less cryptography is required. It provides protection for the credit or debit card number, without using encryption. It complies with U.S. export laws and foreign cryptography usage laws by not using any encryption. It has potential for lower development and testing costs (compare to SET) because of a simpler design. Examples of the simpler design include avoidance of encryption; elimination of the requirement for consumer certificates; and avoiding any requirement for the consumer wallet to validate certificates, generate digital signatures, or verify digital signatures. The invention supports Japanese Payment Options and other issuer-based payment features in a manner simpler than SET.
A more detailed discussion of the protocol steps follows:
Note that the authorization token is “bound” to the particular payment by the reference to the consumer's credit card number, merchant identifier, payment amount, timestamp, and nonce. This means that a specific authorization token is good for just one payment.
Note that the consumer wallet software necessarily provides very little function in this design. Most of the payment protocol function is performed in the issue gateway. At minimum, the wallet provides some method of authenticating the consumer to the issuer gateway, as discussed below. If consumer wallets are shared among issuers, then the authentication scheme must be shared, but the authentication data (e.g. smart card) could be different for each issuer. If consumer wallets are not shared among multiple issuers, as shown in
The consumer wallet must provide payment request timeout and retry functions. Most other functions can be placed in either the consumer wallet or the issuer gateway. These include most of the user interface, the payment inquiry function, the payment transaction log, support for multiple consumer cards, and support for payment selection. Implementing these functions at the consumer machine would result in a “fat” wallet; implementing them in the issuer gateway would result in a “thin” wallet.
Message processing functions (parsing and checking incoming messages, generating complex outgoing messages) are much simpler than in SET, since no encryption is used; the wallet need not examine the merchant's data in step 1 and the authorization token from step 2; and the wallet neither generates nor verifies signatures.
The merchant, acquirer gateway, and issuer gateway should implement replay detection both to handle error retries and to defined against malicious replay attacks.
At step 4, the issuer gateway includes a “reference” to the consumers card number in the authorization token. If the actual card number were used, the authorization token—or at least the card number—would have to be encrypted in steps 3, 4, and 5. Instead, the 4-party protocol uses a “reference”, which can be composed in either of the following ways:
To support this design, the authorization token would include a dummy card number for use in routing the payment to the appropriate issuer. This dummy card number could be shared among all cardholders using this 4-party protocol. Either of these alternatives can support interfacing to the existing capture networks that interconnect acquiring and issuing banks.
The 4-party protocol is supported by a certificate hierarchy that covers issuing banks, acquiring banks, and merchants. The certificate hierarchy is used with standard asymmetric (public-key) digital signatures to identify the protocol participants to each other. The certificates represent the common financial agreements and obligations among these parties. In particular, the issuing bank certificates identify and help authenticate issuing banks to merchants, providing a basis for the merchants to trust the authorization tokens provided by the issuing banks. The acquiring bank and merchant certificates identify and help authenticate the corresponding participants to issuing banks. This serves several purposes: (a) identifies the merchant to the consumer; (b) verifies that the merchant is a valid participant of the payment scheme before the issuing bank provides an authentication token; (c) helps deter some forms of attack on issuing banks by requiring participation of both a consumer and merchant in an attack. The certificate hierarchy is illustrated in the following Table I:
Provide trust base
for entire protocol
Identify & help
issuing banks to
Identity and help
acquires to issuing
Identify and help
merchants to issuing
Consumer certificates are not required, since the consumer authenticates to the consumer's own issuing bank. The consumer and bank have a long-term established relationship, so the bank can keep a data base containing the symmetric or asymmetric key required to authenticate the consumer.
X.509 or other established digital certificate formats are used. Each certificate identifies the certificate owner by name, physical address, network address, and so forth. In particular, the issuing gateway's certificate should contain the issuing gateway's network address to support split, recurring, and installment payments as described below. The merchant's certificate should contain the merchant's name, address, and contact information to assist in dispute resolution. The merchant's certificate should identify the acquiring bank that holds the merchant's business account used to settle payments.
The certificate hierarchy must be rooted by an authority jointly trusted by the banks. The root could be run by individual credit or debit brand associations, such as MasterCard, Visa, or the ATM network associations, by a national regulator such as the Federal Reserve, or by an international organization such as the WTO or World Bank. The choice of who runs the root is associated with the question of who establishes and enforces the business and regulatory arrangements between the issuing and acquiring banks. If national or international commercial laws define these arrangements (as with paper checks), then a public organization would be appropriate. If private bilateral or multi-lateral banking contracts define these arrangements, then financial associations (such as MasterCard or Visa) might operate the root. The organization of the certificate hierarchy should reflect the business arrangements. Possible arrangements could include separate hierarchies for separate countries or financial associations (e.g. one hierarchy for Visa, and another for MasterCard); a shared hierarchy as with SET (e.g. an industry root that grants certificates to sub-trees for financial associations or countries); or other variations.
An advantage of this design is the fact that the issuing bank can choose the technology used to authenticate the consumer to the issuer gateway. Possibilities include many standard techniques common in the industry:
End-user authentication involves a complex trade-off between cost, security, risks, portability and end-user convenience. Furthermore, the trade-offs change over time as new user authentication technology is invented. Unlike SET, the 4-party protocol design allows individual issuing banks to make their own choices for their customers, independently of the digital certificate technology used to authenticate merchants to issuers, and banks to each other.
SET provides the following features:
Split shipments are supported in the 4-party protocol by an additional message interaction between the merchant and issuer gateway, as shown in FIG. 4. When the merchant discovers that it needs to split a shipment, it sends the authorization token from step 3 to the issuer gateway identified in the issuer's digital certificate. This is a message merchant request message on path 402 of FIG. 4. The merchant includes the details of the split requirement, such as the amount of the first payment. The merchant authenticates the request by signing it and including the merchant's digital certificate. The issuer gateway can verify that the merchant signing message is the same merchant that signed the merchant request message. The issuer gateway verifies the split request according to its business and risk management policies, and responds with a new authorization token in a message on path 402 of FIG. 4. Consumer confirmation of split shipments is sent on pad 410 in step S. In step 6, the merchant forwards the new authorization token in the capture message on path 242 of
The 4-party protocol can support recurring and installment features by a combination of additional information in the authorization token, and messages on paths 402 and 242 of FIG. 4. Specifically, the steps of the basic protocol are modified as follows:
SET supports a special business arrangement that is common in Japan. Issuing banks and merchants attract customers and business by offering installment and other payment arrangements that are managed by the banks rather than the merchants. This involves a very complex protocol among all the SET participants.
The 4-party protocol facilitates this feature because the consumer wallet and issuer gateway directly interact. Specifically, at step 4 of the protocol on path 226 of
Many variations of this 4-party design are possible. A principle one is shown in FIG. 4. This variation has the same four steps as the basic design, but the authorization token is sent directly from the issuer gateway to the merchant. Specifically:
Note that the authorization token is “bound” to the particular payment by the reference to the consumer's credit card number, merchant identifier, payment amount, timestamp, and nonce. This means that a specific authorization token is good for just one payment.
The difference between this and the base design is that the issuer gateway sends the authorization token directly to the merchant, instead of relaying it through the consumer wallet. The primary advantage of this design is that it matches a “thin” wallet design by moving responsibility for error recovery to the issuer gateway. The disadvantage is that the consumer wallet (and hence the consumer) has less opportunity to be aware of the progress of the payment.
The principle of operation of the invention applies to both non-interactive internet communications such as email, as well as to interactive applications such as the World Wide Web. The method of the invention includes the step of sending from a consumer's computer to an issuer gateway for an issuing bank, an authorization request message containing consumer identity and authentication information, payment amount, an order description, a timestamp, a digital certificate representing a merchant, and a digital certificate representing the merchants acquiring bank. Then the method continues with the merchant's digital certificate containing a merchant identifier unique for the acquiring bank. Then the method continues with the acquiring bank's digital certificate containing a bank identifier unique among all banks sharing a common financial arrangement. Then the method continues with the step of validating at the issuer gateway the merchant's certificate and the acquirer's certificate to prove that the merchant, acquirer, and issuer share a common financial arrangement. Then the method continues with the step of the issuer gateway verifying the consumer's account and ensuring that funds and/or credit are available to support the payment amount, then authorizing payment by sending over the internet network an authorization token, an issuer's digital certificate, and a reference to the consumer's credit or debit card number. Then the method continues with the authorization token including the payment amount, order description, timestamp, a random nonce, the merchant identifier from the merchant's digital certificate, and the acquiring bank identifier from the acquiring bank's digital certificate, plus a reference to the consumer's credit or debit card number. Then the method continues with the authorization token being digitally signed by the issuing bank. Then the method continues with the step of merchant's computer receiving the authorization token and fulfilling the order description.
The method can include the feature of sending from a merchant's computer over an internet network to a consumer's computer, a merchant message including a wallet initiation message, a merchant digital certificate, and a digital certificate from an acquiring bank, the wallet initiation message including a payment amount, an order description, and a timestamp. Then the method starts a consumer's wallet program in the consumer's computer in response to the wallet initiation message. Then the consumer's wallet program sends the authorization request message.
The method can include the feature of including with the wallet initiation message a merchant's digital signature of the wallet initiation message, including the wallet initiation message and the merchant's digital signature in the authorization request message, and verifying at the issuer gateway the merchant's signature to prove that the consumer is dealing with the actual merchant.
The merchant's computer can perform the steps of receiving the authorization token, verifying the issuer's signature, digital certificate, the payment amount and merchant identity in the authorization token, verifying the freshness of the authorization token via the timestamp in the token, using the nonce in the authorization token to recognize duplicate tokens, and fulfilling the order description.
The merchant can claim payment through the acquiring bank by forwarding the customer reference number and payment amount to the acquiring bank. In the case of a subsequent dispute, the merchant proves payment authorization by submitting a copy of the authorization token and issuer's digital certificate to the acquiring bank. The acquiring bank verifies the issuer's signature on the authorization token, validates the issuer's digital certificate, checks for duplicates via the timestamp in the authorization token, and then the acquiring bank pays the amount indicated in the authorization token.
The authorization request message and authorization token can include a hash of an order description instead of the actual order description, the order description itself being available separately at the merchant, the merchant validating that the authorization token refers to the same order description by comparing the hash of the order description in the authorization token against a locally-computed hash of the same order description.
Although specific embodiments of the invention have been disclosed, it will be understood by those skilled in the art that changes can be made to those specific embodiments without departing from the spirit and the scope of the invention.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4799156 *||Oct 1, 1986||Jan 17, 1989||Strategic Processing Corporation||Interactive market management system|
|US4947028 *||Jul 19, 1988||Aug 7, 1990||Arbor International, Inc.||Automated order and payment system|
|US5495533 *||Apr 29, 1994||Feb 27, 1996||International Business Machines Corporation||Personal key archive|
|US5557518 *||Apr 28, 1994||Sep 17, 1996||Citibank, N.A.||Trusted agents for open electronic commerce|
|US5590197||Apr 4, 1995||Dec 31, 1996||V-One Corporation||Electronic payment system and method|
|US5594796 *||Oct 5, 1994||Jan 14, 1997||Motorola, Inc.||Method and apparatus for detecting unauthorized distribution of data|
|US5621797 *||Dec 19, 1995||Apr 15, 1997||Citibank, N.A.||Electronic ticket presentation and transfer method|
|US5642419 *||Dec 19, 1995||Jun 24, 1997||Citibank N.A.||Method for acquiring and revalidating an electronic credential|
|US5671279 *||Nov 13, 1995||Sep 23, 1997||Netscape Communications Corporation||Electronic commerce using a secure courier system|
|US5677955 *||Apr 7, 1995||Oct 14, 1997||Financial Services Technology Consortium||Electronic funds transfer instruments|
|US5703949 *||Oct 23, 1996||Dec 30, 1997||Citibank, N.A.||Method for establishing secure communications among processing devices|
|US5715314 *||Oct 24, 1994||Feb 3, 1998||Open Market, Inc.||Network sales system|
|US5724424 *||Nov 29, 1995||Mar 3, 1998||Open Market, Inc.||Digital active advertising|
|US5744787||Sep 25, 1995||Apr 28, 1998||Advanced Retail Systems Ltd.||System and method for retail|
|US5757917 *||Nov 1, 1995||May 26, 1998||First Virtual Holdings Incorporated||Computerized payment system for purchasing goods and services on the internet|
|US5790025 *||Aug 1, 1996||Aug 4, 1998||International Business Machines Corporation||Tamper detection using bulk multiple scattering|
|US5790677 *||Jun 29, 1995||Aug 4, 1998||Microsoft Corporation||System and method for secure electronic commerce transactions|
|US5805798 *||Oct 29, 1996||Sep 8, 1998||Electronic Data Systems Corporation||Fail-safe event driven transaction processing system and method|
|US5812776 *||Jun 7, 1995||Sep 22, 1998||Open Market, Inc.||Method of providing internet pages by mapping telephone number provided by client to URL and returning the same in a redirect command by server|
|US5822737 *||Feb 5, 1996||Oct 13, 1998||Ogram; Mark E.||Financial transaction system|
|US5825881 *||Jun 28, 1996||Oct 20, 1998||Allsoft Distributing Inc.||Public network merchandising system|
|US5826242 *||Aug 27, 1997||Oct 20, 1998||Netscape Communications Corporation||Method of on-line shopping utilizing persistent client state in a hypertext transfer protocol based client-server system|
|US5826245 *||Mar 20, 1995||Oct 20, 1998||Sandberg-Diment; Erik||Providing verification information for a transaction|
|US5850446||Jun 17, 1996||Dec 15, 1998||Verifone, Inc.||System, method and article of manufacture for virtual point of sale processing utilizing an extensible, flexible architecture|
|US5930777 *||May 23, 1997||Jul 27, 1999||Barber; Timothy P.||Method of charging for pay-per-access information over a network|
|US5974146 *||Jul 30, 1997||Oct 26, 1999||Huntington Bancshares Incorporated||Real time bank-centric universal payment system|
|US5991750 *||Oct 24, 1997||Nov 23, 1999||Ge Capital||System and method for pre-authorization of individual account transactions|
|US6014636 *||May 6, 1997||Jan 11, 2000||Lucent Technologies Inc.||Point of sale method and system|
|US6016484 *||Apr 26, 1996||Jan 18, 2000||Verifone, Inc.||System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment|
|US6023682 *||Oct 21, 1997||Feb 8, 2000||At&T Corporation||Method and apparatus for credit card purchase authorization utilizing a comparison of a purchase token with test information|
|US6029150 *||Oct 4, 1996||Feb 22, 2000||Certco, Llc||Payment and transactions in electronic commerce system|
|US6049785 *||Mar 2, 1998||Apr 11, 2000||Open Market, Inc.||Open network payment system for providing for authentication of payment orders based on a confirmation electronic mail message|
|US6058381 *||Oct 30, 1997||May 2, 2000||Nelson; Theodor Holm||Many-to-many payments system for network content materials|
|US6163771 *||Aug 28, 1997||Dec 19, 2000||Walker Digital, Llc||Method and device for generating a single-use financial account number|
|JPH1063925A *||Title not available|
|WO1995016971A1 *||Dec 13, 1994||Jun 22, 1995||Open Market, Inc.||Digital active advertising|
|WO1997041540A1||Apr 24, 1997||Nov 6, 1997||Verifone, Inc.||A system, method and article of manufacture for network electronic authorization utilizing an authorization instrument|
|WO1998014921A1||Oct 1, 1997||Apr 9, 1998||Certco, Llc||Payment and transactions in electronic commerce system|
|WO1998021679A1||Nov 13, 1997||May 22, 1998||Microsoft Corporation||System and method for conducting commerce over a distributed network|
|1||"GlobeSet Announces General Availability of Industry-First Server Wallet to Simplify Deployment and Support for Secure Internet Transactions," Business Wire, LookSmart, http://www.findarticles.com/cf_0/mDEN/1998_Nov_5/53177583.html, Nov. 1998, 2 pages, Austin, Texas.|
|2||"SET Secure Electronic Transaction Specification Book 1: Business Description," Version 1, pp. 1-72, May 1997.|
|3||*||"Tech Bytes: Cybercash Distribution Deal with Canadian Bank" American Banker, Jun. 10, 1996, v 161, issue 110, p. 16.|
|4||*||Anderson et al. Description of Financial Agent Secured Transactions Authentication.|
|5||*||Anderson et al., "Description of Financial Agent Secured Transactions (FAST) Authentication," Financial Technology Consortium, Fourth Draft, Dec. 2, 1998.|
|6||L Tang, "A Set of Protocols for Micropayments in Distributed Systems," First USENIX Workshop on Electronic Commerce, http://www.usenix.org, Jul. 1995, 10 pages.|
|7||*||Milt Anderson et al., "Description of Financial Agent Secured Transactions (FAST) Authentication," Financial Services Technology Consortium, Fourth Draft, Dec. 2, 1998.|
|8||*||O'Mahoney et al. Electronic Payment Systems, Artech House, Inc., Norwood, Ma, 1997.|
|9||*||O'Mahony, Donal, Peirce, Michael and Tewari, Hitesh, Electronic Payment Systems, Artech House, Inc., Norwood, MA, 1997.|
|10||T. Clark, "E-commerce firm opens wallet," CNET News.com, http://news.com/2102-1017-212302.html, 2002, 2 pages.|
|11||T. Clark, "Wallet software sparks SET debate," CNET New.com, http://news.com/2102-1017-212623.html, 2002, 2 pages.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US8108317 *||Dec 13, 2005||Jan 31, 2012||Hand Held Products, Inc.||System and method for restricting access to a terminal|
|US8694438 *||Aug 6, 2013||Apr 8, 2014||Scvngr||Distributed authenticity verification for consumer payment transactions|
|US8788429 *||Dec 30, 2009||Jul 22, 2014||First Data Corporation||Secure transaction management|
|US8827154||Jan 20, 2011||Sep 9, 2014||Visa International Service Association||Verification of portable consumer devices|
|US9038886||May 14, 2010||May 26, 2015||Visa International Service Association||Verification of portable consumer devices|
|US9256871||Jul 26, 2012||Feb 9, 2016||Visa U.S.A. Inc.||Configurable payment tokens|
|US9280765||Apr 10, 2012||Mar 8, 2016||Visa International Service Association||Multiple tokenization for authentication|
|US9317848||Aug 9, 2013||Apr 19, 2016||Visa International Service Association||Integration of verification tokens with mobile communication devices|
|US9342823 *||Jan 4, 2008||May 17, 2016||Lemon, Inc.||Payment clearing network for electronic financial transactions and related personal financial transaction device|
|US9372971||Nov 4, 2013||Jun 21, 2016||Visa International Service Association||Integration of verification tokens with portable computing devices|
|US9424413||Mar 2, 2012||Aug 23, 2016||Visa International Service Association||Integration of payment capability into secure elements of computers|
|US9485258 *||Feb 10, 2012||Nov 1, 2016||Openwave Mobility, Inc.||Mediation system and method for restricted access item distribution|
|US9516487||Nov 18, 2014||Dec 6, 2016||Visa International Service Association||Automated account provisioning|
|US9524501||Jun 5, 2013||Dec 20, 2016||Visa International Service Association||Method and system for correlating diverse transaction data|
|US9530131||Oct 7, 2015||Dec 27, 2016||Visa U.S.A. Inc.||Transaction processing using a global unique identifier|
|US9530289||May 21, 2014||Dec 27, 2016||Scvngr, Inc.||Payment processing with automatic no-touch mode selection|
|US9547769||Jul 3, 2013||Jan 17, 2017||Visa International Service Association||Data protection hub|
|US9582801||Oct 9, 2014||Feb 28, 2017||Visa International Service Association||Secure communication of payment information to merchants using a verification token|
|US9589268||May 27, 2016||Mar 7, 2017||Visa International Service Association||Integration of payment capability into secure elements of computers|
|US9660977 *||Dec 22, 2015||May 23, 2017||Alcatel Lucent||Restricted certificate enrollment for unknown devices in hotspot networks|
|US9665722||Aug 12, 2013||May 30, 2017||Visa International Service Association||Privacy firewall|
|US9680942||Apr 29, 2015||Jun 13, 2017||Visa International Service Association||Data verification using access device|
|US9684889 *||May 20, 2003||Jun 20, 2017||Identrust, Inc.||System and method for providing certification-related and other services|
|US9704155||Jul 26, 2012||Jul 11, 2017||Visa International Service Association||Passing payment tokens through an hop/sop|
|US9715681||May 14, 2010||Jul 25, 2017||Visa International Service Association||Verification of portable consumer devices|
|US9727858||Dec 17, 2015||Aug 8, 2017||Visa U.S.A. Inc.||Configurable payment tokens|
|US20040111379 *||May 20, 2003||Jun 10, 2004||Mack Hicks||System and method for providing certification-related and other services|
|US20060149671 *||Jun 27, 2005||Jul 6, 2006||Robert Nix||Payment processing method and system|
|US20070067634 *||Dec 13, 2005||Mar 22, 2007||Siegler Thomas A||System and method for restricting access to a terminal|
|US20080167888 *||Jan 9, 2007||Jul 10, 2008||I4 Commerce Inc.||Method and system for identification verification between at least a pair of entities|
|US20080313047 *||Jan 4, 2008||Dec 18, 2008||Bling Nation, Ltd.||Payment clearing network for electronic financial transactions and related personal financial transaction device|
|US20090177587 *||Jan 23, 2009||Jul 9, 2009||Yt Acquisition Corporation||Method and system for providing online authentication utilizing biometric data|
|US20100299195 *||Jan 21, 2010||Nov 25, 2010||Robert Nix||Systems and methods for implementing financial transactions|
|US20110161233 *||Dec 30, 2009||Jun 30, 2011||First Data Corporation||Secure transaction management|
|US20110208961 *||Feb 12, 2010||Aug 25, 2011||Bushman M Benjamin||Secure messaging system|
|US20120209778 *||Feb 10, 2012||Aug 16, 2012||Openwave Systems Inc.||Mediation system and method for restricted access item distribution|
|US20120284196 *||Oct 7, 2010||Nov 8, 2012||Andras Vilmos||Method for initiating and performing a cnp business transaction, software for the same and a communication device comprising such software|
|US20130018793 *||Jul 12, 2012||Jan 17, 2013||Shoon Ping Wong||Methods and systems for payments assurance|
|US20130191290 *||Jan 19, 2011||Jul 25, 2013||Glencurr Pty Ltd||Method, device and system for securing payment data for transmission over open communication networks|
|US20140289110 *||Mar 31, 2014||Sep 25, 2014||Max R. Levchin||Using tokens in digital wallet transactions|
|US20150026070 *||Jul 16, 2013||Jan 22, 2015||Mastercard International Incorporated||Systems and methods for correlating cardholder identity attributes on a payment card network to determine payment card fraud|
|US20160134622 *||Dec 22, 2015||May 12, 2016||Alcatel Lucent||Restricted Certificate Enrollment For Unknown Devices In Hotspot Networks|
|U.S. Classification||705/65, 705/76, 713/156, 713/172|
|International Classification||G06Q20/04, G06Q20/36, G06Q20/02, G06Q99/00, H04K1/00|
|Cooperative Classification||G06Q20/02, G06Q20/367, G06Q20/04|
|European Classification||G06Q20/02, G06Q20/04, G06Q20/367|
|Oct 7, 2008||CC||Certificate of correction|
|Jun 15, 2009||REMI||Maintenance fee reminder mailed|
|Sep 2, 2009||FPAY||Fee payment|
Year of fee payment: 8
|Sep 2, 2009||SULP||Surcharge for late payment|
Year of fee payment: 7
|Dec 20, 2012||AS||Assignment|
Owner name: EBAY INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:INTERNATIONAL BUSINESS MACHINES CORPORATION;REEL/FRAME:029512/0567
Effective date: 20120928
|Jul 12, 2013||REMI||Maintenance fee reminder mailed|
|Dec 4, 2013||LAPS||Lapse for failure to pay maintenance fees|
|Dec 4, 2013||REIN||Reinstatement after maintenance fee payment confirmed|
|Jul 18, 2014||FPAY||Fee payment|
Year of fee payment: 12
|Jul 18, 2014||SULP||Surcharge for late payment|
|Jan 12, 2015||PRDP||Patent reinstated due to the acceptance of a late maintenance fee|
Effective date: 20080729
|Jul 22, 2015||AS||Assignment|
Owner name: PAYPAL, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036159/0873
Effective date: 20150717