Merchant account transaction processing systems and methods

Information

  • Patent Grant
  • 11797969
  • Patent Number
    11,797,969
  • Date Filed
    Tuesday, February 25, 2020
    5 years ago
  • Date Issued
    Tuesday, October 24, 2023
    a year ago
Abstract
A computer-implemented system and method that includes receiving, by a messaging hub, a code and a transaction amount from a recipient and determining, by the messaging hub, based at least partially on the code, an account number for a credit card held by a user. The system and method may include receiving, by the messaging hub, funds equaling the transaction amount from the credit card and depositing the funds in an account held by the messaging hub, the funds being received via a four-party credit card transaction in which the messaging hub operates as a merchant and sending the funds from the account held by the messaging hub to an account held by the recipient.
Description
FIELD

The present disclosure relates generally to the field of systems that use mobile devices to initiate fund transfer requests. More specifically, the present disclosure relates to systems and methods for enabling individuals to use their electronic devices to transfer funds and purchase products and services.


BACKGROUND

Payments for products and services are often completed using credit cards, debit cards, checks or cash. At the same time, most people carry some type of mobile handheld electronic device, such as a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, and so on. Most of these devices tend to have a wireless Internet connection. A person may wish to make payments to merchants or other individuals using these mobile devices. Likewise, a person may wish to transfer funds to other individuals using their mobile devices. Enhanced systems and methods of facilitating such transactions would be desirable.


SUMMARY

One embodiment includes a computer-implemented method that includes receiving, by a messaging hub, a code and a transaction amount from a recipient and determining, by the messaging hub, based at least partially on the code, an account number for a credit card held by a user. The method may include receiving, by the messaging hub, funds equaling the transaction amount from the credit card and depositing the funds in an account held by the messaging hub, the funds being received via a four-party credit card transaction in which the messaging hub operates as a merchant and sending the funds from the account held by the messaging hub to an account held by the recipient.


One embodiment includes a computer system that includes a processor coupled to machine non-transitory readable storage media having instructions stored therein that, when executed by the processor, cause the processor to receive, by a messaging hub, a code and a transaction amount from a recipient. The processor configured to determine, by the messaging hub, based at least partially on the code, an account number for a credit card held by a user. The processor configured to receive, by the messaging hub, funds equaling the transaction amount from the credit card and depositing the funds in an account held by the messaging hub, the funds being received via a four-party credit card transaction in which the messaging hub operates as a merchant. The processor configured to send the funds from the account held by the messaging hub to an account held by the recipient.


A computer-implemented method for performing a transaction, the method includes receiving, by a bank system, receiving, by a bank system, a request to perform the transaction between a user of a mobile wallet application and a recipient, receiving a generated code and a transaction amount from a recipient, receiving funds equaling the transaction amount from the credit card and depositing the funds in an account held by the messaging hub, and the funds being received via a four-party credit card transaction in which the messaging hub operates as a merchant. The method includes sending the funds from the account held by the messaging hub to an account held by the recipient.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 is a schematic diagram of a computer-implemented payment processing system according to an example embodiment.



FIG. 2a is a process implemented by the payment processing system of FIG. 1.



FIG. 2b is a process implemented by the payment processing system of FIG. 1.



FIG. 3a is a process implemented by the payment processing system of FIG. 1.



FIG. 3b is a process implemented by the payment processing system of FIG. 1.



FIG. 4 is a process implemented by the payment processing system of FIG. 1.



FIG. 5 is a process implemented by the payment processing system of FIG. 1.



FIG. 6 is a process implemented by the payment processing system of FIG. 1.



FIG. 7 is a process implemented by the payment processing system of FIG. 1.





DETAILED DESCRIPTION

Referring to FIG. 1, a computer-implemented payment processing system 100 is shown that may be used to set up and utilize a mobile wallet account. The user may be a business entity and/or an individual consumer that has one or more source accounts with a financial institution. The source accounts may include business or consumer demand deposit accounts. The source accounts may also includes credit accounts such as credit cards, lines of credit, and so on. The mobile wallet account can be created for the user to transmit funds from a source account in return for purchase of goods or services to a merchant. Additionally, funds can be transferred from the source account to another person.



FIG. 1 is a schematic diagram of a computer-implemented payment processing system according to an example embodiment. In the example of FIG. 1, an interoperable mobile wallet platform is provided that may be accessed by consumers that bank at various different banking institutions and by merchants that bank at various different banking institutions. Hence, the mobile wallet client application 6 (or various branded variations thereof) may be offered through multiple banks and may utilize the services of multiple banks to complete transactions. Such an arrangement may promote broader adoption of the mobile banking platform by merchants and consumers.


Specifically, as shown in FIG. 1, a payment processing system 100 may include various computer systems such as a mobile device 1, mobile wallet bank computer system 10, messaging hub computer system 20, recipient bank computer system 30, merchant computer system 40, messaging hub bank computer system 50, and issuing bank computer system 60. As will be appreciated, in practice, the computer system of a given banking institution may operate as the mobile wallet bank computer system in the context of some transactions and may operate as the recipient bank computer system in the context of other transactions.


In FIG. 1, the computer systems 1, 10, 30, 40, 50 and 60 may communicate with each other to complete transactions. As shown in FIG. 1, the connection of mobile device 1 is such that it does not communicate directly with the messaging hub computer system 20 or the recipient bank computer system 30. In other implementations, the mobile device 1 may be configured to communicate some information to the messaging hub computer system 20 and/or the recipient bank computer system 30. Interconnections of the computer systems 1, 20, 30, 40, 50 and 60 will now be briefly described.


The mobile device 1 may be used by an individual user (e.g., a business owner or employee, a consumer, and so on) to create and interact with a mobile wallet account. The mobile device 1 may, for example be, handheld computer, a cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, or other suitable device. The mobile device 1 comprises a network interface logic 2, a display device 4, an input device 5, and a mobile wallet client application 6. Network interface logic 2 may include, for example, program logic that connects the mobile device 1 to a network. As described in greater detail below, for example, the mobile device 1 may receive and display screens including account information, transaction instructions, and so on. In an example embodiment, such screens may be used to request username and password information. Such screens may also be used to prompt the user to provide information regarding the amount of the payment and which merchant or individual (e.g., name, address, phone number or e-mail, a selection of a recipient by the user from his memory or from by the user from the mobile device 1, and so on) is to receive the payment. Such screens are presented to the user via the display device 4. The input device 5 may be used to permit the user to initiate account access and to facilitate receiving requested information from the user. As will be appreciated, in addition to or instead of the mobile device 1, users may also be provided with the ability to access the payment processing system 100 using another type of computer (e.g., a desktop or laptop computer executing browser software) to perform the operations described herein as being performed by the mobile device 1.


The mobile wallet client application 6 may comprise program logic executable by the mobile device to implement at least some or all of the functions described herein. As will be appreciated, the level of functionality that resides on the mobile device 1 as opposed to the banking computer system 30 may vary depending on the implementation. The client application 6 may be a web browser that is configured to receive and display mobile web pages (e.g., web pages prompting the user to provide information to create an account, web pages displaying account balance information and past transactions, and so on). The mobile wallet client application 6 may also include a code/token generator capable of generating a unique code/token for each transaction. As described below, the unique code/token may then be transmitted by the mobile device 1 as part of a transaction to facilitate authentication of the transaction. As will be appreciated, the user may also use other devices (e.g., laptop or desktop computer system, not shown) to create and access account.


In FIG. 1, the mobile wallet application 6 is used in connection with merchant computer system 40 located at a bricks and mortar store location. As previously indicated, however, the mobile wallet application 6 may also be used in connection with online merchant transactions. For example, in another embodiment, merchants may be provided with the ability to have a mobile storefront and profile within the mobile wallet application 6. For example, merchants may be provided with the ability to display marketing material, provide information, and promote products or discounts. Merchants may also be provided with the ability to sell items directly through their mobile storefront for the account holder to purchase from within the mobile application 6.


The mobile device 1 may include, in addition to the other features previously described, a code processing system 7. The code processing system 7 may include a code scanner (i.e. camera), and/or a code generator. In one embodiment, the code processing system 7 may receive a numerical code from the mobile wallet bank computer system 10 and generate an image that represents the received code on the display device 15. In one implementation, the code processing system 7 may receive a code from the mobile wallet bank computer system 10. In another embodiment, the code processing system 7 may use a code/token generator as described in FIG. 1. The code generator 8 of the mobile device 1 may generate or receive a unique code for a transaction at a point of sale location. The unique code may identify the transaction number for the mobile wallet bank computer system 10. In some embodiments, the code may be a dynamic token that remains valid for a single transaction, and/or a temporary period of time. The code is a POS exchange code that is exchanged between a POS (Point of Sale) device 40 of the merchant and a mobile device 1 of the user in exchange for goods or services that are received by the user.


