Anonymous payment transactions

Technology is disclosed for transferring money anonymously between a sender and a recipient by use of a token. In some embodiments, the disclosed technology involves communication between a mobile payment application (“App”) and a payment service system (PSS). Upon the recipient's request, the App, installed on the recipient's device, generates the token, and provides the token to both the recipient and the PSS. The PSS receives both the token and the recipient's identification information from the App, associates the token with the identification information, and stores such association. The recipient, on the other hand, transfers the token to the sender, who forwards it to the PSS to request a money transfer. The PSS receives the token and identifies the recipient's identification information based on the previously stored association with the token. With the identification information, the PSS determines the recipient's financial account to execute the money transfer.

BACKGROUND

As society becomes increasingly “cashless” through the increased use of electronic wallets and other digital forms of money transfer, peer-to-peer money transfers (“P2P transfers”) are becoming increasingly popular between individuals, who may or may not personally know each other. An example is the payment of an “IOU” debt from an individual (payer) to an acquaintance (payee) at a social group outing, where the individual and the distant acquaintance may never socialize again. Another example is the buying and selling of goods at an arts-and-crafts fair, where a buyer (payer) makes a payment to a seller (payee) whom the buyer may never see again.

Decreased reliance on cash often means that individuals have insufficient cash on hand, or even paper checks. Further, for a payee who participates in frequent P2P transfers (e.g., arts-and-crafts fair seller), managing and tracking money transfers from multiple payers can be cumbersome and highly inconvenient. The more convenient payment methods, such as credit cards or bank account debits through electronic funds transfers (EFT), are often available only to retail businesses, as opposed to individual payers and payees. However, even if such payment methods were available, completion of the payments often requires an account setup between the individual payers and payees, necessitating the individuals to reveal information about their personal identities.

DETAILED DESCRIPTION

Technology is disclosed for transferring money anonymously between a payer and a payee (“the disclosed technology”). The term “money transfer” as used here refers to a financial transfer between two individuals' financial accounts that can be fulfilled by using debit “rails” (e.g., bank account deposit) or by using credit “rails” (e.g., credit account charge-back). The term “rails” as used here refers to a series of processing pathways between financial institutions to execute payment transactions from/to desired funding sources. That is, credit rails refer to the pathways of a payment flow to a credit account while debit rails refer to the pathways of a payment flow to a debit account. The term “payee” as used here refers to an individual who wishes to receive, or to be sent, money from another individual (payer). The term “payer” as used here refers to an individual who wishes to provide, or send, money to the payee. The term “payee” may be used synonymously throughout the description with the terms “recipient” or “merchant” without any intended change in meaning. The term “payer” may be used synonymously throughout the description with the terms “sender,” “customer,” or “consumer” without any intended change in meaning.

Briefly described, the disclosed technology enables the payee to receive money (e.g., electronic funds or credit) by use of an anonymizing token, which serves as an identification of the payee for the payer to utilize in sending the money. In some embodiments, the disclosed technology involves communication between a mobile payment application installed on the payee's mobile device, the payer's mobile device, and an intermediary payment service system (PSS). The mobile payment application enables the payee to request for an anonymizing token by submitting the payee's identification information. Upon receiving the request, the mobile payment application generates the anonymizing token for the payee (e.g., display the token on a user interface of the mobile payment application), and transmits the generated anonymizing token and the submitted payee's identification information to the PSS, which stores the token in association with the identification information. The payee, on the other hand, provides the anonymizing token to the payer, for example, through a communication broadcast (e.g., over Wi-Fi®, Bluetooth®, Bluetooth® Low Energy, Apple® AirDrop®, etc.), a scanning of a Quick Response Code (QR code), an email message, or the like. With the anonymizing token, the payer sends a request message to the PSS for a transfer of money, where the request message includes, among other things, the anonymizing token to indicate to whom the money should be transferred. The PSS identifies the payer's financial account based on information included in the request message and the payee's financial account based on the stored association between the anonymizing token and the payee's identification information. Upon successful identification, the PSS executes or triggers execution of the transfer of money.

Among other benefits, the disclosed technology provides a means for individuals to transfer money anonymously, and particularly makes that transfer relatively quick and easy as compared to traditional methods. In particular, use of the anonymizing token enables the payee to receive money without having to reveal the payee's identification information (e.g., personal email address, financial account information, etc.) to the payer. Further, since use of the anonymizing token necessitates the payer to communicate through the PSS, the payer's own identification information is also not revealed to the payee when the money gets transferred.

Consider the following example of an arts-and-crafts fair merchant (e.g., a wood sculptor) initiating the process for money to be transferred to him from one or more arts-and-crafts fair customers. Note that this example is discussed to explain various aspects of the disclosed technology for illustrative purposes only, and that the disclosed technology is not limited in applicability to a arts-and-crafts fair operation or any other particular kind of business. Additionally, the disclosed technology can be employed with any transaction that traditionally would be initiated by, or involve the use of, a payment card or a financial account. Thus, the term “transaction” refers to any exchange of goods and/or services of monetary value. For example, the transaction can be a payment of an “IOU” debt between two individuals who wish to protect their respective identity information.

According to an embodiment of the disclosed technology, to initiate a transfer of money, the arts-and-crafts fair merchant first launches a mobile payment application installed on his mobile device. In the embodiment, the mobile payment application, which is in communication with the PSS, is an application that executes on a mobile computing device. The mobile payment application generates one or more anonymizing tokens as requested by a user of the application (e.g., the arts-and-crafts fair merchant). In some embodiments, the mobile payment application receives information from the user and relays that information to the PSS. The PSS, in turn, generates the anonymizing token and transmits it to the mobile payment application for display to the user.

Referring back to the example, to initiate the generation of the anonymizing token, the arts-and-crafts fair merchant (i.e., payee) first inputs information into the mobile payment application to request for the token. In some embodiments, the information can simply be the arts-and-crafts fair merchant's identification information (e.g., email address, driver's license number, device ID, financial account information identifying the arts-and-crafts fair merchant's financial account, etc.). In some embodiments, the information can also include transaction information associated with a transaction for which the money transfer is requested. For example, the transaction is a purchase of two wooden chairs handmade by the arts-and-crafts fair merchant. The transaction information can include, for example, a transaction ID, a transaction date and/or time, a transaction amount, a list of one or more transaction items (e.g., wooden chairs), etc.

After the arts-and-crafts fair merchant has finished inputting all of the information, the mobile payment application generates the anonymizing token for the arts-and-crafts fair merchant. The mobile payment application sends to the PSS the generated anonymizing token along with at least a portion of the information inputted by the arts-and-crafts fair merchant (e.g., identification information, transaction information, etc.). Upon receipt, the PSS stores the anonymizing token in association with the received information for use in identifying the arts-and-crafts fair merchant and/or the transaction in future transactions. In some embodiments, the mobile payment application communicates all of the information inputted by the arts-and-crafts fair merchant to the PSS, which then generates the anonymizing token, and sends it back to the mobile payment application. In such embodiments, the PSS, after generating the anonymizing, stores the anonymizing token (e.g., a copy of the anonymizing token) in association with at least a portion of the information (e.g., identification information, transaction information, etc.) The anonymizing token can be a Quick Response code (“QR code”), an image, a string of characters, an encrypted message, a globally unique identifier, etc. The anonymizing token is generated for the arts-and-crafts fair merchant to utilize separately from the identification information, which is only known by the PSS based on the stored association. Thus, use of the anonymizing token enables the arts-and-crafts fair merchant to protect his personal identification information from being revealed to any customer who receives the token and, at the same time, to identify himself as a recipient of money in a transaction with any customer.

Upon receiving the anonymizing token, the arts-and-crafts fair merchant provides the token to any customer who wishes to send the merchant money, e.g., to make a purchase from the arts-and-crafts fair merchant. In some embodiments, the arts-and-crafts fair merchant, using his mobile device, can broadcast the anonymizing token to nearby customers. For example, the anonymizing token is an image that can be transmitted to a customer's mobile device using AirDrop®.

A customer, who has received the anonymizing token, can send a money transfer request to the arts-and-crafts fair merchant by communicating with the PSS. In particular, the customer submits the anonymizing token with the request when she communicates with the PSS. The customer can also submit other information with the request, such as a transfer amount to be transferred to the arts-and-crafts fair merchant, transaction information (e.g., list of items the customer is purchasing from the merchant), and/or the customer's identification information (e.g., name, email address, driver's license number, financial account information identifying the customer's financial account, etc.).

In some embodiments, the customer can send the money transfer request to the PSS by using a mobile payment application installed on the customer's mobile device. The mobile payment application can be a different application or the same application utilized by the arts-and-crafts fair merchant. The mobile payment application sends the request, along with the anonymizing token and any other information (e.g., transfer amount), to the PSS for processing.

In some embodiments, the customer can send the money transfer request to the PSS by using an email mechanism[SI1]. In such embodiments, the customer composes an email, e.g., using a native email application installed on the customer's mobile device, and attaches the anonymizing token in the email. The customer can also include other information in the body or subject line of the email (e.g., transfer amount, transaction information, the customer's identification, etc.). Note that the email itself can include the customer's email address, which can serve as the customer's identification to be used by the PSS in processing the money transfer request. Other mechanisms can be utilized by the customer to send the money transfer request to the PSS, for example, a short message service (SMS) mechanism or a web interface mechanism.

Upon receiving the request, the PSS analyzes the anonymizing token to determine the identity and associated financial account of the payee to whom the transfer amount should be transferred (i.e., the arts-and-crafts fair merchant). In particular, the PSS accesses a database of the PSS to identify a matching anonymizing token and any identification information that is stored in association with the token. In one example, the associated identification information can include an email address of the arts-and-crafts fair merchant. In this example, the PSS can further identify whether the email address is associated with a financial account of the arts-and-crafts fair merchant. For example, the arts-and-crafts fair merchant has previously provided financial account information identifying the account to the PSS, e.g., to facilitate the money transfer. In another example, the associated identification information includes the financial account information of the arts-and-crafts fair merchant.

