Interaction messaging using sender and receiver devices

Abstract

One embodiment includes a method comprising: receiving, by a processing network computer from a digital repository on a first user device, a pull message comprising a resource; identifying, by the processing network computer, a source encrypted identifier based on information associated with the digital repository; initiating, by the processing network computer via a source authorizing entity computer that issued a source account identified by the source encrypted identifier, pulling the resource from the source account; receiving, by the processing network computer from the digital repository on the first user device, a destination encrypted identifier for a destination account issued by a destination authorizing entity computer and an push message requesting to push the resource to the destination account; and executing, by the processing network computer, a process to push the resource to the destination account using a destination account identifier associated with the destination encrypted identifier.

Description

INTERACTION MESSAGING USING SENDER AND RECEIVER DEVICESCROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application claims benefit under 35 U.S.C. § 119(e) to U.S. Provisional Patent Application No. 63 / 655,773 filed June 4, 2024, and entitled "INTERACTION MESSAGING USING SENDER AND RECEIVER DEVICES” the disclosure of which is incorporated by reference herein in its entirety for all purposes.BACKGROUND

[0002] Methods for transferring funds from a source account of a first user to a destination account of a second user require extensive set-up which can be time consuming and deter users. Transfer systems are closed loop, and require the source account and destination account to be on the same transfer platform. The first user is thus limited to funds available in the source account on the transfer platform and cannot use a balance from another account. Both users need to download a transfer application (e.g., Venmo, Cash App, etc.) and complete a registration process.

[0003] Transfer systems also require the first user to manually enter an account identifier of the destination account of the second user. This action is prone to human error and may result in a wrong account identifier being used for the transfer. The first user has no way to verify the account identifier, which may lead to fraud.

[0004] Embodiments of the disclosure address these and other problems individually and collectively.SUMMARY

[0005] One embodiment includes a method comprising: receiving, by a processing network computer from a digital repository on a first user device, a pull message comprising an resource; identifying, by the processing network computer, a isource encrypted identifier based on information associated with the digital repository; initiating, by the processing network computer via a source authorizing entity computer that issued a source account identified by the source encrypted identifier, pulling the resource from the source account; receiving, by the processing network computer from the digital repository on the first user device, a destination encrypted identifier for a destination account issued by a destination authorizing entity computer and an push message requesting to push the resource to the destination account; and executing, by the processing network computer, a process to push the resource to the destination account using a destination account identifier associated with the destination encrypted identifier.

[0006] Another embodiment includes a server computer comprising a processor; and a non-transitory computer readable medium comprising instructions executable by the processor to perform a method comprising: receiving, from a digital repository on a first user device, a pull message comprising an resource; identifying, a source encrypted identifier based on information associated with the digital repository; initiating, via a source authorizing entity computer that issued a source account identified by the source encrypted identifier, pulling the resource from the source account; receiving, from the digital repository on the first user device, a destination encrypted identifier for a destination account issued by a destination authorizing entity computer and a push message requesting to push the resource to the destination account; and executing, a process to push the resource to the destination account using a destination account identifier associated with the destination encrypted identifier.

[0007] Another embodiment includes a method comprising receiving, by a sender device, a selection of sender access data in a sender digital repository in the sender device; initiating, by the sender device, sending of a pull message comprising an resource to sender authorizing entity computer via a processing network computer, wherein the sender authorizing entity computer pulls the resource from a sender account; receiving, by the sender device from a receiver device, a communication comprising receiver access data, after a receiver selects the receiver access data in a receiver digital repository in the receiver device; and initiating, by the sender device, sending of a push message comprising the resource to a receiver7authorizing entity computer via the processing network computer, wherein the receiver authorizing entity computer pushes the resource to a receiver account.

[0008] These and other embodiments are described in further detail below.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 shows a flow diagram of a method for processing interactions according to some embodiments of the disclosure.

[0010] FIG. 2 shows a block diagram of an exemplary processing network computer according to embodiments.

[0011] FIG. 3 illustrates a user device 300 according to an embodiment. User device 300 may include device hardware 304 coupled to a system memory 302.

[0012] FIG. 4 shows a block diagram of an exchange process between receiver user device and sender user device.DESCRIPTION

[0013] Prior to discussing embodiments of the disclosure, some terms can be described in further detail.

[0014] A “user device” may be a device that is operated by a user. Examples of user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a vehicle such as an automobile, a thin-client device, a tablet PC, etc. Additionally, user devices may be any type of wearable technology device, such as a watch, earpiece, glasses, etc. The user device may include one or more processors capable of processing user input. The user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc. The user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data. The user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks),Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.

