MXPA06006158A - Multiple party benefit from an online authentication service - Google Patents

Abstract

An account authentication service where a trusted party verifies an account holder's identity for the benefit of a requestor during an online transaction. The account authentication involves requesting a password from the account holder, verifying the password, and notifying the requestor whether the account holder's authenticity has been verified. An alternative embodiment of the account authentication service includes a value-adding component where information about a customer is shared with a value-adding party. The customer information is rich in detail about the customer since it is collected by each of the parties in the account authentication process. The value-adding party can then use this information in various manners. All of the parties involved can benefit from sharing the customer information. The value-adding party can be, for example, a merchant, a shipper, a security organization, or a governmental organization. A transaction identifier identifies a specific transaction between a customer, a merchant, and the customer information.

Description

BENEFIT MULTIPARTES FROM A ONLINE AUTHENTICATION SERVICE FIELD OF THE INVENTION The present invention relates in general to the authentication of the identity of the account holders during online transactions, and more specifically, to a technique for sharing and using the information related to the authentication procedure with value-added parts.

BACKGROUND OF THE INVENTION During a payment transaction using a payment card (for example, a credit, debit, or stored value card), it is important to verify the ownership of the cardholder of an account to avoid a variety of problems, such as Unauthorized use. Paid authentication is the process of verifying ownership of the card holder of an account. The most common method of authenticating the cardholder's ownership of an account occurs routinely at a point of sale during what is called a "present card" transaction. A present card transaction involves the merchant's representative taking the card holder's card, sliding it through a card payment terminal to verify the status of the account and the availability of the credit line, and then verify to see that the signature on the back of the card matches the signature of the buyer. If the merchant follows the specific guidelines for this type of transaction, the merchant will guarantee the payment for the authorized amount less the discount of the installments. A service provider such as Visa International Service Association (or service organization) can provide these specific guides. "Card not present" transactions, on the other hand, such as those that occur online, through mail, or over the telephone involve payments that are not guaranteed to the merchant. No guarantee is provided mainly because the payers are not authenticated in such non-personal transactions, allowing there to be many risks that accompany "card not present" transactions. These risks involve aspects such as reimbursements of payment transactions for online merchants, frauds for both merchants and cardholders, expenses for processing the exception item increased for banks, and an increased perception that purchased goods and services. online are not safe nor are they protected which prevents some customers from buying online. Specific examples of risks include the unauthorized use of information from a stolen account to purchase goods and services online, the manufacture of card account numbers to make fraudulent online purchases, and the extraction of account information from clear text from network traffic. Given the continued high expected growth of electronic commerce, it is important to provide methods to authenticate payers. Given the rise of online transaction types, it is also important to provide methods to authenticate the identity of the parties regardless of whether there is a commercial aspect to a transaction. This will benefit all the participants of the transaction in the scale of cardholders, merchants, financial institutions, to government agencies. The authentication of clients during the transactions lines will reduce the levels of fraud, disputes, recoveries and reimbursements, which will subsequently reduce the costs associated with each of these events. Client authentication will also lead to security issues and consequently will lead to an increase in online activity. The previous systems used to authenticate the parties during the online transactions have not been widely adopted because these systems are difficult to use, have complex designs, require an initial and significant investment through the system participants and lack of interoperability. Certain previous systems additionally require the creation, distribution, and use of certificates through merchants, cardholders, and issuers and acquirers. Said use of certificates is known as oppressive.

In view of the above, there are continuing efforts to provide improved systems to authenticate the identity of customers in online transactions. In addition, there are also ongoing efforts to beneficially use the information available to the parties involved in such authentication procedures.

BRIEF DESCRIPTION OF THE INVENTION The present invention is directed to an account authentication service that authenticates the identity of a presenter during online transactions. The authentication service allows the trusted party to verify the identity of the account holder for the benefit of a requesting party ("requester") using a variety of authentication methods, such as passwords or tokens. Authentication of the account holder's identity during an online transaction involves requesting a password from the account holder, verifying the password, and notifying the requestor if the holder's authenticity has been verified. An alternative modality of the account authentication service includes a value-added component in which the information about the customer is shared with a part of added value. The customer information is rich in detail about the customer as it is collected through each of the parties in the account authentication procedure. The value-added part can then use this information in several ways. All parties involved can benefit from the sharing of customer information and each party can agree on how they can help each other to gain value. Through the use of a transaction identifier, which identifies a specific transaction between the customer and a merchant and the customer's information, each of the parties can also audit the transactions and any agreements related to the customer's information. As a method, one embodiment of the present invention includes at least receiving a password for authentication of identity by the presenter and comparing the authentication password of the identity against a password previously designated for a presenter account. The method also includes notifying an applicant that the presenter is the current owner of the account when the identity authentication password received from the presenter matches the password that was previously designated for the account. In this way, the trusted party authenticates for the benefit of the applicant that the presenter is the current owner of the account. The method also includes sending the presenter information to the value-added party. In some modalities, the method also involves evaluating the presenter's information against a set of criteria and sending the presenter's information to the value-added party if the presenter's information satisfies the group of criteria. This allows the value-added party to receive the desired customer information. Also, each of the applicant and the value-added party may agree to establish rights and obligations as a condition before the presenter's information is sent to the value-added party. Additionally, a transaction identifier can be used to track individual online transactions and related customer information. In one embodiment of the invention, the applicant is a merchant and the value-added part is a shipping company that can use the customer's information to ship a product purchased from the merchant. The customer information helps the shipping company decide if and how a product will be shipped to the customer. In another form of the invention, the applicant is a merchant and the value-added part results from the merchant who can use the information of the customer to market his own goods or services to the customer. The information of the client helps the merchant resulting in the decision of if and how it will correspond to the client. In another embodiment of the invention, the value-added part is a security organization that can use customer information to evaluate security issues. The information of the client helps the security organization in the decision of itself and how the possible concerns about security will be handled. These and other features and advantages of the present invention will be presented in greater detail in the following specification of the invention and the accompanying drawings, which illustrate the principles of the invention by way of example.

BRIEF DESCRIPTION OF THE DRAWINGS The invention, together with the additional advantages thereof, can be better understood by reference to the following description taken in conjunction with the accompanying drawings in which: Figure 1 illustrates one embodiment of a system architecture to increase the account authentication service of the present invention for various types of account authentication applications. Figure 2 illustrates schematically one embodiment of a system architecture that supports the authentication service of the present invention in payment transactions. Figure 3 illustrates the process by which a account holder registers in the account authentication system according to one embodiment of the present invention. Figure 4 illustrates a form of an Internet page where the account holder can capture information during the process of subscribing to the account authentication system.

Figure 5 describes an authenticated payment transaction in the account authentication system where the account holder uses a computer that is connected to the internet. Figure 6 illustrates an illustrative window that asks the account holder for his password. Figure 7 illustrates messages that are sent during the payment transaction superimposed on the account authentication system where a customer uses a computer that is connected to the Internet. Figure 8 illustrates the architecture of the illustrative system and establishes that the flows of the messages involved in the authentication of the online account that includes an aspect of added value. Figure 9 illustrates a telecommunications network suitable for implementing an embodiment of the present invention. Figure 10 illustrates the systems hosted within an exchange center to provide online and offline transaction processing. Figure 11 illustrates another view of the components of the telecommunications network. Figures 12A and 12B illustrate a suitable computer system for implementing the embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION The present invention will now be described in detail with reference to a few modalities thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a broad understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention can be practiced without some or all of the specific details. In other instances, well-known operations have not been described in detail so as not to obscure the present invention unnecessarily. The present disclosure, in Figure 1, will begin with an introduction of a generalized account authentication system and a protocol according to the present invention. The account authentication system is provided as a service to participate issuers, account holders, and merchants. Then, in Figures 2-7, an embodiment of the account authentication system related to online payment transactions is described. The description of online payment transactions covers the payment transaction itself, the system configuration, the customer record, and the flows of specific messages. The description for online payment transactions are analogous to the description for non-payment transactions. Both payment and non-payment transactions involve the authentication of the identity of the account holder.

Then, Figure 8, the description describes an embodiment of the account authentication procedure that includes a value-added component. The value is added first by sharing information about a customer and with a value added part. The customer information is rich in detail about the customer as it is collected through each of the parties in the account authentication procedure. The value-added part can then use this information in various ways. For example, the value added part can then provide information focused on the customer or ship a good to the customer. All parties involved can benefit from the sharing of customer information and each party can agree on how they can help each other to earn the benefits. By using a transaction identifier, which identifies a specific transaction between a customer and a merchant and customer information, each of the parties can also audit the transactions and any agreements related to the customer's information. This application describes how sharing such information can be advantageously used in a scale of applications to benefit a wide scale of parts.

Account Authentication System The account authentication system is designed to authenticate the owner of an account holder's account during transactions where one party can not physically verify the identity of another party claiming to be the owner of a specific account . For example, the account authentication system can be used in several transactions or in a reliable separate authenticates the identity of a presenter for the benefit of an applicant. A presenter is any individual or entity that presents itself as having a specific identity. An applicant is any individual or entity that requests a trusted party to authenticate to identify the presenter. A reliable part is an identity capable of authenticating the identity of the presenter and whose presenter and applicant trust in the development of the authentication procedure. The reliable party may agree to protect the interests of the applicant in the case of errors or fraud with respect to the identity of the presenter. An important application of an account authentication system is in the field of payment transactions that take place either online or through portable electronic devices. However, the system can be useful in many applications other than payment transactions. The system of the present invention can be used in several non-payment situations where the identity of a client requires authentication. For example, non-payment transactions include transactions such as the authentication of a client accessing a website on the Internet to complete an online form, for example, for a registration procedure. Non-payment transactions also include many aspects of retail banking transactions, wholesale banking transactions, medical businesses, insurance businesses and brokerage firms, just to name a few. Retail banking services involve account numbers used with cards such as debit cards, purchase cards, and stored value cards. Non-payment transactions also include filling out online forms for things such as cards and identification licenses. For example, the American Automobile Association (AAA) may use the system to authenticate the identity of one or more of its customers or a telephone card company may use the system to authenticate the identity of a user of a specific card. Figure 1 illustrates one modality of system architecture 100 to implement the account authentication system for various types of account authentication applications. The architecture of the system 100 includes three domains: a domain of the trusted party 103, an interoperability domain 104 and a part of the requesting domain 105. The domains of the trusted party and the applicant define the functional domains within which the components that they are totally or at least partially controlled by the trusted party or the applicant, respectively. The interoperability domain defines a functional domain within which components can be used through the trusted party, the requester, as well as other parties, such as a service organization. The domain of the trusted party 103 includes components that are mainly controlled by a trusted party. An example of a reliable party is a financial institution that issues payment cards to consumers, known as the issuing bank. Specifically, an issuer, or card issuer, customizes the new cards received from a card provider and then issues these cards to its customers. Personalization can also be carried out through the card provider or through a personalization agency. In addition to being a financial institution, an issuer may be any suitable issuing entity such as the telecommunications network operator, a service association, a merchant or other organization, or even an agent acting for an issuer. The requesting domain 105 includes components that are mainly controlled by an applicant. An applicant can be any party that makes a request for the identity of an account holder to be authenticated. For example, an applicant may be a merchant who wishes to authenticate the identity of a person claiming to be the owner of a credit card account. An acquirer can be a financial institution that hires applicants in the payment scheme and manages the accounts of the applicants. An acquirer also routes the information from an online merchant to the telecommunications network. In other modalities, a merchant can directly route the information to the telecommunications network. The interoperability domain 104 may be supported by the Internet and includes components used by both the trusted party and the requester.