The bank computer system 10 includes code/QR generator 11, transaction verification logic 13, code determination logic 15, account database 17, and profile database 19. The code generator 11 may receive a request from an account holder to initiate a transaction. A transaction may be initiated by generating a QR code that can be scanned by a merchant or individual. The account holder may access the code generator 11 via a mobile wallet application that is being executed on the mobile device 1. In various embodiments, the QR code may be generated without the account holder providing the merchant's name or amount of transaction. The code generator 11 can be configured to generate a QR code that incorporates at least one of a date, time, unique transaction identifier, and geographic location of the mobile device. In other embodiments, the code generators 11 and 18 can be configured to generate optically scanned or non-optically scanned codes. Examples of optically scanned codes include bar codes, two dimensional codes (e.g., QR code and other similar codes), three dimensional codes (e.g., QR code with color and others characteristics), and four dimensional codes (e.g., QR code with color and timestamp information). Examples of non-optically scanned codes may include, near field communication (NFC), RFID, HID or other RF signal to transmit the code.


The transaction verification logic 13 may receive a transaction amount from the messaging hub computer system 20. The transaction verification logic 13 may generate a message to send to the mobile device 1 for verifying the transaction amount. Upon receiving the verification message, the account holder via mobile device 1 may approve the transaction amount to the bank computer system 10.


The account database 17 may store details regarding financial institution accounts. In particular, the account database 17 may store each financial transaction that occurred. Each financial transaction may include the amount of the transaction and the merchant. In some embodiments, the messaging hub computer system 20 stores account information for the user, so the account information is not received from the mobile wallet bank computer system 10.


The profile database 19 may store other information regarding the account holder. For example, the profile database 19 may store information useful for generating offers and advertisements that are selected specifically for the account holder. In some embodiments, the messaging hub computer system 20 may also be operative to process the transaction between the two parties.


As shown in FIG. 1, the mobile wallet bank computer system 10 is configured to communicate with the mobile device 1 and the messaging hub computer system 20. The content of the communication with the messaging hub computer system 20 may include account information regarding the user, confirmation of the code and approval/declining a transaction between the user of the mobile device 1 and a merchant. In some embodiments, the messaging hub computer system 20 stores account information for the user, so the account information is not received from the mobile wallet bank computer system 10.


As shown in FIG. 1, the messaging hub computer system 20 is configured to communicate with one or more financial institutions that provide financial accounts to various individuals or merchants. The messaging hub computer system 20 may include various components such as validator 21 discussed in greater detail below. The messaging hub computer system 20 is configured to act as an intermediary between two financial institutions such as mobile wallet bank computer system 10 and recipient bank computer system 30. The messaging hub computer system 20 may act as a message router that is configured to assure that the correct information is transmitted to the correct financial institution to facilitate a transaction between two parties (e.g., a user and a merchant or a user and another user or between two merchants). Additionally, the messaging hub computer system 20 provides a single interface for each bank to communicate with a plurality of other banks. In some embodiments, the messaging hub computer system 20 may also be operative to process the transaction between the two parties.


The messaging hub computer system 20 may be a third party provided interface for one or more financial institutions. In one embodiment, the messaging hub computer system 20 may be provided by an exchange service that allows banks to transmit information securely between banks to process transactions where funds are transferred from one bank to another bank. In the example shown in FIG. 1, funds may be transferred from an account held by the user of the mobile device 1 to an account held by a merchant with a merchant computer system 30. The messaging hub computer system 20 includes a processor and a non-transitory memory that are configured to receive and transmit information between one or more financial institutions. The information received from a sending financial institution may identify the recipient financial institution. The interface between the messaging hub computer system 20 and the financial institutions uses bank level security encryption to send and receive messages.


The validator 21, in the messaging hub computer system 20, performs an initial validation of the code that is received from the recipient bank computer system 30. In another embodiment, a portion of the received code may identify the financial institution that should receive the messages from the messaging hub computer system 20. The validator 21 may access stored information that correlates codes with electronic contact information for financial institutions. In another implementation, a database may be used to determine the correlation between a portion of the code and a financial institution with which the code corresponds.


The validator 21 includes a comparator configured to compare the time provided by the merchant computer system 40 with the time provided via the QR code generated by the mobile device 1. If the time provided by the QR code and the merchant computer system 40 exceeds a predetermined time limit (e.g., five minutes), the messaging hub computer system 20 will deny the transaction.


The recipient bank computer system 30 includes network interface logic 32, account processing logic 34, and accounts database 36. When the mobile wallet account is created, the user is prompted to provide bank account information (e.g., routing number and/or account number) for the source account that is used as a source of funds for the mobile wallet account. Thus, the financial institution that provides the mobile wallet account for the user and the financial institution that typically provides banking services to the user may be two different financial institutions.


In another embodiment, the code generator 31 may receive a request for a code to provide to a merchant, the code being generated to be displayed on a merchant point of sale machine or an ecommerce website. The merchant may display the code for the account holder to scan using a mobile device. Generating the code including embedding in the code a transaction identification number, a geographic location of the merchant, and a timestamp. The financial institution may send the code to the merchant for the mobile device to scan. The mobile device 1 may scan the code from a merchant display device. The mobile device 1 may amend the code to add further authentication information to the code and send the code to the financial institution. The financial institution may receive the amended code from the mobile device to transfer funds from an account held by the account holder to the merchant. In one embodiment, the requested funds are transferred to the merchant upon verifying the geographic location of the mobile device to be within a predetermined distance of the location of the merchant. In another embodiment, the amended code is amended to include authentication information (e.g., geographic location, account number, pass code, pin code) from the mobile device for the financial institution.


The merchant computer system 40 may be configured in generally the same manner as the other computer systems described herein. For example, if the fund recipient is an individual, the computer system 40 may be another mobile device, such as a handheld computer, cellular phone, smart phone, mobile handheld wireless e-mail device, personal digital assistant, portable gaming devices, or other suitable device. If the fund recipient is a merchant (e.g., a brick and mortar merchant, a retail website or other online merchant, etc.), the computer system 40 may comprise a point of sale (POS) device or other computer system (e.g., one or more servers each with one or more processors) configured to execute instructions, send and receive data stored in memory, and perform other operations to implement the operations described herein associated with the fund recipient.


The merchant computer system 40 may be used at a point of sale to conduct transaction with the account holder. For example, the merchant computer system 40 may comprise a point of sale computer system such as a cash register system connected to a central server system operated by the merchant. As another example, the merchant computer system 40 may comprise a mobile computing device (e.g., smart phone, tablet PC, etc.) operated by a store clerk as the clerk moves throughout the store. Again, the mobile computing device in such an embodiment may connect to a central server system operated by the merchant.


The merchant computer system 40 includes code scanner 44, fund requesting logic 48, and fund receiving logic 49. The code scanner 44 may be configured to scan codes, such as but not limited to, optically scanned or non-optically scanned codes. Examples of optically scanned codes include bar codes, two dimensional codes (e.g., QR code and other similar codes), three dimensional codes (e.g., QR code with color and others characteristics), and four dimensional codes (e.g., QR code with color and timestamp information). Examples of non-optical codes include, near field communication (NFC), RFID, HID or other RF signal to transmit the code. Code scanner 44 may include a light emitting device that scans a code using infrared, laser, or other types of communication technology. In one embodiment, the code scanner 44 scans a QR code. After scanning the QR code the QR code scanner 44 determines the information that was incorporated into the QR code by the mobile device 1 that generated the code.


The fund requesting logic 48 communicates a fund request to the recipient bank computer system 130. In one embodiment, the fund requesting logic 48 also sends the amount of transaction to the financial transaction.


The merchant computer system 40 may further connect to or integrate with other hardware. For example, in one embodiment, the merchant computer system 40 may connect to a card reader for reading credit cards, debit cards, stored value cards, and so on. As another example, the merchant computer system 40 may be configured to prompt the user to provide a random security code. The random security code may be generated by the mobile device 1, by a separate security dongle, or in another manner. The security code may be provided to the merchant computer system 40 directly by the mobile device, may be keyed into the merchant computer system (e.g., by a store clerk), or may be received in another manner.


After scanning the QR code, the merchant may transmit the QR code to the recipient bank computer system 30, as previously described. The recipient bank computer system 30 may then return account information (e.g., a credit card number, debit card number, alternative payment type, demand deposit account, etc.) to backend servers associated with the merchant computer system 40 to permit the transaction to be processed in the same manner as a conventional credit card or debit card transaction. Other mechanisms for processing payments may also be used.


As shown in FIG. 1, the recipient bank computer system 30 is configured to communicate with the merchant computer system 40 and the messaging hub computer system 20. The recipient bank computer system 30 is configured to receive funds to the financial institution of the user (e.g., mobile wallet bank computer system 10). In other implementations, the recipient bank computer system 30 may be configured to communicate with the mobile device 1 and/or the mobile wallet bank computer system 10.


As shown in FIG. 1, the merchant computer system 40 is configured to communicate with the recipient bank computer system 30 and the mobile device 1. The merchant computer system 40 is configured to receive a code (e.g., QR code) and other information from the recipient bank computer system 30. In other implementations, the merchant computer system 40 may be configured to communicate with the mobile device 1 and/or the mobile wallet bank computer system 10. The interface between the merchant computer system 40 and the recipient bank computer system 30 uses bank level security encryption to send and receive messages.


As shown in FIG. 1, the messaging hub bank computer system 50 is operative to transfer funds from the issuing bank computer system 60 to the recipient bank computer system 30 under the direction of the messaging hub computer system 20. The messaging hub bank computer system 50 acts as a master merchant acquirer bank and then transfer the fund to a recipient bank computer system 30. In some embodiments, the messaging hub bank computer system 50 may aggregate the funds before sending them to the recipient bank computer system 30. The issuing bank computer system 50 may be configured to communicate via a network with the messaging hub computer system 20 and the messaging hub bank computer system 50. The messaging hub bank computer system 50 may transfer funds to the recipient bank computer system 30. The messaging hub bank computer system 50 is configured to receive funds from various issuing bank computer system 60 and transmit the funds to the appropriate recipient bank computer systems 30.


