Using a mobile wallet infrastructure to support multiple mobile wallet providers

Description

BACKGROUND

Mobile phones and other digital devices have become increasingly popular in recent years. Many mobile device users use their devices to perform countless different daily tasks. For instance, mobile devices allow users to check email, send and receive instant messages, check calendar items, take notes, set up reminders, browse the internet, play games or perform any number of different things using specialized applications or “apps”. These applications allow mobile devices to communicate with other computer systems and perform a wide variety of network-connected tasks previously not possible with a mobile device.

BRIEF SUMMARY

Embodiments described herein extend to methods, systems, and computer program products for a cloud-based transaction platform. Embodiments include an infrastructure that can be used with third party mobile wallets provided by third party mobile wallet providers. Users with native or third party mobile wallets can use the cloud-based transaction platform to enroll a customer for a third party mobile wallet, add a stored value account (either hosted by the cloud-based transaction platform or a third party), add a bank/credit union account to a third party mobile wallet, add a debit/credit card account to a third party mobile wallet, deposit funds in a third party mobile wallet, withdraw funds from a third party mobile wallet, pay bills from a third party mobile wallet, top up a prepaid mobile account through a third party mobile wallet, transfer funds through a third party mobile wallet, and make in store purchases from a third party mobile wallet.

Embodiments described herein are directed to performing a transaction using a third party mobile wallet, performing a transaction using a third party point of sale (POS) system and to making a purchase from a third party mobile wallet provided by a third party mobile wallet provider. In one embodiment, a cloud-based transaction platform is provided, which receives communication from an agent terminal over a communication channel connected to the cloud-based transaction platform. The agent communication indicates that a customer desires to perform a mobile wallet transaction using their third party mobile wallet. The cloud-based transaction platform sends the agent communication to a third party mobile wallet platform, receives communication from the third party mobile wallet platform confirming processing of the transaction, and sends communication to the agent terminal over a communication channel connected to the cloud-based transaction platform, where the communication indicates confirmation of the processing of the transaction.

In another embodiment, a cloud-based transaction platform performs a transaction using a third party point of sale (POS) system. The cloud-based transaction platform receives communication from a specified POS system implemented at an agent terminal over a communication channel connected to the cloud-based transaction platform. The POS communication indicates that a customer has initiated a mobile wallet transaction using their third party mobile wallet. The cloud-based transaction platform sends the POS communication to a corresponding third party POS transaction processing system that has been established to process POS transactions from the specified POS system, receives communication from the third party POS transaction processing system confirming processing of the transaction, and sends communication to the specified POS system implemented at the agent terminal over a communication channel connected to the cloud-based transaction platform, where the communication indicates confirmation of the processing of the transaction.

In yet another embodiment, a cloud-based transaction platform is provided which allows users to make purchases from a third party mobile wallet provided by a third party mobile wallet provider. The cloud-based transaction platform receives communication from a customer over a communication channel connected to the cloud-based transaction platform. The customer communication indicates that a customer desires to purchase an item for a specified amount of funds using a specified payment method indicated by the customer's third party mobile wallet. The cloud-based transaction platform returns a secure, perishable purchase code to the customer over at least one the communication channels connected to the cloud-based transaction platform and receives communication from an agent terminal over a communication channel connected to the cloud-based transaction platform. The agent terminal communication indicates that the purchase code has been presented to an agent. The cloud-based transaction platform then debits the customer's third party mobile wallet by the specified amount of funds to complete the purchase.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Additional features and advantages will be set forth in the description which follows, and in part will be apparent to one of ordinary skill in the art from the description, or may be learned by the practice of the teachings herein. Features and advantages of embodiments described herein may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the embodiments described herein will become more fully apparent from the following description and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

To further clarify the above and other features of the embodiments described herein, a more particular description will be rendered by reference to the appended drawings. It is appreciated that these drawings depict only examples of the embodiments described herein and are therefore not to be considered limiting of its scope. The embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 illustrates a monetary transaction system architecture in which embodiments described herein may operate.

FIG. 2 illustrates an example embodiment of a cloud-based transaction platform.

FIGS. 3A and 3B illustrate example data flows for performing subscriber-to-subscriber and subscriber-to-non-subscriber eMoney transfers via a mobile wallet, respectively.

FIG. 4 illustrates an example data flow for making a retail purchase using a mobile wallet.

FIG. 5 illustrates an example embodiment of a monetary transaction system architecture.

FIG. 6 illustrates an alternate example embodiment of a cloud-based transaction platform.

FIG. 7 illustrates an example embodiment data flow for performing a transaction using a third party mobile wallet.

FIG. 8 illustrates an example embodiment data flow for performing a transaction using a third party point of sale (POS) system.

FIG. 9 illustrates an example embodiment data flow for making a purchase from a third party mobile wallet provided by a third party mobile wallet provider.

DETAILED DESCRIPTION

Embodiments described herein may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments described herein also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are computer storage media. Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments described herein can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media includes RAM, ROM, EEPROM, CD-ROM, solid state drives (SSDs) that are based on RAM, Flash memory, phase-change memory (PCM), or other types of memory, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions, data or data structures and which can be accessed by a general purpose or special purpose computer.

A “network” is defined as one or more data links and/or data switches that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmission media can include a network which can be used to carry data or desired program code means in the form of computer-executable instructions or in the form of data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a network interface card or “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system. Thus, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize transmission media.

Computer-executable (or computer-interpretable) instructions comprise, for example, instructions which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

Those skilled in the art will appreciate that various embodiments may be practiced in network computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. Embodiments described herein may also be practiced in distributed system environments where local and remote computer systems that are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, each perform tasks (e.g. cloud computing, cloud services and the like). In a distributed system environment, program modules may be located in both local and remote memory storage devices.

In this description and the following claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of “cloud computing” is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

For instance, cloud computing is currently employed in the marketplace so as to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. Furthermore, the shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.

A cloud computing model can be composed of various characteristics such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth. In this description and in the claims, a “cloud computing environment” is an environment in which cloud computing is employed.

Additionally or alternatively, the functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), and other types of programmable hardware.

Still further, system architectures described herein can include a plurality of independent components that each contribute to the functionality of the system as a whole. This modularity allows for increased flexibility when approaching issues of platform scalability and, to this end, provides a variety of advantages. System complexity and growth can be managed more easily through the use of smaller-scale parts with limited functional scope. Platform fault tolerance is enhanced through the use of these loosely coupled modules. Individual components can be grown incrementally as business needs dictate. Modular development also translates to decreased time to market for new functionality. New functionality can be added or subtracted without impacting the core system.

Various terminology will be used herein to describe the cloud-based transaction platform (also referred to as a “monetary transaction system”, “mobile wallet platform”, “mobile wallet program”, “mobile wallet transaction system”, “mobile financial services (mFS) platform” or “electronic payment system”). The term “agent” is used to refer to an individual with mFS transaction system tools and training to support specific mFS functions. These mFS functions include subscriber registration and activation, and the deposit and withdrawal of funds from the mFS transaction system. Agents are representatives of the mFS transaction system or “program”. Agents can be employees or contractors of the program provider, or other companies and organizations that partner with the program provider to provide these services themselves. Agents may be found in every facet of a typical economy, and may include large retailers, mobile network operators (MNO) airtime sales agents, gas stations, kiosks, or other places of business.

The cloud-based transaction platform includes an infrastructure that allows native mobile wallet application and third party mobile wallet applications to interact both with the transaction system and with each other. This allows the user of a native or a third party mobile wallet to make purchases, transfer money or perform any of the other transactions described herein. The cloud-based transaction platform may include a mobile wallet application and a web interface or some other type of functionality that allows the user to interact with the cloud-based transaction platform using their mobile device. The native and third party mobile wallet applications may include a subscriber identity module (SIM) application, an Unstructured Supplementary Service Data (USSD) application, a smartphone application, a web application, a mobile web application, a Wireless Application Protocol (WAP) application, a Java 2 Platform, Micro Edition (J2ME) application, a tablet application or any other type of application or interface that provides tools for the agent to register, activate, and offer other services to the mFS subscriber.

As used herein, a mobile wallet application is a mobile wallet application installed on a SIM card or elsewhere on a mobile device. The mobile wallet application may either be native (i.e. provided by the provider of the cloud-based transaction platform) or third party (i.e. provided by a provider other than the provider of the cloud-based transaction platform).

A USSD application is an application that implements USSD for various functionality including prepaid callback service, location-based content services, menu-based information services and other mobile wallet platform services. A web application is one that implements or uses the internet to provide mobile wallet platform functionality. A mobile web application is similar to a web application, but is tailored for mobile devices. A WAP application is one that uses the wireless application protocol to communicate with the mobile wallet platform to provide the platform's functionality. A J2ME application is an application developed in Java and is designed to provide mobile wallet functionality on a variety of different hardware. A tablet application is an application specifically designed for a touchscreen-based tablet that provides mobile wallet platform functionality for tablet devices. Any of these applications (or any combination thereof) may be provided on the user's mobile device. This functionality can also be made available on a retail point of sale (POS) system or web site. Indeed, the cloud-based transaction platform allows different POS systems to interact with each other and conduct transactions between themselves.

The term “agent administrator” refers to an individual with mFS program tools and training to administrate the allocation of funds to agent branches (e.g. retail locations). As agents perform mFS transactions with subscribers, such as depositing and withdrawing money, the agents are adding and removing money from their own accounts. Any of the applications referred to above may be configured to provide tools used by the agent administrator to view the agent company balance, view the agent branch balances, and transfer funds into and out of agent branch mobile wallets. This functionality can also be made available on a website for easier access.

In some embodiments, the mFS platform application may utilize triple data encryption standard (3DES) encryption (or some other type of encryption), encrypted message signing, and password security on some or all of its communications with the mFS transaction system in order to ensure that the transactions are properly secured and authenticated.

The term “agent branch” refers to any location where an agent provides support for subscriber services of the mFS platform. Funds are allocated by the agent administrator from the agent company's main account to each agent branch to fund the subscriber mFS functions such as depositing or withdrawing cash, in-store purchases, bill payments, prepaid airtime top-ups and money transfers. In some cases, multiple agents may work in a single branch. However, at least in some cases, monetary funds are allocated to from the agent company's main account on a per branch basis.

The term “agent branch account balance” refers to the amount of money residing in a particular agent branch account at a given time. Funds can be deposited into the branch account by the agent administrator, or the funds can come from participating in subscriber mFS transactions such as depositing or withdrawing cash from the subscriber's mobile wallet accounts, or making retail purchases with the mobile wallet.

In some embodiments, in countries with more developed economies, it may be beneficial to use program-issued pre-paid debit cards, pre-paid access accounts, stored value accounts or gift cards to conduct business along with the added convenience of card processing networks such as Cirrus, STAR, or Visa for POS and automated teller machine (ATM) functionality. Agents, particularly those in retail outlets and kiosks, can still support subscribers with deposits, withdrawals, and other transfers, but in this case bank external card processors manage the mobile wallet and branch account balances and provide the real-time transfer of funds.

The term “agent branch ledger” refers to a written (or electronic) ledger maintained by the mFS platform. Agent branch transactions are performed on the agent's and subscriber's mobile phones where an electronic record of the transaction is generated and stored on the mFS platform. These electronic transactions are then reconciled with agent branch ledgers to ensure the security and integrity of the transaction. Agent branch ledgers are printed or electronic transaction logs that are distributed to the agent branch locations in hard copy form to serve as a backup record to the electronic transactions.

The term “agent company” refers to a business that registers to participate in the mFS program as a partner of the mFS program provider or owner. The agent company has one or more agent branches which conduct mFS business with mFS program subscribers. In some cases, the agent company may be referred to as a distributor or retailer.

The term “agent company account balance” refers to the sum of the funds deposited at a “partner bank” (defined below) by the agent company to fund the agent company's daily transactions. The funds in the agent company account are then distributed to agent branches by the agent company's agent administrator to conduct everyday business such as accepting cash deposits and cash withdrawals from mFS subscribers. This balance is sometimes referred to as the “agent company float”.

An “agent manager” is a supervisor of company agents for a given company. The agent manager has the training and tools to create, delete or modify agent accounts for a company, as well as monitor the transactions performed by agents. The agent manager may have a special application or an increased level of rights to access applications features not available to other users. The special application is a program installed on the agent manager's terminal. This application provides the agent manager the ability to securely perform agent manager functions such as registering and activating new agent accounts. The mFS agent manager application may be installed on any terminal or device. It communicates with the mFS platform using binary and/or text SMS messages. A wireless service provider or MNO provides the GSM SMS network infrastructure on which the mFS platform operates.

As subscribers, agents, and other mFS program participants conduct business in the mFS program, value is transferred from one account to the next as payment for services rendered or goods purchased. This value can be in the form of real currency or the electronic representation referred to herein as eMoney. Among other situations, eMoney is used in mFS implementations where the real-time processing of financial transactions including card processing is not practical. The mFS platform utilizes an internal transaction processor for managing the real-time balance of mobile wallet and agent accounts as value (eMoney) is transferred from one mobile wallet to another in payment for services.