The domain of the trusted party 103 includes a proprietary system of the issuing account 110, a registration server, an access control server (ACS) 114, and a file of the account holder 18. The additional components are included within the domain of the trusted party 103 depending on the specific field of use where the system will use. For example, in the following payment transactions, the additional components in each of the domains are present for the purpose of authenticating the identities of the account holder with respect to the payment transactions. The registration server 112 is a computer that manages the account holder's account registration in the account authentication system by presenting a series of questions through a web interface that will be answered by the account holder and verified by the reliable party . As shown in Figure 1, the trusted party operates on registry server 112. However, a service organization such as Visa can operate the registration service 112 for the benefit of the trusted party. The trusted party can use the interactive "identity authentication service" provided by an external entity during the registration process to help validate the identity of an account holder. ACS 114 is a computer that has a database of account holders registered in the account authentication service provided by the account authentication system. ACS 114 contains the account information and passwords for each of the account holders. During an account authentication transaction, ACS 114 provides mainly signed waste for an authentication requester, controls access to the account authentication system, and validates the account holder's participation in the service. A card issuer or service organization such as Visa can operate the ACS 114 for the reliable party. While the account authentication service does not require any software from the additional account holder to use the optional account holder software and the hardware can be used. The software of the additional account holder can support additional authentication techniques such as digital certificates, integrated circuit cards (cards with chips) and card readers with chips. Note that the present invention, only a participating system requires a certificate that is going to be issued by the financial institution. The account holder's file 118 is a database managed by the trusted party to store the information related to the account holders that have successfully registered with the account's authentication system. The issuer account holder 110 system (or the Reliable Party Account Holder System) is controlled through the trusted party and contains information about account holders. This information refers to the account information, the services-used by the account holder, etc. Some of this information within the system of the issuing account holder 110 can be used in account account holders in the account authentication service. The requestor 180 of the requesting domain 105 typically desires the authentication of the account holder. The part 180 handles the request for the auxiliary software 182 that facilitates the authentication protocol. The module for requesting auxiliary software 182 is a software module that is integrated into a website of the applicant or a third party. The auxiliary software module 182 provides the interface between the account authentication system and the applicant's processing software, for example, the software for a merchant's payment procedure. The interoperability domain 104 contains the directory 128 server that is supported by the Internet, and includes components used by both the reliable party and the applicant. The directory server 128 routes the requests for authentication of the requesters to the specific ACSs, such as the ACS 114. The directory server 128 is operated through a card scheme manager or a service organization, such as Visa. The operable domain 104 may also be supported by a network different from the Internet.

Account authentication system for payment transactions A description of the system architecture for authentication of an account holder in the domain of payment transactions will now be provided. Note that many of the general concepts described in this section apply to several fields of use since the authentication procedure for payment authentication is analogous to non-payment application. An illustrative use of the authentication system and the protocol in transactions is described below. The authentication system is useful in a scenario when the account holder buys online, adds items to his "shopping cart", proceeds to the completion page of the online merchant's purchase and completes the purchase completion forms online merchant online. Authentication procedures can take place after the customer decides to purchase desired service products, for example, after the consumer clicks on the "buy" button. The authentication procedure can also start at several other times in the customer's payment transaction. The authentication procedure is conducted mainly in a transparent mode for the consumer through the use of software that has been incorporated in several points of a payment network. The system validates the participation through the account holder and the financial institution of the account holder with the authentication service. Then a window is created where the client can confirm their identity by requesting a previously registered password from the account holder. If the identity of the consumer is confirmed, the payment information and the notification of the client's authentication is sent back to the merchant. Then, as is conventionally done, the payment transaction is processed through the merchant. For example, the merchant can send a confirmation order message to the browser of the account holder. Figure 2 schematically illustrates one embodiment of a system architecture 200 that supports the authentication service in payment transactions. As with the architecture of the general system 100 of Figure 1, the architecture 200 is divided into three domains: the domain of the sender 102, the interoperability domain 104 and the domain of the acquirer 106. The domain of the sender 102 and the domain of the acquirer 106 of Figure 2 are analogs for the domain of the trusted party 103 and the requesting domain 105 of Figure 1, respectively. The domain of the sender 102 includes a registration site 108, a system of the issuing account holder 110, and a client device of the account holder 122, a registration server 112, an access control server (ACS) 114 , an identity authentication component of the issuer or the applicant 116, and a file of the account holder 118. Optionally, the domain of the issuer 102 may include a file of the issuer of approved account holders 120. The account holder is another term that refers to a presenter since the account holder will also be controlled as having a specific entity. The registration service 112 is a computer that manages the account holder's registration in the account's authentication system through the presentation of a series of questions through a web interface that will be answered by the account holder and verified by the issuer. The registration server 112 is connected through the Internet to the Internet payment link service 124, which in turn is connected to a telecommunications network 126, for example, VisaNet. The Internet Payment Link Service 124 allows the registration server 112 to communicate with the telecommunications networks 126. The Payment Link Service 124 allows the registration server 112 see the authorization system of issuer 127 to determine if an account holder that is being registered has an active card account. The registration site 108 is a website on the Internet where the account holder can register to participate in the account authentication service provided by the account authentication system. The client device of the account holder 122 is used for the account holder to participate in the account authentication system.

Specifically, the client device of the account holder 122 may be any device capable of accessing the Internet, such as a personal computer, a mobile telephone, a personal data assistant, or an interactive cable television. In some embodiments, the client device of the account holder 122 can not be connected to the Internet, however such devices can still be used through the account holder because the input and output messages of the client device 122 are They route through special nodes that can be controlled by the base messages and not the Internet. For example, mobile phones that transmit and receive messages based on voice and / or text messages do not connect to the internet, however they can still be used with the account authentication system through the routing of messages in a form different. The Short Message Service (SMS) is a commonly used example of a messaging system. An Interactive Voice Response (IVR) unit can be used to automate exchanges through a voice channel. This message routing arrangement will be described in more detail in the following section on non-Internet capable devices. The account holder system of issuer 110 is an issuer-controlled system that contains information about account holders. This information system contains information concerning the account information, the services used by the account holder, etc. Some part of the information within the system of the account holder of the issuer can be used the procedure to register account holders within the account authentication system. The identity authentication database of the issuer or applicant 116 contains information that the user or applicant already has a file with respect to the account holders. The database 116 is used by the issuer in the procedure of registering account holders to verify the identity of the account holders. For example, the information captured by the account holders during the registration procedure of the account holder must match the information that already exists in the files in the authentication database 116 in order for the account holders to successfully they are registered in the service provided by the account authentication system. The third parties can also be companies such as Equifax. The operability domain 104 includes a directory server 128, an authentication history server 130, and a receipt manager 131. The directory server 128 routes authentication requests from the merchants to a specific ASC. The directory 128 server is operated through a service organization, such as Visa. The authentication history server 130 and the receipt administrator 131 store the signed receipts (eg, copies of the Payment Request Response message described below) for each authenticated payment transaction. The authentication history server 130 contains information that verifies which transactions were authenticated and provides additional information during the dispute resolution procedures. The authentication history server 130 and the receipt manager 131 are operated through a service organization. The issuer, the acquirer or the merchant can also keep a copy of the digitally signed receipt. The domain of the acquirer 106 includes the merchant 132 and the validation server 136. An MPI 134 resides in the location of the merchant 132. MPL 134 is a software module that is integrated into the merchant's e-commerce websites. MPL 134 provides the interface between the authentication system of accounts and software for the merchant's payment procedure. Note that MPl 134 is the same software module as the requesting auxiliary software module 182 of Figure 1. The "merchant" descriptor is used so that the MPl 134 indicates which type of requesting party is using the additional software module. However, it should be understood that the additional software modules described throughout this specification function basically in the same independently of the adjective used to describe auxiliary software modules 134. To simplify the use of terminology throughout this specification, the adjective "merchant" will be used to describe additional software modules. However, it should not be read that it limits the auxiliary software modules 134 as only being suitable for use by the requesting parties that are merchants. In addition, MPl will be used as the acronym for the merchant assistant software module. Validation server 136 verifies the digital signature of the issuer of the card used to sign the receipt returned by the account authentication system to the merchant during the payment transaction. In alternative embodiments, the functionality of the validation server 136 can be included in MPl 134, thus eliminating the need for a separate validation server 136. The validation server 136 is operated through the merchant, and the acquirer, or through of a service organization. In some modalities, the account authentication system can interoperate with other applications of account holders, such as electronic wallets, and the service can operate compatible with the electronic commerce markup language (ECML software). The account authentication system can also provide capabilities to implement dispute resolution procedures. For example, a merchant may retain enough information to provide proof of authentication of the account holder for the purposes of dispute resolution or reimbursement.

Description of configuration and registration The description will now provide additional details to configure the account authentication system for both payment and non-payment transactions. First, the procedures required to configure the various system participants so that they can use the account authentication system will be explained. After the procedure of the account holder to register with the account authentication system will be explained. After these phases are described, explanations of the current authorization for payment transactions will be provided.

The configuration of the account authentication system involves configuring procedures for all participants within the system. The configuration procedures are generally the same for both, the authorization of payment and non-payment transactions. These participants include entities such as merchants or other authentication applicants, financial institutions or other reliable parties, and account holders. Applicants, such as online merchants, who register with the account authentication system receive auxiliary software modules such as the auxiliary software module 182 of Figure 1 and module 134 in Figure 2. The software module Auxiliary should be specific to the computing platform and the server software used by the applicant. Applicants, such as financial institutions, participating within the account authentication system will provide their service logos and their marketing designs to be incorporated into the personalized registration site template. Third parties that are acquiring banks must provide merchants with a root certificate and certification authority of the service organization (CA), an SSL certification of service organization certification authority, and an interrogation support. Before a third party can configure the use of the account authentication system, you must obtain and install a copy of all the authentication system hardware and software of the account specified in the domain of the trusted party. Reliable parties such as issuing financial institutions will also provide identity authentication policies and participate in the bank identification number (BIN) information for the account authentication system to be used in identity verification procedures. of the account holder. Optionally, the issuer can provide the authentication information of the account holder to the authentication system to be pre-loaded into the account holder's file 118. The preload facilitates the support of a large volume of account holders. For example, when the trusted party wants to activate all or most of the account holders for account authentication services, the trusted party can send personal identification numbers (PINs) to all account holders. The PIN number can then be used through each account holder to access their pre-loaded passwords. In this way, the registration procedure is streamlined because each account holder does not need to go through the formal registration procedure. After account holders use their pre-loaded password for the first time, account holders have the option to design and a new and easier to remember password. Authentication of the account holder includes information such as business identification, country code, card account number, card expiration date, account holder name, sender-specific authentication data specified in "Participating BIN" data (for example, mother's maiden name), and other information such as billing address, boarding address, social security number, telephone number, account balance, transaction history, and driver's license number. Reliable parties must also provide scales of account numbers for their card account portfolios and ACS IP addresses (URLs) to the directory server. With respect to payment applications of the account authentication system, the service can be offered through websites marked as banks, which allow the account holder to register. Figure 3 illustrates the procedure by which an account holder registers with the account authentication system according to a modality. As shown in step 1, account holders visit an Internet website of the registry server maintained by a trusted party, for example, at a financial institution issuer. Account holders are registered with the account authentication system through the registration of their account numbers. For example, with payment transactions, an account holder can register the account number of his credit, check, or debit card. With respect to non-payment transactions, an account holder may register an account number controlled by an insurance or stock exchange company. Account holders can register one or more cards. In step 2, the account holder captures the information such as the primary account number (PAN), the name and the expiration date of the card. At this point, the account holder can also capture additional information. For example, address, email address, buyer identification, account verification value, the specific password of the account holder, the specific authentication information of the issuer will also be captured. This information can be captured on a page on the registration website such as page 300 shown in Figure 4. After the account holder has captured the requested information on the registration site 108, the authentication system of Accounts checks if the PAN of the account holder falls within the scale of cards that are registered by the trusted party on the directory server 128 of the interoperability domain 104. The identities of the account holder can be verified using several methods. First, as just mentioned, the identities of the account holder can be verified through an authentication database of the applicant or through the authentication database of the trusted party. Additionally, the verification can be carried out through a file of approved account holders 120 provided by the reliable party, through the transmission of the state check authorizations to the reliable party and through the comparison of the answers with the pre-loaded information provided by financial institutions. If the PAN is not within the scale of registered cards, the registry rejects and the registration process is terminated. In a payment transaction, if the PAN is within the scale of registered cards, an authorization for a dollar (or any other nominal amount) will be submitted through the payment network of the service organization, such as VisaNet, to the issuing financial institution. The authorization of the transaction of one dollar allows the issuer to verify the status of the card account, the address using the Address Verification Service, and the verification value of the account holder 2 (CW2). The CW2 is a three-digit number printed on the signature strip on the back of the payment cards. In a non-payment transaction, a one dollar transaction is not required if the PAN is on the scale of the registered card number. In step 3, the account holder is requested for additional authentication information to verify the identity of the account holder in an online session, in real time, and interactive. In some modalities, the account holder can also be requested to capture a password and a couple of "secret question and answer" that will be used to authenticate the account holder during the authentication transaction. As shown in step 4, when the identity of the account holder is verified and the appropriate responses are returned, an authorization message is sent to the issuing financial institution. Then in step 5, the registration server 112 passes the information of the account holder to ACS 114 to configure the records in the account holder's file 118. The account holder's file 118 can store information such as: the BIN numbers of the financial institution, the account numbers, the due dates, the name and surname, the driving license numbers, the billing addresses, the social security numbers, the passwords of the account holder, the questions for the password and the account holder, the answers for the password of the account holder, the email addresses of the account holder, the identity scores of the applicant and other information. In some modalities, during the registration process the account holder may be questioned to enter a phrase, called personal security message (PAM) that is recognizable as the account holder. PAM is then presented to the account holder through the trusted party during an authentication procedure. Since only the trusted party knows the designated PAM of the account holder, the account holder can be sure that a dialog window used with the account authentication system was distributed from the trusted party. An example of PAM is "the sky is blue." It should be noted that account holders do not require new software or client devices to use the authentication system. In a preferred embodiment, the procedure for registering the account holder uses security protocols such as the coding of the SSL channel to protect the data transmitted over the Internet between the account holder and the registration server. Also, during the registration or registration procedure, each trusted party could display its own "terms of use" and / or "data privacy policy". Each trusted party has the ability to require the registration of account holders to either accept or decline the terms and policies in order to complete the registration procedure. The version numbers of the "terms of use" and / or "private data policy" accepted by each account holder must be saved through the reliable parties.