In other embodiments, the issuing bank computer system 50 is configured to be a registry information provider. The registry information may include an identifier for the user mobile wallet account and the registry information such as the user default account number may be provided to the messaging hub computer system 20. In other embodiments, the registry information may include other information that allows the messaging hub computer system 20 to obtain the account information from another financial institution. The messaging hub bank computer system 60 includes an account processing logic 62 that determines which user has a credit card account and an account database that store information regarding user accounts.


As will appreciated, during operation of the system shown in FIG. 1, various parameters may be passed between the computer systems 1, 20, 30, 40, 50 and 60. An exemplary listing of such parameters is set forth below in Table 1. These parameters may be alphanumeric values.










TABLE 1





Term
Definition







Payment Identifier (PI)
A static value that is tied to an underlying



payment type or consumer registry info


Issuer Identifier (II)
A unique number that identifies the issuer to



ensure appropriate routing of Dynamic Token



requests


Wallet Platform ID
A unique ID per Wallet/Version combo


(WPI)



Wallet User ID (WUI)
A unique ID per user of each wallet


Dynamic Token (DT)
A tokenized value that is sent to the issuer or



acquirer for validation and retrieval of key



information to drive a purchase transaction


Previously Used
A previously used tokenized value that is used


Dynamic Token
to drive a refund transaction


(PUDT)



Trace ID (TID)
A subset of the Dynamic Token that is used by



the issuer for security and matching purposes


Merchant ID (MID)
A unique ID for each merchant that is tied to a



Merchant Registry Info


Acquirer ID (AID)
A unique ID for each acquirer/processor


POS ID (PID)
A unique ID for each point of sale terminal


Merchant Registry
A Merchant specific data element that allows


Info (MRI)
MH to look up the DDA or other profile info


Consumer Registry
A Consumer ID that allows MH to look up the


Info (CRI)
DDA or other profile info










FIG. 2a depicts a first process for completing a transaction that may be implemented by the payment processing system of FIG. 2a. For purposes of providing an example, it is assumed that the two parties to the transaction in FIG. 2a are a user of mobile wallet application 6 (e.g., consumer) and a merchant. Again, as above, it will be appreciated that other types of transactions may be possible.


At step 201, the user may provide input to the POS (Point of Sale) device 40. For example, a user purchasing merchandise at a bricks and mortar merchant may be at a checkout counter or other type of POS arrangement. The user may be presented with a series of payment options at the pos devicePOS device 40 (e.g., credit card, debit card, mobile, and so on). The user may select a payment type (here, “mobile”) to pay for goods or services, and the POS device 40 may receive the selection of the payment option.


Next, at step 202, the user may access the mobile wallet application 6 on mobile device 1 and select a “pay now” or similar option on the mobile device. As previously discussed, the mobile wallet application 6 may also offer the user various payment types (e.g., various credit cards, debit cards, alternative payment type, demand deposit account and so on). In one embodiment, the user may have pre-specified a default payment type that may be used. The mobile device 1 may receive the user input and initiate communication with the mobile wallet bank computer system 10.


At step 203, the mobile device 1 may send a request to the mobile wallet bank computer system 10 for a code that may be used to identify the transaction that will occur between the user and the POS device 40. The request to the mobile wallet bank computer system 10 includes the wallet platform ID (WPI) that identifies a unique identification number for the wallet and/or the version of the wallet application that is being used. The message that is transmitted may include information identifying the user (e.g., a device identifier for the mobile device 1, a unique identifier (e.g., wallet user ID (WUI)) associated with the mobile wallet application 6 when installed by the user, etc.). Information regarding the payment type selected by the user may also be sent. The mobile wallet bank computer system 10 may be configured to receive requests directly from the mobile device 1 for codes or other information.


At step 204, the mobile wallet bank computer system 10 may generate a random code or sequential code as described above, e.g., in connection with FIG. 1. In one embodiment, the code may represent a unique identifier (e.g., dynamic token (DT)) for the transaction that is about to be completed between the user and the merchant. In other embodiments, the code may also include a transaction identifier and verification codes that identify the mobile wallet bank computer system 10 to the messaging hub computer system 20 when the code is received by the messaging hub computer system 20. In other embodiments, the code may include a trace ID (TID) which is part of the dynamic token and is used by the issuing bank for security and matching purposes. In some embodiments, the mobile wallet bank computer system 10 may generate a code based on a standard that the messaging hub computer system 20 can decode and understand.


After receiving the code from the mobile wallet bank computer system 10, the mobile device 1 may process the code using the code processing system 7. In one embodiment, the code may be sent over a wireless link between the mobile device 1 and the mobile wallet bank computer system 10. In one embodiment, to reduce bandwidth requirements and transmission times, the code may be sent as a numeric code. In such an embodiment, the code processing system 7 may be configured to convert the code into a displayable image that may be scanned by the POS device 40. In other embodiments, the code may be sent as an image (e.g., QR code or bar code). At step 205, the mobile device 1 may generate a display and the POS device 40 may optically scan the displayed code.


At step 206, after scanning the code from the mobile device 1, the code and a merchant identification number (e.g., Merchant ID (MID)) that represents a unique identifier for the merchant that is tied the merchant registry information in the messaging hub computer system 20) from the POS device 40 is transmitted to the recipient bank computer system 30. At step 207, after receiving the code, the recipient bank computer system 30 may be configured to transmit the code and the merchant identification number to the messaging hub computer system 20. Upon receiving the code, the messaging hub computer system 20 may perform an initial validation of the code and then decode it to determine the banking institution (e.g., issuer identifier (II) or wallet platform ID (WPI)) with which it is associated (i.e., to determine which banking institution generated the code). In some embodiments, the code or a portion of the code (e.g., TID) may be matched with a number that identifies the banking institution (e.g., the last three or four digits may be used to access a lookup table).


Next, at step 208, the code and the merchant identification number is sent to the mobile wallet bank computer system 10. At step 209, the mobile wallet bank computer system 10 confirms the code's validity. Details of the code (TID) may be compared against codes previously generated by the mobile wallet bank computer system 10 (in this example, the code is the same as that generated in step 204). Additionally, the mobile wallet bank computer system 10 may confirm that the code has not expired. For example, the code that was originally generated at step 204 may expire within a predetermined period of time, such as, 15 minutes, 10 minutes, 5 minutes, or another period of time. Also, the mobile wallet bank computer system 10 may confirm that the code has not already been used for another transaction.


At step 210a, upon verifying the code, the mobile wallet bank computer system 10 transmits the messaging hub computer system 20 payment information (e.g., account information) for the payment account to be used for the transaction. The payment information may be the payment identifier (PI) in one embodiment. For example, a credit card or debit card number, demand deposit account or alternative payment of the user may be transmitted. Additionally, the mobile wallet bank computer system 10 may send stored merchant loyalty information to the messaging hub computer system 20. After step 210a, the messaging hub computer system 20 transmits the payment information and the loyalty information to the recipient bank computer system 30.


Next, at step 211, the recipient bank system 30 transmits the loyalty information to the POS device 40. At step 212, the POS device 40 uses the loyalty information to calculate the final transaction amount and transmits the transaction amount to the recipient bank computer system 30. At step 213, upon receiving the transaction amount, the recipient bank system 30 processes the transaction using the payment information received from the messaging hub computer system 20. For example, if a credit card number is received, the recipient bank system 30 may submit the credit card transaction for approval and the credit card transaction may be processed as a standard four party credit card transaction between a customer, a merchant, an issuing bank and an acquiring bank.


Next, at step 214, the recipient bank system 30 provides an indication whether the transaction is approved or declined to the POS device 40. Next, at step 215, the POS device 40 prints a receipt for the user. As another example, the user may opt via the mobile wallet application 6 to have the receipt sent electronically to the mobile device 1 via the messaging hub computer system 20.


Next, at step 216, the recipient bank system 30 provides an indication whether the transaction is approved or declined to the mobile wallet bank computer system 10 through the messaging hub computer system 20. At step 217, the mobile wallet bank computer system 10 sends a notification to the mobile wallet application. Based on this information, a message may be displayed to the user via the mobile device 1 at the point of sale indicating whether the transaction was approved or declined.


In various embodiments, each message that is transmitted for steps 201 to 217 includes the code to identify the transaction. The banks computer systems 10 and 30 and the messaging hub computer system 20 may receive the sensitive account information (e.g., credit card number) during the various steps discussed herein, however, the POS device 40 or the mobile device 1 need not receive the user's account information. Hence, account security may be enhanced. The messaging hub computer system 20 facilitates a secure transmission of sensitive information and aids the banks by providing a single point of contact. Moreover, the messaging hub computer system 20 creates a messaging format that each banking entity must comply with for the messages.


In the embodiment of FIG. 2a, a code is generated on the display of the mobile device 110 and the code is displayed for optical scanning by the POS device 40. Hence, the user presents the mobile device for scanning at the time of sale, creating a user experience for the user that is somewhat similar to presentation of a credit card.