The term “mFS program master account” refers to a bank account maintained by the mFS program partner bank to provide funds and float for the operation of the mFS platform. Depending on the type of mFS implementation, the master account can include sub-accounts for each of the agent branches and subscriber mobile wallets, giving the bank visibility into all transactions on a per-user basis. The mFS platform can also manage the balance of sub-accounts and interact with the bank's master account when funds need to be deposited or withdrawn from the account.

The term mobile network operator (MNO) refers to a provider of mobile phone service including basic voice, SMS, unstructured supplementary service data (USSD) and data service, and may also be referred to as a “wireless service provider”.

The term “mobile wallet” or “mobile wallet account” refers to a stored value account or prepaid access account (PPA) that allows the owner (or “subscriber”) to pay for goods and services on the mFS platform from his or her mobile wallet account. When the mFS eMoney transaction processor is used, the mobile wallet balance is maintained by the mFS platform and value is exchanged within the mFS program as eMoney. When the mFS platform is integrated to an external card processor, the mobile wallet utilizes funds from the subscriber's prepaid debit card and bank account to exchange value on the mFS platform.

The term “partner bank” refers to the primary bank participating in the mFS program. The partner bank is responsible for holding the mFS program master accounts that hold the funds for all mFS services and transactions. A “PIN” refers to a numeric password that may be required to perform a transaction via the mobile wallet application.

The term “subscriber” refers to a participant of the mFS mobile wallet platform. The subscriber maintains a mobile wallet balance and performs transactions using the mFS application. An “unbanked subscriber” is a subscriber that does not have (or does not have access to) a bank account or credit union account. The application or “mobile wallet application” provides mobile wallet functionality to the (unbanked) subscriber. The mobile wallet application is installed on a mobile device in the device's memory, on a SIM card (such as a GSM SIM card) or is otherwise accessible to the mobile device. The mobile wallet application provides the subscriber the ability to securely perform subscriber functions such as making retail purchases, paying bills, or transferring money to other mFS subscribers and non-subscribers. The mobile wallet application communicates with the mFS platform using binary and text SMS messages, among other forms of wireless communication. A wireless service provider or MNO provides the GSM network infrastructure on which the mFS platform operates.

FIG. 1 illustrates an example system architecture for a cloud-based transaction platform. Integration tier 101 is configured to manage mobile wallet sessions and maintain integrity of financial transactions. Integration tier 101 can also include a communication (e.g., Web services) API and/or other communication mechanisms to accept messages from channels 111. Other mechanisms include, but are not limited to: International Standards Organization (“ISO”) 8583 for Point of Sale (“POS”) and Automated Teller Machines (“ATM”) devices and Advanced Message Queuing Protocol (“AMQP”) for queue based interfaces. Each of channels 111 can be integrated to one or more mechanisms for sending messages to integration tier 101. Notification services 102 is configured to send various notifications through different notification channels 112, such as, for example, Short Message Peer-to-Peer (“SSMP”) for Short Messaging Service (“SMS”) and Simple Mail Transfer Protocol (“SMTP”) for emails. Notification services 102 can be configured through a web services API.

Service connectors 103 are a set of connectors configure to connect to 3rd party systems 113. Each connector can be a separate module intended to integrate an external service to the system architecture. Business process services 104 are configured to implement business workflows, including executing financial transactions, auditing financial transactions, invoking third-party services, handling errors, and logging platform objects. Payment handler 105 is configured to wrap APIs of different payment processors, such as, for example, banking accounts, credit/debit cards or processor 121. Payment handler 105 exposes a common API to facilitate interactions with many different kinds of payment processors.

Security services 106 are configured to perform subscriber authentication. Authorization services 107 are configured to perform client authorization, such as, for example, using a database-based Access Control List (“ACL”) table.

Database 108 is configured to manage customer accounts (e.g., storing customer accounts and properties), manage company accounts (e.g., storing company accounts and properties), manage transaction histories (e.g., storing financial transaction details), store customer profiles, storing dictionaries used by the mobile wallet platform, such as, for example, countries, currencies, etc., and managing money containers. Rules engine 109 is configured to gather financial transaction statistics and uses the statistics to provide transaction properties, such as, for example, fees and bonuses. Rules engine 109 is also configured to enforce business constraints, such as, for example, transactions and platform license constraints.

Name matching engine 110 is configured to match different objects according to specified configuration rules. Matching engine 110 can be used to find similarities between names, addresses, etc. Transaction processor 121 is configured to manage financial accounts and transactions. The transaction processor 121 can be used to hold, load, withdraw and deposit funds to mobile wallet accounts. Transaction processor 121 can also be used as a common interface to a third party processor system. When used as a common interface, financial operations may be delegated to the external processor. A Clearing House subsystem of transaction processor 121 can be used to exchange the financial information with a bank.

Components of a mobile wallet platform can be connected to one another over (or be part of) a system bus and/or a network. Networks can include a Local Area Network (“LAN”), a Wide Area Network (“WAN”), and even the Internet. Accordingly, components of the mobile wallet platform can be “in the cloud”. As such, mobile wallet platform components as well as any other connected computer systems and their components, can create message related data and exchange message related data (e.g., Internet Protocol (“IP”) datagrams and other higher layer protocols that utilize IP datagrams, such as, Transmission Control Protocol (“TCP”), Hypertext Transfer Protocol (“HTTP”), Simple Mail Transfer Protocol (“SMTP”), etc.) over the system bus and/or network.

The components depicted in FIG. 1 can interoperate to provide a number of financial and other services including but not limited to enrolling a customer for a mobile wallet, adding a stored value account (either hosted by a mobile wallet platform or a third party), adding a bank or credit union account to a third party mobile wallet, adding a debit or credit card account to a third party mobile wallet, depositing funds in a third party mobile wallet, withdrawing funds from a third party mobile wallet, paying bills from a third party mobile wallet, topping up a prepaid mobile account through a third party mobile wallet, transferring funds through a third party mobile wallet (nationally or internationally), making in-store purchases using a third party mobile wallet, selecting health care providers and paying for health care services, paying for music, games, movies or other downloadable provided by a third party provider and made available over the cloud-based transaction system, and various other tasks as described herein below.

FIG. 2 depicts a monetary transaction architecture 200 similar to that described in FIG. 1. The monetary transaction architecture 200 may provide a more simplified system structure in which each of the above services may be provided. The system includes a subscriber 205. The subscriber may have access to a bank account, or may be an unbanked subscriber. The subscriber has a profile 211 with the cloud-based transaction system 210. The profile includes the subscriber's know your customer (KYC) information, as well as any associated bank accounts, credit union accounts, bill pay accounts or other accounts. The subscriber has (or has access to) a mobile device 206 such as a phone or tablet. The mobile device runs the native or third party mobile wallet application 207.

The subscriber can indicate, using the mobile wallet application 207, which transaction or other action he or she would like to perform. The indicated transaction 208 is sent to the mobile wallet platform 210 to be carried out by the platform. The transaction processor 216 (which may be similar to or the same as transaction processor 121 of FIG. 1) performs the transaction(s) specified by the (unbanked) subscriber 205. The transaction processor may implement various other components to perform the transaction including memory 217, (wireless) communication module 215, rules engine 220 and/or a transaction database 225.

Performing the specified transactions may include communicating with the monetary transaction database 225 to determine whether the transaction is permissible based on data indicated in the unbanked subscriber's profile (for instance, whether the subscriber has enough eMoney 221 in his or her stored value account, or has enough money in his or her bank account). Rules engine 220 may also be consulted to determine whether the subscriber has exceeded a specified number of allowed transactions. Then, if funds are available, and the transaction is otherwise permissible, the monetary transaction system can transfer money or eMoney 221 to or from an entity such as a user or agent (e.g. customer 222) to or from an establishment such as an agent terminal (i.e. a retail store or agent company) 223.