The PSS further analyzes any other information included in the request, such as the customer's identification information, to determine the identity and associated financial account of the payer (i.e., customer) who has sent the request. In one example, the identification information can be the customer's financial account information identifying a financial account of the customer. In another example, the identification information can be a username associated with the mobile payment application from which the request has been sent. In this example, the PSS can access its database to identify the username and a financial account previously stored in association with that username. In another example, the identification information can be the email address of the email sender in the email request (i.e., the customer's email address). In this example, the PSS can access its database to identify the email address and a financial account previously stored in association with that email address.

Upon successful identification of the respective financial accounts of the customer and the arts-and-crafts fair merchant, the PSS executes or triggers execution of the transfer of money from the customer's financial account to the arts-and-crafts fair merchant's financial account. In some embodiments, the PSS performs an additional step of verifying the sufficiency of funds in the customer's financial account before executing, or triggering execution of, the transfer of money.

In some embodiments, if the PSS is unable to identify the financial account of either the arts-and-crafts fair merchant or the customer, the PSS communicates with the respective individual (e.g., through mobile payment application) to obtain the missing financial account information. In such embodiments, the PSS can prompt the respective individual to submit and/or link a payment card (e.g., debit card or credit card) to the individual's identification information (e.g., email address). For example, the PSS causes the mobile payment application to prompt the respective individual to input payment card information (e.g., card number, expiration date, CVV, etc.) of a payment card that identifies a financial account of the respective individual. Upon receiving the respective missing payment card information, the PSS can proceed with executing or triggering execution of the transfer of money.

Although the example provided above uses a mobile device to initiate the process for transfer of money according to the embodiment described above, in other embodiments a processing device other than a mobile device may be used to initiate that process, such as a conventional personal computer (PC). In such embodiments, the mobile payment application can be replaced by a more conventional software application in such processing device, where such software application has functionality similar to that of the mobile payment application as described here.

As used herein, a “module,” “a manager,” an “interface,” a “platform,” or an “engine” includes a general purpose, dedicated or shared processor and, typically, firmware or software modules that are executed by the processor. Depending upon implementation-specific or other considerations, the module, manager, interface, platform, or engine can be centralized or its functionality distributed. The module, manager, interface, platform, or engine can include general or special purpose hardware, firmware, or software embodied in a computer-readable (storage) medium for execution by the processor. As used herein, a computer-readable medium or computer-readable storage medium is intended to include all media that are statutory (e.g., in the United States, under 35 U.S.C. § 101), and to specifically exclude all media that are non-statutory in nature to the extent that the exclusion is necessary for a claim that includes the computer-readable (storage) medium to be valid. Known statutory computer-readable mediums include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage, to name a few), but may or may not be limited to hardware.

FIG. 1is a block diagram illustrating a network-based environment100within which some embodiments of the disclosed technology can be implemented. The environment100includes a first user device104belonging to a user101and a second user device106belonging to a user102. The user101may be referred to as a “sender,” a “payer,” a “customer,” or a “consumer” depending on the context of the examples being described throughout the description, without any intended change in meaning or functionality associated with the user101. The user102may be referred to as a “recipient,” a “payee,” or a “merchant,” depending on the context of the examples being described throughout the description. The user devices104,106can be any computing device capable of general purpose processing and data communications. In one example, each user device104,106can be a smart phone, tablet computer, notebook computer, or any other form of mobile processing device. In another example, each user device104,106can be a desktop computer, a stationary point-of-sale (POS) computer, or any other form of non-mobile processing device. An application can run, or execute, on the user device104,106. The application can be a mobile application, e.g., executing on a mobile computing device, or a conventional software application, e.g., executing on a conventional personal computer (PC).

The environment also includes a computer system110of an intermediary payment service (hereinafter, “payment service system110”), a computer system120of a financial institution (hereinafter, “financial system120”), which is associated with the user101, and a computer system130of another financial institution (hereinafter, “financial system130”), which is associated with the user102. The financial systems120,130can each include an acquirer computer system, an issuing bank computer system, and/or a card payment network computer system. Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks.

All of the aforementioned devices and computer systems are coupled in communication for data transmission over a network108, which can be or include the Internet and one or more wireless networks (e.g., a WiFi network and/or a cellular telecommunications network). The technologies supporting the communications between the user devices104,106, the payment service system110, and the financial systems120,130can include Ethernet (e.g., as described in IEEE 802.3 family of standards) and/or other suitable types of area network technologies.

According to one embodiment of the disclosed technology, the PSS110receives a request associated with a transaction, such as a sales transaction (e.g., a purchase) or a money transfer (e.g., peer-to-peer transfer for an “IOU” debt), and facilitates that transaction in response to the request. In a first part, the PSS110receives a request to generate a token from the user device106of the recipient102, where the recipient102inputs some information in the request. In some embodiments, the information can include, for example, identification information of the recipient102. In such embodiments, the PSS generates the token in response to the request, and associates the generated token with the identification information. The association between the generated token and the identification information is then stored by the PSS, e.g., in a database of the PSS. For example, the token is a string of characters “ABC1234,” and the PSS stores “ABC1234” in association with an email address of the recipient102(i.e., the identification information of the recipient102). In some embodiments, the information can include transaction information associated with a transaction in which the recipient102wishes to receive money. In such embodiments, the PSS generates the token and associates that token with the transaction information, where the association between the token and the transaction information is stored by the PSS, e.g., in a database. For example, the token is a QR code, and the PSS stores content of the QR code in association with a transaction ID provided by the recipient102(i.e., the transaction information).

Upon storing the association between the token and the information, the PSS110transmits the token back to the user device106for display to the recipient102. Note that in other embodiments, the PSS110can communicate with a mobile application installed on the user device106to facilitate generation of the token. In such embodiments, the mobile application, upon receiving the request with the inputted information from the recipient102, generates the token and transmits the generated token (e.g., a copy of the generated token) and the information to the PSS, which associates the token with the information and stores such association for use in future transactions.

In a second part, the recipient102, upon receiving the generated token, communicates with the sender101to transmit the token to the sender101, e.g., by using the user device106to communicate with the user device104. In a third part, the sender101transmits the token to the PSS110to request that money be transferred to an individual identified by the token, i.e., the recipient102. The sender101can transmit the token by an email mechanism, an SMS mechanism, a web interface mechanism, a mobile application mechanism, or the like. For example, the sender101submits a money transfer request to the PSS110in the form of an SMS message that includes the token, where the SMS message is sent to a telephone number associated with the PSS110. The PSS110receives the request from the sender101and, in turn, executes the transfer of money.

In some embodiments, the PSS110communicates with the financial system120that facilitates the financial account of the sender101. In such embodiments, the PSS110can, for example, route an authorization request to the financial system120. If the transaction is approved or authorized by the financial system120, a payment authorization message is sent from the financial account120to the PSS110. Once the transaction is authorized, settlement and clearing occurs. During settlement and clearing, the issuer sends the funds associated with the authorized transaction to the financial system130to be deposited in the account of the recipient102.

FIG. 2illustrates an example payment transaction flow200in accordance with a first embodiment of the disclosed technology. For ease of discussion of the payment transaction flow200, consider an example scenario in which a seller202is an independent artist who wants to be paid for the sale of various paintings at an arts-and-crafts fair. The payment transaction flow200involves the transmission of a token208from the seller202to a buyer204. In the payment transaction flow200, the token208is an enriched token. As used here, an “enriched token” refers to a token embedded with a sufficient amount of information about a particular financial transaction that allows another user, in possession of such token, to carry out the particular financial transaction involving a payment transfer without having to provide any further information. That is, upon sending of the token208to the PSS110, the PSS110has all the information it needs to execute the payment transfer, e.g., for the sale/purchase of the paintings. Note that this information embedded in the token does not include identification information of the payment recipient. For example, the information embedded in the token208is the transaction information for the paintings, e.g., the transaction date, the transaction ID, the description of the items, the itemized prices, and the total amount.

The payment transaction flow200begins when the seller202launches, or opens, a mobile payment application240, installed on his mobile device206, to start the process for a transfer of money, or a payment, for the paintings (“payment transfer”). The mobile payment application240is associated with the PSS110. The mobile payment application240allows the seller202to generate the token208for use in the facilitation of the payment transfer. The token208enables the seller202to identify himself as the recipient of a particular payment amount, and enables any individual, such as a buyer201, to send money to the identified recipient, so long as that individual possesses the token208, without requiring the seller202to reveal his personal identity to the individual. Among other benefits, use of the token208enables the seller202to conceal his identification information from any individual in possession of the token208, as the identification information is stored in association with the token208by the PSS110, and such association is known only upon identification by the PSS110. That is, while the token208may be transferrable and/or read by any computer system (e.g., the mobile device204of the buyer201), the identification information associated with the token208is stored, and thereby concealed, by the PSS110from any computer system in possession of the token208, enabling the seller202to remain anonymous. For example, where the token is a string of characters with the content “J111010101,” only the PSS110is able to identify that the digits “J111010101” is associated, or linked, to the email address “JaneDoe@gmail.com” of Jane Doe (i.e., the identification information of the seller202).

Referring back to the payment transaction flow200, the seller202inputs, through the mobile payment application240, various information to request for the token208(e.g., using a touch screen, keyboard, voice recognition, etc., of the mobile device206). In the embodiment illustrated inFIG. 2, the various information includes personal information identifying the seller202(“identification information”) and information about a particular transaction for which the seller202wishes to receive payment (“transaction information”). An example of the identification information that is submitted and associated with the token208is illustrated in a detailed example211ofFIG. 2. An example of the transaction information that is submitted and embedded in the token208is illustrated in a detailed example212ofFIG. 2.

The transaction information can include a merchant identification number or identifier (“merchant ID”), a timestamp indicating a transaction time and date, a transaction identifier (“transaction ID”), a transaction amount (e.g., price for purchase of two paintings), a description of transaction items (e.g., list of items and individual prices, total price, etc.), and the like. In some embodiments, the transaction information can be automatically received as part of a financial transaction (e.g., a purchase) executing on the mobile payment application240operating as a point-of-sale (POS) system for the seller202, as opposed to being manually inputted by the seller202. For example, the seller202“rings up” a purchase transaction using a POS interface executing on the mobile payment application240, and selects “Get paid with token.” In this example, the transaction information for the purchase is automatically extracted for use in the token generation process.