Referring now to FIG. 2b, FIG. 2b is a process implemented by the payment processing system. In the embodiment shown in FIG. 2b, the credit card issuer bank is different than the mobile wallet application provider. In FIGS. 2b and 3b, for simplicity mobile device 1 and mobile wallet bank computer system 10 are shown as being combined, but it will be appreciated that they operate in a manner that is similar to FIG. 2a. Table 2 below describes the messages that are transmitted in various steps and the content of the messages. Table 2 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIGS. 2b and 3b. The messaging hub that is referred to in Table 2 is the messaging hub computer system 20 and may also include messaging hub bank computer system 50 from FIGS. 1, 2b and 3b. The beta issuer that is referred to in Table 2 may operate or signify the issuing bank computer system 50 from FIGS. 2b and 3b. The POS scanner referred to in Table 2 is shown in FIGS. 2b and 3b as POS device 40. The recipient bank computer 30 shown in FIGS. 2b and 3b is discussed in Table 2 as the gamma acquirer. However, the steps from FIG. 3b may use similar messages and routing as shown in FIG. 2b. Unlike FIG. 2b, the POS device 40 initiates the process of FIG. 3b. The steps shown in FIG. 3b transmit similar data as the step described for FIG. 2b.













TABLE 2








Msg



Step number

Msg
Routing



and

Routing
Info



Name
Step Description
Info (TO)
(FROM)
Payload







251 - Customer
Consumer of Alpha
Mobile
Mobile
WUI


requests a
Wallet or Alpha wallet
wallet
device



Dynamic Token
makes a request for a
provider




(DT)
Dynamic token using a






previously provisioned






Payment Identifier






User selects Payment






Identifier associated






with the underlying






payment method





252 - Dynamic
Alpha Wallet sends
II: Issuer
WUI:
PI: Payment


Token (DT)
request for Dynamic
Identifier
Wallet
Identifier


request sent to
Token to the

User Info



Messaging Hub
Messaging Hub

WPI:



(MH)


Wallet






Platform






Info



253 - Dynamic
Messaging Hub (MH)
II: Issuer
WUI:
PI: Payment


Token (DT)
passes request for
Identifier
Wallet
Identifier


request sent to
Dynamic Token (DT)

User Info



Beta Issuer
to the appropriate

WPI:




Issuer.

Wallet






Platform






Info



254 - Beta issuer
Beta issuer generates a
WUI:
II: Issuer
DT: Dynamic


generates
Dynamic Token in
Wallet User
Identifier
Token.


Dynamic Token
Track 1 or 2 format
Info




and sends back to
and sends it back to the
WPI:




the MH
MH (Messaging Hub)
Wallet




(Messaging Hub)
The Dynamic Token is
Platform





in Track 1 or Track 2
Info





format and includes






issuer specific info,






dynamic data and the






last 4 digits of the






underlying payment






type





255 - MH sends
MH sends the
WUI:
II: Issuer
DT: Dynamic


the Dynamic
Dynamic Token (DT)
Wallet User
Identifier
Token


Token (DT) to the
to the Alpha Wallet.
Info




Alpha Wallet

WPI:






Wallet






Platform






Info




256 - POS
The Alpha Wallet will
via scan
via scan
DT: Dynamic


Scanner reads or
either display the


Token


accepts the DT
Dynamic Token as a






QR Code for scanning






by the POS or transmit






the Dynamic Token to






the POS via other






communication






methods.






Other communication






methods may include






NFC, Bluetooth,






Hypersonic or other






communication






technologies





257 - POS sends
Once the final
II: Issuer
MID:
DT: Dynamic


final purchase
purchase amount is
Identifier
Merchant
Token


amount and DT to
calculated, the POS
as part of
ID



Gamma Acquirer
will send the Dynamic
the DT





Token (Track 1 or 2
Dynamic





Data) to it's existing
Token





acquirer/processor





258 - Gamma
The Gamma Acquirer
II: Issuer
AID:
DT: Dynamic


Acquirer sends
reads the II as part of
Identifier
Acquirer
Token


DT to MH
the Dynamic Token
as part of
ID




and sends the DT to
the DT
MID:




the MH
Dynamic
Merchant





Token
ID



259 - MH receives
The MH reads the II as
II: Issuer
AID:
DT: Dynamic


DT and routes to
part of the Dynamic
Identifier
Acquirer
Token


the Beta Issuer
Token, recognizes it as
as part of
ID




an II and sends the DT
the DT
MID:




to the Beta Issuer.
Dynamic
Merchant





Token
ID



260 - Beta Issuer
Beta issuer matches


ACN/UPC:


confirms the DT's
the DT to the original


Actual Card


validity and
PI that was associated


Number/


retrieves the actual
with the DT and then


Underlying


card
determines the


Payment


number/underlying
underlying payment


Credential


payment credential
credential





261 - Beta Issuer

AID:
II: Issuer
ACN/UPC:


sends the

Acquirer
Identifier
Actual Card


ACN/UPC to the

ID

Number/


MH

MID:

Underlying




Merchant

Payment




ID

Credential






Trace ID: A






subset of the






DT for the






transaction that






is used for issuer






security and






matching


262 - MH Sends
MH looks at the AID
AID:
II: Issuer
ACN/UPC:


the ACN/UPC to
associated with the
Acquirer
Identifier
Actual Card


the Gamma
message and sends the
ID

Number/


Acquirer along
ACN/UPC to the
MID:

Underlying


with a Trace ID.
appropriate acquirer.
Merchant

Payment




ID

Credential






Trace ID: A






subset of the






DT for the






transaction that






is used for issuer






security and






matching


263 - Gamma
Gamma Acquirer


ACN/UPC:


Acquirer
processes payment


Actual Card


processes payment
using the ACN/UPC


Number/


using the
via its existing process


Underlying


ACN/UPC
and includes the Trace


Payment



ID for issuer matching


Credential



and security. This






results in authorization






and settlement





264 - Gamma
Existing process


Approve/Decline


Acquirer sends






Approval/Decline






to the POS






265 - POS prints
Existing process


Approve/Decline


receipt as normal






266 - Gamma
Gamma Acquirer
II: Issuer
AID:
Approve/Decline


Acquirer sends
sends
Identifier
Acquirer



Approval/Decline
Approval/Decline to

ID



to MH
MH based upon the II

MID:






Merchant






ID



267 - MH sends
MH sends
II: Issuer
AID:
Approve/Decline


Approval/Decline
Approval/Decline to
Identifier
Acquirer



to the Alpha
the Alpha Wallet

ID



Wallet
based upon the II

MID:






Merchant






ID



268 - Alpha
Alpha Wallets sends





Wallets sends an
an email and push





email and push
notification to the





notification to the
Alpha Wallet User





Alpha Wallet User









Referring now to FIG. 3a, FIG. 3a is a process implemented by the payment processing system. In the embodiment of FIG. 3a, a code (DT) is generated and displayed by the POS device 40 and optically scanned by the mobile device 1. Such an arrangement avoids the need for the POS device 40 to include a scanner.


Specifically, in the embodiment shown in FIG. 3a, at step 301, the user may select using a mobile device 1 as a payment option at the POS device 40. Upon receiving the user input, the POS device 40 sends a request to the recipient bank system 30, specifically, a request for a numerical code (DT), a QR code or other code as described herein. In response, at step 302, the recipient bank system 30 creates the code (e.g., numerical, barcode, or QR code, etc). The recipient bank system 30 may send the code to POS device 40 for display on POS terminal screen or printed on a receipt. At step 303, the mobile device 1 may receive the code by using a camera. A user may access the mobile wallet application in the mobile device 1 and request that a payment is made. Upon scanning or taking a picture of the code that is displayed on the POS device 40 at step 303, the mobile device 1 may transmit the code to the mobile wallet bank 10 at step 304. Next, at step 305, the mobile wallet bank computer system 10 sends the code to the messaging hub computer system 20. The code may identify the merchant using merchant identifier and merchant registry information (MM). The messaging hub computer system 20, at step 306, sends the code to the recipient bank system 30. At step 307, the recipient bank system 30 determines the validity of the code and also determines the whether the codes is expired, not previously used, etc. The recipient bank system 30 accesses the database and determines the merchant identification for the (POS ID and/or MID) POS device 40. The merchant identification is transmitted from the recipient bank system 30 to the messaging hub computer system 20 and the messaging hub computer system 20 transmits the merchant identification to the mobile wallet bank computer system 10. The mobile wallet bank computer system 10 receives the merchant identification and the transaction code.


At step 308, the mobile wallet bank computer system 10 sends the payment information regarding user payment account and any stored merchant loyalty information to the recipient bank system 30 through the messaging hub computer system 20. Next, at step 309, the recipient bank system 30 may transmit the loyalty information to the POS device 40 to be displayed for the user. Next, at step 310, based on the loyalty information, the final transaction amount is determined by the POS device 40 and transmitted to the recipient bank computer system 40. The recipient bank system 30 receives the transaction amount and processes the transaction using the payment information that the recipient bank system 30 received from the mobile wallet bank computer system 10, at step 311. The recipient bank system 30 also determines whether the transaction is approved or denied.