In some cases, the cloud-based transaction system 210 provides a web interface that allows subscribers of third party mobile wallet applications to perform the same functions provided for native subscribers. For instance, mobile wallet application 207 may provide a web interface that allows a user to enroll for a native or third party mobile wallet. The web interface (or the mobile wallet application itself) receives a subscriber-initiated transaction over one of a plurality of communication channels (111 from FIG. 1) connected to the cloud-based transaction system 210. The web interface or mobile wallet application may prompt for and receive enrollment information (e.g. KYC information) for the (unbanked) subscriber 205 over at least one of the plurality of communication channels (e.g. web, point-of-sale (POS), interactive voice response (IVR, etc.). The web interface or mobile wallet application may then send activation instructions over the same or a different channel to activate the (unbanked) subscriber 205 and create a subscriber account for the (unbanked) subscriber.

Once the subscriber has an account, the cloud-based transaction system generates (or allows the third party provider to generate) a corresponding mobile wallet for the unbanked subscriber (available via the web interface and/or the mobile wallet application). The system then presents the (unbanked) subscriber's account data associated with the mobile wallet and/or a notification indicating that enrollment was successful to the subscriber. Accordingly, the mobile wallet application or the web interface may be used to provide user enrollment functionality. It should also be understood that either the mobile wallet application or the web interface may be used to provide substantially all of the third party or native mobile wallet functionality described herein.

It should also be noted that the mobile device 206 may be any type of plan-based phone or tablet, or prepaid phone or tablet. Many subscribers, such as unbanked subscribers, may primarily use prepaid phones. The mobile wallet application 207 may be installed on both plan-based phones and prepaid phones. The mobile wallet application may be installed on the device's SIM card, or on the device's main memory. Accordingly, the monetary transaction system 200 may be accessed and used via substantially any type of plan-based or prepaid mobile device.

The components depicted in FIG. 1 can interoperate to provide a number of financial and other services including but not limited to enrolling a customer for a third party mobile wallet, adding a stored value account (either hosted by an electronic payment system or a third party), adding a bank/credit union account to a third party mobile wallet, adding a debit/credit card account to a third party mobile wallet, depositing funds in a third party mobile wallet, withdrawing funds from a third party mobile wallet, paying bills from a third party mobile wallet, topping up a prepaid mobile account through a third party mobile wallet, transferring funds through a third party mobile wallet, making in store purchases from a third party mobile wallet, or transferring money or eMoney from one business account to another business account (i.e. from one business's mobile vault to another business's mobile vault, as will be shown in FIG. 4).

FIG. 3A depicts a subscriber-to-subscriber eMoney transfer. In a merchant and distributor scenario, either or both of the merchant and the distributor (including any delivery personnel) may be subscribers. To perform such a transfer, subscriber A (301) enters some type of identification information identifying subscriber B (e.g. subscriber B's phone number) and an amount of money he or she wishes to transfer. The transaction processor 216 of the monetary transaction system 210 determines if there are sufficient funds to complete the transfer. If sufficient funds are available, the monetary transaction system 210 decrements subscriber A's account and credits subscriber B's account (302). The system then sends some kind of notification (e.g. SMS) to subscriber B indicating that a certain amount of money was transferred to their account. Subscriber A may also receive a notification that the transfer was successful. Accordingly, eMoney may be transferred between two cloud-based platform subscribers, one or both of which may be unbanked. The cloud-based transaction system 210 processes the subscribers' requests, updates the subscribers' eMoney balances, logs the transactions, and sends transaction information to a specified bank when needed.

FIG. 3B illustrates a subscriber-to-non-subscriber eMoney transfer. Accordingly, as mentioned above, either or both of the merchant and the distributor may be non-subscribers. In graphic 305, subscriber A wishes to send eMoney to another individual that is not a subscriber to the cloud-based transaction platform. The transaction is initiated in the same fashion as the subscriber-to-subscriber transfer scenario. However, since non-subscriber B does not have a mobile wallet account, the cloud-based transaction system 210 cannot credit them with eMoney. Instead, the cloud-based transaction system 210 sends a notification (e.g. via SMS) to non-subscriber B with instructions for how to pick-up the transferred money, along with an authorization code (306). The cloud-based transaction system 210 puts a hold on subscriber A's account for the amount transferred. Subscriber B then has a specified number of days to pick up the cash before the hold expires and the amount is credited back to subscriber A's eMoney account by the monetary transaction system 210.

When non-subscriber B goes to pick up the money at an agent branch, the agent branch's manager or agent verifies the authorization code via an agent manager or agent mobile wallet application (that, in turn, accesses the cloud-based transaction platform). Once the transfer has been validated, the agent gives the cash to non-subscriber B. The agent branch's mFS account is credited with the transfer amount (307) and the user leaves with the cash in hand (308). The cloud-based transaction platform processes the transfer request, updates subscriber A's eMoney balance, logs the transaction, and sends transaction details to a platform-specified bank.

FIG. 4 illustrates a mobile wallet subscriber making a retail purchase. Mobile wallet subscribers can make retail purchases at agent branches directly from their mobile device. Agent branches, as explained above, are retail stores or other entities that have registered with the cloud-based transaction platform and are able to accept native and third party mobile wallet payments. Accordingly, a subscriber can select the items they wish to purchase, and indicate (via the mobile wallet application) to the agent branch that they wish to pay for the items. The mobile wallet application then communicates with the agent branch and the monetary transaction system to indicate the price of the transaction. The monetary transaction system 210 then debits the subscriber's eMoney account (401) and credits the agent branch's eMoney account (402). The agent branch (and/or the agent manager or agent) receives confirmation that subscriber paid for the purchase. The subscriber may also receive a summary of the retail purchase and may be asked to confirm the purchase by entering a PIN. The monetary transaction system processes the purchase request, updates the agent branch and subscriber's eMoney balances, logs the transaction, and sends transaction details to a cloud-based transaction platform-specified bank.

In one embodiment, the cloud-based transaction system 210 is implemented to make a purchase from a mobile wallet. The communications module 215 of the monetary transaction system 210 receives a communication from a subscriber over a communication channel 111. The subscriber communication indicates that an unbanked subscriber 205 desires to purchase an item for a specified amount of funds using a specified payment method from the unbanked subscriber's native or third party mobile wallet.

The monetary transaction system 210 then returns a secure, perishable purchase code to the unbanked subscriber over at least one of the channels connected to the monetary transaction system and receives a subsequent agent branch communication over a channel indicating that the purchase code has been presented to an agent (branch). The monetary transaction system 210 validates the status of the specified payment method, determines if the specified payment method can accommodate a purchase for the specified amount, performs a limit check and/or a velocity check on the selected payment method, debits the specified payment method by the specified amount of funds, returns a notification to the agent branch authorizing the purchase and sends a receipt to the unbanked subscriber over a communication channel. The cloud-based transaction system 210 may thus be used in this manner to make a retail purchase using a native or third party mobile wallet.

FIG. 5 depicts a physical environment and corresponding computer system architecture 500 for allowing a user to participate in various services using a native or third party mobile wallet (e.g. 511). Some of these services include allowing the user 507 to access disruptively priced or free financial services or items in exchange for participation in opt-in advertising. The environment 500, like the scenarios described in FIGS. 3A, 3B and 4, involves the use of a native or third party mobile wallet application 511. The mobile wallet application 511 can be used to provide disruptively priced or free financial services or items in exchange for participation in opt-in advertising. The mobile wallet application may be run on any type of digital device including a mobile phone, tablet, laptop or other digital device. Embodiments include providing digital data (e.g., coupons or vouchers) for obtaining disruptively priced or free items (e.g., consumer goods or groceries) to such digital devices.

In some embodiments, a user has an account with a mobile payment system. The cloud-based transaction system (e.g. 210 of FIG. 2 or electronic payment system 521 of FIG. 5) can provide the user 507 with a variety of functionality including purchasing items (see FIG. 4), depositing funds, withdrawing funds, transferring funds (see FIGS. 3A and 3B), and others all from a third party wallet. Accordingly, the user can use a digital device to interact with the electronic payment system 521 to pay for goods and/or services.

In exchange for some type of financial benefit, the user opts in to receive advertisements. The financial benefits may include coupons, vouchers, promotions, Buy One Get One (“BOGO”) offers or any other type of benefit (such as a reduced cost or free financial service or good) from the electronic payment system. The benefit may be targeted to the user based on the user's age, location or other demographic information, or based on the user's past purchases. At least in some embodiments, when the user agrees to participate in opt-in advertising, the electronic payment system 521 is permitted to store (e.g., by capturing purchase orders), track, and analyze items that the user purchases through their account with the electronic payment system. The electronic payment system stores and maintains lists of the users' purchased items in a data warehouse. The electronic payment system may also store information about the user (anonymous or otherwise) including age, income level, an indication of whether kids are in the family, or other information that may be useful in targeting ads or benefits to the user.

The electronic payment system analyzes 534 the users purchasing habits to identify advertisements and/or promotions that may be of interest to the user. The advertisements and/or promotions can be for items the user has purchased 503. The advertisements and/or promotions can also be for items related to items the user has purchase. For example, if user has purchased a particular brand of razor, advertisements for the brand's shaving cream can be identified. Advertisements for related items can also be used for cross-promotion.

From time to time, at specified intervals, or based on location (e.g., having a coupon for a merchant this is with a specified proximity) the electronic payment system sends identified advertisements and/or promotions to the user's digital device. When specified advertising thresholds are satisfied (e.g., a specified number and/or type of advertisements and/or promotions are presented), the electronic payment system confers a financial benefit on the user's account. For example, the electronic payment system can provide the user's account with a low cost (e.g., reduced fee) or free financial service, such as, for example, one reduced cost bill pay or one free bill pay. Alternately, the electronic payment system can provide the user's account with a coupon or voucher for an item (e.g., an item a user has pre-selected or an item the user has purchased in the past).

In some embodiments, a client application for the electronic payment system runs on the user's digital device (e.g. mobile wallet application 511). The user interacts with the electronic payment system through the client application. From a screen of the client application, the user can agree to accept opt in advertising. Accordingly, embodiments of the invention essentially permit a user to self-monetize themselves through their digital device.

As further depicted in FIG. 5, computer architecture 500 includes digital device 508, retail location 502, and electronic payment system 521. Digital device 508 further includes mobile wallet application 511. Retail location 502 further includes its own mobile wallet application 512. Electronic payment system 521 includes marketing module 533, data warehouse 532, advertisements 538, payment processor 522, user mobile wallet 524 (user 507's mobile wallet), and merchant mobile wallet 526 (retail location 502's mobile wallet).

Generally, each company in packaged goods companies 571 (or retailers that sell the packaged goods or other goods or services) can send advertisement data to electronic payment system 521. Advertisements 538 represent the collection of advertisement data sent from packaged goods companies 571. Each company in packaged goods companies 571 can also submit benefit rules to electronic payment system 521. Benefit rules 578 represent the collection of benefit rules sent from packaged goods companies 571. Benefit rules 578 define when a benefit, such as, for example, a free financial service, a coupon, a promotion, etc, is to be granted to a user of electronic payment system 521. For example, in response to completing a questionnaire linked to a product advertisement, a user can be given a coupon for the product or for a related product.

In general, user 507 can use native or third party mobile wallet application 511 to pay for goods purchased at retail location 502 (as shown in FIG. 4). For example, user 507 can use mobile wallet application 511 to purchase goods 503. To pay for goods 503, mobile wallet application 511 can send payment instruction 543 in amount 563 to electronic payment system 521. Payment processor 522 can receive payment instruction 543. In response, payment processor 522 can debit 541 user mobile wallet 524 by amount 563. Payment processor 522 can also credit 542 merchant mobile wallet 526 by amount 563.

User 507 can use mobile wallet application 511 to participate in opt-in advertising. For example, user 507 can use mobile wallet application 511 to send opt-in 544 to electronic payment system 521. Advertising module 533 can receive opt-in 544 and record that mobile wallet application 511 has opted in for advertising. As such, when user 507 makes a purchase using mobile wallet application 511, a list of purchased items is sent to electronic payment system 521. For example, upon purchasing goods 503, item list 531 is sent to electronic payment system 521 and stored in data warehouse 532.

Propensity analysis module 534 can analyze user 507's purchases, including item list 531. From the analysis, propensity analysis module 534 can identify items or categories of items user 507 may be interested in. The items can be items user 507 has purchased in the past (e.g., an item in goods 503) or items related to items user 507 has purchases in the past. Propensity analysis module 534 can indicate identified items or categories of items to advertisement identification module 536. These identified items or categories are items that the user is likely interested in and, as such, may have a propensity toward buying these items. The propensity analysis module may use past purchases, personal preferences, lifestyle or demographic information or other data in the propensity analysis.

Advertisement identification module 536 can then select advertisements from advertisements 538 that correspond to the identified items or categories of items. For example, advertisement identification module 536 can select advertisement 546 for presentation at mobile wallet application 511. Advertisement 546 can be an advertisement for a product made by a company in packaged goods companies 571. Additionally or alternatively, the advertisement 546 may be created by the merchant and may advertise products or services sold by that merchant.

Advertising module 533 can send selected advertisements to mobile wallet application 511. For example, advertising module 533 can send advertisement 546 (e.g., related to an item in goods 503) to mobile wallet application 511. In general, advertisements can include interactive content. For example, advertisement 546 includes content 573. Content 573 can be a video, a link to a company website (e.g., for a company in packaged goods companies 571), a call to action (such as a questionnaire), or some other content user 507 can interact with through digital device 508. User 507 can interact with content 573, for example, responding to questions in content 573. Advertisement response 574 can indicate how user 507 has interacted with content 573. In one embodiment, a call to action may be to post an update on Facebook® or some other website such as a retail establishment ranking website. If the user makes such a post or performs some other call to action, the user may be rewarded with a benefit. That benefit may be related to the product about which the user posted on the various websites.

Based on advertisement response 574, benefit determination module 576 can determine if a benefit is to be conferred upon user 507. Benefit determination module 576 can refer to benefit rules 578 when making a determination whether or not to confer a benefit. Thus, when user 507 interacts with advertisement 546 in a specified way (e.g., completes a survey, watches a video, etc.), benefit rules 578 can indicate that a company benefit (e.g., benefit 577) is to be conferred upon user 507. For example, benefit determination module 576 can confer benefit 577 on user 507. When user 507 receives an advertisement for a razor, for instance, and answers a questionnaire on how often they shave, a razor manufacture can give user 507 a coupon for reduced cost or free razor blades.

When a benefit is to be conferred on a user, the benefit can be stored in the user's brand locker. For example, benefit determination module 576 can store benefit 577 in brand locker 572 (part of user mobile wallet 524). Benefit 577 can be a coupon, a reduced cost or free financial service, a voucher, a promotion, a free bill pay, etc.

Benefit determination module 576 can also track aggregate statistics, such as, for example, specified number and/or type of advertisements received, for advertisements presented at native or third party mobile wallet application 511. Benefits can also be conferred upon users based on the aggregate statistics. For example, benefit determination module 576 can confer a benefit upon user 507 in response to twenty advertisements being presented at mobile wallet application 511. Thus, conferred benefits can be company-specified benefits or can be electronic payment system-specified benefits. Electronic payment system 521 can notify a user when a benefit is conferred. For example, electronic payment system 521 can send benefit notification 547 to mobile wallet application 511 to indicate benefit 577 being stored in brand locker 572.

When user 507 makes subsequent purchases through user mobile wallet 524, electronic payment system 521 can automatically check brand locker 572 for benefits related to any purchases items. If benefits for an item are identified, user 507 can be notified through mobile wallet application 511. In some cases, if benefits are identified, those benefits can be applied automatically when the user purchases that item or service. Thus, if the benefit is a coupon or a buy one get one free offer, that benefit may be applied automatically when the user uses his or her mobile wallet application 511 to purchase that item. Accordingly, embodiments of the invention permit user 507 to self monetize digital device 508 through agreeing to participate in opt-in advertising.

Although not depicted, various other modules from the architecture of FIG. 1 or 2 can also be included electronic payment system 521. The modules expressly depicted in FIG. 5 can interoperate with these other modules as appropriate to facilitate desired functionality.

FIGS. 7-9 will now be described in conjunction with the computer architecture 600 illustrated in FIG. 6. FIG. 6 depicts a mobile wallet platform 601 that may have an architecture as shown in FIG. 1. As further depicted in FIG. 6, mobile wallet platform 601 communicates with an agent terminal 602 or a customer 607 to process transactions using a native or third party mobile wallet 605. Mobile wallet platform 601 may also communicate with a third party processor 604 to process transactions using a mobile wallet or third party mobile wallet. Mobile wallet platform 601 may also communicate with a third party mobile wallet platform 603 to process transactions using a mobile wallet owned or managed by a third party mobile wallet provider.

Mobile wallet platform 601 may also process the mobile wallet transaction or third party mobile wallet transaction internally, without the use of third party processors or third party mobile wallet platforms. In particular, mobile wallet platform 601 may process transactions using third party mobile wallets in the same or similar manner that transactions are processed as shown in FIGS. 2-5. Accordingly, the physical environment and corresponding computer system architecture 600 shown in FIG. 6 allows a cloud-based transaction platform 601 to support multiple third party mobile wallet providers.

Mobile wallet platform 601 communicates with agent terminal 602, third party mobile wallet platform 603, third party processor 604, and customer's mobile phone 619 through a variety of communication channels. For example, the communication between mobile wallet platform 601 and any one of these entities may be through communication channels 111, notification channels 112, or third party systems 113, as shown in FIG. 1. Communication between mobile wallet platform 601 and any one of these entities may also be through processor 121 shown in FIG. 1.

With respect to the entire description of FIG. 6, and as explained above, the term “mobile wallet” encompasses not only mobile wallets owned or managed by the mobile wallet platform, but also third party mobile wallets owned by third party mobile wallet providers or managed by third party mobile wallet platforms. In contrast, the term “third party mobile wallet” refers only to third party mobile wallets owned by third party mobile wallet providers or managed by third party mobile wallet platforms. Accordingly, cloud-based transaction platform 601 may manage and process transactions using mobile wallets 605, which may be mobile wallets owned by cloud-based transaction platform 601 or mobile wallets owned by a third party mobile wallet provider.

As shown in FIG. 6, customer 607 initiates a mobile wallet transaction 608 at agent terminal 602. Agent terminal 602 may be part of an agent network consisting of one or more agent terminals that communicate with cloud-based transaction platform 601. Examples of agent terminals are stores and other commercial establishments. Alternatively, customer 607 may initiate a mobile wallet transaction 609 by communicating with cloud-based transaction platform 601 through a channel selected by the customer.

Mobile wallet transactions 608 and 609 may be one or more of any type of transaction that can be performed using a mobile wallet, including but not limited to, a deposit, withdrawal, transfer, purchase, bill payment, topping up of a prepaid mobile account, or any other transaction described herein. Customer 607 may initiate transactions 608 and 609 in a variety of ways. For example, customer 607 can initiate a deposit into a mobile wallet, a withdrawal from a mobile wallet, a bill payment from a mobile wallet, topping up of a prepaid mobile account using a mobile wallet, a transfer from a mobile wallet, a remittance transaction, a selection of health care provider or payment of health services, a purchase of music, movies, games or other downloadable content, or other purchases using a mobile wallet.

After customer 607 initiates transaction 609 through agent terminal 602, agent terminal 602 then communicates with cloud-based transaction platform 601 by sending transaction data 610 to cloud-based transaction platform 601. Once cloud-based transaction platform 601 has received the transaction either through transaction data 610 from agent terminal 602 or from transaction 609 initiated by customer 607, cloud-based transaction platform 601 may then process the transaction in a variety of ways.

For example, cloud-based transaction platform 601 may process the transaction by communicating with third party processor 604 by sending third party transaction data 611, which may include some or all of the information in transaction data 610. Third party processor can then perform the requested transactional processing and respond by sending confirmation data 612 to cloud-based transaction platform 601. Confirmation data 612 can indicate whether the requested mobile wallet transaction was processed successfully or unsuccessfully.

In another example, cloud-based transaction platform 601 may process the transaction by communicating with third party mobile wallet platform 603 by sending third party transaction data 613, which may include some or all of the information in transaction data 610. Third party mobile wallet platform 603 may have any architecture which is suitable for processing mobile wallet transactions. Third party mobile wallet platform 603 may have an architecture that is the same or similar to the architecture shown in FIG. 1.

Alternatively, third party mobile wallet platform 603 may have a different architecture. In addition, any aspects of cloud-based transaction platform 601 or functionality provided by that platform may also be present in third party mobile wallet platform 603. After receiving third party transaction data 613, third party mobile wallet platform 603 may process the transaction itself or forward the transaction to third party processor 604 by sending third party transaction data 614.

Once processing of the transaction is complete, third party mobile wallet platform 603 may respond to cloud-based transaction platform 601 by sending confirmation data 615. Confirmation data 615 can indicate whether the requested mobile wallet transaction was processed successfully or unsuccessfully. In addition, following the processing performed by third party mobile wallet platform 603 after receiving third party transaction data 613, the third party mobile wallet platform 603 may provide a commission or transaction fee 616 to cloud-based transaction platform 601.

In a further example, mobile wallet platform 601 may process the transaction internally within cloud-based transaction platform 601. Specifically, cloud-based transaction platform 601 may process a transaction using a third party mobile wallet entirely within cloud-based transaction platform 601.

Once processing of the transaction is complete, cloud-based transaction platform 601 may communicate with agent terminal 602 by sending confirmation data 617 indicating information such as whether the transaction was successful or not. Also following processing of the transaction, mobile wallet platform may send customer notification 618 through an appropriate channel such as to the customer's mobile phone 619. For example, customer notification 618 may be sent using the notification services 102 and notification channels 112 (e.g. SMPP, SMTP, voice) of FIG. 1.

With reference now to FIGS. 2, 6 and 7, the cloud-based transaction system 210 receives communication 226 from an agent terminal 223 over a communication channel connected to the cloud-based transaction platform 210/601 (act 710). The agent communication indicates that a customer 222/205 desires to perform a mobile wallet transaction using their third party mobile wallet 207. The cloud-based transaction system 210 sends the agent communication to a third party mobile wallet platform 603 (act 720). The cloud-based transaction system 210 then receives communication 611 from the third party mobile wallet platform confirming processing of the transaction 612 (act 730) and sends communication 617 to the agent terminal 602 over communication channels 111 connected to the cloud-based transaction platform indicating confirmation of the processing of the transaction (act 740).

As mentioned above, multiple different types of transactions may be performed using the infrastructure provided by the cloud-based transaction system. The transactions may be a performed not only by a first customer that uses a first mobile wallet provider, but also by a second, different customer using a second, different third party mobile wallet provider. The third party mobile wallet platform may use a third party processor to perform (at least parts of) the transaction. The customer may be notified of confirmation of the processing of the transaction using the third party mobile wallet over various communication channels connected to the cloud-based transaction platform. In some cases, each third party mobile wallet provider has their own point of sale (POS) processing system 230. The third party mobile wallet providers' POS processing systems may communicate with each other using the cloud-based transaction platform to process the transaction.

One of the transactions made possible by the cloud-based transaction platform 601 is depositing funds into a third party mobile wallet owned by an entity different than the customer. The cloud-based transaction system may receive a communication 226 from the agent terminal 223 over a communication channel connected to the cloud-based transaction platform. The agent communication indicates that the customer desires to deposit a specified amount of funds into their third party mobile wallet 605. The cloud-based transaction system may then credit the third party mobile wallet with the specified amount of funds.

Another transaction provided by the cloud-based transaction platform 601 is withdrawing funds from a third party mobile wallet owned by an entity different than the customer. The cloud-based transaction platform receives communication 208 from the customer 205 indicating that the customer desires to withdraw a specified amount of funds from the third party mobile wallet. The cloud-based transaction platform 601 returns a secure, perishable withdrawal code to the customer over at least one of the communication channels connected to the cloud-based transaction platform. It also receives communication from the agent terminal 223 indicating that the withdrawal code has been presented to an agent and debits the third party mobile wallet by the specified amount of funds.

Another transaction provided by the cloud-based transaction platform 601 is transferring money from a third party mobile wallet within the cloud-based transaction platform to a recipient at a second third party mobile wallet provided by a second mobile wallet provider. In this transaction, the platform 601 receives a customer communication 208 indicating that a customer 205 desires to transfer a specified amount of funds to a specified recipient using a specified payment method from the third party mobile wallet 606. The cloud-based transaction platform debits the third party mobile wallet by the specified amount of funds and transfers the specified amount of funds from the cloud-based transaction platform to the second different third party mobile wallet platform for delivery to the specified recipient. The specified amount of funds is then transferred to the second third party mobile wallet platform.

Yet another transaction provided by the cloud-based transaction platform 601 is making a purchase from a third party mobile wallet managed by a third party mobile wallet platform. In this transaction, the cloud-based transaction platform receives communication 208 from the customer 205 indicating that the customer desires to purchase an item for a specified amount of funds using a specified payment method from the customer's third party mobile wallet 606. The cloud-based transaction platform returns a secure, perishable purchase code to the customer, receives communication 226 from the agent terminal 223 indicating that the purchase code has been presented to an agent, and debits the customer's third party mobile wallet by the specified amount of funds.

In another embodiment, as shown in FIG. 8, a cloud-based transaction system performs or facilitates a transaction using a third party point of sale (POS) system. The cloud-based transaction system receives communication 226 from a specified POS system 224 implemented at an agent terminal 223 over a communication channels 111 connected to the cloud-based transaction platform 210 (act 810). The POS communication indicates that a customer 205 has initiated a mobile wallet transaction using their third party mobile wallet 207. The cloud-based transaction system sends the POS communication to a corresponding third party POS transaction processing system 230 that has been established to process POS transactions from the specified POS system (act 820). The cloud-based transaction system then receives communication from the third party POS transaction processing system 230 confirming processing of the transaction (act 830) and sends communication to the specified POS system 224 implemented at the agent terminal 223 indicating confirmation of the processing of the transaction (act 840).

In some cases, transaction fees or commissions 616 may be paid by the third party mobile wallet platform to the cloud-based transaction platform for facilitating the transaction. One of the transactions allowed by the cloud-based transaction system is depositing funds into a third party mobile wallet provided by a third party mobile wallet provider. In this transaction, the cloud-based transaction platform 210 receives communication 226 from a specified POS system 224 implemented at the agent terminal 223 over a communication channels 111 connected to the cloud-based transaction platform. The POS communication indicates that the customer 205/222 desires to deposit a specified amount of funds into the third party mobile wallet 606 provided by the third party mobile wallet provider. The cloud-based transaction system validates the status of the third party mobile wallet provided by the third party mobile wallet provider, determines if the specified POS system implemented at the agent terminal is authorized to deposit money, performs a limit check or a velocity check on the third party mobile wallet provided by the third party mobile wallet provider, credits the third party mobile wallet provided by the third party mobile wallet provider with the specified amount of funds, returns a notification to the specified POS system implemented at the agent terminal confirming the deposit and notifies the customer that the specified amount of funds were deposited in the third party mobile wallet provided by the third party mobile wallet provider over a communication channel connected to the cloud-based transaction platform 210.

Another transaction provided by the cloud-based transaction platform 210 is withdrawing funds from a third party mobile wallet provided by a third party mobile wallet provider. The cloud-based transaction platform 210 receives communication 208 from a customer 205 indicating that the customer desires to withdraw a specified amount of funds from the third party mobile wallet 606 provided by the third party mobile wallet provider. The cloud-based transaction platform 210 validates the status of the third party mobile wallet provided by the third party mobile wallet provider, determines if the balance of the third party mobile wallet provided by the third party mobile wallet provider is sufficient to accommodate the requested withdrawal for the specified amount of funds, performs a limit check and/or a velocity check on the third party mobile wallet, returns a secure, perishable withdrawal code to the customer over a communication channel 111 connected to the cloud-based transaction platform, receives subsequent POS communication 226 indicating that the withdrawal code has been presented to an agent (e.g. at agent terminal 223), debits the third party mobile wallet provided by the third party mobile wallet provider by the specified amount of funds, returns a notification to the POS system at the agent terminal confirming the withdrawal and notifies the customer 205 (e.g. in confirmation 617) that the specified amount of funds were withdrawn from the third party mobile wallet.

In yet another transaction provided by the cloud-based transaction platform, money is transferred using a third party mobile wallet provided by a third party mobile wallet provider. The cloud-based transaction platform 210 receives customer communication 208 indicating that the customer 205 desires to transfer a specified amount of funds to a specified recipient having a third party mobile wallet 606, where the transfer uses a specified payment method from the customer's third party mobile wallet at the cloud-based transaction platform 210. The cloud-based transaction platform validates the status of the specified payment method, performs a limit check and/or a velocity check on the specified payment method, performs a check on the specified recipient having a third party mobile wallet to comply with the office of foreign assets control, debits the customer's mobile wallet at the cloud-based transaction platform by the specified amount of funds, transfers the specified amount of funds to third party mobile wallet provider for delivery to the third party mobile wallet of the specified recipient over a communication channel connected between the cloud-based transaction platform and the third party mobile wallet provider, and notifies the customer that the specified amount of funds was transferred to the specified recipient.

In another transaction provided by the cloud-based transaction platform 210, a purchase is made from a third party mobile wallet provided by a third party mobile wallet provider. In this transaction, the cloud-based transaction system receives communication 208 from the customer 205 indicating that the customer desires to purchase an item for a specified amount of funds using a specified payment method from the customer's third party mobile wallet 606. The cloud-based transaction system returns a secure, perishable purchase code to the customer, receives subsequent agent terminal communication indicating that the purchase code has been presented to an agent, validates the status of the specified payment method, determines if the specified payment method can accommodate a purchase for the specified amount, performs a limit check and/or a velocity check on the specified payment method, debits the customer's third party mobile wallet by the specified amount of funds by sending communication to the third party mobile wallet provider, returns a notification to the POS system at the agent terminal authorizing the purchase and sends a receipt to the customer over at least one of the plurality of communication channels connected to the cloud-based transaction platform.

FIG. 9 describes a further embodiment in which a cloud-based transaction platform facilitates making a purchase from a third party mobile wallet provided by a third party mobile wallet provider. The cloud-based transaction system 210 receives communication 208 from a customer 205 over a communication channel connected to the cloud-based transaction platform (act 910). The customer communication indicating that a customer desires to purchase an item for a specified amount of funds using a specified payment method indicated by the customer's third party mobile wallet 606. The cloud-based transaction system returns a secure, perishable purchase code to the customer (act 920) and receives communication from an agent terminal 223 over at least one of the communication channels connected to the cloud-based transaction platform indicating that the purchase code has been presented to an agent (act 930). The cloud-based transaction system 210 then debits the customer's third party mobile wallet 606 by the specified amount of funds (act 940).

Substantially any item may be purchased using this transaction technique including items provided directly by the cloud-based transaction system, or items provided by third party retailers through the cloud-based transaction system. These items may include health care services, physical, shippable items, music, games, movies or any other digital or downloadable content.

Embodiments of the invention can adhere to Know Your Customer (KYC) rules in the United States by performing Customer Identification Program (CIP) checks as required by the Bank Secrecy Act and U.S. PATRIOT Act. A minimum amount of information can be gathered about a customer, such as, for example, First Name, Last Name, Date of Birth, Government ID Type, Government ID Number, Address. The CIP processes are designed to validate customer identity against government blacklists and assist in the prevention of money laundering and terrorist financing. A combination of non-documentary and documentary verification can be used to ensure beyond a reasonable doubt the identity of the customer.

Non-Documentary Verification can occur through the presentment of the information that was collected from the user to an external third party, such as, for example, Lexis Nexis. Documentary Verification can occur if non-documentary verification fails, then the user is asked to present an unexpired government ID. Various differ forms of identification including Driver's license, Passport, Alien identification (e.g., green card or work visa), and Mexican Consular identification card, can be accepted.

Embodiments of the invention can perform Anti-Money Laundering (AML) and Combating the Financing of Terrorism (CFT) checks. AML and CFT checks can be performed using transaction monitoring methods to flag names and suspicious transactions for further investigation. The mobile wallet platform can perform AML and CFT checks on all electronic financial transactions to ensure that electronic funds are not being used for money laundering or terrorism. Transaction limits can be placed on user accounts. The transaction limits are fully configurable for each particular use case, channel and payment method that allows maximum flexibility to restrict higher risk use cases. Velocity checks can also be performed. Velocity Checks ensure that subscribers are not abusing the mobile wallet platform within the allowable limits.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A computing system for facilitating management of a mobile wallet, comprising: one or more processors;system memory;an integration tier configured to manage mobile wallet sessions with a mobile device and including web services communication mechanisms for interfacing with a mobile wallet application and a plurality of different device types over a plurality of different communication channels, the integration tier being configured to receive binary and text messages from a mobile device;a notification services engine configured to interface with the integration tier and to send a plurality of corresponding different types of messages over the different communication channels to different devices, including a customer's mobile device, to interface with a mobile wallet application installed on the customer's mobile device;service connectors that are each configured to connect the computing system to a different third party system;a payment handler that exposes a common API for interacting with different payment processors;a security services engine that performs subscriber authentication utilizing a database-based Access Control List (ACL);a rules engine configured to enforce constraints on financial transactions performed with the mobile wallet application, the mobile wallet application being associated with a mobile wallet account; andone or more computer-readable storage media having stored thereon computer-executable instructions which are executable by the one or more processors, to facilitate a transaction for a customer using the mobile wallet by causing the computing system to perform at least the following:receive communication from the customer over one of the plurality of channels connected to the computing system, the customer communication indicating that the customer desires to purchase an item at an agent terminal for a specified amount of funds using a specified payment method from a mobile wallet;return a secure, perishable purchase code to the customer over at least one of the plurality of channels connected to the computing system;receive communication from the agent terminal over at least one of the plurality of channels connected to the computing system, the agent terminal communication indicating that the purchase code has been presented to an agent;debit the mobile wallet by the specified amount of funds;credit an agent account by the specified amount of funds; andafter selecting a particular channel included in the plurality of channels, send a notification communication from the computing system to the agent terminal using the particular channel, which is connected to the computing system, the notification communication providing a notification indicating confirmation of the processing of the transaction.
2. The computing system of claim 1, wherein the computing system notifies the customer of confirmation of the processing of the transaction using the mobile wallet over at least one of the plurality of communication channels connected to the computing system.
3. The computing system of claim 1, wherein the mobile wallet is a native mobile wallet.
4. The computing system of claim 1, wherein the mobile wallet is a third party mobile wallet.
5. The computing system of claim 4, wherein the third party mobile wallet is provided by a third party mobile wallet provider.
6. The computing system of claim 5, wherein each third party mobile wallet provider has their own point of sale (POS) processing system.
7. The computing system of claim 1, wherein the customer communication is initiated by the customer through the mobile wallet application installed on a device of the customer.
8. A computer-implemented method of facilitating management of a mobile wallet, the computer-implemented method being performed by one or more hardware processors executing computer executable instructions for the computer-implemented method, and the computer-implemented method comprising: a computer system receiving communication from a customer over one of a plurality of channels connected to the computer system, the customer communication indicating that the customer desires to purchase an item at an agent terminal for a specified amount of funds using a specified payment method from a mobile wallet;returning a secure, perishable purchase code to the customer over at least one of the plurality of channels connected to the computer system;receiving communication from the agent terminal over at least one of the plurality of channels connected to the computer system, the agent terminal communication indicating that the purchase code has been presented to an agent;debiting the mobile wallet by the specified amount of funds;crediting an agent account by the specified amount of funds; andafter selecting a particular channel included in the plurality of channels, sending a notification communication from the computer system to the agent terminal using the particular channel, which is connected to the computer system, the notification communication providing a notification indicating confirmation of the processing of the transaction, wherein the computer system includes at least the following:one or more processors;system memory;an integration tier configured to manage mobile wallet sessions with a mobile device on which a mobile wallet application is installed and including web services communication mechanisms for interfacing with the mobile wallet application and a plurality of different device types over the plurality of different communication channels, the integration tier being configured to receive binary and text messages from the mobile device;a notification services engine configured to interface with the integration tier and to send a plurality of corresponding different types of messages over the different communication channels to different devices, including the mobile device, to interface with the mobile wallet application installed on the mobile device;service connectors that are each configured to connect the computer system to a different third party system, each of the service connectors being configured as a separate module for integrating a corresponding external service to the computer system;a payment handler that exposes a common API for interacting with different payment processors;a security services engine that performs subscriber authentication utilizing a database-based Access Control List (ACL); anda rules engine configured to enforce constraints on financial transactions performed with the mobile wallet application.
9. The method of claim 8, further comprising notifying the customer of confirmation of the processing of the transaction using the mobile wallet over at least one of the plurality of communication channels connected to the computer system.
10. The method of claim 8, wherein the mobile wallet is a native mobile wallet.
11. The method of claim 8, wherein the mobile wallet is a third party mobile wallet.
12. The method of claim 11, wherein the third party mobile wallet is provided by a third party mobile wallet provider.
13. The method of claim 12, wherein each third party mobile wallet provider has their own point of sale (POS) processing system.
14. The method of claim 13, wherein the third party mobile wallet providers' POS processing systems communicate with each other using the computer system to process the transaction.
15. The method of claim 8, wherein the customer communication is initiated by the customer through the mobile wallet application installed on a device of the customer.
16. A computer program product comprising one or more hardware storage devices having stored thereon computer-executable instructions that are executable by one or more processors of a computer system and that configure the computer system to facilitate management of a mobile wallet, including computer-executable instructions that configure the computer system to perform at least the following: receive communication from a customer over one of a plurality of communication channels connected to the computing system, the customer communication indicating that the customer desires to purchase an item at an agent terminal for a specified amount of funds using a specified payment method from a mobile wallet;return a secure, perishable purchase code to the customer over at least one of the plurality of channels connected to the computing system;receive communication from the agent terminal over at least one of the plurality of channels connected to the computing system, the agent terminal communication indicating that the purchase code has been presented to an agent;debit the mobile wallet by the specified amount of funds;credit an agent account by the specified amount of funds; andafter selecting a particular channel included in the plurality of channels, send a notification communication from the computer system to the agent terminal using the particular channel, which is connected to the computer system, the notification communication providing a notification indicating confirmation of the processing of the transaction, wherein the computer system includes at least the following:one or more processors;system memory;an integration tier configured to manage mobile wallet sessions with a mobile device on which a mobile wallet application is installed and including web services communication mechanisms for interfacing with the mobile wallet application and a plurality of different device types over the plurality of different communication channels, the integration tier being configured to receive binary and text messages from the mobile device;a notification services engine configured to interface with the integration tier and to send a plurality of corresponding different types of messages over the different communication channels to different devices, including the mobile device, to interface with the mobile wallet application;service connectors that are each configured to connect the computer system to a different third party system, each of the service connectors being configured as a separate module for integrating a corresponding external service to the computer system;a payment handler that exposes a common API for interacting with different payment processors;a security services engine that performs subscriber authentication utilizing a database-based Access Control List (ACL); anda rules engine configured to enforce constraints on financial transactions performed with the mobile wallet application.
17. The computer program product of claim 16, wherein the computer system notifies the customer of confirmation of the processing of the transaction using the mobile wallet over at least one of the plurality of communication channels connected to the computing system.
18. The computer program product of claim 16, wherein the mobile wallet is a native mobile wallet.
19. The computer program product of claim 16, wherein the mobile wallet is a third party mobile wallet.
20. The computer program product of claim 16, wherein the customer communication is initiated by the customer through the mobile wallet application installed on a device of the customer.
21. A computing system for facilitating management of a mobile wallet, including: one or more processors;system memory;an integration tier configured to manage mobile wallet sessions with a mobile device and including web services communication mechanisms for interfacing with a mobile wallet application installed on computer readable media executable by the mobile device as well as with a plurality of different device types over a plurality of different communication channels, the integration tier being configured to receive digital communications from the mobile device;a notification services engine configured to interface with the integration tier and to send digital messages over the different communication channels to different devices, including the mobile device, to interface with the mobile wallet application installed on the computer readable media executable by the mobile device;service connectors that are each configured to connect the computing system to a different third party system, each of the service connectors being configured as a separate module for integrating a corresponding external service to the computing system;a payment handler that exposes a common API for interacting with different payment processors;a security services engine that performs subscriber authentication utilizing a database-based Access Control List (ACL);a rules engine configured to enforce constraints on financial transactions performed with the mobile wallet application, the mobile wallet application being associated with a mobile wallet account; andone or more computer-readable storage media having stored thereon computer-executable instructions that are executable by the one or more processors to cause the computing system to perform a transaction for a customer using the mobile wallet which is owned by another entity than the customer, comprising the following:the computing system receiving communication from an agent terminal over one of a plurality of communication channels connected to a cloud-based transaction platform, the communication from the agent terminal indicating that a customer desires to perform a transaction comprising a mobile wallet transaction using a third party mobile wallet, wherein the mobile wallet transaction comprises at least one of a mobile wallet transfer in which funds are transferred from the mobile wallet of the customer to a third party mobile wallet, a mobile wallet withdrawal in which funds are withdrawn from the third party mobile wallet and provided to the customer, or a mobile wallet deposit in which funds are deposited into the third party mobile wallet;the computing system sending the communication from the agent terminal to the third party mobile wallet platform;the computing system determining whether the mobile wallet transaction comprises the mobile wallet withdrawal and when the mobile wallet transaction is determined to comprise the mobile wallet withdrawal, generating and providing a perishable withdrawal code to the customer, which is presented to the agent terminal to facilitate processing of the mobile wallet withdrawal;the computing system receiving communication from the third party mobile wallet platform confirming processing of the transaction, the transaction comprising at least one of the mobile wallet transfer, the mobile wallet withdrawal or the mobile wallet deposit; andafter selecting a particular communication channel included in the plurality of communication channels, the computing system sending a notification communication to the agent terminal using the particular communication channel, which is connected to the cloud-based transaction platform, the notification communication to the agent terminal providing a notification indicating confirmation of the processing of the transaction.
22. A computing system for facilitating management of a mobile wallet, including: one or more processors;system memory;an integration tier configured to manage mobile wallet sessions with a mobile device and including web services communication mechanisms for interfacing with a mobile wallet application installed on computer readable media executable by the mobile device as well as with a plurality of different device types over a plurality of different communication channels, the integration tier being configured to receive digital communications from the mobile device;a notification services engine configured to interface with the integration tier and to send digital messages over the different communication channels to different devices, including the mobile device, to interface with the mobile wallet application installed on the computer readable media executable by the mobile device;service connectors that are each configured to connect the computing system to a different third party system, each of the service connectors being configured as a separate module for integrating a corresponding external service to the computing system;a payment handler that exposes a common API for interacting with different payment processors;a security services engine that performs subscriber authentication utilizing a database-based Access Control List (ACL);a rules engine configured to enforce constraints on financial transactions performed with the mobile wallet application, the mobile wallet application being associated with a mobile wallet account; andone or more computer-readable storage media having stored thereon computer-executable instructions that are executable by the one or more processors to cause the computing system to perform a transaction for a customer using the mobile wallet which is owned by another entity than the customer, comprising the following:the computing system receiving communication from an agent terminal over one of a plurality of communication channels connected to a cloud-based transaction platform, the communication from the agent terminal indicating that a customer desires to perform a transaction comprising a mobile wallet transaction using a third party mobile wallet, wherein the mobile wallet transaction comprises digitally transferring of funds for a purchase;the computing system sending the communication from the agent terminal to the third party mobile wallet platform;the computing system, upon determining that the mobile wallet transaction comprises the the digital transfer of funds, generating and providing a perishable withdrawal code to the customer, which is presented to the agent terminal to facilitate processing of the mobile wallet withdrawal;the computing system receiving communication from the third party mobile wallet platform confirming processing of the transaction, the transaction comprising at least one of the mobile wallet transfer, the mobile wallet withdrawal or the mobile wallet deposit; andafter selecting a particular communication channel included in the plurality of communication channels, the computing system sending a notification communication to the agent terminal using the particular communication channel, which is connected to the cloud-based transaction platform, the notification communication to the agent terminal providing a notification indicating confirmation of the processing of the transaction.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of, and claims priority to, U.S. patent application Ser. No. 13/680,824, entitled “Using A Mobile Wallet Infrastructure To Support Multiple Mobile Wallet Providers”, filed Nov. 19, 2012, which claims the benefit of U.S. Provisional Application Ser. No. 61/562,301, entitled “Using A Mobile Wallet Infrastructure To Support Multiple Mobile Wallet Providers”, filed Nov. 21, 2011, which is herein incorporated by reference in its entirety.

US Referenced Citations (469)

Number	Name	Date	Kind
5717374	Smith	Feb 1998	A
5828739	Nakanishi	Oct 1998	A
5991749	Morrill	Nov 1999	A
6021397	Jones et al.	Feb 2000	A
6175823	Van Dusen	Jan 2001	B1
6185545	Resnick	Feb 2001	B1
6250557	Forslund	Jun 2001	B1
6415156	Stadelmann	Jul 2002	B1
6622015	Himmel	Sep 2003	B1
6697839	Sini	Feb 2004	B2
6714797	Rautila	Mar 2004	B1
6736322	Gobburu	May 2004	B2
6819219	Bolle	Nov 2004	B1
6840448	Fukushima	Jan 2005	B2
6862575	Anttila et al.	Mar 2005	B1
6873974	Schutzer	Mar 2005	B1
6957342	Vatanen	Oct 2005	B2
7016532	Boncyk	Mar 2006	B2
7024174	Nagy	Apr 2006	B2
7054430	Lynam	May 2006	B2
7069001	Rupp	Jun 2006	B2
7089208	Levchin	Aug 2006	B1
7099850	Mann	Aug 2006	B1
7100821	Rasti	Sep 2006	B2
7107247	Kinoshita	Sep 2006	B2
7110972	Handa	Sep 2006	B1
7221939	Ylitalo	May 2007	B2
7240836	Vrotsos	Jul 2007	B2
7248855	Joyce	Jul 2007	B2
7255264	De Leon	Aug 2007	B2
7275685	Gray	Oct 2007	B2
7322043	Letsinger	Jan 2008	B2
7325132	Takayama	Jan 2008	B2
7334720	Hulst et al.	Feb 2008	B2
7347361	Lovett	Mar 2008	B2
7349871	Labrou	Mar 2008	B2
7353382	Labrou	Apr 2008	B2
7363261	Whitehead	Apr 2008	B2
7370017	Lindeman	May 2008	B1
7403652	Boncyk	Jul 2008	B2
7421410	Schechtman et al.	Sep 2008	B1
7461010	Kwan	Dec 2008	B2
7461028	Wronski	Dec 2008	B2
7477780	Boncyk	Jan 2009	B2
7494055	Fernandes	Feb 2009	B2
7512098	Jiang	Mar 2009	B2
7527194	Truitt	May 2009	B2
7548915	Ramer	Jun 2009	B2
7562818	Bierbaum	Jul 2009	B1
7564469	Boncyk	Jul 2009	B2
7565008	Boncyk	Jul 2009	B2
7606560	Labrou	Oct 2009	B2
7657489	Stambaugh	Feb 2010	B2
7677973	Van Luchene	Mar 2010	B2
7680324	Boncyk	Mar 2010	B2
7689506	Fei et al.	Mar 2010	B2
7694876	Barnes et al.	Apr 2010	B2
7699218	Garcia	Apr 2010	B2
7708194	Vawter	May 2010	B2
7729963	Lego	Jun 2010	B1
7729987	Wakim	Jun 2010	B1
7748618	Vawter	Jul 2010	B2
7774076	Skowronek	Aug 2010	B2
7774231	Pond	Aug 2010	B2
7775437	Boncyk	Aug 2010	B2
7784684	Labrou	Aug 2010	B2
7801826	Labrou	Sep 2010	B2
7819307	Lyons	Oct 2010	B2
7822688	Labrou	Oct 2010	B2
7823772	Vawter	Nov 2010	B2
7848500	Lynam	Dec 2010	B2
7848504	Lynam	Dec 2010	B2
7865414	Fung	Jan 2011	B2
7865431	Takayama	Jan 2011	B2
7877605	Labrou	Jan 2011	B2
7881529	Boncyk	Feb 2011	B2
7886962	Vawter	Feb 2011	B2
7890424	Wakim	Feb 2011	B1
7899243	Boncyk	Mar 2011	B2
7899252	Boncyk	Mar 2011	B2
7937302	Lego	May 2011	B1
7937305	Lego	May 2011	B1
7942317	Racz et al.	May 2011	B2
7958052	Powell	Jun 2011	B2
7967196	Bierbaum	Jun 2011	B1
7979026	Hulvey	Jul 2011	B2
7988060	Killian	Aug 2011	B2
8016185	Modi	Sep 2011	B2
8019365	Fisher	Sep 2011	B2
8033458	Hulst et al.	Oct 2011	B2
8041338	Chen	Oct 2011	B2
8052042	Kolinski-Schultz	Nov 2011	B2
8060012	Sklovsky	Nov 2011	B2
8061598	Racz et al.	Nov 2011	B2
8073783	Felsted	Dec 2011	B2
8077042	Peeters	Dec 2011	B2
8090945	Singhal	Jan 2012	B2
8095113	Kean	Jan 2012	B2
8116734	Vawter	Feb 2012	B2
8116773	Chitrapu	Feb 2012	B2
8118221	Racz et al.	Feb 2012	B2
8121945	Rackley	Feb 2012	B2
8130242	Boncyk	Mar 2012	B2
8145568	Rackley	Mar 2012	B2
8160959	Rackley	Apr 2012	B2
8170485	Hulvey	May 2012	B2
8190087	Fisher et al.	May 2012	B2
8195576	Grigg et al.	Jun 2012	B1
8196131	von Behren	Jun 2012	B1
8213470	Gu	Jul 2012	B2
8218873	Boncyk	Jul 2012	B2
8229354	Sklovsky	Jul 2012	B2
8239325	Schwarz	Aug 2012	B2
8275312	Fisher	Sep 2012	B2
8290433	Fisher	Oct 2012	B2
8332272	Fisher	Dec 2012	B2
8333319	Roth	Dec 2012	B2
8336772	Racz et al.	Dec 2012	B2
8352323	Fisher	Jan 2013	B2
8355670	White	Jan 2013	B2
8359265	Van Rensburg	Jan 2013	B2
8360329	Grigg	Jan 2013	B2
8374916	White	Feb 2013	B2
8380177	Laracey	Feb 2013	B2
8396793	Hill	Mar 2013	B2
8487771	Hsieh et al.	Jul 2013	B2
8538845	Liberty	Sep 2013	B2
8577803	Chatterjee et al.	Nov 2013	B2
8612325	Laracey	Nov 2013	B2
8632000	Laracey	Jan 2014	B2
9208488	Liberty	Dec 2015	B2
20010011248	Himmel	Aug 2001	A1
20010037264	Husemann	Nov 2001	A1
20010042785	Walker et al.	Nov 2001	A1
20020042776	Woo	Apr 2002	A1
20020052754	Joyce	May 2002	A1
20020060246	Gobburu	May 2002	A1
20020065774	Young	May 2002	A1
20020069123	Soderlind	Jun 2002	A1
20020131404	Mehta	Sep 2002	A1
20020141586	Margalit	Oct 2002	A1
20020152177	Wolf	Oct 2002	A1
20020161708	Offer	Oct 2002	A1
20030001010	Schmidt	Jan 2003	A1
20030026404	Joyce	Feb 2003	A1
20030055735	Cameron	Mar 2003	A1
20030071115	Horn	Apr 2003	A1
20030154165	Horn	Aug 2003	A1
20030195842	Reece	Oct 2003	A1
20040117302	Weichert et al.	Jun 2004	A1
20040181531	Becker	Sep 2004	A1
20040205618	Sini	Oct 2004	A1
20040235450	Rosenberg	Nov 2004	A1
20040248554	Khan	Dec 2004	A1
20050070265	Korpinen	Mar 2005	A1
20050071512	Kim et al.	Mar 2005	A1
20050080697	Foss	Apr 2005	A1
20050199709	Linlor	Sep 2005	A1
20050222961	Staib	Oct 2005	A1
20050283434	Hahn-Carlson	Dec 2005	A1
20060116892	Grimes	Jun 2006	A1
20060136901	Nichols	Jun 2006	A1
20060165060	Dua	Jul 2006	A1
20060179452	Amodeo	Aug 2006	A1
20060200427	Morrison	Sep 2006	A1
20060253335	Keena et al.	Nov 2006	A1
20060287004	Fuqua	Dec 2006	A1
20070006327	Lal et al.	Jan 2007	A1
20070033285	Shiigi	Feb 2007	A1
20070106564	Matotek	May 2007	A1
20070123305	Chen	May 2007	A1
20070125838	Law	Jun 2007	A1
20070125840	Law	Jun 2007	A1
20070162471	Samuelsson	Jul 2007	A1
20070179885	Bird	Aug 2007	A1
20070198432	Pitroda	Aug 2007	A1
20070203850	Singh	Aug 2007	A1
20070241189	Slavin	Oct 2007	A1
20070244811	Tumminaro	Oct 2007	A1
20070255620	Tumminaro et al.	Nov 2007	A1
20070255652	Tumminaro et al.	Nov 2007	A1
20070255653	Tumminaro	Nov 2007	A1
20070265984	Santhana	Nov 2007	A1
20080006685	Rackley	Jan 2008	A1
20080010191	Rackley	Jan 2008	A1
20080010196	Rackley	Jan 2008	A1
20080010204	Rackley	Jan 2008	A1
20080010215	Rackley	Jan 2008	A1
20080011825	Giordano	Jan 2008	A1
20080017704	VanDeburg	Jan 2008	A1
20080040265	Rackley	Feb 2008	A1
20080040285	Wankmueller	Feb 2008	A1
20080052192	Fisher	Feb 2008	A1
20080065490	Novick et al.	Mar 2008	A1
20080097851	Bemmel	Apr 2008	A1
20080126145	Rackley	May 2008	A1
20080126929	Bykov	May 2008	A1
20080143487	Hulvey	Jun 2008	A1
20080197190	Fujita	Aug 2008	A1
20080204358	Sato	Aug 2008	A1
20080208743	Arthur	Aug 2008	A1
20080208744	Arthur	Aug 2008	A1
20080208762	Arthur	Aug 2008	A1
20080210751	Kim	Sep 2008	A1
20080249927	Rethorn	Oct 2008	A1
20080249928	Hill	Oct 2008	A1
20080249930	Hill	Oct 2008	A1
20080249933	Rethorn	Oct 2008	A1
20080255947	Friedman	Oct 2008	A1
20080275779	Lakshminarayanan	Nov 2008	A1
20080281737	Fajardo	Nov 2008	A1
20090024526	Erickson	Jan 2009	A1
20090037326	Chitti	Feb 2009	A1
20090055322	Bykov	Feb 2009	A1
20090063312	Hurst	Mar 2009	A1
20090081989	Wuhrer	Mar 2009	A1
20090098854	Park	Apr 2009	A1
20090104888	Cox	Apr 2009	A1
20090106148	Prada	Apr 2009	A1
20090108015	Kreamer	Apr 2009	A1
20090119190	Realini	May 2009	A1
20090132362	Fisher	May 2009	A1
20090132392	Davis	May 2009	A1
20090138366	Bemmel	May 2009	A1
20090144161	Fisher	Jun 2009	A1
20090156190	Fisher	Jun 2009	A1
20090157546	Garcia	Jun 2009	A1
20090177578	Garcia	Jul 2009	A1
20090177581	Garcia	Jul 2009	A1
20090210308	Toomer	Aug 2009	A1
20090222353	Guest	Sep 2009	A1
20090222358	Bednarek	Sep 2009	A1
20090234751	Chan et al.	Sep 2009	A1
20090248537	Sarkeshik	Oct 2009	A1
20090254440	Pharris	Oct 2009	A1
20090254479	Pharris	Oct 2009	A1
20090265272	Dill et al.	Oct 2009	A1
20090281904	Pharris	Nov 2009	A1
20090288012	Hertel	Nov 2009	A1
20090299844	Reilly	Dec 2009	A1
20090307132	Phillips	Dec 2009	A1
20100010964	Skowronek	Jan 2010	A1
20100023449	Skowronek	Jan 2010	A1
20100030651	Matotek et al.	Feb 2010	A1
20100044430	Song	Feb 2010	A1
20100048226	Owen	Feb 2010	A1
20100049599	Owen	Feb 2010	A1
20100051685	Royyuru	Mar 2010	A1
20100057614	Rainey	Mar 2010	A1
20100057619	Weller	Mar 2010	A1
20100057624	Hurt	Mar 2010	A1
20100063895	Dominguez	Mar 2010	A1
20100088188	Kumar	Apr 2010	A1
20100114739	Johnston	May 2010	A1
20100125495	Smith	May 2010	A1
20100125510	Smith	May 2010	A1
20100146607	Piepenbrink et al.	Jun 2010	A1
20100151790	Hoeksel et al.	Jun 2010	A1
20100197326	Ngo	Aug 2010	A1
20100223110	Slavin	Sep 2010	A1
20100235283	Gerson	Sep 2010	A1
20100248710	Sklovsky	Sep 2010	A1
20100250356	Gillenson	Sep 2010	A1
20100250436	Loevenguth	Sep 2010	A1
20100260388	Garrett	Oct 2010	A1
20100333129	Alhadeff et al.	Dec 2010	A1
20110047016	Cook	Feb 2011	A1
20110057025	Denzer	Mar 2011	A1
20110087529	Angell	Apr 2011	A1
20110087610	Batada	Apr 2011	A1
20110105022	Vawter	May 2011	A1
20110113473	Corda	May 2011	A1
20110131421	Jogand-Coulomb et al.	Jun 2011	A1
20110145049	Hertel	Jun 2011	A1
20110145149	Valdes	Jun 2011	A1
20110179113	Thomas	Jul 2011	A1
20110196788	Lu et al.	Aug 2011	A1
20110218911	Spodak	Sep 2011	A1
20110246284	Chaikin	Oct 2011	A1
20110250866	Fisher	Oct 2011	A1
20110251941	Dunwoody	Oct 2011	A1
20110258024	Prince	Oct 2011	A1
20110258115	Mulhim	Oct 2011	A1
20110276417	Campbell	Nov 2011	A1
20110295750	Rammal	Dec 2011	A1
20110302016	Haddad	Dec 2011	A1
20110302406	Machani	Dec 2011	A1
20110313924	Carell	Dec 2011	A1
20110320243	Khan	Dec 2011	A1
20110320293	Khan	Dec 2011	A1
20110320294	Votaw	Dec 2011	A1
20110320345	Taveau	Dec 2011	A1
20120005076	Dessert	Jan 2012	A1
20120011058	Pitroda et al.	Jan 2012	A1
20120011063	Killian	Jan 2012	A1
20120028612	Hurst	Feb 2012	A1
20120029990	Fisher	Feb 2012	A1
20120047070	Pharris	Feb 2012	A1
20120074232	Spodak	Mar 2012	A1
20120078735	Bauer	Mar 2012	A1
20120079521	Garg et al.	Mar 2012	A1
20120084203	Mehew	Apr 2012	A1
20120095855	Sterling	Apr 2012	A1
20120095856	Sanjeev	Apr 2012	A1
20120122447	Craft	May 2012	A1
20120123841	Taveau	May 2012	A1
20120123868	Brudnicki	May 2012	A1
20120123880	Craft	May 2012	A1
20120123935	Brudnicki	May 2012	A1
20120123937	Spodak	May 2012	A1
20120131653	Pasquero	May 2012	A1
20120143752	Wong	Jun 2012	A1
20120150669	Langley	Jun 2012	A1
20120158589	Katzin	Jun 2012	A1
20120166311	Dwight	Jun 2012	A1
20120171992	Cheong	Jul 2012	A1
20120172026	Kwon	Jul 2012	A1
20120172089	Bae	Jul 2012	A1
20120174189	Lim	Jul 2012	A1
20120191557	Fisher	Jul 2012	A1
20120191612	Spodak	Jul 2012	A1
20120196586	Grigg	Aug 2012	A1
20120197691	Grigg	Aug 2012	A1
20120197740	Grigg	Aug 2012	A1
20120197743	Grigg	Aug 2012	A1
20120197745	Fisher	Aug 2012	A1
20120197787	Grigg	Aug 2012	A1
20120203610	Grigg et al.	Aug 2012	A1
20120203632	Blum	Aug 2012	A1
20120209688	Lamothe	Aug 2012	A1
20120209749	Hammad	Aug 2012	A1
20120215701	Mehta	Aug 2012	A1
20120221421	Hammad	Aug 2012	A1
20120221475	Grigg	Aug 2012	A1
20120226610	Gill	Sep 2012	A1
20120229647	Calman	Sep 2012	A1
20120229657	Calman	Sep 2012	A1
20120231424	Calman	Sep 2012	A1
20120231425	Calman	Sep 2012	A1
20120232937	Calman	Sep 2012	A1
20120232977	Calman	Sep 2012	A1
20120232983	Bertha	Sep 2012	A1
20120245986	Regan	Sep 2012	A1
20120253852	Pourfallah	Oct 2012	A1
20120259598	Yurrow	Oct 2012	A1
20120259686	Yurow	Oct 2012	A1
20120259732	Sasankan	Oct 2012	A1
20120265677	Rackley	Oct 2012	A1
20120265685	Brudnicki	Oct 2012	A1
20120271712	Katzin	Oct 2012	A1
20120284131	Soffer	Nov 2012	A1
20120286928	Mullen	Nov 2012	A1
20120290376	Dryer	Nov 2012	A1
20120290449	Mullen	Nov 2012	A1
20120290478	Crofts et al.	Nov 2012	A1
20120293303	Khan	Nov 2012	A1
20120296708	Bachmann	Nov 2012	A1
20120296720	Pirillo	Nov 2012	A1
20120296722	Gosavi	Nov 2012	A1
20120296741	Dykes	Nov 2012	A1
20120297204	Buer	Nov 2012	A1
20120302204	Gupta	Nov 2012	A1
20120303425	Katzin	Nov 2012	A1
20120310720	Balsan	Dec 2012	A1
20120310760	Phillips	Dec 2012	A1
20120310824	Liberty	Dec 2012	A1
20120310826	Chatterjee	Dec 2012	A1
20120316950	LaPorte	Dec 2012	A1
20120316951	Fisher	Dec 2012	A1
20120316992	Oborne	Dec 2012	A1
20120317019	Carnes	Dec 2012	A1
20120323653	Fisher	Dec 2012	A1
20120323664	Klems	Dec 2012	A1
20120323670	Fisher	Dec 2012	A1
20120323777	Liberty	Dec 2012	A1
20120329394	Fisher	Dec 2012	A1
20120330737	Liberty	Dec 2012	A1
20120330792	Kashanian	Dec 2012	A1
20130012125	Fisher	Jan 2013	A1
20130012126	Fisher	Jan 2013	A1
20130012131	Fisher	Jan 2013	A1
20130013352	Fisher	Jan 2013	A1
20130013353	Fisher	Jan 2013	A1
20130013355	Fisher	Jan 2013	A1
20130013432	Fisher	Jan 2013	A1
20130013434	Fisher	Jan 2013	A1
20130013490	Keller	Jan 2013	A1
20130013498	Fisher	Jan 2013	A1
20130013501	Rackley	Jan 2013	A1
20130017784	Fisher	Jan 2013	A1
20130018738	Faires	Jan 2013	A1
20130018740	Fisher	Jan 2013	A1
20130018742	Fisher	Jan 2013	A1
20130018793	Wong	Jan 2013	A1
20130023209	Fisher	Jan 2013	A1
20130023294	Singh	Jan 2013	A1
20130024220	Fisher	Jan 2013	A1
20130024221	Fisher	Jan 2013	A1
20130024223	Thomas	Jan 2013	A1
20130024280	Fisher	Jan 2013	A1
20130024364	Fisher	Jan 2013	A1
20130024371	Hariramani	Jan 2013	A1
20130024372	Spodak	Jan 2013	A1
20130024377	Stong	Jan 2013	A1
20130029646	Chowdhury	Jan 2013	A1
20130030828	Pourfallah	Jan 2013	A1
20130030960	Kashanian	Jan 2013	A1
20130030997	Spodak	Jan 2013	A1
20130035035	Fisher	Feb 2013	A1
20130035036	Fisher	Feb 2013	A1
20130035037	Fisher	Feb 2013	A1
20130035068	Fisher	Feb 2013	A1
20130035069	Fisher	Feb 2013	A1
20130035070	Fisher	Feb 2013	A1
20130035071	Fisher	Feb 2013	A1
20130035072	Fisher	Feb 2013	A1
20130035087	Fisher	Feb 2013	A1
20130035967	Fisher	Feb 2013	A1
20130035968	Fisher	Feb 2013	A1
20130035969	Fisher	Feb 2013	A1
20130035970	Fisher	Feb 2013	A1
20130040568	Fisher	Feb 2013	A1
20130040569	Fisher	Feb 2013	A1
20130041699	Fisher	Feb 2013	A1
20130041700	Fisher	Feb 2013	A1
20130041701	Roth	Feb 2013	A1
20130041736	Coppinger	Feb 2013	A1
20130041743	Coppinger	Feb 2013	A1
20130041744	Coppinger	Feb 2013	A1
20130041745	Coppinger	Feb 2013	A1
20130041769	Fisher	Feb 2013	A1
20130046608	Coppinger	Feb 2013	A1
20130046634	Grigg	Feb 2013	A1
20130046645	Grigg	Feb 2013	A1
20130048723	King	Feb 2013	A1
20130052952	Fisher	Feb 2013	A1
20130054336	Graylin	Feb 2013	A1
20130054337	Brendell	Feb 2013	A1
20130054412	Brendell	Feb 2013	A1
20130054441	Kamdar	Feb 2013	A1
20130057392	Bullock	Mar 2013	A1
20130060618	Barton	Mar 2013	A1
20130073373	Fisher	Mar 2013	A1
20130073377	Heath	Mar 2013	A1
20130073458	Sherwin	Mar 2013	A1
20130080228	Fisher	Mar 2013	A1
20130080229	Fisher	Mar 2013	A1
20130080230	Fisher	Mar 2013	A1
20130080231	Fisher	Mar 2013	A1
20130080232	Fisher	Mar 2013	A1
20130080233	Fisher	Mar 2013	A1
20130080240	Fisher	Mar 2013	A1
20130080241	Fisher	Mar 2013	A1
20130080329	Royyuru	Mar 2013	A1
20130091012	Liberty	Apr 2013	A1
20130246141	Liberty	Apr 2013	A1
20130132219	Liberty	May 2013	A1
20130238455	Laracey	Sep 2013	A1
20130246203	Laracey	Sep 2013	A1
20130013499	Kalgi	Oct 2013	A1
20130317928	Laracey	Nov 2013	A1
20130332347	Liberty	Dec 2013	A1
20130346309	Giori	Dec 2013	A1
20140006048	Liberty	Jan 2014	A1
20140014721	Lindeman	Jan 2014	A1
20140201070	Liberty	Jul 2014	A1
20150039517	Liberty	Feb 2015	A1
20160055483	Liberty	Feb 2016	A1
20160314443	Liberty	Oct 2016	A1

Foreign Referenced Citations (32)

Number	Date	Country
2666616	Apr 2008	CA
101606400	Dec 2009	CN
102073958	May 2011	CN
10119808	Sep 2002	DE
1280115	Jan 2003	EP
2284783	Feb 2011	EP
2001-297198	Oct 2001	JP
2001357164	Dec 2001	JP
2002-99716	Apr 2002	JP
10-2002-0065989	Aug 2002	KR
10-2003-0068603	Aug 2003	KR
10-2007-0092400	Sep 2007	KR
199834203	Aug 1998	WO
9913636	Mar 1999	WO
0171627	Sep 2001	WO
2001097118	Dec 2001	WO
2002071354	Sep 2002	WO
2003012717	Feb 2003	WO
2004010393	Jan 2004	WO
2004023353	Mar 2004	WO
2004053640	Jun 2004	WO
2004088641	Oct 2004	WO
2005079254	Sep 2005	WO
2005086593	Sep 2005	WO
2007145500	Dec 2007	WO
2008008735	Jan 2008	WO
2012025824	Mar 2012	WO
2013009444	Jan 2013	WO
2013009446	Jan 2013	WO
2013025273	Feb 2013	WO
2013078176	May 2013	WO
2013166174	Nov 2013	WO

Non-Patent Literature Citations (92)

Entry
U.S. Appl. No. 14/928,105, filed Oct. 30, 2015, Liberty, Michael A.
Chen, Jiajun Jim et al, Short-Range Wireless Technologies with Mobile Payments Systems. Proceedings of the 6th International Conference on Electronic Commerce [Online] 2004, pp. 649-656.
Clarke, Irvine III, “Emerging Value Propositions for M-commerce,” Journal of Business Strategies, vol. 25, Issue 2, Fall 2008, p. 41-57; ISSN: 0887-2058.
Edwin, et al., “Technobiography,” Oct. 2004, 29 pages.
European Search Report for EP12824344 dated Sep. 29, 2014.
Gao, Jerry, et al., “P2P-Paid: A Peer-to-Peer Wireless Payment System,” Proceedings of the 2005 Second IEEE International Workshop on Mobile Commerce and Services (WMCS'05) Jul. 2005, 10 pages.
International Search Report and Written Opinion for PCT/US2012/066013 dated Jan. 29, 2013.
International Search Report and Written Opinion for PCT/US2012/040131 dated Jan. 29, 2013.
International Search Report and Written Opinion for PCT/US2012/043321 dated Sep. 6, 2012.
International Search Report and Written Opinion for PCT/US2012/058849 dated Jan. 4, 2013.
International Search Report and Written Opinion for PCT/US2012/43458 dated Aug. 17, 2012.
International Search Report and Written Opinion for PCT/US2013/039100 dated Aug. 23, 2013.
Labrou, Yannis et al, Wireless Wallet. Proceedings of the First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services [Online] 2004, pp. 1-10.
Motorola, Motorola M-Wallet Solution. [Online] 2006 http://www.motorola.com/networkoperators/pdfs/M-Wallet-Brochure.pdf (Accessed Oct. 4, 2012).
Sykes, et al. “Securing Mobile Banking,” Credit Union Management, Nov. 2010, vol. 33 No. 11; ISSN 0273-9267.
Valcourt, E. et al., “Investigating Mobile Payment,” Wireless and Mobile Computing, Networking and Communications, 2005. (WiMob'2005), IEEE International Conference on Aug. 22-24, 2005, Aug. 2005, vol. 4, pp. 29-36.
Wei, et al., “Development of a Web-Based Mobile Airline Ticketing Model with Usability Features,” 2005, Industrial Management + Data Systems; vol. 105 No. 9, ISSN: 0263-5577.
U.S. Appl. No. 13/484,199, Dec. 26, 2012, Office Action.
U.S. Appl. No. 13/484,199, Jun. 7, 2013, Notice of Allowance.
U.S. Appl. No. 13/527,466, Apr. 15, 2013, Office Action.
U.S. Appl. No. 13/527,466, Dec. 4, 2013, Final Office Action.
U.S. Appl. No. 13/964,707, Feb. 24, 2014, Office Action.
U.S. Appl. No. 14/213,543, May 6, 2014, Office Action.
U.S. Appl. No. 13/680,824, Jun. 16, 2014, Office Action.
U.S. Appl. No. 13/528,720, Jun. 25, 2014, Office Action.
U.S. Appl. No. 13/964,707, Jul. 10, 2014, Office Action.
U.S. Appl. No. 13/527,466, Aug. 1, 2014, Office Action.
U.S. Appl. No. 14/012,822, Aug. 7, 2014, Office Action.
U.S. Appl. No. 13/528,720, Dec. 10, 2014, Final Office Action.
U.S. Appl. No. 14/012,822, Jan. 7, 2015, Final Office Action.
U.S. Appl. No. 13/680,824, Feb. 6, 2015, Final Office Action.
U.S. Appl. No. 13/964,707, Mar. 16, 2015, Final Office Action.
U.S. Appl. No. 14/213,543, Apr. 8, 2015, Office Action.
U.S. Appl. No. 13/874,192, Jul. 14, 2015, Office Action.
U.S. Appl. No. 13/527,466, Jul. 16, 2015, Office Action.
U.S. Appl. No. 13/528,720, Jul. 22, 2015, Office Action.
U.S. Appl. No. 14/012,822, Sep. 11, 2015, Office Action.
U.S. Appl. No. 13/680,824, Sep. 18, 2015, Notice of Allowance.
U.S. Appl. No. 14/213,543, Jan. 6, 2016, Final Office Action.
U.S. Appl. No. 15/201,152, Aug. 8, 2017, Notice of Allowance.
U.S. Appl. No. 13/527,466, Aug. 9, 2017, Office Action.
U.S. Appl. No. 13/874,192, Apr. 18, 2016, Final Office Action.
International Search Report and Written Opinion for PCT/US2015/58886 dated Feb. 4, 2016.
European Search Report for EP12851211 dated Feb. 18, 2016.
U.S. Appl. No. 13/528,720, Mar. 2, 2016, Final Office Action.
U.S. Appl. No. 14/012,822, May 6, 2016, Final Office Action.
U.S. Appl. No. 15/201,152, Oct. 25, 2016, Office Action.
U.S. Appl. No. 15/201,152, Jun. 15, 2017, Final Office Action.
U.S. Appl. No. 13/527,466, Dec. 14, 2016, Office Action.
Ron White, How Computers Work, Oct. 15, 2003, Paul Boger, Illustrated by Timothy Edward Dwons, 7th Edition (Year: 2003).
U.S. Appl. No. 14/341,605, Nov. 27, 2017, Office Action.
U.S. Appl. No. 13/527,466, Apr. 1, 2016, Office Action.
U.S. Appl. No. 15/809,872, filed Nov. 10, 2017, Liberty, Michael A.
U.S. Appl. No. 61/493,064, filed Jun. 3, 2011, Liberty, Michael A.
U.S. Appl. No. 61/522,099, filed Aug. 10, 2011, Liberty, Michael A.
U.S. Appl. No. 62/075,657, filed Nov. 5, 2014, Liberty, Michael A.
U.S. Appl. No. 61/498,957, filed Jun. 20, 2011, Liberty, Michael A.
U.S. Appl. No. 61/499,927, filed Jun. 22, 2011, Liberty, Michael A.
U.S. Appl. No. 61/562,301, filed Nov. 21, 2011, Liberty, Michael A.
U.S. Appl. No. 61/694,118, filed Aug. 28, 2012, Liberty, Michael A.
U.S. Appl. No. 61/641,677, filed May 2, 2012, Liberty, Michael A.
U.S. Appl. No. 61/862,437, filed Aug. 5, 2012, Liberty, Michael A.
U.S. Appl. No. 14/928,105, Aug. 27, 2018, Office Action.
Medhi et al., “Mobile-banking adoption and usage by low-literate, low-income users in the developing world”, 2009, N. Aykin (Ed.): Internationalization, Design, LNCS 5623, pp. 485-486.
Mbogo, “The impact of mobile payments on the success and growth of micro-business: the case of M-Pesa in Kenya”, The Journal of Language, Technology & Entrepreneurship in Africa, vol. 2, No. 1, 2010, ISSN 1998-1279, pp. 182-203.
Jack et al., “Monetary Theory and electronic money: reflections on the Kenyan experience”, economic quarterly, vol. 96, No. 1, first quarter 2010, pp. 83-122.
Comninos et al., “M-banking the unbanked”, towards evidence-based ICT policy and regulation, vol. 1, 2008, policy paper 4, pp. 1-15.
Lonie, “M-PESA: finding new ways to serve the unbanked in Kenya”, innovations in rural and agricultural finance, Jul. 2010, focus 18, brief 8, pp. 1-3.
Plyler et al., “Community level economic effects of M-PESA in Kenya: initial findings (executive summary)”, financial services assessment, IRIS center, university of maryland college park, Mar. 30, 2010, pp. 1-4, accessible at <http://www.fsassessment.umd.edu/>.
Hughes et al., “M-PESA: mobile money for the ‘unbanked’ turning cellphones into 24-hour tellers in Kenya”, winter & spring 2007, innovations, pp. 63-81.
Omwansa, “M-PESA: Progress and prospects”, innovations case discussion: M-PESA, 2009, innovations, mobile world congress, pp. 107-123.
Mas et al., “Designing mobile money services—lessons from M-PESA”, innovations, spring 2009, pp. 77-91.
Porteous, “Just how transformational is m-banking?”, commissioned by FinMark Trust, bankable frontier associates LLC, Feb. 2007, pp. 1-32.
Morawczynski et al., “Poor people using mobile financial services: observations on customer usage impact from M-PESA”, CGAP, Aug. 2009, pp. 1-4.
Jack et al., “The economics of M-PESA”, Aug. 2010, commissioned by the Centre Bank of Kenya, managed by Financial Sector Deepening, administered by the Steadman Group, pp. 1-20.
“RadioShack and Trumpet Mobile launch prepaid mobile phone service nationwide with unique mobile money transfer capabilities”, Apr. 1, 2008, Source: Trumpet Mobile, pp. 1-3.
Sultana, “Mobile banking: overview of regulatory framework in emerging markets”, Grameenphone Ltd, Celebration Point, Bangladesh, electronic copy available at <http://ssrn.com/abstract=1554160>, pp. 1-17.
Ivatury et al., “The early experience with branchless banking”, CGAP, No. 46, Apr. 2008, electronic copy available at <http://ssrn.com/abstract=1655257> pp. 1-16.
Porteous, “The enabling environment for mobile banking in Africa”, version 3.1, report commissioned by Department for International Development (DFID), Bankable Frontier Associates, May 2006, pp. 1-57.
Jack et al., “Mobile money: the economics of M-PESA”, working paper 16721, National Bureau of Economic Research (NBER) working paper series, Jan. 2011, accessible at <http://www.nber.org/papers/w16721>, pp. 1-30.
Rice, “Kenya sets world first with money transfers by mobile”, The Guardian, Mar. 20, 2007, pp. 1-3, accessed via <https://www.theguardian.com/money/2007/mar/20/kenya.mobilephones> on Mar. 25, 2019.
PYMNTS, “Mobile payments go viral: M-PESA in Kenya”, Aug. 4, 2010, Business Wire, from ‘Yes Africa can: success stories from a dynamic continent, world bank’—May 2010, pp. 1-30, accessed via <https://www.pymnts.com/business-wire/2010/mobile-payments-go-viral-m-pesa-in-kenya/> on Mar. 25, 2019.
Youtube video, “M-PESA: send money home tv commercial”, accessed via <https://www.youtube.com/watch?v=nEZ30K5dBWU> on Mar. 25, 2019.
Graham, “M-PESA: Kenya's mobile wallet revolution”, technology of business reporter, BBC news, Nov. 22, 2010, pp. 1-18, accessed via <https://www.bbc.com/news/business-11793290> on Mar. 25, 2019.
Starita, “Mobile cash transfers pose threat to banks”, Feb. 26, 2009, News & Commentary, Philanthropy Action, pp. 1-4, accessed via <philanthropyaction.com/nc/mobile_cash_transfers_pose_threat_to_banks/> on Mar. 25, 2019.
Anonymous Staff Writer, “Portuguese firm flourishing in Mozambique”, Africa Business Insight, How We Made It in Africa, pp. 1-2, accessed via <https://howwemadeitinafrica.com/portuguese-firm-flourishing-in-mozambique/3599/> on Mar. 25, 2019.
Njihia, “What you dont now about Mpesa . . . ”, The Mind of Mbugua Njihia, Jul. 15, 2009, adapted from an article by Olga Morawczynski from CGAP dated Jul. 14, 2009, pp. 1-3, accessed via <www.mbuguanjihia.com/business/what-you-dont-now-about-mpesa.html> on Mar. 25, 2019.
McKinley, “Trumpet Mobile Wallet Takes-Off”, May 6, 2008, CardFlash, pp. 1-5, accessed via <https://cardweb.com/news/2008/05/trumpet-mobile-wallet-takes-off> on Mar. 25, 2019.
Anonymous, “Radioshack, Trumpet launch prepaid mobile money”, Apr. 1, 2008, FierceWireless, pp. 1-3, accessed via <https://www.fiercewireless.com/wirelessiradioshack-trumpet-launch-prepaid-mobile-money> on Mar. 25, 2019.
Anonymous, “RadioShack to offer Trumpet Mobile service—plan includes mobile money transfer capabilities”, Apr. 1, 2008, The Prepaid Press—Where Prepaid Converges, pp. 1-2, accessed via <www.prepaidpress.com/features/radioshack-to-offer-trumpet-moblie-service.html> on Mar. 25, 2019.
Lugmayr, “RadioShack and Trumpet Mobile launch prepaid mobile phone service”, posted Apr. 1, 2008, updated Aug. 11, 2010, I4U News, pp. 1-5, accessed via <https://www.i4u.com/19814/radioshack-and-trumpet-mobile-launch-prepaid-mobile-phone-service> on Mar. 25, 2019.
U.S. Appl. No. 14/928,105, Mar. 7, 2019, Final Office Action.

Related Publications (1)

	Number	Date	Country
	20160055483 A1	Feb 2016	US

Provisional Applications (1)

	Number	Date	Country
	61562301	Nov 2011	US

Continuations (1)

	Number	Date	Country
Parent	13680824	Nov 2012	US
Child	14928521		US

Using a mobile wallet infrastructure to support multiple mobile wallet providers

Information

Patent Number

Date Filed

Date Issued

Inventors

Original Assignees

Examiners

Agents

CPC

Field of Search

US

International Classifications

Disclaimer

Term Extension

Abstract