[0015] An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.

[0016] An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.

[0017] A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters, as well as any object or document that can serve as confirmation. Examples of credentials include value credentials, identification cards, certified documents, access cards, passcodes, and other login information, etc.

[0018] A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include tokens, access tokens, personal identification tokens, etc. A token may include an identifier for an account that is a substitute for an account identifier, such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may beconfigured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0019] A “token provider” or “token service computer” can include one or more computers that service tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating) and / or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN and conducting a transaction using that PAN. In some embodiments, a token service computer may include a tokenization computer alone, or in combination with other computers such as a transaction processing network computer. Various entities of a tokenization ecosystem may assume the roles of the token provider. For example, processing networks and issuers or their agents may become the token provider by implementing the token services according to embodiments of the present invention.

[0020] An “interaction” may include a reciprocal action or influence. An interaction can include a communication, contact, or exchange between parties, devices, and / or entities. Example interactions include a transaction between two parties and a data exchange between two devices. In some embodiments, an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like. In other embodiments, an interaction can include a payment transaction in which two devices can interact to facilitate a payment. An interaction can include a transaction interaction, a data transfer interaction, an access interaction, etc.

[0021] An “interaction request message” may be an electronic message that requests authorization for an interaction. In some embodiments, it is sent to a gateway computer and / or an authorizing entity computer associated with a portable device to request authorization for an interaction involving the portable device. The interaction request message may be a pull interaction message or a push interactionmessage. The interaction request message may include an authorizing entity account identifier that may be associated with a portable device or account. An interaction request message may also comprise interaction information associated with a current interaction, such as a value for the interaction, and a credential. An interaction request message according to some embodiments may be an authorization request message.

[0022] “Interaction data” can include data related to and / or recorded during an interaction. In some embodiments, interaction data can include a resource (e.g., an amount, a secure document, a secure object or other secure data), a date, a time, one or more user identifiers, credentials, and / or additional data relating to an interaction between a sender user and receiver user.

[0023] A “digital repository” may be code or other data stored on a computer readable medium (e.g. memory element or secure element) that may be executable by a processor to securely store a resource and / or to initiate an interaction using the stored resource. According to various embodiments, the digital repository may include a digital wallet application, or an interaction application.

[0024] A “pull message” may be an interaction request message seeking that a value of a current interaction be debited from an account. The pull interaction message can comprise one or more indicators that enable an authorizing entity to make an authorization decision regarding the account that it manages. In embodiments, the pull interaction message may be used to debit the value for the interaction from an account associated with the sender, and can comprise a sender credential and the value for the interaction. An example of a pull transaction message can include an AFT message.

[0025] An AFT (Account Funding Transaction) is a transaction designed to supply funds to another account such as a credit, prepaid, debit, ATM or online account. In some cases, an AFT is paying the service provider bank for sending funds to the recipient and results in a debit to the sender's card account.

[0026] A “push message” may be an interaction request message seeking that a value of a current interaction be credited to an account. The push interaction message can comprise one or more indicators that enable an authorizing entity to deliver a value for the interaction to a recipient account that it manages. Thetransmission of a push interaction message may be separate from and can take place after the transmission of a pull interaction message. An example of a push transaction message can be a credit transaction message such as an OCT message.

[0027] A “settlement process” can is a process in which funds are actually delivered from one entity to one or more other entities to fulfil a transaction.

[0028] Embodiments can provide quick and convenient interactions between user devices. A sender user may send a resource (e.g., an amount, a secure document) to a receiver user via a sender user device. To initiate the transfer, the sender user operating the sender user device can select a source account, and the amount for the interaction. The receiver user can provide a destination account via a contactless interaction. For example, the receiver user can tap their receiver user device to the sender user device to transmit a destination encrypted identifier over near-field communication (NFC). Advantageously, errors associated with manual credential input are avoided, and sensitive account information is not exposed.

[0029] During the contactless interaction, the sender user device may generate a verifiable cryptogram (e.g., EMV cryptogram). The cryptogram can be verified by a processing network computer and / or authorizing entity computer for added security.

[0030] To effectuate the transfer, a pull message followed by a push message may be used. The pull message may be verified (e.g., verification of interaction cryptogram), and can ensure that the resource is available in the source account. The push message may be used to reposit the resource to the destination account.

[0031] Embodiments can provide interoperability across various interaction applications. Users may conduct peer-to-peer interactions even if they do not operate the same interaction application, avoiding excessive registrations to multiple interaction applications. Compared to traditional methods which require both users to operate the same interaction application, embodiments save time and resources.