In some embodiments, the identification information can be any identifier that identifies the seller202including, for example, an email address, a telephone number, a driver's license number, a social security number, an employee identification number or identifier, a device identifier, an application identifier, an IP address, a personal identification number (PIN), a card verification value (CVV), a security access code, a biometric identifier (e.g., fingerprint, face, iris, retina, etc.), or any other identification means that function as a combination thereof. For example, where the identification information is an email address, the PSS110can use the email address to identify the seller202and a financial account associated with that email address.

In some embodiments, the identification information can include financial account information identifying the financial account of the seller202. In such embodiments, the PSS110, for example, can identify the financial account without requiring the PSS110to determine an association between the email address and the financial account information. In some embodiments, the identification information can include a billing address of the seller202. In some embodiments, the identification information can include a mailing address of the seller202.

Upon receiving from the seller202submission of all desired information, the mobile payment application240generates the token208with the transaction information embedded. The mobile payment application240then forwards the generated token along with the submitted identification information to the PSS110, as indicated by step210A. The PSS110, in turn, associates the received token with the received identification information and stores the association, e.g., in a database (e.g., user account DB604). For example, where the content of the token208is “12345,” the PSS110associates the content of the token with “johnj@gmail.com.” As will be explained in further details below, the PSS110can use this stored association to process a money transfer between the seller202and the buyer201when the PSS110receives the generated token208again from the buyer201at step220.

In some embodiments, the generated token208is in the form of an encrypted message. In such embodiments, the mobile payment application240includes a token generator (not shown) that can generate the encrypted message. In some embodiments, the generated token208is in the form of a Quick Response Code (“QR Code”). In such embodiments, the mobile payment application240includes a token generator (not shown) capable of generating a QR Code. In some embodiments, the generated token208is in the form of a media file, such as an audio file, a video file, an image file. In such embodiments, the mobile payment application240includes a token generator (not shown) capable of generating the media file.

The payment transaction flow200continues at step210B when the seller202provides the token208to the buyer201. In some embodiments, the seller202can provide the token208through a communication broadcast (e.g., Wi-Fi®, Bluetooth®, Bluetooth® Low Energy, Near Field Communication (NFC), Apple® AirDrop®, etc.). For example, the seller202enables the AirDrop® feature on his iPhone® (e.g., mobile device206) to transmit an image token to a nearby iPhone® (e.g., mobile device204of the buyer201). In another example, the seller202broadcasts the token in the form of a QR Code by using Bluetooth® Low Energy to enable nearby mobile devices, such as the mobile device204of the buyer201, to receive the QR Code.

In some embodiments, the seller202can provide the token208by physically showing it to the buyer201. For example, the seller202prints out the QR code, which has been generated by the mobile payment application240, and displays it in front of his merchandise for any interested buyer, such as the buyer201, to scan, e.g., using a camera of the mobile device204. In this example, the buyer201can scan the QR code when she is ready to make a purchase from the seller202(i.e., ready to tender him money for the merchandise).

In some embodiments, the buyer201can view the content of the token208through a mobile payment application242installed on the mobile device204of the buyer201. In such embodiments, the mobile payment application242can be a different application or the same application utilized by the seller202(e.g., mobile payment application240). The buyer201launches the mobile payment application242, which extracts and displays for the buyer201the content of the token208, which includes the transaction information.[SI2]For example, the token208is an image token and the image, along with the transaction information, are displayed for the buyer201through the mobile payment application242. In another example, the token208is a string of numbers, and the numbers “12345,” along with the transaction information, are displayed for the buyer201through the mobile payment application242. In both examples, the displayed content does not include any identification information of the seller202, enabling the seller202to remain anonymous to the buyer201. Only the PSS110, which is able to identify the seller202based on a previously stored association between the token and the identification information of the seller202.

In some embodiments, the mobile payment application242can display a transaction prompt to facilitate the sending of a request message222to the PSS110, upon receipt of the token208. For example, the mobile payment application242generates and displays a prompt to the buyer101, “Do you agree to pay the merchant $15 for painting A1in this purchase transaction?” In step220, upon receiving an approval to proceed from the buyer201(e.g., the buyer201clicks “Yes” in response to the prompt), the mobile payment application242transmits the request message222to the PSS110, as indicated in step220, to request that money be transferred to the recipient identified by the token208.

In some embodiments, the buyer201transmits the request message222to the PSS110, as indicated by step220, by using an email mechanism. In such embodiments, the buyer201launches an email application (e.g., a native email application installed on the mobile device204, a web-based email application, etc.) to compose an email to be sent to an email address associated with the PSS110(“PSS email address”). The buyer201can attach the token208in the body of the email. The buyer201can also include other information in the body or subject line of the email. For example, the buyer201inputs a payment amount in the subject line of the email to indicate how much money the buyer201wishes to send to the seller202. In another example, the buyer201inputs the shipping address of the buyer201. Other customized information can also be included in the email (e.g., special customer note, updated billing address, etc.). Note that in this example, the email itself includes the email address of the buyer201(“buyer email address”), which can serve as the identification information of the buyer201to be used in the processing of the payment transfer.

Upon receiving the request message222, the PSS110analyzes the included token208to determine the identity and associated financial account of the payment recipient (i.e., the seller204). In particular, the PSS110analyzes the identification information stored in association with the token208to determine an identity of the recipient to whom money should be sent. The identification information can be, for example, an email address of the seller202(“seller email address”). In such example, the PSS110performs a database lookup to identify a match to the seller email address. If there is a match, the PSS110identifies any financial account that has been previously linked, or associated, with the seller email address, and utilizes the identified financial account in the execution, or the triggering of the execution of, the payment transfer. Example databases maintained by the PSS110to perform the lookup is shown as databases702,704inFIG. 7.

Note, in some embodiments, the seller email address may be a payment service account with the PSS110created by the seller202, who has provided to the PSS110the financial account information identifying the financial account when creating the payment service account. In such embodiments, the PSS110stores that financial account information in association with the email address. In some embodiments, the financial account information is provided to the mobile payment application240at the time the seller202requests for the token208. In such embodiments, the financial account information is forwarded to the PSS110to store in association with the identification information of the seller202, which is then stored in association with the token208.

In some embodiments, the financial account information of the seller202is submitted after the buyer201sends a request222to the PSS110. That is, the PSS110is unable to identify the financial account of the seller202. For example, the financial account information is not stored previously by the PSS110, is not provided along with the request for the token208, is not an active account, or is otherwise not available, thereby preventing the PSS110to identify, access, and/or communicate with the financial account of the seller202. In such embodiments, upon an unsuccessful attempt to identify the financial account of the seller202, the PSS110sends a financial account request message to the seller202(e.g., through the mobile payment application240, the seller email address, the seller telephone number, etc.). The financial account request message is configured to prompt the seller202to input financial account information associated with a particular financial account that the seller202desires to utilize for the money transfer.

Referring back to the payment process flow200, the PSS110further analyzes other information associated with the request message222to determine the identity and financial account of the buyer201who has sent the request message222. The information associated with the request message222can include the information submitted by the buyer201and/or inherent information that is included the request message222. The inherent information can include, for example, identification information of the request message sender, i.e., the buyer201, (“buyer identification information”), such as the email address of the buyer201from which the “request message” email has been sent (“buyer email address”). In an example, the PSS110performs a database lookup to identify a match to the buyer email address. If there is a match, the PSS110identifies any financial account that has been previously linked, or associated, with the buyer email address, and utilizes the identified financial account in the execution, or the triggering of the execution of, the payment transfer. Example databases maintained by the PSS110to perform the lookup is shown as databases702,704inFIG. 7.

Note, in some embodiments, the buyer email address may be a payment service account with the PSS110created by the buyer201, who has provided to the PSS110the financial account information identifying the financial account when creating the payment service account. In such embodiments, the PSS110stores that financial account information in association with the email address. In some embodiments, the financial account information is included in the request222sent to the PSS110, e.g., through the mobile payment application242. In such embodiments, the PSS110receives the financial account information and stores it in association with any identification information of the buyer201(e.g., email address). In some embodiments, the identification information of the buyer201includes the financial account information identifying the financial account of the buyer201.

In some embodiments, the financial account information is submitted after the buyer201sends the request222to the PSS110. That is, the PSS110is unable to identify the financial account of the buyer201. For example, the financial account information is not stored previously by the PSS110, is not provided in the request222, is not an active account, or is otherwise not available, thereby preventing the PSS110to identify, access, and/or communicate with the financial account of the buyer201. In such embodiments, upon an unsuccessful attempt to identify the financial account of the buyer201, the PSS110sends a financial account request message to the buyer201(e.g., through the mobile payment application242, the seller email address, the seller telephone number, etc.). The financial account request message is configured to prompt the buyer201to input financial account information associated with a particular financial account that the buyer201desires to utilize for the money transfer.

At step230, upon successful identification of the respective financial accounts of the buyer201and the seller202, the PSS110executes, or triggers execution of, the transfer of money232from the identified financial account of the buyer201to the identified financial account of the seller202. In some embodiments, before the PSS110executes the transfer of money, the PSS110further analyzes the transaction information embedded in the token208to determine the payment amount to transfer. Once the PSS110successfully transfers the money (e.g., debits the bank account of the seller202with a payment amount from the bank account of the buyer201), the PSS110sends a confirmation message to the seller202. In some embodiments, the PSS110can also send a confirmation message to the buyer201to inform the buyer201that the payment amount has been transferred.

Once the seller202has received the confirmation message from the PSS110, the seller202can then, for example, provide the two paintings to the buyer201. In some embodiments, the seller202can also send a confirmation message to the PSS110to indicate that he has rendered the goods to the buyer201. An example confirmation message can include a reference number that the PSS110can utilize to generate a receipt for the transaction, where the receipt can be utilized for a refund. For example, the PSS110generates a receipt for each of the buyer201and seller202, where that receipt includes the reference number along with the transaction information extracted from the token208. Further details regarding the receipt and the refund process will be discussed below in at least with reference toFIG. 4.

Note that in the above provided example, the payment transaction flow200discusses providing the token208to only one individual, the buyer201, according to one embodiment of the disclosed technology. However, in other embodiments, the seller202can provide the same token208to multiple buyers to have money be transferred to him in multiple transactions (e.g., multiple sales of the same two painting replicas to different buyers). In such embodiments, the multiple buyers can each transfer money (i.e., a payment) to the seller202by including the token208in their respective payment transfer requests222to the PSS110.

