Validation password for interaction

Abstract

A method for verifying an interaction is disclosed. A first interaction cryptogram can be generated by a first device using information about a first party to the interaction and a second party to the interaction. A second interaction cryptogram can be generated by a second device also using information about the first party to the interaction and the second party to the interaction. Checking each cryptogram can verify that the details of the interaction have not been altered and that both the first party and the second party have authorized the interaction.

Description

[0001] This invention application is a divisional application of the invention patent application entitled "Verification Password for Interaction" with international application number PCT / US2017 / 021939, international application date March 10, 2017, Chinese national phase application number 201780017915.5.

[0002] This application is an international patent application claiming the benefit of U.S. Provisional Application No. 62 / 308,788, filed on March 15, 2016, the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Peer-to-peer transactions allow individuals to directly exchange information and value. Peer-to-peer transactions can be facilitated by intermediary applications, such as digital wallet providers.

[0004] For example, Alice can activate the digital wallet app on her mobile device and enable peer-to-peer transactions. Alice enters her account credentials and indicates that she wants to send the payment to Bob by entering his phone number. When Alice submits the transaction, her mobile device sends her credentials along with the transaction amount and Bob's phone number to the digital wallet provider. The digital wallet provider then contacts Bob's mobile device to request his credentials. Bob enters his credentials, and his mobile device sends them back to the digital wallet provider. Having obtained both Alice's and Bob's credentials, the digital wallet provider can then proceed with the transaction, transferring the payment value from Alice's account to Bob's account.

[0005] While peer-to-peer transactions enable individuals to send value to each other, they also introduce numerous security risks. For example, scammers can execute man-in-the-middle attacks by intercepting transaction messages, altering some information, and then forwarding the modified messages.

[0006] As an example, a scammer could intercept messages Alice sends to a digital wallet provider. The scammer could alter the message so that Bob is no longer designated as the transaction recipient, but instead, the scammer is the recipient (e.g., by changing Bob's phone number to the scammer's). As a result, the digital wallet provider contacts the scammer's mobile device (instead of Bob's), and the scammer enters their own account credentials. The payment is then sent to the scammer instead of Bob.

[0007] As another example, scammers could intercept messages Bob sends to digital wallet providers. They could alter the message so that Bob's credentials are no longer listed, and instead, the scammer's credentials are displayed. Similarly, the payment would be sent to the scammer instead of Bob.

[0008] The embodiments of the present invention address these and other problems individually or collectively. Summary of the Invention

[0009] Embodiments of this invention relate to processing an interaction between a first party and a second party. The first party can provide account information and a password to verify its legitimate participation. The second party can agree to the interaction, and can also provide account information and a password to verify its legitimate participation. A coordinating computer can aggregate the information from the first and second parties, create a digital signature, and send the information to an interaction processing computer. The interaction processing computer can then verify the first party's password, the second party's password, and the digital signature, thereby verifying that each party agrees to the interaction and that the interaction details have not been altered.

[0010] Embodiments of the present invention also allow for the generation of passwords using information about both the first and second parties. As a result, both the first and second accounts can be verified using a single password.

[0011] One embodiment of the present invention relates to a method. The method includes receiving an interaction request, including interaction details and a first password, by a server computer. The interaction details include receiver information, wherein the first password is generated using the receiver information. The method further includes verifying the first password. The method also includes coordinating a transfer from sender to receiver.

[0012] Another embodiment of the present invention relates to a server computer configured to perform the methods described above. In some embodiments, the server computer may be an interactive processing computer.

[0013] Another embodiment of the present invention relates to a method comprising: receiving interaction details and a first password by a first computer. The interaction details include receiver information, wherein the first password is generated using the receiver information. The method further comprises sending an interaction confirmation request to a receiver device associated with the receiver information; and receiving an interaction confirmation response from the receiver device. The method further comprises sending an interaction request including the interaction details and the first password to a second computer. The second computer verifies the first password and coordinates the transfer from sender to receiver.

[0014] Another embodiment of the invention relates to a first computer configured to perform the methods described above. In some embodiments, the first computer may be a coordinating computer.

[0015] Further details regarding embodiments of the present invention can be found in the detailed description and accompanying drawings. Attached Figure Description

[0016] Figure 1A block diagram of a system according to an embodiment of the present invention is shown.

[0017] Figure 2 A block diagram of an exemplary mobile device according to an embodiment of the present invention is shown.

[0018] Figure 3 A block diagram of a coordinating computer according to an embodiment of the present invention is shown.

[0019] Figure 4 A block diagram of an interactive processing computer according to an embodiment of the present invention is shown.

[0020] Figure 5 A flowchart illustrating a method for handling interactions according to an embodiment of the present invention is shown. Detailed Implementation

[0021] Embodiments of the present invention relate to preventing man-in-the-middle attacks, replay attacks, and other deceptive interactions. Embodiments prevent these deceptive interactions by verifying the authenticity of the interaction and its parameters. A first party (e.g., a “sender”) may initiate an interaction via a first device (e.g., a “sender device”) to send value to a second party (referred to as a “receiver”). The sender initiates the interaction by selecting the value to be sent, selecting the account from which the value will be received, and instructing the recipient to receive the value. The sender device can then generate a cipher for the interaction. The cipher can be generated using a key associated with the sender, information identifying the sender, and information identifying the recipient.

[0022] When an interaction request is sent to the interaction processing computer, the computer can use the corresponding key, the sender identification information included in the interaction details, and the receiver identification information included in the interaction details to verify the authenticity of the password. If the password is successfully verified, the interaction processing computer verifies that the sender legitimately requested the interaction and that the information about the sender and receiver in the interaction details has not been altered (e.g., due to a man-in-the-middle attack).

[0023] Therefore, the password goes beyond verifying that the sender initiated the interaction (which can happen in some interactions). The implementation allows the password to further verify that the recipient chosen by the sender has not been changed.

[0024] In some implementations, the sender-identifying information and / or receiver-identifying information may include an account identifier or account token. Therefore, the interaction processing computer can verify that the account from which interaction values ​​are retrieved and deposited has not been altered.

[0025] Embodiments of the present invention also allow for the creation and verification of a recipient password. The recipient device can consent to the interaction by providing account information (e.g., a token) and by generating and providing a second password. In addition to a first password from the sender device, the interaction processing computer can verify this password. As a result, the interaction processing computer can verify that the recipient has agreed to the same interaction details as the sender. Therefore, it is possible to verify that the same interaction parameters are agreed upon by both the sender and the recipient, and that the interaction details are not altered during message exchange between the sender, the recipient, and / or the interaction processing computer.

[0026] Embodiments of this invention are applicable to any suitable interaction of any suitable type of value. For example, embodiments allow a sender to transfer property rights, access codes and passwords, event tickets, security documents and data, monetary funds and / or any other suitable value from a sender's account to a receiver's account.

[0027] Before discussing specific embodiments of the present invention, some terms can be described in detail.

[0028] "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Instances of interaction include transactions between two parties and data exchange between two devices.

[0029] An "interaction request" can be an attempt to initiate communication, contact, or exchange. An interaction request may include a message sent to the interaction processing entity. An interaction request may include any suitable information for performing the interaction, such as interaction details, authentication information (e.g., one or more passwords), and any other suitable information. An example of an interaction request can be a transaction request.

[0030] "Interaction details" can include information associated with communication, contact, or exchange. Interaction details can indicate different entities on which the interaction takes place and the value or information exchanged. Interaction details can include value, information associated with the sender (e.g., token or account information, alias, device identifier, contact address, etc.), information associated with the receiver (e.g., token or account information, alias, device identifier, contact address, etc.), one-time values ​​(e.g., random values, one-time non-repeating random numbers (nonce), timestamps, counts, etc.), and / or any other suitable information. An example of interaction details can be transaction details.

[0031] A "key" can refer to a piece of information used in a cryptographic algorithm to transform input data into another representation. Keys can include symmetric keys and asymmetric keys. A cryptographic algorithm can be an encryption algorithm that transforms raw data (e.g., plaintext) into an alternative representation (e.g., ciphertext), or a decryption algorithm that transforms encrypted information (e.g., ciphertext) back into raw data (e.g., plaintext). Examples of cryptographic algorithms can include Triple Data Encryption Standard (TDES), Data Encryption Standard (DES), Advanced Encryption Standard (AES), etc.