Description of the transaction payment After all the participants are configured and the account holders are registered, the account authentication is carried out. Figure 5 describes an authenticated payment transaction using the core account authentication system where the account holder uses a computer that is connected to the Internet. In step 1 of Figure 5, an account holder visits a merchant's e-commerce site on the Internet. The account holder can also be referred to as a cardholder since in a payment transaction the most common type of account maintained by an account holder will be some type of credit, debit, or check card account. After the account holder selects the service products you wish to purchase, the account holder initiates the purchase completion process, and then clicks on a "purchase" button. After the "compare" button is selected as shown in step 2 of Figure 5, the MPl is activated and then performs a verification procedure to determine if the holder of the specific account is registered with the authentication system. account. There are several methods through which MPl can determine if the account holder is registered with the account authentication system. For example, a two-step process in the directory server and the ACS associated with the account holder are verified, a procedure in which only the ACS is verified and a method where the merchant can verify its cache containing the same information maintained on the directory server can be used. A description of a two-step procedure will now be provided. Reference will be made to Figure 2 during this description. In the first step, the MPl identifies the card account number and consults the directory 128 server to verify that the card number is within a number scale associated with the issuing bank that is a participant of the account authentication system . If the account number does not fall within the scale of the number of accounts defined in the directory 128 server, then the issuer and, therefore, its account holder are not registered. In this case, the merchant is notified that the account number is not registered and the MPl 134 returns control of the transaction back to the software of the merchant's store. At this point, the merchant's store software can proceed with the transaction, as will normally be done, will reject the additional service of the account holder, and will proceed with alternative payment methods.

On the other hand, if the account number is determined to be within the scale of the account numbers present in the directory server 128, then it initiates the second step of the verification procedure. The second verification step starts when the directory 128 sends the account number to an ACS to determine if the account number is registered. If the card is not registered, the registration procedure is terminated. If the ACS determines that the card is registered, the ACS through the directory server returns its Internet URL address to the MPL. The MPL then invokes the ACS through the client device of the account holder and its resident browser. Again, it is noted that there may be multiple ACSs in the account authentication system. A second verification method to see if the account holder is registered with the account authentication system is for the MPL 134 to directly consult the ACS 114 without first consulting the directory server 128. The third method, as mentioned above is for the merchant to have a cache containing the same information held as on the directory 128 server. In this way, the merchant can at least make a preliminary verification. It should be noted that there could be more than one physical directory server in the account authentication system. However, it is preferable that there is only one logical directory server. In other words, all directory servers must be consistent and contain the same information.

If the account holder is a participant in the account authentication system ACS 114 displays a window marked as bank for the account holder. The window marked as a bank contains the basic payment transaction information and asks the account holder for his or her authentication password or card. See Figure 6 for an illustrative window 500 that asks the account holder for his authentication password. The account holder captures its authentication password and ACS 14 verifies the authentication password. The size and design of the 500 window vary depending on the parameters of the device used by the account holder. As is commonly the case today, the account holder can be given a certain number of attempts to correctly capture the authentication password. If the account holder is unable to incorrectly capture the authentication password, then the account holder can be requested with the secret question that is established during the registration procedure of the account holder.

Preferably, the account holder is given an opportunity to capture and the correct answer in response to the secret question. The authentication of the payment continues if the correct authentication password or card is immediately captured or the account holder provides the correct answer to the secret question. The ACS then proceeds to digitally sign a receipt using the key signature of the issuer or the key of the service provider. This receipt will contain the merchant's number, the card account number, the amount to be paid, and the payment date. In some embodiments, the receipt is a copy of the Payment Authentication Response (PAR) message or a message that has at least some of the information fields copied from the PARes message. The authentication history server 130 stores the following transaction data: on behalf of the merchant, the merchant's URL, the card account number, the due date, the payment amount, the payment date, the signature payment of the issuer and the authentication verification value of the account holder. The ACS then redirects the account holder back to the MPL through the browser of the account holder. At this point, the ACS also passes to the merchant the digitally signed receipt and the determination of whether the account holder has been authenticated. The validation server 136, in the domain of the acquirer 106, is used through MPL 134 to verify the digital signature used to sign the payment receipt. After verifying the digital signature, the account holder is considered as "authenticated". In some modalities, after the transaction is completed, the account holder will also have the ability to re-register their card account and create a new password that will be used for future online purchases. After the account holder is authenticated in step 3, step 4 starts the procedure to authorize the account of the specific account holder. Authorization refers to the process of verifying that an account holder has an adequate credit and has a good reputation for a specific purchase. In contrast, authentication refers to the procedure for verifying the identity of an account holder. In step 4, the merchant uses the MPl to send an authorization message to a payment network such as VisaNet. The payment network, in turn, sends the authorization message and an electronic commerce indicator (ECI) to a issuing 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 issuing financial institution can verify to the merchant that a specific account has a good reputation and has an adequate line of credit for the requested purchase amount of the payment transaction. The ECI indicates that the transaction was completed through the Internet and indicates the level of message security (ie, channel coding (SSL), in clear) and the authentication used. In alternative modes, the merchant is able to provide the additional information along with the authorization message. For example, the following information may also be sent, a flag indicating whether the account holder is successfully authenticated, the account information, the digital signatures, the value of the account holder's verification 2, a dentifier of the transaction, an off-line PIM authenticated through the cryptogram of the Europay, MasterCard, and Visa (EMV) chip card, and the necessary fields to provide the merchant with a guarantee of payment.

After the processing of the issuing financial institution of the authorization transaction is completed, the control of the payment transaction after it is returned to the software of the merchant's store through the payment network. The issuer then becomes the authorization response through the merchant payment network. In step 5 of Figure 5, the issuing financial institution either authorizes or declines the transaction. In some modalities, authorization messages can be formed in batches and sent to a group some time later. Authentication information is also included in the authorization message batch. The identifier of the transaction is created through ACS that authenticates the account holder and is a unique value for a given payment card and a specific payment transaction for that card. Issuers use transaction identifiers to only identify authenticated payment transactions for various purposes such as when a subsequent dispute occurs. Note that the transaction identifier can take many forms of data that are adequate to uniquely identify records such as those related to a specific online transaction. In some implementations, said payment transactions, transaction identifiers are card authentication verification (CAW) values. In the following description, a transaction identifier can be referred to as a CAW, however the level of various types of transaction identifiers can also be used. The access control servers (ACS) 114 are capable of several other functions. For example, the ACS can deactivate registered accounts from the database. Accounts can be deactivated manually, through the account holder, or through the issuer. ACS 114 can also provide a simplified renewal registration procedure when the account holder receives a replacement card. ACS 114 can support multiple users of the same registered account with unique access control information. When a user is provided with a connection to ACS 114 for payment transaction or account updates, ACS 114 can validate the user as an authorized account holder of the registered account through one or more of the following mechanisms: a pass of phrase, digital signatures, an online PIN number, or an offline PIN authentication through the chip card EMV cryptogram. Trader 132 can interoperate with existing systems when the merchant has the account holder's account information on file, interoperates with the existing merchant's authorization and clarification systems, third-party support that provides services to the merchant Multiple, supports a variety of payment interface between the merchant and the acquirer, and minimizes the mandatory impact to the authorization messages of the payment network by the acquirer when the value of the electronic commerce indicator (ECI) is established. One method to route transactions from the merchant to an ACS is to have a directory that provides the address of the server based on the account number of the account holder. In this method, requests to route information are only acceptable from authenticated merchants. When a merchant's activity exceeds normal activity, the account authentication system may deny access to a merchant whose acquirer indicates that access is no longer valid. This could be the case when a merchant fraud is considered probable. The authentication of the merchant for the account authentication system can be used, but the use is not required. Merchant authentication can help minimize fraud by the merchant. Figure 7 illustrates specific messages that are transmitted during a payment transaction using the core account authentication system when a consumer uses a computer that is connected to the Internet according to a modality. The messages of the Figure 7 overlaps the architecture of the payment system as shown in Figure 2. It should be understood that even when the message and the data fields within each of the messages have specific names, these names do not affect the operation of the authentication protocol. Therefore, different names can be assigned to messages and data fields as explained later. Also note that in the alternative embodiments of the invention, the specific messages described in Figure 7 may be altered or omitted and / or additional messages may be added without affecting the overall objectives of the authentication procedure. Multiple messages can be altered, added, or omitted for various purposes such as adding functionality and streamlined communications. Also note that the flow of messages in the procedures described throughout this specification may vary in alternative modes for reasons such as those just described. As described above, the payment transaction starts when an account holder visits a merchant's website through a browser, and selects the items for purchase. The merchant's payment system will ask the account holder to capture their payment information. Generally, the capture of the paid information should occur in a secure environment, for example, through an SSL encryption protocol. When the account holder indicates that he is ready to complete the transaction, the merchant's payment system invokes MPL 134. Then, as shown on line 1A, MPL 134 checks the directory server 128 for a specific URL of the ACS that can Contain the PAM of the account holder to validate the owner of the account that is registered in the service. Alternatively, MPl 134 verifies its own cache containing this information MIP 134 can also verify ASC 114 to verify the PAN of the account holder that is registered in the account's authentication system. In the case where MPl 134 can verify its own cache, MPl I 134 will have the ability to copy the contents of directory 128 into its local cache. If this capacity is used, the merchant can immediately determine from his cache if the account is part of a registered scale. If the merchant implements this capability, the contents of the cache must expire and must be updated for at least 24 hours. The cache should be requested when MPL 134 is loaded and at regular time intervals thereafter. MPL 134 searches for the PAN through the formatting of a Verification of the Registration Request (VEReq) message using the PAN of the account holder. If it is not already established, MPL 134 will establish a secure connection and authenticate itself the directory server 128 or ACS 114. MPL 134 will look for the entry of the scale of the card that corresponds to the PAN of the holder of the account in several places. After MPL 134 leads the search, the message VEReq is transmitted to ACS 114 either directly, as shown by line 1b, or after first passing through directory server 128, as shown in line 1a. When the message VEReq is transmitted to ACS 1 4 through the directory server 128, the directory server 128 searches for a second record corresponding to the PAN of the account holder contained in the VEReq message. In the case of an unsuccessful comparison, the directory server 128 will format a Registration Response Verification (VERes) message without a URL value (s) and will set the State value of the PAN record or the status SEE as "N" . The VERes message is then returned to the MPl. On the other hand, when the match is successful, the directory server 128 will establish, if not already established a secure connection and authenticate itself by the ACS URL. Then, the VEReq message is sent to the ACS URL. If the URL is not available, the MPl must proceed to the next ACS URL value (if available), and allow a maximum of up to 5 ACS URLs to be searched. Of course, the number of URLs attempted is variable. If not successful in all attempts, a message is returned to the MPl with a status of set to "N" to indicate to the merchant that the payment transaction can not be processed using the account authentication system. After the VEReq message is received by ACS 114, the ACS accepts the PAN of the account holder from the VEReq message and validates it against the account holder 118 file. ACS 114 then formats a VERes message. In the case where a successful match occurs, the ACS sets the status of the PAN record as "AND" creates a single-use Proxy PAN, whose ACS 114 will internally be associated with the PAN, and will popularize the URL field (s) in the message VEReq. In the case of an unsuccessful match, the ACS sets the state of the PAN register "N". Then, as illustrated through line 2a, the ACS returns a VERes message back to the MPl through the directory server 128. For the case where a VEReq message is transmitted directly to the ACS, the message VERes is transmitted directly from back to the limit and as shown on line 2b. The caching of the server data of the directory 128 within MPl 134 can be facilitated through the use of a pair of CRReq and CRRes messages. The CRReq message is sent from MPl to the directory server and requests the list of the scales of the participating cards, in order that MPl updates its cache. The CRRes message is the response containing the participating scales. In some modalities, the account authentication system checks to see if the client device of the account holder has distributed authentication capabilities through the use of a couple of messages Consult Account HolderApplication (See Account HolderApplication (QueryAccount holderReq)) and ConsultAccountTituIarResponse (ConsultAccountResponse (QueryAccount holderRes)). The MPl will format and send a query, the QueryAccountholderReq message to the client device of account holder 122 to determine if a module of the account holder of the distributed account authentication is resident. Sending a QueryAccount holderReq message is shown in Figure 7, on line 3. If any of the distributed authentication options are returned in the QueryAccount holderRes message, the MPl will communicate directly with the client's software. client of the account holder to carry out the authentication steps. The sending of the QueryAccount holderRes message is shown in Figure 7 on line 4. Additionally, through the use of the QueryAccount holderReq and QueryAccount holderRes messages, the VEReq and VERES messages described later they will be deleted. The client software of the account holder can be used with the URL of the issuer's ACS embedded in the software. The MPl will first complete the Consult QueryAccount holderReq and QueryAccount holderRes messages. If the client software of the account holder is detected, the PAReq message will be sent to the ACS or to the client software of the account holder without having to drive the VEReq and VERes messages. If the VERES state has a value not equal to "Y", then the merchant is notified that the payment transaction can not be processed using the account authentication system, however if the VERES state has a value of "Y" , then MPL 134 will format a pager authentication request message (PAReq). MPl 134 will send the PAReq message through the browser of the client device of the account holder to the ACS server of the issuer, as shown in line 5. After MPl passes the PAReq message to the issuer's ACS, the ACS displays a window to the account holder. The window displays the payment details contained in the payer's authentication response message (PARes) in addition to other items such as the issuer's logo, the brand of the service organization or the brand's logo, the name of the merchant, the location of the merchant (URL), the amount of the total purchase and currency in circulation, the date of purchase, the card number, the terms of the delivery / recurring payment, the description of the order or the link to the description, the special terms and conditions of the sale or the link to this information, the personal security message (PAM), and request the password of the account holder or any other type of authentication form. The ACS will then request the account holder to capture the appropriate password. The ACS accepts the capture of the account holder and validates it against the account holder's file 118. The account authentication system will allow, for example, a number of unsuccessful inmates (for example, three attempts) to capture the account. correct password Of course, the number of attempts allowed may vary. After the last unsuccessful attempt, the account authentication system can display a secret question. The account holder will need to capture the answer to the correct secret question. The secret question associated with the account holder is then displayed. The account holder is provided with at least one attempt to capture the correct answer. If the account holder provides an incorrect answer, the merchant can notify that a transaction using the account authentication system can not be completed. If the account holder provides the correct answer, the transaction should be treated as if the password had matched. Note that there is more than one entry for an account number, the various names of the account holder are displayed in a sale that slides down. The account holder can then select his name. After the comparison of the password, the ACS generates and digitally signs a PARes message. The ACS also generates and sends a Save Receipt message to the authentication history server 130 and the receipt administrator 131 as shown by line 7. As shown by line 7a, the message Save Receipt (Save Receipt) can also be passed from the authentication history service 130 to the authorization to the issuer authorization and establishment system 138 to allow the issuer to compare the payment authorization request with the authenticated transaction of the payer in real time. The sending of the Save Receipt message to the authorization of the issuer and the establishment system 138 allows the issuer to simultaneously determine if the authorization request is for an authenticated purchase. The ACS will then redirect the signed PARs message back to the MPl as shown by line 6. After the signed PARs message is transmitted back to MPl 134, MPl 134 is reactivated. If the authentication status is a "Y", MPl sends the message PARes to the validation server 136. In the case in which the functions of the validation server are provided by MPl 134, MPl 134 validates the signature of the message PARes and returns the result of the validation of the signature. If the signature can not be validated, MPL 134 will notify the merchant that the transaction can not be processed using the account authentication system. If the status of the authentication is an "N", the merchant must send a request to the account holder asking for additional information, requesting the account holder to use a different card or payment method, or process the payment transaction as a non-authenticated payment transaction.