FIG. 3illustrates an example payment transaction flow300in accordance with a second embodiment of the disclosed technology. For the discussion inFIG. 3, consider a similar example discussed above with respect toFIG. 2, in which a seller302wants to be paid for the sale of various paintings from his design collection. In contrast to the example inFIG. 2, however, the payment transaction flow300ofFIG. 3involves the transmission of a token308from the seller302to both (a) a buyer301and (b) the PSS110. In the payment transaction flow300, the token308is a simplified token, in contrast to the enriched token208ofFIG. 2. As used here, a “simplified token” refers to a token embedded with a minimum amount of information that simply enables anyone, in possession of the token, to start the process of payment transfer for any kind of financial transaction (e.g., a purchase transaction, an IOU debt transaction, etc.). That is, upon sending of the token308to the PSS110, the PSS110needs more information about the transaction (e.g., transaction information such as the transaction ID, the transaction items being purchased, etc.) in order to execute the payment transfer. For example, the minimum amount of information can be a string of characters representative of the token308. An example of the minimum amount of information, or content, of the token308is illustrated in a detailed example316ofFIG. 3.

The payment transaction flow300begins when the seller302launches, or opens, a mobile payment application350, installed on his mobile device306, to initiate a transfer of money, or a payment, for the paintings (“payment transfer”). The mobile payment application350is associated with the PSS110. The mobile payment application350allows the seller302to generate the token308for use in the facilitation of the payment transfer. The token308enables the seller302to identify himself as the recipient of a particular payment amount, and enables any individual, such as the buyer301, to send money to the identified recipient, so long as that individual possesses the token308, without requiring the seller302to reveal his personal identity to the individual. Among other benefits, use of the token308enables the seller302to conceal his identification information from any individual in possession of the token308, as the identification information is stored in association with the token308by the PSS110, and such association is known only upon identification by the PSS110.[SI3]That is, while the token308may be transferrable and/or read by any computer system (e.g., the mobile device304of the buyer301), the identification information associated with the token308is stored, and thereby concealed, by the PSS110from any computer system in possession of the token308, enabling the seller302to remain anonymous. For example, where the token is a string of characters with the content “987654,” only the PSS110is able to identify that the digits “987654” is associated, or linked, to the telephone number “503-727-1000” of John Doe (i.e., the identification information of the seller302).

Referring back to the payment transaction flow300, the seller302, inputs, through the mobile payment application350, various information to request for the token308(e.g., by using a touch screen, keyboard, voice recognition, etc. of the mobile device306). The various information can include personal information identifying the seller302(“identification information”) and information about a particular transaction for which the seller302wishes to receive payment (“transaction information”).

The transaction information can include a merchant identification number or identifier (“merchant ID”), a timestamp indicating a transaction time and/or date, a transaction identifier (“transaction ID”), a transaction amount (e.g., total price for purchase of two paintings), a description of transaction items (e.g., list of items and individual prices, total price, etc.), and/or the like. In some embodiments, the transaction information can be automatically received as part of a financial transaction (e.g., a purchase) executing on the mobile payment application350operating as a point-of-sale (POS) system for the seller302, as opposed to being manually inputted by the seller302. For example, the seller302“rings up” a purchase transaction using a POS interface executing on the mobile payment application350, and selects “Get paid with token.” In this example, the transaction information for the purchase is automatically extracted for use in the token generation process.

In some embodiments, the identification information can be any identifier that identifies the seller302, including, for example, an email address, a telephone number, a driver's license number, a social security number, an employee identification number or identifier (ID), a device identifier, an application identifier, an IP address, a personal identification number (PIN), a card verification value (CVV), a security access code, a biometric identifier (e.g., fingerprint, face, iris, retina, etc.), or any other identification means that function as a combination thereof. In the embodiment ofFIG. 3, the seller302submits his email address (“seller email address”) as the identifier. For example, where the identification information is an email address, the PSS110can use the email address to identify the seller302and a financial account associated with that email address.

In some embodiments, the identification information inputted by the seller302can include financial account information identifying the financial account of the seller302. In such embodiments, the PSS110, for example, can identify the financial account without requiring the PSS110to determine an association between the email address and the financial account information. In some embodiments, the identification information can include a billing address of the seller302. In some embodiments, the identification information can include a mailing address of the seller302.

Upon receiving the identification information and the transaction information from the seller302, the mobile payment application350generates the token308. Note, in contrast to the payment transaction flow200, the payment transaction flow300does not involve embedding the generated token308with any additional information, such as the transaction information.

In some embodiments, the token308is in the form of an encrypted message. In such embodiments, the mobile payment application350includes a token generator (not shown) that can generate the encrypted message. In some embodiments, the token308is in the form of a Quick Response Code (“QR Code”). In such embodiments, the mobile payment application350includes a token generator (not shown) that can generate a QR Code®. In some embodiments, the token308is in the form of a media file, such as an audio file, a video file, an image file. In such embodiments, the mobile payment application350includes a token generator (not shown) that can generate the media file.

The payment transaction flow300continues at steps310and320when the seller302provides the token308to the PSS110and to the buyer301, respectively. In particular, at step310, the seller302transmits a merchant message312to the PSS110. The merchant message312includes the generated token308(e.g., a copy of the token308), the identification information of the seller302, and the transaction information. An example merchant message314with the identification information (e.g., “MerchantID: seller @mail.us”) and the transaction information is illustrated inFIG. 3.

In some embodiments, the seller302transmits the merchant message312to the PSS110by use of an email mechanism. In such embodiments, the seller302launches an email application (e.g., a native email application installed on the mobile device204, a web-based email application, etc.) to compose an email to be sent to an email address associated with the PSS110(“PSS email address”). The seller302can include the token308as an attachment to the email and input the transaction information and the identification information in the body and/or the subject line of the email.

In some embodiments, the seller302transmits the merchant message312to the PSS110through the mobile payment application350installed on the mobile device306. In such embodiments, the seller302launches the mobile payment application350to submit the merchant message312to the PSS110. The seller302can submit, to the mobile payment application350, the token308, the identification information, and the transaction information to be included in the merchant message222. Upon receiving from the seller302submission of all desired information, the mobile payment application350transmits the merchant message312to the PSS110.

The PSS110receives the merchant message312and stores the information, e.g., in a database. In particular, the PSS110associates the token308with the received identification information, and stores such association, e.g., in a database (e.g., user account DB604). For example, where the content of the token208is “12345,” the PSS110associates the content of the token with the email address “johnj@gmail.com.” The PSS110further associates the token308with the transaction information received in the merchant message312, and stores such association. As will be explained in further details below, the PSS110can use the stored associations to process a money transfer between the seller302and the buyer301when the PSS110receives the generated token308again from the buyer301at step330.

The payment transaction flow300continues at step320, where the seller302also provides the token308to the buyer301. In some embodiments, the seller302can provide the token308through a communication broadcast (e.g., Wi-Fi®, Bluetooth®, Bluetooth® Low Energy, Near Field Communication (NFC), Apple® AirDrop®, etc.). For example, the seller302enables the AirDrop® feature on his iPhone® (e.g., mobile device306) to transmit an image token to a nearby iPhone® (e.g., mobile device304of the buyer301). In another example, the seller302broadcasts the token in the form of an encrypted message by using Bluetooth® Low Energy to enable nearby mobile devices, such as the mobile device304of the buyer301, to receive the encrypted message.

In some embodiments, the seller302can provide the token308by physically showing it to the buyer301. For example, the seller302prints out a QR code token, which has been generated by the mobile payment application350, and displays it in front of his merchandise for any interested buyer, such as the buyer301, to scan, e.g., by using a camera of the mobile device304. In this example, the buyer301can scan the QR code when she is ready to make a purchase from the seller302(i.e., ready to tender him money for the merchandise).

In some embodiments, the buyer301can receive the token308and view the content of the token308through a mobile payment application352installed on the mobile device304of the buyer301. In such embodiments, the mobile payment application352can be a different application or the same application utilized by the seller302(e.g., mobile payment application350). The buyer301launches the mobile payment application352, which extracts and displays for the buyer301the content of the token308. For example, the token308is an image token and the image is displayed for the buyer301through the mobile payment application352. In this example, the displayed content does not include any identification information of the seller302, as the identification information has been sent only to the PSS110for storage, enabling the seller302to remain anonymous to the buyer301.

At step330, the buyer301transmits a request message332, which includes the token308, to the payment service system110(“PSS110”) to request that a payment be made (i.e., money to be transferred) to a recipient identified by the token308. In some embodiments, the request message222also includes a payment amount specified by the buyer301. For example, the payment amount is the transaction amount for the purchase of three paintings from the seller302. In some embodiments, the request message222include identification information associated with the buyer301. For example, the identification information includes an email address of the buyer301. In another example, the identification information includes financial account information identifying a financial account of the buyer301. In yet another example, the identification information includes a telephone number of the buyer301.

In some embodiments, the buyer301transmits the request message222to the PSS through the mobile payment application352installed on the mobile device304. In such embodiments, the mobile payment application352generates and displays a transaction prompt to facilitate the sending of the request message332. For example, the transaction prompt displays the message, “Would you like to pay the identified merchant?” In such example, upon receiving an approval to proceed from the buyer301(e.g., the buyer301clicks “Yes” and enters an amount in response to the prompt), the mobile payment application352transmits the request message332to the PSS110, as indicated by step330.

In some embodiments, the buyer301transmits the request message332to the PSS110, as indicated by step330, by using an email mechanism. In such embodiments, the buyer301launches an email application (e.g., a native email application installed on the mobile device304, a web-based email application, etc.) to compose an email to be sent to an email address associated with the PSS110(“PSS email address”). The buyer301can attach the token308in the body of the email. The buyer301can also include other information in the body or subject line of the email. For example, the buyer301inputs a payment amount in the subject line of the email to indicate how much money the buyer301wishes to send to the seller302. In another example, the buyer301inputs the shipping address of the buyer301. Other customized information can also be included in the email (e.g., special customer note, updated billing address, etc.). Note that in this example, the email itself includes the email address of the buyer301(“buyer email address”), which can serve as the identification information of the buyer301to be used in processing of the payment transfer. Note that in other embodiments, other mechanisms may be used by the buyer301to transfer the request message332to the PSS110. For example, the buyer301can send an SMS message or a message using a web interface of a website hosted by the PSS110.