[0032] FIG. 1 shows a flow diagram of a method for processing interactions according to some embodiments of the disclosure. FIG. 1 shows a first user 101 (e.g., a sender) operating a sender user device 102 comprising a digital repository102A, a second user 103 (e.g., a receiver) operating a receiver user device 105, a token service computer 106, a service provider computer 111 , a processing network computer 108, a source authorizing entity computer 110, and a destination authorizing entity computer 112. The processing network computer 108 may be in operable communication with the token service computer 106, the service provider computer 111 , the source authorizing entity computer 110, the destination authorizing entity computer 112, and the sender user device 102.

[0033] The sender user device 102 and receiver user device 105 may have NFC capability. The sender user device 102 may also be referred to as a sender device. The receiver user device 105 may be referred to as a receiver device. The sender user device 102 may be a sender mobile phone (also referred to as a source mobile phone) and the receiver user device 105 may be a receiver mobile phone (also referred to as a destination mobile phone).

[0034] The source authorizing entity computer 110 may issue and manage a source account on behalf of the first user 101. The destination authorizing entity computer 112 may issue and manage a destination account on behalf of the second user 103. For example, the source authorizing entity computer 110 may be operated by a first issuer bank with which the first user 102 has the source account. The destination authorizing entity computer 112 can be operated by a second issuing bank with which the second user 103 has the destination account. In some embodiments, the source authorizing entity computer 110 and the destination authorizing entity computer 112 may be operated by the same entity.

[0035] The digital repository 102A on the sender user device 102 may store secure data (e.g., encrypted account identifiers) and enable the sender user device 102 to initiate interactions / exchanges using the secure data. Examples of the digital repository 102A include a wallet application, an interaction application, or a transfer application. The service provider computer 111 may be an application backend for the digital repository 102A.

[0036] The digital repository 102A may be associated with the processing network computer 108. For example, the digital repository 102A may include a software development kit (SDK) provided by the processing network computer 108 which enables the sender user device 102 to initiate contactless interactions asdescribed herein. In some embodiments, the processing network computer 108 may assume the role of the service provider computer 111 by managing the digital repository 102A and including an application backend for the digital repository 102A.

[0037] The processing network computer 108 can forward and optionally reformat interaction messages to facilitate the interaction. The processing network computer may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. For example, the processing network computer may comprise a server coupled to a network interface (e.g., by an external communication interface), and databases of information. The processing network computer 108 may be representative of a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are able to process credit card transactions, debit card transactions, and other types of commercial transactions. VisaNet™, in particular, includes a VIP system (Visa Integrated Payments system) which processes authorization requests and a Base II system which performs clearing and settlement services. The processing network computer 108 may use any suitable wired or wireless network, including the Internet. The processing network computer 108 may operate a token service computer and may perform tokenization and de- tokenization processing.

[0038] In the method of FIG. 1 , the first user 101 initiates an interaction with the second user 103. The interaction can include a pull message that debits the source account and a push message that credits the destination account. To identify the destination account, the push message may include a destination encrypted identifier provided by the receiver user device 105. For example, the destination encrypted identifier may be transmitted from the receiver user device 105 to the sender user device 102 in a contactless interaction via NFC.

[0039] The second user 103 may provide the destination encrypted identifier via a digital repository on the receiver user device 105, which may be any suitable application. The digital repository may be a wallet application which stores the destination encrypted identifier, for example, and need not be associated with the digital repository 102A of the sender user device 102. Embodiments do not requireboth the first user 101 and the second user 103 to be registered to the same platform.

[0040] The digital repository on the receiver user device 105 may further comprise an SDK which enables cryptogram generation during contactless interactions. In some embodiments, the digital repository on the receiver user device 105 may be associated with or managed by the processing network computer 108.

[0041] Prior to step S10, the first user 101 may register the source account with the digital repository 102A. As a part of registration, the digital repository 102A may request a credential to identify the source account. The first user 101 can interact a portable device (e.g., payment card, account identifying card) comprising the credential to the contactless interface of the sender user device 102, and the digital repository 102A may capture the credential using NFC capability of the sender user device 102.

[0042] The digital repository 102A may obtain a source account encrypted identifier (e.g., a token) upon capturing the credential. For example, the first user 101 may register a debit card with the digital repository 102A (e.g, a digital wallet application), interact the debit card with the contactless interface of the sender user device 102, and the digital repository 102A can receive a token for the debit card PAN from the token service computer 106. The token may be stored in association with the PAN at a token vault.

[0043] The source encrypted identifier may be a source device token. For example, the source encrypted identifier (e.g., device token) may be stored in association with an identifier of the sender user device 102 and the source account identifier (e.g., PAN) in a token vault associated with the token service computer 106.

