WO2001027887A1 - System and method for global internet digital identification - Google Patents

System and method for global internet digital identification Download PDF

Info

Publication number
WO2001027887A1
WO2001027887A1 PCT/US2000/027458 US0027458W WO0127887A1 WO 2001027887 A1 WO2001027887 A1 WO 2001027887A1 US 0027458 W US0027458 W US 0027458W WO 0127887 A1 WO0127887 A1 WO 0127887A1
Authority
WO
WIPO (PCT)
Prior art keywords
recited
response message
network
authorization
identification data
Prior art date
Application number
PCT/US2000/027458
Other languages
French (fr)
Inventor
Michael D. S. Harris
John Wankmueller
Original Assignee
Mastercard International Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mastercard International Incorporated filed Critical Mastercard International Incorporated
Priority to JP2001530828A priority Critical patent/JP2003511802A/en
Priority to AU78593/00A priority patent/AU772372B2/en
Priority to EP00968720A priority patent/EP1218861A1/en
Priority to CA002385954A priority patent/CA2385954C/en
Publication of WO2001027887A1 publication Critical patent/WO2001027887A1/en
Priority to HK02108987.6A priority patent/HK1047337A1/en

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • G06Q20/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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
    • G06Q20/403Solvency checks
    • G06Q20/4037Remote solvency checks