In the case of the domain of the acquirer 106 containing a validation server 136, it validates the signature of the PARes message. The validation server 136 then returns the result of the validation of the signature to MPl 134. If the signature can not be validated, MPl notifies the merchant that the transaction can not be processed using the account authentication system. On the other hand, if the signature is validated, the merchant proceeds with an authenticated payment authorization. The PARes message can also be passed from the merchant to its acquirer 140 payment processor as shown on line 6a. The PAR message can then be passed from the acquirer through telecommunications networks 142 to the sender. In this way, the results of the payer's authentication are made available to the issuer as part of the standard payment authorization procedure. Now, the security aspects related to the various transmission channels will be explained. As a baseline, all transmission channels are preferably encoded using 128-bit SSL. The channel between the account holder and the merchant includes two channels. The merchant must ensure the connection that is used when the owner of the incoming account, captures the information paid through the use of the SSL certificate content of the certificate authority tested by the service organization. The merchant must also ensure that the connection used to transport the PAR message is from the account holder to the MPl through the use of the SSL certificate obtained from an approved certificate authority of the organization. The channel between the account holder and the ACS should be coded through ACS using an SSL certificate obtained from an approved certificate authority of the service organization. This channel is used for two purposes. First to send the PAReq message from the MPl to the ACS, and secondly to send the PARes message from the ACS to the account holder. The channel between the account holder and the registration server should be encrypted through the registration server using a certificate SSL obtained from an approved certificate authority organization.

This channel is used to accept the registration information of the account holder. The channel between the merchant and the directory server, and between the directory server and the ACS server, must be secured through an SSL encryption certificate issued by the organization in order to protect the PAN data contained in the VEReq and VERes messages. and the ACS URLs contained in the VERes message. The channel between the ACAS and the account holder should be coded to protect the account holder's password request and the password captured by the account holder. This channel should be protected with an SSL certificate obtained from an approved certificate authority of service organizations.

For most payment authentication transaction request message transactions, they include fields that include but are not limited to Message Version Number, Merchant Identifier, Merchant Country Code, Order Number, Purchase Date, Purchase Quantity, Transaction Status of Purchase Terms and Conditions, also, the QueryAccount holderRes 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 Color. These messages can be in the XML (Extensible Markup Language) format. In non-purchase authentication transaction, the payment authentication request, payment authentication response, and QueryAccount holderRes messages may 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 for which an extension is added. These additional elements can be used to further facilitate specific transactions, including payment transactions.

Account Authentication Procedure with the Aggregate Value Component Figure 8 illustrates an illustrative system architecture and establishes the message flows involved with the authentication of online accounts that include a value added aspect. The value-added aspect involves sharing the information collected throughout the authentication procedure of the account with a value-added part. This information refers to the presenter and can be collected through the issuer or the trusted and requesting party. The information of the presenter is evaluated for its high integrity because it serves as the basis for the authentication of the presenter 122. The presenter information can be marked with a transaction identifier, which identifies a specific online transaction and states that the information originated of the authentication procedure of the present invention. Value information can be used through a 196 value-added portion for various purposes related to shipping, sales tracking, security checks, and workflow management, just to name a few. All parties involved can benefit from the sharing of the presenter's information and each party can agree on how they can help each other to earn the benefits, for example, an applicant and a value-added party can agree on additional contractual terms based on in the sharing of presenter information.

The authentication procedure that includes sending the presenter information to a value-added part 196 will be described with reference to Figure 8. Figure 8 will be described based on the payment transactions. After said description, Figure 8 will also be described based on non-payment transactions. Figure 8 depicts the messages of Figure 7 in a simplified form. The architecture of the account authentication system in Figure 8 includes a sender domain 102, an interoperability domain 104, an acquirer domain 106, and a value added domain 107. Sender domain 102 includes a presenter 122, ACS 114, and an emitter 190. The presenter 122 represents the human presenter and the presenting client device, for example, a computer terminate, or a mobile computing device. The issuer 190 represents a card issuing bank that is capable of issuing a payment card for the presenter 122. The interoperability domain 104 includes a Visa 128 directory which in this case is a directory that is controlled by Visa, a history server authentication 30, and VisaNet 194. The domain of the acquirer 106 includes an applicant 132, an MPL 134 and the acquiring bank 192. The requestor 132 may be several party types, however, since the applicant 132 is commonly a merchant the Merchant term can be used in place of applicant. The value-added domain 107 includes a value-added part 196 and a value-added control server 198.

The payment transaction of Figure 8 is described through the directional arrows that are numbered 1-14. The payment transaction starts in step 1 when a presenter browses the merchant's website, adds items that he wants to buy to a shopping cart, and then completes the purchase. At this point, the merchant 132 has the necessary data, which includes the PAN, the expiration date, and the address information, to proceed with the payment transaction. In step 2, a MPl 134 sends the primary account number of the presenter (and the user's device information, if applicable) to the Visa 128 directory server to verify whether the presenter's PAN is registered with the authentication system of the host. account. This procedure occurs after confirmation of the final "buy" by the presenter during the process of completing the merchant's purchases. After the "buy" button is clicked the merchant software invokes MPl 134 to format a Verification Check Request (VEReq) message. MPL 134 determines if you currently have a secure connection to the Visa 128 directory server. If a secure connection has not been established, MPL 134 establishes an SSL connection with the Visa 134. Address server. If the configuration of the Visa directory server indicates that the merchant 32 has issued an SSL client certificate, the server of the Visa 129 directory will require the merchant 132 to present the certificate of SSL client during the establishment of the SSL session. After the secure connection has been established, MPL 134 postulates in VEReq message the directory server Visa 128. It will be observed in several modalities, the confirmation of the "buy" key can be completed using several purchase order confirmation procedures. The VEReq message, along with any other message sent during the authentication procedure, may include an identifier denoting that the online authentication process will also involve sharing the presenter information with a value-added part. In step 3, if the Visa 128 directory server determines that the PAN is on the scale of the participating cards, then the Visa 128 directory server queries an ACS, such as an ACS 114, to determine if the authentication (or test) Authentication attempt) is available for the PAN. This process occurs after the Visa 128 directory server receives the VEReq message from MPL 134. In order for the Visa 128 directory server to verify that the PAN is on the scale of participating cards, the Visa 128 directory server validates the VEReq message syntax and returns an Error if the validation fails. The Visa 128 directory server validates the VEReq message data to ensure that certain requirements have been met. First, the acquirer's BIN must represent a participating acquirer. Second, the merchant's ID must represent a participating merchant of the acquirer identified by the acquirer's BIN. Third, if the acquirer's Visa region requires a merchant password for the account authentication service, then a value for the password must be received and the password must be valid for the combination of the acquirer's BIN and the ID of the acquirer. merchant. If they do not meet any of these requirements, then the Visa 128 directory server formats a Verification Register Response (VERES) that includes an available authentication PAN set to "N" and an invalid request message. Note that this VERes does not contain the data fields of the account identifier, the ASS URL and the payment protocols. After the Director 128 Visa server returns the message SEE to MPL 134, the payment transaction can proceed in a variety of ways. For example, the payment transaction may come to an end, the payment transaction may proceed as an unauthenticated transaction, or the presenter may attempt to use a different account number. The Visa 128 directory server searches for a record by specifying a scale of cards that includes the PAN of the presenter that was received in the VEReq message. If the presenter's PAN is not found, then the server of the Visa 128 directory formats a VERES message that includes a PAN of the available authentication set to "N" and does not include the data fields of the account identifier, the URL ACS, payment protocols, and invalid request. Then the Visa 128 directory server returns the message VERes to MPl 134 and the account authentication again reaches a possible stopping point as will be described later. Assuming the presenter's PAN was found on the Visa 128 directory server, the Visa 128 directory server determines whether it currently has a secure connection to an appropriate ACS. The Visa 128 directory server establishes an SSL connection to the ACS if a secure connection has not yet been established. The SSL client certificate of the Visa 28 directory server and the ACS server certificate must be presented and validated during the establishment of the SSL session. If the first attempt of the URL is not available, each successive URL value (if provided) will be attempted. The Visa 128 directory server can attempt to connect up to four rnative URLs that are optionally configured for each ACS. If the Visa 128 directory server can not connect to the URL in each of its attempts, the Visa 128 directory server formats a VERES message that includes the PAN of the available authentication set to "N" but includes the data fields of the account identifier, ACS URL, payment protocols or invalid request. Then the directory server Visa 128 returns the message VERes to MPL 134 and brings the account to the authentication process to a possible stopping point. After a successful connection is made with URL, the server of the Visa 128 directory removes the password change of the VEReq message and sends the message to the ACS URL. In step 4, ACS 114 determines whether PAN authentication is available and then instructs the server of the Visa 128 directory to determine it. This procedure occurs after ACS receives the VEReq message through the server of the Visa 128 directory. ACS 1 4 validates the VEReq syntax and returns an Error if the validation fails. Note that when it is not possible to authenticate a payment transaction, it is sometimes possible to provide a proof of an authentication attempt instead. ACS 114 uses the presenter PAN from the VEReq message and queries the presenter database located within the ACS 114 to determine if the presenter is registered. If the PAN is not found, ACS 114 formats a VERes message that includes the available authentication PAN set to "N" and does not include the account identifier data fields, the ACS URL, the payment protocols, and the request invalid ACS 114 then sends the VERes message to the server of the Visa 128 directory. In step 5, the Visa 128 directory server sends the decision of the ACS 114 to the MIP 134. From this point of view of the Visa 128 directory server, this The procedure occurs after the Visa 128 directory server sends the VEReq message to the ACS URL. From the point of view of ACS 114, this procedure occurs after ACS 114 sends the message VERes to the server of the Visa 428 directory. The Visa 128 directory server reads the message VERes, which contains the corresponding VERes or Error. The Visa 128 directory server validates the syntax of the VERes message and returns an Error to ACS 114 if the validation fails. If the message received by ACS is syntactically correct, the Visa 128 directory server sends the VERes or error to MPL 134. If the message received from ACS is not syntactically correct, the directory server Visa 128 formats a VERES message that includes a PAN of available authentication set to "N" and that does not include the account identifier, the ASC URL, the payment protocols, or the invalid request. The server of the Visa 128 directory returns the message VERes to the MPL 132 and possibly stops the authentication procedure of the account. From the point of view of MPl 134 this procedure occurs immediately after the MPL 134 postulates the VEReq message on the server of the Visa 128 directory. From the point of view of the Visa 128 directory server, this occurs immediately after the server of the Visa directory sends the message VERes to the MPl. MPl 134 reads the response, which contains the VERes or corresponding error. If an error message is received, the account authentication procedure may be stopped. At points where the authentication of the account possibly reaches its termination for the various reasons mentioned above, the merchant could proceed with a normal payment authorization using the information available from the exit process. In this case, the merchant's payment system must process the transaction as a non-authenticated e-commerce transaction, which is beyond the scope of this document. Note that the electronic commerce indicator should be set to a value corresponding to the authentication results and the characteristics of the exit procedure. If the merchant is unable to process an authenticated transaction using the selected account through the presenter during the exit process, the merchant can either abandon the transaction or give the customer the option to select an alternative account. If an alternative account is selected, the authentication procedure can be repeated. In an alternative mode, the need to consult the Visa directory server to verify the participation of the presenter in the account authentication system for each payment transaction (steps 2-5) can be avoided by copying the content of the server from the server. visa directory in a local cache memory device of the merchant 132. If this capability is used, the merchant 132 can immediately determine from the cache whether the account is part of a registered scale. This alternative technique of using a local cache in the merchant 132 starts when MPl 134 formats a Card Scale Request (CRReq) message and sends it to the Visa 128 directory server. If this is the first time the cache is being loaded ( or if the cache has been cleaned and needs to be reloaded), a serial number element in CRReq is not included, which will result in the Visa 128 directory server returning the full list of the scales of the participating cards. On the contrary, MPL 134 should include the serial number of the CRRes most recently processor, which will result in the Visa directory server only returning the changes from the previous CRRes. A serial number is a value that defines the current state of a card scale database of the Visa 128 directory server. The Visa 128 directory server provides the serial number to the MPL 134. The specific value is only important for the directory server visa that returns it.