[0044] The token service computer 106 may include one or more computers that generate, process, and maintain tokens (e.g., encrypted identifiers). For example, the token service computer 106 may include or be in communication with a token vault where the generated tokens are stored. The token vault may maintain a one-to-one mapping between a token and an underlying account identifier represented by the token.

[0045] The digital repository 102A can check that the source authorizing entity computer 110 approves contactless interactions prior to enabling the source account for contactless interactions. The digital repository 102A may also perform checks to verify the source account. The digital repository 102A may store the source encrypted identifier to be used in interactions.

[0046] At step S10, the first user 101 can initiate an interaction via the digital repository 102A. The first user 101 can select a source encrypted identifier (which may be an example of sender access data) of the source account to use for the interaction and input interaction details such as a resource (e.g., an amount) for the interaction. The sender user device 102 may receive the selection of the sender access data. In some embodiments, the digital repository 102A may prompt that the first user 101 authenticate themselves as the source account owner (e.g., perform CDCVM).

[0047] At steps S11-S12, the digital repository 102A may transmit a pull message comprising the resource to the processing network computer 108 via the service provider computer 111. The pull message may additionally comprise the source encrypted identifier.

[0048] At step S14, after receiving the pull message, the processing network computer may identify the source encrypted identifier, and detokenize the source encrypted identifier via the token service computer 106 to obtain a source credential. For example, the source encrypted identifier may be included in the pull message. The processing network computer 108 can detokenize the source encrypted identifier to obtain a source credential.

[0049] At step S15, the processing network computer 108 can modify the pull message to include the source credential and transmit the modified pull message to the source authorizing entity computer 110.

[0050] At step S18, after receiving the modified pull message comprising the resource and the source credential, the source authorizing entity computer 110 may authorize the interaction and pull the resource from the source account. The resource for the interaction can be temporarily held in a virtual account until a corresponding push message is processed.

[0051] In some embodiments, the pull message may use an AFT (Account Funding Transaction) authorization request message. An AFT (Account Funding Transaction) is a transaction designed to supply funds to another account such as a prepaid, debit, ATM card or on-line account. The AFT eventually will result in a debit to the source account. Assuming that funds are available from the source account (or that credit is available), the source authorizing entity computer 110 can approve the transaction and the first user 101 can receive an indication via the processing network computer 108 that the authorization is successful.

[0052] At step S20, the digital repository 102A can obtain a destination encrypted identifier from the receiver user device 105. The digital repository 102A may prompt to input destination account information for the interaction. The second user 103 can use a second interaction application on the receiver user device 105 to select a destination account. The second user 103 can tap the receiver user device 105 to the sender user device 102 to transmit the destination encrypted identifier. The digital repository 102A may further capture interaction details such as a cryptogram for the interaction, an expiration date, and an identifier for the second interaction application.

[0053] In some embodiments, after capturing the destination encrypted identifier from the receiver user device 105, the digital repository 102A can detokenize the destination encrypted identifier to obtain a destination account identifier. The digital repository 102A may retrieve the destination account identifier from a token vault via the token service computer 106 which stores the destination encrypted identifier in association with the destination account identifier. For example, the digital repository 102A may transmit a token request message comprising the destination encrypted identifier to the token service computer 106, and the token service computer 106 can return a token response message comprising the destination account identifier.

[0054] At steps S22-S23, the digital repository 102A can transmit a push message comprising the destination encrypted identifier and optionally the destination account identifier (if it was obtained in step S20) to the processing network computer 108 via the service provider computer 111. The push message may further comprise the captured interaction details such as the cryptogram.

[0055] In some embodiments, the push message may be an OCT (Original Credit Transaction) authorization request message. An OCT is typically a clearing and settlement credit transaction designed for use in applications such as a business money transfer or business-to-consumer repayments. When used in the context of the present invention for funds transfer, the OCT is the transaction used to deliver funds to the destination account. It is separate from, and takes place after, an AFT transaction. This timing is to ensure that funds are secured before funds are sent to the second user 103.

[0056] At step S24, after receiving the push message, the processing network computer 108 can verify the cryptogram and other interaction details and detokenize the destination encrypted identifier via the token service computer 106 to obtain a destination credential for the destination account (if it was not provided by the digital repository 102A in the push message). For example, the processing network computer 108 may retrieve the destination account identifier from a token vault via the token service computer 106 which stores the destination encrypted identifier in association with the destination account identifier.

[0057] If verifications are successful, the processing network computer 108 can execute a process to push the resource to the destination account. The processing network computer 108 can modify the push transfer message to include the destination credential and route the modified push transfer message to the destination authorizing entity computer 112.