At step 312, the approval or denial is transmitted to the POS device 40. Next, at step 313, the POS device 40 prints a receipt or sends a receipt to the user. Next, at step 314, the recipient bank system 30 sends an approval and/or decline message to the mobile wallet bank 10 via a messaging hub computer system 20. The mobile wallet bank system 10 transmits a notification to the mobile device 110 to inform the mobile device 110 regarding the approval or decline decisions at step 315.


Referring now to FIG. 3b, FIG. 3b is a process implemented by the payment processing system. Table 2 above describes the messages that are transmitted in various steps and the content of the messages. Table 2 refers to the steps from FIG. 2a. However, the steps from FIG. 3b may use similar messages and routing as shown in FIG. 2a. FIG. 3b illustrates a process implemented by the payment processing system of FIG. 1. In the embodiment shown in FIG. 3b, the credit card issuer bank is a separate entity than the mobile wallet application provider. Table 4 below describes the messages that are transmitted in various steps and the content of the messages.


In the embodiments of FIGS. 2a, 2b, 3a and 3b, the recipient bank system 30 receives the credit card number of the user, submits the credit card transaction for approval, and the credit card transaction is processed as a standard four party credit card transaction between a customer, a merchant, an issuing bank and an acquiring bank. Referring now to FIGS. 4 and 5, in other embodiments, the messaging hub computer system 20 may operate as a master merchant by acting as an aggregator of funds and processing the transaction by transferring the funds from a credit card of the user of the mobile device to the recipient bank computer system 30.


For example, in some instances, a merchant or an individual may not be a member of a credit card association and may not be able to receive funds as a “merchant” in the standard four party credit card transaction arrangement between a customer, a merchant, an issuing bank and an acquiring bank. In such an arrangement, the merchants (and/or individuals) may receive credit card payments via the messaging hub 20. For example, the messaging hub may operate as the merchant and the master merchant bank may operate as the acquiring bank for purposes of the credit card transaction. The recipient bank computer system 30 then only need operate as a recipient of the funds, and does not need to operate as the acquiring bank in the credit card transaction. Hence, in a first step of the transfer, the funds may be transferred as a credit card transaction from the mobile wallet bank computer system 10 to the messaging hub bank computer system 50. In a second step of the transfer, the funds may be transferred (e.g., via an ACH payment or other payment mechanism) from the master messaging hub computer system 50 to the recipient bank computer system 30. Hence, a merchant or individual that is not a member of a credit card association may receive payments from mobile wallet users that use a credit card as a source of funds.


Referring to FIG. 4, FIG. 4 illustrates another method for completing a transaction that is implemented by the payment processing system of FIG. 1. For purposes of providing an example, it is assumed that the two parties to the transaction in FIG. 4 are a user of mobile wallet application 6 (e.g., consumer) and a merchant. In some embodiments, the merchant may also be using a mobile wallet application that is the same or similar to the mobile wallet application that is being used by the consumer. As mentioned above, it will be appreciated that other types of transactions may be possible.


At step 401, the user may provide input to the POS device 40. For example, a user purchasing merchandise at a merchant location may be at a checkout counter or other type of POS arrangement. The user may be presented with a series of payment options at the POS device 40 (e.g., credit card, debit card, mobile device, and so on). The user selects a payment type (here, “mobile”) to pay for goods or services, and the POS device 40 receives the user's selection of the payment option. The payment option chosen by the user may be a mobile device and the mobile device may offer a credit card as a payment option for mobile. In an example embodiment, the mobile wallet bank may issue the card. In another example embodiment, another financial institution (e.g., other bank 1, other bank 2, etc.) issues the card. In some embodiments, the mobile wallet bank may store account identification information for the credit card associated with the mobile wallet account, such as but not limited to, the credit card number, expiration date, cvv numbers and other account identification information.


Next, at step 402, the user may access the mobile wallet application 6 on the mobile device 1 and select a “pay now” or similar option on the mobile device 1. As previously discussed, the mobile wallet application 6 may also offer the user various payment types (e.g., various credit cards, debit cards, alternative payment type, demand deposit account, bank account, money market account and so on). A profile may be stored on the mobile device 1 or the mobile wallet bank computer system 10 that stores a priority of payment types in the most preferred to the least preferred option. The mobile device 1 may receive the user input and initiate communication with the mobile wallet bank computer system 10.


At step 403, the mobile device 1 may send a request to the mobile wallet bank computer system 10 for a code that may be used to identify the transaction that will occur between the user and the owner of the POS device 40. The message that is transmitted may include information identifying the user (e.g., a device identifier for the mobile device 1, a unique identifier associated with the mobile wallet application 6 when installed by the user, etc.). Information regarding the payment type selected by the user may also be sent. The mobile wallet bank computer system 10 may be configured to receive requests directly from the mobile device 1 for codes and/or other information.


At step 404, the mobile wallet bank computer system 10 may generate a random code or sequential code as described above, e.g., in connection with FIG. 1. In one embodiment, the code may represent a unique identifier for the transaction that is about to be completed between the user and the merchant. In other embodiments, the code may also include a transaction identifier and verification codes that identify the mobile wallet bank computer system 10 or the recipient bank computer 30 to the messaging hub computer system 20 when the code is received by the messaging hub computer system 20. In some embodiments, the mobile wallet bank computer system 10 may generate a code based on a standard that the messaging hub computer system 20 can decode and determine which entity (e.g., financial institution of the recipient or merchant) to communicate with next. In some embodiments, the code may represent a coded version of the a card association payment type information (i.e. card number, expiration date, security codes) that may be decoded by the messaging hub computer system 20 using a key that is embedded within a decodable portion of the code.


After receiving the code from the mobile wallet bank computer system 10, the mobile device 1 may process the code using the code processing system 7. In one embodiment, the code may be sent over a wired or wireless link between the mobile device 1 and the mobile wallet bank computer system 10. In one embodiment, to reduce bandwidth requirements and transmission times, the code may be sent as a numeric code and transformed into a QR code for display purposes. In such an embodiment, the code processing system 7 may be configured to convert the code into a displayable image that may be scanned by the POS device 40. In other embodiments, the code may be sent as an image (e.g., QR code or bar code). At step 405, the mobile device 1 may generate a display and the POS device 40 may optically scan the displayed code.


At step 406, after scanning the code from the mobile device 1, the code and a merchant identification number from the POS device 40 is transmitted to the recipient bank computer system 30. At step 407, after receiving the code, the recipient bank computer system 30 may be configured to transmit the code and the merchant identification number to the messaging hub computer system 20. Upon receiving the code, the messaging hub computer system 20 may perform an initial validation of the code and then decode it to determine the banking institution with which it is associated (i.e., to determine which banking institution generated the code). In some embodiments, the code or a portion of the code may be matched with a number that identifies the banking institution (e.g., the last three or four digits may be used to access a lookup table).


Next, at step 408, the code and the merchant identification number is sent to the mobile wallet bank computer system 10. At step 409, the mobile wallet bank computer system 10 confirms the code's validity. Details of the code may be compared against codes that were previously generated by the mobile wallet bank computer system 10 (in this example, the code is the same as the code that was generated in step 404). Additionally, the mobile wallet bank computer system 10 may confirm that the code has not expired. For example, the code that was originally generated at step 404 may expire within a predetermined period of time, such as, 15 minutes, 10 minutes, 5 minutes, 3 minutes or another period of time. The mobile wallet bank computer system 10 maintains a record of the time when each code was generated. When the mobile wallet bank computer system 10 receives the code from the messaging hub computer system 20 or another entity, the mobile wallet bank computer system 10 compares the time the code was generated and the time when the code was received from the messaging hub computer system 20. In some embodiments, the mobile wallet bank computer system 10 provides the time the code was generated to the messaging hub computer system 20 and the messaging hub computer system 20 may perform the time comparison. Also, the mobile wallet bank computer system 10 may confirm that the code has not already been used for another transaction.


At step 410a, upon verifying the validity of the code, the mobile wallet bank computer system 10 transmits the payment information (e.g., account information) to the messaging hub computer system 20. The payment information may include the credit card number to be used for the transaction. Additionally, the mobile wallet bank computer system 10 may send stored merchant loyalty information to the messaging hub computer system 20. At step 410b, the messaging hub computer system 20 may transmit the payment information and the loyalty information to the recipient bank computer system 30.


Next, at step 411, the recipient bank system 30 transmits the loyalty information to the POS device 40. At step 412, the POS device 40 uses the loyalty information to calculate the final transaction amount and transmits the transaction amount to the recipient bank computer system 40. At step 413a, upon receiving the transaction amount, the messaging hub computer system 20 triggers the transaction to occur between the mobile wallet default or user chosen credit card and the recipient bank computer 30 (e.g., merchant demand deposit account). The messaging hub computer system 20 may transfer funds from the credit card account to a messaging hub bank computer system 50. For example, the messaging hub computer system 20 may submit the transaction to the messaging hub bank computer system 50, which may process the credit card transaction as a four party credit card transaction between a merchant (messaging hub 20), acquiring bank (messaging hub bank computer system 50), issuing bank (mobile wallet bank computer system 10 or other bank computer system), and customer (mobile device 1). (If the credit card used by the customer is issued by the mobile wallet bank, then the mobile wallet bank is the issuing bank. If the customer provides a credit card from another bank, then the other bank operates as the issuing bank in the transaction.) The messaging hub bank computer system 50 in step 413b transmits the funds to the recipient bank computer system 30 (e.g., via ACH transfer or other suitable payment mechanism).