The Visa 128 directory server validates the CRReq syntax and returns an error if the validation fails. The Visa 128 directory server formats a Card Scale Response (CRRes) containing the participating scales and is sent by the MPL 134. The Visa 128 directory server includes a serial number in response. MPl 134 must retain this value that will be included in the next day's CRReq message. MPL 134 validates the CRRes syntax and must send an error to the Visa 128 directory server if the validation fails. MPL 134 updates its local cache. The list must be processed in order to return it with the scales being added or eliminated as indicated by the Action element. Note that if CRRes indicates an error condition with respect to the serial number, the MPl must clear its cache and submit the CRReq if a serial number. When authentication is available to the presenter's PAN, MPL 134 sends a Payer Authentication Request (PAReq) message to ACS 114 through the presenter's client device at 122. Step 6 represents the PAReq message being sent to the host. Client 122 host device. This process occurs immediately after MPL 134 receives the VERES message from the Visa 128 directory server. MPL 134 validates the VERes syntax and must send an error to the Visa directory server if the validation fails. MPL 134 formats a PAReq message that includes the identifier of the account received in the VERes. This embodiment of the authentication procedure involves the sharing of the information related to the presenter between merchants 132 and the issuer 190. Each of the sender 190 and the merchant 132 can collect a wide range of information about the presenter through a single or multiple transactions. Such information may include information concerning the presenter's purchasing habits. Such information may be useful for various parties such as the merchant 132, the issuer 190, and value added part 196. Said customer information may be shared between the merchant 132 and the issuer 190 during the authentication procedure through the inclusion of said information within the PAReq and PARes messages. Accordingly, in step 6, the merchant 132 may include within the PAReq message information that relative to the presenter 122. MPl 134 constructs a form for containing the following fields; PAReq .TermUrl, which is the URL of the merchant in which the final answer must be submitted, and the MD field ("Merchant Data"). The MD field contains the merchant's status data that must be returned to the merchant. This field is used to accommodate the different ways in which the merchant's systems handle the state of the session. If the merchant system can associate the final application with the original purchase session without any original assistance, the MD field must be empty. If the merchant system does not control a state for a given purchase assignment, the MD can carry any data the merchant needs to continue the assignment. Since the content of this field varies through the implementation of the merchant, the ACS should be retained without changes and without assumptions about this content. MPl 134 passes the PAReq through the presenter's browser to the ACS URL received in the VERes, causing the presenter's browser to publish the form in the ACS. All connections are HTTPS to accommodate the presenter's browser. Step 7 represents the message PAReq that is being sent to ACS 114 from the client device of the presenter 122. This procedure occurs after ACS 114 receives the publication including PAReq of MPl 134. The following description applies to the case where the authentication The presenter is carried out using a password. Other methods, such as those that are based on applications on a chip card, can be used. ACS 114 validates the PAReq message and returns an error if the validation fails. If the validation fails then ACS 114 formats a PARES message with the status of the transaction set to "N" and an invalid request. In step 8, ACS authenticates the presenter using the processes applicable to PAN. These procedures include techniques such as but not limited to, requesting a password or PIN that is previously established between the sender 190 and the presenter 122 with censorship of data to the presenter. A data censor for example, may involve ACS 114 requesting that the client device of the presenter 122 provide a specific data response that could authenticate for the identity of the presenter or the client device of the presenter. In one scenario, an ACS 114 may request that a client presenter device create a specific cryptogram that could authenticate the presenter 122. Alternatively, ACS 114 may produce a test of the authentication attempt. ACS 114 then formats a PAR message with appropriate values and then applies a digital signature to the response message. ACS 114 validates the password, the data response, or cryptogram against the presenter's database located within ACS. ACS 114 also generates a transaction identifier, such as a CAW for each online transaction. Along with being associated with a specific online transaction, the identifier of the transaction is also associated with client information shared between the merchant 132 and the sender 190. In step 9, ACS 114 returns a PAR message to the presenter's client device 122. The information maintained by the issuer 190 concerning the presenter 122 and the transaction identifier can be sent to the merchant through inclusion within the message PARes. ACS 114 builds a shape containing a PAR and an MD field. ACS 114 passes the signed PAR through the presenter's browser to the merchant's URL (TermUrl in the published form of the MPL), causing the presenter's browser to publish from the MPl. In the procedure, the window that appears is closed and the control is returned to the merchant's browser window.

At this point in time, ACS also sends the selected data to the authentication history server 130. For example, ACS 114 formats a message Authentication Transaction of the Pager (PATransReq) that is sent to the authentication history server 130. The presenter information controlled and / or transferred during the authentication procedure can be stored through each of the merchants 132 and sender 190. Each party can store one. portion or your own complete group of customer information. Alternatively, a portion or all of the client information may be stored within authentication server 130. In step 10, the presenting client device routes the PAR message to MPl 134. In step 11, MPl 134 validates the digital signature placed in the message PARES through ACS 114. The validation of the digital signature can be carried out from ACS 114 itself or by passing the message PARes to a separate validation server. The validation process validates the signature PARes using the Visa Root Certificate. If this is implemented using a separate validation server then MPL 134 sends the PARes to the validation procedure, the validation procedure validates the signature on the PARes using the Visa root certificate, and the validation procedure returns the validation result of sign the MPl.

In step 12, the merchant 132 proceeds with an exchange of authorization with the acquirer 192. In step 13, the merchant 132 uses a certain set of criteria to evaluate the information of the customer that is in his possession. If the customer information group satisfies the criterion, then the customer information and the transaction identifier is sent to the value added part 196. The criterion may revolve around several aspects that will determine whether the value added part 196 wants receive the client's information. This criterion will be described in more detail through the detailed examples of how the authentication procedure operates. In step 14, the value-added part 196 stores the client information and the transaction identifier in a database, such as the value-added control server 198. Step 15 represents communication forward and backward. back between the value-added control server 198 and the authentication history server 130 that takes place for various purposes, such purposes include, for example, concluding a transaction between the merchant 132 and the value-added part 196, the resolution of a dispute and the extraction of data. The following sections of the description will describe in more detail the various value-added modes of the present invention.

