Source: http://www.google.com/patents/US20020194138?dq=7,453,150
Timestamp: 2017-03-26 03:46:41
Document Index: 643385031

Matched Legal Cases: ['§120', 'application No. 60', 'arty 1550', 'arty 1550', 'arty 1550', 'arty 1532']

Patent US20020194138 - Online account authentication service - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA payment authentication service authenticates the identity of a payer during online transactions. The authentication service allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords. Also, the only system participant requiring a certificate...http://www.google.com/patents/US20020194138?utm_source=gb-gplus-sharePatent US20020194138 - Online account authentication serviceAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20020194138 A1Publication typeApplicationApplication numberUS 10/156,271Publication dateDec 19, 2002Filing dateMay 24, 2002Priority dateApr 24, 2000Also published asCA2407653A1, EP1277180A2, EP2278538A1, US7827115, US7991701, US8271395, US20020111919, US20030212642, US20080301056, US20100057619, US20100332393, US20120323733, US20120323734, US20160358175, WO2001082246A2, WO2001082246A3Publication number10156271, 156271, US 2002/0194138 A1, US 2002/194138 A1, US 20020194138 A1, US 20020194138A1, US 2002194138 A1, US 2002194138A1, US-A1-20020194138, US-A1-2002194138, US2002/0194138A1, US2002/194138A1, US20020194138 A1, US20020194138A1, US2002194138 A1, US2002194138A1InventorsBenedicto Dominguez, Thomas ManessisOriginal AssigneeVisa International Service Association A Delaware CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (99), Referenced by (218), Classifications (44), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetOnline account authentication service
US 20020194138 A1Abstract
A payment authentication service authenticates the identity of a payer during online transactions. The authentication service allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords. Also, the only system participant requiring a certificate is the issuing financial institution. Authenticating the identity of a cardholder during an online transaction involves querying an access control server to determine if a cardholder is enrolled in the payment authentication service, requesting a password from the cardholder, verifying the password, and notifying a merchant whether the cardholder's authenticity has been verified. A chip card and the authentication service independently generate cryptograms to match in order for the service to verify that the correct chip card is being used by the cardholder. Images(18) Claims(21)
[0001] This application is a continuation of U.S. patent application Ser. No. 09/842,313 filed Apr. 24, 2001, entitled “On-Line Payer Authentication Service,” from which priority under 35 U.S.C. §120 is claimed, which in turn claims priority of U.S. provisional patent application No. 60/199,727, filed Apr. 24, 2000 entitled “Visa Payer Authentication Service Description,” both of which are hereby incorporated by reference.
FIELD OF THE INVENTION [0002] The present invention relates generally to on-line transactions, and more specifically to authenticating the identity of account holders during online transactions. BACKGROUND OF THE INVENTION [0003] During a payment transaction using a payment card (e.g., a credit, debit, or stored value card), it is important to verify a cardholder's ownership of an account to avoid a variety of problems, such as unauthorized use. Payer authentication is the process of verifying a cardholder's ownership of an account. The most common method to authenticate a cardholder's ownership of an account occurs routinely at a point of sale during what is called a “card present” transaction. A card present transaction involves a merchant's representative taking the cardholder's card, swiping it though a payment card terminal to verify account status and credit line availability, and then checking to see that the signature on the back of the card matches the purchaser's signature. If the merchant follows specific guidelines for this type of transaction, the merchant will be guaranteed payment for the amount authorized less discount and fees. A service provider such as Visa International Service Association (or service organization) may provide these specific guidelines. [0004] “Card not present” transactions, on the other hand, such as those occurring online, through the mail, or over the telephone, involve payments that are not guaranteed to the merchant. No guarantee is provided primarily because the payers are not authenticated in such non face-to-face transactions, thereby allowing many risks to accompany the “card not present” transactions. Such risks involve issues such as chargebacks of payment transactions to online merchants, fraud for both merchants and cardholders, increased exception item processing expenses for banks, and an increased perception that buying goods and services online is not safe and secure, which may keep some consumers from buying online. Specific examples of risks include the unauthorized use of stolen account information to purchase goods and services online, fabrication of card account numbers to make fraudulent online purchases, and extraction of clear text account information from network traffic. [0005] Given the continued expected high growth of electronic commerce, it is important to provide methods to authenticate payers. This will benefit all payment system participants including cardholders, merchants, and financial institutions. Authenticating the payer during online purchase transactions will reduce the levels of fraud, disputes, retrievals and chargebacks, which subsequently will reduce the costs associated with each of these events. Authenticating the payer also addresses consumer security concerns and therefore will lead to increased online sales. Prior systems used to authenticate consumers during online transactions have not been widely adopted because these systems were difficult to use, had complex designs, required significant up-front investment by system participants and lacked interoperability. Certain prior systems additionally required the creation, distribution and use of certificates by merchants, cardholders, issuers and acquirers. Such use of certificates is known to be quite burdensome. [0006] In view of the foregoing, a system for authenticating the identity of the payer in an online transaction would be desirable. Such an authenticating system should be relatively easy to implement and use, require a minimal investment of resources, and provide a high level of interoperability between the system's participants. BRIEF SUMMARY OF THE INVENTION [0007] The present invention is directed towards an online service for authenticating the identity of a payer during online transactions. The present invention is relatively easy to implement and use, requires a minimal investment of resources to implement, and provides a high level of interoperability between the system's participants. The authentication service of the present invention allows a card issuer to verify a cardholder's identity using a variety of authentication methods, such as the use of passwords. Also, the only system participant requiring a certificate is the issuing financial institution. The authentication service can also provide authentication results to the merchant in real time during the checkout process. [0008] One aspect of the present invention pertains to a method wherein a trusted party authenticates, for the benefit of a third party, that an entity using an account during an online transaction is the actual owner of the account. The method involves receiving, by the trusted party from the entity, of an identity authenticating password, comparing, by the trusted party, of the identity authenticating password received from the entity against a password previously designated for the account, and notifying the third party, by the trusted party, that the entity is the actual owner of the account when the identity authenticating password received from the entity matches the password that was previously designated for the account. [0009] Another aspect of the present invention pertains to an account authentication system in which a trusted party authenticates, for the benefit of a third party, that an entity using an account during an online transaction is the actual owner of the account. The system includes a trusted party domain, and interoperability domain, and a third party domain. The trusted party domain includes an access control server being configured to receive and verify a password from the entity. The a third party domain includes a third-party plug-in software module contained within a server of the third party, the module configured to send a payment authentication request message to the access control server, the payment authentication request message prompting the access control server to request the password from the customer. The interoperability domain including a receipt database that is configured to store receipts for authenticated online transactions. [0010] These and other features and advantages of the present invention will be presented in more detail in the following specification of the invention and the accompanying figures, which illustrate by way of example the principles of the invention. BRIEF DESCRIPTION OF THE DRAWINGS [0011] The invention, together with further advantages thereof, may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which: [0012] [0012]FIG. 1 schematically illustrates one embodiment of an infrastructure architecture that can support the Payer Authentication Service (PAS). [0013] [0013]FIG. 2 illustrates the process through which a cardholder registers with PAS according to one embodiment of the present invention. [0014] [0014]FIG. 3 illustrates one embodiment of an Internet web page in which a cardholder can enter information during the enrollment process for PAS. [0015] [0015]FIG. 4 illustrates a PAS authenticated payment transaction according to one embodiment of the present invention. [0016] [0016]FIG. 5 illustrates an exemplary window that prompts the cardholder for his or her password. [0017] [0017]FIG. 6 illustrates exemplary messages that are sent during the payment transaction superimposed over the PAS architecture. [0018] [0018]FIG. 7 illustrates the message flows on the centralized PAS architecture according to a centralized embodiment of the present invention. [0019] [0019]FIG. 8 illustrates the centralized payment flow that occurs between the cardholder client device, the PAS, and the merchant system, according to the centralized embodiment of the present invention. [0020] [0020]FIG. 9 illustrates the enrollment flow in the distributed PAS architecture according to a distributed embodiment of the present invention. [0021] [0021]FIG. 10 illustrates the payment flow in the distributed PAS architecture according to the distributed embodiment of the present invention. [0022] [0022]FIG. 10A provides a high-level system architecture view of one embodiment of the chip card payer authorization service. [0023] [0023]FIG. 11 is a flow chart describing one example of a payment transaction using the chip card embodiment of the payer authentication service. [0024] [0024]FIG. 12 illustrates a system architecture view of the chip card authentication process according to one embodiment of the present invention. [0025] [0025]FIG. 12A illustrates a detailed flow of messages between the chip card, the cardholder client system, and the issuer's access control server. [0026] [0026]FIG. 13 illustrates a system diagram of the components utilized in the access control system embodiment of the payer authentication service. [0027] [0027]FIG. 14 illustrates a telecommunications network suitable for implementing an embodiment of the present invention. [0028] [0028]FIG. 15 illustrates systems housed within an interchange center to provide online and offline transaction processing. [0029] [0029]FIG. 16 illustrates another view of the components of the telecommunications network. [0030] [0030]FIGS. 17A and 17B illustrate a computer system suitable for implementing embodiments of the present invention. [0031] [0031]FIG. 18 illustrates a simplified system architecture for implementing the Payer Authentication Service in a non-purchase application according to one embodiment of the invention. DETAILED DESCRIPTION OF THE INVENTION [0032] The present invention will now be described in detail with reference to a few preferred embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known operations have not been described in detail so not to unnecessarily obscure the present invention. [0033] To begin with, a high-level description of the authentication process used by the Payer Authentication Service (PAS) will be provided. Later in this disclosure, a more detailed description of the authentication process and other processes, such as system setup and customer registration and specific message flows, will be provided. As explained in the previous sections of this disclosure, PAS is designed to authenticate cardholder account ownership during online purchase transactions. PAS will be used, for example, when a cardholder shops online, adds items to a shopping cart, proceeds to the online merchant's checkout page, and completes the online merchants checkout forms. PAS can also be used in various transactions when a trusted party authenticates the identity of an individual or entity for the benefit of a third party. As is commonly known, the trusted party usually accepts legal responsibility for the authentication of the individual or entity to the third party. For example, PAS can be used to authenticate a financial institution's customers when accessing an Internet web site to complete an online form. PAS can also be used in aspects of retail banking such as debit cards, purchase cards, stored value cards, as well as wholesale banking, the medical business, the insurance business, the brokerage business, etc. ID cards can also be used with PAS. For example, AAA may use PAS to authenticate the identity of its customer, or a telephone card company can use PAS to authenticate the identity of the user of a specific card. [0034] PAS can perform its authentication processes after the consumer decides to buy his or her desired products or services, for example, after the consumer clicks a “buy” button. PAS can also begin its authentication process at various other times in the consumer's purchase transaction, not only after the “buy” button is clicked. The authentication process is conducted mostly in a transparent mode to the consumer by utilizing software that has been incorporated in several points of a payment network. PAS validates participation by the cardholder and the cardholder's financial institution and then creates a window in which the consumer can confirm his or her identity by requesting a previously registered password from the cardholder. If the identity of the consumer is confirmed, the payment information and notice of the consumer's authentication is sent back to the merchant. Then, as conventionally performed, the payment transaction is processed by the merchant. For example, the merchant may send an order confirmation message to the cardholder's browser. High Level System Description [0035] [0035]FIG. 1 schematically illustrates one embodiment of an infrastructure architecture 100 that can support the PAS. The architecture is divided into three domains, the issuer domain 102, the interoperability domain 104, and the acquirer domain 106. The issuer domain 102 includes components that are primarily controlled by an issuer. An issuer, for example, can be a financial institution that issues payment cards to consumers. Specifically, an issuer, or a card issuer, personalizes new cards received from a card supplier and then issues these cards to its customers. Personalization may also be performed by the card supplier or by a personalization bureau. In addition to being a financial institution, an issuer may be any suitable issuing entity such as telecommunications network operator, a service association, a merchant or other organization, or even an agent acting for an issuer. The acquirer domain 106 includes components that are primarily controlled by an acquirer. An acquirer, for example, can be a financial institution that enrolls merchants in the payment scheme and manages the accounts of merchants. The acquirer also routes information from an online merchant to the telecommunications network. The interoperability domain 104 is supported by the Internet and includes components used by both the issuer and the acquirer. The interoperability domain 104 is typically managed by the card scheme manager such as Visa. The interoperability domain 104 can also be supported by a network other than the Internet. [0036] The issuer domain 102 includes an enrollment site 108, an issuer cardholder system 110, the cardholder client device 122, an enrollment server 112, an access control server 114, an issuer or third party identity authentication component 116, and an account holder file 118. Optionally, the issuer domain 102 can include an issuer file of approved cardholders 120. The enrollment server 112 is a computer that manages cardholder enrollment into the PAS service through presenting a series of questions via a web interface to be answered by the cardholder and verified by the issuer. As shown in FIG. 1, the card issuer operates the enrollment server 112. However, a service organization, such as Visa, may operate the enrollment server 112 on behalf of the issuer. The issuer may use a web-enabled, interactive “identity authentication service” provided by a third party during the enrollment process to help validate a cardholder's identity. The enrollment server 112 is connected via the Internet to the Internet Payment Gateway Service 124, which is in turn, connected to a telecommunications network 126, for example, VisaNet. The Internet Payment Gateway Service 124 allows the enrollment server 112 to communicate with the telecommunications network 126. The connection via the Payment Gateway Service 124 allows the enrollment server 112 to query the issuer's authorization system 127 to determine if a cardholder being enrolled has an active card account. Enrollment site 108 is an Internet web site where the cardholder can register to participate in the PAS. [0037] The access control server (ACS) 114 is a computer that has a database of cardholders registered for PAS containing cardholder account and password information. During an online payment transaction, the access control server 114 provides digitally signed receipts to merchants, controls access to PAS, and validates cardholder participation in the service. The card issuer or a service organization, such as Visa, on behalf of the issuer may operate the access control server 114. While PAS does not require any additional cardholder software to be used, optional cardholder software and hardware may be deployed. The cardholder software may be used to support additional authentication techniques such as digital certificates, integrated circuit cards (chip cards) and chip card reader, or to verify that the ACS is properly associated to the appropriate cardholder client device. Account holder file 118 is a issuer managed database for storing information relating to the cardholders that are successfully enrolled in PAS. [0038] Cardholder client device 122 is used by the cardholder to participate in PAS. Specifically, the cardholder client device 122 can be any device capable of accessing the Internet, such as a personal computer, mobile telephone, a personal data assistant, or an interactive cable television. [0039] The issuer cardholder system 110 is an issuer controlled system containing information about cardholders. This system information contains information concerning account information, services utilized by the cardholder, etc. Some of the information within the issuer cardholder system can be used in the process for enrolling cardholders in the PAS. [0040] Issuer or third party identity authentication database 116 contains information that the issuer or third party already has on file regarding cardholders. Database 116 is used by issuer in the process of enrolling cardholders to verify the identity of the cardholders. For instance, information entered by cardholders during the PAS registration process must match the information already on file in the authentication database 116 in order for cardholders to successfully register for PAS. Third parties can be companies such as Equifax. [0041] The interoperability domain 104 includes a directory server 128, a receipt file 130 and a receipt manager 131. Directory server 128 routes authentication requests from merchants to specific access control servers. The directory server 128 is operated by a service organization, such as Visa. The receipt file 130 and receipt manager 131 store signed receipts for each authenticated purchase transaction. The receipt file 130 contains information that verifies which transactions were authenticated and provides additional information during dispute resolution processes. The receipt file 130 and receipt manager 131 are operated by a service organization. The issuer, Acquirer, or merchant may also maintain a copy of the digitally signed receipt. [0042] Acquirer domain 106 includes the merchant 132 and the validation server 136. A merchant plug-in software module 134 resides at the location of the merchant 132. The merchant plug-in software module 134 is a PAS software module that integrates into a merchant's electronic commerce web sites. The plug-in software module 134 provides the interface between the PAS and the merchant's payment processing software. The validation server 136 verifies the digital signature of the card issuer used to sign the receipt returned by PAS to the merchant during the payment transaction. In alternative embodiments of the present invention, the functionality of the validation server 136 may be included within the merchant plug-in software module 134, thus eliminating the need for a separate validation server 136. The validation server 136 is operated by the merchant, the acquirer or by a service organization. [0043] The infrastructure of the PAS may be implemented in two separate architectural approaches. One approach is a centralized architecture and the second is a distributed architecture. The centralized approach requires no software or data to be stored on the cardholder's client device. In the distributed architecture, on the other hand, PAS software exists on the cardholder's client device. This software is downloaded by the enrollment server to the cardholder client device during the enrollment process. In the distributed approach, the merchants determine a cardholder's participation in the PAS through a mechanism provided by the cardholder's system client device. It should be noted that a vendor, a PAS software supplier, could choose to create the centralized, distributed, or a combination of the two architectures depending upon the vendor's or their customer's specific business requirements. FIGS. 7-10 will provide further detail as to centralized and distributed architectures. [0044] As mentioned earlier, the distributed architecture requires software to be stored on the cardholder client device. The distributed PAS provides a mechanism for a cardholder to transfer payment applications and persistent data from one cardholder client device to another cardholder client device. This mechanism provides PAS with the ability to authenticate a cardholder's identity when the cardholder client device is a different client device from the client device that the cardholder accessed during the registration process. The PAS system is also capable of authenticating the cardholder's identification when the current cardholder's client device is one that the cardholder had not used previously. In other words, cardholders can use PAS on more than one client device. At least two methods exist for transferring the PAS software between cardholder client devices. The first method involves a cardholder using a portable storage medium, such as a floppy disk, to transport the software. The second method involves the ACS dynamically downloading the software onto the additional client device to be used by the cardholder. [0045] In some embodiments, PAS can interoperate with other cardholder applications, such as electronic wallets, and PAS can operate compatibly with electronic commerce mark-up language (ECML Software). PAS also provides capabilities to implements dispute resolution procedures. For instance, the PAS allows the merchant to retain sufficient information to provide proof of cardholder authentication for the purposes of dispute resolution and chargebacks. Set-Up, Registration AND Authorization Detailed Description [0046] The description will now provide further detail regarding the various phases from setting up of the PAS to the actual authorization of online transactions. First, the procedures required to set up the various system participants such that they may operate within the PAS will be explained. Then the cardholder's process for registering with the PAS will be explained. After these phases are described, explanation will be provided as to the actual authorization of payment transactions. [0047] Setting up the PAS involves set up procedures for all the participants within the system. These participants include entities such as the merchants, financial institutions, and cardholders. First, the set up procedures of the online merchants and financial institutions will be described, and then the set up procedures for cardholders will be described. [0048] Online merchants who sign up with the PAS receive merchant plug-in software modules, such as plug-in software module 134 in FIG. 1. The plug-in software module should be specific to the computing platform and commerce server software used by the merchant. Financial institutions participating within PAS will provide bank logos and marketing designs to be incorporated into their customized PAS enrollment site template. Acquirers should also provide merchants with a service organization certification authority (CA) root certificate, a service organization certification authority SSL certificate for client authentication, and integration support. [0049] Before an Issuer can be set up to use PAS they must obtain a copy o fall PAS software specified in the Issuer domain and install hardware systems and the PAS software. Then, Issuer financial institutions will also provide identity authentication policies and participating BIN information to PAS to be used in cardholder identity verification processes. Optionally, the issuer can provide to the PAS the cardholder authentication information for pre-loading into the account holder file 118. Pre-loading facilitates large volume support of cardholders. For example, when an issuer desires to activate all or most of its cardholders for PAS, the issuer can send PIN numbers to all of its cardholders. The PIN number can then be used by each cardholder to access his or her preloaded passwords. In this manner, the enrollment process is expedited because each cardholder need not go through the formal PAS enrollment process. After the cardholders use their preloaded password for the first time, the cardholders have the option of designating a new and easier to remember password. [0050] Cardholder authentication information includes information such as business identification, country code, card account number, card expiration date, cardholder name, issuer-specific authentication data specified in the “participating BIN” data (e.g., mother's maiden name), and other information such as billing address, shipping address, social security number, telephone number, account balance, transaction history, and driver license number. Issuers should also provide account number ranges for their card account portfolios and access control server IP addresses (URLs) to the directory server. PAS will be offered through bank branded web-sites, which will allow cardholders to register with PAS. [0051] [0051]FIG. 2 illustrates the process through which a cardholder registers with PAS according to one embodiment of the present invention. As shown in step 1, cardholders visit an enrollment server Internet web site maintained by a financial institution, such as an issuer. Cardholders register with PAS by registering their credit card account numbers. Alternatively, cards such as check and debit cards may also be registered. Also, cardholders may register one or more cards with PAS. As shown at step 2, the cardholder enters information such as a cardholder primary account number (PAN), name and card expiration date. Additional information may also be entered by the consumer at this point. For instance, address, e-mail address, shopper identification, an account verification value, cardholder-specific password, and issuer-specific authentication information may also be entered by the cardholder. This information can be entered in a page at the enrollment web site such as page 300 shown in FIG. 3. [0052] After the cardholder enters the requested information at the enrollment site 108, PAS verifies that the cardholder PAN falls within a card range that is registered by the issuer in the directory server 128 of the Interoperability domain 104. The PAS can verify cardholder identities using various methods. First, as just mentioned, the PAS can verify the cardholder identity through a third party authentication database or through the issuer's own authentication database. Additionally, verification can be performed by using the issuer provided file of approved cardholders 120, by transmitting status check authorizations to the issuer, and by comparing responses to pre-loaded information provided by financial institutions. [0053] If the PAN is not within an issuer enrolled card range, the enrollment is rejected and the enrollment process is terminated. If the PAN is within an enrolled card range, an authorization for one dollar will be submitted through a service organization payment network, such as VisaNet, to the issuer financial institution. The authorization of the one-dollar transaction allows the issuer to verify the card account status, verify the address using the Address Verification Service, and verify the Cardholder Verification Value 2 (CVV2). The CVV2 is a three-digit number printed on the signature strip on the back of the payment cards. [0054] If the card is approved, then at step 3, the cardholder will then be prompted for additional authentication information to verify the cardholder's identity in an interactive, real-time, online session. In some embodiments of the present invention, the cardholder can also be requested to enter a password and a “hint question and response” pair that will be used to authenticate the cardholder during the purchase transaction. [0055] As shown in step 4, when the cardholder's identity is verified and the appropriate responses are returned, PAS sends an authorization message to the issuer financial institution. Then at step 5, the enrollment server 112 passes cardholder information to the access control server 114 to set up records in the account holder file 118. The account holder file, such as account holder file 118 in FIG. 1, can store information such as: financial institution BIN numbers, account numbers, expiration dates, first and last names, driver's license numbers, billing addresses, social security numbers, cardholder passwords, cardholder password questions, cardholder password answers, cardholder email addresses, third party identity scores, and other information. [0056] In some embodiments of the present invention, during the registration process, the cardholder can be asked to enter a phrase, called the personal assurance message (PAM), that is recognizable to the cardholder. PAM is later presented to the cardholder by the issuer during a payment transaction. Since only the issuer knows the cardholder's designated PAM, the cardholder can be assured that a dialog window used with PAS was delivered from the cardholder's issuer. An example PAM is, “the sky is blue.”
[0057] It should be noted that cardholders require no new client software or devices to use PAS. In some cases however, chip card implementations of PAS may require additional cardholder components such as a chip card reader. In a preferred embodiment, the consumer registration process utilizes security protocols such as SSL channel encryption to protect data transmitted across the internet between the cardholder and the enrollment server. [0058] Also, during the consumer registration or enrollment process, each financial institution may display its own “terms of use” and/or “data privacy policy.” Each financial institution has the ability to require registering cardholders to either accept or not accept the terms and policies in order to complete the registration process. The version numbers of the “terms of use” and/or the “data privacy policy” accepted by each consumer should be saved by the financial institutions. [0059] After PAS system participants are set up and the cardholders are registered, a payment transaction may be authenticated utilizing PAS. A PAS authenticated payment transaction is illustrated in FIG. 4. In step 1 of FIG. 4, a cardholder visits a merchant's electronic commerce site on the Internet. After the cardholder selects the products or services he or she wishes to purchase, the cardholder begins the checkout process, completes the checkout form, and then clicks on a “buy” button. [0060] After the “buy” button is selected, as shown in step 2 of FIG. 4, the merchant plug-in software module is activated and then performs a verification process to determine whether the cardholder's specific account is registered with the PAS. There are various methods by which the merchant plug-in software module can determine if the cardholder is registered with PAS. For instance, a two-step process in which the directory server and then the ACS accociated with the cardholder is checked, a process where only the ACS is checked, and a method in which the merchant can check a cache memory containing the same information held in the directory server. [0061] A description of the two-step process will now be provided. In the first step, the merchant plug-in software module identifies the card account number and queries the directory server 128 to verify that the account number is within a range of numbers associated with an issuer bank that is a PAS participant. If the account number does not fall within a range of account numbers defined on the directory server 128, then the issuer and thereby its cardholder are not registered with the PAS. In this case, the merchant is notified that the account number is not registered with PAS and the merchant plug-in software module returns control of the transaction back to the merchant storefront software. At this point, the merchant storefront software can proceed with the transaction, as it normally would, refuse further service to the cardholder, or proceed with alternative payment methods. [0062] On the other hand, if the account number is determined to be within a range of account numbers present in directory server 128, then the second step of the verification process begins. The second step of the verification begins by the directory sending the ACS capable of authenticating the cardholder the card number to determine if the card is enrolled. If the card is not enrolled, the enrollment process is terminated. If the ACS indicates that the card is enrolled, the ACS via the directory server returns its URL Internet address to the merchant plug-in. The merchant plug-in then invokes the ACS via the cardholder client device and it resident browser. Once again it is noted that there can be multiple ACS's in PAS. [0063] A second method of checking to see if the cardholder is registered with PAS is for the merchant plug-in software module to directly query the ACS without first querying the directory server. The third method, as mentioned above, is for the merchant to have a cache memory containing the same information held at the directory server. In this manner, the merchant can at least do a preliminary check. [0064] It should be noted that there could be more than one physical directory server in the PAS system. However, it is preferable that there be only one logical directory server. In other words, all of the directory servers should be consistent in that they contain the same information. [0065] If the cardholder is a PAS participant, the ACS displays a bank branded window to the cardholder. The bank branded window contains basic payment transaction information and prompts the cardholder for his PAS password. See FIG. 5 for an exemplary window 500 that prompts the cardholder for his or her PAS password. The cardholder enters his or her password and the ACS verifies the password. As is common today, the cardholder can be given a certain number of attempts to correctly enter the password. If the cardholder is unable to correctly enter the password, then the cardholder can be prompted with the hint question that was established during the cardholder's registration process. Preferably, the cardholder is given one chance to enter the correct answer in response to the hint question. [0066] The payment authentication continues if the correct password is immediately entered or is the correct response is provided by the cardholder to the hint question within the allowed number of attempts. The ACS then proceeds to digitally sign a receipt using the issuer's signature key or a service provider's key. This receipt will contain the merchant name, card account number, payment amount, and the payment date. The receipt file 130 stores the following transaction data: merchant name, merchant URL, card account number, expiration date, payment amount, payment date, the issuer payment signature and the cardholder authentication verification value. The ACS then redirects the cardholder back to the merchant plug-in through the cardholder browser. At this point, the ACS also passes to the merchant the digitally signed receipt and the determination as to whether the cardholder has been authenticated. The validation server 136, in the acquirer domain 106, is used by the merchant plug-in 134, to verify the digital signature used to sign the payment receipt. After verifying the digital signature, the cardholder is deemed “authenticated.” In some embodiments of the invention, after the transaction is completed, the cardholder will also have the ability to re-register his or her card account and create a new password to be used for future online purchases. [0067] After the cardholder is authenticated in step 3, step 4 initiates the process for authorizing the specific cardholder's account. Specifically, in step 4, the merchant, through the merchant plug-in software module, sends an authorization message to a payment network such as VisaNet. The payment network, in turn, forwards the authorization message and the ECT to an issuer financial institution. The authorization message is a message as is commonly known in the art. The authorization message is sent to the issuer so that the issuer financial institution can verify to the merchant that a specific account is in good standing and has adequate credit line for the requested purchase amount of the payment transaction. The ECI indicates that the transaction was completed over the Internet and indicates that level of message security (i.e., channel encryption (SSL), in the clear) and authentication used. [0068] In alternative embodiments of the invention, the merchant is capable of providing additional information along with the authorization message. For instance, the following information can also be sent: a flag indicating if the cardholder was successfully authenticated, account information, digital signatures, a cardholder verification value 2, card authentication verification value (CAVV), an offline PIN authenticated by chip card EMV cryptogram, and the necessary fields to provide the merchant with guaranteed payment. The CAVV is data is created by the ACS which authenticated the cardholder and is a unique value for a given payment card and a specific payment transaction from that card. It is used by PAS card issuers to uniquely identify authenticated payment transaction if any subsequent disputes occur. After the issuer financial institution processing of the authorization transaction is complete, control of the purchase transaction is then returned to the merchant's storefront software via the payment network. The issuer then returns the authorization response via the payment network to the merchant. In step 5 of FIG. 4, the issuer financial institution will either authorize or decline the transaction. In some embodiments, the authorization messages can be batched and sent in a group at a later time. The PAS authentication information is also included in the batch authorization messages. [0069] The access control server 114 is capable of various other functions. For example, the access control server can deactivate registered accounts from the database. Accounts can be deactivated manually, by the cardholder, or by the issuer. The access control server 114 can also provide a simplified renewal registration process when the cardholder receives a replacement card. The access control server 114 can support multiple users of the same registered account with unique access control information. When providing a user with a connection to the access control server 114 for purchase transactions or account updating, the access control server 114 can validate the user as an authorized cardholder of the registered account through one or more of the following mechanisms: pass phrase, digital signatures, an online PIN number, or and off-line PIN authentication by chip card EMV cryptogram. [0070] In the PAS, the merchant 132 can interoperate with existing systems where the merchant has the cardholder account information on file, interoperate with existing merchant authorization and clearing systems, support third parties who provide services to multiple merchants, support a variety of payment interfaces between the merchant and the acquirer, and minimize the mandatory impact to payment network authorization messages from the acquirer when setting the value of the electronic commerce indicator (ECI). [0071] One method for routing transactions from the merchant to an access control server is to have a directory that provides the address of the server based on the cardholder account number. In such a method, the PAS requests for routing information is only acceptable from authenticated merchants. If PAS detects and reports activity from a merchant that exceeds its normal activity, then PAS is able to deny access to a merchant whose acquirer indicates that such access is no longer valid. This could be the case when merchant fraud is deemed probable. Merchant authentication to the PAS system can be deployed, but deployment is not required. Merchant authentication can help minimize merchant fraud. Detailed Message Flow for PAS Payment Transactions [0072] [0072]FIG. 6 illustrates exemplary messages that are sent during the payment transaction superimposed over the PAS architecture. As described above, the purchase transaction begins when a cardholder visits a merchant website via a browser and selects items to purchase. The merchant's payment system will ask the cardholder to enter his or her payment information. Generally, entry of the payment information should occur in a secure environment, for example, through the use of SSL encryption protocol. When the cardholder indicates that he or she is ready to finalize the transaction, the merchant's payment system invokes the PAS merchant plug-in software module 134. Then as shown by line la, the plug-in software module 134 checks the directory server 128 for the specific URL of the ACS that may contain the cardholder's Payer Authentication Number (PAN) to validate that the cardholder is enrolled in the service. Alternatively, the plug-in software module 134 checks its own cache memory that contains this information. The software 134 searches for the PAN by formatting a VerifyEnrollmentReq message using the cardholder PAN. If not already established, the merchant plug-in software 134 will establish a secure connection with and authenticate itself to the directory server 128 or the access control server 114. The merchant plug-in software 114 will search for a card range entry that corresponds to the cardholder PAN at various locations. One place that is searched is the merchant plug-in software cache of directory information. The merchant plug-in software module can also check the directory server and the access control server. [0073] After the merchant plug-in software 114 conducts the search, the VerifyEnrollmentReq message is transmitted to the access control server 114 either directly, as shown by line 1 b, or after first passing through the directory server 128, as shown by line 1 a. When the VerifyEnrollmentReq message is transmitted to the access control server 114 via the directory server 128, the directory server 128 searches for a record corresponding to the cardholder PAN contained in the VerifyEnrollmentReq message. On unsuccessful match, the directory server 128 will format a VerifyEnrollmentRes message with no URL value(s) and set the value of Status of PAN Enrollment or VerifyEnrollmentRes-Status to “N.” The VerifyEnrollmentRes message is then returned to the merchant plug-in software. On the other hand, upon successful match, the directory server 128 will, if not already established, establish a secure connection with and authenticate itself to the access control server URL. Then, the VerifyEnrollmentReq message is forwarded to the access control server URL. If that URL is not available, the merchant plug-in should proceed to the next access control server URL value (if available), and allow for up to a maximum of up to five access control server URL's to be searched. Of course, the number of URL's attempted is variable. If unsuccessful on all attempts, a VerifyEnrollmentRes message is returned to the merchant plug-in with VerifyEnrollmentRes-Status set to “N” to indicate to the merchant that the purchase transaction cannot be processed as a PAS transaction. [0074] After the VerifyEnrollmentReq message is received by the access control server 114, the access control server accepts the cardholder PAN from the VerifyEnrollmentReq message and validates it against the account holder file 118. The access control server 114 then formats a VerifyEnrollmentRes message. In the case where a successful match occurs, the access control server sets the Status of PAN Enrollment to “Y,” creates a single use proxy PAN, which the access control server 114 will internally associate with the PAN, and populates the URL field(s) in the VerifyEnrollmentReq message. In the case of an unsuccessful match, the access control server sets the Status of PAN Enrollment to “N.” Then, as shown by line 2 a, the access control server returns a VerifyEnrollmentRes message back to the merchant plug-in through the directory server 128. For the case when a VerifyEnrollmentReq message is transmitted directly to the access control server, the VerifyEnrollmentRes message is transmitted directly back to the merchant plug-in as shown in line 2 b. [0075] Caching of the directory server 128 can be facilitated by utilizing a CRReq and CRRes message pair. The CRReq message is sent from the merchant plug-in module to the directory server and requests the list of participating card ranges, in order for the plug-in module to update its cache. The CRRes message is the response containing the participating ranges. [0076] After the issuer access control server returns the VerifyEnrollmentRes message, the PAS system checks to see if the cardholder client device has distributed authentication capabilities by using a QueryCardholderReq and QueryCardholderRes message pair. The merchant plug-in will format and send a query, the QueryCardholderReq message, to the cardholder client device 122 to determine if a distributed PAS cardholder module is resident. Sending of the QueryCardholderReq message is shown in FIG. 6 by line 3. If any distributed authentication options are returned in the QueryCardholderRes message, the merchant plug-in will communicate directly with the PAS cardholder client software to perform the authenticated steps. Sending of the QueryCardholderRes message is shown in FIG. 6 by line 4. [0077] If the VerifyEnrollmentRes-Status has a value not equal to “Y,” then the merchant is notified that the purchase transaction cannot be processed as a PAS transaction. However, if the VerifyEnrollmentRes-Status has a value of “Y,” then the merchant plug-in will format a payment request message, PAReq. The merchant plug-in will send the PAReq message via the cardholder client device browser to the issuer's ACS server, as is shown by line 5. [0078] Additionally, by using the QueryCardholderReq and QueryCardholderRes messages, the VerifyEnrollmentReq and VerifyEnrollmentRes messages may be eliminated. Cardholder client software could be deployed with issuer's ACS URL embedded in the software. The merchant plug-in will complete the QueryCardholderReq and QueryCardholderRes messages first. If PAS cardholder client software is detected, the Payer Authentication Request (PAReq) message could be sent to the ACS or the cardholder client software without having to conduct the VerifyEnrollmentReq and VerifyEnrollmentRes messages. [0079] After the merchant plug-in passes the Payer Authentication Request (PAReq) to the issuer's ACS, the ASC displays a window to the cardholder. The window displays the payment details contained in the Payer Authentication Response (PARes) in addition to other items such as: a Issuer's logo, a service organization mark or brand logo, merchant name, merchant location (URL), total purchase amount and currency, purchase date, card number, installment/recurring payment terms, order description or link to description, special terms and conditions of sale or link to this information, personal assurance message (PAM), and prompt for the cardholder's password. [0080] The ACS will then prompt the cardholder to enter the appropriate password. The ACS accepts the cardholder input and validates it against the account holder file 118. The PAS will allow, for example, a number of unsuccessful attempts (e.g., three attempts) to enter the correct password. Of course, the number of attempts allowed can be varied. After the final unsuccessful attempt, the PAS will display the hint question. The cardholder will need to enter the correct hint question response. The hint question associated with the cardholder is then displayed. The cardholder is provided at least one attempt to enter the correct response. If the cardholder provides an incorrect response, merchant can be notified that PAS transaction cannot be completed. If the cardholder provides the correct response, the transaction should be treated as if the password was matched. Note, if there is more than one entry for an account number, the various cardholder names are displayed in a drop down window. The cardholder can then select his or her name. [0081] Upon matching of the password, the ACS generates and digitally signs a payment response message, PARes. The ACS also generates and sends a SaveReceipt message to the receipt file 130 and receipt manager 131, as is shown by line 7. As shown by line 7 a, the SaveReceipt message may also be passed from the receipt file 130 to the issuers authorization and settlement system 138 to allow the issuer to match up the payment authorization request with the payer authenticated transaction in real time. Sending the SaveReceipt message to the issuers authorization and settlement system 138 allows the issuer to determine simultaneously if the authorization request is for an authenticated purchase. The ACS will then re-direct the signed PARes back to the merchant server plug-in, as is shown by line 6. [0082] After signed PARes is transmitted back to the merchant plug-in, the plug-in is reactivated. If the authentication status is a “Y,” the plug-in sends the PARes to the validation server 136. In the case that the validation server functions are provided by the merchant plug-in, the merchant plug-in validates the PARes signature and returns the result of the signature validation. If the signature cannot be validated, the merchant plug-in will notify the merchant the transaction cannot be treated as a PAS transaction. If the authentication status is a “N,” the merchant should send a prompt to the cardholder asking for additional information, request the cardholder to use a different payment card or form of payment, or process the payment transaction as a non-authenticated payment transaction. [0083] In the case that the acquirer domain 106 contains a validation server, the validation server 136 validates the signature on the PARes. The validation server 136 then returns the result of the signature validation to the merchant plug-in. If the signature cannot be validated, merchant plug-in notifies the merchant that the transaction cannot be treated as a PAS transaction. On the other hand, if the signature is validated, the merchant proceeds with an authenticated payment authorization. The PARes message may also be passed from the merchant to its acquirer payment processor 140 as shown in line 6 a. The PARes message may then be passed from the acquirer through a telecommunications network 142 to the issuer. Thus, the payer authentication results are made available to the issuer as part of the standard payment authorization process. [0084] Now the security issues related to the various channels of transmission will be discussed. As a base-line, all the channels of transmission are preferably encrypted using 128-bit SSL. The channel between the cardholder and the merchant includes two channels. The merchant should secure the connection that is used when the cardholder enters the payment information by using an SSL certificate obtained from a service organization-approved certificate authority. The merchant should also secure the connection used to transport the PARes message from the cardholder to the merchant plug-in by using an SSL certificate obtained from a service organization-approved certificate authority. [0085] The channel between the cardholder and the ACS should be encrypted by the ACS by using an SSL certificate obtained from a service organization-approved certificate authority. This channel is used for two purposes. First to send the PAReq message from the merchant plug-in to the ACS, and secondly to send the signed PARes message from the ACS to the cardholder. [0086] The channel between the cardholder and the enrollment server should be encrypted by the enrollment server using an SSL certificate obtained from a service organization-approved certificate authority. This channel is used to accept the cardholder enrollment information. [0087] The channel between the merchant and the directory server, and between the directory server and the ACS server should be secured through a service organization-issued SSL encryption certificate in order to protect the PAN data contained in the VerifyEnrollmentReq and VerifyEnrollmentRes messages and the ACS URL address contained in the VerifyEnrollmentRes message. [0088] The channel between the ACS to the cardholder should be encrypted to protect the prompt for the cardholder's password and the cardholder entered password. This channel should be protected with an SSL certificate obtained from a service organization-approved certificate authority. Centralized and Distributed Architecture Embodiments [0089] [0089]FIGS. 7 and 8 illustrate a centralized architecture and FIGS. 9 and 10 illustrate a distributed architecture. FIGS. 7-10 also show the superimposed representations of the message flows during both the enrollment and payment processes. [0090] [0090]FIG. 7 illustrates the message flows on the centralized PAS architecture according to one embodiment of the present invention. As previously mentioned, the centralized approach requires no software or data to be stored on the cardholder's system and the cardholder's password is stored at a central data storage site (AHF). The centralized architecture 700 consists of a cardholder client device, for example, a personal computer (PC) 702, and the PAS 704. The cardholder client device 702 supports an Internet browser 706 that allows the cardholder to access PAS. PAS 704 includes at least an enrollment server 708. The various other components of the PAS system have not been illustrated so not to unnecessarily complicate the representation of the centralized architecture. The centralized enrollment process begins at step 1 when the cardholder goes to the bank Internet site and the specific enrollment page to register with PAS. In response to the cardholders inquiry, in step 2, the enrollment server 708 presents the cardholder with authentication questions. In step 3, the cardholder answers the authentication questions and provides the required password. [0091] The enrollment server then validates the answers through a validation process in step 4. The result of the validation process is returned to the enrollment server 708 in step 5. At step 6, databases and directory servers are updated. At step 7, the cardholder is informed whether or not his or her registration has been confirmed. [0092] [0092]FIG. 8 illustrates the centralized payment flow that occurs between the cardholder client device 702, PAS 704, and the merchant system 720, according to one embodiment of the present invention. In FIG. 8, PAS 704 is shown to include a directory server 710, the ACS server 712, and a receipt database 714. The merchant server includes a storefront software program 722, a PAS provided merchant plug-in software module 724, and a payment system 726. The centralized payment flow begins when the cardholder shops at the merchant's electronic commerce web site at step 1. When the cardholder begins the checkout process, step 2 shows that the merchant plug-in module 724 checks to see if the cardholder has been enrolled in the directory server 710. If the cardholder is enrolled, the directory server returns the URL address of the issuer's ACS server to the merchant plug-in. At step 3, the merchant plug-in module 724 sends a PAReq message to the ACS 712. In response to the PAReq message, the cardholder eventually enters his or her password. Assuming the password is validated successfully by the ACS server, in step 4, a digitally signed PARes message is sent to the merchant plug-in module from the ACS 712 informing the merchant that the transaction is authenticated. The status of the transaction is sent to the payment system 726 in step 5. To conclude the transaction, in step 6, the merchant's storefront software 722 sends the payment data to the payment system. [0093] [0093]FIG. 9 illustrates the enrollment flow in the distributed PAS architecture according to one embodiment of the present invention. As previously mentioned, the distributed architecture stores software and/or data on the cardholder's system. In the distributed approach, merchants determine a cardholder's participation in the PAS through a mechanism within the PAS cardholder module on the cardholder client device. The distributed architecture 900 includes at least the cardholder client device 902, which includes an Internet browser 904, and PAS 906, which includes an enrollment server 908. Note that in the distributed approach, there is no directory server. The enrollment process begins when a cardholder goes to the bank specific Internet enrollment page to register with PAS in step 1. In step 2, the cardholder is presented with authentication questions. In step 3, the cardholder returns answers to the authentication questions to the enrollment server 908. The cardholders answers are validated in step 4 through a validation process. The results of the validation process are returned to the enrollment server 908 in step 5. If the cardholder is validated, then a cardholder software module 910 and a certificate are provided to the cardholder in step 6. These are down-loaded across the internet from the enrollment server. [0094] [0094]FIG. 10 illustrates the payment flow in the distributed PAS architecture according to one embodiment of the present invention. The merchant module 950 includes the storefront software 952, the merchant plug-in software module 954 and the payment system 956. The payment process begins, as usual, in step 1 when a cardholder shops and proceeds to checkout at a merchant's electronic commerce web site. In step 2 the merchant checks to see if the cardholder software module 910 is present in the cardholder's client device. If the cardholder software module 910 is present, the merchant module 954 sends a PAReq message to the cardholder software module 910, rather than an ACS as in the centralized architecture. The cardholder PAS software module, which knows the internet URL address of its issuer's ACS server, passes on the PAReq message to the ACS server. The ACS server dialogs with the cardholder module to ask the cardholder for his password. If the password supplied by the cardholder compares equal to the password for the same cardholder on the AHF, the cardholder is authenticated. Then the ACS server responds with the PARes message to the merchant module in step 4. The status of the authentication process and the associated data is sent to the payment system 956 in step 5. A receipt of the transactions is sent to the receipt database 960 in step 6. To conclude the transaction and the payment data are sent to the payment system from the storefront in step 7. Chip Card Embodiment [0095] A chip card embodiment of the Payer Authentication Service (PAS) involves a cardholder using an integrated circuit card (also known as a chip card or a smart card) and a chip card reader. The chip card embodiment adds another level of authentication in an online purchase transaction. Where the previously described PAS provides the ability to authenticate the identity of the cardholder in an online purchase, the chip card embodiment of PAS also provides the ability to authenticate that the cardholder actually has possession of his or her chip card. There are a variety of methods that can be used to validate the authenticity of the chip card. One approach is to use a secret generated by the chip, which can then be validated by the issuer's ACS. [0096] The chip card embodiment can also use the PAS to authenticate the cardholder as described previously in this document in addition the authenticating the card. Two techniques may be used to provide the PAS password to the ACS. In a first technique, the chip card credit and debit application of the chip card prompts the cardholder to type in their PAS password. The cardholder enters in the password in a similar way as described previously. The password is then forwarded to the ACS. [0097] In a second technique, the PAS password is automatically supplied to the ACS by the chip card. This technique uses passwords stored on the chip card to authenticate the cardholder in order to allow the cardholder to utilize the chip card. This approach uses an applet resident on the card referred to as the “Access” applet, because it provides universal access to the card, and its resident applications, and can be used to authenticate a cardholder. The Access applet can also disable access to the applications on the card. Upon presentation of the single, universal “Access” password and authentication of the cardholder, the Access applet then allows the cardholder to access to a variety of services or applications (e.g., access to an online banking site, access to an electronic bill payment service). For example, by presentation of a single “Access” password, the applet then allows use of any stored passwords on the card. [0098] Generally, the set up procedures and the authentication process for the chip card embodiment are the same as for the traditional card embodiment. The differences between the chip card embodiment and the traditional chip card embodiment will be evident in the description that follows. [0099] The chip card embodiment of the PAS will be described relative to each of FIGS. 10A, 11, 12, 12A and 13. FIG. 10A illustrates one embodiment of the chip card payer authorization service architecture. FIG. 11 provides a general description of the PAS chip card and cardholder authentication in an authenticated payment transaction. FIG. 12 illustrates a combination of a system architecture layout along with superimposed process flows. FIG. 12A illustrates a more detailed flow of messages during a payment transaction using a payer authentication service with a chip card. Finally, FIG. 13 is used to illustrate a different embodiment of the chip card payer authentication system. Specifically, FIG. 13 illustrates the chip card embodiment with an added feature of the Access application that is used to control access to the various applications that may be on a chip card. [0100] [0100]FIG. 10A provides a high-level system architecture view of one embodiment of the chip card payer authorization service. As usual, the payment transaction begins when the cardholder accesses a merchant's electronic commerce web site using a cardholder client device 122. The cardholder client device 122 is connected to the issuer access control server 114, which has a chip payer authentication ACS plug-in 115. The issuer ACS 114 is connected to an account holder file 118, which is in turn connected to a receipt file 130. The merchant 132 uses a merchant plug-in software module 134 to participate in the payer authentication service. The merchant 132 is connected to the directory server 128, the validation server 136, and the acquirer payment processor 182. The acquirer payment processor 182 is connected to the payment network 126, which is in turn connected to the issuer 180. [0101] [0101]FIG. 11 illustrates a flow chart that provides a general description of a payment transaction using the chip card system. The payment transaction begins at block 1100 when a cardholder shops at an online merchant web site and desires to conclude the shopping experience at the checkout web page. In block 1110, the PAS verifies that the cardholder is a PAS registered participant, for example, after the cardholder clicks the “buy” button. Then in block 1120, the merchant plug-in module sends a PAReq message to the associated access control server, which leads to block 1130 where the access server via the PAS cardholder module in the cardholder client device verifies that the cardholder client device includes chip card reader. If the cardholder does not have a chip card reader, then the payment transaction is either ended or another payment method must be used. [0102] If the cardholder client device has a chip card reader, then in block 1140 the consumer is directed to insert his or her chip card into the chip card reader. In block 1150, the cardholder module in the cardholder client device requests the chip card to generate a cryptogram based upon secret information contained in the chip card. Also, in block 1160, the cardholder is requested to enter his or her registered PAS password. In block 1170, the chip card generated cryptogram and the cardholder entered password are both sent to the ACS for authentication. [0103] At block 1180, the ACS validates the PAS password in methods similar to those described for the non-chip card PAS system described previously as in FIG. 4. The ACS also independently generates another copy of the cryptogram for this chip card using information in the various components of the ACS server—see FIG. 12. If the PAS password matches, then the identity of the cardholder is authenticated. At block 1190, if the cryptograms generated by each the chip card and the ACS are matching, then it is verified that the actual chip card is being used by the cardholder. At block 1195, a payment response message is sent back by the ACS to the merchant plug-in software module. The payment response message contains a card authorization verification value (CAVV), to inform the merchant that the cardholder has been authenticated and that the actual card is being used at the cardholder client device is the proper card. The purchase transaction then proceeds as was described previously. [0104] Now, FIG. 12 is presented to illustrate payment process flows that are superimposed upon a chip card system architecture according to one embodiment of the present invention. The chip card authentication architecture 1500 involves the cardholder client device 1510, the issuer's ACS 1520, the cardholder 1530, the chip card 1540, and the requesting party 1550. The requesting party in the PAS environment is typically the merchant. The cardholder client device 1510 includes a display device 1512, terminal software 1514, PIN pad or key entry device 1516, and the card reader 1518. The card reader 1528 is the electromechanical device into which a chip card is inserted for use with a terminal application, functionally equivalent to a Card Acceptance Device or InterFace Device (IFD in a physical point of sale environment). [0105] The ACS 1520 includes PAS authentication software 1522, a hardware security module 1524, the cardholder database 1526, and system software 1528. The chip card 1540 includes a chip card credit and debit application 1542 such as the Visa Smart Debit Credit Application (VSDC). It should be appreciated that a general debit and credit application can be utilized in situations where the VSDC application is mentioned in the present specification. [0106] The requesting party 1550 is the merchant associated with a particular payment transaction. The issuer server 1520 is the ACS operated by an issuer or a third party on behalf of an issuer capable of validating a chip card's cryptogram. It acts as the interface between the requesting party 1550 and the cardholder client device 1510. The cardholder client device 1510 is a system of components and software that acts as an interface among the cardholder 1530, the chip card 1540 and the issuer's ACS 1520 such as a personal computer, a mobile phone, a settop box or any other device or collection of functionally comparable components. [0107] The cardholder 1530 is a party who is usually in control of the cardholder client device 1510 and capable of performing functions like inserting a card, entering a PIN or checking to see whether components of the cardholder client device 1510 are properly operational. Chip card 1540 is a payment card from an issuer that contains the chip card credit and debit application 1542, for example Visa Smart Debit Credit Application. [0108] Referring to the numbered circles in FIG. 12, which correspond to ordered process steps, the following is a brief scenario describing what happens during chip card payment authentication processing. In step 1, a requesting party such as a merchant, determines that chip card authentication is required and calls upon the issuer ACS to do it. [0109] In step 2, the issuer's ACS, having obtained the primary account number (PAN) for the card to be authenticated from the pay request message sends a message called the VSDC Authentication Request to the cardholder client device. [0110] In step 3, the cardholder client device, acting in response to the request from the issuer's ACS attempts to authenticate the card. First it determines whether the necessary components are present and operational. Then, by putting a message on the display, the cardholder client device requests the cardholder to insert the chip card to be authenticated into the card reader. [0111] In step 4, the cardholder responds by inserting the chip card in the card reader which generates a message to the cardholder client device informing it the card has been inserted, or depending upon how sophisticated the card reader is, the cardholder client device may need to poll the card reader using the path numbered 5 to determine whether it is now able to read the card. [0112] In step 5, the cardholder client device initializes the chip card and the VSDC application on the chip card and then communicates with them to direct the return of a cryptogram from the chip card for later validation. [0113] In step 6, in the course of communicating with the chip card several exchanges occur. The chip card may request that the cardholder to enter a PIN. If so then the cardholder client device notifies the cardholder to enter a PIN via a PIN pad or other key entry device. [0114] In step 7, while sending messages (commands) and receiving responses from the card in steps 5 and 6, the cardholder client device was gathering the information necessary to compose the VSDC Authentication Response which it now sends to the issuer's ACS. The Access Control server using information provided in the VSDC Authentication Response message attempts to authenticate both the cardholder via his password and the chip card via its cryptogram. [0115] In step 8, the issuer's ACS replies via a payment response message to the merchant or requesting party with the results of the cardholder and chip card authentication processes. [0116] The principal functional capabilities of each entity in the VSDC Authentication service will now be described. The requesting party or merchant functions to signal or trigger the issuer's ACS to initiate chip card VSDC Authentication processing, provide issuer ACS with the necessary data to perform VSDC Authentication, and uses the result of VSDC Authentication provided by issuer's ACS. [0117] The issuer's ACS functions to securely store cryptographic keys needed for cryptogram validation, collect the necessary data to perform VSDC Authentication processing, initiate VSDC Authentication processing by sending VSDC Authentication Request message to cardholder client device software, validate cryptogram sent from the chip card via the cardholder client device in its attached Hardware Security Module (HSM), and provide the result of the validation of cryptogram to requesting party or merchant via the payment response message. [0118] The cardholder client device functions to communicate with issuer ACS, receive VSDC Authentication Request message, communicate with cardholder for card insertion/removal and PIN entry, communicate with the chip card, send necessary data for VSDC Authentication to chip card, receive necessary data for VSDC Authentication from chip card, receive cryptogram from chip card, and send the card generated cryptogram to the issuer ACS. The cardholder client device also requests the cardholder to enter his password and passes the entered password to the ACS. [0119] The cardholder functions to insert chip card into card reader, determine whether the chip card environment is ready, enter PIN, remove chip card from card reader, and enter his or her password. DETAILED MESSAGE FLOW EXAMPLE [0120] [0120]FIG. 12A illustrates a detailed flow of messages between the chip card 1540, the cardholder client system 1510, and the issuer's access control server 1520. This flow of messages defines the manner in which chip card payment authentication processing is performed. The flow of messages is organized in a top-down manner that progresses through the phases of the authentication process. [0121] Explanation of Message Flow [0122] This section briefly describes the phases of the VSDC Authentication processing in the order in which they occur as illustrated in the preceding diagram: [0123] 4.2.1.1 VSDC Authentication Request—The issuer's ACS starts the VSDC Authentication processing. [0124] 4.3.2.1 Initiation—The cardholder client device software prompts the cardholder to insert the chip card into the card reader. [0125] 4.3.2.2 Application Selection—The cardholder client device software selects a VSDC application from the chip card. [0126] 4.3.2.3 Application Initiation—The cardholder client system device and the chip card initiate VSDC Authentication processing. [0127] 4.3.2.4 Read Application Data—The cardholder client system device reads the application data from the chip card. [0128] 4.3.2.5 Cardholder Verification (Optional)—The cardholder client device software performs offline PIN verification to authenticate cardholder. [0129] 4.3.2.6 Terminal Action Analysis—The cardholder client system device requests the chip card to generate the cryptogram. [0130] 4.3.2.7 Completion—The cardholder client device software completes and terminates the processing for VSDC Authentication. [0131] 4.2.1.2 VSDC Authentication Response—The cardholder client device software returns the cryptogram and the other data to the issuer's ACS server. [0132] Now the message flow and the functions involved in generating the flow between the cardholder client device software and the chip card will be described. VSDC Authentication Request is the message that delivers the necessary data from the issuer access control server to the cardholder client device software to invoke the cardholder client device software to start processing. VSDC Authentication response is the message that returns the cryptogram and the supporting data from the cardholder client device software to the issuer's ACS. [0133] Now, the details of message and processing flow will be described: [0134] VSDC Authentication Request is the message that invokes the cardholder client device software to start VSDC Authentication processing. This message contains the necessary data for the chip card to generate a cryptogram. [0135] The issuer's ACS preferably should obtain or generate the necessary data listed here: Amount, Authorized; Application Identifier; Application Label (of VSDC application); Application Preferred Name; Terminal Country Code; Transaction Currency Code; Transaction Date; Transaction Type; and Unpredictable Number. [0136] The source of these data varies dependent on the authentication environment within which VSDC Authentication is working. The issuer's ACS preferably should construct a VSDC Authentication Request to deliver these data to the cardholder client device software. This message preferably should invoke the cardholder client device software to start the processing between the cardholder client device software and the chip card. [0137] The cardholder client device software preferably should start the initiation process. [0138] 4.2.1.2. VSDC Authentication Response [0139] VSDC Authentication Response is the message that delivers the cryptogram and the other supporting data to the issuer' ACS server. VSDC Authentication Response message is also used to deliver the status code when errors and exceptions occur during VSDC Authentication processing. The VSDC Authentication Response message is also used to provide the access control server with the cardholder's password. [0140] The cardholder client device software preferably should obtain all the necessary data described in the table 1 below. TABLE 1 Data Element Source Cryptogram From the first GENERATE AC response message. Derivation Key Index From the first GENERATE AC response (DKI) message. (DKI is a component of issuer Application Data.) Cryptogram Version From the first GENERATE AC response Number message. (Cryptogram Version Number is a component of issuer Application Data.) Application Interchange From the GET PROCESSING OPTIONS Profile (AIP) response message. Application Transaction From the first GENERATE AC response Counter (ATC) message. Card Verification Results From the first GENERATE AC response (CVR) message. (CVR is a component of issuer Application Data.) Terminal Verification From the cardholder client device software. Results (TVR) PAN Sequence Number From the READ RECORD response message. Status Code From the cardholder client device software. Reserved for future use 1 Filled by “00000000000000000000” Reserved for future use 2 Undefined format and content, 10 bytes. [0141] The cardholder client device software preferably should construct a VSDC Authentication Response message to deliver these data to the issuer's ACS server. [0142] The issuer's ACS server preferably should retrieve the data from the VSDC Authentication Response and validate both the cryptogram and the cardholder's password. The issuer's ACS server receives the VSDC Authentication Response containing status codes when errors or exceptions occur and when processing completes successfully between the cardholder client device software and the chip card. The issuer's ACS server may store the data from the cardholder client device software to permit the issuer to use that information to analyze the processing that occurred between the chip card and the cardholder client device software and to respond to inquiries from cardholders when errors and exception occurs. [0143] Optional Process at Issuer ACS [0144] If the authentication environment requests, the issuer ACS may need to send the result of the authentication to the merchant or requesting party. In some environments, the issuer ACS may send an indication that a cryptogram authentication has occurred and whether it was successful. Note: The VSDC Authentication Response is always sent even if the cardholder client device software terminates prematurely due to errors or other causes. [0145] The description will now cover the message flow and the functions involved in generating the flow between the VSDC application on the chip card and the cardholder client device software. First, an overview of processing flow of cardholder client device software functions to the chip card message flow is provided. The functions are those of initiation, application selection, application initiation, read application data, cardholder verification, termianl action analysis, and completion. [0146] Initiation describes how the cardholder client device software assures that the chip card is inserted into the card reader and is ready for the process. Application Selection describes how the cardholder client device software proceeds to select VSDC application on the chip card for VSDC Authentication processing. Application Initiation describes how the cardholder client device software initiates the VSDC application on the chip card. Read Application Data describes how the cardholder client device software reads the VSDC application data from the chip card. Cardholder Verification describes how the cardholder client device software performs cardholder verification. Terminal Action Analysis describes how the cardholder client device software requests the chip card to generate the Cryptogram. Completion describes how the cardholder client device software terminates the chip card processing and ends its processing. [0147] A detailed explanation of each flow and message will now be given. [0148] 4.3.2.1. Initiation [0149] The Initiation phase comprises two sub-phases. One is Initiation for the card environment on the cardholder client device and the other is Initiation for the chip card. [0150] The cardholder client device software preferably should assure to the extent possible in the environment that the card reader and any associated device support software necessary to enable it are ready for card insertion. If the card environment is not ready, the cardholder client device software preferably should communicate with Cardholder to verify that conditions at the cardholder client device are correctly set up. Communication with the cardholder might include asking such questions as whether the card reader is properly attached, whether the power is on, and whether the correct version of card reader driver software is installed. The cardholder client device software may terminate the VSDC Authentication processing if it determines that the card environment cannot be made ready. When the cardholder client device software terminates processing it preferably should skip all succeeding phases and return the VSDC Authentication Response message to the issuer Service with an appropriate status code. [0151] If the sub-phase “4.3.2.1.2 Initiation for the chip card” fails, control may return to this sub-phase whereupon the cardholder client device software prompts the cardholder to insert the chip card. The cardholder client device software may terminate VSDC Authentication processing if, after it requests card insertion and returns again to “Initiation for the chip card”, the chip card subsequently fails to respond. When the cardholder client device software terminates VSDC Authentication processing, it preferably should skip all the succeeding phases and preferably should send the VSDC Authentication Response message to the issuer ACS with an appropriate status code. [0152] Initiation for the Chip Card [0153] In this sub-processing phase the cardholder client device software communicates with the chip card to determine whether it is ready for processing. [0154] The cardholder client device software preferably should reset the chip card. The chip card returns an Answer To Reset (ATR) to the cardholder client device software, or the chip card fails to return an ATR. [0155] When the cardholder client device software receives ATR, it proceeds to the next phase, Application Selection. When the chip card does not return ATR within a time established by standards, the cardholder client device software may return to “4.3.2.1.1 Initiation for card environment on cardholder client device” or it may terminate VSDC Authentication processing. When the cardholder client device software terminates VSDC Authentication processing, it preferably should skip all the succeeding phases and preferably should send the VSDC Authentication Response message to the issuer server with an appropriate status code. [0156] 4.3.2.2. Application Selection [0157] Application Selection is the processing phase in which the cardholder client device software selects the VSDC application from the chip card. [0158] Process at the cardholder client device software includes the following: [0159] (a) The cardholder client device software preferably should perform Application Selection. [0160] (b) To comply with security requirements, cardholder client device software preferably should use only the Explicit Selection Method, sending the SELECT commands with the AID (Application ID) as supplied in the VSDC Authentication Request. [0161] (c) If the response to the first SELECT command returns an AID with no suffix, then there is only one instance of the application for the requested AID on the card. Processing continues with step g)below. [0162] (d) If the response to the first SELECT command returned an AID with a suffix indicating there are multiple instances of the application for the requested AID on the card then processing continues with step e) through step g) below, [0163] (e) By issuing successive SELECT commands using the AID (as supplied in the VSDC Authentication Request) until the card indicates there are no additional instances of applications for the requested AID to be returned. As each AID is returned the cardholder client device software constructs a list of AIDs along with the corresponding Application Label and Application Preferred Name for each AID. [0164] (f) Using the Application Label and the Application Preferred Name as supplied in the VSDC Authentication Request the cardholder client device software searches the list constructed in the prior step for a match. The SELECT command is issued to the card using the AID of the matched list entry. If no match is found, the appropriate status code is set for return in the VSDC Authentication Response as indicated in “Exception handling” below. [0165] (g) Application Selection for the cardholder client device software is complete. Either there was a singular eligible application on the card and it was selected in step c) above. Or, it has been determined among multiple eligible applications which one to select in step f) above. [0166] (h) When the cardholder client device software and the chip card support multiple applications in addition to VSDC, it is the issuer's responsibility to decide which and in what sequence other applications are to be executed. [0167] The chip card performs Application Selection. [0168] Exception Handling [0169] If the VSDC application is not found, the cardholder client device software preferably should terminate VSDC Authentication processing. When the cardholder client device software terminates VSDC Authentication processing, it preferably should skip all the succeeding phases and preferably should send VSDC Authentication Response to the issuer server with an appropriate status code. [0170] 4.3.2.3. Application Initiation [0171] Application Initiation is the processing phase during which the cardholder client device software signals to the chip card that transaction processing is beginning. [0172] The cardholder client device software preferably should initiate the application. The cardholder client device software preferably should send the GET PROCESSING OPTIONS command to chip card to initiate the VSDC application. [0173] The chip card responds to the GET PROCESSING OPTIONS command. [0174] The cardholder client device software preferably should store the Application Interchange Profile that will be used in later phases to construct the VSDC Authentication Response. Enforcing geographical restrictions is one of the optional functions of the VSDC application. [0175] When the chip card responds to the GET PROCESSING OPTIONS command with an error code that indicates the conditions of use are not satisfied, the VSDC Authentication processing must be terminated. [0176] If the card terminates the transaction then the cardholder client software device preferably should skip all the succeeding phases and preferably should send the VSDC Authentication Response message to the issuer server with an appropriate status code. Note: It is the issuer's responsibility to decide what action to take after termination of VSDC Authentication processing. Such decisions and consequent actions are outside the scope of this document. [0177] 4.3.2.4. Read Application Data [0178] Read Application Data is the processing phase in which the cardholder client device software reads the records of VSDC application files on the chip card. [0179] The cardholder client device software preferably should read the VSDC application data. The cardholder client device software preferably should sends READ RECORD commands to retrieve the necessary data from the VSDC application. The cardholder client device software preferably should retain the value of the PAN Sequence Number for later use in composing the VSDC Authentication Response. [0180] The VSDC application responds to the READ RECORD commands. [0181] 4.3.2.5. Cardholder Verification [0182] Cardholder Verification is the phase of processing in which the cardholder client device software may verify the cardholder by using an offline PIN verification method. Note: Cardholder Verification must be implemented in compliance with appropriate Visa security guidelines. [0183] Conditions of Execution [0184] This phase is conditional, i.e. required only when cardholder Verification is implemented and available on the card and in the cardholder client device software. [0185] The cardholder client device software preferably should verify the cardholder using the Offline Plaintext PIN Verification method. Neither the Offline Enciphered PIN Verification method or Online PIN verification is supported. [0186] The chip card performs Offline Plaintext PIN Verification. In response to the first GENERATE AC command, the chip card provides the result of the offline PIN verification in the CVR. [0187] 4.3.2.6. Terminal Action Analysis [0188] Terminal Action Analysis is the phase of processing in which the cardholder client device software requests the chip card to generate a Cryptogram, which will be sent to the issuer server for validation. [0189] The cardholder client device software preferably should perform Terminal Action Analysis. The cardholder client device software preferably should assume the role of the “merchant POS terminal” described therein and behave just like that terminal with the following exceptions: [0190] a) Issuer Action Code and Terminal Action Code Processing: The cardholder client device software preferably should not compare the Terminal Verification Results to the chip card's issuer Action Codes or to Terminal Action Codes. [0191] b) GENERATE AC Command: The cardholder client device software preferably should construct the GENERATE AC command by requesting only ARQC, i.e., must not request AAC or TC during Terminal Action Analysis. [0192] Terminal Verification Results (TVR) Values [0193] Terminal Verification Results is a record of the outcome of the various application functions performed by the cardholder client device. Different from the standard VSDC processing at POS terminal, some of the values are static for VSDC authentication. The values to be assigned to bits that are static are indicated below. Bits whose values are to be dynamically set, will be set by the cardholder client device during the course of the VSDC Authentication processing. [0194] The chip card produces a cryptogram. [0195] 4.3.2.7. Completion [0196] Completion is the processing phase in which the cardholder client device software terminates the processing of the chip card. [0197] Process Variation [0198] The cardholder client device software processing preferably should vary based upon the GENERATE AC response message. The cardholder client device software preferably should perform Completion. The VSDC application provides the chip card with the authority to decline transactions offline (AAC) even if the cardholder client device software issues the first GENERATE AC command for an online authorization (ARQC). Therefore the client cardholder device software should expect that the chip card will return either an ARQC or AAC during VSDC Authentication processing. To determine whether the outcome of the GENERATE AC is an ARQC or AAC the issuer ACS can check the CVR. [0199] VSDC Authentication preferably should continue processing even though the response from the chip card is Offline Decline (AAC). Processing can continue because even though the response indicates declined, the returned cryptogram can nonetheless be used for card authentication. VSDC Authentication requires the cryptogram for card authentication regardless of the type of the cryptogram. [0200] 4.3.2.7.1. Card Response Is ARQC [0201] This sub-section describes the processing flow when the chip card returns an Authorization ReQuest Cryptogram (ARQC). For VSDC Authentication, such an interpretation is not relevant because an authorization will not be requested and VSDC Authentication is always an “online” process. The objective of issuing the GENERATE AC command is to cause the card to return a cryptogram for validation. [0202] After receiving the first GENERATE AC response with ARQC from the chip card, the cardholder client device software preferably should perform the following: [0203] The cardholder client device software preferably should keep only the cryptogram and no other data except for the following data elements sent from the chip card in order to send them to the issuer server; see Table 2. TABLE 2 Data Element Source Cryptogram From the first GENERATE AC response message. Derivation Key Index From the first GENERATE AC response (DKI) message. (DKI is a component of issuer Application Data.) Cryptogram Version From the first GENERATE AC response Number message. Cryptogram Version Number is a component of issuer Application Data. Application Transaction From the first GENERATE AC response Counter (ATC) message. Card Verification Results From the first GENERATE AC response (CVR) message. (CVR is a component of issuer Application Data.) [0204] The cardholder client device software preferably should store information necessary for subsequent phases to prepare and send the VSDC Authentication Response. Then, the cardholder client device software preferably should issue the final GENERATE AC command to the chip card as if the online authorization response would indicate transaction unapproved by the issuer. It means that the cardholder client device software requests an AAC. Note: [0205] There are no authorization request/response messages in VSDC Authentication processing. [0206] Source of Data Listed in CDOL2 [0207] The Data Elements, which the cardholder client device software transmits to the chip card in the data field of the final GENERATE AC command, preferably should be obtained from the sources indicated in the table 3 below. TABLE 3 Data Element Source Amount, Authorized From Network-based VSDC Authentication Request message Amount, Other From Network-based VSDC Authentication Request message Terminal Country Code From Network-based VSDC Authentication Request message Terminal Verification From the cardholder client device software Results (TVR) Transaction Currency From Network-based VSDC Code Authentication Request message Transaction Date From Network-based VSDC Authentication Request message Transaction Type From Network-based VSDC Authentication Request message Unpredictable Number From Network-based VSDC Authentication Request message [0208] The chip card returns the response to the final GENERATE AC command with AAC. [0209] The cardholder client device software preferably should ignore a response from the chip card to the final GENERATE AC command. The cardholder client device software preferably should comply with security requirements by clearing from its memory extraneous data received from the chip card. Note: It is assumed that by this time all prior unused data from previous phases have been cleared in compliance with security requirements. [0210] Card Response Is AAC [0211] This sub-section describes the processing flow when the chip card returns an Application Authentication Cryptogram (AAC). For VSDC Authentication, such an interpretation is not relevant because an authorization was not requested. The objective of issuing the GENERATE AC command is to cause the card to return a cryptogram for authentication of the chip card. [0212] After receiving the AAC in the response to the first GENERATE AC command from the chip card, the cardholder client device software preferably should perform the following functions. The cardholder client device software preferably should keep the cryptogram and the other information sent from the chip card in order to send them to the issuer ACS. The cardholder client device software preferably should prepare to send VSDC Authentication Response. The cardholder client device software preferably should clear all the data received from the chip card in all phases. Chip Card Embodiment with Access Application [0213] Now that the description of the message flows in FIG. 12A has been completed, embodiment of the chip card device utilizing an Access application will now be presented. [0214] The additional embodiment of the chip card system involves an Access application that can optionally be used as an extra feature of the chip card system. The Access application is used to control access to the chip card and the multiple applications that may reside on the chip card. The Access application can be referred to as the “Access application or applet.” The Access application controls access to the other applications resident upon the chip card. In this manner, the Access application is able to verify the identity of the person attempting to utilize the chip card and its associated applications. If the person attempting to use the chip card enters the correct user identification number or string, and a password, then it is presumed that an authorized person is about to use the chip card. In this case, the Access application unlocks all of the applications on the chip card so that they may be used. In addition to unlocking the applications, the Access application can make the passwords for the applications on the chip card available for use. In some embodiments of the Access application, only a select number of the applications will be unlocked after entering the correct information in response to the Access application. [0215] There are numerous references to the passwords or secret values that the cardholder enters and/or the issuer ACS checks. As shown in Table 4, secrets #1, #2, and #3 are different values (and none of the three is a financial ATM or POS PIN). TABLE 4 Passwords and Secret Values Secret #1 A cardholder-defined password to enable access to the chip card Access application for chip-based payer authentication. In some embodiments, secret #1 allows an access program on a smart card to open all the applications on a smart card, including the PAS application. Secret #2 An issuer-defined password returned by the chip card Access application to enable the ACS to validate the cardholder for chip-based payer authentication. The cardholder is not required to know this password since it is automatically used to open applications on the smart card. Secret #3: The password used in the non-chip card embodiment of PAS (the core system). The cardholder-defined password to enable the ACS to validate the cardholder. This password or secret can also be used to validate the cardholder when chip card access is not available on the card. [0216] [0216]FIG. 13 illustrates a system diagram of the components utilized in the payer authentication service using the chip card and a universal Access application. The system diagram of FIG. 13 shows the chip card 1540, the chip card reader 1518, the cardholder client device 122, the access control server 114, and a database 1240. The chip card 1540 includes the access applet 1202 and the chip card credit and debit application 1204. The access applet 1202 stores a password, which is secret #2, that will be used to unlock the various applications on the chip card. The cardholder client device includes the payer authentication application 1542. [0217] Upon making an online purchase transaction, the access applet 1202 prompts the cardholder to enter his or her user ID and password, which is secret #1. If the cardholder enters the correct user ID and the associated password, then secret #2 is automatically used to unlock the applications on the chip card. Then the PAS system utilizing the chip card system can proceed as was described earlier in this specification. [0218] This second, more detailed description explains the processes and commands that should be supported by the cardholder client device software, which facilitates communication between the chip card reader, the cardholder's Internet browser and the ACS. [0219] The various basic processes and commands will now be described. First, the cardholder client device software will be activated by a message from the ACS server (client can also be implemented with a timeout feature, e.g. a client will be timed out after 30 minutes). Then, the cardholder client device software will check for the existence of a compliant chip reader and respond to the ACS that it is capable of processing a chip based payer authentication transaction. The cardholder client device software will receive a message from the ACS containing the appropriate merchant and ACS data to enable a chip card program (e.g., VSDC application) to generate a cryptogram. An example of such a chip card program is the Visa Smart Debit Credit application (VSDC), which is Visa's implementation of the Europay, Mastercard, and Visa (EMV) chip card standard. The cryptogram is a cryptographic value generated by the card that is specific to the card and to each transaction. The ACS can validate that the cryptogram using cryptographic keys in hardware security module. It is noted that the VSDC application is the same application used in the face-to-face transaction taking place at brick-and-mortar POS merchant. [0220] After receiving the message from the ACS, the cardholder client device software will check for the presence of secret #2 and UID in the defined data element. If it is not available, the cardholder client device software will ask the cardholder to insert the chip card and enter secret #1 to validate against the chip card Access application and retrieve secret #2 and User ID (UID). [0221] If the cardholder is validated for chip-based payer authentication, the cardholder client device software will execute a VSDC purchase transaction to obtain the cryptogram and associated data to perform Online chip card Authentication. [0222] Execution of the VSDC purchase transaction involves multiple steps to be taken by each of the cardholder client device software and the VSDC chip application. The cardholder client device software will perform Application Selection using the Explicit Selection Method by issuing one or more SELECT commands to the card. The cardholder client device software will also issue a GET PROCESSING OPTIONS command that includes the PDOL, if a PDOL was present in the File Control Information (FCI) from Application Selection. Then the VSDC chip application will return the Application File Locator (AFL) and Application Interchange Profile (AIP) in the response from the GET PROCESSING OPTIONS command. [0223] The cardholder client device software will issue the READ RECORD commands necessary to read the VSDC chip application records designated by the AFL. Note: The chip will return all of the data necessary to complete a VSDC purchase transaction, as well as the data used for internet payment authentication. The cardholder client device software will need to parse out the correct data. The cardholder client device software will then perform the Processing Restrictions checks, bypass CVM List Processing, and bypass Terminal Risk Management except for the Floor Limit and New card checks. All transactions will be over the floor limit. The cardholder client device software will set the TVR Transaction Exceeds Floor Limit bit to ‘1’. The cardholder client device software will perform Terminal Action Analysis and always request an ARQC (online) cryptogram in the GENERATE AC command. This command will include the CDOL1 data including Transaction Date and the Unpredictable Number from the ACS. Then the cardholder client device software will pass the cryptogram returned by the chip and supporting data unaltered to the ACS for validation. Finally, the cardholder client device software will issue a GENERATE AC command requesting an AAC. This will terminate the transaction on the VSDC card application. After issuing the second GENERATE AC command, all information from the transaction should be forgotten by the cardholder client device software The following process occurs after the Merchant Plug In forwards the PAReq message to the ACS. First, the ACS should determine if the cardholder's PC is chip-enabled. (Note: Though the PAN may be registered as being chip-enabled, this step is necessary in those situations where the PC currently being used in the transaction does not have a chip reader or is otherwise not chip-enabled.) The ACS should allow the issuer to configure two different actions for the situation when the PC is not chip enabled or the chip is not readable. [0224] Option #1, prompt the cardholder for secret #3 (his or her PAS password). Option #2, do not perform any cardholder nor chip card authentication and populate the PARes Transaction Status field with a “not applicable” response. The ACS should extract all of the appropriate merchant information from the PAReq and provide this data and the appropriate ACS information to the cardholder client device software that will be required to request the chip card to generate a cryptogram. [0225] The ACS then sends the information to support the cryptogram to the cardholder's cardholder client device software and sends a request for secret #2 and the Unique Identifier (UID). The cardholder client device software invokes an application that obtains secret #2 (password) and UID from the previously performed chip-enabled check-out process. If secret #2 is not available via this procedure, the cardholder client device software obtains secret #2 from the chip card by invoking the Access applet, which requires the cardholder to enter secret #1 to activate the applet, and obtains secret #2 and UID from within the Access applet on the chip card. If the Access applet is not present on the chip card, The cardholder client device software asks the cardholder to enter secret #3 (his or her PAS password). [0226] After secret #2 and UID are obtained, the cardholder client device software initiates a VSDC transaction to generate a cryptogram request and obtain the cryptogram from the chip card. If secret #2 is not obtained (i.e. the cardholder is not validated), the cardholder client device software does not call upon the VSDC applet. [0227] The cardholder client device software returns secret #2, the cryptogram, and the supporting data to the ACS for the ACS to validate the cryptogram to the ACS. The ACS accepts the cardholder client device software's input and validates it against the Account Holder Database. If there is more than one Account Holder Database entry (secret #2) for a Primary Account Number (PAN), the cardholder is validated if any of the entries (secret #2) match the secret #2 sent to the ACS by the cardholder client device software. [0228] The ACS validates the card by replicating the cryptogram and comparing it to the cryptogram from the chip card sent to the ACS by the cardholder client device software. The ACS creates the PARes message, populating all of the, and returns the PARes message to the merchant via the connection through the cardholder's browser. [0229] The ACS digitally signs the PARes, sets the PARes Transaction Status, Transaction Detail, ECI, values, chip card codes indicating the type of card, payment conditions, and card authentication results, and sends the signed PARes back to the merchant, and generates a SaveReceipt message to the receipt manager 131 (the SaveReceipt message may also be referred to as the PATrans message). [0230] Two types of chip cards carry the Visa Smart Debit/Credit (VSDC) application. First is a card that is capable of validating the cardholder (payer) offline via the Access application on the card using the access password or secret #1. The access password is obtained from the cardholder and passed to the cardholder client device software on the browser. If the access password provided is correct, the chip card Access application returns secret #2 and UID to the cardholder client device software. Secondly, a card that is not capable of validating the cardholder (payer) offline (i.e., a card that only contains the VSDC application). In this case the cardholder client device software on the browser prompts the cardholder for secret #3 (his or her password) and it is provided to the ACS to achieve cardholder authentication. [0231] The flow related to the cardholder client device software after it is given control from the ACS (after the ACS has received the PAReq message from the merchant plug-in) will now be presented. The cardholder client device software should first determine if the cardholder's PC is chip card enabled (chip card reader and client software components present). If it is not, the transaction is processed via core payer authentication. If the PC is chip card enabled, then in step 2, obtain the secret #2 via the Access application on the chip card or obtain the secret #3 via a prompt to the cardholder. [0232] If secret #2 and UID or secret #3 is provided, Call the VSDC application on the chip to: retrieve the Magnetic Stripe Image (MSI) data element, retrieve the chip data necessary to allow the ACS to regenerate the cryptogram, and generate the ARQC cryptogram. If secret #2 or #3 is not provided, the VSDC applet is not called. [0233] Send the following data to the ACS for card authentication: the ARQC cryptogram, magnetic stripe image (MSI), and the data to support the cryptogram regeneration by the ACS. Optionally, the MSI data can be read. [0234] Then send secret #2 and UID or secret #3 to the ACS for cardholder authentication. [0235] Generally, it is noted that chip cardholders will be allowed to conduct purchase transactions on the Internet without the card being present via core payer authentication (PAS without the chip card and chip card reader components). Also, the cardholder client device software distributed by the issuer should support all types of VSDC cards. Authentication should accommodate chip-based payment applications that implement the full and limited versions of Visa Smart Debit or Credit applets. Initially the chip-based payment application deployed will support limited VSDC features on an Open Platform card. This limited VSDC payment applet, “jump start”, supports the following subset of the “full” VSDC features: MSI, Online Card Authentication, and offline Static Data Authentication (SDA). However, SDA is not performed during Internet transactions. All information from the transaction should be forgotten by the payer authentication cardholder client device software at the end of the transaction.(Such as at the time the PARes message is sent to the merchant). [0236] The ACS is configurable by the issuer to allow different actions to be taken when the cardholder client device software is not available or is not able to read the chip card. Option #1, the ACS will prompt the cardholder to manually enter secret #3 or option #2, no authentication is conducted and a “not applicable” response is returned to the merchant. [0237] Chip cardholders will be allowed to conduct purchase transactions on the Internet without the card being present (for example, from a different PC without the cardholder client device software and chip card reader). The cardholder would manually complete the merchant check out form (or use other non-chip method) and will be prompted by the ACS to manually enter secret #3 if the issuer chose this approach. Preferred Payment Network [0238] [0238]FIG. 14 illustrates a telecommunications network 800 suitable for implementing an embodiment of the present invention. The present invention may make use of any suitable telecommunications network and may involve different hardware, different software and/or different protocols then those discussed below. The below-described network is a preferred embodiment of the telecommunications network 126 of FIG. 1. Network 800 is a global telecommunications network that supports purchase and cash transactions using any bankcard, travel and entertainment cards, and other private label and proprietary cards. The network also supports ATM transactions for other networks, transactions using paper checks, transactions using smart cards and transactions using other financial instruments. [0239] These transactions are processed through the network's authorization, clearing and settlement services. Authorization is when an issuer approves or declines a sales transaction before a purchase is finalized or cash is dispersed. Clearing is when a transaction is delivered from an acquirer to an issuer for posting to the customer's account. Settlement is the process of calculating and determining the net financial position of each member for all transactions that are cleared. The actual exchange of funds is a separate process. [0240] Transactions can be authorized, cleared and settled as either a dual message or a single message transaction. A dual message transaction is sent twice-the first time with only information needed for an authorization decision, an again later with additional information for clearing and settlement. A single message transaction is sent once for authorization and contains clearing and settlement information as well. Typically, authorization, clearing and settlement all occur on-line. [0241] The main components of telecommunications network 800 are interchange centers 802, access points 804, 806 and processing centers 808 and 810. Other entities such as drawee banks and third party authorizing agents may also connect to the network through an access point. An interchange center is a data processing center that may be located anywhere in the world. In one embodiment, there are two in the United States and one each in the United Kingdom and in Japan. Each interchange center houses the computer system that performs the network transaction processing. The interchange center serves as the control point for the telecommunication facilities of the network, which comprise high speed leased lines or satellite connections based on IBM SNA protocol. Preferable, lines 820 and 822 that connect an interchange center to remote entities use dedicated high-bandwidth telephone circuits or satellite connections based on the IBM SNA-LU0 communication protocol. Messages are sent over these lines using any suitable implementation of the ISO 8583 standard. [0242] An access point 804 or 806 is typically a small computer system located at a processing center that interfaces between the center's host computer and the interchange center. The access point facilitates the transmission of messages and files between the host and the interchange center supporting the authorization, clearing and settlement of transaction. Links 826 and 828 are typically local links within a center and use a proprietary message format as prefer by the center. [0243] A data processing center (such as is located within an acquirer, issuer, or other entity) houses processing systems that support merchant and business locations and maintains customer data and billing systems. Preferably, each processing center is linked to one or two interchange centers. Processors are connected to the closest interchange, and if the network experiences interruptions, the network automatically routes transactions to a secondary interchange center. Each interchange center is also linked to all of the other interchange centers. This linking enables processing centers to communicate with each other through one or more interchange centers. Also, processing centers can access the networks of other programs through the interchange center. Further, the network ensures that all links have multiple backups. The connection from one point of the network to another is not usually a fixed link; instead, the interchange center chooses the best possible path at the time of any given transmission. Rerouting around any faulty link occurs automatically. [0244] [0244]FIG. 15 illustrates systems 840 housed within an interchange center to provide on-line and off-line transaction processing. For dual message transaction, authorization system 842 provides authorization. System 842 supports on-line and off-line functions, and its file includes internal systems tables, a customer database and a merchant central file. The on-line functions of system 842 support dual message authorization processing. This processing involves routing, cardholder and card verification and stand-in processing, and other functions such as file maintenance. Off-line functions including reporting, billing, and generating recovery bulletins. Reporting includes authorization reports, exception file and advice file reports, POS reports and billing reports. A bridge from system 842 to system 846 makes it possible for members using system 842 to communicate with members using system 846 and access the SMS gateways to outside networks. [0245] Clearing and settlement system 844 clears and settles previously authorized dual message transactions. Operating six days a week on a global basis, system 844 collects financial and non-financial information and distributes reports between members. It also calculates fees, charges and settlement totals and produces reports to help with reconciliation. A bridge forms an interchange between system 844 processing centers and system 846 processing centers. [0246] Single message system 846 processes full financial transactions. System 846 can also process dual message authorization and clearing transactions, and communicates with system 842 using a bridge and accesses outside networks as required. System 846 processes Visa, Plus Interlink and other card transactions. The SMS files comprise internal system tables that control system access and processing, and the cardholder database, which contains files of cardholder data used for PIN verification and stand-in processing authorization. System 846 on-line functions perform real-time cardholder transaction processing and exception processing for authorization as well as full financial transactions. System 846 also accumulates reconciliation and settlement totals. System 846 off-line functions process settlement and funds transfer requests and provide settlement and activities reporting. Settlement service 848 consolidates the settlement functions of system 844 and 846, including Interlink, into a single service for all products and services. Clearing continues to be performed separately by system 844 and system 846. [0247] [0247]FIG. 16 illustrates another view of the components of telecommunications network 800. Integrated payment system 850 is the primary system for processing all on-line authorization and financial request transactions. System 850 reports both dual message and single message processing. In both cases, settlement occurs separately. The three main software components are the common interface function 852, authorization system 842 and single message system 846. [0248] Common interface function 852 determines the processing required for each message received at an interchange center. It chooses the appropriate routing, based on the source of the message (system 842, 844 or 846), the type of processing request and the processing network. This component performs initial message editing, and, when necessary, parses the message and ensures that the content complies with basic message construction rules. Function 852 routes messages to their system 842 or system 846 destinations. Computer System Embodiment [0249] [0249]FIGS. 17A and 17B illustrate a computer system 900 suitable for implementing embodiments of the present invention. FIG. 17A shows one possible physical form of the computer system. Of course, the computer system may have many physical forms ranging from an integrated circuit, a printed circuit board and a small handheld device up to a huge super computer. Computer system 900 includes a monitor 902, a display 904, a housing 906, a disk drive 908, a keyboard 910 and a mouse 912. Disk 914 is a computer-readable medium used to transfer data to and from computer system 900. [0250] [0250]FIG. 17B is an example of a block diagram for computer system 900. Attached to system bus 920 are a wide variety of subsystems. Processor(s) 922 (also referred to as central processing units, or CPUs) are coupled to storage devices including memory 924. Memory 924 includes random access memory (RAM) and read-only memory (ROM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to the CPU and RAM is used typically to transfer data and instructions in a bi-directional manner. Both of these types of memories may include any suitable of the computer-readable media described below. A fixed disk 926 is also coupled bi-directionally to CPU 922; it provides additional data storage capacity and may also include any of the computer-readable media described below. Fixed disk 926 may be used to store programs, data and the like and is typically a secondary storage medium (such as a hard disk) that is slower than primary storage. It will be appreciated that the information retained within fixed disk 926, may, in appropriate cases, be incorporated in standard fashion as virtual memory in memory 924. Removable disk 914 may take the form of any of the computer-readable media described below. [0251] CPU 922 is also coupled to a variety of input/output devices such as display 904, keyboard 910, mouse 912 and speakers 930. In general, an input/output device may be any of: video displays, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, biometrics readers, or other computers. CPU 922 optionally may be coupled to another computer or telecommunications network using network interface 940. With such a network interface, it is contemplated that the CPU might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Furthermore, method embodiments of the present invention may execute solely upon CPU 922 or may execute over a network such as the Internet in conjunction with a remote CPU that shares a portion of the processing. [0252] In addition, embodiments of the present invention further relate to computer storage products with a computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher level code that are executed by a computer using an interpreter. Implementation of PAS in Non-Purchase Transactions [0253] As described above, PAS is designed to authenticate cardholder account ownership during online purchase transactions. However, as also mentioned above, PAS can be used in more generic applications that do not necessarily involve purchase transactions. In general, PAS can be used in various transactions when a trusted party authenticates the identity of an individual or entity for the benefit of a third party. As is commonly known, the trusted party usually accepts legal responsibility for the authentication of the individual or entity to the third party. For example, PAS can be used to authenticate a financial institution's customers when accessing an Internet web site to complete an online form. PAS can also be used in aspects of retail banking such as debit cards, purchase cards, stored value cards, as well as wholesale banking, the medical business, the insurance business, the brokerage business, etc. ID cards can also be used with PAS. For example, AAA may use PAS to authenticate the identity of its customer, or a telephone card company can use PAS to authenticate the identity of the user of a specific card. [0254] [0254]FIG. 18 illustrates a simplified system architecture 1500 for implementing the Payer Authentication Service in a non-purchase application according to one embodiment of the invention. Specifically, FIG. 18 is a simplified version of the system architecture 100 shown in FIG. 1. Components such as an issuer authorization and settlement system are not required since settlement is not required in non-purchase transactions. The simplified architecture 1500 still includes the three domains of: the trusted party domain 1502, the interoperability domain 1504, and the third party or requesting party domain 1506. Trusted party domain 1502 is analogous to issuer domain 102 of FIG. 1 in that the party designated to perform the account authentication procedures manages access control server 1514. Also within trusted party domain 1502 is the issuer cardholder system 1510, the enrollment server 1512, and the account holder file 1518. Third party or requesting party domain 1506 is analogous to acquirer domain 106 of FIG. 1 in that a party 1532 that requires the authentication of an account holder manages software 1534 that facilitates the authentication protocol of the present invention. Interoperability domain 1504 contains the directory 1528 and is supported by the Internet and includes components used by both the trusted party and the third party. [0255] For most transactions the Payment Authentication Request and Response messages include fields that include but are not limited to Message Version Number, Merchant Identifier, Merchant Country Code, Order Number, Purchase Date, Purchase Amount, Transaction Status, and Purchase Terms and Conditions. Also, the QueryCardholderRes Message typically includes fields such as but not limited to Message Version Number, Merchant Name, Order Number, Purchase Date, Purchase Amount, Card Expiration Date, and Transaction Stain. These messages can be in XML (Extensible Markup Language) format. [0256] In non-purchase authentication transactions, the Payment Authentication Request, Payment Authentication Response, and QueryCardholderRes messages can include message extension fields. As is well known in the art, message extension fields are data fields that define additional elements with respect to the message to which the extension is attached. These additional elements can be used to further facilitate specific transactions, including non-payment transactions. [0257] While this invention has been described in terms of several preferred embodiments, there are alteration, permutations, and equivalents, which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS2002 *Mar 12, 1841 Tor and planter for plowingUS2004 *Mar 12, 1841 Improvement in the manner of constructing and propelling steam-vesselsUS5163098 *Sep 6, 1990Nov 10, 1992Dahbura Abbud SSystem for preventing fraudulent use of credit cardUS5420926 *Jan 5, 1994May 30, 1995At&T Corp.Anonymous credit card transactionsUS5430827 *Apr 23, 1993Jul 4, 1995At&T Corp.Password verification systemUS5442342 *May 27, 1993Aug 15, 1995Hughes Aircraft CompanyDistributed user authentication protocolUS5473689 *May 25, 1994Dec 5, 1995Siemens AktiengesellschaftMethod for authentication between two electronic devicesUS5485510 *Sep 1, 1994Jan 16, 1996At&T Corp.Secure credit/debit card authorizationUS5544322 *May 9, 1994Aug 6, 1996International Business Machines CorporationSystem and method for policy-based inter-realm authentication within a distributed processing systemUS5590197 *Apr 4, 1995Dec 31, 1996V-One CorporationElectronic payment system and methodUS5671279 *Nov 13, 1995Sep 23, 1997Netscape Communications CorporationElectronic commerce using a secure courier systemUS5684950 *Sep 23, 1996Nov 4, 1997Lockheed Martin CorporationMethod and system for authenticating users to multiple computer servers via a single sign-onUS5712913 *Feb 8, 1994Jan 27, 1998Digicash IncorporatedLimited-traceability systemsUS5778065 *Feb 8, 1996Jul 7, 1998International Business Machines CorporationMethod and system for changing an authorization password or key in a distributed communication networkUS5793028 *Jun 24, 1996Aug 11, 1998Fred N. GratzonElectronic transaction security systemUS5815665 *Apr 3, 1996Sep 29, 1998Microsoft CorporationSystem and method for providing trusted brokering services over a distributed networkUS5826241 *Sep 16, 1994Oct 20, 1998First Virtual Holdings IncorporatedComputerized system for making payments and authenticating transactions over the internetUS5826245 *Mar 20, 1995Oct 20, 1998Sandberg-Diment; ErikProviding verification information for a transactionUS5835896 *Mar 29, 1996Nov 10, 1998Onsale, Inc.Method and system for processing and transmitting electronic auction informationUS5845070 *Dec 18, 1996Dec 1, 1998Auric Web Systems, Inc.Security system for internet provider transactionUS5845265 *Nov 7, 1995Dec 1, 1998Mercexchange, L.L.C.Consignment nodesUS5883810 *Sep 24, 1997Mar 16, 1999Microsoft CorporationElectronic online commerce card with transactionproxy number for online transactionsUS5884272 *Sep 6, 1996Mar 16, 1999Walker Asset Management Limited PartnershipMethod and system for establishing and maintaining user-controlled anonymous communicationsUS5903721 *Mar 13, 1997May 11, 1999cha|Technologies Services, Inc.Method and system for secure online transaction processingUS5903878 *Aug 20, 1997May 11, 1999Talati; Kirit K.Method and apparatus for electronic commerceUS5909492 *Jun 18, 1997Jun 1, 1999Open Market, IncorporatedNetwork sales systemUS5930777 *May 23, 1997Jul 27, 1999Barber; Timothy P.Method of charging for pay-per-access information over a networkUS5970475 *Oct 10, 1997Oct 19, 1999Intelisys Electronic Commerce, LlcElectronic procurement system and method for trading partnersUS5991738 *Nov 12, 1997Nov 23, 1999Ogram; Mark E.Automated credit card processingUS5999596 *Mar 6, 1998Dec 7, 1999Walker Asset Management LimitedMethod and system for controlling authorization of credit card transactionsUS6016476 *Jan 16, 1998Jan 18, 2000International Business Machines CorporationPortable information and transaction processing system and method utilizing biometric authorization and digital certificate securityUS6029141 *Jun 27, 1997Feb 22, 2000Amazon.Com, Inc.Internet-based customer referral systemUS6047268 *Nov 4, 1997Apr 4, 2000A.T.&T. CorporationMethod and apparatus for billing for transactions conducted over the internetUS6052675 *Apr 21, 1998Apr 18, 2000At&T Corp.Method and apparatus for preauthorizing credit card type transactionsUS6070241 *Sep 10, 1998May 30, 2000Anitek Verification, Inc.Third party verification system and methodUS6076078 *Feb 14, 1997Jun 13, 2000Carnegie Mellon UniversityAnonymous certified deliveryUS6078902 *Apr 14, 1998Jun 20, 2000Nush-Marketing Management & ConsultanceSystem for transaction over communication networkUS6098053 *Jan 26, 1999Aug 1, 2000Citibank, N.A.System and method for performing an electronic financial transactionUS6122624 *May 28, 1998Sep 19, 2000Automated Transaction Corp.System and method for enhanced fraud detection in automated electronic purchasesUS6167378 *Jan 21, 1997Dec 26, 2000Webber, Jr.; Donald GaryAutomated back office transaction method and systemUS6202051 *Feb 19, 1999Mar 13, 2001Merc Exchange LlcFacilitating internet commerce through internetworked auctionsUS6205437 *Mar 2, 1998Mar 20, 2001Open Market, Inc.Open network payment system for providing for real-time authorization of payment and purchase transactionsUS6236981 *Nov 17, 1997May 22, 2001British Telecommunications Public Limited CompanyTransaction systemUS6237578 *Oct 29, 1999May 29, 2001Hitachi, Ltd.Ignition coil for use in internal combustion engineUS6243691 *Mar 29, 1996Jun 5, 2001Onsale, Inc.Method and system for processing and transmitting electronic auction informationUS6260024 *Dec 2, 1998Jul 10, 2001Gary ShkedyMethod and apparatus for facilitating buyer-driven purchase orders on a commercial network systemUS6327578 *Dec 29, 1998Dec 4, 2001International Business Machines CorporationFour-party credit/debit payment protocolUS6343284 *Dec 7, 1998Jan 29, 2002Nippon Telegraph And Telephone CorporationMethod and system for billing on the internetUS6381316 *May 9, 2001Apr 30, 2002Unpaid Systems, Ltd.Enhanced communication platform and related communication method using the platformUS6427132 *Aug 31, 1999Jul 30, 2002Accenture LlpSystem, method and article of manufacture for demonstrating E-commerce capabilities via a simulation on a networkUS6629081 *Dec 22, 1999Sep 30, 2003Accenture LlpAccount settlement and financing in an e-commerce environmentUS6704714 *Feb 3, 2000Mar 9, 2004The Chase Manhattan BankVirtual private lock boxUS6735572 *Mar 13, 2002May 11, 2004Mark LandesmannBuyer-driven targeting of purchasing entitiesUS6820202 *Nov 9, 1998Nov 16, 2004First Data CorporationAccount authority digital signature (AADS) systemUS6839692 *Dec 1, 2000Jan 4, 2005Benedor CorporationMethod and apparatus to provide secure purchase transactions over a computer networkUS6879965 *Jun 14, 2001Apr 12, 2005Passgate CorporationMethod, system and computer readable medium for web site account and e-commerce management from a central locationUS6889325 *Apr 28, 2000May 3, 2005Unicate BvTransaction method and system for data networks, like internetUS6931382 *Feb 23, 2001Aug 16, 2005Cdck CorporationPayment instrument authorization techniqueUS6938019 *Aug 29, 2000Aug 30, 2005Uzo Chijioke ChukwuemekaMethod and apparatus for making secure electronic paymentsUS6941285 *Oct 11, 2002Sep 6, 2005Branko SarcaninMethod and system for a virtual safeUS7177838 *Apr 21, 2000Feb 13, 2007Paybyclick CorporationMethod and apparatus for conducting electronic commerce transactions using electronic tokensUS7343351 *Aug 31, 2000Mar 11, 2008American Express Travel Related Services Company, Inc.Methods and apparatus for conducting electronic transactionsUS7370011 *Jun 28, 2001May 6, 2008Yahoo! Inc.Financial information portalUS20010014158 *Mar 28, 2001Aug 16, 2001Hush Communications CorporationPublic key cryptosystem with roaming user capabilityUS20010029496 *Feb 23, 2001Oct 11, 2001Otto Ray KarlSystems and methods for providing anonymous financial transactionsUS20010039535 *Feb 9, 2001Nov 8, 2001Tsiounis Yiannis S.Methods and systems for making secure electronic paymentsUS20010039536 *Feb 28, 2001Nov 8, 2001Masahide MoriCost data management system, method of managing cost data, and recording mediumUS20010044787 *Dec 14, 2000Nov 22, 2001Gil ShwartzSecure private agent for electronic transactionsUS20010051902 *Jun 8, 2001Dec 13, 2001Messner Marc A.Method for performing secure internet transactionsUS20010054003 *Apr 13, 2001Dec 20, 2001Emily ChienSystem and method for using loyalty pointsUS20020000735 *Apr 12, 2001Jan 3, 2002Crown North AmericaVehicle courier door system and method of conversionUS20020019811 *May 30, 2001Feb 14, 2002Veristar CorporationBiometric financial transaction system and methodUS20020069174 *Feb 27, 1998Jun 6, 2002Microsoft CorporationGump: grand unified meta-protocol for simple standards-based electronic commerce transactionsUS20020091646 *Oct 22, 2001Jul 11, 2002Lake Lawrence L.Method and system for verifying the identity of on-line credit card purchasers through a proxy transactionUS20020111919 *Apr 24, 2001Aug 15, 2002Visa International Service AssociationOnline payer authentication serviceUS20020129877 *Mar 14, 2002Sep 19, 2002Ugine SaNiobium-stabilized 14% chromium ferritic steel, and use of same in the automobile sectorUS20020169720 *May 12, 2001Nov 14, 2002Wilson Phillip C.Method for cardholder to place use restrictions on credit card at willUS20030097451 *Nov 16, 2001May 22, 2003Nokia, Inc.Personal data repositoryUS20030120615 *Feb 4, 2000Jun 26, 2003B. Todd PattersonProcess and method for secure online transactions with calculated risk and against fraudUS20030144952 *Jan 31, 2002Jul 31, 2003International Business Machines CorporationDetection of unauthorized account transactionsUS20030200184 *Feb 19, 2003Oct 23, 2003Visa International Service AssociationMobile account authentication serviceUS20030208684 *Mar 7, 2001Nov 6, 2003Camacho Luz MariaMethod and apparatus for reducing on-line fraud using personal digital identificationUS20030212642 *Mar 11, 2003Nov 13, 2003Visa International Service AssociationOnline payer authentication serviceUS20040044627 *Nov 29, 2000Mar 4, 2004Russell David C.Methods, systems and apparatuses for secure transactionsUS20040059688 *Sep 10, 2003Mar 25, 2004Visa International Service AssociationData authentication and provisioning method and systemUS20040078328 *Feb 7, 2002Apr 22, 2004Talbert Vincent W.Method and system for completing a transaction between a customer and a merchantUS20040177047 *Mar 26, 2001Sep 9, 2004Graves Michael E.Authenticated paymentUS20040230536 *Feb 26, 2004Nov 18, 2004Passgate CorporationMethod, system and computer readable medium for web site account and e-commerce management from a central locationUS20040243520 *Apr 9, 2004Dec 2, 2004Bishop Fred AlanMethods and apparatus for conducting electronic transactionsUS20050065855 *Sep 23, 2003Mar 24, 2005Extreming, Inc.Virtual server consumer authorization, verification and credit update method and articleUS20050131826 *Nov 23, 2004Jun 16, 2005Zix CorporationCentralized authorization and fraud-prevention system for network-based transactionsUS20050192896 *Sep 24, 2003Sep 1, 2005Echarge CorporationMethod and apparatus for ordering goods, services and content over an internetwork using a virtual payment accountUS20050246278 *May 3, 2004Nov 3, 2005Visa International Service Association, A Delaware CorporationMultiple party benefit from an online authentication serviceUS20060143119 *Oct 7, 2005Jun 29, 2006Scott KruegerSecure networked transaction systemUS20080016003 *Jul 10, 2007Jan 17, 2008Echarge CorporationMethod and apparatus for ordering goods, services, and content over an internetwork using a virtual payment accountUS20080301056 *Feb 20, 2008Dec 4, 2008Weller Kevin DOnline payer authentication serviceUS20100029496 *Jul 31, 2008Feb 4, 2010Cary R BruceMultiplexed lateral flow microarray assay for detection of citrus pathogens Xylella fastidiosa and Xanthomonas axonopodis PV citriUS20100057619 *Apr 6, 2009Mar 4, 2010Visa International Service AssociationAccount authentication service with chip cardUS20100063895 *Nov 12, 2009Mar 11, 2010Visa International Service AssociationMobile account authentication service* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS6970851 *Sep 28, 2001Nov 29, 2005Ncr CorporationSystem and method of configuring value cardsUS7007840 *Jul 2, 2004Mar 7, 2006Visa U.S.A., Inc.Managing activation of cardholders in a secure authentication programUS7342918 *Apr 15, 2003Mar 11, 2008American Express Travel Related Services Co., Inc.Transaction card information access web serviceUS7431207 *Jan 5, 2005Oct 7, 2008American Express Travel Related Services Co., Inc.System and method for two-step payment transaction authorizationsUS7472824Mar 18, 2002Jan 6, 2009Diebold Self-Service Systems Division Of Diebold, IncorporatedAutomated banking machine processing system and methodUS7566002 *Jan 6, 2005Jul 28, 2009Early Warning Services, LlcIdentity verification systems and methodsUS7604165Jan 2, 2009Oct 20, 2009Diebold, IncorporatedAutomated banking machine processing system and methodUS7627522Jun 4, 2007Dec 1, 2009Visa U.S.A. Inc.System, apparatus and methods for comparing fraud parameters for application during prepaid card enrollment and transactionsUS7702916Mar 31, 2004Apr 20, 2010Visa U.S.A. Inc.Method and system for secure authenticationUS7761380 *Sep 28, 2007Jul 20, 2010Verifi, Inc.System and method for authenticating a payment instrument transaction originating from a non-internet channelUS7801825Jun 10, 2004Sep 21, 2010Mastercard International IncorporatedSystems and methods for conducting secure payment transactions using a formatted data structureUS7809637Jun 4, 2007Oct 5, 2010Visa U.S.A. Inc.Portability of financial tokensUS7835974Apr 23, 2004Nov 16, 2010Cantor Index, LLC.System and method for managing risk associated with product transactionsUS7860790Jun 4, 2007Dec 28, 2010Visa U.S.A. Inc.Systems and methods for automatic migration of a consumer between financial accountsUS7866551Feb 15, 2008Jan 11, 2011Visa U.S.A. Inc.Dynamic payment device characteristicsUS7882208 *Sep 22, 2005Feb 1, 2011Felica Networks, Inc.Information management apparatus, information management method, and program for managing an integrated circuitUS7908215Dec 4, 2003Mar 15, 2011American Express Travel Related Services Company, Inc.System and method for selection of payment systems from a payment system directory to process a transactionUS7925577Apr 23, 2004Apr 12, 2011Cantor Index LlcSystem and method for establishing and providing access to various types of online accountsUS7991701Sep 1, 2010Aug 2, 2011Visa International Service AssociationOnline payer authentication serviceUS7996297Apr 23, 2004Aug 9, 2011Cantor Index, LlcSystem and method for providing access to and managing account activity for an online accountUS8001039 *Apr 23, 2004Aug 16, 2011Cantor Index, LlcSystem and method for establishing and providing access to an online accountUS8073772Jun 5, 2009Dec 6, 2011American Express Travel Related Services Company, Inc.Systems and methods for processing transactions using multiple budgetsUS8090655Feb 3, 2011Jan 3, 2012American Express Travel Related Services Company, Inc.System and method for selection of payment systems from a payment system directory to process a transactionUS8117649Aug 5, 2010Feb 14, 2012Dormarke Assets Limited Liability CompanyDistributed hierarchical identity managementUS8118223Jan 29, 2008Feb 21, 2012Visa U.S.A. Inc.Smart sign mobile transit fare paymentUS8146806Jun 4, 2007Apr 3, 2012Visa U.S.A. Inc.Prepaid negative balance fee processing and fee diversionUS8160953Nov 15, 2010Apr 17, 2012Cantor Index, LlcSystem and method for managing risk associated with product transactionsUS8165938Jun 4, 2007Apr 24, 2012Visa U.S.A. Inc.Prepaid card fraud and risk managementUS8171525Sep 26, 2011May 1, 2012Google Inc.Enabling users to select between secure service providers using a central trusted service managerUS8172132 *Jul 24, 2009May 8, 2012Early Warning Services, LlcIdentity verification systems and methodsUS8180706Jun 5, 2009May 15, 2012Lead Core Fund, L.L.C.Systems and methods for maximizing a rewards accumulation strategy during transaction processingUS8190514Jun 5, 2009May 29, 2012Lead Core Fund, L.L.C.Systems and methods for transaction processing based upon an overdraft scenarioUS8195565Jun 5, 2009Jun 5, 2012Lead Core Fund, L.L.C.Systems and methods for point of interaction based policy routing of transactionsUS8196131Sep 26, 2011Jun 5, 2012Google Inc.Payment application lifecycle management in a contactless smart cardUS8200260 *Aug 11, 2009Jun 12, 2012Ericsson Television, Inc.Systems and methods for processing purchase transactions between mobile phonesUS8249960Dec 6, 2001Aug 21, 2012Wmode Inc.System and method to provide real time transaction validation and billing via a communications networkUS8255687Sep 26, 2011Aug 28, 2012Google Inc.Enabling users to select between secure service providers using a key escrow serviceUS8260806Jun 29, 2007Sep 4, 2012Grdn. Net Solutions, LlcStorage, management and distribution of consumer informationUS8271384Nov 18, 2011Sep 18, 2012American Express Travel Related Services Company, Inc.System and method for selection of payment systems from a payment system directory to process a transactionUS8290832Jun 4, 2007Oct 16, 2012Visa U.S.A. Inc.Method and system for handling returned prepaid payment cardsUS8297520Sep 27, 2011Oct 30, 2012Google Inc.Secure application directoryUS8311913Feb 13, 2008Nov 13, 2012Visa U.S.A. Inc.Payment entity account set up for multiple payment methodsUS8311914Feb 13, 2008Nov 13, 2012Visa U.S.A. Inc.Payment entity for account payables processing using multiple payment methodsUS8311937Feb 13, 2008Nov 13, 2012Visa U.S.A. Inc.Client supported multiple payment methods systemUS8313036Sep 16, 2011Nov 20, 2012Google Inc.Secure application directoryUS8335921Sep 26, 2011Dec 18, 2012Google, Inc.Writing application data to a secure elementUS8335932Sep 26, 2011Dec 18, 2012Google Inc.Local trusted services manager for a contactless smart cardUS8341046Feb 13, 2008Dec 25, 2012Visa U.S.A. Inc.Payment entity device reconciliation for multiple payment methodsUS8346639Feb 28, 2007Jan 1, 2013Visa U.S.A. Inc.Authentication of a data card using a transit verification valueUS8352749Sep 17, 2011Jan 8, 2013Google Inc.Local trusted services manager for a contactless smart cardUS8359474Mar 1, 2010Jan 22, 2013Visa U.S.A. Inc.Method and system for secure authenticationUS8359630Aug 19, 2008Jan 22, 2013Visa U.S.A. Inc.Method and system for implementing a dynamic verification valueUS8374932Feb 13, 2008Feb 12, 2013Visa U.S.A. Inc.Payment entity device transaction processing using multiple payment methodsUS8376227Jan 17, 2012Feb 19, 2013Ayman HammadSmart sign mobile transit fare paymentUS8379863Apr 10, 2012Feb 19, 2013Google Inc.Enabling users to select between secure service providers using a central trusted service managerUS8385553Jun 14, 2012Feb 26, 2013Google Inc.Portable secure elementUS8386349Feb 28, 2007Feb 26, 2013Visa U.S.A. Inc.Verification of a portable consumer device in an offline environmentUS8407141 *Oct 30, 2007Mar 26, 2013Visa U.S.A. Inc.System and method for processing multiple methods of paymentUS8412933Aug 17, 2012Apr 2, 2013Google Inc.Enabling users to select between secure service providers using a key escrow serviceUS8417626Apr 11, 2011Apr 9, 2013Cantor Index, LlcSystem and method for sports bettingUS8429409Jul 11, 2012Apr 23, 2013Google Inc.Secure reset of personal and service provider information on mobile devicesUS8438109Dec 15, 2011May 7, 2013Plati Networking, LlcSystem and method for selection of payment systems from a payment system directory to process a transactionUS8498924Aug 8, 2011Jul 30, 2013Cantor Index LlcManaging risk associated with betting transactionsUS8504451Nov 14, 2007Aug 6, 2013Visa U.S.A. Inc.Method and system using candidate dynamic data elementsUS8504704 *Jan 24, 2005Aug 6, 2013Dormarke Assets Limited Liability CompanyDistributed contact information managementUS8511573Sep 14, 2012Aug 20, 2013Google Inc.Secure application directoryUS8516560Jan 16, 2009Aug 20, 2013John F. SheetsSecure remote authentication through an untrusted networkUS8523069Sep 28, 2006Sep 3, 2013Visa U.S.A. Inc.Mobile transit fare paymentUS8527752Jan 24, 2005Sep 3, 2013Dormarke Assets Limited LiabilityGraduated authentication in an identity management systemUS8560417Sep 26, 2012Oct 15, 2013Visa U.S.A. Inc.Payment entity for account payables processing using multiple payment methodsUS8566248Nov 20, 2001Oct 22, 2013Grdn. Net Solutions, LlcInitiation of an information transaction over a network via a wireless deviceUS8577801Dec 15, 2011Nov 5, 2013Plati Networking, LlcSystem and method for selection of payment systems from a payment system directory to process a transactionUS8589285Sep 23, 2009Nov 19, 2013Visa U.S.A. Inc.System, apparatus and methods for comparing fraud parameters for application during prepaid card enrollment and transactionsUS8596527Jan 13, 2009Dec 3, 2013Lead Core Fund, L.L.C.Methods for locating a payment system utilizing a point of sale deviceUS8615457Oct 16, 2012Dec 24, 2013Visa U.S.A. Inc.Payment entity device reconciliation for multiple payment methodsUS8620810Mar 31, 2011Dec 31, 2013Isignthis Ltd.Methods and systems for verifying transactionsUS8621168Sep 26, 2011Dec 31, 2013Google Inc.Partitioning the namespace of a contactless smart cardUS8625800Feb 25, 2013Jan 7, 2014Google Inc.Portable secure elementUS8646059Sep 26, 2011Feb 4, 2014Google Inc.Wallet application for interacting with a secure element application without a trusted server for authenticationUS8646685Jan 13, 2009Feb 11, 2014Lead Core Fund, L.L.C.Device for allocating a payment authorization request to a payment processorUS8650103Oct 16, 2002Feb 11, 2014Ebay, Inc.Verification of a person identifier received onlineUS8655768Apr 16, 2012Feb 18, 2014Cantor Index, LlcSystem and method for managing risk associated with product transactionsUS8666855Jun 30, 2003Mar 4, 2014Plati Networking, LlcSystem and method for a payment system directoryUS8666865Sep 26, 2012Mar 4, 2014Visa U.S.A. Inc.Payment entity account set up for multiple payment methodsUS8688554Mar 23, 2009Apr 1, 2014Visa U.S.A. Inc.Bank issued contactless payment card used in transit fare collectionUS8700513Nov 30, 2012Apr 15, 2014Visa U.S.A. Inc.Authentication of a data card using a transit verification valueUS8712892Jan 24, 2013Apr 29, 2014Visa U.S.A. Inc.Verification of a portable consumer device in an offline environmentUS8719161Dec 15, 2011May 6, 2014Plati Networking, LlcSystem and method for selection of payment systems from a payment system directory to process a transactionUS8733663Mar 23, 2009May 27, 2014Visa U.S.A. Inc.Mobile phone containing contactless payment card used in transit fare collectionUS8737621Jan 28, 2013May 27, 2014Google Inc.Enabling users to select between secure service providers using a central trusted service managerUS8738485Dec 28, 2007May 27, 2014Visa U.S.A. Inc.Contactless prepaid product for transit fare collectionUS8751347Jan 9, 2013Jun 10, 2014Visa U.S.A. Inc.Payment entity device transaction processing using multiple payment methodsUS8774721Apr 10, 2012Jul 8, 2014Google Inc.Detecting a communication tap via signal monitoringUS8788382Nov 19, 2010Jul 22, 2014Visa U.S.A. Inc.Systems and methods for automatic migration of a consumer between financial accountsUS8788417Dec 15, 2011Jul 22, 2014Plati Networking, LlcSystem and method for selection of payment systems from a payment system directory to process a transactionUS8788945 *Jun 30, 2008Jul 22, 2014Amazon Technologies, Inc.Automatic approvalUS8793508Dec 17, 2012Jul 29, 2014Google Inc.Local trusted services manager for a contactless smart cardUS8794509Jan 13, 2009Aug 5, 2014Lead Core Fund, L.L.C.Systems and methods for processing a payment authorization request over disparate payment networksUS8799121Apr 23, 2004Aug 5, 2014Cantor Index, LlcSystem and method for managing trading order requestsUS8799814Feb 22, 2008Aug 5, 2014Amazon Technologies, Inc.Automated targeting of content componentsUS8806199Nov 27, 2012Aug 12, 2014Google Inc.Writing application data to a secure elementUS8807440Sep 26, 2011Aug 19, 2014Google Inc.Routing secure element payment requests to an alternate applicationUS8814039Jan 13, 2009Aug 26, 2014Lead Core Fund, L.L.C.Methods for processing a payment authorization request utilizing a network of point of sale devicesUS8820633Jan 13, 2009Sep 2, 2014Lead Core Fund, L.L.C.Methods for a third party biller to receive an allocated payment authorization requestUS8825512 *Aug 10, 2011Sep 2, 2014Verizon Patent And Licensing, Inc.Persistent network-based electronic transaction servicesUS8826397 *Jan 15, 2009Sep 2, 2014Visa International Service AssociationSecure remote authentication through an untrusted networkUS8827156Jul 10, 2013Sep 9, 2014Visa U.S.A. Inc.Mobile payment deviceUS8851369Jul 17, 2009Oct 7, 2014Lead Core Fund, L.L.C.Systems and methods for transaction processing using a smartcardUS8875990Jan 13, 2009Nov 4, 2014Lead Core Fund, L.L.C.Systems and methods for allocating a payment authorization request to a payment processorUS8898761 *Jan 13, 2011Nov 25, 2014International Business Machines CorporationSystems and methods for generating and validating configuration files for computing devicesUS8904481Dec 17, 2012Dec 2, 2014Visa U.S.A. Inc.Method and system for implementing a dynamic verification valueUS8931691Dec 1, 2010Jan 13, 2015Visa U.S.A. Inc.Dynamic payment device characteristicsUS8959652Aug 30, 2013Feb 17, 2015Dormarke Assets Limited Liability CompanyGraduated authentication in an identity management systemUS8971533Apr 22, 2013Mar 3, 2015Google Inc.Secure reset of personal and service provider information on mobile devicesUS9008616Dec 9, 2011Apr 14, 2015Google Inc.Point of sale processing initiated by a single tapUS9198214Jul 7, 2014Nov 24, 2015Google Inc.Detecting a communication tap via signal monitoringUS9213977Mar 9, 2014Dec 15, 2015Visa U.S.A. Inc.Authentication of a data card using a transit verification valueUS9245266Jun 16, 2004Jan 26, 2016Callahan Cellular L.L.C.Auditable privacy policies in a distributed hierarchical identity management systemUS9275239May 27, 2011Mar 1, 2016Hewlett-Packard Development Company, L.P.Transaction gatewayUS9355391Mar 6, 2012May 31, 2016Google Inc.Digital walletUS9373115Apr 9, 2014Jun 21, 2016Visa U.S.A. Inc.Contactless prepaid product for transit fare collectionUS9390414Jan 30, 2012Jul 12, 2016Google Inc.One-click offline buyingUS9398020Feb 13, 2015Jul 19, 2016Callahan Cellular L.L.C.Graduated authentication in an identity management systemUS9449319Jun 30, 2008Sep 20, 2016Amazon Technologies, Inc.Conducting transactions with dynamic passwordsUS9450927Mar 18, 2013Sep 20, 2016Google Inc.Enabling users to select between secure service providers using a key escrow serviceUS9495672Apr 1, 2014Nov 15, 2016Visa U.S.A. Inc.Mobile device containing contactless payment card used in transit fare collectionUS9576288 *Jul 21, 2014Feb 21, 2017Amazon Technologies, Inc.Automatic approvalUS20020055911 *Nov 6, 2001May 9, 2002Electronic Warfare AssociatesSystem and method for controlling online purchases using an online accountUS20020133536 *Mar 18, 2002Sep 19, 2002Diebold, IncorporatedAutomated banking machine processing system and methodUS20020164031 *Aug 10, 2001Nov 7, 2002Lauri PiikiviDevicesUS20040068473 *Dec 6, 2001Apr 8, 2004Cooper Dave M.L.System and method to provide real time transaction validation and billing via a communications networkUS20040078324 *Oct 16, 2002Apr 22, 2004Carl LonnbergSystems and methods for authenticating a financial account at activationUS20040208164 *Apr 15, 2003Oct 21, 2004Keenan Sean M.Transaction card information access web serviceUS20040230514 *Apr 23, 2004Nov 18, 2004Cantor Index LlcSystem and method for managing risk associated with product transactionsUS20040230515 *Apr 23, 2004Nov 18, 2004Cantor Index LlcSystem and method for providing access to and managing account activity for an online accountUS20040230516 *Apr 23, 2004Nov 18, 2004Cantor Index LlcSystem and method for establishing and providing access to an online accountUS20040230517 *Apr 23, 2004Nov 18, 2004Cantor Index LlcSystem and method for establishing and providing access to various types of online accountsUS20040260640 *Apr 23, 2004Dec 23, 2004Cantor Index LlcSystem and method for managing trading order requestsUS20040267643 *Dec 4, 2003Dec 30, 2004American Express Travel Related Services Company, Inc.System and method for selection of payment systems from a payment system directory to process a transactionUS20050029344 *Jul 2, 2004Feb 10, 2005Visa U.S.A.Managing activation of cardholders in a secure authentication programUS20050060263 *Sep 13, 2004Mar 17, 2005Lior GolanSystem and method for authenticationUS20050125347 *Dec 8, 2003Jun 9, 2005Akialis Ronald P.Jr.Bill payment authorization system and methodUS20050160064 *Sep 30, 2004Jul 21, 2005Arto LehtonenConfirming user rights in distribution of application programsUS20060101136 *Sep 22, 2005May 11, 2006Felica Networks, Inc.Information management apparatus, information management method, and programUS20060144927 *Jan 6, 2005Jul 6, 2006First Data CorporationIdentity verification systems and methodsUS20060259439 *Jul 17, 2006Nov 16, 2006Mann William F IiiSystem for providing cardless paymentUS20070011172 *Oct 14, 2005Jan 11, 2007Netfire1 Pty LtdManaged e-community trading environmentsUS20080120214 *Nov 6, 2007May 22, 2008Kim SteeleAdaptive authentication optionsUS20080120236 *Nov 14, 2007May 22, 2008Patrick FaithDynamic magnetic stripeUS20080126252 *Sep 28, 2007May 29, 2008Matthew KatzMethod and system for converting mail order/telephone order transactions into E-commerce transactionsUS20080197201 *Feb 15, 2008Aug 21, 2008Thomas ManessisDynamic payment device characteristicsUS20080298569 *Jun 4, 2007Dec 4, 2008Monk Justin TPrepaid negative balance fee processing and fee diversionUS20080300895 *Jun 4, 2007Dec 4, 2008Monk Justin TMethod and system for handling returned payment card account statementsUS20080301011 *Jun 4, 2007Dec 4, 2008Monk Justin TMethod and system for handling returned prepaid payment cardsUS20080301037 *Jun 4, 2007Dec 4, 2008Monk Justin TSystems and methods for automatic migration of a consumer between financial accountsUS20080301048 *Jun 4, 2007Dec 4, 2008Monk Justin TPortability of financial tokensUS20090055893 *Aug 19, 2008Feb 26, 2009Thomas ManessisMethod and system for implementing a dynamic verification valueUS20090112658 *Feb 13, 2008Apr 30, 2009Visa Usa, Inc.Client supported multiple payment methods systemUS20090112659 *Feb 13, 2008Apr 30, 2009Visa Usa, Inc.Payment entity account set up for multiple payment methodsUS20090112661 *Feb 13, 2008Apr 30, 2009Visa Usa, Inc.Payment entity device transaction processing using multiple payment methodsUS20090112662 *Feb 13, 2008Apr 30, 2009Visa Usa, Inc.Payment entity device reconciliation for multiple payment methodsUS20090112747 *Oct 30, 2007Apr 30, 2009Visa U.S.A. Inc.System and Method For Processing Multiple Methods of PaymentUS20090145962 *Jan 2, 2009Jun 11, 2009Diebold, IncorporatedAutomated banking machine processing system and methodUS20090157518 *Jan 13, 2009Jun 18, 2009American Express Travel Related Services Company, Inc.Systems and Methods for Allocating a Payment Authorization Request to a Payment ProcessorUS20090157519 *Jan 13, 2009Jun 18, 2009American Express Travel Related Servics Company, Inc.Device for Allocating a Payment Authorization Request to a Payment ProcessorUS20090164324 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Methods for a Third Party Biller to Receive an Allocated Payment Authorization RequestUS20090164325 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Systems and Methods for Locating an Automated Clearing House Utilizing a Point of Sale DeviceUS20090164326 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Methods for locating a payment system utilizing a point of sale deviceUS20090164327 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Methods for Processing a Payment Authorization Request Utilizing a Network of Point of Sale DevicesUS20090164328 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Systems and Methods for Locating a Payment System and Determining a Taxing Authority Utilizing a Point of Sale DeviceUS20090164329 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Systems for Processing a Payment Authorization Request Utilizing a Network of Point of Sale DevicesUS20090164330 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Systems and Methods for Processing a Payment Authorization Request Over Disparate Payment NetworksUS20090164331 *Jan 13, 2009Jun 25, 2009American Express Travel Related Services Company, Inc.Systems for Locating a Payment System Utilizing a Point of Sale DeviceUS20090271277 *Jun 5, 2009Oct 29, 2009American Express Travel Related Services Company, Inc.Systems and methods for transaction processing based upon an overdraft scenarioUS20090271278 *Jun 5, 2009Oct 29, 2009American Express Travel Related Services Company, Inc.Systems and methods for routing a transaction request to a payment system via a transaction deviceUS20090287564 *Jun 5, 2009Nov 19, 2009American Express Travel Related Services Company, Inc.Systems and methods for maximizing a rewards accumulation strategy during transaction processingUS20090287565 *Jun 5, 2009Nov 19, 2009American Express Travel Related Services Company, Inc.Systems and methods for point of interaction based policy routing of transactionsUS20090299841 *Jun 5, 2009Dec 3, 2009American Express Travel Related Services Company Inc.Systems and methods for processing transactions using multiple budgetsUS20090313069 *Jul 24, 2009Dec 17, 2009Early Warning Services, LlcIdentity Verification Systems and MethodsUS20100070424 *Sep 23, 2009Mar 18, 2010Monk Justin TSystem, apparatus and methods for comparing fraud parameters for application during prepaid card enrollment and transactionsUS20100180326 *Jan 15, 2009Jul 15, 2010Sheets John FSecure remote authentication through an untrusted networkUS20100180327 *Jan 16, 2009Jul 15, 2010Sheets John FSecure remote authentication through an untrusted networkUS20100325052 *Aug 25, 2010Dec 23, 2010Jagdeep Singh SahotaWireless transaction payment service application selectionUS20100332382 *Sep 2, 2010Dec 30, 2010Monk Justin TPortability of financial tokensUS20110039585 *Aug 11, 2009Feb 17, 2011Tandberg Television Inc.Systems and methods for processing purchase transactions between mobile phonesUS20110066542 *Nov 15, 2010Mar 17, 2011Adam BurgisSystem and method for managing risk associated with product transactionsUS20110082792 *Oct 25, 2010Apr 7, 2011Data Treasury CorporationProcessing of Credit Card Transactions Using Internet ProtocolUS20110125634 *Nov 19, 2010May 26, 2011Monk Justin TSystems and methods for automatic migration of a consumer between financial accountsUS20110137798 *Feb 3, 2011Jun 9, 2011American Express Travel Related Services Company, Inc.System and method for selection of payment systems from a payment system directory to process a transactionUS20110184861 *Apr 5, 2011Jul 28, 2011American Express Travel Related Services Company, Inc.Method and system for implementing and managing an enterprise identity management for distributed security in a computer systemUS20110186626 *Dec 1, 2010Aug 4, 2011Thomas ManessisDynamic payment device characteristicsUS20110196724 *Feb 9, 2010Aug 11, 2011Charles Stanley FentonConsumer-oriented commerce facilitation services, applications, and devicesUS20110202565 *Apr 4, 2011Aug 18, 2011American Express Travel Related Services Company, Inc.Method and system for implementing and managing an enterprise identity management for distributed security in a computer systemUS20110208658 *Dec 9, 2010Aug 25, 2011Oleg MakhotinMultifactor Authentication Using A Directory ServerUS20120066129 *Aug 4, 2011Mar 15, 2012Visa International Service AssociationData authentication and provisioning method and systemUS20120066130 *Aug 4, 2011Mar 15, 2012Visa International Service AssociationData authentication and provisioning method and systemUS20120078795 *Dec 6, 2011Mar 29, 2012Jpmorgan Chase Bank, N.A.System for providing cardless paymentUS20120185925 *Jan 13, 2011Jul 19, 2012International Business Machines CorporationSystems and Methods for Generating and Validating Configuration Files for Computing DevicesUS20130041770 *Aug 10, 2011Feb 14, 2013Verizon Patent And Licensing, Inc.Persistent network-based electronic transaction servicesUS20130105573 *Apr 20, 2012May 2, 2013Early Warning Services, LlcIdentity verification systems and methodsUS20130185207 *Jan 17, 2012Jul 18, 2013Mastercard International IncorporatedMethod and system for online authentication using a credit/debit card processing systemUS20150006407 *Jan 11, 2013Jan 1, 2015Ebay Inc.Systems, methods, and computer program products providing payment in cooperation with emv card readersEP1528451A1 *Oct 27, 2003May 4, 2005Axalto S.A.Authentication framework for smart cardsEP1636680A2 *Jun 10, 2004Mar 22, 2006Mastercard International, Inc.Systems and methods for conducting secure payment transactions using a formatted data structureEP1636680A4 *Jun 10, 2004Mar 13, 2013Mastercard International IncSystems and methods for conducting secure payment transactions using a formatted data structureEP1723582A2 *Oct 21, 2004Nov 22, 2006Visa USA, Inc.Managing attempts to initiate authentication of electronic commerce card transactionsEP1723582A4 *Oct 21, 2004May 21, 2008Visa Usa IncManaging attempts to initiate authentication of electronic commerce card transactionsWO2004025413A2 *Sep 10, 2003Mar 25, 2004Visa International Service AssociationData authentication and provisioning method and systemWO2004025413A3 *Sep 10, 2003Apr 28, 2005Benedicto H DominguezData authentication and provisioning method and systemWO2004029823A1 *Sep 25, 2003Apr 8, 2004Telemac CorporationMethod and system for managing local control of wlan accessWO2005001635A2 *Jun 10, 2004Jan 6, 2005Mastercard International IncorporatedSystems and methods for conducting secure payment transactions using a formatted data structureWO2005001635A3 *Jun 10, 2004Oct 12, 2006Mastercard International IncSystems and methods for conducting secure payment transactions using a formatted data structureWO2008042252A2 *Sep 28, 2007Apr 10, 2008Matthew KatzMethod and sysem for converting mail order/telephone order transactions into e-commerce transactionsWO2008042252A3 *Sep 28, 2007Jul 3, 2008Matthew KatzMethod and sysem for converting mail order/telephone order transactions into e-commerce transactionsWO2008106561A2 *Feb 27, 2008Sep 4, 2008Visa U.S.A. Inc.Verification of a portable consumer device in an offline environmentWO2008106561A3 *Feb 27, 2008Nov 6, 2008Visa Usa IncVerification of a portable consumer device in an offline environmentWO2011106404A2 *Feb 23, 2011Sep 1, 2011Visa International Service AssociationMultifactor authentication using a directory serverWO2011106404A3 *Feb 23, 2011Dec 8, 2011Visa International Service AssociationMultifactor authentication using a directory server* Cited by examinerClassifications U.S. Classification705/64International ClassificationG06Q20/04, G06Q20/08, G06Q20/40, G06Q20/36, G06Q20/38, G06Q20/34, G06Q20/02, G06Q20/12, G06K17/00, G07F7/12, G07F7/10Cooperative ClassificationG06Q20/4012, G07F7/1016, G06Q20/3829, G06Q20/341, G06Q20/3674, G06Q20/40, G06Q20/02, G06Q20/382, G06Q20/355, G06Q20/0855, G06Q20/4014, G07F7/1008, G06Q20/367, G06Q20/027, G06Q20/12, G06Q20/04European ClassificationG06Q20/12, G06Q20/04, G06Q20/40, G06Q20/02, G06Q20/3674, G06Q20/027, G06Q20/3829, G06Q20/382, G06Q20/4012, G06Q20/355, G06Q20/367, G06Q20/0855, G06Q20/341, G06Q20/4014, G07F7/10E, G07F7/10DLegal EventsDateCodeEventDescriptionMar 17, 2009ASAssignmentOwner name: VISA INTERNATIONAL SERVICE ASSOCIATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RENO, JAMES DONALD;REEL/FRAME:022409/0485Effective date: 20060331Mar 18, 2016FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services