In some embodiments, the messaging hub computer system 20 may store profile information for the user of the mobile device 1 in a registry. The profile information for the user may identify a credit card number to be used for the transaction in one embodiment. In other embodiments, the messaging hub computer system 20 may use the registry information to obtain the credit card number from a trusted third party, such as the credit card issuer or the mobile wallet bank computer system 10. In either embodiment, the user may choose a mobile device as the payment option and be offered an option to select from a plurality of credit cards.


In some embodiments, the messaging hub computer system 20 may aggregate the payments for each recipient bank computer system 30 for a period of time (e.g., 1 hour, 1 day, 1 week, etc.). The messaging hub computer system 20 may then cause a single payment to be transmitted for the period of time. For example, the messaging hub computer system 20 may receive the funds from the various credit card issuing banks of different mobile wallet users and transmit the funds to the recipient bank computer system 30 once per day.


Next, at step 414, the messaging hub computer system 20 provides an indication whether the transaction is approved or declined to the POS device 40 via recipient bank computer 30. Next, at step 415, the POS device 40 prints a receipt for the user. As another example, the user may choose via the mobile wallet application 6 to have the receipt sent electronically to the mobile device 1 via the messaging hub computer system 20.


Next at step 416, the messaging hub computer system 20 sends an indication whether the transaction is approved or declined to the mobile wallet bank computer system 10. At step 417, the mobile wallet bank computer system 10 sends a notification to the mobile wallet application 6. Based on this information, a message may be displayed to the user via the mobile device 1 at the point of sale indicating whether the transaction was approved or declined.


In various embodiments, each message that is transmitted for steps 401 to 417 includes the code to identify the transaction. The banks computer systems 10 and 30 and the messaging hub computer system 20 may receive the sensitive account information (e.g., card account information) during the various steps discussed herein, however, the POS device 40 or the mobile device 1 need not receive the user's card account information. Hence, account security may be enhanced. The messaging hub computer system 20 facilitates a secure transmission of sensitive information and aids the banks by providing a single point of contact. Moreover, the messaging hub computer system 20 creates a messaging format that each banking entity must comply with for transmitting messages.


In the embodiment of FIG. 4, a code is generated on the display device 4 of the mobile device 1 and the code is displayed for optical scanning by the POS device 40. Hence, the user presents the mobile device for scanning at the time of sale, creating a user experience for the user that is somewhat similar to presentation of a credit card.


Referring now to FIG. 5, FIG. 5 is a process implemented by the payment processing system 100. In the embodiment of FIG. 5, a code is generated and displayed by the POS device 40 and optically scanned by the mobile device 1. Such an arrangement avoids the need for the POS device 40 to include a scanner.


Specifically, in the embodiment shown in FIG. 5, at step 501, the user may select using a mobile device 1 as a payment option at the POS device 40. Upon receiving the user input, the POS device 40 sends a request to the recipient bank system 30, specifically, a request for a numerical code, a QR code, an RFID code, a near field communication code or other code as described herein. In response, at step 502, the recipient bank system 30 creates the code (e.g., numerical, barcode, or QR code, etc.). The recipient bank system 30 may send the code to POS device 40 for display on POS terminal screen or printed on a receipt. At step 503, the mobile device 1 may receive the code by using a camera. A user may access the mobile wallet application in the mobile device 1 and request that a payment is made. Upon scanning or taking a picture of the code that is displayed on the POS device 40 at step 503, the mobile device 1 may transmit the code to the mobile wallet bank 10 at step 504. Next, at step 505, the mobile wallet bank computer system 10 sends the code to the messaging hub computer system 20. The messaging hub computer system 20, at step 506, sends the code to the recipient bank system 30. At step 507, the recipient bank system 30 determines the validity of the code and also determines whether the code is expired, not previously used, and/or sufficiently timely as described above. The recipient bank system 30 accesses the database and determines the merchant identification for the POS device 40. The merchant identification is transmitted from the recipient bank system 30 to the messaging hub computer system 20 and the messaging hub computer system 20 transmits the merchant identification to the mobile wallet bank computer system 10. The mobile wallet bank computer system 10 receives the merchant identification and the transaction code.


At step 508, the mobile wallet bank computer system 10 sends the payment information regarding user payment credit card and any stored merchant loyalty information to the messaging hub computer system 20. Alternatively or additionally, the messaging hub computer system 20 determines the payment credit card using the registry information stored on the messaging hub computer system 20. Next, at step 509, the recipient bank system 30 may transmit the loyalty information to the POS device 40 to be displayed for the user. Next, at step 510, based on the loyalty information, the final transaction amount is determined by the POS device 40 and transmitted to the recipient bank computer system 40 and the messaging hub computer system 20. The POS device 40 and the recipient bank computer system 40 may transmit the final transaction amount to the messaging hub computer system 20, at step 510.


The messaging hub computer system 20 may process the transaction between the credit card and the messaging hub bank computer system 50 after receiving the transaction amount, at step 511a. In some embodiments, the messaging hub bank computer system 50 may receive the funds equaling the transaction amount from the credit card of the user. Next, at step 511b, the received funds may be transferred to the recipient bank computer system 30 by the messaging hub bank computer system 50. Hence, in some embodiments, the messaging hub computer system 20 may process the transaction as a master merchant on behalf of merchants that lack the ability to process the transaction as a master merchant.


At step 512, the messaging hub computer system 20 sends the approval or denial to the POS device 40. Next, at step 513, the POS device 40 prints a receipt or sends a receipt to the user. Next, at step 514, the recipient bank system 30 sends an approval and/or decline message to the mobile wallet bank 10 via a messaging hub computer system 20. The mobile wallet bank system 10 transmits a notification to inform the mobile device 1 regarding the approval or denial decisions at step 515.



FIG. 6 illustrates a process implemented by the payment processing system of FIG. 1. In the embodiment shown in FIG. 6, the credit card issuer bank is different than the mobile wallet application provider. In FIGS. 6 and 7, for simplicity mobile device 1 and mobile wallet bank computer system 10 are shown as being combined, but it will be appreciated that they operate in a manner that is similar to FIGS. 4, and 5. Table 3 below describes the messages that are transmitted in various steps and the content of the messages. FIG. 7 illustrates a process implemented by the payment processing system of FIG. 1. Table 3 refers to the steps from FIG. 6. However, the steps from FIG. 7 may use similar messages and routing as shown in FIG. 6. In the embodiment shown in FIGS. 6 and 7, the credit card issuer bank is a separate entity than the mobile wallet application provider. Unlike FIG. 6, the POS device 40 initiates the process of FIG. 7. The steps shown in FIG. 7 transmit similar data as the step described for FIG. 6. Table 3 refers to an alpha wallet that represents the mobile wallet bank computer 10 and the mobile device 1 from FIGS. 6 and 7. The messaging hub that is referred to in Table 3 has the messaging hub computer system 20 from FIGS. 6 and 7. The beta issuer that is referred to in Table 3 may operate or signify the issuing bank computer system 60 from FIGS. 6 and 7. The POS scanner referred to in Table 3 is shown in FIGS. 6 and 7 as POS device 40. The recipient bank computer 30 shown in FIGS. 6 and 7 is discussed in Table 3 as the gamma acquirer. In other embodiments, the gamma acquirer can the messaging hub bank computer system 50 that receives instructions from the messaging hub 20. After receiving the funds the messaging hub bank computer system 50 may transfer the funds to the recipient bank computer system 30.













TABLE 3







Msg
Msg





Routing
Routing





Info
Info



Step Name
Step Description
(TO)
(FROM)
Payload







601 - Customer
Consumer of Alpha Wallet or
N/A
N/A
N/A


requests a
Alpha wallet makes a request for





Dynamic
a Dynamic token using a





Token (DT)
previously provisioned Payment






Identifier.






User selects Payment Identifier






associated with the underlying






payment method





602 - Dynamic
Alpha Wallet sends request for
II: Issuer
WUI:
PI:


Token (DT)
Dynamic Token to the
Identifier
Wallet User
Payment


request sent to
Messaging hub

Info
Identifier


Messaging


WPI:



Hub (MH)


Wallet






Platform






Info



603 - Dynamic
Messaging hub (MH) passes
II: Issuer
WUI:
PI:


Token (DT)
request for Dynamic Token
Identifier
Wallet User
Payment


request sent to
(DT) to the appropriate Issuer.

Info
Identifier


Beta Issuer


WPI:






Wallet






Platform






Info



604 - Beta
Beta issuer generates a Dynamic
WUI: Wallet
II: Issuer
DT:


issuer generates
Token in Track 1 or 2 format
User Info
Identifier
Dynamic


Dynamic
and sends it back to the MH
WPI: Wallet

Token.


Token and
(Messaging hub).
Platform Info




sends back to
The Dynamic Token is in Track





the MH
1 or Track 2 format and includes





(Messaging
issuer specific info, dynamic





hub)
data and the last 4 digits of the






underlying payment type.





605 - MH sends
MH sends the Dynamic Token
WUI: Wallet
II: Issuer
DT:


the Dynamic
(DT) to the Alpha Wallet.
User Info
Identifier
Dynamic


Token (DT) to

WPI: Wallet

Token