[0058] At step S26, if the destination authorizing entity computer 112 authorizes the interaction, the destination account can be credited with the resource (e.g, for the amount) of the interaction. The destination authorizing entity computer 112 can notify the digital repository 102A that the destination account has been credited. In some embodiments, the destination authorizing entity computer 112 may also notify the second user 103 (e.g., via the receiver user device 105).

[0059] At an appropriate time, funds can be transferred from the virtual account to the destination account.

[0060] FIG. 2 shows a block diagram of an exemplary processing network computer according to embodiments. The processing network computer 200 may comprise a processor 204 coupled to a memory 202, a network interface 206 and acomputer readable medium 208. The computer readable medium 208 can comprise a cryptogram validation module 208A, a communication module 208B, and a detokenization module 208C, and an interaction processing module 208D. The processing network computer 200 can be in operative communication with a database 210.

[0061] The memory 202 can be used to store data and code. The memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud-based data storage), and may comprise any combination of volatile and / or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device. For example, the memory 202 can store credentials, tokens, resource provider identifiers, account information, etc.

[0062] The memory 202 may comprise a computer readable medium comprising code, executable by the processor, to perform a method comprising: receiving, by a processing network computer from a digital repository on a first user device, a pull message comprising an resource; identifying, a source encrypted identifier based on information associated with the digital repository; initiating, via a source authorizing entity computer that issued a source account identified by the source encrypted identifier, pulling the resource from the source account; receiving, from the digital repository on the first user device, a destination encrypted identifier for a destination account issued by a destination authorizing entity computer and an push message requesting to push the resource to the destination account; and executing, a process to push the resource to the destination account using a destination account identifier associated with the destination encrypted identifier.

[0063] The cryptogram validation module 208A may comprise code or software, executable by the processor 204, for validating a cryptogram or other dynamic value associated with a request. The cryptogram validation module 208A may use shared secrets or algorithms to validate a cryptogram that uses repeatable input data to re-calculate and compare a dynamic cryptogram for an interaction. For example, the cryptogram or other dynamic value may be generated by a digital repository (e.g., a wallet application) using an account identifier, expiration date, interaction time, resource, or any other suitable interaction information.

[0064] The communication module 208B that may comprise code that causes the processor 204 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities. When an electronic message is received by the processing network computer 200 via the network interface 206, it may be passed to the communication module 208B. The communication module 208B, in conjunction with the processor 204, may identify and parse the relevant data based on a particular messaging protocol used in the system. The communication module 208B, in conjunction with the processor 204, may then transmit any received information to an appropriate module within the processing network computer 200 (e.g., via a data bus line, etc.). The communication module 208B may also receive information from one or more of the modules in the processing network computer 200 and generate an electronic message in an appropriate data format in conformance with a transmission protocol, such that the message may be sent to one or more entities. The electronic message may then be passed to the network interface 206 for transmission.

[0065] The detokenization module 208C may comprise code that causes the processor 204 to determine an identifier for an encrypted identifier. The interaction processing module 208D may comprise code that causes the processor 204 to process an interaction request message (e.g., a pull message, a push message). The interaction processing module 208D may modify interaction request messages and route them for authorization.

[0066] The network interface 206 may include an interface that can allow the processing network computer 200 to communicate with external computers. The network interface 206 may enable the processing network computer 200 to communicate data to and from another device. Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 206 may include Wi-Fi™. Data transferred via the network interface 206 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). Theseelectronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.

[0067] FIG. 3 illustrates a user device 300 according to an embodiment. User device 300 may include device hardware 304 coupled to a system memory 302.

[0068] Device hardware 304 may include a processor 306, a short range antenna 314, a long range antenna 316, input elements 310, a user interface 308, and output elements 312 (which may be part of the user interface 308). Examples of input elements may include microphones, keypads, touchscreens, sensors, etc. Examples of output elements may include speakers, display screens, and tactile devices. The processor 306 can be implemented as one or more integrated circuits (e.g., one or more single core or multicore microprocessors and / or microcontrollers), and is used to control the operation of user device 300. The processor 306 can execute a variety of programs in response to program code or computer-readable code stored in the system memory 302, and can maintain multiple concurrently executing programs or processes.

[0069] The long range antenna 316 may include one or more RF transceivers and / or connectors that can be used by user device 300 to communicate with other devices and / or to connect with external networks. The user interface 308 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of user device 300. The short range antenna 314 may be configured to communicate with external entities through a short range communication medium (e.g., using Bluetooth, Wi-Fi, infrared, NFC, etc.). The long range antenna 316 may be configured to communicate with a remote base station and a remote cellular or data network, over the air.