[0032] A "password" can include encrypted information (such as ciphertext). For example, a password can be a value that is the result of data elements being input into a cryptographic algorithm and then encrypted. Passwords can be used to verify data integrity. A password generated using that symmetric key can be decrypted using the same symmetric key. A password generated using the corresponding private key can be verified using the corresponding private key.

[0033] The term "public / private key pair" can include a pair of associated cryptographic keys generated by an entity. The public key can be used for public functions, such as encrypting messages to be sent to the entity, or for verifying digital signatures that should be made by the entity. The private key, on the other hand, can be used for private functions, such as decrypting received messages or applying digital signatures. The public key can be authorized by a subject called a Certificate Authority (CA), which stores the public key in a database and distributes it to any other entity that requests it. The private key is generally kept in a secure storage medium and is typically known only to the entity. However, the cryptographic system described herein can be characterized by a key recovery mechanism for recovering lost keys and preventing data loss. Public and private keys can be in any suitable format, including formats based on RSA or Elliptic Curve Cryptography (ECC).

[0034] A "digital signature" or "signature" can refer to the result of an algorithm applied based on a public / private key pair. A digital signature allows the signer to assert the authenticity and integrity of a message, document, or other information, and the verifier to verify it. The signer uses their private key, and the verifier uses their public key. This process proves the authenticity of the sender, the integrity of the signed message, and the principle of non-repudiation, which does not allow for the denial of signed content. A message, document, certificate, or other data that includes the signer's digital signature is said to be "signed" by the signer.

[0035] "Recipient information" may include data associated with a recipient. Recipient information may identify the recipient, the recipient's device, the recipient's account, or something else associated with the recipient. For example, recipient information may include a phone number, email address, mobile device identifier, account number, token, name, alias, or any other suitable information.

[0036] "Sender information" may include data associated with a provider. Sender information can identify the sender, the sender's device, the sender's account, or something else associated with the sender. For example, sender information may include a phone number, email address, mobile device identifier, account number, token, name, alias, or any other suitable information.

[0037] An "alias" can include an identifier used to refer to a person or entity also known by a more familiar name. For example, an alias can be a title, name, idiom, code, label, or other indicator that identifies a person, organization, device, or account. An alias can be a secondary name that can be used in place of a primary name, or a pseudonym used to protect a person's identity. In some implementations, an alias can be associated with a context or situation. For example, an alias can be a name associated with an individual within a specific network.

[0038] A “device identifier” may include any suitable information used to identify the device. Examples of device identifiers include MSISDN, telephone number, SMS text address, IP address, or any other information that can be used to identify a mobile device. In some implementations, the device identifier may include a unique device number, such as an International Mobile Station Equipment Identifier (IMEI) number, a unique serial number for a Subscriber Identity Module (SIM) card (i.e., an Integrated Circuit Card Identifier (ICCI)), or a unique International Mobile Subscriber Identity (IMSI).

[0039] An "interaction confirmation request" may include a message soliciting acceptance of the interaction. For example, an interaction confirmation request may be sent to ask an entity (such as a recipient) whether it wants to continue the interaction. An interaction confirmation request may include interaction details, such as value, information about the sender, information about the recipient, and / or any other suitable information. An example of an interaction confirmation request may be a transaction confirmation request.

[0040] An "interaction confirmation response" may include a message indicating whether the interaction has been accepted. For example, an interaction confirmation request may be sent in response to an interaction confirmation request, and the message may indicate whether an entity (e.g., a recipient) has agreed to continue the interaction. An interaction confirmation response may include interaction details, such as value, information about the sender, information about the recipient, and / or any other suitable information. An example of an interaction confirmation response may be a transaction confirmation response.

[0041] A "payment credential" may include any suitable information associated with an account (e.g., the payment account and / or payment device associated with the account). Such information may be directly related to the account or derived from information associated with the account. Examples of payment credentials may include a PAN (primary account or "account"), user name, expiry date, and verification value such as CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. An example of a PAN is a 16-digit number, such as "4147 0900 0000 1234".

[0042] A "digital wallet" can include an electronic device that allows individuals to conduct e-commerce transactions. An e-wallet can store user profile information, payment credentials, bank account information, one or more digital wallet identifiers, and can be used in various transactions, such as but not limited to e-commerce, social networks, money transfers / personal payments, mobile commerce, proximity payments, etc., for retail purchases, digital goods purchases, utility payments, and inter-user fund transfers. Digital wallets can be designed to simplify the purchasing and payment process. A digital wallet allows users to load one or more payment cards onto it for payments without having to enter an account number or present a physical card.

[0043] A "token" can be an alternative value for a credential. A token can be a string of numbers, letters, or any other suitable characters. Examples of tokens include payment tokens, access tokens, personal identification tokens, etc.

[0044] A "payment token" may include an identifier for a payment account, which is an alternative to an account identifier such as a primary account number (PAN). For example, a token may include a string of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the PAN "4147 0900 0000 1234". In some embodiments, the token may be "preserved format" and may have a numerical format consistent with account identifiers used in existing transaction processing networks (e.g., ISO 8583 Financial Transaction Message Format). In some embodiments, the token may be used in place of the PAN to initiate, authorize, process, or resolve payment transactions, or to represent the original credentials in other systems where the original credentials would typically be provided. In some embodiments, the token value may be generated such that the original PAN or other account identifier cannot be recovered from the token value through computation. Additionally, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity issuing the token.

[0045] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers that work like cells. In one example, a server computer can be a database server coupled to a web server. A server computer can be coupled to a database and can include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers.

[0046] Figure 1 A system 100 comprising several components is illustrated. System 100 includes a transmitter device 110 operated by a transmitter 111 and a receiver device 120 operated by a receiver 121. System 100 also includes a coordinating computer 115, an interactive processing computer 150, a transmitting computer 160, a receiving computer 130, and a transmitting computer 140, implemented by one or more computers. The transmitter device 110, receiver device 120, coordinating computer 115, interactive processing computer 150, transmitting computer 160, receiving computer 130, and transmitting computer 140 can all interoperate and communicate through any suitable communication channel or communication network. A suitable communication network can be any one and / or a combination of the following: direct interconnection, the Internet, a local area network (LAN), a metropolitan area network (MAN), an Operational Mission as an Internet node (OMNI), a secure custom connection, a wide area network (WAN), a wireless network (e.g., using protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.), etc.

[0047] Messages between computers, networks, and devices can be transmitted using secure communication protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); Secure Sockets Layer (SSL); ISO (e.g., ISO 8583).

[0048] In system 100, sender 111 and receiver 121 can be individuals, organizations, or any other suitable entities associated with an account. Sender 111 can initiate an interaction between sender 111 and receiver 121, such that value can be transferred from the sender's account at sending organization computer 160 to the receiver's account at receiving organization computer 130.

[0049] Any suitable type of interaction can be performed to transfer any suitable type of value. For example, sender 111 can transfer monetary funds to receiver 121 (e.g., through a financial transaction). As other examples, senders can transfer access credentials (e.g., passwords and keys), digital files, event tickets, etc.

[0050] In one implementation, the sender 111 and the receiver 121 can be individuals or friends, and the sender 111 can send monetary value as a gift or to reimburse the receiver 121 for any expenses incurred. In another scenario, the sender 111 can be a consumer, and the receiver 121 can be a merchant participating in a transaction and selling goods or services or providing access to goods or services. In this case, the sender 111 can send monetary value in exchange for goods or services provided by the receiver 121.

[0051] Sender 111 can initiate an interaction using sender device 110. Sender device 110 can then provide interaction details to coordinating computer 115, which can then obtain additional interaction data from receiver device 120. In some embodiments, sender device 110 and / or receiver device 120 may also provide a password for interaction authentication. Coordinating computer 115 can then send all interaction details to interaction processing computer 150, which can then facilitate the transfer of value from the sender's account at sending agency computer 160 to the receiver's account at receiving agency computer 130.