Shipping company vs. value-added part The authentication system and procedure shown in Figure 8 will now be described according to a modality where the value-added part 196 is a shipping company ("shipper"), referred to as the shipper 200a. In this mode, the host 122 purchases a product from the merchant 132 that needs to be shipped to the presenter's residence or other mailing address. Information from the presenter or the customer that is sent to the shipper 196 allows the shipper 196 to ship the good to the presenter 122. As described above, the customer information has a high degree of integrity and richness as it originates from of the authentication procedure. Therefore, the value of the information serves as a basis for the trader 132 and the value added part 196 to capture it in a transaction with one another. The scale of these types of transactions can vary greatly. In one instance, the shipper 196 relies on the integrity and richness of the customer information to the extent that the shipper 196 wishes to ship the product at a lower cost to the trader 132 and presenter 122. This may be the case due to that the customer's information states that the presenter has never requested to deliver a package back to the merchant. Additionally, the merchant 132 may also rely on such customer information to the extent that he is comfortable with releasing the shipper 196 from the responsibility or costs involved with a return delivery request through the presenter 122. The authentication procedure and added value starts when the authentication procedure as described through the numbered steps shown in Figure 8. In steps 6 and 7, the merchant 132 can include the customer information that he keeps in his PAReq message that is sent to the transmitter 190. In steps 9 and 10, the issuer 190 may include the customer information that the sender 190 controls in the PAR message that is sent to the merchant 132. The sender 190 also generates a transaction identifier, which is associated with the specific online transaction and customer information. The customer information can be for example: 1) the customer's contact information such as name, mailing address, email address, telephone numbers, and fax numbers; 2) customer payment history, such as the number of payments made by such and the number of default payments; and 3) shipping history, such as preferred shipping methods, boarding numbers made without refund service requests, and the number of shipments on time. The customer information may include any type of information collected through the sender 190 and the merchant 132. Also in step 9, the customer information is stored through one or both of the merchant 132 and the issuer 190. Alternatively, the The customer information is stored in a database such as the authentication history server 130. In step 13, the merchant 132 evaluates the customer information against certain criteria to determine if such information should be sent to the shipper 196. The criterion is formulate in such a way that the customer's information is sent to the shipper 196 if the customer's information indicates that, for example, the shipper 196 can complete his task without difficulty. The help criterion analyzes the risk of the embarkation to a certain client through the examination of the information of the history available in the client. The illustrative criterion includes: 1) Has the customer made more than a certain number of purchase transactions with the merchant? 2) Is the shipping address within a certain country, for example, the United States? 3) Has the customer failed to pay a purchase before? 4) Has the customer requested a shipment return before? 5) Is the client a new customer? 6) Is the transaction at least a certain monetary amount? 7) Was the shipping address checked? and 8) Is the country of delivery a country of low or high risk ?. The trader 132, the shipper 196, or both of the parties can establish the criteria. If the customer's information meets the criteria of the merchant, then the customer information and the transaction identifier is sent to the shipper 196. Since the issuer 190 generates the transaction identifier, the shipper 196 ensures the veracity of the transaction. information. Based on the customer's information, the shipper 196 ships the product to the customer 122 with a certain level of assurance that the shipment will be made without difficulty and therefore without excessive costs. Due to the security provided by the customer information of a problem-free transaction for the shipper 196, the trader 132 and the shipper 196 can provide each other with extra consideration. For example, the shipper 196 may wish to ship the products at a lower cost to the trader 132 and the customer 122. Also, the trader 132 may assume some of the risks of making a shipment for the benefit of the shipper 196 or the trader 132 may partially agree to the 196 shipper for the cost of the vessel. In step 14, the shipper 196 stores the customer information along with the transaction identifier on a value added control server 198. The shipper 196 can ship the products to the customer 122 with the printed transaction identifier on the boarding sticker. Step 15 involves retrieving the transaction identifier along with the associated customer information for various purposes. Such purposes include but are not limited to concluding a transaction between the merchant 132 and the value added part 196, resolving a dispute, and / or extracting data. The identifier of the transaction corresponds to the specific transactions and therefore it is useful to track history of each transaction so that the users 190, the traders 132 and the value added parts 196 can verify the information about each transaction. The present invention can also validate merchants to better protect themselves from buying frauds where a customer could claim that he did not make a certain purchase. The invention can also enable the shipping companies to better protect themselves from fraud shipments where the customer could falsely state that they have received a shipment. The client information can be retrieved from the authentication history server (AHS) 130 in either a "push" or "pull" situation. A "push" situation is one where an event is expected to happen, and therefore the client's information is pushed over the receiver, the value-added part 196. A "pull" situation is one in which the customer's information is pulled through a receiver -only over an event that occurs irregularly . For example, customer information can only be pulled when a dispute arises that requires verification against customer information and transaction identifier stored within AHS 130. Customer information and transaction identifiers can be retrieved to from AHS 130 to complete a transaction. These transactions are based on the sharing of customer information and include additional terms agreed upon by each of the parties. These transactions are referred to as value-added transactions since the customer information serves as the basis for the additional transactions from which the various parties can benefit. For example, a party to a value-added transaction may receive additional business opportunities, receive more competitive costs for goods or services and / or receive more benefits in contractual terms. Some transactions include an agreement on the part of the shipper 196 to ship a product to the trader 132 according to certain terms. Such terms may include a lower shipping cost charged to the merchant 132 and / or the assumption of risk and reliability through the merchant 132. By verifying customer information and transaction identifiers, merchants 132 and shippers 196 can verify that the shipper 196 made certain shipments. Then, for example, a trader 132 could then pay the shipper 196 the charge for discontinued shipment. Recovery of customer information and transaction identifiers to conclude transactions are push transactions when such information is retrieved is a regular procedure for concluding such transactions. Customer information and transaction identifiers are also useful in dispute resolution situations. Disputes may arise between any of the traders 132, customers 122, and a shipper 196. Disputes can be resolved by providing facts about a transaction with the AHS information. When a dispute arises, the client's information and the transaction identifier are "pulled" from places where the information was stored. A dispute between a merchant and a shipper can be related to the fulfillment of a value-added transaction between each of the parties. For example, when a disagreement arises over a payment for shipping services, the trader 132 may use said information to prove that the shipment was made through the shipper 196 with an agreed charge and discontinued shipment. Or when a customer makes a complaint, for example, that a shipment was not received or the merchandise was damaged during shipping, then the shipper 196 can prove that the responsibility for that transaction was assumed by the merchant 132. In some instances, the Responsibility could be assumed by the issuer 190. The customer information and the transaction identifiers can also be used through each of the trader 132, the issuer 190, and the shipper 196 for data extraction purposes. Each of these parties, through their transactions, can gain information about specific customers that can be analyzed to determine their personal characteristics and trends of these clients. Said personal characteristics and trends may be useful for marketing purposes of each of the trader 132, the shipper 196, and the issuer 190. The traders 132 may use information about the personal characteristics of the customer and the trends to determine their sales. future and marketing strategies for a client. The shipper 190 also uses this information for risk analysis, for example, to determine the likelihood of products shipped to a customer without encountering difficulties. And issuers 190 may use such information to determine the level of risk of issuing future accounts to a customer or to determine whether a credit level should be increased. Additionally, the information can be used through any of the parties to determine the characteristics about any other parties. For example, a shipper can determine if entering into agreements with a certain merchant could be a wise business decision. To carry out such an analysis, the customer's information can be analyzed to determine a fraudulent history of the merchant, a history of refunds, common boarding countries for their customers, etc. When such information shows that transactions with specific merchants are usually easy to ship, then a merchant may decide to conduct more business with those merchants. Traders can analyze such data to determine if they want to meet their shipping needs with specific shippers. For example, customer data can show which merchants have a high degree of success and delivery and a ticket score on time. In embodiments where one or both of the merchant 132 and the issuer 190 control the customer information, the customer information and the transaction identifier can be retrieved from each of the respective entities. In an alternative embodiment of the implementation of the shipment of the invention, a merchant 132 may send copies of the customer data and the identifier of a transaction for a specific transaction for multiple shippers. Since the customer data has a high level of integrity thanks to its origin from the authentication procedure, each shipper 196 may be interested in carrying out the shipment for that transaction. Each shipper 196 may be interested because the integrity of the customer's information ensures the authenticity of the information related to the transaction. For example, the boarding address. More importantly, since the customer information is sent to each shipper 196 after passing the merchant's criteria, each shipper 196 is assured of a low probability of encountering problems with the shipped transaction. In an alternative, the shippers 196 will at least know the level of risk involved with the specific transaction. In addition, the shippers 196 may be interested in shipping the product for the transaction because the trader 132 or the issuer 190 have agreed to bear the cost of the risks with the transaction. Having said knowledge about the transaction and the customer, each of the shippers 196 can then place an offer with the merchant 132 for their shipping cost. The trader 132 may therefore select one of the shippers 196 to ship the product.

The resulting merchant as a value-added part In one embodiment of the information sharing and authentication procedure shown in Figure 8, the value-added part 196 is a resulting merchant 196. In this embodiment, the invention can increase the utility opportunities for a resulting merchant 196, and in some cases for a merchant 132 and an issuer 190. The resulting merchant 196 receives the information of the customer and the originator of the transaction from the merchant 132 and uses that information to market his own goods. and services for the customer 122. The resulting merchant 196 can offer any type of goods or services, but these will probably be related in some way to the goods or services sold by the merchant 132. The customer information from the merchant 132 is valuable in which a customer 122 can probably buy something related to the subject of the transaction with the merchant 132. The merchant 132 and the resulting merchant 196 can make several agreements with each other based on the customer's information. This process also starts with the authentication procedure as described with the numbered steps as shown in Figure 8. In steps 6, 7, 9, and 10, the merchant 132 and the resulting merchant 196 share information about the client 122 including said information in the PAReq and PARes messages previously described. Also, the issuer 190 generates an identifier of the transaction, which is associated with the specific online transaction and the customer information. The customer information and the transaction identifier are also stored through each of the issuer 190, the merchant 132, or within an individual database, such as the authentication history server 130. In step 13 , the merchant 132 evaluates the information of the customer to determine if this and the identifier of the transaction should be sent to the resulting merchant 196. Such information of the customer has been related, for example, to the average amount of money the customer spends, the maximum amount that the client spends, when a customer makes the purchases, who the customer prefers to buy, in what the client spends money, the client's sex, and the demographic information near the client. It should be understood that the scale of analysis about the characteristics of the client is extremely large. If the customer's information passes the criterion, then the information is sent to the resulting merchant 196 in step 13. Once the customer information and the transaction identifier are received, in step 14, the resulting merchant stores the customer data and the transaction identifier in its database, such as the value added control server 198. At this time, the resulting merchant 196 can use the customer's information to engage in a marketing strategy that it will focus on the specific client. The customer information can inform the resulting merchant 196 how to customize their marketing strategy for several customers. For example, information about the amount a customer spends on specific transactions will inform the resulting merchant 196 the level of prices for goods or services that the customer 122 may be interested in. Also, the information about the goods or services sold by the merchant 132 informs the resulting merchant 196 of the types of goods or related services that the customer 122 might want to buy. For example, if a customer purchased a CD player from dealer 132, then the resulting merchant 196 could sell certain CDs to customer 122. Such transactions can be referred to as "complementary goods" transactions. Other complementary goods that include, for example, cordless drills and rechargeable batteries, shavers and razor blades, mowers and fertilizers. The receipt of the customer information may be conditioned depending on the resulting merchant agreement 196 to provide the merchant 132 and / or the issuer 190 with the percentage of any resulting merchant sales resulting from the customer's information. Said sales and sales of a similar nature are referred to as, for example, "elaborate sales" and "complementary sales". As can be imagined, the reception of customer information could be conditioned by several agreements between the merchant 132 and the resulting merchant 196. As described above, the customer information is exceptionally valuable to the resulting merchant 196 as it is rich in details and is of high integrity. The customer information is rich in details since one of both the merchant 132 and the issuer 190 has collected it. Each of the merchant 132 and the issuer 190 are in unique positions to obtain certain type of information about the customers. Finally, the client information is of high integrity as it went through the authentication procedure described through steps 1 to 12. Step 15, again involves the retrieval of the transaction identifier along with the associated customer information for several purposes such as to conclude a transaction between the merchant 132 and the resulting merchant 196, the resolution of a dispute, and / or the extraction of data. Step 15 may be required to conclude an agreement between the merchant 132 and the resulting merchant 196 wherein the information about a resulting sale through merchants 196 is verified before sending a percentage of the resulting sale of merchant 132. For example , the customer information and the transaction identifier can be retrieved either through the customer 132 or the resulting merchant 196 to verify that the resulting sale was a result of the customer's information. Then, depending on such verification, a monetary amount is sent to said merchant 132. In this situation, the customer information can be pushed over one or both of the merchants as a regular business course to follow through the agreement or the Customer information can be pushed only when a discrepancy in the needs results. In terms of dispute resolution, the customer information and transaction identifiers are recovered in the event of disputes between any merchant 132, resulting merchants 196, or customers 122. Disputes arise due to agreements between merchant 132 and the merchant. resulting merchant 196 that may have violated. Again, when the merchant 132 agrees to send customer information to the resulting merchant 196, the resulting merchant 196 may be required to share any of the sales that follow from the customer's information. Then, the customer information can be pulled when a dispute arises with respect to a payment that is thanks to the merchant 132 from the resulting merchant 196. The parties can compare the customer's information and the identifiers of the transaction to verify whether certain sales through the resulting merchants 196 were completed based on customer information. Some agreements with respect to customer information may involve the issuer 190 where the issuer 190 may also expect a portion of any sales made by the resulting merchant 196. The customer information may also be used for the purposes of extracting data where each of the issuer 90, the merchant 132 and the resulting merchant 196 can gain knowledge about each other and customers. Your customer information analyzes can inform the parties if future transactions would be favorable to each other.