[0070] The system memory 302 can be implemented using any combination of any number of non-volatile memories (e.g., flash memory) and volatile memories (e.g. DRAM, SRAM), or any other non-transitory storage medium, or a combination thereof media. The system memory 302 may store computer code, executable bythe processor 306, for performing a method comprising receiving a selection of sender access data in a sender digital repository 302A in the sender device; initiating, sending of a pull message comprising an resource to sender authorizing entity computer via a processing network computer, wherein the sender authorizing entity computer pulls the resource from a sender account; receiving, from a receiver device, a communication comprising receiver access data, after a receiver selects the receiver access data in a receiver digital repository in the receiver device; and initiating, sending of a push message comprising the resource to a receiver authorizing entity computer via the processing network computer, wherein the receiver authorizing entity computer pushes the resource to a receiver account.

[0071] The system memory 302 may also store a digital repository 302A, a communication module 302B, an authentication module 302C, credentials / tokens 302D, and an operating system 302E. The digital repository 302A may comprise executable code for storing secure data (e.g., encrypted account identifiers) and initiating interactions / exchanges using the secure data. Examples of the digital repository 302A include a wallet application, an interaction application, or a transfer application. The digital repository 302A can include instructions or code initiating and conducting an interaction with an external device such as another user device. The digital repository 302A may comprise code, executable by the processor 306, to capture interaction data during a contactless interaction and generate a cryptogram for the interaction. It may also include code, executable by processor 306, for conducting interactions between a source account and a destination account. For example, the digital repository 302A may include instructions or code to transmit push transfer messages and pull messages. The authentication module 302C may comprise code, executable by the processor 306, to authenticate a user. This can be performed using user secrets (e.g., passwords) or user biometrics.

[0072] System memory 302 may also store credentials and / or tokens 302D. Credentials may also include information identifying the user device 300 and / or the user of the user device 300.

[0073] FIG. 4 shows a block diagram of an exchange process 500 between receiver user device 105 and sender user device 102. The process can be used in, for example, step S20 of FIG. 1.

[0074] The receiver user device 105 may include a digital repository (e.g., a wallet application) which stores one or more identifiers for one or more accounts. The identifiers may be encrypted identifiers (e.g., tokens) which can be used to conduct contactless interactions.

[0075] At step S504, a user can use the receiver user device 105 to initiate a transaction with the sender user device 102. The user may hold the receiver user device 105 near the sender user device 102, such that both devices may mutually detect each other. The user may present (e.g., tap, hold near, etc.) the receiver user device 105 to the sender user device 102 to exchange data with the sender user device 102.

[0076] At step S506, during a process for exchanging data between the receiver user device 105 and the sender user device 102, the receiver user device 105 may provide the sender user device 102 with a list of available applications including at least a first application and a second application. In an interaction, the sender user device 102 may send an available applications request message to the receiver user device 105. The available applications request message can request information regarding which applications (e.g., a list of application identifiers (AIDs)) are available on the receiver user device 105. In some embodiments, the available applications request message may be in the form of a SELECT PPSE command.

[0077] At step S508, the receiver user device 105 then identifies, from a memory of the receiver user device 105, available applications including at least a first application and a second application. The receiver user device 105 then provides (e.g., transmits) an initial or first available applications response message to the sender user device 102. The available applications response message includes the list of the applications (e.g., a list of AIDs) available at the receiver user device 105 in a SELECT PPSE response in response to receiving the SELECT PPSE command. The available applications response message can comprise an application list comprising at least the first application and the second application. The application list can be ordered according to a first priority and a second priority to indicate a preference for the sender user device 102 to use the first application over the second application to process the interaction.

[0078] As shown in step S510, the sender user device 102 selects an application from the received application list, and then transmits the selection of the application in a select AID message to the receiver user device 105 (step S512). In some embodiments, the sender user device 102 selects the application highest in the list (e.g., the application associated with the highest priority, in this case the first application). If the interaction is a payment transaction, then this process for application selection may conform to a payment standard such as EMV 1.0 and / or EMV 2.0.

[0079] At step S516, the receiver user device 105 may transmit a request for terminal transaction data (e.g., a PDOL request).

[0080] At step S518, responsive to the request for terminal transaction data, the sender user device 102 may send transaction data to the receiver user device 105. In some embodiments, the sender user device 102 may send such data in a processing options data object list (PDOL) message to the receiver user device 105. The selected application (e.g., the first application or international application) may receive the data via the PDOL message.