[0052] The sender device 110 and the receiver device 120 can be mobile devices, laptop computers, desktop computers, or any other suitable type of user device, respectively. Figure 2The diagram illustrates an example of a sender device 110 in the form of a mobile device according to some embodiments of the present invention. In some embodiments, a receiver device 120 may take a similar form. The sender device 110 may include circuitry for enabling certain device functions, such as telephone. Functional elements responsible for implementing these functions may include a processor 110A, which can execute instructions to implement the functions and operations of the device. The processor 110A may access memory 110E (or another suitable data storage area or element) to retrieve instructions or data used in executing instructions, such as providing scripts and mobile applications. Data input / output elements 110C, such as a keyboard or touchscreen, may be used to enable a user to operate the sender device 110 and input data (e.g., user authentication data). The data input / output elements may also be configured to output data (e.g., via a speaker). A display 110B may also be used to output data to a user. A communication element 110D may be used to enable data transmission between the sender device 110 and a wired or wireless network (e.g., via antenna 110H) to facilitate connection to the Internet or other networks and to enable data transmission functionality. The sender device 110 may also include a contactless element interface 110F to enable data transmission between the contactless element 110G and other elements of the device, wherein the contactless element 110G may include secure storage and near-field communication data transmission elements (or another form of short-range communication technology). As described above, a cellular phone or similar device is an example of the sender device 110 that can be used according to embodiments of the invention. However, other forms or types of devices may be used without departing from the basic concept of the invention. For example, the sender device 110 may alternatively take the form of a payment card, a key card, a tablet computer, a wearable device, or, for example, a vehicle such as an automobile.

[0053] The memory 110E may include a coordination application 110J, a token 110K, a key 110L, and any other suitable modules or data. In some embodiments, one or more of these modules or data may be stored in secure memory. The sender device 110 may have any number of mobile applications installed or stored on the memory 110E, and is not limited to these. Figure 2 shown.