the Alpha

Platform Info




Wallet






606 - POS
The Alpha Wallet will either
n/a - via scan
n/a - via
DT:


Scanner reads
display the Dynamic Token as a

scan
Dynamic


or accepts the
QR Code for scanning by the


Token


DT
POS or transmit the Dynamic






Token to the POS via other






communication methods. Other






communication methods may






include NFC, Bluetooth,






Hypersonic or other






communication technologies





607 - POS
Once the final purchase amount
II: Issuer
MID:
DT:


sends final
is calculated, the POS will send
Identifier as
Merchant
Dynamic


purchase
the Dynamic Token (Track 1 or
part of the
ID
Token


amount and DT
2 Data) to it's existing
DT Dynamic




to Gamma
acquirer/processor
Token




Acquirer






608 - Gamma
The Gamma Acquirer reads the
II: Issuer
AID:
DT:


Acquirer sends
II as part of the Dynamic Token
Identifier as
Acquirer
Dynamic


DT to MH
and sends the DT to the MH
part of the
ID
Token




DT Dynamic
MID:





Token
Merchant






ID






MRI:






Merchant






Registry






Info



609 - MH
The MH reads the II as part of
II: Issuer
AID:
DT:


receives DT
the Dynamic Token, recognizes
Identifier as
Acquirer
Dynamic


and routes to
it as an II and sends the DT to
part of the
ID
Token


the Beta Issuer
the Beta Issuer.
DT Dynamic
MID:





Token
Merchant






ID



610 - Beta
Beta issuer matches the DT to
n/a
n/a
CRI:


Issuer confirms
the original PI that was


Consumer's


the DT's
associated with the DT and then


Registry


validity and
identifies the Consumer's


Info


retrieves the
Registry Info





Consumer's






Registry Info






611 - Beta

AID:
II: Issuer
CRI:


Issuer sends the

Acquirer ID
Identifier
Consumer's


Consumer's

MID:

Registry


Registry Info

Merchant ID

Info


to the MH






612 - MH
The CRI enables MH to look up





acting as master
the consumer's actual payment





merchant
credential either internally or





processes the
from an external source.





transaction
MH acts as master merchant and






triggers a transaction by






knowing the Final Purchase






Amount and the CRI.






After the payment clears, MH






sends the money to the






appropriate merchant based upon






the MRI.






This is where the money






movement occurs.





613 - MH sends
MH sends Approval/Decline to
AID:
MH
Approve/


Approval/Decline
Gamma Acquirer based upon the
Acquirer ID

Decline


to Gamma
AID/MID
MID:




Acquirer

Merchant ID




614 - Gamma
Gamma Acquirer sends
MID:
MH
Approve/


Acquirer sends
Approval/Decline to the POS
Merchant ID

Decline


Approval/Decline
based upon the MID





to the POS






615 - POS



Approve/


prints receipt



Decline


616 - MH
MH sends Approval/Decline to
WUI: Wallet
MH
Approve/


sends
Alpha Wallet based upon WUI
User Info

Decline


Approval/Decline
and WPI
WPI: Wallet




to Alpha

Platform




Wallet

Info




617 - Alpha
Alpha Wallets sends an email





Wallets sends
and push notification to the





an email and
Alpha Wallet User





push






notification to






the Alpha






Wallet User









The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings. The present embodiments contemplate methods, systems and program products on any machine-readable media for accomplishing its operations. The embodiments of may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired system.


As noted above, embodiments within the scope of this disclosure include program products comprising non-transitory machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable or non-transitory storage media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.


Embodiments have been described in the general context of method steps which may be implemented in one embodiment by a program product including machine-executable instructions, such as program code, for example in the form of program modules executed by machines in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps.


As previously indicated, embodiments may be practiced in a networked environment using logical connections to one or more remote computers having processors. Those skilled in the art will appreciate that such network computing environments may encompass many types of computers, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and so on. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.


An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The system memory may include read only memory (ROM) and random access memory (RAM). The computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer. It should also be noted that the word “terminal” as used herein is intended to encompass computer input and output devices. Input devices, as described herein, include a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. The output devices, as described herein, include a computer monitor, printer, facsimile machine, or other output devices performing a similar function.


It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the software and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.


The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.

Claims
  • 1. A computer-implemented method, comprising: receiving, by a messaging hub computer system, a payment token generated for a mobile wallet transaction between a payor and a merchant from a mobile device of the payor, wherein the payment token is unique to the mobile wallet transaction and wherein the payment token is displayed on a POS (Point of Sale) device of the merchant and scanned by the mobile device as part of the mobile wallet transaction;decoding, by the messaging hub computer system, the payment token;determining, by the messaging hub computer system and based on a portion of the decoded payment token, an issuing financial institution and an account number corresponding to a payment method used by the payor, wherein determining the issuing financial institution comprises correlating the portion of the decoded payment token to electronic contact information regarding the issuing financial institution; andinitiating, by the messaging hub computer system, a transfer of funds from a payor account at the issuing financial institution to a merchant account held by the merchant at a recipient financial institution, the payor account corresponding to the payment method.
  • 2. The method of claim 1, further comprising: causing the POS device associated with the merchant to display the payment token as a scannable code comprising the payment token and transmit the scannable code, via the mobile device, to a mobile wallet bank computer system; andreceiving, from the mobile wallet bank computer system, transaction information comprising the payment token.
  • 3. The method of claim 2, wherein the scannable code is transmitted to the mobile device via one of optical scanning and near-field communications.
  • 4. The method of claim 2, further comprising: causing the POS device associated with the merchant to transmit a transaction request to a recipient bank computer system; andcausing the recipient bank computer system to generate the payment token and transmit the payment token to the POS device.
  • 5. The method of claim 4, wherein the mobile wallet bank computer system is operated by the issuing financial institution.
  • 6. The method of claim 4, wherein the mobile wallet bank computer system is operated by an entity different from the issuing financial institution.
  • 7. The method of claim 1, wherein the mobile device is a smart phone.
  • 8. The method of claim 1, wherein the mobile device is a portable gaming device.
  • 9. A messaging hub computer system comprising at least one processor and a memory, the memory having computer-executable instructions stored thereon that, when executed by the at least one processor, cause the messaging hub computer system to: receive a payment token generated for a mobile wallet transaction between a payor and a merchant from a mobile device of the payor, wherein the payment token is displayed on a POS (Point of Sale) device of the merchant and scanned by the mobile device as part of the mobile wallet transaction;decode the payment token;determine, based on a portion of the decoded payment token, an issuing financial institution and an account number corresponding to a payment method used by the payor, wherein determining the issuing financial institution comprises correlating the portion of the decoded payment token to electronic contact information regarding the issuing financial institution; andinitiate a transfer of funds from a payor account at the issuing financial institution to a merchant account held by the merchant at a recipient financial institution, the payor account corresponding to the payment method.
  • 10. The messaging hub computer system of claim 9, the computer-executable instructions further structured to: cause the POS device associated with the merchant to display the payment token as a scannable code comprising the payment token and transmit the scannable code, via the mobile device, to a mobile wallet bank computer system; andreceive, from the mobile wallet bank computer system, transaction information comprising the payment token.
  • 11. The messaging hub computer system of claim 10, the computer-executable instructions further structured to: cause the POS device associated with the merchant to transmit a transaction request to a recipient bank computer system; andcause the recipient bank computer system to generate the payment token and transmit the payment token to the POS device.
  • 12. The messaging hub computer system of claim 9, wherein the mobile device is at least one of a smart phone and a portable gaming device.
  • 13. Non-transitory computer-readable media having instructions stored thereon that, when executed by a processor of a messaging hub computer system, are structured to cause the messaging hub computer system to perform operations comprising: receiving a payment token generated for a mobile wallet transaction between a payor and a merchant from a mobile device of the payor, wherein the payment token is displayed on a POS (Point of Sale) device of the merchant and scanned by the mobile device as part of the mobile wallet transaction;decoding the payment token;determining, based on a portion of the decoded payment token, an issuing financial institution and an account number corresponding to a payment method used by the payor, wherein determining the issuing financial institution comprises correlating the portion of the decoded payment token to electronic contact information regarding the issuing financial institution; andinitiating a transfer of funds from a payor account at the issuing financial institution to a merchant account held by the merchant at a recipient financial institution, the payor account corresponding to the payment method.
  • 14. The media of claim 13, the operations further comprising: causing the POS device associated with the merchant to display the payment token as a scannable code comprising the payment token and transmit the scannable code, via the mobile device, to a mobile wallet bank computer system; andreceiving, from the mobile wallet bank computer system, transaction information comprising the payment token.
  • 15. The media of claim 14, the operations further comprising: causing the POS device associated with the merchant to transmit a transaction request to a recipient bank computer system; andcausing the recipient bank computer system to generate the payment token and transmit the payment token to the POS device.
  • 16. The media of claim 13, wherein the mobile device is a smart phone.
  • 17. The media of claim 13, wherein the mobile device is a portable gaming device.
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

This application is a Continuation of U.S. application Ser. No. 13/831,577, filed Mar. 15, 2013, which is a continuation of U.S. patent application Ser. No. 13/831,326, filed Mar. 14, 2013 which claims the benefit of U.S. Provisional Patent App. Ser. No. 61/738,376, filed Dec. 17, 2012, incorporated herein by reference in its entirety.