Several parties as part of value added In alternative forms of authentication of accounts and the value-added system, the parties of various types can take on the role of the client, of the merchant 132, and the part of the added value 196. The role of the client at 122 and from the merchant 132 can be any party that interacts with another online where the merchant 132 requires the authentication of the customer's entity. Many commercial situations can be imagined where the merchant 132 sells some kind of product or service to the customer 122. However, several non-commercial situations can also be imaged. Some situations involve online registration for things such as driver's licenses, fishing licenses, building permits, social security payments, and classroom records at school. It should be understood that those scenarios in which a party (such as the merchant 132) will request the authentication of the other party's identity (such as a customer 122). The criterion evaluated for the identity authentication part, such as merchant 132, can be related to several types of value-added parts 196. The criterion will typically be related if the value added part 196 could wish to receive information about a part, such as client 122, whose identity has been identified by the present invention. The customer information sent in step 13 may be related to each of the different different value-added parts 196. When a customer 122 requests a driver's license, the customer's information may be related to, for example, the registration of the customer. customer management, the car that has been driving, the driving routine, and common destinations. An added value part 196 could be any party that wants to sell a product or service to the customer 122 that is related to the management. For example, the value added part 196 could be a pollution inspection company, a repair shop, or an auto insurance company. In other modalities, the value added part 196 may not sell anything that is related to the management. However, the value added part 196 can still sell a good or service to tooth 122 where he may be interested. For example, the customer information may reveal that the customer 122 handles a certain type of automobile and therefore the customer 122 may be interested in a certain type of good or service. Various types of relationships can be extracted from the customer information and therefore be useful for the value added part 196. When the customer 122 obtains a fishing license, the value added part 196 can be, for example, a fishing equipment store, a travel agency or a clothing store. Again, the 196 value-added part does not need to be a company that is directly related to fishing. The customer information sent to the value added part 196 can relate the customer's preferences with respect to fishing. The criterion evaluated by the trader 122 may determine what kind of fishing equipment the client 122 prefers, what type of fishing is preferred, where the client 122 likes to go fishing, and the type of clothing that the client 122 uses. Customer information can be sent to a value-added party for workflow purposes, too. For example, after the customer 122 requests a building permit or a merchant's license 122, it may be necessary for the customer's information to be sent to another government agency for the next level of approvals. For example, a manager may need to receive customer information in order to set up a safety inspection during the construction of a building. Each of the traders 122 and the value added parts 196 can also capture the value-added relationships with one another based on the sharing of the customer information and the identifiers of the transaction. In some modalities, the merchant 122 can send the customer information and the identifiers of the transaction to multiple value-added parties. Trader 122 can evaluate different or same criteria groups for each value-added part 196. Each value-added part 196 could then proceed to carry out this task either in parallel or in sequence with one another. The value-added parts 196 can execute their respective tasks in real time so that the client 122 receives immediate notification of each value-added part 196 or the tasks can be executed offline. As described above, steps 15 can be used for the various purposes of concluding agreements between any trader 132, part of value added 196, and issuer 190.

Security organizations as value-added parties Some embodiments of the present invention may be used for security purposes, such as for national security. In such modalities, the value added part 196 may be a government agency or any organization in charge of the duty to check the intelligence (data) for security aspects. The merchant 132 can be any commercial, non-commercial, governmental, or non-governmental agency that conducts transactions with tooth 122 online. For example, the merchant can be a company for airline reservations, a hardware store, a chemical supplier, or a school for flight training. Note that some or all of the client's information transmissions can be regulated through laws related to privacy and civil rights. The merchant 132 evaluates the customer's information against the security-related criteria and sends the information along with the transaction identifier to the value added part 196 when they do not meet certain criteria. For example, the criterion can evaluate the items purchased by the customer, license records, travel destinations, frequency of travel, and other security-related issues. Once the customer information and the transaction identifier are received, the value added part 196 can carry out its surveillance tasks. The identifier of the transaction is useful for documenting the client's information so that the security performance review can be tracked precisely, if necessary. This may be necessary, for example, in the case of government-mandated investigations of security protocols. Specifically traders 132 may be required to prove that they have followed the security protocol correctly. In some situations, 132 merchants are responding to judicial situations ordered by the court. The customer information and the transaction identifiers can be pushed or pulled from the rectification history server 130 in step 15. Step 15 can also be used to conclude agreements between the merchant 132, the reporting party and the merchant. value added part 196. For example, the merchant 132 may receive credit or withdrawal to report useful information. This credit received after using the identification of the transaction to prove the source, date and other details regarding the client's information. Case 15 can also be used through several parts to pull data from the history server to authentication 130 for data extracted to security-related issues. Since the customer information is obtained from the sender 190 and the merchant 132, the customer information is probably rich in information since it is of great use for surveillance purposes. In some embodiments, the value added part 196 and the merchant 132 communicate with each other in real time in such a way that the value added part 196 can send messages to the merchant 32 immediately after receiving the customer information. In this way, immediate action can be taken to resolve or avoid undesired situations.

Preferred system network Figure 9 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 from those described below. The network described below is a preferred embodiment of the telecommunications network 126 of Figure 2. The network 800 is a global telecommunications network that supports purchase and cash transactions using any bank card, travel and entertainment cards, and other private label and property cards. The network also supports ATM transactions for other networks, transactions that use paper checks, transactions using smart cards and transactions using other financial instruments. These transactions are processed through network authorization, clarifying and establishing the services. Authorization is when an issuer approves or declines a sales transaction before the purchase is finalized or the cash is dispersed. Clarification is when the transaction is distributed from an acquirer to an issuer to publish the client's account. Settlement is the procedure for calculating and determining the financial position in each member's network for all transactions that are clarified. The current exchange of funds is a separate procedure. Transactions can be authorized, clarified, either as a double message transaction or as an individual message. A double message transaction is sent twice, the first time only with the information necessary for an authorization decision and again afterwards with additional information for clarification and settlement. In the individual message transaction it is sent once for authorization and contains the clarification and settlement information as well. Typically, authorization, clarification and settlement all occur online. The main components of the telecommunications network 800 are exchange centers 802, access points 804, 806 and processing centers 808 and 810. Other entities such as paying banks, and agents authorized by the applicant can also be connected to the network through an access point. An exchange center is a center for data processing that can be located anywhere in the world. In one modality, there are two in the United States and one in the United Kingdom and another in Japan. Each exchange center hosts the computer system that allows the processing of the network transaction. The exchange center serves as the control point for the telecommunication service of the network, which comprises high-speed contracted lines and satellite connections based on the IBM SNA protocol. Preferably, lines 820 and 822 that connect an exchange center to remote entities utilize high bandwidth telephone circuits or satellite connections through the IBM SNA-LUO communication protocol. Messages are sent through these lines using any suitable implementation of the ISO 8583 standard. The access point 804 or 806 is typically a small computer system located in the processing center that interconnects with the host computer of the center and the center of exchange. The access point facilitates the transmission of messages and files between the host and the exchange center that supports the authorization, clarification and settlement of the transaction. Links 826 and 828 are typically local links within a center and use the property message format as preferred by the center. The data processing center (which is located within an acquirer, issuer, or other entity) houses the processing systems that support the location of the merchant and the business and maintains customer data and billing systems. Preferably, each processing center is linked to one or two exchange centers. The processors are connected to the closest exchange, and if the network experiences interruptions, the network automatically routes the transactions to a secondary exchange center. Each exchange center is also linked to all the other exchange centers. This link enables the processing centers to communicate with one another through one or more exchange centers. As well, the processing centers can access the networks of the programs through the exchange center. In addition, the network ensures that all links have multiple backups. The connection of one point of the network to another is not usually a fixed link; rather, the exchange center selects the best possible trajectory at the time of any given transmission. Re-routing about any failed link occurs automatically. Figure 10 illustrates the systems 840 housed within an exchange center to provide on-line and off-line transaction processing. For the transaction of double messages, authorization system 842 provides authorization. The 842 system supports both online and offline functions, and its file includes internal system boxes, a customer database, and the merchant's central file. The online functions of the system 842 support the processing of the authorization of the double message. This processing involves routing, presenter and card verification, and substitute processing, and other functions such as file maintenance. Off-line functions include reporting, billing, generation of recovery bulletins. The reports include authorization reports, the exception file and notices of file reports, POS reports and billing reports. A bridge from system 842 to system 846 makes it possible for members to use system 842 to communicate with members using system 846 and access the SMS gateways to external networks. The clarification and settlement system 844 clarifies and consolidates previously authorized double message transactions. By operating 6 days a week in a global basic system 844, the financial and non-financial information is collected and reports distributed among the members. This also calculates quotas, charges, and settlement totals and produces reports to help reconciliation. A bridge forms an exchange between the processing centers of the system 844 and the processing centers of the system 846. The system of individual messages 846 processes the complete financial transactions. The 846 system can also process authorization and clarification transactions for dual messages, and communicates with the 842 system using a bridge and access to external networks as required. The 846 system processes Visa, Plus Interlink transactions, and other cards. SMS files include internal system boxes that control the access and processing of the system and the presenter's database, which contains files of the presenter data used for PIN verification and auxiliary processing authorization. The online 846 system functions to carry out the processing of the presenter transaction in real time and the processing of the exception for authorization as well as full financial transactions. The 846 system also accumulates reconciliation and settlement totals. The functions of the 846 off-line system process the settlement and fund transfer requests and provide the settlement report and activities. The 848 settlement service consolidates the settlement functions of the 844 and 846 systems, including Interlink, in an individual service for all products and services. The clarification continues to be carried out separately through the system 844 and the system 846. Figure 11 illustrates another view of the components of the telecommunications network 800. The integrated payment system 850 is the main system for processing all authorization transactions in line and financial application. The 850 system reports the processing of both individual and double messages. In both cases, the settlement occurs separately. The three main software components are the function of the common interface 852, the authorization system 842 and a system of individual messages 846. The function of the common interface 852 determines the processing required for each message received in an exchange center. Select the appropriate routing, based on the source of! message (system 842, 844 or 846), the type of processing request and the processing network. This component carries out the editing of the initial message, and, when necessary, analyzes the message and makes sure that the content compiles the construction rules of the basic message. The 852 function routes the message to your 842 system or to the 846 system destinations.

Modality of the computer system Figures 12A and 12B illustrate a computer system 900 suitable for implementing embodiments of the present invention. Figure 12A shows a possible physical form of the computer system. Of course, the computer system can have many physical forms on the scale of from an integrated circuit, a printed circuit board, and a small portable device to a supercomputer. The computer system 900 includes a monitor 902, a screen 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 the computer system 900. Figure 12B is an example of a block diagram for the 900 computer system. Annexed to the 920 system controller there are a variety of subsystems. The processor (s) 922 (also referred to as central processing units, or CPUs) are coupled to the storage devices including memory 924. The memory 924 includes random access memory (RAM) and read-only memory ( ROM). As is well known in the art, ROM acts to transfer and instructions unidirectionally to the CPU and RAM is typically used to transfer data and instructions in a bidirectional manner. Both of these types of memories can include any suitable computer readable medium described below. A fixed disk 926 is also bidirectionally coupled to the CPU 922; provides additional data storage capacity and may also include any other computer readable media described below. The fixed disk 926 can 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 the fixed disk 926 may, in appropriate cases, be incorporated into a standard form as a virtual memory in the memory 924. The removable disk 914 may take the form of any computer readable medium as described further ahead. The CPU 922 is also coupled to a variety of input / output devices such as a display 904, a keyboard 910, a mouse 912, and the speakers 930. In general, the input / output device can be any of: video, seguibolas, mice, keyboards, microphones, touch-sensitive screens, transducer card readers, paper magnetic tape readers, tablet computers, styluses, voice and handwriting recognizers, biometric readers, or other computers. The CPU 922 can optionally be coupled to another computer or telecommunications network using the network interface 940. With said network interface, it is contemplated that the CPU can receive information from the network, or it can output the information to the network in the course of operation of the steps of the method described above. In addition, the embodiments of the method of the present invention can be executed only on the CPU 922 or can be executed through the network such as the Internet in conjunction with a remote CPU that shares a portion of the processing. In addition, the embodiments of the present invention further relate to computer storage products with computer-readable media having a computer code and for carrying out various operations implemented by the computer. The means and the 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 with experience in computer software techniques. Examples of computer readable media include, but are not limited to: magnetic media such as hard drives, floppy disks, and magnetic tapes; optical media such as CD-ROMs and holographic devices. Magneto-optical media such as floppy disks; and hardware devices that are specially configured to store and execute the program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), and ROM and RAM devices. Examples of computer code include the code of the machine, as it is produced through a compiler, and files that contain code of higher levels that are executed through a computer using an interpreter. Since the invention has been described in terms of several preferred embodiments, there are alterations, permutations and equivalents that fall within the scope of this invention. It should be noted that there are many alternative ways of implementing the methods and apparatus of the present invention. Accordingly, it is intended that the following appended claims be construed as including all such alterations, permutations and equivalents that fall within the true spirit and scope of the present invention.

Claims (2)