Upon receiving the request message332from the buyer301, the PSS analyzes the included token308and compares it to the token received in the merchant message312sent from the seller302. In response to identifying a match between the tokens, the PSS identifies the identification information associated with the seller302based on the previously stored association between the token308and the identification information. The PSS can further utilize the identification information to identify a financial account of the seller302. For example, the seller302has provided, in the past, to the PSS financial account information identifying a financial account of the seller302, which the PSS110has stored in association with the identification information. The PSS110can utilize the identified financial account to execute the payment transfer. Example databases maintained by the PSS110to perform the lookup of the token and the identification information is shown as databases702,704inFIG. 7.

The PSS can further analyze the merchant message312to identify the transaction information included in the merchant message312. In some embodiments, the PSS110determines an amount that should be transferred based on a matching of transaction amount specified by the transaction information included in the merchant message312and the transaction amount specified by the buyer301in the request message332.

The PSS110further analyzes other information associated with the request message332to determine the identity and financial account of the buyer301. The information associated with the request message332can include the information submitted by the buyer301and/or inherent information that is included in the request message332. The inherent information can include, for example, identification information of the request message sender, i.e., the buyer301, (“buyer identification information”), such as the email address of the buyer301from which the “request message” email has been sent (“buyer email address”). In an example, the PSS110performs a database lookup to identify a match to the buyer email address. If there is a match, the PSS110identifies any financial account that has been previously linked, or associated, with the buyer email address, and utilizes the identified financial account in the execution, or the triggering of the execution of, the payment transfer. Example databases maintained by the PSS110to perform the lookup is shown as databases702,704inFIG. 7.

Note, in some embodiments, the buyer email address may be a payment service account with the PSS110created by the buyer301, who has provided to the PSS110the financial account information identifying the financial account when creating the payment service account. In such embodiments, the PSS110stores that financial account information in association with the email address. In some embodiments, the financial account information is included in the request332sent to the PSS110, e.g., through the mobile payment application352. In such embodiments, the PSS110receives the financial account information and stores it in association with any identification information of the buyer301(e.g., email address). In some embodiments, the identification information of the buyer301includes the financial account information identifying the financial account of the buyer301.

In some embodiments, the financial account information is submitted after the buyer301sends the request332to the PSS110. That is, the PSS110is unable to identify the financial account of the buyer201. For example, the financial account information is not stored previously by the PSS110, is not provided in the request332, is not an active account, or is otherwise unavailable, thereby preventing the PSS110to identify, access, and/or communicate with the financial account of the buyer301. In such embodiments, upon an unsuccessful attempt to identify the financial account of the buyer301, the PSS110sends a financial account request message to the buyer301(e.g., through the mobile payment application352, the seller email address, the seller telephone number, etc.). The financial account request message is configured to prompt the buyer301to input financial account information associated with a particular financial account that the buyer301desires to utilize for the money transfer.

At step340, upon successful identification of the respective financial accounts of the buyer301and the seller302, the PSS110executes or triggers execution of the transfer of money342. In some embodiments, before the PSS110executes the transfer of money, the PSS110further analyzes the transaction information included in the merchant message312to determine the payment amount to transfer. In some embodiments, prior to executing the transfer of money342, the PSS110also performs an additional step to verify whether the financial account of the buyer301has sufficient funds to satisfy the payment amount requested. Further details regarding the verification step will be discussed inFIG. 5below.

Once the PSS110successfully transfers the money (e.g., debits the bank account of the seller302with a payment amount from the bank account of the buyer301), the PSS110sends a confirmation message to the seller302. In some embodiments, the PSS110can also send a confirmation message to the buyer301to inform the buyer301that the payment amount has been transferred.

Once the seller302has received the confirmation message from the PSS110, the seller302can then, for example, provide the two paintings to the buyer301. In some embodiments, the seller302can also send a confirmation message to the PSS110to indicate that he has rendered the goods to the buyer301. An example confirmation message can include a reference number that the PSS110can utilize to generate a receipt for the transaction, where the receipt can be utilized for a refund. For example, the PSS110generates a receipt for each of the buyer301and seller302, where that receipt includes the reference number along with the transaction information extracted from the merchant message312. Further details regarding the receipt and the refund process will be discussed below in at least with reference toFIG. 4.

Note that in the above provided example, the payment transaction flow300discusses providing the token308to the PSS110and to only one individual money sender (i.e., the buyer302), in accordance with one embodiment of the disclosed technology. However, in other embodiments, the seller302can provide the same token308to multiple money senders (e.g., two or more buyers). In such embodiments, the multiple money senders each transfers money (i.e., a payment) to the seller302by including the token308in their respective payment transfer requests to the PSS110. Further, the seller302, at the same time, can send multiple, different merchant messages corresponding to each of the buyers. The seller302can include different transaction information in each merchant message to correspond to a particular transaction associated with a particular buyer, while attaching the same308token in the merchant message. For example, the seller302sends a first merchant message312A to include transaction details for only 1 item to be sold to a buyer301A, and a second merchant message312B to include details for 3 items sold to a buyer301B.

In reference toFIGS. 2 and 3, the examples provided above, according to some embodiments, require that the buyer201,301and the seller202,302must each have a user account with the payment service system110(“payment service account”) before the transaction to transfer the payment can be performed. In some embodiments, only the seller301,302is required to have a payment service account, and a payment service account is automatically created for the buyer201,301upon the buyer201,301sending the request message220,332to the PSS110.

A user, such as the buyer201,301, can sign up using the mobile payment application342,352or another mobile application, or using an online website to communicate with the PSS110. The user can use the mobile device or another computing device, e.g., a home computer, to sign up. At some point prior to the transaction, a mobile application is downloaded to the mobile device, e.g., through an application store. Creation of the payment service account can be handled through the mobile application, or through another application, e.g., a generic web browser, communicating with the PSS110. The user enters a name, account password, and identification information, e.g., an email address where the user can be contacted, a social security number, a personal pin number, etc.

Additionally, before any payment transaction can be performed, the user also enters financial account information sufficient to conduct the transaction into the PSS110. For example, in the case of a credit card account, the user can enter the credit card issuer, credit card number and expiration date into the PSS110; the card validation value and mailing address may also be required. However, the financial account could also be associated with a debit card or pre-paid card, or another third party financial account. The data associated with a payment service account can be stored, e.g., in a database of the PSS110.

In some embodiments, if the user is a merchant, such as the seller202,302, the user can also provide other information, e.g., a list of goods or services available, operating hours, phone number, a small identifying image logo or mark, to the payment service system110. The data associated with such user can be store, e.g., in a database of the PSS110.

Note that each of the tokens208,308generated in the payment transaction flows200,300can include other information not discussed in the examples above, as long as that information does not include identification information of the seller202,302.

FIG. 4is a sequence diagram illustrating a process for an anonymous transfer of payment between a sender and a recipient by use of an enriched token. For purposes of illustration only, the process ofFIG. 4is explained with reference to certain elements illustrated inFIG. 1. The process ofFIG. 4involves the recipient102initiating a transfer of money to be sent to him from the sender101by use of an enriched token.

In some embodiments, before the transfer of money can take place, the recipient102is required to have a user account with the payment service system110(“payment service account”). The recipient102can sign up for a payment service account at step400A, or another time before money actually gets transferred to a financial account of the recipient102(e.g., at step430(a)). In particular, creation of the payment service account can be handled through a mobile application, or through another application, e.g., a generic web browser, capable of communicating with the PSS110. Through the application, the recipient102enters a name, account password, and identification information, e.g., an email address where the user can be contacted, a social security number, a personal pin number, etc. In some embodiments, the recipient102also enters financial account information sufficient to conduct any payment transaction to be saved in database of the PSS110. For example, in the case of a credit card account, the recipient102can enter the credit card issuer, credit card number and expiration date into the PSS110; the card validation value and mailing address may also be required. However, the financial account could also be associated with a debit card or pre-paid card, or another third party financial account such as a bank. In some embodiments, the recipient102can also provide other information, e.g., a list of goods or services available, operating hours, phone number, a small identifying image logo or mark, to the payment service system110. In such embodiments, provision of the other information to the PSS110is beneficial if the recipient102utilizes the payment service account as a merchant account to conduct sales.

At step402, the recipient102launches, or opens, a mobile payment application installed on his mobile device106to initiate the transfer of a payment, or money. The mobile payment application is associated with the PSS110, and can communicate with the PSS110in facilitating the payment transfer (e.g., transmit, receive, and execute instructions of the PSS110). The mobile payment application can be the same application used to create the payment service account as described in the embodiment above.

The mobile payment application allows the recipient102to generate a token that contains embedded information for use in the facilitation of the payment transfer. The embedded information, according to the embodiment ofFIG. 4, includes transaction information related to the transaction between the sender101and the recipient102.

At step402, the recipient102submits, through the mobile payment application, the transaction information in addition to identification information associated with the recipient102. The identification information can be, for example, an email address of the recipient (“recipient email address”). In some embodiments, the identification information is automatically detected, or determined, by the mobile payment application if the recipient102is logged into his payment service account110. For example, the username for the payment service account, which is the recipient email address, is automatically detected by the mobile payment application. The transaction information can include, for example, a timestamp indicating a transaction time and date, a transaction amount (e.g., amount of “IOU” debt owed by the sender101to the recipient102), a description of transaction items (e.g., IOU for pizza and beverages in social outing), and the like.

Upon receiving all of the information, the mobile payment application generates for the recipient102the token embedded with the transaction information. In some embodiments, the token is in the form of an encrypted message. In some embodiments, the token is in the form of a Quick Response Code (“QR Code”). In some embodiments, the token is in the form of a media file, such as an audio file, a video file, an image file.