US Referenced Citations (109)
Number Name Date Kind
5943423 Muftic Aug 1999 A
5987438 Nakano et al. Nov 1999 A
6173272 Thomas et al. Jan 2001 B1
6246769 Kohut Jun 2001 B1
6327578 Linehan Dec 2001 B1
6424953 Glassman et al. Jul 2002 B1
7257554 Glassman et al. Aug 2007 B1
7433845 Flitcroft et al. Oct 2008 B1
7502761 Siegal et al. Mar 2009 B2
7543738 Saunders et al. Jun 2009 B1
7734527 Uzo Jun 2010 B2
8417633 Chmara et al. Apr 2013 B1
8616453 Itwaru Dec 2013 B2
8720771 MacKinnon Keith May 2014 B2
9195984 Spector et al. Nov 2015 B1
9355393 Purves et al. May 2016 B2
10354321 Royyuru et al. Jul 2019 B2
20020161645 Walker et al. Oct 2002 A1
20020194080 Lourie Dec 2002 A1
20020194128 Maritzen et al. Dec 2002 A1
20030042301 Rajasekaran Mar 2003 A1
20030200184 Dominguez et al. Oct 2003 A1
20040077332 Ephraim et al. Apr 2004 A1
20040143550 Creamer Jul 2004 A1
20040153402 Smith et al. Aug 2004 A1
20040167854 Knowles et al. Aug 2004 A1
20050125343 Mendelovich Jun 2005 A1
20050192884 Raines Sep 2005 A1
20060054695 Owada Mar 2006 A1
20060116940 Dippold et al. Jun 2006 A1
20070033070 Beck et al. Feb 2007 A1
20070250440 Paulsen et al. Oct 2007 A1
20070267479 Nix et al. Nov 2007 A1
20070276765 Hazel et al. Nov 2007 A1
20080183621 Evans Jul 2008 A1
20080207203 Arthur et al. Aug 2008 A1
20080208744 Arthur et al. Aug 2008 A1
20080215489 Lawson et al. Sep 2008 A1
20080308628 Payne et al. Dec 2008 A1
20090024527 Sellen et al. Jan 2009 A1
20090048953 Hazel et al. Feb 2009 A1
20090112747 Mullen Apr 2009 A1
20090204530 Hanson Aug 2009 A1
20090254440 Pharris Oct 2009 A1
20100106649 Annan Apr 2010 A1
20100125510 Smith et al. May 2010 A1
20100145860 Pelegero Jun 2010 A1
20100153273 Sellars et al. Jun 2010 A1
20100217710 Fujita Aug 2010 A1
20100306168 Ostad et al. Dec 2010 A1
20100312704 Rohatgi Dec 2010 A1
20110087537 Hanafi et al. Apr 2011 A1
20110137797 Stals et al. Jun 2011 A1
20110161233 Tieken Jun 2011 A1
20110191250 Bishop et al. Aug 2011 A1
20110208600 Aharoni Aug 2011 A1
20110258062 Hirson Oct 2011 A1
20110276478 Hirson et al. Nov 2011 A1
20120005076 Dessert et al. Jan 2012 A1
20120011072 Lodolo Jan 2012 A1
20120035997 Burgess et al. Feb 2012 A1
20120048925 Suzuki Mar 2012 A1
20120084200 Triana Apr 2012 A1
20120109762 Getchius May 2012 A1
20120130889 Lyons et al. May 2012 A1
20120185317 Wong Jul 2012 A1
20120185322 Shipley Jul 2012 A1
20120191611 Kelly et al. Jul 2012 A1
20120203700 Ornce et al. Aug 2012 A1
20120259698 Yurow Oct 2012 A1
20120259782 Hammad Oct 2012 A1
20120271660 Harris et al. Oct 2012 A1
20120290376 Dryer Nov 2012 A1
20120316992 Oborne Dec 2012 A1
20120323786 Kirsch Dec 2012 A1
20130080318 Katz et al. Mar 2013 A1
20130103574 Conrad et al. Apr 2013 A1
20130110658 Lyman et al. May 2013 A1
20130117138 Hazel et al. May 2013 A1
20130132219 Liberty May 2013 A1
20130151400 Makhotin Jun 2013 A1
20130198080 Anderson et al. Aug 2013 A1
20130238455 Laracey Sep 2013 A1
20130238492 Muthu et al. Sep 2013 A1
20130246259 Dessert Sep 2013 A1
20130256403 MacKinnon Keith Oct 2013 A1
20130282588 Hruska Oct 2013 A1
20130282589 Shoup Oct 2013 A1
20130339253 Sincai Dec 2013 A1
20140006224 Grigg et al. Jan 2014 A1
20140032419 Anderson et al. Jan 2014 A1
20140040130 Kunz et al. Feb 2014 A1
20140040131 Andrews et al. Feb 2014 A1
20140040147 Varadarajan et al. Feb 2014 A1
20140040148 Ozvat et al. Feb 2014 A1
20140108260 Poole Apr 2014 A1
20140114853 Guedj Apr 2014 A1
20140143146 Passanha et al. May 2014 A1
20140149285 De et al. May 2014 A1
20140164243 Aabye et al. Jun 2014 A1
20140344153 Raj et al. Nov 2014 A1
20140351070 Christner et al. Nov 2014 A1
20140351132 Wieler et al. Nov 2014 A1
20150026070 Groarke Jan 2015 A1
20150032622 Powell Jan 2015 A1
20150032626 Dill et al. Jan 2015 A1
20150032627 Dill et al. Jan 2015 A1
20150248664 Makhdumi Sep 2015 A1
20170161701 Amancherla Jun 2017 A1
Foreign Referenced Citations (8)
Number Date Country
2574198 Feb 2006 CA
2 506 421 Apr 2014 GB
M410932 Sep 2011 TW
WO-03029942 Apr 2003 WO
WO-2012005954 Jan 2012 WO
WO-2012031905 Mar 2012 WO
WO-2012151660 Nov 2012 WO
WO-2012166790 Dec 2012 WO
Non-Patent Literature Citations (15)
Entry
A.J.C. Trappey, C.V. Trappey and A.P.T. Hsu, “Patent portfolio analysis of e-payment services using technical ontology roadmaps,” 2016 IEEE International Conference on Systems, Man, and Cybernetics (SMC), Budapest, 2016, pp. 004824-004829.
Daswani, Neil et al. “SWAPEROO: A Simple Wallet Architecture for Payments, Exchanges, Refunds, and Other Operations.” USENIX Workshop on Electronic Commerce (1998).
F. Wan, J. Li, N. Ma, X. He, Y. Cao ana H. Yang, “Researcn and Design of E-commerce Payment System,” 2017 International Conference on Computer Technology, Electronics and Communication (ICCTEC), Dalian, China, 2017, pp. 1294-1297.
M. A. Hassan and Z. Shukur, “Review of Digital Wallet Requirements,” 2019 International Conference on Cybersecurity (ICoCSec), Negeri Sembilan, Malaysia, 2019, pp. 43-48.
U.S. Appl. No. 13/831,326, filed Mar. 14, 2013.
U.S. Appl. No. 13/831,577, filed Mar. 15, 2013.
Kim, S. and Oh, H., A New Electronic Check System with Reusable Refunds, International Journal of Information Security, 1.3(2002), 175-188.
Mann, Ronald J., Regulating Internet Payment Intermediaries, Texas Law Review, 82.3(2004), 681.
Mohanty, R.P., Seth, D., and Mukadam, S., Quality Dimensions of E-Commerce and Their Implications, Total Quality Management & Business Excellence, 18.3(2007), 219-247.
Ruiz-Martinez, Antonio and Marin-Lopez, C. Inmaculada, A Lightweight Payment Scheme for Real-Time Services Eased on SIP, EURASIP Journal on Wireless Communications and Networking 2012, 1-25 (2012).
Bareisis, Z. (2011). Defining a payment services hub. Journal of Internet Banking and Commerce, 16(1), 1-16. Retrieved from https://www.proquest.com/scholarly-journals/defi ning-payment-services-hub/docview/876040059/se-2?accountid = 14 7 53 (Year: 2011).
Alhothaily, Abdulrahma. “Secure Verification for Payment and Banking Systems.” ProQuest Dissertations Publishing, 2017. Print. (Year: 2017).
Alhothaily, Abdulrahman et al. “QuickCash: Secure Transfer Payment Systems.” Sensors (Basel, Switzerland) 17.6 (2017): 1376-. Web. (Year: 2017).
Kandra, A., How to Turn Your Smartphone Into a Wallet. PCWorld, 2013;31(4):26. Accessed Jun. 28, 2022. https://search.ebscohost.com/login.aspx?direct=true&db=iih&AN=86173049&site=ehost-live&scope=site (Year: 2013).
Zhuang, Yunhui et al., “Matching in Proximity Authentication and Mobile Payment EcoSystem: What Are We Missing?” Radio Frequency Identification and IoT Security. Cham: Springer International Publishing, 2017. 163-172. Web. (Year: 2017).
Provisional Applications (1)
Number Date Country
61738376 Dec 2012 US
Continuations (2)
Number Date Country
Parent 13831577 Mar 2013 US
Child 16800953 US
Parent 13831326 Mar 2013 US
Child 13831577 US