Definitions

  • This invention relates to digital identification (hereinafter “digital ID”) applications used to purchase goods or services.
  • a digital ID is a set of digital data associated with an individual or entity.
  • the ID can be, for example, a digital document (e.g., a digital certificate) which associates a digital key with the individual or entity.
  • Digital ID applications for use over the
  • One model for digital ID applications allows a third party service provider on the Internet to perform an exchange with a cardholder accessing the third party site and to retrieve from the cardholder a digital ID that the service provider can then validate with a "central point" before providing service.
  • the service provider goes to the "central point” for each validation and is charged based on the level of assurance that the "central point" is prepared to provide (e.g., 0.100 for a guarantee that digital ID is good for $100, l for a guarantee that digital ID is good for $1000, etc.).
  • the present invention provides a unique system and method for performing a digital ID function using currently existing payment system building blocks (such as the "EMV” standard promulgated jointly by Europay International S.A., MasterCard International Incorporated, and Visa International Service Association, and the "SET” standard promulgated by SET Secure Electronic Transaction, LLC) and currently existing credit/debit card payment system contractual relationships.
  • EMV Europay International S.A., MasterCard International Incorporated, and Visa International Service Association
  • SET promulgated by SET Secure Electronic Transaction, LLC
  • each digital ID issuer has one contractual relationship with a "central switch" and each service provider has one contractual relationship with the "central switch.”
  • issuers of digital IDs may choose to use some or all of the assurance levels.
  • FIG. 1 is a diagram of information flow in an exemplary system for performing digital ID in accordance with the invention.
  • a digital ID issuer issues a digital ID to a digital ID holder.
  • the request for digital ID verification is routed to the digital ID issuer over a distributed communication network.
  • the distributed communication network may include the Internet and an existing legacy payment system infrastructure (such as the Banknet infrastructure of MasterCard International Incorporated).
  • the Internet and the existing legacy payment system infrastructure are connected by a "central switch" or gateway (such as a SET gateway).
  • Digital ID holders are, with the present invention, able to anonymously identify themselves in remote environments, such as the Internet, to other parties.
  • the digital ID is a portable identity object that is simple for digital ID holders to use and can eliminate the need by digital ID holders to remember different passwords and user-ID combinations required to gain access to protected Internet sites. While not revealing any other details of the identity to the identity verification requester, the present invention can release only agreed identity data to the identity verification requester. It is the digital ID issuer who provides and controls all data.
  • the present invention uses a set of separate, stand-alone, non-payment messages which utilize existing legacy payment system message formats and payment-related data.
  • the digital ID verification request involves the use of a shared secret (of any type) possessed only by the digital ID issuer and the digital ID holder. High security is enabled since the number and types of secrets shared and algorithms used by the parties are varied and potentially non-standard.
  • the digital ID issuer will receive and validate a digital ID payment object, which is created by the digital ID holder with the shared secret.
  • the digital ID payment object is passed as an opaque block (an object that cannot be read) through all intermediary nodes to the digital ID issuer.
  • the digital ID issuer When a digital ID issuer receives a digital ID verification request, the digital ID issuer has a number of response options available to it. One option is to simply respond with a binary "yes" or “no" to the digital ID verification request. A second option is to respond with other data which is related to the digital ID holder, such as demographic data, payment history data, and/or other marketing data. Preferably, this other data is non-personally identifiable data, and the dissemination of this other data is pre-approved by the digital ID holder. The data may also include passwords for accessing a service provider's web site.
  • Previous digital identification technology has employed asymmetric key technology with private/public key pairs and digital certificates, sometimes combined with secured integrated circuit (IC) chip cards.
  • the present invention can be deployed without chip cards or any secure hardware deployed by the digital ID issuer.
  • the present invention may use shared symmetric key technology, instead of asymmetric key technology, to provide a digital ID function.
  • digital ID verification may occur before and/or after a payment transaction, and the digital ID verification is capable of being linked with the payment transaction through cryptography.
  • the linking is accomplished through the use of a cryptogram, which is an object containing the result of a cryptographic operation.
  • the present invention uses time-sensitive data.
  • the basic cryptographic techniques utilize parts of the EMV credit or debit payment specification and an EMV infrastructure.
  • An EMV- compliant chip card may be used with this embodiment, but (as already mentioned) chip card use is not required.
  • an digital ID application may be stored, for example, on a computer that is connected to the Internet. The stored digital ID application stored on the computer could function as a "virtual" chip card.
  • a digital ID issuer 500 (such as a bank) preferably issues a physical or virtual chip card 100 based on the EMV specification.
  • the chip card 100 can, optionally, be direct mailed to an end user.
  • the chip card 100 may contain a single application or multiple applications on it, and can, optionally, be based on the MULTOSTM operating system or on another operating system. It is assumed that the reader is familiar with the MULTOSTM standard, which is maintained by the MAOSCO Consortium. The standard is described in the
  • the digital ID issuer 500 assigns a payment-related or non-payment-related digital ID account number within the MasterCard Payment Application (MCPA) function in the chip card 100.
  • the digital ID account number is not required to be a credit/debit card account number (and, indeed, for security purposes, it is preferred that the digital ID not be such a number).
  • the digital ID issuer may deploy digital ID EMV-based applications which do not use credit/debit card account numbers but assign an account number only for digital ID use.
  • the cardholder logs onto the Internet and requests a service from a service provider web site (this request represented by arrow 1 of Fig.
  • the service provider 200 may decide to verify the cardholder's identity. It is up to the service provider to decide the frequency with which it requests verification from its customers. The service provider may request verification each and every time a service is requested, or it may request verification only occasionally.
  • the service provider 200 decides to request verification, the service provider preferably initiates a SET specification based transaction (for confidentiality and integrity of messaging over the Internet) and asks the cardholder (this request represented by arrow 2 of Fig. 1) to use its chip card (virtual or physical) to initiate a digital ID verification transaction (shown as arrow 3).
  • the digital ID verification transaction uses the credit/debit payment message formats of the MCPA and EMV specifications. These message formats may be used in a number of ways. For example, the payment amount field may be set to zero and the request may be treated as an authorization for a payment transaction of zero amount. Alternatively, a new message type may be added (for example, a "digital ID request" type) to the existing payment infrastructure. This new message type can be used to redefine certain fields. In particular, the payment field may no longer represent a payment amount, but a validation level amount. For example, if the payment field contains $100, the digital ID issuer will validate the identity of the digital ID at this validation level.
  • EMV -formatted cryptogram shown as arrow 3
  • ARQC authorization request cryptogram
  • the cryptogram is then transported (arrow 4) securely over the Internet, protected by (for example) the SET protocol.
  • the cryptogram can be a digital certificate.
  • the service provider passes this transaction request (arrow 4) over the Internet, using (preferably) the SET protocol, to a "central switch" 300, which may provide a SET payment gateway function. Since the transaction is not a payment, a bank- provided payment gateway is not necessary.
  • the central switch 300 can, optionally, be a SET acquirer.
  • the switch 300 reformats the verification transaction request to the format for message transmission over a trusted back-end network 400 (such as MasterCard International Inc.'s Banknet network).
  • a trusted back-end network 400 such as MasterCard International Inc.'s Banknet network
  • the verification request message is formatted as a "0100" chip formatted authorization request message.
  • the reformatted message is then passed (arrow 5) into the trusted back-end network 400, which routes the verification request (arrow 6) to the digital ID issuer 500.
  • the digital ID issuer 500 authenticates the digital ID verification transaction and stores the transaction for possible service provider fee collection at a level identified and requested on the verification request message.
  • the response by the digital ID issuer may be a simple "yes” or “no” or it may include other digital ID holder-related data.
  • the response also preferably includes an Authorization Response Cryptogram ("ARPC").
  • the digital ID issuer 500 responds to the switch via the trusted back-end network 400 with an authorization response message (arrow 7). If the back-end network is MasterCard's Banknet network, the message is a "01 10" formatted authorization response message. It is formatted as a payment authorization request but carries digital ID response data.
  • the back-end network 400 then passes the message (arrow 8) to the switch 300.
  • the switch formats the authorization response message as a SET/EMV response message (arrow 9) to the service provider 200.
  • the response message confirms or denies the digital ID authentication at the requested service level. This response message is similar to an authorization for purchase response.
  • the service provider 200 When the service provider 200 receives the SET/EMV response message, it decides whether to provide service to the cardholder.
  • the service provider may optionally complete the EMV-like transaction by sending a SET message (arrow 10) back to the physical or virtual card.
  • the digital ID number is preferably a fully "routable" credit or debit primary account number (PAN), but the number is not necessarily related to a payment account. In a preferred embodiment, the digital ID number is not the account number used for payment.
  • PAN credit or debit primary account number
  • This final TC (arrow 1 1 ) is a cryptographic object that may be used to link a digital ID verification transaction to a payment transaction.
  • the TC is based on the same shared secret as that used in generating the ARQC and on the ARPC received from the digital ID issuer.
  • the TC (along with the data needed to generate the TC) provides a strong linkage between the digital ID verification transaction and a payment authorization request.
  • the TC may be bundled into a payment transaction as the "random number" used in the initiate payment transaction stage.
  • MAOSCO Information Bulletin No. 7 -Export Controls, Sept. 29, 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).
  • MAOSCO Information Bulletin No. 9 - Export Controls, End-User Undertaking Guidance, Mar. 4, 1999 (available at http://dh007-00.web.dircon.net/present.ihtml).

Abstract

A system and method for authenticating a digital ID can utilize a central switch to transmit data between a network connected to a service provider and a network connected to a digital ID issuer. The system can be configured to provide a 'yes/no' authorization or a validation at a selected validation level. The system can receive an encrypted authorization request message, and can generate an encrypted authorization response message. The authorization response message can be used by the service provider to decide whether to provide a service to a digital ID holder.

Description

SYSTEM AND METHOD FOR GLOBAL INTERNET DIGITAL
IDENTIFICATION
SPECIFICATION
FIELD OF THE INVENTION
This invention relates to digital identification (hereinafter "digital ID") applications used to purchase goods or services.
BACKGROUND OF THE INVENTION
A digital ID is a set of digital data associated with an individual or entity. The ID can be, for example, a digital document (e.g., a digital certificate) which associates a digital key with the individual or entity. Digital ID applications for use over the
Internet and elsewhere are proliferating. One model for digital ID applications allows a third party service provider on the Internet to perform an exchange with a cardholder accessing the third party site and to retrieve from the cardholder a digital ID that the service provider can then validate with a "central point" before providing service. The service provider goes to the "central point" for each validation and is charged based on the level of assurance that the "central point" is prepared to provide (e.g., 0.100 for a guarantee that digital ID is good for $100, l for a guarantee that digital ID is good for $1000, etc.).
Currently, some parties are attempting to fill a need for new hierarchical/trust models based on new commercial relationships. In contrast, the present invention provides a unique system and method for performing a digital ID function using currently existing payment system building blocks (such as the "EMV" standard promulgated jointly by Europay International S.A., MasterCard International Incorporated, and Visa International Service Association, and the "SET" standard promulgated by SET Secure Electronic Transaction, LLC) and currently existing credit/debit card payment system contractual relationships. It is assumed that the reader is familiar with the EMV and SET standards, which are described in detail in the EMV and SET "References" listed in the "Related References" section below. These documents are incorporated by reference.
SUMMARY OF THE INVENTION
It is an object of the present invention to leverage existing investments and infrastructure to provide a unique system and method for providing digital ID applications. It is another object of the present invention to enable banks with a way to issue digital IDs at an assurance level with which they are comfortable, without the investment required to set up a new infrastructure or without the requirement to join a new consortium.
It is another object of the present invention to simplify contractual relationships required for providing digital ID applications. Under the present invention, each digital ID issuer has one contractual relationship with a "central switch" and each service provider has one contractual relationship with the "central switch."
It is another object of the present invention to provide standardized assurance levels for service providers. With the present invention, issuers of digital IDs may choose to use some or all of the assurance levels.
It is another object of the present invention to provide a digital ID application that provides a high level of authentication while, at the same time, allowing the digital ID holder to remain anonymous to a digital ID verification requestor.
BRIEF DESCRIPTION OF THE DRAWING
Further objects, features, and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying figure showing illustrative embodiments of the invention, in which:
FIG. 1 is a diagram of information flow in an exemplary system for performing digital ID in accordance with the invention.
In the figure, unless otherwise stated, the same reference numerals and characters are used to denote like features, elements, components, or portions of the illustrated embodiments. Moreover while the subject invention will now be described in detail with reference to the figure and in connection with the illustrative embodiments, changes and modifications can be made to the described embodiments without departing from the true scope and spirit of the subject invention as defined by the appended claims.
DETAILED DESCRIPTION OF THE INVENTION
According to the present invention, a digital ID issuer issues a digital ID to a digital ID holder. When a party desires to authenticate a digital ID holder, the request for digital ID verification is routed to the digital ID issuer over a distributed communication network. The distributed communication network may include the Internet and an existing legacy payment system infrastructure (such as the Banknet infrastructure of MasterCard International Incorporated). The Internet and the existing legacy payment system infrastructure are connected by a "central switch" or gateway (such as a SET gateway). Digital ID holders are, with the present invention, able to anonymously identify themselves in remote environments, such as the Internet, to other parties. The digital ID is a portable identity object that is simple for digital ID holders to use and can eliminate the need by digital ID holders to remember different passwords and user-ID combinations required to gain access to protected Internet sites. While not revealing any other details of the identity to the identity verification requester, the present invention can release only agreed identity data to the identity verification requester. It is the digital ID issuer who provides and controls all data.
In transmitting the request for digital ID verification, the present invention uses a set of separate, stand-alone, non-payment messages which utilize existing legacy payment system message formats and payment-related data. The digital ID verification request involves the use of a shared secret (of any type) possessed only by the digital ID issuer and the digital ID holder. High security is enabled since the number and types of secrets shared and algorithms used by the parties are varied and potentially non-standard. The digital ID issuer will receive and validate a digital ID payment object, which is created by the digital ID holder with the shared secret. Advantageously, the digital ID payment object is passed as an opaque block (an object that cannot be read) through all intermediary nodes to the digital ID issuer.
When a digital ID issuer receives a digital ID verification request, the digital ID issuer has a number of response options available to it. One option is to simply respond with a binary "yes" or "no" to the digital ID verification request. A second option is to respond with other data which is related to the digital ID holder, such as demographic data, payment history data, and/or other marketing data. Preferably, this other data is non-personally identifiable data, and the dissemination of this other data is pre-approved by the digital ID holder. The data may also include passwords for accessing a service provider's web site.
Previous digital identification technology has employed asymmetric key technology with private/public key pairs and digital certificates, sometimes combined with secured integrated circuit (IC) chip cards. Advantageously, the present invention can be deployed without chip cards or any secure hardware deployed by the digital ID issuer. Moreover, the present invention may use shared symmetric key technology, instead of asymmetric key technology, to provide a digital ID function.
Another unique feature of the present invention is that digital ID verification may occur before and/or after a payment transaction, and the digital ID verification is capable of being linked with the payment transaction through cryptography. The linking is accomplished through the use of a cryptogram, which is an object containing the result of a cryptographic operation. Preferably, the present invention uses time-sensitive data.
A preferred embodiment of the present invention will now be described. In this preferred embodiment, the basic cryptographic techniques utilize parts of the EMV credit or debit payment specification and an EMV infrastructure. An EMV- compliant chip card may be used with this embodiment, but (as already mentioned) chip card use is not required. Instead, an digital ID application may be stored, for example, on a computer that is connected to the Internet. The stored digital ID application stored on the computer could function as a "virtual" chip card.
With reference to Fig. 1, a digital ID issuer 500 (such as a bank) preferably issues a physical or virtual chip card 100 based on the EMV specification. The chip card 100 can, optionally, be direct mailed to an end user. The chip card 100 may contain a single application or multiple applications on it, and can, optionally, be based on the MULTOS™ operating system or on another operating system. It is assumed that the reader is familiar with the MULTOS™ standard, which is maintained by the MAOSCO Consortium. The standard is described in the
MULTOS™ "References" listed in the "Related References" section below. These documents are incorporated by reference.
The digital ID issuer 500 assigns a payment-related or non-payment-related digital ID account number within the MasterCard Payment Application (MCPA) function in the chip card 100. However, the digital ID account number is not required to be a credit/debit card account number (and, indeed, for security purposes, it is preferred that the digital ID not be such a number). In essence, the digital ID issuer may deploy digital ID EMV-based applications which do not use credit/debit card account numbers but assign an account number only for digital ID use. After the digital ID is issued, the cardholder logs onto the Internet and requests a service from a service provider web site (this request represented by arrow 1 of Fig.
1).
Before providing the requested service, the service provider 200 may decide to verify the cardholder's identity. It is up to the service provider to decide the frequency with which it requests verification from its customers. The service provider may request verification each and every time a service is requested, or it may request verification only occasionally.
If the service provider 200 decides to request verification, the service provider preferably initiates a SET specification based transaction (for confidentiality and integrity of messaging over the Internet) and asks the cardholder (this request represented by arrow 2 of Fig. 1) to use its chip card (virtual or physical) to initiate a digital ID verification transaction (shown as arrow 3). The digital ID verification transaction uses the credit/debit payment message formats of the MCPA and EMV specifications. These message formats may be used in a number of ways. For example, the payment amount field may be set to zero and the request may be treated as an authorization for a payment transaction of zero amount. Alternatively, a new message type may be added (for example, a "digital ID request" type) to the existing payment infrastructure. This new message type can be used to redefine certain fields. In particular, the payment field may no longer represent a payment amount, but a validation level amount. For example, if the payment field contains $100, the digital ID issuer will validate the identity of the digital ID at this validation level.
When a cardholder receives a request to initiate a digital ID verification transaction, the cardholder produces an EMV -formatted cryptogram (shown as arrow 3) (such as an authorization request cryptogram or an "ARQC" cryptogram) and provides it to the service provider 200. The cryptogram is then transported (arrow 4) securely over the Internet, protected by (for example) the SET protocol. The cryptogram can be a digital certificate.
The service provider passes this transaction request (arrow 4) over the Internet, using (preferably) the SET protocol, to a "central switch" 300, which may provide a SET payment gateway function. Since the transaction is not a payment, a bank- provided payment gateway is not necessary. The central switch 300 can, optionally, be a SET acquirer.
The switch 300 reformats the verification transaction request to the format for message transmission over a trusted back-end network 400 (such as MasterCard International Inc.'s Banknet network). For example, if the back-end network is MasterCard International Inc.'s Banknet network, the verification request message is formatted as a "0100" chip formatted authorization request message. The reformatted message is then passed (arrow 5) into the trusted back-end network 400, which routes the verification request (arrow 6) to the digital ID issuer 500.
The digital ID issuer 500 authenticates the digital ID verification transaction and stores the transaction for possible service provider fee collection at a level identified and requested on the verification request message. As previously discussed, the response by the digital ID issuer may be a simple "yes" or "no" or it may include other digital ID holder-related data. The response also preferably includes an Authorization Response Cryptogram ("ARPC").
The digital ID issuer 500 responds to the switch via the trusted back-end network 400 with an authorization response message (arrow 7). If the back-end network is MasterCard's Banknet network, the message is a "01 10" formatted authorization response message. It is formatted as a payment authorization request but carries digital ID response data. The back-end network 400 then passes the message (arrow 8) to the switch 300. The switch formats the authorization response message as a SET/EMV response message (arrow 9) to the service provider 200. The response message confirms or denies the digital ID authentication at the requested service level. This response message is similar to an authorization for purchase response.
When the service provider 200 receives the SET/EMV response message, it decides whether to provide service to the cardholder. The service provider may optionally complete the EMV-like transaction by sending a SET message (arrow 10) back to the physical or virtual card.
The functions of the switch system are as follows:
1. Receive and translate SET/EMV messages on the Internet from service providers into 0100 payment formatted messages for Banknet.
2. Identify and translate 0110 formatted messages from Banknet into SET/EMV messages on the Internet to service providers.
3. Identify and log transactions for fee purposes.
4. Gather fees from service providers.
5. Distribute shares of fees to digital ID issuers.
6. Identify new contents of fields on 0100/0110 messages and SET/EMV messages to facilitate identification or non-payment transaction. To ensure the freshness of a digital ID request and avoid replay of a digital ID request at a later date and time, it is preferred that digital ID devices will generate a random number challenge which is used, along with other data, by the digital ID holder to create the digital ID cryptogram sent to the digital ID issuer for validation. A preferred embodiment is to use SET technology and EMV chip card technology for this function.
A preferred embodiment of the present invention is built upon the EMV electronic commerce specification but includes the following modifications and additions. The digital ID number is preferably a fully "routable" credit or debit primary account number (PAN), but the number is not necessarily related to a payment account. In a preferred embodiment, the digital ID number is not the account number used for payment.
In addition, the present invention also adds the option to save the EMV final Transaction Certificate (TC) by the cardholder system. This final TC (arrow 1 1 ) is a cryptographic object that may be used to link a digital ID verification transaction to a payment transaction. The TC is based on the same shared secret as that used in generating the ARQC and on the ARPC received from the digital ID issuer. In those cases when the digital ID issuer is the same as the payment account issuer, the TC (along with the data needed to generate the TC) provides a strong linkage between the digital ID verification transaction and a payment authorization request. To achieve the linkage, the TC may be bundled into a payment transaction as the "random number" used in the initiate payment transaction stage. An advantage to using the TC in this manner is that a lower level of security is needed to transmit the payment transaction data over the Internet. This is because the transaction route has already been verified by the digital ID verification transaction and the receipt of an ARPC. Although the present invention has been described in connection with particular embodiments thereof, it is to be understood that such embodiments are susceptible of modification and variation without departing from the scope of the inventive concept as defined by the appended claims. RELATED REFERENCES
The following references are hereby incorporated by reference in their entireties: SET References:
SET Secure Electronic Transaction Specification, Book 1: Business Description, Version 1.0, May 31, 1997 (available at http://www.setco.org/download.html).
SET Secure Electronic Transaction Specification Book 2: Programmer's Guide, Version 1.0, May 31, 1997 (available at http://www.setco.org/download.html).
SET Secure Electronic Transaction Specification Book 3: Formal Protocol Definition, Version 1.0, May 31, 1997 (available at http://www.setco.org/download.html).
SET Glossary of Terms, July 1999 (available at http://www.setco.org/download.html).
External Interface Guide to SET Secure Electronic Transaction, September 24, 1997 (available at http://www.setco.org/download.html).
SET Generic Cryptogram Extension, July 19, 1999 (available at http://www.setco.org/download.html).
SET Japanese Payment Option Extension, August 24, 1999 (available at http://www.setco.org/download.html).
SET Merchant Initiated Authorization Extension, July 19, 1999 (available at http://www.setco.org/download.html).
SET Online PIN Extensions, July 19, 1999 (available at http://www.setco.org/download.html).
SET CW2/CVC2 Extension, September 29, 1999 (available at http://www.setco.org/download.html). EMV References:
EMV '96 Chip Electronic Commerce Specification, Draft 1.0, 1999.
EMV '96 Integrated Circuit Card Specification for Payment Systems, Version 3.1.1, May 31, 1998 (available at http://www.emvco.com/specifications.cfm).
EMV '96 Integrated Circuit Card Terminal Specification for Payment Systems,
Version 3.1.1, May 31, 1998 (available at http://www.emvco.com/specifications.cfm).
EMV '96 Integrated Circuit Card Application Specification for Payment Systems, Version 3.1.1, May 31, 1998 (available at http://www.emvco.com/specifications.cfm).
Business Functional Requirements for Debit and Credit on Chip, Version 1.0, October 20, 1997 (available at http://www.mastercard.eom emv/emvspecs02.html#emv2).
Integrated Circuit Card Application Specifications for Debit and Credit on Chip, Version 2.0, November 1998 (available at http://www.mastercard.eom/emv/emvspecs02.html#emv2).
Minimum Card Requirements for Debit and Credit on Chip, Version 2.0, November 1998 (available at http://www.mastercard.eom emv/emvspecs02.html#emv2).
Terminal Requirements for Debit and Credit on Chip, Version 2.0, November 1998 (available at http://www.mastercard.eom/emv/emvspecs02.html#emv2).
Integrated Circuit Card Terminal Application Services - Type Approval, Version 1.0, October 24, 1997 (available at http://www.mastercard.eom/emv/emvspecs02.html#emv2).
Personalization Data Specifications for Debit and Credit on Chip, Version 1.0, August 1998 (available at http://www.mastercard.eom emv/emvspecs02.html#emv2). MULTOS References:
MAOSCO, A Guide to the MULTOS Scheme (2000).
MAOSCO, Information Bulletin - Introduction to MULTOS & MAOSCO, Jan. 4, 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Information Bulletin 6 - MAOSCO Policy Position on ITSEC Matters, Mar. 19, 1999 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Information Bulletin No. 3 - Developing & Loading Applications, Mar. 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Information Bulletin No. 4 - Using MULTOS, Apr. 1998 (available at http://dh007-00.web.dircon.net present.ihtml).
MAOSCO, Information Bulletin No 5 - Application Load/Delete Certificates & Application Load Units, March 18, 1998 (available at http://dh007- O0.web.dircon.net/present.ihtml).
MAOSCO, Information Bulletin No. 7 -Export Controls, Sept. 29, 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Information Bulletin No. 8 - Obtaining an Implementation Licence, May 14, 1998 (available at http://dh007-00.web.dircon.net present.ihtml).
MAOSCO, Information Bulletin No. 9 - Export Controls, End-User Undertaking Guidance, Mar. 4, 1999 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Technical Bulletin No. 1 - Shell Applications, Apr. 15, 1999 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Technical Bulletin No. 2 - MULTOS and ISO 7816 Files, Jul. 7, 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Technical Bulletin No. 4 - Enablement/MSM Controls Data Loading, Dec. 4, 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Technical Bulletin No. 5 - Delegation, Apr. 15, 1999 (available at http://dh007-00.web.dircon.net/present.ihtml).
MAOSCO, Technical Bulletin No. 6 - What's New in MULTOS, Sept. 1, 1998 (available at http://dh007-00.web.dircon.net/present.ihtml).

Claims

CLAIMS 1. A method for verifying an identity of an ID holder, comprising the steps of: providing a central switch in communication with a first network and a second network; receiving, into the central switch, identification data from the first network, wherein the identification data has been provided by the ID holder and transmitted into the first network; controlling the central switch to use the identification data to generate an authorization request message having a format suitable for transmission through the second network; controlling the central switch to transmit the authorization request message into the second network to an ID issuer; receiving, into the central switch, an authorization response message from the second network, wherein the authorization response message has been generated by the ID issuer in response to the authorization request message; controlling the central switch to use the authorization response message to generate an output response message having a format suitable for transmission through the first network; and controlling the central switch to transmit the output response message into the first network.
2. A method as recited in claim 1, wherein the identification data includes a result of a cryptographic operation.
3. A method as recited in claim 2, wherein the result of the cryptographic operation includes an EMV-formatted cryptogram.
4. A method as recited in claim 2, wherein the cryptographic operation comprises: generating an essentially random number; and using the essentially random number to generate the result of the cryptographic operation.
5. A method as recited in claim 2, wherein the cryptographic operation comprises at least one of a secure electronic transaction cryptographic operation and an EMV chip card cryptographic operation.
6. A method as recited in claim 1, wherein the authorization response message includes a result of a cryptographic operation.
7. A method as recited in claim 6, wherein the result of the cryptographic operation includes an Authorization Response Cryptogram.
8. A method as recited in claim 1 , further comprising issuing a digital ID to the ID holder, wherein the identification data is generated by the digital ID.
9. A method as recited in claim 1, wherein the first network comprises an international network.
10. A method as recited in claim 1 , wherein the second network comprises a trusted network.
11. A method as recited in claim 1 , wherein the central switch comprises a secure electronic transaction gateway.
12. A method as recited in claim 1 , wherein the authorization response message includes at least one of an indication of authorization and an indication of denial of authorization.
13. A method as recited in claim 1, wherein the authorization response message includes information about the ID holder.
14. A method as recited in claim 13, wherein the information about the ID holder includes at least one of demographic data and payment history data.
15. A method as recited in claim 1, wherein the authorization response message includes a password suitable for enabling the ID holder to access a web site.
16. A method as recited in claim 1, further comprising issuing, to the ID holder, one of a physical chip card and a virtual chip card, wherein the identification data is generated by said one of a physical chip card and a virtual chip card.
17. A method as recited in claim 16, wherein the identification data has been transmitted into the first network by an ID requestor, said method further comprising sending a transaction-related message from the ID requestor to said one of a physical chip card and a virtual chip card.
18. A method as recited in claim 16, wherein said one of a physical chip card and a virtual chip card stores at least one application.
19. A method as recited in claim 16, further comprising assigning, to the ID holder, a digital ID account number, wherein the digital ID account number is stored within said one of a physical chip card and a virtual chip card.
20. A method as recited in claim 1 , further comprising using the output response message to decide whether to provide a service to the ID holder.
21. A method as recited in claim 1 , wherein the identification data includes a payment amount field.
22. A method as recited in claim 21 , wherein the authorization response message is generated by performing an authentication operation upon the authorization request message, wherein the payment amount field is set to a selected amount, and wherein the authentication operation comprises deciding whether to authorize a payment transaction having a value corresponding to the selected amount.
23. A method as recited in claim 22, wherein the selected amount is zero.
24. A method as recited in claim 1, wherein the identification data includes a validation level amount field.
25. A method as recited in claim 24, wherein the authorization response message is generated by performing an authentication operation upon the authorization request message, wherein the validation level amount field is set to a selected level, and wherein the authentication operation comprises deciding whether to validate the identity of the ID holder at a value corresponding to the selected level.
26. A method as recited in claim 1, wherein the authorization response message is generated by performing an authentication operation upon the authorization request message, said method further comprising storing transaction data related to at least one of the identification data, the authorization request message, the authentication operation, the authorization response message, and the output response message.
27. A method as recited in claim 26, wherein the transaction data comprises a cryptographic transaction certificate, said method further comprising: storing secret data which is shared with the ID holder; and using the secret data to generate the transaction certificate.
28. A method as recited in claim 27, further comprising: incorporating the transaction certificate into payment transaction data; and using the payment transaction data to initiate a payment.
29. A method as recited in claim 1 , wherein the authorization request message has a 0100 chip format.
30. A method as recited in claim 1, wherein the authorization response message has a 0110 format.
31. A method as recited in claim 1 , wherein the output response message has an EMV format.
32. A method as recited in claim 1, further comprising the steps of: collecting a fee from an ID requestor which has transmitted the identification data into the first network; and distributing at least one share of the fee to at least one ID issuer.
33. A method as recited in claim 1 , wherein the identification data does not include a payment account number.
34. A method as recited in claim 1 , further comprising: storing secret data which is shared with the ID holder; receiving, by the ID issuer, the authorization request message; using, by the ID issuer, the secret data to perform an authentication operation upon the authorization request message, thereby generating the authorization response message; and transmitting, by the ID issuer, the authorization response message through the second network to the central switch.
35. A method as recited in claim 34, wherein: the identification data includes a result of a first cryptographic operation; the authorization response message includes a result of a second cryptographic operation; the first network comprises an international network; the second network comprises a trusted network; the central switch comprises a secure electronic transaction gateway; the authorization response message includes at least one of an indication of authorization and an indication of denial of authorization; the authorization response message includes information about the ID holder; the authorization response message includes a password suitable for enabling the ID holder to access a web site; the identification data includes at least one of a payment amount field and a validation level amount field; the authorization request message has a 0100 chip format; the authorization response message has a 0110 format; the output response message has an EMV format; and the identification data does not include a payment account number, said method further comprising the steps of: issuing a digital ID to the ID holder, wherein the identification data is generated by the digital ID; using the output response message to decide whether to provide a service to the ID holder; using the secret data to generate a cryptographic transaction certificate; storing transaction data related to at least one of the identification data, the authorization request message, the authentication operation, the authorization response message, and the output response message, said transaction data including said transaction certificate; incorporating the transaction certificate into payment transaction data; using the payment transaction data to initiate a payment; collecting a fee from an ID requestor which has transmitted the identification data into the first network; and distributing at least one share of the fee to at least one ID issuer.
36. A method for verifying an identity of an ID holder, comprising the steps of: receiving identification data from at least one of a first network and an ID requestor; using the identification data to generate an authorization request message having a format suitable for transmission to at least one of a second network and an ID issuer; transmitting the authorization request message to said at least one of a second network and an ID issuer; receiving, from said at least one of a second network and an ID issuer, an authorization response message generated in response to the authorization request message; using the authorization response message to generate an output message having a format suitable for transmission to said at least one of a first network and an ID requestor; and transmitting the output message to said at least one of a first network and an ID requestor.
37. A method as recited in claim 36, wherein the identification data includes a result of a cryptographic operation.
38. A method as recited in claim 36, wherein the authorization response message includes a result of a cryptographic operation.
39. A method as recited in claim 36, further comprising issuing a digital ID to the ID holder, wherein the identification data is generated by the digital ID.
40. A method as recited in claim 36, wherein the first network comprises an international network.
41. A method as recited in claim 36, wherein the second network comprises a trusted network.
42. A method as recited in claim 36, wherein at least one of said steps of receiving identification data, using the identification data, transmitting the authorization request message, receiving an authorization response message, using the authorization response message, and transmitting the output message is performed using a secure electronic transaction gateway.
43. A method as recited in claim 36, wherein the authorization response message includes at least one of an indication of authorization and an indication of denial of authorization.
44. A method as recited in claim 36, wherein the authorization response message includes information about the ID holder.
45. A method as recited in claim 36, wherein the authorization response message includes a password suitable for enabling the ID holder to access a web site.
46. A method as recited in claim 36, further comprising issuing, to the ID holder, one of a physical chip card and a virtual chip card, wherein the identification data is generated by said one of a physical chip card and a virtual chip card.
47. A method as recited in claim 36, further comprising using the output message to decide whether to provide a service to the ID holder.
48. A method as recited in claim 36, wherein the identification data includes a payment amount field.
49. A method as recited in claim 36, wherein the identification data includes a validation level amount field.
50. A method as recited in claim 36, wherein the authorization response message is generated by performing an authentication operation upon the authorization request message, said method further comprising storing transaction data related to at least one of the identification data, the authorization request message, the authentication operation, the authorization response message, and the output message.
51. A method as recited in claim 50, wherein the transaction data comprises a cryptographic transaction certificate, said method further comprising : storing secret data which is shared with the ID holder; and using the secret data to generate the transaction certificate.
52. A method as recited in claim 51 , further comprising: incorporating the transaction certificate into payment transaction data; and using the payment transaction data to initiate a payment.
53. A method as recited in claim 36, wherein the authorization request message has a 0100 chip format.
54. A method as recited in claim 36, wherein the authorization response message has a 0110 format.
55. A method as recited in claim 36, wherein the output message has an EMV format.
56. A method as recited in claim 36, further comprising the steps of: collecting a fee from an ID requestor from which the identification data has been received; and distributing at least one share of the fee to at least one ID issuer.
57. A method as recited in claim 36. wherein the identification data does not include a payment account number.
58. A method as recited in claim 36, further comprising: storing secret data which is shared with the ID holder; receiving, by said at least one of a second network and an ID issuer, the authorization request message; using the secret data to perform an authentication operation upon the authorization request message, thereby generating the authorization response message; and transmitting, from said at least one of a second network and an ID issuer, the authorization response message.
59. A system for verifying an identity of an ID holder, comprising a central switch in communication with a first network and a second network, said central switch being configured to perform the steps of: receiving identification data from the first network; using the identification data to generate an authorization request message having a format suitable for transmission through the second network; transmitting the authorization request message through the second network; receiving, from the second network, an authorization response message generated in response to the authorization request message; using the authorization response message to generate an output message having a format suitable for transmission through the first network; and transmitting the output message through the first network.
60. A system as recited in claim 59, wherein the identification data includes a result of a cryptographic operation.
61. A system as recited in claim 59, wherein the authorization response message includes a result of a cryptographic operation.
62. A system as recited in claim 59, further comprising an ID issuer configured to issue a digital ID to the ID holder, wherein the identification data is generated by the digital ID.
63. A system as recited in claim 59, wherein the first network comprises an international network.
64. A system as recited in claim 59, wherein the second network comprises a trusted network.
65. A system as recited in claim 59, wherein the central switch comprises a secure electronic transaction gateway.
66. A system as recited in claim 59, wherein the authorization response message includes at least one of an indication of authorization and an indication of denial of authorization.
67. A system as recited in claim 59, wherein the authorization response message includes information about the ID holder.
68. A system as recited in claim 59, wherein the authorization response message includes a password suitable for enabling the ID holder to access a web site.
69. A system as recited in claim 59, further comprising an ID issuer configured to issue, to the ID holder, one of a physical chip card and a virtual chip card, wherein the identification data is generated by said one of a physical chip card and a virtual chip card.
70. A system as recited in claim 59, further comprising an ID requestor configured to use the output message to decide whether to provide a service to the ID holder.
71. A system as recited in claim 59, wherein the identification data includes a payment amount field.
72. A system as recited in claim 59, wherein the identification data includes a validation level amount field.
73. A system as recited in claim 59, further comprising an ID issuer configured to generate the authentication response message by performing an authentication operation upon the authorization request message, wherein at least one of said central switch and said ID issuer is further configured to store transaction data related to at least one of the identification data, the authorization request message, the authentication operation, the authorization response message, and the output message.
74. A system as recited in claim 73, wherein the transaction data comprises a cryptographic transaction certificate.
75. A system as recited in claim 74, wherein said at least one of said central switch and said ID issuer is further configured to perform the steps of: incorporating the transaction certificate into payment transaction data; and using the payment transaction data to initiate a payment.
76. A system as recited in claim 59, wherein the authorization request message has a 0100 chip format.
77. A system as recited in claim 59, wherein the authorization response message has a 0110 format.
78. A system as recited in claim 59, wherein the output message has an EMV format.
79. A system as recited in claim 59, wherein the central switch is further configured to perform the steps of: collecting a fee from an ID requestor which has transmitted the identification data into the first network; and distributing at least one share of the fee to at least one ID issuer.
80. A system as recited in claim 59, wherein the identification data does not include a payment account number.
81. A system as recited in claim 59, further comprising an ID issuer configured to perform the steps of: storing secret data which is shared with the ID holder; receiving the authorization request message from the central switch, through the second network; using the secret data to perform an authentication operation upon the authorization request message, thereby generating the authorization response message; and transmitting the authorization response message to the central switch, through the second network.
82. A system as recited in claim 81 , further comprising an ID requestor, wherein: the identification data includes a result of a first cryptographic operation; the authorization response message includes a result of a second cryptographic operation; the first network comprises an international network; the second network comprises a trusted network; the central switch comprises a secure electronic transaction gateway; the authorization response message includes at least one of an indication of authorization and an indication of denial of authorization; the authorization response message includes information about the ID holder; the authorization response message includes a password suitable for enabling the ID holder to access a web site; the identification data includes at least one of a payment amount field and a validation level amount field; the authorization request message has a 0100 chip format; the authorization response message has a 0110 format; the output message has an EMV format; the identification data does not include a payment account number; the ID issuer is configured to issue a digital ID to the ID holder, wherein the identification data is generated by the digital ID; the ID requestor is configured to use the output message to decide whether to provide a service to the ID holder; at least one of the central switch and the ID issuer is further configured to store transaction data related to at least one of the identification data, the authorization request message, the authentication operation, the authorization response message, and the output response message, said transaction data including a cryptographic transaction certificate; at least one of the central switch and the ID issuer is further configured to perform the steps of: incorporating the transaction certificate into payment transaction data; and using the payment transaction data to initiate a payment; and the central switch is further configured to perform the steps of: collecting a fee from the ID requestor; and distributing at least one share of the fee to at least one ID issuer.
PCT/US2000/027458 1999-10-08 2000-10-05 System and method for global internet digital identification WO2001027887A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2001530828A JP2003511802A (en) 1999-10-08 2000-10-05 Global internet digital identification system and method
AU78593/00A AU772372B2 (en) 1999-10-08 2000-10-05 System and method for global internet digital identification
EP00968720A EP1218861A1 (en) 1999-10-08 2000-10-05 System and method for global internet digital identification
CA002385954A CA2385954C (en) 1999-10-08 2000-10-05 System and method for global internet digital identification
HK02108987.6A HK1047337A1 (en) 1999-10-08 2002-12-11 System and method for global internet digital identification

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US15860899P 1999-10-08 1999-10-08
US60/158,608 1999-10-08
US16388699P 1999-11-05 1999-11-05
US60/163,886 1999-11-05

Publications (1)

Publication Number Publication Date
WO2001027887A1 true WO2001027887A1 (en) 2001-04-19

Family

ID=26855201

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/027458 WO2001027887A1 (en) 1999-10-08 2000-10-05 System and method for global internet digital identification

Country Status (6)

Country Link
EP (1) EP1218861A1 (en)
JP (1) JP2003511802A (en)
AU (1) AU772372B2 (en)
CA (1) CA2385954C (en)
HK (1) HK1047337A1 (en)
WO (1) WO2001027887A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002015509A2 (en) * 2000-08-15 2002-02-21 Nokia Corporation Device for secure payment over a network
WO2003098899A1 (en) * 2002-05-16 2003-11-27 Schlumberger Omnes, Inc. Method and apparatus for lan authentication on switch

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0590861A2 (en) * 1992-09-29 1994-04-06 AT&T Corp. Secure credit/debit card authorization
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5826245A (en) * 1995-03-20 1998-10-20 Sandberg-Diment; Erik Providing verification information for a transaction
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
EP0921487A2 (en) * 1997-12-08 1999-06-09 Nippon Telegraph and Telephone Corporation Method and system for billing on the internet

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5590197A (en) * 1995-04-04 1996-12-31 V-One Corporation Electronic payment system and method
FR2733068B1 (en) * 1995-04-14 1997-07-04 G C Tech ELECTRONIC PAYMENT METHOD FOR PERFORMING TRANSACTIONS RELATED TO THE PURCHASE OF GOODS ON A COMPUTER NETWORK
US5943424A (en) * 1996-06-17 1999-08-24 Hewlett-Packard Company System, method and article of manufacture for processing a plurality of transactions from a single initiation point on a multichannel, extensible, flexible architecture
US5991750A (en) * 1997-10-24 1999-11-23 Ge Capital System and method for pre-authorization of individual account transactions

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0590861A2 (en) * 1992-09-29 1994-04-06 AT&T Corp. Secure credit/debit card authorization
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5826245A (en) * 1995-03-20 1998-10-20 Sandberg-Diment; Erik Providing verification information for a transaction
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5883810A (en) * 1997-09-24 1999-03-16 Microsoft Corporation Electronic online commerce card with transactionproxy number for online transactions
EP0921487A2 (en) * 1997-12-08 1999-06-09 Nippon Telegraph and Telephone Corporation Method and system for billing on the internet

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
See also references of EP1218861A1 *
SIRBU M ET AL: "NETBILL: AN INTERNET COMMERCE SYSTEM OPTIMIZED FOR NETWORK- DELIVERED SERVICES", IEEE PERSONAL COMMUNICATIONS,US,IEEE COMMUNICATIONS SOCIETY, vol. 2, no. 4, 1 August 1995 (1995-08-01), pages 34 - 39, XP000517588, ISSN: 1070-9916 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002015509A2 (en) * 2000-08-15 2002-02-21 Nokia Corporation Device for secure payment over a network
WO2002015509A3 (en) * 2000-08-15 2002-07-04 Nokia Corp Device for secure payment over a network
WO2003098899A1 (en) * 2002-05-16 2003-11-27 Schlumberger Omnes, Inc. Method and apparatus for lan authentication on switch

Also Published As

Publication number Publication date
HK1047337A1 (en) 2003-02-14
AU7859300A (en) 2001-04-23
CA2385954C (en) 2008-05-06
CA2385954A1 (en) 2001-04-19
EP1218861A1 (en) 2002-07-03
JP2003511802A (en) 2003-03-25
AU772372B2 (en) 2004-04-22

Similar Documents

Publication Publication Date Title
US6681328B1 (en) System and method for global internet digital identification
US7680736B2 (en) Payment system
US7058611B2 (en) Method and system for conducting secure electronic commerce transactions with authorization request data loop-back
US6941285B2 (en) Method and system for a virtual safe
US20030069792A1 (en) System and method for effecting secure online payment using a client payment card
US20010047335A1 (en) Secure payment method and apparatus
EP1687725B1 (en) Secure payment system
AU2001248198A1 (en) A method and system for a virtual safe
AU2001283489A1 (en) Method and system for conducting secure electronic commerce transactions with authorization request data loop-back
CA2385954C (en) System and method for global internet digital identification
Van Herreweghen et al. Risks and Potentials of Using EMV for Internet Payments.
KR100458526B1 (en) System and Method for the wire·wireless complex electronic payment
ZA200202364B (en) System and method for global internet digital identification.
Asokan et al. Electronic payment systems
Balasubramanian et al. Electronic payment systems and their security
AU2011203165B2 (en) Secure payment system
Watson Electronic cash and set
Waidner Electronic Payment Systems
R3 Project Number AC026 Project Title Secure Electronic MarketPlace for Europe SEMPER Deliverable Security Class Public CEC Deliverable Number AC026/SMP/CT2/DS/P/015/b1
Pfitzmann et al. Smartcard-Supported Internet Payments
Van Herreweghen et al. USENIX Technical Program-Paper-Smartcard 99 [Technical Program] Risks and Potentials of using EMV for Internet Payments

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2002/02364

Country of ref document: ZA

Ref document number: 200202364

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 78593/00

Country of ref document: AU

Ref document number: 2385954

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2000968720

Country of ref document: EP

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2001 530828

Kind code of ref document: A

Format of ref document f/p: F

WWP Wipo information: published in national office

Ref document number: 2000968720

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 78593/00

Country of ref document: AU