At step404A, the recipient102provides the token to the sender102. In the embodiment ofFIG. 4, the recipient102provides the token by transmitting the token to the user device104of the sender102. The token transmission can be carried out through a communication broadcast (e.g., Wi-Fi®, Bluetooth®, Bluetooth® Low Energy (BLE), Near Field Communication (NFC), Apple® AirDrop®, etc.). For example, the user device106, through the mobile payment application, generates a QR code and transmits it to the user device104over BLE.

At step404B, the recipient102provides the token (e.g. a copy of the same token provided to the sender101), in addition to the identification information of the recipient102, to the PSS110. The PSS110stores the token in association with the identification information of the recipient102for use in identifying the recipient associated with the token in future transactions, as indicated by step404C.

At step406, the sender101, having received the token from the recipient102, transmits a request message, which includes the token, to the payment service system110(PSS110) to request that a payment be made (i.e., money to be transferred) to a recipient identified by the token. In some embodiments, the request message also includes a payment amount specified by the sender101. For example, the payment amount is the amount owed by the sender101to the recipient102.

In some embodiments, the sender101transmits the request message through a mobile payment application installed on the user device104. In such embodiments, the sender101can view the content of the token through the mobile payment application. In particular, the mobile payment application installed on the user device104can extract and display for the sender101the transaction information embedded in the enriched token. The mobile payment application is associated with the PSS110, and can communicate with the PSS110in facilitating the payment transfer (e.g., transmit, receive, and execute instructions of the PSS110). The mobile payment application can be a different application or the same application utilized by the recipient102at step402to generate the token.

In some embodiments, the sender101transmits the request message to the PSS110through an email mechanism. In such embodiments, the sender101launches an email application (e.g., a native email application installed on the mobile device104, a web-based email application, etc.) to compose an email to be sent to an email address associated with the PSS110(“PSS email address”). The sender101can include the token as an attachment to the email. The sender101can also include other information in the body or subject line of the email. For example, the sender101inputs a payment amount in the subject line of the email to indicate how much money the sender101wishes to send to the recipient102. In another example, the sender101inputs a personalized note to the recipient102. Note that in this example, use of the email enables the PSS110to use the email address of the sender101as identification information to identify the sender101and to process the payment transfer.

At step408, upon receiving the request message, the PSS110analyzes the token to determine (a) the identity and associated financial account of the payment recipient (i.e., the recipient102), (b) the identity and associated financial account of the payment sender (i.e., the sender101), and (c) the transaction information for which the payment is to be transferred. For example, the PSS110performs a database lookup to identify a matching token and identification information that is stored in association with the token. The PSS110, in this example, utilizes that identification information (e.g., the recipient email address) to identify a financial account that has been previously linked, or associated, with the recipient email address, and utilizes the identified financial account in the execution, or the triggering of the execution of, the payment transfer. For example, the recipient email address is the same email address used to create the payment service account with the PSS110in step400A. As such, the PSS110can correlate that recipient email address to identify a financial account linked to the payment service account.

In some embodiments, if the PSS110is unable to identify the financial account of the recipient102based on the identification information stored in association with the token, the PSS110transmits a message to the recipient102(e.g., through the mobile payment application) to obtain information for the missing financial account. For example, the recipient102did not link a financial account when signing up for the payment service account in step400A. In another example, the recipient102did not sign up for a payment service account at all.

In such embodiments where there is no financial account identified, the PSS110transmits, to the mobile device106, a push notification prompting the recipient102to link a payment card (e.g., a debit card or a credit card) to the identification information (e.g., email address) of the recipient102, as indicated in step430(a). In response to the push notification, the recipient102can submit, through the mobile payment application, payment card information (e.g., card number, expiration date, CVV, etc.) of a particular payment card that identifies a financial account of the seller202.

Upon receiving submission of the payment card information, the PSS110can proceed with executing or triggering execution of the transfer of money. In some embodiments, the PSS110stores the newly submitted payment card information in association with the identification information, thereby linking the payment card to the recipient102. In some embodiments, the PSS110creates a payment service account for the recipient102when it stores an association between the identification information and the financial account of the recipient102. That is, the PSS110performs step400A at this point in the process ofFIG. 4.

At step408, the PSS110further analyzes other information included in the request message to determine the identity and financial account of the sender101who has sent the request message. The information included in the request message can include the information submitted by the sender101and/or inherent information that is part of the request message (e.g., metadata). The inherent information can include identification information of the request message sender. The identification information can be, for example, the email address from which the email has been sent, such as the email address of the sender101(“sender email address”), the device ID from which the email has been sent (e.g., ID of the mobile device104), the IP address from which the email has been sent, or any other information identifying the request message sender.

The PSS110performs a database lookup to identify a match to the identification information of the sender101, e.g., the sender email address. If there is a match, the PSS110identifies any financial account that has been previously linked, or associated, with, e.g., the sender email address, and utilizes the identified financial account in the execution, or the triggering of the execution of, the payment transfer.

In some embodiments, if the PSS110is unable to identify the financial account of the sender101, the PSS110transmits a message to the sender101to obtain information for the missing financial account. In one example, the PSS110transmits to the user device104(e.g., through the mobile payment application) a push notification prompting the sender101to link a payment card (e.g., a debit card or a credit card), as indicated in step430(b). In response to the push notification, the sender101submits payment card information (e.g., card number, expiration date, CW, etc.) of a particular payment card that identifies a financial account of the sender101.

Upon receiving submission of the payment card information, the PSS110can proceed with executing or triggering execution of the transfer of money. In some embodiments, the PSS110stores the newly submitted payment card information in association with the identification information, thereby linking the payment card to the sender101for processing of future transactions. In some embodiments, the PSS110creates a payment service account for the sender101when it stores an association between the identification information and the financial account of the sender101. That is, the PSS110performs step400B at this point in the process ofFIG. 4.

At step410, upon successful identification of the respective financial accounts, the PSS110executes or triggers execution of the transfer of money from the identified financial account of the sender101to the identified financial account of the recipient102. In some embodiments, the PSS110simply communicates with the financial system120, which has been identified as the account of the sender101at step408, to cause the payment amount to be transferred to the financial system130. In such embodiments, the financial system120, in response, transfers funds to the financial system130of the recipient102, as indicated in step412.