[0081] At step S534, the receiver user device 105, upon receiving the application selection message at step S518, may send a terminal transaction data request to request transaction data from the sender user device 102. In some embodiments, the terminal transaction data request may be in the form of a “Select AID Response” and may include application identifier (AID) and file control information (FCI) associated with the selected AID as the dedicated file name. The terminal transaction data request may include a list of transaction data identifiers to request the appropriate data from the sender user device 102. The list of transaction data identifiers can be in the form of a processing options data object list (PDOL).

[0082] The transaction data requested by the receiver user device 105 for the transaction may include terminal processing options (TPO), an resource, and other information. In addition, the transaction data may include one or more dynamic data elements (e.g., a random number).

[0083] At step S536, after receiving the terminal transaction data request from receiver user device 105, the sender user device 102 may send the terminal transaction data to the receiver user device 105. In some embodiments, the terminaltransaction data may be sent in the form of a get processing options (GPO) command, and may include the requested terminal transaction data in a processing options data object list (PDOL). The terminal transaction data (e.g., Transaction Processing Options (TPO)) may include a TPO indicator that indicates which transaction data types the sender user device 102 supports.

[0084] Once the receiver user device 105 receives the terminal transaction data, the receiver user device 105 may obtain relevant credentials (e.g., card credentials), and may send a set of transaction processing information to the sender user device 102 In some embodiments, the transaction processing information can be sent in the form of a “get processing options” (GPO) response. In some embodiments, the transaction processing information may include one or more application file locators (AFLs) that can be used as file addresses by sender user device 102 to read account data stored on the receiver user device 105, and an application interchange profile (AIP) that can be used to indicate the capabilities of the payment application.

[0085] The transaction processing information may include any credentials for the transaction including a cryptogram generated using transaction information, Track-2 equivalent data (e.g., PAN, expiration date), and / or additional data. For example, the cryptogram may be generated using transaction information, which may include a dynamic data element (e.g., the random number), the receiver user device 105 identifier (e.g., a PAN), and optionally other information such as a session identifier, a value such as a zero dollar resource, and a transaction counter. The transaction processing information may also include issuer application data (IAD), a form factor indicator (FFI), card transaction qualifiers (CTQ), cryptogram information data (CID), and / or an application PAN sequence number (PAN). In some embodiments, the issuer application data (IAD) may include a length indicator indicating the length of the IAD, a cryptogram version number (CVN) indicating the version of the transaction cryptogram, a derived key indicator (DKI) that can be used to identify a master key (e.g., a master key associated with the issuer), and / or card verification results (CVR).

[0086] In some embodiments, after the sender user device 102 receives the transaction processing information, in step S538, the sender user device 102 maysend an account data request to the receiver user device 105 to read additional account data that may be stored on the receiver user device 105. In some embodiments, the account data request may be in the form of a “read record” command, and may include an application file locator (AFL) indicating a location of the account data that the sender user device 102 is attempting to read. The AFL included in the account data request may correspond to an AFL in the transaction processing information that was provided to the sender user device 102 from receiver user device 105.

[0087] In response to receiving the account data request from the sender user device 102 in step S540, the receiver user device 105 may send account data stored at the location indicated by the AFL to the sender user device 102. In some embodiments, the account data may be sent in the form of a “read record” response. The account data may include, for example, application usage control that indicates the issuer’s restrictions on usage and services allowed for the application, the cardholder's name, customer exclusive data, issuer country code, and / or other account related data that is accessible at the AFL location and is stored in the receiver user device 105. The account data, transaction processing information, and other data received by the sender user device 102 in previous steps may be subsequently used by the sender user device 102 to request authorization of the transaction (e.g., from an authorizing entity).

[0088] At some point, the user may remove the receiver user device 105 from the sender user device 102, or otherwise disengage the receiver user device 105 from the sender user device 102.

[0089] Embodiments of the invention provide a number of advantages. Embodiments provide an interoperable method for conducting person to person interactions while utilizing existing system infrastructure. A sender can interact with a receiver even if they do not operate the same interaction application. Service providers that operate interaction applications do not need to individually onboard with each authorizing entity. Moreover, embodiments can reduce error and fraud associated with credentials that are manually input into an interaction application.

[0090] Any of the software components or functions described in this application may be implemented as software code to be executed by a processorusing any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and / or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.

[0091] Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and / or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

[0092] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0093] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0094] As used herein, the use of "a," "an," or "the" is intended to mean "at least one," unless specifically indicated to the contrary.

Claims

WHAT IS CLAIMED IS:

