"method and system"

专利摘要:
METHOD AND SYSTEMA transaction authentication system based on a password generating medium is disclosed. Issuer, merchants and a payment processing network generate password generating means or unique keys to authenticate messages between them and to authenticate a sending or consumer entity as they are redirected between the entities. Password generating means are also used to identify the particular line of authentication with which a message or sending entity is associated. Authentication of the sending entity takes place on a network based channel or on a mobile based channel.
公开号:BR112012017880A2
申请号:R112012017880-6
申请日:2011-01-19
公开日:2020-11-17
发明作者:Mike Lindelsee；Olivier Brand；James Dimmick；Benedicto Dominguez
申请人:Visa International Service Association；
IPC主号:

专利说明:

"METHOD, AND, SYSTEM"
CROSS REFERENCES TO RELATED APPLICATIONS This non-provisional application claims benefit under 35 U.S.C. § 119 (e) of US Provisional Patent Application 61 / 296,385, entitled 5 "PROTOCOL FOR ACCESS CONTROL SERVER", filed on 19
V January 2010, whose full disclosure is hereby incorporated by reference '4 in its entirety for all purposes.
BACKGROUND OF THE INVENTION Online and mobile payments often have a higher risk level because a payment card cannot be physically presented to a merchant. Different types of transactions, such as mobile payments or money transfers, may require more interaction between issuers, merchants, payment processing networks and shipping entities, which introduces additional risk. To reduce the risk involved with various types of transactions, shipping entities can be authenticated by an issuer. However, authentication of the sending entity may require that the sending entity be redirected between a merchant and an issuer, and may involve verification of messages sent between multiple entities. , 20 The confirmed authentication process between multiple entities with multiple redirects exposes the system to injection attacks, in which malicious parties can pretend to be a valid entity to collect sensitive data, intercept a transaction or otherwise disrupt the transaction or compromise data security. The merchant, the issuer and the payment processing network can also process multiple transactions simultaneously, potentially with each other, and thus may need to + clearly identify a sending entity and messages received in the context of a specific instance of a authentication process.
Thus, there is a need in technology for a transaction authentication system based on a password generating medium that addresses the concerns raised. Modalities of the invention address these and other problems, individually and collectively.
SUMMARY OF THE INVENTION 5 Modalities of the invention disclosed herein include systems, "technical systems architecture and methods for an authentication system
W transaction based on password generating medium. A transaction authentication system based on a password generator can be implemented using one or more computer devices and databases. One embodiment of the invention is directed to a method for sending a message comprising a first payment reference identifier to a merchant, receiving, from the merchant, a second payment reference identifier, a consumer payment nickname and a merchant key, determine whether the second payment reference identifier matches the first payment reference identifier, analyze the consumer's payment nickname to determine a issuer, communicate to the issuer a message comprising the first payment reference identifier , the merchant's key and the consumer's payment nickname, 20 receive from the issuer an authentication address, an issuer key and a third payment reference identifier, and determine whether the third payment reference identifier payment corresponds to the first payment reference identifier.
Another embodiment of the invention is directed to a method 25 for sending the authentication address, the sender's key, the merchant's key and the first payment reference identifier to the merchant, where the merchant sends the authentication address, the key of the issuer, the merchant key and the first payment reference identifier to a sending entity and redirects the sending entity to the authentication address, where the sending entity authenticates with the issuer by providing the sender's key and a pass code, in which the sender detects the sender's key received from the sending entity c-orrespond.e and the e-sender's key that the sender sent, and in which, after the sending entity is redirected to the merchant with the first "payment reference identifier, the sending entity authenticates with the% merchant by providing the merchant key, and where the merchant determines whether the merchant key received from the sending entity corresponds to the merchant key sent by the merchant. Another fashion of the invention is directed to a method for receiving a merchant key from a merchant and an issuer key from an issuer and generating a payment reference identifier, sending it to the merchant an. message comprising the merchant key, the issuer key and the payment reference identifier, where the merchant sends the merchant key, the issuer key and the payment reference identifier to the sending entity and redirects the entity of sending to the issuer, in which the sending entity authenticates with the issuer by providing the issuer's key and, subsequently, the issuer redire.ciones the sending entity to the merchant, in which the sending entity authenticates with the merchant the provision of the merchant's key.
BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a transaction authentication system based on a password generating means according to an exemplary modality. Figure 2 is a more detailed block diagram of a transaction authentication system based on a password generator in accordance with an exemplary embodiment. Figure 3 is a process flow of an Internet-based authentication process according to an exemplary embodiment.
Fig. 4 is a process flow of an authentication process based on a cell phone according to an exemplary embodiment. Figure 5 is a diagram of a computer apparatus of 5 according to an exemplary embodiment.
"DETAILED DESCRIPTION 4 Modalities of the invention are directed to systems, system architectures and methods that conduct transaction authentication based on a password generating medium.
10 In certain modalities, the password-based transaction authentication system authenticates transactions and money transfers. As a sending entity is redirected between a merchant, an issuer and a payment processing network, during an authentication process, and as these entities communicate with each other to authenticate the sending entity and to verify authentication, password generating means or unique keys are generated by the payment processing network, the merchant and the issuer to authenticate the sending entity, messages between the entities, and to identify an authentication thread. As used here, a "20 authentication thread" can represent a particular instantiation of an authentication process.
In the following description, reference is made to a "merchant".
A trader can be an exeniplo of a "paiticipante". Other examples of participants can include entities that receive information from a sending entity, such as a code name or other identification information. These entities can retrieve information from the payment instrument that is currently stored or that is acquired by consulting a payment processing network. A participant can send and receive information from the consumer's portable device from the sending entity, and can operatively communicate with a merchant.
In the following description, reference is made to an "issuer". An issuer can be an example of an "authorization entity". An authorization entity can be an entity that can authorize a money transfer transaction.
Other examples of an * authorization entity may include entities that manage or host the sending entity's accounts, such as an 'online value storage account provider, a bank or a money transfer service.
The authentication process can support, and can precede, 10 transactions conducted between the shipping entity, such as a consumer, and the merchant, where the shipping entity uses a portable device from the consumer to send links to the dealer.
A "consumer portable device" can be a credit card, a debit card, a cell phone, a prepaid card, a mobile application, a payment device, or any portable device or software application capable of consolidating funds transfer.
For example, fund transfers can take place from an account associated with the sending entity's credit card "t" to the merchant's merchant bank account, and may require authorization from the issuer of the transaction.
Examples of such 20 fund transfers may include the use of a credit card for purchases with "an online merchant.
The transaction authentication system based on a password generating medium can also support, and can precede money transfer between, consumer portable devices.
In an exemplary form, a money transfer is a transaction that transfers funds from an account. associated with a consumer portable device to another account associated with another consumer portable device.
In an exemplary form, a cash transfer can transfer funds from one credit account to another credit account.
In another embodiment, accounts can be associated with a mobile device, such as a cell phone or smart card. In an exemplary form, accounts can be associated with a payment processing network and / or guaranteed by issuing entities or banks. 5 In an exemplary mode, the authentication process of the sending entity can use an authentication channel based on Intemet, in which payment and authentication information is communicated through Intemet. In an additional modality, the sending entity's authentication process can use an authentication channel based on a cell phone, in which payment and authentication information is sent through a mobile device communication protocol, such as such as SMS, mobile application, Intemet mobile or USSD2.
The transaction authentication system based on the master generating means can facilitate the authentication of the sending entities 15 involved in the transactions and money transfer. In an exemplary modality, portable consumer devices can be associated with sensitive information, such as a credit card expiration date, a CW2 or a primary account number ("PAN"), also referring to a permanent account number or to a personal account number. In an exemplary embodiment, codenames, also known as "consumer identity codenames" ("CIA"), can be used to identify a sending entity to preserve privacy and reduce the likelihood of Kaude associated with sharing sensitive information. In an exemplary embodiment, a codename can be an alphanumeric value, such as a user name. In an additional embodiment, a codename can be a verifiable value, such as a phone number or an email address. For example, a money transfer transaction can send money to the code name "ted@ted.com" instead of a credit card or bank account number. A "consumer payment nickname" ("CPN") can be used to identify consumer devices. A CPN can be a nickname defined by the sending entity, such as "My Green Card", "My Yellow Card", etc. A CPN can include any combination of filters, numbers and characters, it can be an alphanumeric string, a password generating medium, or it can be static or dynamic. The CPN can be used to identify a portable device
CONSLINER n · d and to protect the identification of PAN data. For example, CPN data can be shared with a merchant when a sending entity does not want PAN data to be exposed. In an exemplary embodiment, certain ANCs can be authenticated only through certain authentication channels. For example, there may be a CPN that can be authenticated through Intemet, but not through a cell phone.
The password-based transaction authentication system may comprise a sending entity, a merchant, a payment processing network and an issuer. In an exemplary way, the sending entity can communicate through an Intemet entity and a mobile entity. In an exemplary modality, a. sending entity initiates a transaction with the merchant. The sending entity may co-communicate with the merchant through an Intemet-based channel, 20 mobile channel or another co-communication channel. For example, a shipping entity may initiate a transaction on a merchant's Intemet page.
The sending entity can identify itself by providing the merchant with a consumer identity code. The merchant can then consult the payment processing network to verify that the CIA is valid and that it is associated with a consumer device. The paganient.o processing network can respond to the merchant's query by searching for the CIA and by returning a list of CPNs associated with the CIA, the CPNs representing the consumer's portable devices that the sending entity may be able to use to pay for the merchant's goods. In an exemplary way, the sending entity has registered the CIA with the payment processing network, and the registration information is accessible through the payment processing network. A CIA can be associated. with one or more CPNs. The payment processing network can also analyze the list of CPNs and resume only those CPNs that can be authenticated and through the authentication channel used by the sending entity to initiate the
F trms. The payment processing network can also send a payment reference identifier (a "PRID") to the merchant. As used herein, a "10 payment reference identifier" can include any combination of letters, numbers and characters, can be an alphanumeric string, a password generating medium, or can be static or dynamic. The PRID can identify a particular transaction that the sending entity is initiating and can be generated by the payment processing network. In an exemplary modality, a PRID is exclusive over a period of ten years, and is generated using a random or pseudo-random process. In an exemplary embodiment, the PRID comprises a time recording component, a numerical sequence component and a dispersion component. The time recording component can identify the time to the nearest 100th second. The number sequence component can be a short integer to identify the state stage of a particular transaction. The dispersion component can be a dispersion of the time stamp and number sequence, or another part of the PRID, to confirm that the message has been
Ü sent by a legitimate party to a reasonable degree. 25 The PRJD can be passed between the sending entity, the merchant, the payment processing network and the issuer to identify a particular authentication thread. Because the merchant, the issuer and the payment processing network may be processing multiple authentications simultaneously, a PRID can identify a specific authentication thread. As used here, an "authentication thread" identifies a specific instance of an authentication process for a particular transaction. For example, a PRID can identify that one. message or request in particular is for a 5-thread authentication in paiicular that started at time X, with the
Commender Y, from sending entity Z, etc. An authentication thread can also identify a particular stage or eni state of a transaction, for example, that a transaction is at the stage where a sending entity must authenticate directly with an issuer. This can assist you when the sending entity, the merchant, the payment processing network and the issuer are engaged in multiple simultaneous transactions. The use of a PRID also defends against injection attacks, as it will be unlikely that nialicious entities will determine the value of PRID. The payment processing network can store and remember the PRID value and match it to the authentication thread.
If more than one CPN is associated with the provided CIA, the merchant can submit the list of CPNs to the sending entity. The list of CPNS can be sent to the sending entity through Internet, SMS, IVR or through another communications network. Then, the sending entity 20 selects a CPN from the list of CPNs to use in the authentication process, and sends this selection to the merchant. If no CPN is associated with the provided CIA, then the authentication process can be terminated. If only one CPN is associated with the provided CIA, then this CPN is used, and it may be that no list of CPNs is presented to the sending entity. Upon the merchant determining a CPN for use in the authentication process, the merchant then sends a message to the payment processing network to initiate the authentication request. The merchant can request, from the payment processing network, the address to which the sending entity can be redirected in order to authenticate. In an exemplary way, the trader can also return the PRID to the payment processing network with a CPN, and the payment processing network can use the PRID to authenticate the 5 message and identify the authentication thread. The merchant can also
P send a key from the dealer to the payment processing network.
2 From the form used here, a "merchant key" can include any combination of letters, numbers and characters, can be an alphanumeric string, a password generator, or can be static or dynamic. The merchant key can identify the merchant or can identify the authentication thread from the merchant's perspective. The merchant key can be generated by the merchant. The merchant stores and remembers the value of the merchant's key and the PRID, and can authenticate messages and identify the authentication thread with the merchant's key.
The payment processing network can analyze the CIA to determine the associated issuer. An issuer can provide authentication services to the sending entity. In another embodiment, the issuer may be an issuing bank that issued the consumer's portable device to the sending entity. In an additional modality, the issuer may have issued the consumer's portable device associated with the CIA used in the transaction. The payment processing network can send the PRID, the merchant's key and the CPN to the issuer. In an exemplary form, the payment processing network can also send the PAN associated with the 25 CPN to the issuer.
Upon receipt of the PRID, merchant key and CPN from the payment processing network, the issuer can check to see if the PRID has already been processed. If the PRID has already been processed by the issuer, the message from the payment processing network can be ignored. If the PRID has not been processed, then the issuer can analyze the PRID and CPN / PAN to determine an authentication address. An authentication address can be a URL, IP address, a link or data that directs a user to a new location, system or application. The authentication address can lead to an authentication server operated by the issuer. Then, the sender sends the 0
W PRID, the authentication address and a key from the issuer to the payment processing network.
As used here, the "sender key" can include any combination of letters, numbers and characters, it can be an alphanumeric string, or a password generator, or it can be static or dynamic. The issuer's key can identify the issuer or identify the transaction from the issuer's perspective. The sender's key can be generated by the sender. The sender can then prepare a memo that the authentication address has been provided for the PRID. The sender's key can also be provided to the sending entity so that when the sending entity is redirected to the sender for authentication, the sender's key can be taken back to the sender to authenticate and identify the au 'thread. temptation.
The payment processing network receives the authentication address, the issuer key and the PRID from the issuer. Upon receipt of the data, the payment processing network can analyze the PRID to verify that it is valid and to map it to an authentication thread. Then, the payment processing network can provide the authentication address, the PRID, the key of the issuer and the key of the merchant to the merchant. Upon receipt of the data, the merchant can analyze the PRID to authenticate the message and to correspond to an authentication thrcad. In addition, the merchant can also analyze the merchant's key to authenticate the message and match it with an authentication thread. The merchant can then send the authentication address, the sender's key, the PRID and the merchant's key to the sending entity. The merchant can also redirect the shipping entity to the authentication address. In an exemplary embodiment, the sender's browser is directed from a merchant's website 5 to the authentication address. The authentication address can lead to an authentication Intemet page hosted by the issuer. P
V Upon the sending entity being redirected to the authentication / sender address, the sending entity can provide the sender's key and PRID to the sender. The sender's key and / or the PRID can be used to authenticate the message and the sending entity and identify the authentication thread. After analyzing the issuer's key / PRID, the issuer can present the CPN / PAN to the sending entity and request a pass code. The sending entity can provide a pass code to the issuer through Intemet, cell phone, SMS or other communication channel. If the passcode authenticates the sending entity, the issuer can provide a command to redirect the sending entity back to the merchant. After the shipping entity is redirected to the merchant, the shipping entity provides the merchant's key and PRID to the merchant. The merchant key and / or PRID can be used to authenticate the message and identify the authentication thread. The merchant can then verify that the sending entity has successfully authenticated with the issuer. The merchant then sends an authentication status request message to the payment processing network. The authentication status request message can comprise the PRID, the merchant's cliave 25, and the sender's key. The payment processing network can authenticate the message using the PRID and identify the authentication thread and then send the authentication request status to the issuer. The authentication request state can include the PRID. The issuer responds to the payment processing network if the sending entity has authenticated for this issuer PRID / key combination, and can analyze the PRID to authenticate the message and identify the authentication thread. The sender's response is then sent through the payment processing network to the merchant. If the sending entity 5 has authenticated with the issuer, then the merchant notifies the sending entity of 'successful authentication. F.j1, the trader can communicate with the
W payment processing network and the issuer to conduct a transaction or money transfer. If the sending entity has not successfully authenticated 7, the merchant can encourage the sending entity to authenticate LO again, proceed with the independent transaction or cancel the transaction. Other specific examples of embodiments of the invention are described below in further detail. I. SYSTEMS Figure 1 is a transaction authentication system based on a password generating means according to an exemplary embodiment. The transaction authentication system based on a password generating means 100 comprises a sending entity 102, a merchant 104, a payment processing network 106 and an issuer 108. Although only an e-mail entity 102, a merchant 104, a payment processing network 106 and an issuer 108 are shown, there may be any suitable number of any of these entities in the transaction authentication system based on a password generating means 100. The sending entity 102 can use a consumer device that uses the consumer's portable device to conduct a transaction or money transfer, and can operate in addition one or more user devices, including a mobile device that can comprise a cell phone. As used herein, a merchant 104 may consult any suitable entity or entities that may conduct a transaction with the sending entity.
Dealer 104 may have a physical location that sells goods and services to the user.
Merchant 104 can use an e-commerce company to allow the transaction to be conducted by the merchant through Intemet.
Other examples of a merchant 104 include a department store, gas station, drugstore, grocery store or other suitable company. · ¶
4 The payment processing network 106 refers to a network of suitable entities that have information related to an account associated with the consumer's portable device.
This information includes 10 data associated with the account on the consumer's portable device, such as profile information, data and other appropriate information.
The payment processing network 106 may have or operate a server computer and may include a database.
The database can include any hardware, software, embedded software or a combination of those exposed to store and facilitate information retrieval.
Also, the database can use any of a variety of data structures, arrangements, and compilations to store and facilitate information retrieval.
The server computer can be attached to the database and can include any hardware, software, other logic or combination of those exposed to meet requests from one or more client computers.
The server computer can use any of a variety of computing structures, arrangements and builds to meet requests from one or more client computers. 25 Payment processing network 106 can inelect subsystems, networks and data processing operations used to support and distribute authorization services, exception filing services and clearing and settlement services.
An exemplary payment processing network may include VisaNetTM, Networks that include VisaNetTM can process credit card transactions, debit card transactions and other types of business transactions. VisaNet "in particular, includes a VlP system (Visa Integrated Payments system) that processes authorization requests and a base system. II which performs clearing and settlement services. The payment processing network 106 "can use any suitable wired or wireless network, including Intemet. Issuer 108 refers to any suitable entity that can open and maintain an account associated with the used consumer device. Some examples of issuers 108 10 may be a bank, a business entity, such as a retail store, or a government entity. The sending entity 102 is in communication with the merchant 104. In one embodiment The merchant 104 may operate an exemplary computer, the merchant 104, be a physical store, a collection of servers, an e-commerce entity or the logical representation of an online entity that comprises the website. example, merchant 104 can be an online merchant with which the
A send 102 communicates via the Internet or a mobile network. Sending entity 20 may communicate with merchant 104 via a merchant's Internet page (not shown), such as an online e-commerce website. Sending entity 102 can communicate with merchant 104 via Ihtemet, cell phone, mobile network or any communication network. The sending entity 102 can communicate 25 with the merchant 104 to provide a CIA, a CPN, to be redirected to an authentication server, and to receive recognition of a successful authentication. Sending entity 102 can also be in communication with sender 1.08. In an exemplary modality, issuer 108 can operate a computer device of the issuer, it can be a physical bank, a collection of servers, an online bank or the logical representation of an online entity that comprises functions and authentication services accessible by Intemet.
In an additional modality, the issuer can be a bank 5 with accessible authentication services.
In an exemplary modality, the «sending entity 102 can authenticate with the issuer 108 by providing a
. CPN and a pass code.
In an exemplary embodiment, the sending entity's consumer portable device (not shown) may have been issued by the issuer 108 to the sending entity 102. 10 The merchant 104 and the issuer 108 can communicate with a payment processing network 106 to determine the CPNs associated with a CIA, to determine the issuer associated with a CPN, to receive the various keys and password generating means necessary to authenticate the sending entity 102 and to determine whether 15 the sending entity 102 has successfully authenticated with the issuer 108. The payment processing network 106 can communicate with the issuer 108 to determine an authentication address to which the sending entity 102 is redirected and to subsequently verify that the sending entity 102 has successfully authenticated with the issuer 108. The payment payment processing network 106 can send fund deposit transaction / original credit transaction messages to the issuer 108 and to the merchant’s bank in order to make a money transfer.
Payment processing network 106 can also send debit and deposit messages to issuer 108 / merchant bank 106 to perform a credit / debit card transaction.
The sending entity 102 can also communicate with the payment processing network 106. The sending entity 102 can communicate with the payment processing network 106 after the authentication process to conduct a transaction, and can also communicate with the payment network payment processing 106 before authentication to register / enroll in authentication services.
In an exemplary embodiment, the sending entity 102 can communicate with the payment processing network 106 during the authentication process to provide and receive authentication data. ¥
Co-merchant 104 can also communicate with issuer k 1 08. In an exemplary mode, merchant 104 can receive the status of an authentication request from sender 108. Communications between entities in the 10 transaction authentication system based on password generator means 100 can be conducted through Intemet, a mobile network, an intranet, SMS / Ivjm an old fixed telephone system, electronic mail, USSD-2, APls, adapted messages, a specialized application or a communications network.
% Ura 2 is a more detailed block diagram of a transaction authentication system based on a password generating means 200 according to an exemplary embodiment.
In this block diagram, merchant 10 04 can connect with payment processing network 106 via a merchant plug-in 202. Merchant pIug-in 202 can be software installed on merchant 104's system that 20 implements the logic to support an authentication protocol, such as the protocol described in figure 3. The plug-in. co-merchant 202 can communicate with payment processing network 106 through Intemet and through a payment processing network interface 208. Issuer 108 can communicate with payment processing network interface 208 through. an access control server 204 or a treadmill authenticator 206. An access control server 204 may comprise a server operated or facilitated by issuer 108 that can authenticate holders of consumer portable devices.
A third party authenticator 306 can be used by issuer 108 to perform authentication operations if enumerator 108 does not have an access control server 204 or does not support authentication directly. Third party authenticator 306 can be a server or service provider that can perform the authentication steps for issuer 108. Access control server 204 and third party authenticator 206 can communicate with "the network for processing payment 106 through Intemet and through a payment processing network interface 208. The payment processing network interface 208 can have modules that support various communication protocols. have an XML / HTTP 210 module and a SOAP module (simple object access protocol) 212 to receive, parse and analyze messages sent via XML, HTTP and SOAP. The XML / HTTP 210 module and the SOAP module 212 can also package and create outgoing messages in their respective 15 formats.
The payment processing network 106 may comprise a transaction services module 214 and a subscription services module 221. The 'transaction services module 214 can support transaction processing through the payment processing network 106. The transaction services module 214 can comprise a codename verification module 216. The codename verification module 216 can comprise logic for receiving a message to verify a codename or a CIA. In an exemplary embodiment, code name verification module 214 can receive a CIA and determine CPNs associated with the CIA. The codename verification module 216 can also send a response message comprising the discovered CPNs. In an exemplary embodiment, the codename verification module 214 analyzes and sends a codename verification request message and a verification response message. codenamed. In an additional embodiment, messages are sent to a merchant 104 or to the merchant's 202 port. The transaction services module 214 taínbén.i can comprise an authentication initiation module 218. The authentication initiation module 218 can understand Logic to receive a message, to initiate authentication, send an authentication request to an authentication entity, receive an authentication response from the authentication entity and forward the authentication response. the authentication initiation module 218 receives a request to initiate authentication. The request to initiate authentication may include a CP'N and a merchant key. The authentication initiation module 218 can analyze the CPN and determine the PAN and associated issuer 108. Then, the authentication initiation module 218 can send an authentication initiation request message to issuer 108 and receive the sender 108 authentication start response. Then, the authentication initiation module 218 can analyze the sender's response message and send an authentication initiation response message to merchant 104. In an exemplary mode, sender 108 an issuer key can be returned in the authentication authentication reply message and the issuer key can be sent to the merchant 104. In an exemplary mode, the authentication initiation module 218 analyzes and sends an authentication initiation request message. and an authentication start reply message. In an additional modality, the 25 messages are sent to a merchant 104 or to the merchant plug-in
202. The transaction services module 214 may also comprise an authentication status module 220. The authentication status module 220 may comprise logic for receiving a message to determine an authentication status, sending a message to determine a status of authentication. authentication to an authentication entity, receive an authentication status response from the authentication entity and forward the authentication status response. In an exemplary embodiment 5, the authentication status module 220 can receive an authentication status request from a merchant 104, can 0
W send an authentication status request to an issuer 108, can receive an authentication status response from an issuer 108 and can send an authentication status response to a merchant 104. In an exemplary mode, the authentication status module 220 analyzes and sends an authentication status request message and an authentication status response message. In an additional modality, the messages are sent to a merchant 104 or to the merchant plug-in 202. 15 The subscription services module 221 can support the registration / registration of a sending entity 102 with the payment processing network 106 The subscription services module 221 can comprise creation modules 222, update 224, read 226 and verification 228. These modules can assist in the registration of a sending entity 20 102 with the payment processing network 106. Eiii an exemplary modality, the sending entity 102 can enroll in the authentication program with the payment processing network 106, which can allow the sending entity 102 to use the protocol of figure 3. The creation module 222 can create a user profile on the payment processing network. The user profile can determine and associate CIAS, CPNs, pass codes and other relevant user data. Update module 224 can be used to update user profile data. Reading module 226 can be used to read the user profile, such as when determining which CPN is associated with a CLA. The verification module 228 can verify stored data in the user profile.
In an exemplary way, the data collected during user enrollment can be shared with an associated issuer 108. The payment processing network 106 can also be a remote directory providing remote services. 'II.
METHOD b A.
Internet-based authentication Figure 3 is a flow of an authentication process based on Intemet according to an exemplary modality.
In operation 10 1, the sending entity 102 starts one. transaction with merchant 104 for the provision of a CIA / codename.
Sending entity 102 may prefer to provide a CIA as opposed to a PAN for various security or convenience factors.
The sending entity 102 provides the CIA to the merchant 104 through Intemet, such as through a website, an online kja 15 operated by the merchant, an application or other Intemet-enabled communication medium.
In an exeinplar modality, the sending entity 102 can communicate with the co-merchant 104 through üll) plug-in of the merchant 202. The sending entity 102 can also provide additional information to the merchant 104. For example, a e.nt of 20 shipping 102 you can visit a Jntemet page of the merchant and select items to buy.
To purchase the items, the shipping entity 102 may provide the merchant 104 with a message comprising the CIA "ted @, ted.con: i" or a telephone number.
Upon receipt of the message from the sending entity 25 102 sent in transaction 1, the merchant 104 can. analyze the data.
So,
in transaction 2, the merchant can send the CIA in a niensagern to the payment processing network 106 for verification.
In an exemplary embodiment, merchant 104 sends a codinonie verification request message, which comprises the CIA, and created by merchant 202's plug-in, to the payment processing network 106. For example, merchant 104 can receive a message comprising the CIA "ted@ted.com" from the sending entity 102 and then sending a message comprising the CIA "ted@ted.com" to payment processing network 106. ^ The network payment processing 106 receives the
Y message from trader 104 sent in transaction 2 and analyzes the content. Payment processing network 106 can analyze the CIA for the CIA search and retrieve CPNs associated with the CIA. In an exemplary embodiment, the CPNS are associated with the CIA during a user enrollment process with the payment processing network 106, in which the sending entity 102 can create a single CIA and in which they can add one or more devices consumer laptops and create a CPN for each device. CPN data can indicate which authentication channels are available with this particular CPN. In an exemplary mode, each unique CPN / authentication channel pair can be added to a CPN list.
In operation 3, the payment processing network 106 can send the CPNs to the merchant 104. In an exemplary embodiment, the payment processing network 106 can send only the CPN / authentication channel pairs that are eligible under an authentication channel. based on Intemet. In exemplary fashion, payment processing network 106 packages CPN data into a codename verification response message. 25 The payment processing network 106 can also generate a PRID in response to the merchant's request message. A request by a merchant 104 for the codename data can be the first step in many of an authentication process. Payment processing 106 can assign a PRID to an authentication thread. PRID can be used to authenticate subsequent messages that payment processing network 106 receives. For example, PRID can be passed from entity to entity during payment. the entire authentication process, so that when a message is received by the payment processing network 106 from another entity, the payment processing network 106 can identify which authentication thread the message is with is associated and that it probably comes from a valid source. The PRID can also be used by other entities in the authentication process to identify the authentication and authentication thread air 10 a message. In an exemplary mode, the PRID is packaged as part of the codename verification reply message.
The ijue message contains the CPN data and the PRID can be sent by the code processing verification module of the payment processing network 216. In an e.xemplar modality, the message can be a codename verification response message. In an additional modality, the message can be sent via the payment processing network interface 208. The message can be sent via the XML / HTTP module 210 or a SOAP 212 module, and can be received by a plug- in from merchant 202. For example, payment processing network 106 may receive a message comprising the CIA "ted@ted.com" from the merchant] 04 and fetch CPNs related to this codinoine. The payment processing network 1 06 can determine that the CPNs "Cartão Vennelho", "Meu Cartão Verde" and "Meu Cartão Azul" are associated with the CIA and resume the CPNS in a message to the merchant 25 104.
Merchant 104 can receive the message containing the CPN / PRID data from payment processing network 106 sent in transaction 3. Merchant 104 can analyze the CPN data to determine which one to submit to the shipping entity 102. Se nial CPN is listed in the CPN data, then, in operation Al, the plurality of CPNs can be presented to the sending entity 102. For example, the CPNS "Red Card", "My Green Card" and "My Blue Card" are then presented to sending entity 102. 5 In transaction N ', sending entity 102 can select a "CPN from the plurality of CPNs and resend it to merchant 104 for use.
In ex an exemplar mode, only eligible CPNs, given the coin authentication channel based on the sending entity's Intemet, can be presented.
If no CPN is eligible, then the authentication process 10 can be canceled.
If only one CPN is listed or is eligible, then that CPN is used.
For example, if "Red Card" is not compatible with the initiation used, then only "My Green Card" and "My Blue Card" can be displayed to the sending entity 102. If only "My Blue Card" is compatible with the initiation channel used, then sending entity 15 102 may not be encouraged to select a CPN.
After determining a CPN to be used in the authentication process, the merchant 104 can send a message to the payment processing network 106 in operation 4 that identifies the CPN selected by the sending entity 102. The message sent to the payment processing network 20 payment 106 can also resume the PRID provided by the payment processing network 106 in operation 3. By returning the PRID to the payment processing network 106, the message sent in operation 4 can be identified as belonging to a certain authentication thread and also be authenticated as likely to be valid, since it resumes PRID to payment processing network 106. In addition, merchant 104 can provide a merchant key to payment processing network 106 in transaction 4. The merchant's key can be generated by merchant 104 specifically for this authentication thread.
The merchant key can be passed between entities so that further communication with merchant 104 can include the merchant key, which can be used by merchant 104 to identify the authentication thread and authenticate the message.
In an exemplary embodiment, the CPN, PRID and key of the 5 merchant selected by the sending entity 102 can be sent by the "merchant 104 in a request to initiate authentication to the payment processing network 106. A The authentication start request message can be sent by a counter of the counter 202. 'The payment processing network 106 can receive the 10 message from the merchant 104 sent in operation 4. Then, the process network . payment payment] 06 can analyze the message content.
The PRID can be analyzed to determine which authentication thread the message is associated with and to authenticate the message.
The message can be received and analyzed by an authentication initiation module 218. The network
'15 payment processing 106 can also analyze c) CPN for detemi.nar an associated PAN and an associated issuer 108. For example, the sending entity 102 can select the CPN "My Blue Card" and this selection can be connected to the payment processing network 106 through the merchant 104. The payment processing network 10 06 can determine the PAN associated with the CIA "Meu Cartão Azul" and, from the PAN, determine the issuer associated 108. Payment processing network 106 can, in operation 5, send a message to associated issuer 108. The message can comprise the PRID and the CPN / PAN.
The message can also 25 understand the merchant key and other data.
In an exemplary embodiment, the message is a message to request authentication initiation sent by the authentication initiation module 2 18. The message sent to sender 108 may be requesting an address to which the sending entity 102 is directed in order to that the sending entity 102 authenticates with the issuer 108. For example, the payment processing network 106 can send a message to the issuer associated with "My Blue Card" to the request and authentication address. The sender 108 receives the message sent from the payment processing network 5 Ilâ operation 5 and analyzes the content. Issuer 108 can analyze the PRID in the message to determine if an ¥ authentication address has already been provided for this PRID. Issuer 108 can use the CPN / PAN to determine the authentication address. The authentication address can direct to the issuer 108, a 10 sender access control server 204 or a third party authenticator authentication service 206, The message can be analyzed and received by the authentication start module 218. If the PRID has not been seen by the sender 108 before, then, in operation 6, the sender sends a message to the payment processing network 106 which comprises the authentication address 15. Issuer 108 can also send the PRID and a key from the sender with the message. be passed to the payment processing network 106, the merchant 104 and the sending entity 102 to be taken back to the issuer 108 by the sending entity 102 when the sending entity 102 is redirected to the issuer 108. In a in exemplary mode 20, the message is an authentication start response message comprising the sender's authentication address and key. For example, sender 108 can receive the message from the payment processing network 106 and determine to send sending entity 102 to "authenticate.issuer.net" for authentication.
25 The payment processing network 106 receives the message sent from the issuer 108 in operation 6 and can analyze the content. The payment processing network 106 can analyze the PRID to authenticate the message and identify the authentication thread. By PRID analysis, the payment processing network 106 can identify the merchant 104. In operation 7, the payment processing network 106 sends a message to the merchant 104 with the authentication address and the sender's key. The message can also comprise the merchant's key, PRID and other data. In an exemplary embodiment, the message 5 is an authentication initiation reply message sent by the authentication initiation module 218.
F m Merchant 104 receives the message from the payment processing network 106 sent in transaction 7 and can analyze its contents. For example, merchant 104 can analyze the PRID to determine the authentication / transaction thread and sending entity 102. In operation 8, merchant 104 redirects the sending entity's browser 102 to the authentication address. The trader 104 may also induce the PRID, the issuer key, the coInercy key] 1te and other data in the redirection request. In 'Lln] the exemplary mode, the trader 104 sends an HTTP redirect next to the server (codes 30X). Thus, the browser of the sending entity 102 can go from an Intemet page of the merchant 10 04 to an Internet page operated by the issuer 108 or by an affiliated third party authenticator 206. In operation 9, the sending e-ntity 102 may request to be authenticated by the issuer 20. The request 'may include the data contained in the redirection request. For example, the authentication address "authenticate.issuer.net" can be communicated from issuer 108 to payment processing network 106 to merchant 104, where merchant 104 sends a redirect message to the browser of the sending entity to 25 address "authenticate.issuer.net". Then, the sending entity 102 is redirected to "authenticate.issuer.net", where it sends a message requesting authentication with the sender 108. The sender 108 receives the message sent by the sending entity 102 in operation 9 and analyzes its contents . Enutor 108 can analyze the PRID to authenticate the message and identify the authentication thread. Sender 108 can also analyze the sender's key to authenticate the message and identify the authentication thread. By analyzing the sender's key / PRJD, sender 108 can determine the CPN associated with the authentication thread. In operation 10, the issuer 108 presents the 'CPN to the sending entity 102 and requests that the sending entity 102 provide
A pass code for authentication. The sending entity 102 receives the message sent in operation 10 and responds, in operation I, with the pass code. Issuer 108 receives the pass code sent in operation Il and 10 verifies that it corresponds to the pass code associated with the CPN. In operation 12, sender 108 sends a message to sending entity 102 with the results of the authentication request. The message may also contain a redirect command to the sender's browser 102 to redirect to the merchant 104. The message may also contain the merchant's key, PRID and other data. For example, sending entity 102 and issuer 108 can exchange pass codes and messages for authentication at "authenticate.issuer.net".
In operation 13, the sending entity 102 is redirected to the merchant 104. The sending entity 102 can provide the key of the 20 merchant and the PRID to authenticate the message with the merchant 104 and to identify the authentication thread. By returning the merchant key to the merchant 104, the merchant 104 can be confident that the redirected entity is reagent to the sending entity 102. For example, after the sending entity 102 has provided a code of 25, it passes the sender 108, sender 108 can redirect the sender's browser back to merchant 104.
After the merchant 104 identifies the sending entity 102 and the merchant's key, then the merchant 104 consults to verify that the sending entity 102 has successfully authenticated. The merchant
104 sends a message to the payment processing network 106 in operation 14 inquiring about the sending entity's authentication status
102. The message can be an authentication status request message. Payment processing network L06 receives message 5 from operation 14 and can determine issuer 108. In operation 15, payment processing network 106 sends a message to issuer 6 "108 i11 inquiring about the status of authentication of the sending entity 102. In an exemplary embodiment, the message can be an authentication status request message sent by the authentication status module 220. Issuer 108 receives the message sent in operation 15 and can analyze its The issuer 108 can analyze the PRID to determine if the sending entity 102 has authenticated with this PRID In operation 16, the issuer 108 sends a message to the payment processing network 106 containing the authentication status of the sending entity 15 102. The payment processing network 106 receives the message and forwards it to the merchant 104 in operation "" o 17. In an exemplary embodiment, the message] is a response message from the created authentication status. by the authentication status module 220. Trader 104 analyzes the message. If authentication has been successful, trader 104 may initiate a traditional transaction with an acquirer and the issuer or a money transfer transaction. In transaction 19, the merchant 104 can send an authentication confirmation to the sending entity 102.
B. Authentication based on cell phone 25 Figure 4 is a process flow of the authentication process based on cell phone on board with an exemplary modality. Operations 1-5 in figure 4 operate in the same way as operations 1-5 in figure 3. However, in figure 4, the sending entity 102 communicates both through an Intemet 404 entity, such as a browser, and from a mobile entity 402, such as a cell phone. A mobile entity 402 can be a cell phone, mobile application or mobile device by which a sending entity 102 can communicate with other entities in a transaction authentication system based on a password generating means. 5 An Intemet 404 entity can be a personal computer with an Intemet browser, such as Microsoí Intemet Explorer, or another 0
An Intemet-enabled device by which a sending entity 102 can communicate with other entities in a transaction authentication system based on a password generating means. Also, in figure 4, the CPN 10 selected in operation A2 allows authentication on a cell phone-based channel.
Starting in operation 5, the issuer 108 receives the message sent from the payment processing network 108 in operation 5 and analyzes the content. Issuer 108 can analyze the PRID in the message to determine that a cell phone authentication channel has been selected.
Issuer 108 can use the CPN / PAN to determine the variables of cell phone authentication, such as the phone number or SMS number. The message can be analyzed and received by the authentication start module 218. If the PRID has not been seen by the sender 108 before, 20 then, in operation 6, the sender sends a message to the payment processing network 106 which comprises a warning that cell phone authentication will take place. Sender 108 can also send the PRID and a sender key with the message.
The payment processing network 106 receives the 25 message sent from the issuer 108 in operation 26 and can analyze the content. The payment processing network 106 can analyze the PRID to authenticate the message and identify the authentication thread. Through PRID analysis, payment processing network 106 can identify merchant 104. In transaction 27, payment processing network 106
3I sends a message to merchant 104. The message can also comprise the merchant's key, PRID and other data. In a cxemplar modality, the message is a reply message of authentication start sent by the authentication start module 218. Message 5 can indicate an authentication action in the cell phone channel. m Merchant 104 receives the message from the payment processing network 106 and can analyze its contents. For example, merchant 104 can analyze the PRID to determine the authentication thread and sending entity 102. In operation 28, merchant 104 10 sends a message to the Intemet 404 entity that authentication will take place on the cell phone channel. Then, the Internet 404 entity can expect to receive successful authentication confinement.
In operation 29, the sender 108 sends a message to the mobile entity 402. The message can be sent via SMS, 15 Mobile Internet, W1Fi or another communication network. The message can be directed to a mobile application that supports the authentication protocol. The message can notify mobile entity 402 that issuer 108 is ready to authenticate. In operation 30, mobile entity 402 may send a message to issuer 108 to request authentication. Upon receipt of the message sent in operation 30, the sender 108 can send a message containing the CPN and a request for a pass code in operation 3 1. Upon receipt of the message, the mobile entity 402 can respond with a pass code in operation 32. Issuer 108 receives the pass code and checks whether it corresponds to the value stored with the user profile associated with the sending entity. In operation 33, the issuer 108 can send a message to the mobile entity 402 which describes whether the authentication was successful or not. During operations 29-33, operations 34-37 execute and loop continuously for a predetermined amount of time to verify the authentication status of the sending entity 102 / mobile entity 402. Before operation 34, the merchant 104 it waits for the sending entity 102 to authenticate with the issuer 108 via mobile entity 402. In operation 34, the merchant 104 sends a message to the payment processing network 5 requesting the status of the authentication.
The "message may include PRID and other data.
In an exemplary V embodiment, the message is an authentication status request message.
The payment processing network 106 receives the message sent in operation 34, and can analyze the PRID to authenticate the message and to identify the authentication thread.
The payment processing network 106 can send a message to the issuer comprising the PRID in operation 35 requesting the status of the authentication.
In an exemplary embodiment, the message is an authentication status request message created by authentication status module 220. 15 Issuer 108 can receive the message sent in operation 35 and analyze its contents.
The PRID can be analyzed to authenticate the message and identify the authentication thread.
Then, the issuer 108 can send a message to the payment processing network 106, in operation 36, indicating the authentication status.
Authentication status 20 may indicate that authentication has succeeded, failed, is in process, or is waiting for a response from sending entity 102. The message may comprise a PRID.
In an exemplary mode, the message is a response message from the authentication state.
The merchant 104 can receive the message sent in transaction 36 and analyze the contents. O
25 PRID can be analyzed to authenticate the message and to identify the authentication thread.
If merchant 104 determines that authentication was successful, then, in operations 38 and 39, dealer 1.04 continues with a traditional transaction or money transfer and sends confirmation of authentication to the Intemet 404 entity. If authentication was unsuccessful, it is in process or waiting for a response from mobile entity 402, then operations 34-37 are in loop until a predetermined period of time expires.
After a shipping entity authenticates and successfully completes the operations listed in figures 3-4, the shipping entity can &
continue with a typical union. payment or money transfer transaction.
In a typical acquisition transaction, a shipping entity purchases a good or service from the merchant using a consumer portable device, which can be in the form of a credit card.
The consumer consumer portable device 10 can interact with an access device, such as a POS (point of sale) terminal on coinerc-iant.e.
For example, the sending entity can take the credit card and pass it through an appropriate opening in the POS terminal.
Alternatively, the POS terminal may be a contactless reader, and the consumer's portable device may be a contactless device, such as a contactless card.
Then, an authorization request message is sent to the buyer.
Then, after receiving the authorization request message, the authorization text message is sent to the payment processing system.
The payment processing system then forwards the authorization request message to the issuer of the consumer's portable device.
After the issuer receives the authorization request message, the issuer resends an authorization response message to the payment processing system to indicate whether the current transaction is authorized or not (or not authorized). The transaction processing system then forwards the authorization reply message to the acquirer.
The buyer then resends the reply message to the merchant.
Then, after the merchant receives the authorization response message, the access device at the merchant can provide the authorization response message to the consumer. The response message can be displayed via the POS terminal or can be printed on a receipt.
5 At the end of the day, a "nomal clearing and settlement process can be conducted by the transaction processing system. One, clearing process is a process of exchanging financial details between the acquirer and an issuer to facilitate posting to an account. and the reconciliation of the consumer's settlement position.
10 Clearing and settlement can occur simultaneously.
Modalities of the invention are not limited to the specific examples described above.
In another exemplary embodiment, the authentication steps, from the perspective of a payment processing network, may comprise sending a message comprising a first payment reference identifier to a merchant, receiving, from of the merchant, a second payment reference identifier, a consumer payment nickname and a corner key, determine whether the second payment reference identifier matches the first payment reference identifier, analyze the consumer payment nickname for determine a sender, co-communicate to the sender a message comprising c) the first payment reference identifier, the merchant key and the consumer's payment surname, receive, from the sender, an authentication address, a sender key and a third payment reference identifier, and determine whether the third payment reference identifier is correct corresponds to the first payment reference identifier.
In an additional embodiment, the authentication steps, from the perspective of the issuer, may comprise receiving a message comprising the first payment reference identifier, the merchant key and the consumer payment nickname from a network. payment processing, where the payment processing network sent one. message comprising a first payment reference identifier to a merchant, received, "from the merchant, a second payment reference identifier, a consumer payment nickname and a merchant key, and determined whether the second payment reference identifier corresponded to the first 10 payment reference identifier, analyze the consumer's payment nickname to determine the issuer, and send an authentication address, an issuer key and a third payment reference identifier to payment processing network, where the payment processing network determines whether the third payment reference identifier corresponds to the first payment reference identifier.
Figure 5 is a diagram of a computer device according to an exemplary n) odality. The various participants and elements of the system diagrams previously described (for example, the merchant, the issuer, the access control server, the third party authenticator, the payment processing network r 20, etc.) 1, 2, 3, 4) can use any suitable number of subsystems in the computer device to facilitate the functions described here. Examples of such subsystems or components are shown in figure 5. The subsystems shown in figure 5 are interconnected via a system bus 775. Additional subsystems 25, such as a printer 774, a keyboard 778, a fixed disk 779 ( or other media comprising computer-readable media), a 776 monitor, which is attached to a 782 display adapter, and still others are shown. Peripheral devices and input / output (I / O) devices, which connect to the 771 I / O controller, can be connected to the computer system by any number of devices known in the technology, such as a 777 serial port. serial 777 or the external interface 781 can be used to connect the computer device to a wide area network, such as Intemet, a mouse input device 5 or a digitizer. Interconnection via the system bus "allows the 773 central processor to connect with each subsystem and
V control the execution of instructions from system memory 772 or fixed disk 779, as well as the exchange of information between subsystems. System memory 772 and / or fixed disk 779 can incorporate readable media 10 computer.
The software components or functions described in this order. they can be implemented as software code to be executed by one or more processors using any suitable computer language, such as, for example, Java, C ++ or Perl, using, for example, conventional or object-oriented techniques. the software code can be stored as a series of instructions or commands on a computer-readable medium, such as a random access memory (RAM), an exclusive read-only memory (ROM), a magnetic medium, such as a hard disk or a floppy disk, or an optical media, such as a CD-20 ROM. Any such computer-readable media can also reside on a single computing device, and can be present on different computing devices on a system or network.
The present invention can be implemented in the form of control logic in sofhvare or hardware or in a combination of both. The control logic can be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to carry out a set of steps disclosed in the modalities of the present invention. Based on the disclosure and the precepts provided herein, versed in the art, they perceive other ways and / or methods to implement the present invention.
In modalities, any of the entities described here can be incorporated by a computer that performs any or all of the functions and stages disclosed.
"Any quotation from" one "," one "," o "or" a "m is intended to mean" one or more ", unless specifically stated to the contrary. The description shown is illustrative and is not restrictive Many variations of the invention will become apparent to those of skill in the art. Upon review of the disclosure, therefore, the scope of the invention should be determined not in relation to the description described, but should instead be determined in relation to the appended claims. , together with their full scope or equivalents.
Certain modalities are described here including logic or 15 numerous components, modules or mechanisms. Modules can constitute both sofbvare modules (for example, code embedded in machine-readable media or in a transmission signal) and hardware modules. A hardware module is a tangible unit capable of performing certain operations, and can be configured or arranged in a certain way. 20 Etn exemplary modalities, one or more computer systems (for example, an independent computer system, client or server) or one or more hardware modules of a computer system (for example, a processor or group of processors) can be configured by sofh'vare (for example, an application or application part) as a hardware module that operates to perform certain operations of the fonna described herein.
In various disabilities, a hardware module can be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuit systems or logic that are permanently configured (for example, as a special-purpose processor, such as a field programmable port arrangement (FPGA) or an application-specific integrated circuit ( ASlC)) to perform certain operations. A hardware module can also comprise logic or programmable circuitry (for example, covered in a general purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. It is noticed that the decision to implement a hardware module mechanically, in a dedicated and permanently configured circuit system, or in a temporarily configured circuit system (for example, configured by software) can be driven by cost and time considerations.
In this way, the term "hardware module" should be understood as covering a tangible entity, which is an entity that is physically constituted, permanently configured (for example, physically connected) or temporarily configured (for example, programmed) to operate in a certain way and / or to perform certain operations described here. Considering modalities in which hardware modules are temporarily configured (for example, programmed), 20 each of the hardware modules does not need to be configured or instantiated in any one instance over time. For example, when the hardware modules comprise a general purpose processor configured using software, the general purpose processor can be configured as respective different hardware modules at different times. In this way, 25 software can configure a processor, for example, to constitute a particular hardware module in a time instance and to constitute a different hardware module in a different time instance.
Hardware modules can provide information to, and receive information from, other hardware modules. In this way, the described hardware modules can be considered as communicatively coupled. When multiples of such hardware modules exist continuously, communications can be achieved through signal transmission (for example, in circuits and "appropriate buses") that connect the hardware modules. In modalities in which multiple hardware modules are configured or - instantiated at different times, communications between such hardware modules can be achieved, for example, by storing and retrieving information in memory structures to which multiple hardware modules have access, for example, a hardware module it can perform an operation and store the output of this operation on a memory device to which it is com- pressively attached.1 Then an additional hardware module can, at a later time, access the 15 memory device to retrieve and process it. Using the stored output, hardware modules can also initiate communications with input or output devices, and can operate rar in a recllrso (for example, a collection of information).
The various operations of exemplary methods described herein 20 can be performed, at least partially, by one or more processors that are temporarily configured (for example, pot software) or permanently configured to carry out the relevant operations. If temporary or permanently configured, such processors may constitute modules implemented by a processor that operate to perform one or more operations or functions. The modules referred to here may, in some exemplary modalities, comprise modules implemented by processor.
If the methods described herein can be, at least partially, implemented per processor. For example, at least some of the operations of a method can be performed by one or more processors or modules implemented per processor. The performance of certain operations can be distributed among one or more processors, not only residing on a single machine, but 5 implemented through numerous machines. In some exemplary modalities *, the processor or processors can be located in one. single location (for example, in a domestic environment, a professional environment or on a server farm), while in other modalities, processors can be distributed across countless 10 locations.
One or more processors can also operate to support performance of the relevant operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations can be performed by a group of computers (such as examples of machines that include developers), these operations being accessible via a network (for example, Intemet) and via a network or more appropriate interfaces (for example, Application Program Interfaces (APIs).) Modalities of the transaction authentication system based on a password generating medium can provide several advantages over existing systems. A transaction authentication system based on a password generator means that a payment processing network, an issuer and a merchant can authenticate messages and associate messages with an authentication thread. The merchant, the issuer and a. payment processing network 25 can also potentially process multiple transactions simultaneously, potentially with each other, and the use of a PRID, merchant key and issuer keys allows entities in a transaction based authentication system password generating means correspond messages with authentication threads. The use of multiple keys and PRIDS reduces the likelihood of injection attacks, where malicious parties can pretend to be a valid entity to collect sensitive data, intercept a transaction or otherwise disrupt the transaction or compromise the security of the data.
. P

权利要求:
Claims (20)
[1]
1. Method, characterized by the fact that it comprises: sending a message comprising a first payment reference identifier to a participant; 5 receive, from the participant, a second
C payment reference and a merchant key; q determine whether the second payment reference identifier corresponds to the first payment reference identifier and determine an authorization entity; 10 communicating to the authorization entity a message comprising the first payment reference identifier and the merchant's key; receive, from the authorization entity, an authentication address, an issuer key and a third payment reference identifier 15; and determining whether the third payment reference identifier matches the first payment reference identifier.
[2]
2. Method according to claim 1, characterized by the fact that it additionally comprises: 20 sending the authentication address, the issuer key, the merchant key and the first payment reference identifier to the participant, in which the participant sends the authentication address, the issuer key, the merchant key and the first payment reference identifier to a sending entity and redirects the sending entity to the 25 authentication address, where the sending entity authenticates with the entity authorization by providing the key of the issuer and a pass code, in which the authorization entity determines whether the key of the issuer received from the sending entity corresponds to the key of the issuer that the authorization entity sent, and in which, after the sending entity is redirected to the participant with the first payment reference identifier, the sending entity authenticates with the participant by providing the merchant key and in which the participant determines whether the merchant key received from the sending entity corresponds to the 5 merchant key that panicipal1tc sent.
T
[3]
Method according to claim 2, characterized by. fact that it comprehensively includes receiving a message from the participant comprising the first payment reference identifier; 10 consult the authorization entity to determine if the sending entity has authenticated with the authorization entity; and communicate if the sending entity has authenticated the authorization to the participant with the authorization entity.
[4]
4. Method according to claim 1, characterized by the fact that it additionally receives, from the participant, a payment nickname from the consumer, which is analyzed to determine the authorization entity.
[5]
5. Method according to claim 1, characterized by the fact that the participant is a trader and the authorization entity is an issuer.
[6]
6. Method according to claim 1, characterized by the fact that the authorization entity communicates through a third-party authenticator.
[7]
7. Method according to claim 1, characterized by the fact that it additionally comprises receiving, from the participant, a consumer identity code and sending the participant a plurality of consumer payment nicknames associated with the identity code consumer.
[8]
8. Method according to claim 7, characterized by the fact that the participant received the code name of the consumer from the sending entity.
[9]
9. Method according to claim 7, characterized by the fact that the participant provides the plurality of payment nicknames of the consumer to the sending entity and in which the payment nickname of the "" consumer received from the participant is one of the plurality of nicknames, payment of the consumer that is selected by the sending entity.
[10]
10. Method according to claim 1, characterized by the fact that the consumer's payment nickname is analyzed for 10 to derive a primary account number.
[11]
11. Method according to claim 10, characterized by the fact that the primary account number is analyzed to determine the authorization entity-
[12]
12. Method, characterized by the fact that it comprises: 15 receiving a merchant key from a participant and an issuer key from an authorization entity and generating a payment reference identifier; and send to the participant a message comprising the key of the merchant, the key of the issuer and the payment reference identifier, in which the participant sends the key of the merchant, the key of the issuer and the payment reference identifier to the payment entity. sending and redirects the sending entity to the authorization entity, where the sending entity authenticates with the authorization entity by providing the key of the issuer and, subsequently, the authorization entity redirects the sending entity to the participant, in that the sending entity authenticates the participant by providing the merchant's key.
[13]
13. Method according to claim 10, characterized by the fact that the sending entity also provides the payment reference identifier to authenticate with the authorization entity.
[14]
14. Method according to claim 12, characterized by the fact that the sending entity also provides the payment reference identifier to authenticate with the participant.
[15]
15. Method according to claim 12, characterized by the fact that the sending entity also provides a pass code to the 'authorization entity,,
[16]
16, Method according to claim 12, characterized by the fact that the authorization entity also provides an authentication address of the issuer, which is sent to the participant and is where the participant 10 redirects the sending entity.
[17]
17. System, characterized by the fact that it comprises: a processor; and a non-transitory computer-readable media coupled to the processor, the computer-readable media comprising code 15 executable by the processor to implement a method which comprises: sending a message comprising a first payment reference identifier to a partic. ipante; receive, from the participant, a second payment reference identifier and a merchant key; 20 determine whether the second payment reference identifier corresponds to the first payment reference identifier and determine an authorization entity; communicating to the authorization entity a message comprising the first payment reference identifier and the merchant's key; receive, from the authorizing entity, an e.authentication address, a key from the issuer and a third payment reference identifier; and determine whether the third payment reference identifier corresponds to the first payment reference identifier.
[18]
18. System according to claim 17, characterized by the fact that it additionally comprises the operations of sending the authentication address, the issuer key, the merchant key and the first payment reference identifier to the participant, in which the
Ü participant sends the authentication address, the issuer key, the key. merchant and the first payment reference identifier to the sending entity and redirects the sending entity to the authentication address, where the sending entity authenticates with the 10 authorization entity by providing the issuer key and of a pass code, in which the authorization entity determines whether the sender's key received from the sending entity corresponds to the sender's key that the authorization entity sent, and where, after the sending entity is redirected to the participant with the first payment reference identifier 15, the sending entity authenticates with the participant by providing the merchant key and where the participant determines whether the merchant key received from the sending entity corresponds to the merchant key that the participant sent.
[19]
19. System according to claim 17, characterized by the fact that it additionally comprises the operations of receiving a message from the participant that comprises the first payment reference identifier; consult the authorization authority to determine whether the sending authority has authenticated with the authorization authority; and 25 communicate whether the sending entity has authenticated with the authorization entity to the participant.
[20]
20. System according to claim 17, characterized by the fact that it additionally comprises receiving, from the participant, a code name of the consumer's identity and sending the participant a
2 · 6 4 plurality of consumer payment nicknames associated with the consumer's identity code.
q ".
* -

类似技术:

---

公开号 | 公开日 | 专利标题

---

BR112012017880A2|2020-11-17|"method and system"

---

US10552828B2|2020-02-04|Multiple tokenization for authentication

---

RU2698767C2|2019-08-29|Remote variable authentication processing

---

JP5430701B2|2014-03-05|System and method for validating financial instruments

---

US8527417B2|2013-09-03|Methods and systems for authenticating an identity of a payer in a financial transaction

---

US8317090B2|2012-11-27|Methods and systems for performing a financial transaction

---

US20120059758A1|2012-03-08|Protecting Express Enrollment Using a Challenge

---

US20110231315A1|2011-09-22|Method and system for making secure payments

---

US20150193765A1|2015-07-09|Method and System for Mobile Payment and Access Control

---

WO2015139597A1|2015-09-24|Method and system for reversed near field communication electronic transaction

---

US20190287111A1|2019-09-19|Payer-controlled payment processing

---

WO2015139623A1|2015-09-24|Method and system for mobile payment and access control

---

US20180121908A1|2018-05-03|Cross device digital wallet payment system and process

---

AU2015200688B2|2017-03-16|Token based transaction authentication

---

US20210365953A1|2021-11-25|Electronic transaction system

同族专利:

---

公开号 | 公开日

---

WO2011091053A2|2011-07-28|

---

CN102754116A|2012-10-24|

---

WO2011091053A3|2011-12-08|

---

US20130232079A1|2013-09-05|

---

AU2011207551B2|2014-11-13|

---

AU2011207551A1|2012-08-02|

---

EP2526517A2|2012-11-28|

---

EP2526517A4|2014-08-06|

---

EP2526517B1|2018-08-08|

---

RU2565368C2|2015-10-20|

---

US20110178925A1|2011-07-21|

---

US9582799B2|2017-02-28|

---

CA2787060C|2017-07-25|

---

EP3404601A1|2018-11-21|

---

US8346666B2|2013-01-01|

---

CA2787060A1|2011-07-28|

---

CN102754116B|2016-08-03|

---

AU2011207551C1|2015-05-14|

---

US20130191282A1|2013-07-25|

---

US8924301B2|2014-12-30|

---

RU2012135494A|2014-02-27|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US5557518A|1994-04-28|1996-09-17|Citibank, N.A.|Trusted agents for open electronic commerce|

---

US6029150A|1996-10-04|2000-02-22|Certco, Llc|Payment and transactions in electronic commerce system|

---

US6607136B1|1998-09-16|2003-08-19|Beepcard Inc.|Physical presence digital authentication system|

---

US6327578B1|1998-12-29|2001-12-04|International Business Machines Corporation|Four-party credit/debit payment protocol|

---

US7571139B1|1999-02-19|2009-08-04|Giordano Joseph A|System and method for processing financial transactions|

---

KR101015341B1|2000-04-24|2011-02-16|비자 인터내셔날 써비스 어쏘시에이션|Online payer authentication service|

---

US20010047335A1|2000-04-28|2001-11-29|Martin Arndt|Secure payment method and apparatus|

---

WO2002033363A2|2000-10-18|2002-04-25|Joshua Edwards Bixler|Method and apparatus for secure payment processing|

---

US7890393B2|2002-02-07|2011-02-15|Ebay, Inc.|Method and system for completing a transaction between a customer and a merchant|

---

AT291319T|2001-04-30|2005-04-15|Activcard Ireland Ltd|METHOD AND SYSTEM FOR AUTHENTICATING A PERSONAL SECURITY DEVICE COMPRISING AT LEAST ONE REMOTE COMPUTER SYSTEM|

---

US7225156B2|2001-07-11|2007-05-29|Fisher Douglas C|Persistent dynamic payment service|

---

US20030078987A1|2001-10-24|2003-04-24|Oleg Serebrennikov|Navigating network communications resources based on telephone-number metadata|

---

US7805376B2|2002-06-14|2010-09-28|American Express Travel Related Services Company, Inc.|Methods and apparatus for facilitating a transaction|

---

US7707120B2|2002-04-17|2010-04-27|Visa International Service Association|Mobile account authentication service|

---

SG152061A1|2002-09-10|2009-05-29|Visa Int Service Ass|Data authentication and provisioning method and system|

---

BRPI0411005A|2003-06-04|2006-07-04|Mastercard International Inc|systems for authentication of a customer business transaction and method for remote authentication of a customer participating in an electronic business transaction using the network access device|

---

KR20050042694A|2003-11-04|2005-05-10|한국전자통신연구원|Method for electronic commerce using security token and apparatus thereof|

---

US8762283B2|2004-05-03|2014-06-24|Visa International Service Association|Multiple party benefit from an online authentication service|

---

WO2006052203A1|2004-11-15|2006-05-18|Runtime Ab|Apparatus and method for secure credit card processing infrastructure|

---

US7210620B2|2005-01-04|2007-05-01|Ameriprise Financial, Inc.|System for facilitating online electronic transactions|

---

US8396747B2|2005-10-07|2013-03-12|Kemesa Inc.|Identity theft and fraud protection system and method|

---

US8447700B2|2005-10-11|2013-05-21|Amazon Technologies, Inc.|Transaction authorization service|

---

US20070245414A1|2006-04-14|2007-10-18|Microsoft Corporation|Proxy Authentication and Indirect Certificate Chaining|

---

JP2008033789A|2006-07-31|2008-02-14|Oki Electric Ind Co Ltd|Identification/attribute authentication system and identification/attribute authentication method|

---

AU2008204838B2|2007-01-09|2012-11-01|Visa U.S.A. Inc.|Mobile phone payment process including threshold indicator|

---

KR101540417B1|2007-04-17|2015-07-29|비자 유에스에이 인코포레이티드|Method and system for authenticating a party to a transaction|

---

US7849014B2|2007-08-29|2010-12-07|American Express Travel Related Services Company, Inc.|System and method for facilitating a financial transaction with a dynamically generated identifier|

---

US8639600B2|2008-08-11|2014-01-28|Visa U.S.A. Inc.|Mobile payer authentication|

---

AU2009311303B2|2008-11-06|2015-09-10|Visa International Service Association|Online challenge-response|

---

US20100312703A1|2009-06-03|2010-12-09|Ashish Kulpati|System and method for providing authentication for card not present transactions using mobile device|

---

US8364593B2|2009-06-30|2013-01-29|Visa International Service Association|Intelligent authentication|

---

US20110010234A1|2009-07-07|2011-01-13|Mike Lindelsee|Mobile device including auto initiation|

---

US8788429B2|2009-12-30|2014-07-22|First Data Corporation|Secure transaction management|

---

AU2011207551C1|2010-01-19|2015-05-14|Visa International Service Association|Token based transaction authentication|

---

RU2563163C2|2010-01-19|2015-09-20|Виза Интернэшнл Сервис Ассосиэйшн|Remote variable authentication processing|

---

US8571837B1|2010-07-16|2013-10-29|Cadence Design Systems, Inc.|System and method for simulating a bi-directional connect module within an analog and mixed-signal circuit|

---

SG195079A1|2011-06-03|2013-12-30|Visa Int Service Ass|Virtual wallet card selection apparatuses, methods and systems|US8016185B2|2004-07-06|2011-09-13|Visa International Service Association|Money transfer service with authentication|

---

US8762263B2|2005-09-06|2014-06-24|Visa U.S.A. Inc.|System and method for secured account numbers in proximity devices|

---

KR101540417B1|2007-04-17|2015-07-29|비자 유에스에이 인코포레이티드|Method and system for authenticating a party to a transaction|

---

US7739169B2|2007-06-25|2010-06-15|Visa U.S.A. Inc.|Restricting access to compromised account information|

---

US7937324B2|2007-09-13|2011-05-03|Visa U.S.A. Inc.|Account permanence|

---

US8219489B2|2008-07-29|2012-07-10|Visa U.S.A. Inc.|Transaction processing using a global unique identifier|

---

US9715681B2|2009-04-28|2017-07-25|Visa International Service Association|Verification of portable consumer devices|

---

US9038886B2|2009-05-15|2015-05-26|Visa International Service Association|Verification of portable consumer devices|

---

US8893967B2|2009-05-15|2014-11-25|Visa International Service Association|Secure Communication of payment information to merchants using a verification token|

---

US8534564B2|2009-05-15|2013-09-17|Ayman Hammad|Integration of verification tokens with mobile communication devices|

---

US10846683B2|2009-05-15|2020-11-24|Visa International Service Association|Integration of verification tokens with mobile communication devices|

---

US9105027B2|2009-05-15|2015-08-11|Visa International Service Association|Verification of portable consumer device for secure services|

---

US10140598B2|2009-05-20|2018-11-27|Visa International Service Association|Device including encrypted data for expiration date and verification value creation|

---

WO2011028840A2|2009-09-02|2011-03-10|Visa International Service Association|Portable consumer device with funds transfer processing|

---

US10255591B2|2009-12-18|2019-04-09|Visa International Service Association|Payment channel returning limited use proxy dynamic value|

---

CN102713922B|2010-01-12|2015-11-25|维萨国际服务协会|For the method whenever confirmed to checking token|

---

AU2011207551C1|2010-01-19|2015-05-14|Visa International Service Association|Token based transaction authentication|

---

US9245267B2|2010-03-03|2016-01-26|Visa International Service Association|Portable account number for consumer payment account|

---

US9342832B2|2010-08-12|2016-05-17|Visa International Service Association|Securing external systems with account token substitution|

---

US20120136796A1|2010-09-21|2012-05-31|Ayman Hammad|Device Enrollment System and Method|

---

AU2012220669A1|2011-02-22|2013-05-02|Visa International Service Association|Universal electronic payment apparatuses, methods and systems|

---

US10223730B2|2011-09-23|2019-03-05|Visa International Service Association|E-wallet store injection search apparatuses, methods and systems|

---

US10586227B2|2011-02-16|2020-03-10|Visa International Service Association|Snap mobile payment apparatuses, methods and systems|

---

AU2013214801B2|2012-02-02|2018-06-21|Visa International Service Association|Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems|

---

CN107967602A|2011-03-04|2018-04-27|维萨国际服务协会|Ability to pay is bound to the safety element of computer|

---

US9280765B2|2011-04-11|2016-03-08|Visa International Service Association|Multiple tokenization for authentication|

---

US8544735B2|2011-05-23|2013-10-01|Mastercard International Incorporated|Combicard transaction method and system having an application parameter update mechanism|

---

US9582598B2|2011-07-05|2017-02-28|Visa International Service Association|Hybrid applications utilizing distributed models and views apparatuses, methods and systems|

---

US10121129B2|2011-07-05|2018-11-06|Visa International Service Association|Electronic wallet checkout platform apparatuses, methods and systems|

---

US9704155B2|2011-07-29|2017-07-11|Visa International Service Association|Passing payment tokens through an hop/sop|

---

US10242358B2|2011-08-18|2019-03-26|Visa International Service Association|Remote decoupled application persistent state apparatuses, methods and systems|

---

US10825001B2|2011-08-18|2020-11-03|Visa International Service Association|Multi-directional wallet connector apparatuses, methods and systems|

---

US9710807B2|2011-08-18|2017-07-18|Visa International Service Association|Third-party value added wallet features and interfaces apparatuses, methods and systems|

---

US9355393B2|2011-08-18|2016-05-31|Visa International Service Association|Multi-directional wallet connector apparatuses, methods and systems|

---

KR20130082948A|2011-12-23|2013-07-22|주식회사 케이티|Payment agency system, user terminal and market server|

---

EP2801061B1|2012-01-05|2020-08-26|Visa International Service Association|Data protection with translation|

---

US9830595B2|2012-01-26|2017-11-28|Visa International Service Association|System and method of providing tokenization as a service|

---

US9325696B1|2012-01-31|2016-04-26|Google Inc.|System and method for authenticating to a participating website using locally stored credentials|

---

US10282724B2|2012-03-06|2019-05-07|Visa International Service Association|Security system incorporating mobile device|

---

US8489507B1|2012-03-28|2013-07-16|Ebay Inc.|Alternative payment method for online transactions using interactive voice response|

---

US20130297501A1|2012-05-04|2013-11-07|Justin Monk|System and method for local data conversion|

---

US9154470B2|2012-05-25|2015-10-06|Canon U.S.A., Inc.|System and method for processing transactions|

---

US9524501B2|2012-06-06|2016-12-20|Visa International Service Association|Method and system for correlating diverse transaction data|

---

US9547769B2|2012-07-03|2017-01-17|Visa International Service Association|Data protection hub|

---

US9256871B2|2012-07-26|2016-02-09|Visa U.S.A. Inc.|Configurable payment tokens|

---

US9665722B2|2012-08-10|2017-05-30|Visa International Service Association|Privacy firewall|

---

AU2013315510B2|2012-09-11|2019-08-22|Visa International Service Association|Cloud-based Virtual Wallet NFC Apparatuses, methods and systems|

---

US10176478B2|2012-10-23|2019-01-08|Visa International Service Association|Transaction initiation determination system utilizing transaction data elements|

---

US9911118B2|2012-11-21|2018-03-06|Visa International Service Association|Device pairing via trusted intermediary|

---

WO2014087381A1|2012-12-07|2014-06-12|Visa International Service Association|A token generating component|

---

US8972296B2|2012-12-31|2015-03-03|Ebay Inc.|Dongle facilitated wireless consumer payments|

---

US10740731B2|2013-01-02|2020-08-11|Visa International Service Association|Third party settlement|

---

US9741051B2|2013-01-02|2017-08-22|Visa International Service Association|Tokenization and third-party interaction|

---

US10223710B2|2013-01-04|2019-03-05|Visa International Service Association|Wearable intelligent vision device apparatuses, methods and systems|

---

DE102013000967B4|2013-01-22|2016-01-07|Ngoc-Khanh Le|Procedure for authorizing an electronic transaction|

---

AU2014219386B2|2013-01-30|2017-03-16|Paypal, Inc.|Transaction token issuing authorities|

---

CN105264558A|2013-04-04|2016-01-20|维萨国际服务协会|Method and system for conducting pre-authorized financial transactions|

---

US11055710B2|2013-05-02|2021-07-06|Visa International Service Association|Systems and methods for verifying and processing transactions using virtual currency|

---

EP2997532A4|2013-05-15|2016-05-11|Visa Int Service Ass|Mobile tokenization hub|

---

US20140365363A1|2013-06-07|2014-12-11|Prairie Cloudware, Inc|Secure integrative vault of consumer payment instruments for use in payment processing system and method|

---

US10878422B2|2013-06-17|2020-12-29|Visa International Service Association|System and method using merchant token|

---

EP2824628A1|2013-07-10|2015-01-14|Vodafone Holding GmbH|Direct debit procedure|

---

SG10201800629WA|2013-07-24|2018-02-27|Visa Int Service Ass|Systems and methods for communicating risk using token assurance data|

---

AP2016009010A0|2013-07-26|2016-01-31|Visa Int Service Ass|Provisioning payment credentials to a consumer|

---

US10496986B2|2013-08-08|2019-12-03|Visa International Service Association|Multi-network tokenization processing|

---

WO2015021420A1|2013-08-08|2015-02-12|Visa International Service Association|Methods and systems for provisioning mobile devices with payment credentials|

---

RU2019114941A|2013-10-11|2019-06-13|Виза Интернэшнл Сервис Ассосиэйшн|NETWORK TOKEN SYSTEM|

---

US9978094B2|2013-10-11|2018-05-22|Visa International Service Association|Tokenization revocation list|

---

US10515358B2|2013-10-18|2019-12-24|Visa International Service Association|Contextual transaction token methods and systems|

---

US10489779B2|2013-10-21|2019-11-26|Visa International Service Association|Multi-network token bin routing with defined verification parameters|

---

US10366387B2|2013-10-29|2019-07-30|Visa International Service Association|Digital wallet system and method|

---

CN103580967A|2013-11-08|2014-02-12|广东广联电子科技有限公司|Token passing method applied to digital home network|

---

US20150134518A1|2013-11-14|2015-05-14|Google Inc.|Pre-authorized online checkout|

---

US20150161608A1|2013-12-09|2015-06-11|Mastercard International Incorporated|Systems, apparatus and methods for improved authentication|

---

US9922322B2|2013-12-19|2018-03-20|Visa International Service Association|Cloud-based transactions with magnetic secure transmission|

---

SG11201604906QA|2013-12-19|2016-07-28|Visa Int Service Ass|Cloud-based transactions methods and systems|

---

US10305893B2|2013-12-27|2019-05-28|Trapezoid, Inc.|System and method for hardware-based trust control management|

---

US9258331B2|2013-12-27|2016-02-09|Trapezoid, Inc.|System and method for hardware-based trust control management|

---

US10433128B2|2014-01-07|2019-10-01|Visa International Service Association|Methods and systems for provisioning multiple devices|

---

US9846878B2|2014-01-14|2017-12-19|Visa International Service Association|Payment account identifier system|

---

US9286450B2|2014-02-07|2016-03-15|Bank Of America Corporation|Self-selected user access based on specific authentication types|

---

US9647999B2|2014-02-07|2017-05-09|Bank Of America Corporation|Authentication level of function bucket based on circumstances|

---

US9208301B2|2014-02-07|2015-12-08|Bank Of America Corporation|Determining user authentication requirements based on the current location of the user in comparison to the users's normal boundary of location|

---

US9223951B2|2014-02-07|2015-12-29|Bank Of America Corporation|User authentication based on other applications|

---

US9965606B2|2014-02-07|2018-05-08|Bank Of America Corporation|Determining user authentication based on user/device interaction|

---

US9424572B2|2014-03-04|2016-08-23|Bank Of America Corporation|Online banking digital wallet management|

---

US9600844B2|2014-03-04|2017-03-21|Bank Of America Corporation|Foreign cross-issued token|

---

US9406065B2|2014-03-04|2016-08-02|Bank Of America Corporation|Customer token preferences interface|

---

US9600817B2|2014-03-04|2017-03-21|Bank Of America Corporation|Foreign exchange token|

---

US9721248B2|2014-03-04|2017-08-01|Bank Of America Corporation|ATM token cash withdrawal|

---

US10002352B2|2014-03-04|2018-06-19|Bank Of America Corporation|Digital wallet exposure reduction|

---

US9830597B2|2014-03-04|2017-11-28|Bank Of America Corporation|Formation and funding of a shared token|

---

US9721268B2|2014-03-04|2017-08-01|Bank Of America Corporation|Providing offers associated with payment credentials authenticated in a specific digital wallet|

---

US10026087B2|2014-04-08|2018-07-17|Visa International Service Association|Data passed in an interaction|

---

US9942043B2|2014-04-23|2018-04-10|Visa International Service Association|Token security on a communication device|

---

CN106233664B|2014-05-01|2020-03-13|维萨国际服务协会|Data authentication using an access device|

---

SG10201803024SA|2014-05-05|2018-06-28|Visa Int Service Ass|System and method for token domain control|

---

WO2015179637A1|2014-05-21|2015-11-26|Visa International Service Association|Offline authentication|

---

US11023890B2|2014-06-05|2021-06-01|Visa International Service Association|Identification and verification for provisioning mobile application|

---

US20160012422A1|2014-07-11|2016-01-14|Google Inc.|Hands-free transactions with a transaction confirmation request|

---

US9780953B2|2014-07-23|2017-10-03|Visa International Service Association|Systems and methods for secure detokenization|

---

US10484345B2|2014-07-31|2019-11-19|Visa International Service Association|System and method for identity verification across mobile applications|

---

US9775029B2|2014-08-22|2017-09-26|Visa International Service Association|Embedding cloud-based functionalities in a communication device|

---

US10140615B2|2014-09-22|2018-11-27|Visa International Service Association|Secure mobile device credential provisioning using risk decision non-overrides|

---

EP3198907B1|2014-09-26|2019-04-10|Visa International Service Association|Remote server encrypted data provisioning system and methods|

---

US11257074B2|2014-09-29|2022-02-22|Visa International Service Association|Transaction risk based token|

---

US10015147B2|2014-10-22|2018-07-03|Visa International Service Association|Token enrollment system and method|

---

GB201419016D0|2014-10-24|2014-12-10|Visa Europe Ltd|Transaction Messaging|

---

US10257185B2|2014-12-12|2019-04-09|Visa International Service Association|Automated access data provisioning|

---

US10096009B2|2015-01-20|2018-10-09|Visa International Service Association|Secure payment processing using authorization request|

---

US11250391B2|2015-01-30|2022-02-15|Visa International Service Association|Token check offline|

---

US20160260084A1|2015-03-06|2016-09-08|Mastercard International Incorporated|Secure mobile remote payments|

---

US10164996B2|2015-03-12|2018-12-25|Visa International Service Association|Methods and systems for providing a low value token buffer|

---

EP3281164B1|2015-04-10|2019-06-05|Visa International Service Association|Browser integration with cryptogram|

---

US9998978B2|2015-04-16|2018-06-12|Visa International Service Association|Systems and methods for processing dormant virtual access devices|

---

US10552834B2|2015-04-30|2020-02-04|Visa International Service Association|Tokenization capable authentication framework|

---

US10127551B2|2015-09-11|2018-11-13|Bank Of America Corporation|System for modeling and implementing event-responsive resource allocation structures|

---

US10013714B2|2015-09-11|2018-07-03|Bank Of America Corporation|System for simulation and implementation of dynamic state-dependent resource reconfiguration|

---

US10249002B2|2015-09-11|2019-04-02|Bank Of America Corporation|System for dynamic visualization of individualized consumption across shared resource allocation structure|

---

US10607215B2|2015-09-30|2020-03-31|Bank Of America Corporation|Account tokenization for virtual currency resources|

---

US10453059B2|2015-09-30|2019-10-22|Bank Of America Corporation|Non-intrusive geo-location determination associated with transaction authorization|

---

RU2018117661A3|2015-10-15|2020-04-16|

---

US11010782B2|2015-10-16|2021-05-18|International Business Machines Corporation|Payment for a service utilizing information|

---

EP3156957A1|2015-10-16|2017-04-19|Mastercard International Incorporated|System and method of enabling asset leasing on a token enabled payment card|

---

US9729536B2|2015-10-30|2017-08-08|Bank Of America Corporation|Tiered identification federated authentication network system|

---

CN108370319B|2015-12-04|2021-08-17|维萨国际服务协会|Method and computer for token verification|

---

US9723485B2|2016-01-04|2017-08-01|Bank Of America Corporation|System for authorizing access based on authentication via separate channel|

---

US9749308B2|2016-01-04|2017-08-29|Bank Of America Corporation|System for assessing network authentication requirements based on situational instance|

---

US9912700B2|2016-01-04|2018-03-06|Bank Of America Corporation|System for escalating security protocol requirements|

---

US10003686B2|2016-01-04|2018-06-19|Bank Of America Corporation|System for remotely controlling access to a mobile device|

---

US10002248B2|2016-01-04|2018-06-19|Bank Of America Corporation|Mobile device data security system|

---

WO2017120605A1|2016-01-07|2017-07-13|Visa International Service Association|Systems and methods for device push provisioning|

---

KR20170086957A|2016-01-19|2017-07-27|삼성전자주식회사|Device for Performing Transaction and Method Thereof|

---

AU2017214412A1|2016-02-01|2018-06-28|Visa International Service Association|Systems and methods for code display and use|

---

CN105761076A|2016-02-06|2016-07-13|优住（北京）科技股份公司|Payment system based on wireless identification and wireless identification equipment|

---

US10373199B2|2016-02-11|2019-08-06|Visa International Service Association|Payment device enrollment in linked offers|

---

US10313321B2|2016-04-07|2019-06-04|Visa International Service Association|Tokenization of co-network accounts|

---

US10643203B2|2016-04-12|2020-05-05|Digicash Pty Ltd.|Secure transaction controller for value token exchange systems|

---

US10460367B2|2016-04-29|2019-10-29|Bank Of America Corporation|System for user authentication based on linking a randomly generated number to the user and a physical item|

---

US11250424B2|2016-05-19|2022-02-15|Visa International Service Association|Systems and methods for creating subtokens using primary tokens|

---

AU2016409079B2|2016-06-03|2021-07-22|Visa International Service Association|Subtoken management system for connected devices|

---

US11068899B2|2016-06-17|2021-07-20|Visa International Service Association|Token aggregation for multi-party transactions|

---

US10268635B2|2016-06-17|2019-04-23|Bank Of America Corporation|System for data rotation through tokenization|

---

SG11201808737YA|2016-06-24|2018-11-29|Visa Int Service Ass|Unique token authentication cryptogram|

---

US10990967B2|2016-07-19|2021-04-27|Visa International Service Association|Method of distributing tokens and managing token relationships|

---

GB201613882D0|2016-08-12|2016-09-28|Mastercard International Inc|Digital secure remote payment Enhancements when transacting with an authenticated merchant|

---

US10509779B2|2016-09-14|2019-12-17|Visa International Service Association|Self-cleaning token vault|

---

US20180232728A1|2017-02-14|2018-08-16|Its, Inc.|Payment tokenization using encryption|

---

US10915899B2|2017-03-17|2021-02-09|Visa International Service Association|Replacing token on a multi-token user device|

---

US10902418B2|2017-05-02|2021-01-26|Visa International Service Association|System and method using interaction token|

---

US10524165B2|2017-06-22|2019-12-31|Bank Of America Corporation|Dynamic utilization of alternative resources based on token association|

---

US10313480B2|2017-06-22|2019-06-04|Bank Of America Corporation|Data transmission between networked resources|

---

US10511692B2|2017-06-22|2019-12-17|Bank Of America Corporation|Data transmission to a networked resource based on contextual information|

---

US10491389B2|2017-07-14|2019-11-26|Visa International Service Association|Token provisioning utilizing a secure authentication system|

---

US11256789B2|2018-06-18|2022-02-22|Visa International Service Association|Recurring token transactions|

---

WO2020047676A1|2018-09-06|2020-03-12|Royal Bank Of Canada|System and method for managing resource consumption for electronic transaction data processes|

---

WO2021118519A1|2019-12-09|2021-06-17|Visa International Service Association|Computer-implemented method for determining a merchant location using a virtual card, in real-time|

法律状态:
2020-11-24| B15I| Others concerning applications: loss of priority|Free format text: PERDA DA PRIORIDADE US 61/296,385, DE 19/01/2010 POR AUSENCIA DE CUMPRIMENTO DA EXIGENCIA PUBLICADA NA RPI NO 2590, DE 25/08/2020. |

---

2020-12-01| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|

---

2020-12-08| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|

---

2021-03-23| B11B| Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements|

---

2021-12-07| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

US29638510P| true| 2010-01-19|2010-01-19|

---

US61/296385|2010-01-19|

---

PCT/US2011/021737|WO2011091053A2|2010-01-19|2011-01-19|Token based transaction authentication|

---