In some embodiments, the PSS110performs, at step410, an additional action to verify and confirm that the financial account110has sufficient funds to satisfy the payment amount requested to be transferred. In such embodiments, the PSS110communicates with the financial system120the payment amount and waits for a verification message from the financial system120that the amount has been credited from the account of the sender101to the account of the recipient102(i.e., facilitated by the financial system130. In response to the verification message, the PSS110transmits a message to the user device106of the recipient102indicating that money has been transferred. The recipient102, can then, for example, render goods or services to the sender101. In some embodiments, the recipient102can transmit a message to the PSS110indicating that the goods or services (or any other obligation owed to the sender101in exchange for the money transferred) has been completed, as indicated by step422. The payment transfer process can end at step422.

In some embodiments, the PSS110generates and transfers a receipt (e.g., a confirmation receipt) to both the recipient102and the sender101, as indicated by steps440and442. In some embodiments, the generation and transfer of the receipt can be triggered by the message received from the recipient indicating the transaction (e.g., rendering of goods by the recipient102to the sender101) has been completed. In some embodiments, the generation and transfer of the receipt can be triggered by a successful transfer of the payment amount from a financial account of the sender101to the recipient102.

In some embodiments, the PSS110, in generating the receipt, also generates a second token (not shown) associated with the sender101(i.e., a “sender anonymizing token”). In such embodiments, the PSS110associates the second token with all information relevant to the transfer of money, and stores such association in a database of the PSS110. In some embodiments, the information can include the identification information associated with the recipient102and the sender101, respectively. In some embodiments, the information can include the transaction information, such as a transaction identifier (ID) that identifies the transaction between the sender101and the recipient102, a transaction date, a list of transaction items, the transaction amount, and/or the like. The second token serves to protect the personal identification information of the sender101from being known by the recipient102, and vice versa, as only the PSS110has knowledge of the association between the second token and the identification information. The second token can be included in the receipt and transmitted to each of the recipient102and the sender101.

FIG. 5is a sequence diagram illustrating a process for an anonymous transfer of payment between a sender and a recipient by use of a simplified token. For purposes of illustration only, the process ofFIG. 5is explained with reference to certain elements illustrated inFIG. 1. The process ofFIG. 5involves the recipient102initiating a transfer of money to be sent to him from the sender101.

In some embodiments, before the transfer of money can take place, the recipient102is required to have a user account with the payment service system110(“payment service account”). The recipient102can sign up for a payment service account at step500A, or another time before money actually gets transferred to a financial account of the recipient102(e.g., at step530(a)). In particular, creation of the payment service account can be handled through a mobile application, or through another application, e.g., a generic web browser, capable of communicating with the PSS110. Through the application, the recipient102enters a name, account password, and identification information, e.g., an email address where the user can be contacted, a social security number, a personal pin number, etc. In some embodiments, the recipient102also enters financial account information sufficient to conduct any payment transaction to be saved in database of the PSS110. For example, in the case of a credit card account, the recipient102can enter the credit card issuer, credit card number and expiration date into the PSS110; the card validation value and mailing address may also be required. However, the financial account could also be associated with a debit card or pre-paid card, or another third party financial account such as a bank. In some embodiments, the recipient102can also provide other information, e.g., a list of goods or services available, operating hours, phone number, a small identifying image logo or mark, to the payment service system110. In such embodiments, provision of the other information to the PSS110is beneficial if the recipient102utilizes the payment service account as a merchant account to conduct sales.

At step502, the recipient102launches, or opens, a mobile payment application installed on his mobile device106to initiate the transfer of a payment, or money. The mobile payment application is associated with the PSS110, and can communicate with the PSS110in facilitating the payment transfer (e.g., transmit, receive, and execute instructions of the PSS110). The mobile payment application can be the same application used to create the payment service account as described in the embodiment above.

The mobile payment application allows the recipient102to generate a token for use in the facilitation of the payment transfer. In contrast to the token generated in the embodiment ofFIG. 4, the token generated in the embodiment ofFIG. 5is a simplified token with no additional information embedded (e.g., no embedded transaction information). For example, the simplified token simply contains the image that is indicative of the token.

At step502, the recipient102, through the mobile payment application, submits identification information and transaction information (e.g., by using a touch screen, keyboard, voice recognition, etc.) in a request for the token. The identification information can be any identifier that identifies the recipient102, including, for example, an email address, a telephone number, a driver's license number, a social security number, an employee identification number (ID), a device identifier, an application identifier, an IP address, a personal identification number (PIN), a card verification value (CVV), a security access code, a biometric identifier (e.g., fingerprint, face, iris, retina, etc.), or any other identification means that function as a combination thereof. In the embodiment ofFIG. 5, the recipient102submits his email address (“recipient email address”) as the identifier.

Upon receiving the submission from the recipient102, the mobile payment application generates the token. In some embodiments, the token is in the form of an encrypted message. In some embodiments, the token308is in the form of a Quick Response Code (“QR Code”). In some embodiments, the token308is in the form of a media file, such as an audio file, a video file, an image file.

At step504A, the recipient102provides the token to the sender101. In some embodiments, the recipient102can provide the token through a communication broadcast (e.g., Wi-Fi®, Bluetooth®, Bluetooth® Low Energy, Near Field Communication (NFC), Apple® AirDrop®, etc.). For example, the recipient101enables the AirDrop® feature on his iPhone® (e.g., device106) to transmit an image token to a nearby iPhone® (e.g., device104of the sender101). In another example, the recipient102broadcasts the token in the form of an encrypted message by using Bluetooth® Low Energy to enable nearby mobile devices, such as the device104, to receive the encrypted message.

In some embodiments, the recipient102can provide the token by physically showing it to the sender101. For example, the recipient102prints out a QR code token, which has been generated by the mobile payment application, and displays it in front of his merchandise for any interested buyer, such as the sender101, to scan, e.g., by using a camera of the user device104. In this example, the sender101can scan the QR code when she is ready to make a purchase from the recipient102(i.e., ready to tender him money for the merchandise).

At step504B, the recipient102provides the generated token, along with the submitted transaction information and the identification information, to the PSS110, e.g., by sending a message from the user device106to the PSS110. In some embodiments, the recipient102transmits the message to the PSS110by use of an email mechanism. In such embodiments, the recipient102launches an email application (e.g., a native email application installed on the user device104, a web-based email application, etc.) to compose an email to be sent to an email address associated with the PSS110(“PSS email address”). The recipient102can include the token as an attachment to the email. The recipient102can also include the transaction information and the identification information in the body or subject line of the email.

In some embodiments, the recipient102transmits the message to the PSS110through the mobile payment application installed on the user device106. In such embodiments, the recipient102launches the mobile payment application to submit the token, the identification information, and the transaction information to be included in the message. Upon receiving submission of all desired information from the recipient102, the mobile payment application then transmits the message to the PSS110.

At step504C, the PSS110receives the message sent from the recipient102, where the message includes the token, the identification information, and the transaction information. In particular, the PSS110stores the token in association with the identification information of the recipient102for use in future transactions, e.g., in step510. The PSS110also stores the transaction information. In some embodiments, the transaction information is stored in association with the token. In some embodiments, the transaction information is stored in association with the identification information.

At step506, the sender101, having received the token from the recipient102, transmits a request message, which includes the token, to the payment service system110(“PSS110”) to request that a payment be made (i.e., money to be transferred) to a recipient identified by the token. In some embodiments, the request message also includes a payment amount specified by the sender101. For example, the payment amount is the transaction amount for the purchase of three paintings from the recipient102.

In some embodiments, the sender101transmits the request message to the PSS110through a mobile payment application installed on the mobile device104. The mobile payment application can be a different application or the same application utilized by the recipient102to generate the token in step502. In some embodiments, the mobile payment application displays the general content of the token (e.g., the string of characters “X1234” indicative of the token) along with a transaction prompt to facilitate the sending of a request message to the PSS110. For example, the transaction prompt displays the message, “Would you like to pay the identified merchant?” In such example, upon receiving an approval to proceed from the sender101(e.g., the sender101clicks “Yes” and enters an amount in response to the prompt), the mobile payment application transmits the request message to the PSS110, as indicated in step506.

At step508, upon receiving the request message from the sender101, the PSS110analyzes the included token and compares it to the token received in the message sent from the recipient101(at step504A). In response to identifying a match between the tokens, the PSS110identifies the identification information stored in association with the token to determine an identity of the recipient102. Further, the PSS110identifies the transaction information associated with the token. In some embodiments, the PSS110compares the transaction information included in the message sent at step504A (from the recipient102) with the transaction information included in the message sent at step506(from the sender101) to process the payment transfer. For example, the PSS110determines the amount that should be transferred to be the matching amount between the messages received at steps504A,506. As already discussed in the process ofFIG. 4, the PSS110, in the process ofFIG. 5, similarly determines the identity and associated financial account of the payment recipient (i.e., the recipient102) based on the previously stored association between the token and the identification information of the recipient102.

The PSS110further analyzes other information associated with the request message to determine the identity and financial account of the sender101. The information associated with the request message can include the information submitted by the sender101and/or inherent information that is part of the request message. The inherent information can include, for example, identification information of the request message sender (e.g., the sender101). The identification information can be, for example, the email address from which the “request message” email has been sent, such as the email address of the sender101(“sender email address”). The PSS110identifies the financial account of the sender101based on the identification information.

At step510, upon successful identification of the respective financial accounts, the PSS110executes or triggers execution of the transfer of money from the identified financial account of the sender101to the identified financial account of the recipient102. In some embodiments, the PSS110communicates with the financial system120, which has been identified as the account of the sender101at step510, to cause the payment amount to be transferred to the financial system130. In such embodiments, the financial system120, in response, transfers funds to the financial system130of the recipient102, as indicated in step514.

In some embodiments, the PSS110performs, at step510, an additional action to verify and confirm that the financial account110has sufficient funds to satisfy the payment amount requested to be transferred. In such embodiments, the PSS110communicates with the financial system120the payment amount and waits for a verification message from the financial system120that the amount has been credited from the account of the sender101to the account of the recipient102(i.e., facilitated by the financial system130.

In response to the verification message, the PSS110transmits a message to the user device106of the recipient102indicating that money has been transferred, as indicated by step520A. In some embodiments, the PSS110can also send the message to the user device104of the sender102indicating that money has been transferred, as indicated by step520B. The recipient102, can then, for example, render goods or services to the sender101. In some embodiments, the recipient102can transmit a message to the PSS110indicating that the goods or services has been completed, as indicated by step522. The payment transfer process can end at step522.

In some embodiments, the PSS110generates and transfers a receipt (e.g. a confirmation receipt) to both the recipient102and the sender101, as indicated by steps540and542. In some embodiments, the generation and transfer of the receipt can be triggered by the message received from the recipient102to indicate that the transaction (e.g., rendering of goods by the recipient102to the sender101) has been completed. In some embodiments, the generation and transfer of the receipt can be triggered by a successful transfer of the payment amount from a financial account of the sender101to the recipient102.

In some embodiments, the PSS110, in generating the receipt, also generates a second token (not shown) associated with the sender101(i.e., a “sender anonymizing token”). In such embodiments, the PSS110associates the second token with the identification information of the sender101, and stores such association in a database of the PSS110. In some embodiments, the PSS110can also generate a second token that is associated with all information relevant to the transfer of money, and stores such association in a database of the PSS110(“transaction anonymizing token”). The information can include the identification information associated with the sender101and the transaction information associated with the transaction between the sender101and the recipient102(e.g., a transaction identifier (ID) that identifies the transaction between the sender101and the recipient102, a transaction date, a list of transaction items, the transaction amount, and/or the like).

In some embodiments, the transaction information can be embedded in the second token, as opposed to being stored in association with the second token, to enable any individual in possession of the token to view details about the transaction. In such embodiments, no identification information is embedded in the token. For example, the identification information of the seller101is only associated with the second token and stored by the PSS110.

Among other benefits, use of the second token serves to protect the personal identification information of the sender101from being known by the recipient102, as only the PSS110has knowledge of the association between the second token and the identification information. The second token can be included in the receipt and transmitted to each of the recipient102and the sender101. For example, if either the sender101or the recipient102decides to return goods associated with the transaction, the sender101or the recipient102can provide the receipt with the second token to enable a payment transfer for the refund (“refund payment transfer”) to the sender101.

In some embodiments, the sender101, as opposed to the recipient102, can utilize a mobile payment application installed on the user device104to generate a simplified token in the form of a one-time use token for use with the recipient102. In some embodiments, the mobile payment application is associated with the PSS110(e.g., works in coordination with the PSS110). In some embodiments, the mobile payment application receives instructions from the PSS110for executing various processes. In some embodiments, the mobile payment application is a different application as the one used to generate the token for the recipient102. In some embodiments, the mobile payment application is a different application as the one used to generate the token for the recipient102.

As used here, the term “one-time use token” refers to a simplified token that operates as a “cash” payment card that carries a limited amount of cash, or funds, available for use. In some embodiments, the one-time use token can be configured to operate only within a specified time period. In such embodiments, the limited amount of funds would be ineffective upon expiration of the specified time period. For example, the one-time use token carries an amount of $50 that must be used within 30 min. of creation, or generation, of the token (e.g., by the mobile payment application).

In accordance with the embodiments, the sender101can provide the one-time use token to the recipient102as a payment mechanism, e.g., in exchange for goods. For example, the one-time use token is a QR code. In this example, the recipient102can scan the QR code provided by the sender101to “charge” the sender101for a transaction amount, and the transaction amount is deducted from the amount carried by the one-time use token. With such implementation, the recipient102would never learn of the real identity (and/or personal identification information) of the sender101, while still being able to receive payment from the sender101for the transaction.

In accordance with the embodiments, the sender101first submits identification information to the mobile payment application to generate the one-time use token. In some embodiments, the sender101can also submit financial account information associated with a financial account of the sender101(e.g., credit card information associated with a credit card, debit card information associated with a debit card, etc.), and a token amount for the one-time use token. In such embodiments, the mobile payment application communicates the identification information, the financial account information, and the token amount to the PSS110, which creates a “one-time use token” account for the sender101. The one-time use token can then be provided to the recipient102to utilize as payment. Upon a reading of the one-time use token by an application installed on a device of, or associated with, the recipient102, the application sends an indication to the PSS110that a “charge” amount has been initiated on the one-time use token. The PSS110identifies the one-time use token account and deducts the charge amount from the financial account of the sender101.

In various embodiments, the token information receiver612, the token generator614, the request analyzer622, the financial account manager624, and the payment executor626can handle the steps for implementing the one-time use token process. For example, the token information receiver612and the token generator614can work in coordination to generate the one-time use token for the sender101. Further, in this example, the request analyzer622, the financial account manager624, and the payment executor626can receive the one-time use token from the recipient102to analyze content of the token, identify the financial account of the sender101, and execute or cause the execution of a payment transfer from the financial account of the sender101to a financial account of the recipient102.

FIG. 6is block diagram illustrating various components of an intermediary payment service system600(“PSS600”) in accordance with some embodiments of the disclosed technology. In one embodiment, the PSS600can be the PSS110ofFIG. 1. The PSS600includes an anonymous payment transaction system602and databases604,606,608. The payment transaction system602includes a token request engine610and a payment transfer request engine620. In implementing the disclosed technology, the token request engine610can include, for example, a token information receiver612and a token generator614. Additionally, in implementing the disclosed technology, the payment transfer request engine620can include, for example, a request analyzer622, a financial account manager624, and a payment executor626.

The databases604,606,608can be used for storing information for executing applications that facilitate money transfer transactions (e.g., mobile payment applications240,242,350,352). For example, the user account database604(“DB604”) can store user account information of one or more users of a payment service executed by the PSS600. The account information can include, for example, a user identifier (e.g., name, email address, phone number, device identifier, mobile application identifier, username), account password, user preferences, billing address, shipping address, and/or the like. An example database table maintained by the DB604is shown as the database702ofFIG. 7.

The financial account database606(“DB606”), for example, can store information related to the financial accounts associated with payment cards of the one or more users of the payment service. The financial account information, or payment card information, can include, for example, a user identifier (e.g., name, email address, phone number, device identifier, mobile application identifier, username), payment card/account number (e.g., primary account number or PAN), expiration date, card/account type, CVV code, billing address, and/or the like. An example database table maintained by the DB606is shown as the database704ofFIG. 7.

The transaction history database608(“DB608”), for example, can store information related to financial transactions, such as a transfer of money between users of the payment service operated by the PSS600. The information related to the financial transactions can include, for example, a transaction ID, a merchant ID or an identifier of a payee (“payee ID”), a customer ID or an identifier of a payer (“payer ID”), a transaction amount (e.g., total price, individual prices, tax, etc.), a transaction date, a transaction description (e.g., product or service item names or codes), and/or the like.

Each of the databases604,606,608discussed above can include, for example, one or more hard drives, a centralized or distributed data cluster, a cloud-storage service provider, or other suitable storage systems suitable for storing digital data. Additionally, various other databases other than those discussed above can also be accessed by the PSS600.

The token request engine610can process requests from one or more users for tokens, for example, as described inFIGS. 2-5. The token information receiver612, of the engine610, can detect or receive one or more selections or inputs from a user through a user device (e.g., device106,FIG. 1) (e.g., via an input device coupled to the device106, such as a mouse, a keyboard, a touchscreen, an actuatable button, a gesture capturing device, a microphone, or the like). Through the selections or inputs, the user can specify or provide the type of token the user would like to be generated (e.g., simplified token, enriched token, QR token, string-of-character token, encrypted message token, an image token), the number of tokens desired, the information that the user wants to be embedded in the token (e.g., transaction information, personalized/customized message, etc.), and the identification information of the user to be associated with the generated token. For example, the user can select one of several existing sets of identification information, or alternatively input an email address, to be used as the identification information for association with the token. In another example, the user can input details about a transaction in which she wishes to receive money (i.e., transaction information). In yet another example, the user can select one of several existing accounts, or input payment card/account information identifying a particular account, that the user wishes to receive money for the payment transfer.

The token request engine610is coupled to the token generator614in communicating the information specified in the token request from the user. The token generator614generates the token based on the token request (e.g., request for a simplified token or an enriched token, request for a particular type of token, request for a particular number of tokens, etc.) and transmits that token back to the user device in response to the token request. For example, the token generator614generates four QR codes indicative of four enriched tokens, and transmits those QR codes to the user, e.g., via email, text message, or a mobile payment application. The token request engine610also works in coordination with the databases604,606, and608to store the generated tokens in association with the identification information provided by the user. In some embodiments, the token request engine610also stores the transaction information (and any other information) provided by the user in association with the token and/or the identification information.

The payment transfer request engine620can process requests from one or more users (i.e., senders of money) to transfer money using a token, for example, as described inFIGS. 2-5. The token can be generated, for example, by the token generator614as discussed above. The request analyzer622, of the payment transfer request engine620, can receive a request from a sender for the money transfer through a user device (e.g., user device104,FIG. 1). The request analyzer622can then parse the money transfer request to extract details, such as the content of the token (e.g., a string of numbers “1234898” representative of the token), including any embedded information of the token (e.g., transaction information).

The request analyzer622can communicate with the financial account manager624to determine whether a recipient identifier is associated with one or more payment cards/financial accounts. For example, the financial account manager624can utilize the recipient identifier extracted by the request analyzer622to compare it with a recipient identifier stored in the user account DB604, and access the financial account DB606to identify a financial account that is stored in association with that identifier. In some embodiments, where no financial account is identified, the financial account manager624notifies the request analyzer622, which communicates with another user device (e.g., device106) to request financial account information from the recipient. This may be done, for example, by sending an email to the recipient using the recipient identifier. In another example, this may be done by sending a push notification to the recipient using the recipient identifier. Upon receiving the financial account information for a financial account/payment card from the recipient, the request analyzer622communicates that information to the financial account manager624for storage in the DB606.

In some embodiments, the request analyzer622further communicates with the financial account manager624to determine whether the sender's identifier (i.e., payer identifier) is associated with one or more payment cards/financial accounts. Similarly, where no financial account is identified, the financial account manager624notifies the request analyzer622of the missing account information. In response, the request analyzer622communicates with the sender's user device (e.g., device104) to request financial account information from the sender. This can be done, for example, by sending an email to the sender using the sender's identifier. In another example, this can be done by sending back a push notification to the user device. Upon receiving the financial account information for a financial account/payment card from the sender, the request analyzer622communicates that information to the financial account manager624for storage in the DB606.

The payment executor626is in communication with the request analyzer622and the financial account manager624to execute or trigger execution of the transfer of an amount associated with the money transfer request, as described inFIGS. 2-5. In particular, the payment executor626, upon receiving confirmation of identified financial accounts for the recipient and the sender, causes the money to be transferred from a financial account associated with the sender (e.g., a bank account funding the sender's payment card) to another financial account associated with the recipient (e.g., a bank account associated with the recipient's payment card).

FIG. 8is a high-level block diagram illustrating an example of a computer system that can represent any of the devices described above, such as the user devices104,106, the PSS110, and the financial systems120,130. In alternative embodiments, the computer system operates as a standalone device or can be connected (e.g., networked) to other computer systems. In a networked deployment, the computer system can operate in the capacity of a server or a client computer in a client-server network environment, or as a peer computer in a peer-to-peer (or distributed) network environment.

The computer system can be a server computer, a client computer, a personal computer (PC), a mobile electronic user device, a tablet PC, a laptop computer, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone or a smart phone (e.g., an iPhone or an Android phone), a web-enabled household appliance, a network router, switch or bridge, a (hand-held) gaming device, a music player, or any computer capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that computer.

In the illustrated embodiment, the computer system800includes one or more processors802, one or more memories804, a network interface device808, and one or more input/output devices (I/O) devices810, all coupled to each other through an interconnect806. The interconnect806can be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices.

The processor(s)802can be or include, for example, one or more general purpose programmable microprocessors, microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices. The processor(s)802control the overall operation of the processing device800.

The one or more memor(ies)804can be or include one or more physical storage devices, which can be in the form of random access memory (RAM), read-only memory (ROM) (which can be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices. The one or more memor(ies)804can store data and instructions that configure the processor(s)801to execute operations in accordance with the techniques described above.

While the computer-readable medium or computer-readable storage medium is shown in an exemplary embodiment to be a single medium, the term “computer-readable medium” and “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” and “computer-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the computer and that cause the computer to perform any one or more of the methodologies of the presently disclosed technique and innovation.

Further examples of computer-readable storage media, computer-readable media, or computer-readable (storage) media include, but are not limited to, recordable type media such as volatile and non-volatile memory devices, floppy and other removable disks, hard disk drives, optical disks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks, (DVDs), etc.), among others, and transmission type media such as digital and analog communication links.

The network interface device808enables the computer to mediate data in a network with an entity that is external to the host server, through any known and/or convenient communications protocol supported by the host and the external entity. The network interface device can include one or more of a network adaptor card, a wireless network interface card, a router, an access point, a wireless router, a switch, a multilayer switch, a protocol converter, a gateway, a bridge, bridge router, a hub, a digital media receiver, and/or a repeater.

The network interface device808can include a firewall which can, in some embodiments, govern and/or manage permission to access/proxy data in a computer network, and track varying levels of trust between different computers and/or applications. The firewall can be any number of modules having any combination of hardware and/or software components able to enforce a predetermined set of access rights between a particular set of computers and applications, computers and machines, and/or applications and applications, for example, to regulate the flow of traffic and resource sharing between these varying entities. The firewall can additionally manage and/or have access to an access control list which details permissions including for example, the access and operation rights of an object by an individual, a computer, and/or an application, and the circumstances under which the permission rights stand.

Other network security functions can be performed or included in the functions of the firewall, can be, for example, but are not limited to, intrusion-prevention, intrusion detection, next-generation firewall, personal firewall, etc. without deviating from the novel art of this disclosure.

While some aspects of the disclosure are presented below in certain claim forms, the inventors contemplate the various aspects of the disclosure in any number of claim forms. For example, while only one aspect of the disclosure is recited as a means-plus-function claim under 35 U.S.C. § 112, ¶6, other aspects can likewise be embodied as a means-plus-function claim, or in other forms, such as being embodied in a computer-readable medium. Accordingly, the applicant reserves the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the disclosure.