1. A method comprising: receiving, by a processing network computer from a digital repository on a first user device, a pull message comprising a resource; identifying, by the processing network computer, a source encrypted identifier based on information associated with the digital repository; initiating, by the processing network computer via a source authorizing entity computer that issued a source account identified by the source encrypted identifier, pulling the resource from the source account; receiving, by the processing network computer from the digital repository on the first user device, a destination encrypted identifier for a destination account issued by a destination authorizing entity computer and a push message requesting to push the resource to the destination account; and executing, by the processing network computer, a process to push the resource to the destination account using a destination account identifier associated with the destination encrypted identifier.

2. The method of claim 1 , further comprising: managing, by the processing network computer, a part of the digital repository on the first user device.

3. The method of claim 1, further comprising: receiving, by the processing network computer, the destination account identifier associated with the destination encrypted identifier from the digital repository on the first user device, wherein the digital repository retrieves the destination account identifier from a token vault storing an association between the destination encrypted identifier and the destination account identifier.

4. The method of claim 1 , wherein the source authorizing entity computer is the same as the destination authorizing entity computer.

5. The method of claim 1, wherein the destination encrypted identifier is provided to the digital repository on the first user device from a second user device via an interaction between the first user device and the second userdevice using near-field communication (NFC) capabilities of the first user device and the second user device.

6. The method of claim 5, wherein the first user device is a source mobile phone and the second user device is a destination mobile phone.

7. The method of claim 1 , further comprising: generating, by the processing network computer, a virtual account; and storing, by the processing network computer, the resource at the virtual account after pulling the resource from the source account and before pushing the resource to the destination account.

8. The method of claim 1 , further comprising: managing, by the processing network computer, a part of a digital repository on a second user device, wherein the destination encrypted identifier is stored at, or generated by, the part of the digital repository of the second user device managed by the processing network computer.

9. A server computer comprising: a processor; and a non-transitory computer readable medium comprising instructions executable by the processor to perform steps comprising: receiving, from a digital repository on a first user device, a pull message comprising a resource; identifying, a source encrypted identifier based on information associated with the digital repository; initiating, via a source authorizing entity computer that issued a source account identified by the source encrypted identifier, pulling the resource from the source account; receiving, from the digital repository on the first user device, a destination encrypted identifier for a destination account issued by a destination authorizing entity computer and a push message requesting to push the resource to the destination account; andexecuting, a process to push the resource to the destination account using a destination account identifier associated with the destination encrypted identifier.

10. The server computer of claim 9 wherein the steps further comprise: managing, a part of the digital repository on the first user device.11 . The server computer of claim 9 wherein the steps further comprise: receiving the destination account identifier associated with the destination encrypted identifier from the digital repository on the first user device, wherein the digital repository retrieves the destination account identifier from a token vault storing an association between the destination encrypted identifier and the destination account identifier.

12. The server computer of claim 9, wherein the source authorizing entity computer is the same as the destination authorizing entity computer.

13. The server computer of claim 9, wherein the destination encrypted identifier is provided to the digital repository on the first user device from a second user device via an interaction between the first user device and the second user device using near-field communication (NFC) capabilities of the first user device and the second user device.

14. The server computer of claim 13, wherein the first user device is a source mobile phone and the second user device is a destination mobile phone.

15. The server computer of claim 9 wherein the steps further comprise: generating, a virtual account; and storing, the resource at the virtual account after pulling the resource from the source account and before pushing the resource to the destination account.

16. The server computer of claim 9 wherein the steps further comprise:managing, a part of a digital repository on a second user device, wherein the destination encrypted identifier is stored at, or generated by, the part of the digital repository of the second user device managed by the server computer.

17. A method comprising: receiving, by a sender device, a selection of sender access data in a sender digital repository in the sender device; initiating, by the sender device, sending of a pull message comprising a resource to sender authorizing entity computer via a processing network computer, wherein the sender authorizing entity computer pulls the resource from a sender account; receiving, by the sender device from a receiver device, a communication comprising receiver access data, after a receiver selects the receiver access data in a receiver digital repository in the receiver device; and initiating, by the sender device, sending of a push message comprising the resource to a receiver authorizing entity computer via the processing network computer, wherein the receiver authorizing entity computer pushes the resource to a receiver account.

18. The method of claim 17, wherein the sender device is a sender mobile phone and the receiver device is a receiver mobile phone.

19. The method of claim 17, wherein the sender access data is a source encrypted identifier associated with the sender account, and the receiver access data is a destination encrypted identifier associated with the receiver account.

20. The method of claim 17, wherein the sender device receives the communication comprising the receiver access data from the receiver device using near-field communication (NFC) capabilities of the sender device and the receiver device.

Images