[0054] In some implementations, key 110L may be a symmetric key. In some implementations, key 110L may have already been provided by coordinating computer 115, interactive processing computer 150, or any other suitable entity. For example, interactive processing computer 150 may have provided key 110L and / or token 110K during the installation or personalization of coordinating application 110 or at any other suitable time. Key 110L may be unique to the sending device 110. Therefore, the sending device 110 can use key 110L to send data such that only coordinating computer 115 or interactive processing computer 150 can view the data. Similarly, receiving device 120 may also have a key (which may be different from the sending device's key and unique to the receiving device 120).

[0055] In some implementations, sender device 110 may store information associated with sender 111 and / or the sender's account. For example, memory 110E may include a token 110K. Token 110K may be a proxy account identifier that can be used in place of ordinary account credentials. Memory 110E may also include other account information or personal information, such as account credentials, name, address, email address, telephone number, alias, or any other suitable sender 111 identification information. Similarly, receiver device 120 may store information associated with receiver 121 and / or the receiver's account, such as a receiver token associated with the receiver's account.

[0056] The coordination application 110J can be combined with the processor 110A to provide a user interface for the sender 111 to provide input and initiate, facilitate, and manage interactions using the sender device 110. Through the coordination application 110J, the sender 111 can select the value to be transferred, select the account from which the value will be withdrawn, and instruct the recipient. The sender 111 can enter the recipient's contact address (e.g., a phone number or email address), enter the recipient's name or alias, select the recipient 121 from a list of known contacts, or identify another possible recipient 121. The coordination application 110J can then send an interaction request with the selected interaction details to the coordination computer 115.

[0057] The coordination application 110J can be combined with the processor 110A to store and / or access the token 110K, along with other account credentials and sender information. Therefore, when initiating an interaction, the coordination application 110J can send the token 110K to the coordination computer 115. In some embodiments, the token 110K may be stored on a secure element in the sender device 110.

[0058] The coordination application 110J can also generate ciphers for interaction. In some implementations, cipher generation may occur in a secure element or other secure memory of the sender device 110. The secure element may be a tamper-proof platform (e.g., a single-chip secure microcontroller) capable of securely hosting the application and its credentials and cipher data.

[0059] In some implementations, the sender device 110 may prompt the sender 111 for authentication information before granting access to the coordination application 110J, before initiating an interaction, before using the token 110K, before generating a password, or at any other suitable time. For example, user authentication can be used to gain access to the secure element. User authentication may include a PIN, password, biometric input (such as a fingerprint, voice sample, or eye scan), or any other suitable information that identifies the individual.

[0060] The sender's password can be generated using a key and any suitable cryptographic algorithm. In addition to the key, several other pieces of information can be used to generate the sender's password. For example, inputs used to generate the sender's password may include transaction details, such as information about the value transferred (e.g., payment amount) and sender account information (e.g., token 110K). Additional inputs may include a one-time, non-repeating random number (which can be generated at the time the interaction was initiated), a random number, a timestamp, a count, and / or any other suitable information.

[0061] In some implementations, a sender password can be used to verifiably associate additional sender information with the interaction. For example, additional input for the sender password may include information about the sender, such as sender contact information (e.g., phone number or email address), sender alias, sender device ID, and / or sender's digital wallet identifier.

[0062] Similarly, in some implementations, additional recipient information can be verifiably associated with the interaction via a sender's password. For example, additional input for the sender's password may include information about the recipient, such as the recipient's name or alias, the recipient's contact address (e.g., email address or telephone number), and / or the recipient's account information (e.g., a recipient token). Some or all of the sender's identification information and the recipient's identification information may be hashed before being included in the interaction request or used as password input.

[0063] As a result, the sender's password can be used to bind different data fields together in an interaction request. For example, in some implementations, the sender's password can prove that sender 111 authorized the interaction because it can be generated using a key and token 110K in a secure element (which can only be accessed by user authentication). The sender's password can also prove that a specific sender account was selected for the current interaction. In another implementation, the sender's password can prove that the interaction value is intended for a specific recipient because it can be generated using information about the intended recipient (e.g., alias, contact address, token, account, device identifier, wallet identifier, etc.).

[0064] As mentioned above, the receiver device 120 can also employ, for example... Figure 2 The mobile device shown is in the form of a receiver device 120. The receiver device 120 may have similar functionality to that described above for the sender device 110. The receiver device 120 may also include a key (e.g., a symmetric key uniquely used for communication between the receiver device 120 and the interactive processing computer 150), a token, and a coordination application.

[0065] The coordination application on receiver device 120 can provide a user interface for receiving notifications about initiated interactions and accepting said interactions. Receiver 121 can select options for acknowledging and agreeing to the interaction. Receiver 121 may also be able to indicate the account used to receive transferred values.

[0066] The coordinating application at the receiver device 120 can also generate a password. This receiver password can be a second password, in addition to the first password from the sender, used to verify the details of the interaction. The receiver password can be generated using one or more values ​​that are the same as or different from the sender password. For example, the receiver password can be generated using the receiver key, information about the value being transferred (e.g., the payment amount), and receiver account information (e.g., the receiver token). Additional inputs may include a one-time non-repeating random number (which can be generated at the time the interaction is initiated), a random number, a timestamp, and / or any other suitable information.

[0067] In some implementations, a recipient password can be used to verifiably associate additional recipient information with the interaction. For example, additional input for the password may include information about the recipient, such as recipient contact information (e.g., phone number or email address), recipient device ID, recipient alias, and / or the recipient's digital wallet identifier.

[0068] Similarly, in some implementations, additional sender information can be verifiably associated with the interaction via a recipient password. For example, additional input for the recipient password may include information about the sender, such as sender information provided via an interaction notification. Sender information may include a sender alias, sender contact address (e.g., email address or phone number), and / or sender account information (e.g., sender token). Some or all of the sender identification information and recipient identification information may be hashed before being included in the interaction request or used as password input.

[0069] As a result, the recipient password can be used to bind together different data fields in an interaction request and information associated with the recipient's acceptance of the interaction. For example, in some implementations, the recipient password can prove that the recipient accepted the transfer because it can be generated using keys and tokens in a secure element (e.g., one that can be accessed only by user authentication). The recipient password can also prove that a specific receiving account was selected to receive the transferred value. In another implementation, the password can prove that the transferred value was sent by a specific sender because it can be generated using the sender's information (e.g., alias, contact address, token, account, device identifier, wallet identifier, etc.).

[0070] Therefore, two different passwords can be used to verify that the interaction in progress is the one that was agreed upon. Two passwords can be generated using similar information, indicating that the sender and receiver have agreed to the same interaction details.

[0071] Refer to Figure 1 The coordinating computer 115 can coordinate interactions initiated between the sender 111 and the receiver 121. The coordinating computer 115 can obtain information for processing the interactions from both the sender 111 and the receiver 121, and then provide this interaction information to the interaction processing computer 150 for executing the interactions.

[0072] Figure 3 An example of a coordination computer 115 according to some embodiments of the present invention is shown. The coordination computer 115 includes a processor 115A, a network interface 115B, a user database 115C, and a computer-readable medium 115D.

[0073] Computer-readable medium 115D may include an interaction processing module 115E, an information collection module 115F, a signature module 115G, and any other suitable software modules. Computer-readable medium 115D may also include code executable by processor 115A to implement a method comprising: receiving interaction details and a first password, the interaction details including receiver information, wherein the first password is generated using the receiver information; sending an interaction confirmation request to a receiver device associated with the receiver information; receiving an interaction confirmation response from the receiver device; and sending an interaction request including the interaction details and the first password to a second computer, wherein the second computer verifies the first password and coordinates a transfer from sender to receiver.

[0074] The interaction processing module 115E may include code that causes the processor 115A to process the interaction. For example, the interaction processing module 115E may include logic that causes the processor 115A to recognize interaction details received from the sender device 110 and / or the receiver device 120 for the interaction. The interaction processing module 115E may also include instructions for creating an interaction request and sending the interaction request to the interaction processing computer 150. The interaction request may include interaction details, such as information about the sender's and receiver's accounts, information about the interaction value, contact information for the sender and receiver, and any other suitable information. The interaction request may also include one or more passwords.

[0075] The information gathering module 115F may include code that enables the processor 115A to obtain interaction details for the interaction. For example, the information gathering module 115F may include logic that enables the processor 115A to contact the receiver device 120 to obtain receiver account information, receiver password, and any other suitable information that can be used for interaction processing. Instructions may be given to the processor 115A to contact the receiver device 120 after the sender device 110 initiates the interaction and instructs a specific receiver 121 or receiver device 120.

[0076] The signature module 115G may include code that enables the processor 115A to create a digital signature for interaction. For example, the signature module 115G may include logic that enables the processor 115A to use the key 115H (e.g., a private key), any suitable cryptographic algorithm, and some or all of the interaction details to generate a digital signature for interaction.

[0077] In some implementations, the coordinating computer 115 is capable of verifying the cipher received from the sender device 110 and / or the receiver device 120. Instructions and additional keys used for such verification may be included in the signature module 115G or in a separate verification module.

[0078] User database 115C may store information about one or more senders and receivers. In some embodiments, user database 115C may associate a user's alias with specific contact information. For example, receiver 121 may be associated with a specific alias (e.g., the title "Wally72"). Sender 111 may indicate a desire to send value to this alias, and coordinating computer 115 may identify the alias in user database 115C. Coordinating computer 115 may then determine the contact information (e.g., a phone number or email address) associated with this alias in user database 115C, enabling coordinating computer 115 to contact receiver device 120 for additional interaction details.

[0079] In some implementations, user database 115C may store account information about one or more senders and receivers. For example, user database 115C may store sender tokens and / or receiver tokens. As a result, when an interaction is initiated, sender device 110 and / or receiver device 120 may not have to send account information to coordinating computer 115. Instead, the coordinating computer may recognize tokens in user database 115C (e.g., based on aliases, device identifiers, wallet identifiers, or other user identification information).

[0080] In some implementations, the coordinating computer 115 may be a digital wallet computer. The digital wallet computer can store information about the user's payment account and coordinate currency transfers. In this case, the coordinating application at the sender device 110 and the receiver device 120 may be a digital wallet application through which the sender and receiver can initiate payment transactions.

[0081] In another embodiment, the coordination application at the sender device 110 and receiver device 120 can send interaction details directly to the interaction processing computer 150. The interaction processing computer 150 or the sender device 110 can collect the interaction details instead of the coordination computer 115. As a result, the coordination computer 115 can be removed from the system 100.

[0082] Interactive processing computer 150 may be located between sending institution computer 160 and receiving institution computer 130. Transaction processing computer 150 may include data processing subsystems, networks, and operations for supporting and transmitting authorization services, exception document services, and clearing and settlement services. For example, processing network computer 150 may include (e.g., via an external communication interface) a server coupled to a network interface, and an information database. In some embodiments, interactive processing computer 150 may be a transaction processing computer. Furthermore, a transaction processing computer may represent a transaction processing network. Exemplary transaction processing networks may include VisaNet™. A transaction processing network such as VisaNet™ is capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™ specifically includes a VIP system (Visa Integrated Payment System) for processing authorization requests and a Base II system for performing clearing and settlement services. Interactive processing computer 150 may use any suitable wired or wireless network, including the Internet.

[0083] Figure 4 An example of an interactive processing computer 150 according to some embodiments of the present invention is shown. The interactive processing computer 150 includes a processor 150A, a network interface 150B, a token database 150C, a key database 150J, and a computer-readable medium 150D.

[0084] Computer-readable medium 150D may include an interaction processing module 150E, an authentication module 150F, a risk processing module 150G, a tokenization module 150H, and any other suitable software modules. Computer-readable medium 150D may also include code executable by processor 150A for implementing a method comprising: receiving an interaction request including interaction details and a first password, the interaction details including receiver information, wherein the first password is generated using the receiver information; verifying the first password; and coordinating a transfer from sender to receiver.

[0085] Token database 150C may include information about one or more tokens. For example, token database 150C may have token records indicating how different tokens are associated with different groups of payment credentials or other account identifiers. In some embodiments, token records may include additional information about the user or account associated with the token. For example, the token may be associated with a specific contact address (e.g., telephone number or email address), alias, device identifier, organization, or any other suitable information. Some or all of this information may be hashed in the token record. In some embodiments, token records may be stored at a third-party token database or at any other suitable location.

[0086] Key database 150J may include information about one or more keys. For example, key database 150J may include keys associated with one or more user devices, secure elements, digital wallets, coordinating computers, and / or any other suitable entities. Key database 150J may include a first key 150K associated with sender device 110. The first key 150K may be a symmetric key shared only with sender device 110. Additionally, key database 150J may include a second key 150L associated with receiver device 120. The second key 150L may be a symmetric key shared only with receiver device 120. Furthermore, key database 150J may include a third key 150M associated with coordinating computer 115. The third key 150M may be a public key corresponding to a private key at coordinating computer 115. In some embodiments, key database 150J may include information for identifying the key, associated with each key where appropriate. For example, key database 150J may store information about sender device 110 and / or receiver device 120, such as device identifiers, digital wallet identifiers, contact addresses, tokens, names, aliases, or any other suitable information for identifying users and / or devices. Some or all of this information may be hashed in the key record. In some embodiments, the key record may be stored in a third-party key database or any other suitable location.

[0087] The interaction processing module 150E may include code that causes the processor 150A to process the interaction. For example, the interaction processing module 150E may include logic that causes the processor 150A to receive an interaction request and, based on the interaction request, coordinate the transfer of value from the sender's account to the receiver's account. In some embodiments, the interaction processing module 150E may include instructions to coordinate the transaction by sending an AFT ("Account Funds Transaction") message to the sending institution computer 160 and an OCT ("Original Credit Transaction") message to the receiving institution computer 130.

[0088] The verification module 150F may include code that causes the processor 150A to verify the interaction request. For example, the verification module 150F may include logic that causes the processor 150A to verify one or more ciphers associated with the interaction, such as a sender's cipher and / or a receiver's cipher. The verification module 150F may also include instructions for verifying a digital signature from the coordinating computer 115. In embodiments of the invention, the verification module 150F may include any suitable cryptographic algorithm. Suitable data cryptography algorithms may include DES, triple DES, and AES, etc. Keys that can be used for cryptographic algorithms may also be stored or accessed (e.g., at a key database 150J). Symmetric and / or asymmetric encryption techniques may be used.

[0089] In some implementations, the sender password can be verified by recreating the sender password using some or all of the interaction details (e.g., information of the same type used to create the sender password on sender device 110), a key associated with sender device 110 (e.g., first key 150K), and any suitable cryptographic algorithm (e.g., the same algorithm used to create the sender password on sender device 110). If the recreated password matches the received password, the sender password can be considered verified, and the interaction details are thus verified. In alternative implementations, the sender password can be verified by decrypting the sender password using a key associated with sender device 110 (e.g., first key 150K). The decrypted information can then be compared with the received interaction details, and if they match, the sender password can be considered verified, and the interaction details are thus verified. A similar verification method and a key associated with receiver device 120 (e.g., second key 150L) can be used to verify the receiver password.

[0090] In some implementations, a key associated with the coordinating computer 115 (e.g., a third key 150M) and any suitable verification algorithm can be used to verify digital signatures from the coordinating computer 115.

[0091] In other implementations, the sender's password and / or the receiver's password can alternatively be a digital signature. Furthermore, the digital signature of the coordinating computer can alternatively be a password. In any of these cases, suitable types of keys and verification methods as described above for passwords and digital signatures can be used. For example, if the sender's password and / or the receiver's password are alternatively replaced by a digital signature, then the sender device 110 and / or the receiver device 120 can store a private key instead of a symmetric key, and the interactive processing computer 150 can store the corresponding public key.

[0092] In some implementations, both sender and receiver passwords can be generated based on both sender and receiver identification information. Therefore, both passwords can indicate that the interaction is between a specific sender 111 and receiver 121. If both passwords are verified to be associated with the same sender and receiver, the interaction processing computer 150 can be confident that sender 111 and receiver 121 agree to the same interaction, and that no details have been fraudulently altered during the sending and receiving of messages related to the interaction.

[0093] The verification module 150F may also include instructions that cause the processor 150A to verify that the sender token and receiver token are being used appropriately. For example, the instructions may include checking that an interaction request involving a particular token is accompanied by a specific contact address (e.g., a telephone number or email address), an alias, and / or a device identifier associated with the token, as indicated by a token record in the token database 150C.

[0094] The risk processing module 150G may include code that enables the processor 150A to analyze the risks of the interaction. For example, the risk processing module 150G may include logic that enables the processor 150A to analyze the interaction speed, value or amount thresholds, and other possible risk indications. Risk scores can be created and used to assess whether to authorize a transaction.

[0095] The tokenization module 150H may include code that causes the processor 150A to tokenize and detoxify account identifiers. For example, the tokenization module 150H may include logic that causes the processor 150A to receive a token, identify a matching stored token, determine the account identifier or other payment credential associated with the matching stored token, and then provide or use the account identifier.

[0096] Refer to Figure 1 The sending organization computer 160 can be associated with a sending organization, which can be an entity that sends value. The sent value can be withdrawn from the sender's account. An example of a sending organization can be an issuer, which can typically refer to a commercial entity (e.g., a bank) that maintains a user's (e.g., the sender's) account. The issuer can also issue and manage accounts (e.g., payment accounts) associated with the sender device 110.

[0097] The receiving institution computer 130 may be associated with a receiving institution, which may be an entity that receives value. The received value may be credited to the recipient's account. An example of a receiving institution may be an acquiring party, which is typically a commercial entity (e.g., a commercial bank) that has a business relationship with a particular recipient (e.g., a merchant) or other entity. In some implementations, the receiving institution computer 130 may also be an issuer.

[0098] The transmitting computer 140 can be an intermediary or account. In some embodiments, interactive values ​​transferred from the sending computer 160 may first go to the transmitting computer 140. The value can then be transferred from the transmitting computer 140 to the receiving computer 130. In some embodiments, the transmitting computer 140 can be an acquirer or an acquirer processor.

[0099] The interactive processing computer 150, the sending agency computer 160, the receiving agency computer 130, and the transmitting computer 140 can run appropriate routing tables to route authorization request messages and / or authorization response messages using payment credentials, merchant identifiers, or other account identifiers.

[0100] You can refer to Figure 5 Method 500 according to an embodiment of the present invention will be described below. Reference will also be made to some elements in other figures. In embodiments of the invention, the steps shown in method 500 may be performed sequentially or in any suitable order. In some embodiments, one or more of the steps may be optional.

[0101] The various messages described below can use any suitable form of communication. In some implementations, the request or response can have an electronic message format, such as email, Short Message Service (SMS) message, Multimedia Messaging Service (MMS) message, Hypertext Transfer Protocol (HTTP) request message, Transmission Control Protocol (TCP) packet, or web form submission. The request or response can point to any suitable location, such as an email address, telephone number, Internet Protocol (IP) address, or Uniform Resource Locator (URL). In some implementations, the request or response can include a mixture of different message types, such as both email messages and SMS messages.

[0102] The following method describes a transaction involving the transfer of monetary funds from a first party to a second party. However, as explained above, the implementation allows for any suitable type of interaction, and allows the first party to transfer any suitable type of value to the second party. For example, security data, access credentials, event tickets, login codes and passwords, monetary funds, and any other suitable data, value, or object can have their ownership changed by moving from a first account to a second account.

[0103] One or more keys may be distributed before a transaction is initiated. For example, at step S501a, the interaction processing computer 550 may provide a first key (e.g., a symmetric key) to the sender device 510. The sender device 510 may store the first key (e.g., in a complete component), and the interaction processing computer 550 may also store a copy of the first key. In some embodiments, this key may be provided along with the token during token provision and / or application personalization.

[0104] At step S501b, the interactive processing computer 550 may provide a second key (e.g., a symmetric key) to the receiving device 520. The receiving device 520 may store the second key (e.g., in a complete element), and the interactive processing computer 550 may also store a copy of the second key. In some embodiments, this key may be provided along with the token during token provision and / or application personalization.

[0105] At step S501c, the interactive processing computer 550 may receive a third key (e.g., a public key) from the coordinating computer 515. The third key may be a public key corresponding to the private key at the coordinating computer 515. The interactive processing computer 550 may store the third key.

[0106] At a later time, the first party (called the sender) may want to send payment to the second party (called the recipient). For example, the sender may intend to pay the recipient for one or more goods or services, or to send a gift.

[0107] At step S502, the sender can activate a coordinating application (which may be a digital wallet application) on the sender device 510. To log in to the coordinating application and / or enable payment functionality on the sender device 510, the sender can provide authentication information. For example, the sender can enter a PIN or password, or provide biometric authentication information such as a fingerprint or eye scan.

[0108] After accessing the coordination application, the sender can select the options used to send the payment. The sender can also provide information about the payment, such as the payment amount and the sender's account from which funds are withdrawn. For example, the sender can select an account associated with their digital wallet or provide information for a new account. In some implementations, a default account (e.g., based on the sender's digital wallet or device identifier) ​​can be automatically selected and used.

[0109] The sender may also provide information that identifies the recipient and / or the recipient's account. For example, the sender may enter the recipient's name or alias, the recipient's contact information (such as an email address or phone number), or a recipient token.

[0110] At step S504, the sender device 510 may obtain a payment token associated with the account selected for the transaction. For example, the sender device 510 may retrieve a payment token stored in the secure element of the sender device 510 (this may involve additional user authentication). Alternatively, the sender device 510 may request a payment token from a token provider computer (e.g., wirelessly).

[0111] Additionally, the sender device 510 can generate a password for payment. The password can be generated using a key (e.g., a symmetric key), any suitable cryptographic algorithm, and one or more transaction-related details. For example, inputs for generating the password may include the payment amount, the sender's payment token, a one-time non-repeating random number (which may be generated at the time the transaction is initiated), a random number, a timestamp, a counter, and / or any other suitable information. Additional inputs for the password may include information about the sender, such as the sender's digital wallet identifier, sender device ID, sender's name or alias, and / or sender contact information (e.g., telephone number or email address). In some implementations, the password may also be generated using information about the recipient, such as the recipient's name or alias, recipient's contact address (e.g., email address or telephone number), and / or recipient's account identifier (e.g., recipient token). Some or all of the user identification information may be hashed before being used as password input or additionally included in the payment request.

[0112] At step S506, the coordinating application enables the sender device 510 to send a payment instruction and associated password to the coordinating computer 515 (which may be a computer providing digital wallet services). The payment instruction may include a sender token, amount, recipient identification information (e.g., alias, contact information, token, wallet identifier, or device identifier) ​​and / or any other suitable information. Some or all of this information may be included in plaintext. In some embodiments, the payment instruction may include additional information for verifying the password. For example, the payment instruction may include a timestamp, a one-time non-repeating random number, a random number, and information about the sender, such as the sender's digital wallet identifier, sender device ID, and / or sender contact information (e.g., telephone number or email address), some or all of which may be hashed.

[0113] In step S508, after receiving the payment instruction, the coordinating computer 515 can notify the recipient that the payment has been initiated. The coordinating computer 515 can identify the information indicated in the payment instruction for contacting the recipient, such as the recipient's phone number, email address, or digital wallet identifier. The coordinating computer 515 can then send a transaction confirmation request to the recipient device 520 (e.g., via SMS message, email, wallet notification, etc.). The request can indicate the amount to be transferred and information about the sender (e.g., name, alias, phone number, etc.). The request can prompt the recipient device 520 to acknowledge acceptance of the transaction and provide account information for receiving the transferred value.

[0114] In step S510, the recipient can activate the coordination application on the recipient device 520 and view the payment notification. The recipient can confirm that the payment should be accepted (e.g., by selecting the "Accept" option). To accept, the recipient may be prompted to perform self-authentication. The recipient can then proceed to enter a PIN or password, or provide biometric authentication information, such as a fingerprint or eye scan.

[0115] The recipient can also provide information about an account that can be used to deposit the transferred value. In some implementations, the recipient can select an account already associated with the recipient's device 520 or digital wallet. Alternatively, the recipient can enter new account information.

[0116] At step S512, the receiving device 520 may obtain a payment token associated with the selected account. For example, the receiving device 520 may retrieve a payment token stored in the secure element of the receiving device 520. Alternatively, the receiving device 520 may request a payment token from a token provider's computer (e.g., wirelessly). In other embodiments, a physical payment credential (e.g., represented by the payment token) may be obtained.

[0117] Additionally, the recipient device 520 can generate a password for payment (e.g., at the secure element). The password can be generated using a key (e.g., a symmetric key), any suitable cryptographic algorithm, and details related to one or more transactions. For example, inputs for generating the password may include the recipient's payment token (or other account information), the payment amount, a one-time non-repeating random number, a random number, a timestamp, and / or any other suitable information. The password can also be generated using information about the recipient, such as a recipient alias, recipient contact address (e.g., email address or phone number), wallet identifier, or device identifier. Additional inputs for the password may include information about the sender, such as any sender information sent from the digital wallet computer 515 to the recipient device 520. This may include the sender's payment token, the sender's digital wallet identifier, the sender's device ID, the sender's alias, and / or the sender's contact information (e.g., phone number or email address).

[0118] At step S514, the coordinating application can cause the recipient device 520 to send a transaction confirmation response and a password to the coordinating computer 515. The transaction confirmation response may include a recipient token, an amount, information identifying the recipient (e.g., alias, contact information, token, wallet identifier, or device identifier), information identifying the sender, and / or any other suitable information. In some embodiments, some or all of this information may be included in plaintext. In some embodiments, some or all of the sender identification information and recipient identification information may be hashed before being included in the payment instruction or used as password input. In some embodiments, the payment instruction may include additional information for verifying the password. For example, the payment instruction may include a timestamp, a one-time non-repeating random number, and / or a random number.

[0119] The coordinating computer 515 can now have a sender payment token, a receiver payment token, and an amount. The coordinating computer 515 can also have information for verifying transaction details, such as the sender's password, the receiver's password, various identification information, and other transaction-related data. Therefore, the coordinating computer 515 can have the necessary information for command transfer.

[0120] At step S516, the coordinating computer 515 may create a digital signature based on some or all of the information (or the hash of the information) received from the sender device 510 and the receiver device 520. The digital signature may be generated using a coordinating computer key (e.g., a private key) and any suitable cryptographic algorithm.

[0121] At step S518, the coordinating computer 515 may send a transfer instruction to the interactive processing computer 550. The instruction may include some or all of the data received from the sender device 510 and the receiver device 520, as well as a digital signature. In some embodiments, the transfer instruction may include transaction details in plaintext and a ciphertext and digital signature as ciphertext.

[0122] At step S520, the interactive processing computer 550 can verify that the information received from the coordinating computer 515 is legitimate and has not been altered by verifying the digital signature. The interactive processing computer 550 can determine the key associated with the coordinating computer 515 (e.g., based on the coordinating computer identifier). For example, the interactive processing computer 550 can identify a third key (e.g., the public key associated with the coordinating computer 515). The interactive processing computer 550 can use the third key and any suitable verification algorithm to verify the digital signature.

[0123] The interactive processing computer 550 can also verify the sender's password. For example, the interactive processing computer 550 can determine the key associated with the sender device 510 (e.g., based on sender information included in the transaction details). The interactive processing computer 550 can identify a first key (e.g., a symmetric key associated with the sender device 510) and can use this first key, some or all of the received transaction details, and any suitable cryptographic algorithm to verify the sender's password. For example, the interactive processing computer 550 can use the first key and the received transaction details to recreate the password. If the second recreated password matches the first received password, the received password can be considered verified. Alternatively, the interactive processing computer 550 can use the first key to decrypt the password (e.g., inverse the cryptographic algorithm used to generate the password) and determine whether the transaction details from the decrypted password match the received transaction details. As a result, the interactive processing computer 550 can confirm that the sender legitimately requested the transaction and that the received transaction details are the same as those specified by the sender.

[0124] Additionally, the interactive processing computer 550 can verify the recipient's password. For example, the interactive processing computer 550 can determine the key associated with the recipient device 520 (e.g., based on recipient information included in the transaction details). The interactive processing computer 550 can identify a second key (e.g., a symmetric key associated with the recipient device 520) and can use this second key, some or all of the received transaction details, and any suitable cryptographic algorithm to verify the recipient's password. For example, the interactive processing computer 550 can use the second key and the received transaction details to recreate the password. If the second recreated password matches the first received password, the received password can be considered verified. Alternatively, the interactive processing computer 550 can use the second key to decrypt the password (e.g., inverse the cryptographic algorithm used to generate the password) and determine whether the transaction details from the decrypted password match the received transaction details. As a result, the interactive processing computer 550 can confirm that the recipient has legitimately agreed to the transaction and that the received transaction details are the same as the transaction details seen by the recipient.

[0125] The interactive processing computer 550 can also perform screening and speed checks, as well as any other suitable type of transaction risk analysis. For example, in some implementations, the interactive processing computer 550 can verify that the transaction request includes other information associated with the sender's token and / or the receiver's token, as indicated by records in a token database. For example, the interactive processing computer 550 can verify that transaction details include contact addresses, device identifiers, or other suitable information matching token database records.

[0126] If the verification in step S520 is successful, the interactive processing computer 550 can authorize the transaction, seek authorization from another entity, and / or perform additional transaction processing. In some implementations, if one or more verifications fail, the transaction can be rejected.

[0127] At step S522, the interactive processing computer 550 can detoxify the sender's payment token and / or the receiver's payment token. The interactive processing computer 550 can identify a set of sender payment credentials (e.g., payment account) associated with the sender's payment token. Similarly, the interactive processing computer 550 can obtain a set of receiver payment credentials associated with the receiver's payment token.

[0128] In steps S524-S534, the interactive processing computer 550 can coordinate the transfer of funds from the sender's account at the sending agency computer 560 to the receiver's account at the receiving agency computer 530.

[0129] For example, at step S524, the interactive processing computer 550 may send a message to the sending institution computer 560, notifying the sending institution computer 560 of matters related to the transfer. For example, the interactive processing computer 550 may provide information about the transfer amount, the sender's account, the recipient's account, and the bank, as well as any other suitable information. In some embodiments, the interactive processing computer 550 may use an AFT (“Account Funds Transaction”) message to instruct the sending institution computer 560 to authorize the transfer, hold funds, and / or transmit funds.

[0130] In step S526, the sending institution computer 560 can authorize the transaction, suspend the transfer of funds, and / or transmit the transferred funds. The sending institution computer 560 can check that the sender's account has sufficient funds and perform other appropriate risk management activities. The sender's account can then be debited, and the transferred funds can be moved to the holding account or, for example, an intermediary bank of the transmitting computer.

[0131] At step S528, the sending computer 560 may notify the interactive processing computer 550 that the transfer has been authorized, the funds have been moved, or otherwise reserved for the transfer.

[0132] At step S530, the interactive processing computer 550 may send a message to the receiving institution computer 530, notifying it of matters related to the transfer. For example, the interactive processing computer 550 may provide information about the transfer amount, the sending bank, the receiving bank, and any other suitable information. The interactive processing computer 550 may also notify the receiving institution computer 530 that the transfer has been authorized at the sending institution computer 560, thus securing the funds. In some embodiments, the interactive processing computer 550 may use an OCT (“Original Credit Transaction”) message to instruct the receiving institution computer 530 to credit the funds to the recipient's account.

[0133] In step S532, the receiving institution computer 530 can credit the transferred value to the recipient's account. As a result, the transferred funds become available to the recipient. The receiving institution computer 530 can also perform any suitable risk management activities.

[0134] At step S534, the receiving computer 530 may notify the interactive processing computer 550 that the recipient's account has been successfully credited. In some embodiments, at a later time, the interactive processing computer 550 may coordinate the settlement and clearing process between the sending computer 560, the receiving computer 530, and / or the transmitting computer.

[0135] At step S536, the interactive processing computer 550 can then proceed to notify the coordinating computer 515 that the transfer has been successfully executed. Next, at step S538, the coordinating computer 515 can notify the sender that the transfer is complete (e.g., by sending a message to the coordinating application on the sender device 510). Additionally, at step S540, the coordinating computer 515 can notify the receiver that the transfer is complete (e.g., by sending a message to the coordinating application on the receiver device 520). In other embodiments, the sender and receiver can be notified directly by the interactive processing computer 550, the sending computer 560, and / or the receiving computer 530.

[0136] Embodiments of the present invention include several alternatives to the methods described above. For example, in some embodiments, the coordinating computer 515 may locally store sender payment tokens and / or receiver payment tokens. The sender and / or receiver may have accounts (e.g., digital wallet accounts) at the coordinating computer 515, eliminating the need to provide account information for each transaction. In practice, the coordinating computer 515 may identify each transaction and use a payment token (or other account information) based on sender and / or receiver identification information (e.g., alias, phone number, device ID, wallet ID, etc.). In some embodiments, a default receiver token may be used automatically, and the receiver device 520 may not be contacted for transaction acceptance.

[0137] In some implementations, the coordinating computer 515 can verify the password generated at the sender's device and / or the receiver's device. In this case, the coordinating computer 515 may have access to one or more keys associated with one or more devices. Alternatively, in some implementations, the sender's password and / or receiver's password may instead be generated by the coordinating computer 115. For example, the coordinating computer may generate the sender's password using the key associated with the sender, the sender's token, and / or any other suitable information.

[0138] In another implementation, the functions performed by the coordinating computer 515 may be performed by the interactive processing computer 550, and the coordinating computer 515 may be removed from the system.

[0139] As mentioned above, the sender's password can be generated using information associated with the recipient, such as a recipient alias or contact address. In another implementation, the sender's password can be generated using the recipient's account information, such as a token or payment account. For example, the sender can enter (e.g., manually type) the recipient's token when initiating a transaction, and the sender's device can then access the recipient's token to generate the password.

[0140] In some implementations, different passwords can be generated for different transaction processing networks. For example, the sender device can generate two passwords: a first password generated using a first key associated with a first transaction processing network, and a second password generated using a second key associated with a second transaction processing network. Additionally, passwords can be generated when there is no network-specific input. For example, the information input associated with the sender and / or receiver could be an alias, contact address, or account identifier in lieu of a token. As a result, the transaction can be verified (e.g., using either the first or second password) regardless of whether it is processed at the first or second network.

[0141] In addition to sender-initiated transactions, the implementation also allows receiver-initiated transactions. For example, the receiver can choose the receiving account, amount, and sender (e.g., using an alias, contact address, etc.). The coordinating computer 515 can then send a transaction confirmation request to the sender device 510. Therefore, the sender can receive a payment request and decide whether to approve sending the payment. If approved, the sender can choose the sending account. The method can be referenced above. Figure 5 The description continues similarly, with the recipient instead providing initial information, and the sender accepting or rejecting the proposed transaction.

[0142] As described above for steps S524-S534, the interactive processing computer 550 can coordinate the transfer of value from the sender's account at the sending institution computer 560 to the receiver's account at the receiving institution computer 530. Many alternatives can be made to this transfer process. For example, in some embodiments, steps S524-S528 can occur directly after step S506. In other words, as soon as the sender initiates the transaction, the coordinating computer 515 and / or the interactive processing computer 550 can notify the sending institution computer 560 of the transfer (e.g., by sending an AFT). As a result, funds can be held, transferred, or otherwise obtained and prepared at an earlier time. Then, once the receiver has accepted the transfer and provided account information, the funds can be sent to the receiving institution computer 530 (e.g., steps S530-S534 can be performed). In some embodiments, if the receiver does not accept the transfer within a specific time frame, the transaction can be cancelled, and the funds can be returned to the sender's account.

[0143] As explained above, in some implementations, funds can initially be transferred from the sending institution's computer 560 to an intermediary bank (e.g., Figure 1 The funds are then transferred from the sending institution's computer 560 to the receiving institution's computer 530 via an intermediary holding account. Alternatively, instead of an intermediary bank, one or more holding accounts can be used at the sending institution's computer 560 or the receiving institution's computer 530. For example, funds can be debited from the sender's account and then transferred to a holding account at the sending institution's computer 560. Once approved by the receiving institution's computer 530, the funds can be transferred to the receiving institution's computer 530. The funds can be credited directly to the recipient's account, or they can be received first at another holding account at the receiving institution's computer 530.

[0144] The embodiments of the present invention have many advantages. For example, in embodiments of the present invention, interaction security can be improved. One method for improving interaction security is to generate a cipher that verifies many interaction details. For example, a sender's cipher can be generated using a first key and interaction details such as a sender's token and a receiver's alias (or other identifying information). The interaction processing computer (or other suitable entity) can verify this cipher using the corresponding key and the received interaction details. Successful cipher verification can indicate that the sender has legitimately requested the interaction because the secure element (e.g., for accessing a payment token and generating a genuine cipher) is inaccessible before the sender is authenticated at the sender's device. The verification can also verify that the received interaction details are the same as the interaction details originally specified by the sender, and therefore the interaction details have not been altered during transmission (e.g., by a man-in-the-middle attack). Any interaction details used to generate the original cipher can be verified. For example, information about the sender (e.g., alias, token, account, etc.), information about the receiver (e.g., alias, token, account, etc.), interaction values, and / or any other suitable information can be verified. You can also use one-time values ​​(such as one-time non-repeating random numbers, timestamps, counts, etc.) to generate sender passwords, which can then be used to verify that the interaction request is unique (e.g., it is not a replay attack).

[0145] Embodiments of the present invention can further enhance interaction security by introducing a recipient password. The recipient password can be generated using interaction details similar to the sender password. However, the recipient password can contain more specific information associated with the recipient, such as a recipient token or account identifier. Furthermore, the recipient password can be generated using a key associated with the recipient. Therefore, verifying the recipient password can indicate that the appropriate recipient has legitimately accepted and approved the interaction because secure elements (e.g., those used to access payment tokens and generate genuine passwords) are inaccessible until the recipient is authenticated at the recipient's device. The verification can also confirm that the recipient token (or other account information) in the interaction details has not been altered (e.g., by a man-in-the-middle attack).

[0146] Embodiments of the present invention can further advantageously use multiple passwords together. For example, for the same interaction, both a sender password and a receiver password can be generated and verified. Two passwords can be generated and verified using the same or similar interaction details. As a result, the interaction processing computer can verify that the sender and receiver agree on the same interaction details, even if they perform the interaction remotely through their respective devices. In other words, the sender and receiver have seen the interaction details at different locations (e.g., physically separate areas) and at different times (e.g., the sender initiates the interaction first, and the receiver sees and accepts the interaction later). The password with the agreed interaction details can verify that the interaction details have not been altered during transmission between the sender's device and the interaction processing computer, between the sender's device and the receiver's device, or between the receiver's device and the interaction processing computer.

[0147] Embodiments of the present invention can further enhance interaction security by digitally signing the interaction details. A coordinating computer, combining the interaction details received from the sending and receiving devices, can create a digital signature based on the interaction details and a key. An interaction processing computer, which receives the interaction details in the interaction request from the coordinating computer, can then verify the digital signature using the corresponding key. Therefore, the interaction processing computer can further be confident that the interaction has not been altered since the transmission from the coordinating computer.

[0148] Embodiments of the present invention advantageously allow interactions without requiring a coordinating computer (e.g., a digital wallet computer) to store and maintain tokens or other account information associated with the sender or receiver. This improves operational efficiency and reduces security risks at the coordinating computer. Embodiments allow tokens to be managed alternatively at the sender and receiver devices. For example, during an interaction, the token can be retrieved from secure storage at the sender device. The token can be sent along with the interaction request but does not need to be stored by the coordinating computer. Similarly, the receiver device can provide the token (or other account information) upon prompting.

[0149] Computer systems that can be used to implement any of the entities or components described herein will now be described. Subsystems within the computer system are interconnected via a system bus. Additional subsystems include printers, keyboards, fixed disks, and monitors, which may be coupled to a display adapter. Peripheral devices and input / output (I / O) devices may be coupled to an I / O controller and may be connected to the computer system via any number of means known in the art, such as serial ports. For example, a serial port or external interface may be used to connect the computer device to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via the system bus allows the central processing unit to communicate with each subsystem and control the execution of instructions from system memory or fixed disks, as well as the exchange of information between subsystems. System memory and / or fixed disks may embody computer-readable media.

[0150] As described above, the services of the present invention may relate to implementing one or more functions, processes, operations, or method steps. In some embodiments, the functions, processes, operations, or method steps can be implemented by executing an instruction set or software code through a suitably programmed computing device, microprocessor, data processor, etc. The instruction set or software code may be stored in a memory or other form of data storage element accessed by the computing device, microprocessor, etc. In other embodiments, the functions, processes, operations, or method steps may be implemented by firmware or a dedicated processor, integrated circuit, etc.

[0151] Any software component or function described in this application can be implemented as software code executed by a processor using any suitable computer language (such as, for example, Java, C++, or Perl) and employing techniques such as conventional or object-oriented methods. The software code can be stored as a series of instructions or commands on a computer-readable medium, such as random access memory (RAM), read-only memory (ROM), magnetic media such as a hard disk drive or floppy disk, or optical media such as a CD-ROM. Any such computer-readable medium can reside on or within a single computing device and can exist on or within different computing devices within a system or network.

[0152] Although some exemplary embodiments have been described in detail and shown in the accompanying drawings, it should be understood that such embodiments are merely illustrative of the invention and not restrictive, and that the invention is not limited to the specific arrangements and structures shown and described, as various other modifications will be apparent to those skilled in the art.

[0153] As used herein, unless explicitly indicated otherwise, the terms "a," "an," or "the" are intended to mean "at least one."

Claims

1. A method for processing interactions, the method comprising: A server computer receives a peer-to-peer interaction request from a sender device via a coordinating computer. The request includes interaction details and a first cipher formed using a first key. The interaction details include receiver information associated with the receiver device, the interaction amount, and a first token. The server computer recreates the first password using the interaction details, the first key, and the encryption algorithm used at the sender device to create the first password; The server computer determines that the recreated first password matches the first password received from the sender device via the coordinating computer; The first password is verified by the server computer; The server computer detoxifies the first token to obtain the sender's credentials; The server computer uses the recipient information to obtain the recipient's credentials. as well as In response to verifying the first password, the server computer coordinates a peer-to-peer transfer of the interaction amount from the sender account associated with the sender credential to the receiver account associated with the receiver credential.

2. The method of claim 1, further comprising, before receiving the peer-to-peer interaction request from the sender device: The server computer provides the first key to the sender device, wherein the first key is a first symmetric key; A copy of the first key is stored by the server computer; The server computer provides a second key to the receiving device, wherein the second key is a second symmetric key; A copy of the second key is stored by the server computer; The server computer receives a third key from the coordinating computer, wherein the third key is a public key corresponding to the private key of the coordinating computer; as well as A copy of the third key is stored by the server computer.

3. The method of claim 2, further comprising, before receiving the peer-to-peer interaction request from the sender device: The server computer provides the first token with the first key; and The server computer provides a second token with the second key.

4. The method of claim 3 further includes detoxing the second token.

5. The method of claim 2, wherein the interaction details further include sender information, wherein the second password is generated using the sender information, and wherein the method further includes verification of the second password by the server computer.

6. The method of claim 5, wherein the first password is generated using the sender information, and the second password is generated using the receiver information, such that both the first password and the second password are generated using the sender information and the receiver information.

7. The method according to claim 6, further comprising: The server computer determines the first key associated with the sender device, wherein the first password is verified using the first key; The server computer determines the second key associated with the receiving device, wherein the second password is verified using the second key; The server computer determines the third key associated with the coordinating computer, wherein the peer-to-peer interaction request includes a digital signature generated by the coordinating computer using the interaction details; as well as The server computer verifies the digital signature using the third key.

8. The method of claim 1, further comprising, prior to coordinating the peer-to-peer transfer from the sender's account to the recipient's account, authorizing the peer-to-peer transfer from the sender's account to the recipient's account based on a verified first password. The authorization of the peer-to-peer transfer includes analyzing the interaction speed.

9. A server computer, comprising: processor; as well as A computer-readable medium comprising code executable by the processor to perform a method including the following operations: The server computer receives a peer-to-peer interaction request from the sender device via a coordinating computer, including interaction details and a first cipher formed using a first key, the interaction details including receiver information associated with the receiver device, the interaction amount, and a first token. The server computer recreates the first password using the interaction details, the first key, and the encryption algorithm used at the sender device to create the first password; The server computer determines that the recreated first password matches the first password received from the sender device via the coordinating computer; The first password is verified by the server computer; The server computer detoxifies the first token to obtain the sender's credentials; The server computer uses the recipient information to obtain the recipient's credentials. as well as In response to verifying the first password, the server computer coordinates a peer-to-peer transfer of the interaction amount from the sender account associated with the sender credential to the receiver account associated with the receiver credential.

10. The server computer of claim 9, further comprising, before receiving the peer-to-peer interaction request from the sender device: The server computer provides the first key to the sender device, wherein the first key is a first symmetric key; A copy of the first key is stored by the server computer; The server computer provides a second key to the receiving device, wherein the second key is a second symmetric key; A copy of the second key is stored by the server computer; The server computer receives a third key from the coordinating computer, wherein the third key is a public key corresponding to the private key of the coordinating computer; as well as A copy of the third key is stored by the server computer.

11. The server computer of claim 10, further comprising, before receiving the peer-to-peer interaction request from the sender device: The server computer provides the first token with the first key; and The server computer provides a second token with the second key.

12. The server computer of claim 11, wherein the method detoxifies the second token.

13. The server computer of claim 10, wherein the interaction details further include sender information, wherein the second password is generated using the sender information, and wherein the method further includes the server computer verifying the second password.

14. The server computer according to claim 13, the method further comprising: The server computer determines the first key associated with the sender device, wherein the first password is verified using the first key; The server computer determines the second key associated with the receiving device, wherein the second password is verified using the second key; The server computer determines the third key associated with the coordinating computer, wherein the peer-to-peer interaction request includes a digital signature generated by the coordinating computer using the interaction details; as well as The server computer verifies the digital signature using the third key.

15. A method for processing interactions, the method comprising: The server computer receives a confirmation response from the receiving device via a coordinating computer for a peer-to-peer interaction request that includes interaction details and a second password. The confirmation response includes recipient information associated with the receiving device, the interaction amount, and the second token. The server computer uses the second key to decrypt the second password; The server computer determines the interaction details from the decrypted second password; The server computer determines that the interaction details from the decrypted second cipher match the interaction details received from the receiving device via the coordinating computer; The second password is verified by the server computer; The server computer detoxifies the second token to obtain the recipient's credentials; The sender's credentials are obtained by the server computer; as well as In response to verifying the second password, the server computer coordinates a peer-to-peer transfer from the sender account associated with the sender credentials to the receiver account associated with the receiver credentials.

16. The method of claim 15, wherein the interaction details include transaction details.

17. The method of claim 16, wherein the transaction details include sender account information.

Images