1. NOVELTY OF THE INVENTION CLAIMS . 1.- A method for a value-added party to interact with an online authentication system where the identity of the presenter is authenticated during an online transaction through the trusted party, said method comprises: receiving an authentication password from identity of said presenter; comparing said identity authentication password against a password previously designated for an account of said presenter; notify an applicant that said presenter is the current owner of said account when said identity authentication password received from said presenter matches the password previously designated for said account, while said reliable party authenticates for said applicant's benefit said presenter is the current owner of said account; and send the presenter's information to that added value party.
2. 2. The method according to claim 1, further characterized in that it comprises: evaluating said information of the presenter against a group of criteria and sending said information from the presenter to said added-value part if said presenter information satisfies said group of criteria . 3. - The method according to one of the claims 1-2, further characterized in that it further comprises: sending a payment authentication request message from said requester to said trusted party to request said trusted party to authenticate said identity of said presenter. 4. The method according to claim 3, further characterized in that said request message for the authentication of the payment includes the presenter information maintained by said applicant. 5. The method according to claim 4, further characterized in that it further comprises: sending said payment authentication response message from said trusted party to said requestor. 6. The method according to claim 5, further characterized in that said payment authentication response message includes the presenter information maintained by the trusted party. 7. The method according to claim 6, further characterized by additionally comprising: generating an identifier of the transaction through said trusted party where said transaction identifier is associated with said online transaction and with said presenter information that was sent to that part of added value. 8. - The method according to claim 2, further characterized in that said presenter information includes the information describing the main topic of the online transaction. 9. The method according to claim 8, further characterized in that said information of the presenter also includes the information of the behavior of the purchase about said presenter. 10. The method according to claim 2, further characterized by additionally comprising: agreeing on a group of rights and obligations through each of said applicant and said value-added part as a condition before the operation of the The presenter's information is sent to that added value party. 11. The method according to claim 10, further characterized in that it further comprises: transferring a monetary value to said applicant of said added value portion in exchange for said information of the presenter. The method according to claim 9, further characterized by additionally comprising: sending the related information, through said added value part, which is related to the presenter information of said presenter. 13. The method according to claim 7, further characterized in that it further comprises: sending a copy of said payment authentication response message and said transaction identifier to a history server for storage. 14. The method according to claim 13, further characterized in that it further comprises: recovering a copy of said payment authentication response message and said transaction identifier from said history server; and verify the identifier of the transaction to audit the value-added transaction between said applicant and said value-added part. 15. The method according to claim 14, further characterized in that a copy of said payment authentication response message and said transaction identifier is retrieved through said value added part for dispute resolution purposes that also comprise: sending said copy of the payment authentication response message and the transaction identifier to said applicant in order to resolve a dispute. 16. The method according to claim 13, further characterized in that it additionally comprises: recovering a copy of said message from the payment authentication response and said transaction identifier of said history server; and analyzing said presenter information for data extraction purposes. 17. The method according to one of claims 1, 2, or 4-16, further characterized in that said reliable party is a financial institution. 18. - The method according to one of claims 1, 2 or 4-16, further characterized in that said reliable party maintains said account of said client. 19.- A method for a shipper to interact with an online authentication system where the identity of the customer is authenticated during the online transaction through a reliable party, this method includes: receiving an identity authentication password. part of said client; comparing said authentication and identity password against a password previously designated for said client's account; notify the applicant that said consumer is the current owner of said account when said identity authentication password of said client matches the password previously designated for said account, while the reliable party authenticates for the benefit of the applicant that said customer is the current owner of said account; send the customer information to the shipper; and ship a product purchased from said customer. 20. The method according to claim 19, further characterized by additionally comprising: evaluating the Nformation of the customer against a set of criteria and send the customer information to the shipper if said customer information satisfies the group of criteria. 21. - The method according to claim 20, further characterized in that the customer information includes a mail address. 22. The method according to claim 19, further characterized by additionally comprising: obtaining the customer information from said applicant and said reliable party. 23. The method according to one of the claims 19-22, further characterized by additionally comprising: sending a payment authentication request message from said requester to said trusted party to request the reliable party to authenticate the identity of the consumer. 24. The method according to claim 23, further characterized in that said payment authentication request message includes the customer information maintained by the applicant. The method according to claim 23, further characterized in that it further comprises: sending a payment authentication response message from said trusted party to said requestor. 26. The method according to claim 25, further characterized in that said payment authentication response message includes the information of the client controlled by the trusted party. The method according to claim 25, further characterized in that it additionally comprises: generating a transaction identifier through said trusted party where the identifier of the transaction is associated with said transaction online and with said customer information that It is sent to the shipper. 28. The method according to claim 27, further characterized in that the boarding operation is carried out through the shipper only if the shipper receives the identifier of the transaction. 29. The method according to claim 28, further characterized by additionally comprising: agreeing on a group of rights and obligations through each of the applicant and the shipper as a condition before the operation of sending the presenter information to said shipper. 30. The method according to claim 28, further characterized by additionally comprising: generating a bill of lading at a discount price when the shipper receives the customer information and the identifier of the transaction. The method according to claim 27, further characterized in that it further comprises: sending a copy of said payment authentication response message and said transaction identifier to the history server for storage. 32. The method according to claim 31, further characterized in that it additionally comprises: recovering a copy of said payment authentication response message and said transaction identifier from the history server; and verify the identifier of the transaction to audit a transaction between the applicant and the shipper. 33. The method according to one of claims 19-22 or 24-32, further characterized in that said reliable party is a financial institution. 34.- The method according to one of the claims 19-22 or 24-32, further characterized because said reliable party maintains the account of said client. 35.- The method according to one of the claims 19-22 or 24-32, further characterized in that it further comprises: generating a transaction identifier through said trusted party wherein the identifier of the transaction is associated with the online transaction and with the customer information; send the information and the identifier of the transaction to a plurality of shippers; receive a fee for the boarding price of at least one of said shippers; and selecting a shipper to ship said product purchased based on the price quotas. 36.- A method for a security organization to interact with an online authentication system where the identity of the presenter is authenticated during the online transaction through the trusted party, this method includes: receiving an authentication password from identity by said presenter; compare the identity authentication password against a password previously designated for an account of said presenter; notify the applicant that said presenter is the current owner of said account when the identity authentication password received from the presenter matches the password previously designated for said account, while said reliable party authenticates for the benefit of said applicant that said presenter is the owner current account; and send an information from the presenter to the security organization. 37.- The method according to claim 36, further characterized by additionally comprising: evaluating the presenter information against a group of criteria and sending the presenter information to the security organization if said presenter information satisfies the group of criteria , where the group of criteria determines when there is a concern regarding safety. 38.- The method according to claim 36, further characterized in that it additionally comprises: sending a payment authentication request message from said applicant to said trusted party to request the reliable party to authenticate the identity of the presenter. 39.- The method according to claim 38, further characterized in that the message of request and authentication of payment include the information of the presenter maintained by the applicant. 40. - The method according to claim 39, further characterized in that it further comprises: sending a payment authentication response message from said trusted party to said requestor. 41. The method according to claim 40, further characterized in that said payment authentication response message includes the information of the presenter maintained by the trusted party. 42. The method according to claim 41, further characterized in that it further comprises: generating a transaction identifier through said trusted party where the identifier of the transaction is associated with the online transaction and with the information of said transaction. presenter who is sent to the security organization. 43.- The method according to claim 37, further characterized in that the presenter information includes information describing at least one main topic of the online transaction. 44. The method according to claim 43, further characterized in that the information of the presenter also includes the information of the behavior of the purchases about the presenter. 45. The method according to claim 43, further characterized in that it further comprises: carrying out a security check on said presenter, through the security organization, in response to the receipt of said information from! presenter. 46.- The method according to claim 41, further characterized by additionally comprising: sending a copy of said payment authentication response message and the transaction identifier to a history server for storage. 47. The method according to claim 41, further characterized in that it additionally comprises: recovering a copy of the payment authentication response message and the transaction identifier of said history server; and analyze the information of the presenter to show the security problems. 48. The method according to claim 37, further characterized by additionally comprising: agreeing on a group of rights and obligations through each of the applicant and the security organization as a condition prior to the operation of sending the information from the presenter to said security organization. 49. The method according to claim 47, further characterized in that a copy of said payment authentication response message and said transaction identifier is retrieved by the security organization for purposes of dispute resolution which further comprises: sending a copy of the authentication response message and the transaction identifier to the applicant or security organization in order to resolve a dispute. 50. - The method according to one of claims 36-49, further characterized because the reliable party is a financial institution. 51. The method according to one of claims 36-49, further characterized in that said reliable party maintains said account of said client. 52. A method to provide high integrity presenter information to the value added party in the course of an online transaction between an individual presenter and a requesting party, said method comprising: collecting the presenter's information pertaining to the presenter during the course of such online transaction, the presenter's information is collected through the requesting party or through the trusted party; receiving, through the trusted party, an online requesting authentication message from the requesting party to authenticate the identity of the presenter during the online transaction; receive, through the reliable party during the online transaction, an identity authentication card of said presenter; compare the identity authentication card against a card previously designated for said presenter during the online transaction; sending an online authentication response message from said trusted party to the requesting party during said online transaction notifying the requester that said presenter is authenticated when said identity authentication token matches the token previously designated for said presenter; and sending said information from the presenter collected from said requesting party to the value added party. 53. The method according to claim 52, further characterized in that it further comprises: evaluating, through the requesting party, the information of the presenter against a group of criteria; and sending the presenter information to the value-added part when it is determined that the presenter information satisfies a group of criteria. 54.- The method according to claim 52, further characterized by additionally comprising: collecting the presenter information through the course of multiple line transactions through the presenter, wherein the presenter's information represents the activity through the presenter through multiple transactions. The method according to claim 52, further characterized in that it additionally comprises: said added value part, a specific action related to the presenter based and partly on the presenter information. 56. The method according to claim 52, further characterized in that a portion of said presenter information is included within the authentication response message. The method according to claim 52, further characterized in that said trusted party is an issuer that maintains an account of said presenter, said method further comprising: verifying, through the issuer during the registration process, the identity of the presenter as the owner of said account, and associate the previously designated record with said account. 58. The method according to claim 52, further characterized in that it further comprises: generating a transaction identifier identifying the transaction online; and said transaction identifier includes said presenter information that is sent to the value added party, while said transaction identifier associates the information of the presenter with a particular transaction. 59. The method according to claim 58, further characterized by additionally comprising: sending the information and the identifier of the transaction to a history server for storage; recover the information of the presenter and said identifier of the transaction from the history server; and using said recovered presenter information and said transaction identifier to conclude a transaction between the requesting party and said value-added party. The method according to claim 58, further characterized in that it further comprises: sending said information from the presenter to said transaction identifier to a history server for storage; retrieve the presenter information and the transaction identifier from said history server; and using said information from the recovered presenter and said transaction identifier to carry out the resolution of a dispute or to carry out the data extraction. 61.- The method according to claim 52, further characterized in that the information of the presenter includes describing the information of the main topic of the online transaction. 62. The method according to claim 52, further characterized in that said information of the presenter includes the information of the behavior of the purchase relative to the presenter. 63. The method according to claim 52, further characterized by additionally comprising: said applicant and said value-added part agree a rights and obligations group before the step of sending the information of the presenter to said value-added party. The method according to claim 63, further characterized in that it additionally comprises: transferring a monetary value to said applicant from the value-added part in exchange for said information of the presenter. The method according to claim 52, further characterized in that said value-added part is a shipping company, a resulting merchant or a security organization. The method according to claim 52, further characterized in that it comprises: sending said information from the collected presenter to a plurality of value-added parts; receive a fee for the service related to said presenter from at least one of said value-added parts; and selecting one of said value-added parts based on at least the quota received. 67.- A system for authentication that provides High Integrity presenter information to a value-added party in the course of an online transaction between an individual presenter and a requesting party, said system comprising: a computer device of a presenter , said presenter provides the presenter's information during the course of the online transaction to said requesting party or to the reliable party; a server computer of the requesting party of said requesting party configured to conduct said transaction in line with said computing device of said presenter, the requesting party's computer configured to send an online authentication request message to the trusted party requesting the authentication of the identity of the presenter; a server for access control of said trusted party configured to receive an identity authentication token from said presenter, said access control server being further configured to compare the identity authentication token against the token previously designated for the presenter and for sending an online authentication response message to said requesting party and indicating that said presenter is authenticated; a server computer of a value-added part configured to receive the presenter's information from the requesting party. 68.- The system according to claim 67, further characterized in that a portion of the information of the presenter is included within said authentication response message. 69.- The system according to claim 67, further characterized by additionally comprising: a transaction identifier identifying the online transaction, said transaction identifier is included with the presenter information that is sent to the value added party, while the transaction identifier associates the presenter's information with a particular transaction. The system according to claim 69, further characterized in that it additionally comprises: a history server to which the information of the presenter and the identifier of the transaction for storage is sent. 71.- The system according to claim 67, further characterized in that the information of the presenter includes the description of the information of the main topic of the online transaction. 72. The system according to claim 67, further characterized in that the information of the presenter includes the information of the behavior of the account relative to said presenter. 73. - The system according to claim 67, further characterized in that said value-added part is a shipping company, a resulting merchant or a security organization. The system according to claim 67, further characterized in that it additionally comprises: a plurality of value-added parts; and a plurality of server computer to each of which the presenter information is sent, each server computer is associated with one of said value-added parts. The system according to claim 67, further characterized in that said computing device of the presenter is a computer, a PDA or a mobile telephone.