Systems and methods for secure wireless payment transactions when a wireless network is unavailable

Systems, methods, and devices are disclosed which allow a mobile device user to complete financial transactions even when the mobile device is not connected to a wireless network. The systems, methods, and devices of the present disclosure may utilizing a combination of an encrypted lockbox containing out of network payment codes on the mobile device and a matching set of out of network payment codes stored on a server of a payment authority.

BACKGROUND

The present invention relates generally to electronic commerce. More specifically, but not by way of limitation, the present invention relates to systems and methods for conducting wireless payment transactions when a wireless network is unavailable.

Cell coverage is not ubiquitous and cannot be guaranteed to be available in all locations. However, some types of mobile device payment systems may connect to services over cellular or other wireless networks to authorize and settle transactions with merchants. Thus, the unavailability of a cellular or wireless network can result in a failure to complete the financial transaction. A mobile device user cannot always accurately predict whether a wireless network will be available when the user is choosing to patronize a particular merchant.

Accordingly, there may be a need to provide an out-of-network option to allow mobile device users to use their mobile devices as payment devices even when a wireless network is unavailable.

SUMMARY

Illustrative embodiments of the present invention are shown in the drawings and are summarized below. These and other embodiments are more fully described in the Detailed Description section. It is to be understood, though, that there is no intention to limit the invention to the forms described in this Summary or in the Detailed Description.

Systems, methods, and devices are disclosed which allow a mobile device user to complete financial transactions even when the mobile device is not connected to a wireless network. The systems, methods, and devices of the present disclosure may utilizing a combination of an encrypted lockbox containing out of network payment codes on the mobile device and a matching set of out of network payment codes stored on a server of a payment authority.

In a first set of embodiments, a method for authorizing a transaction includes: receiving at a payment authority server system, from a point of sale terminal, a request to authorize the transaction using a payment code provided to the point of sale terminal via a mobile device, the payment code associated with a state of disconnection between the mobile device and a wireless network; determining that the received payment code matches a payment code contained within at least one set of stored payment codes at the payment authority server system; authorizing the transaction to the point of sale terminal based on the determination; marking the received payment code as used in the at least one set of stored payment codes at the payment authority server system; and transmitting a replacement payment code to the mobile device in response to the mobile device connecting to a wireless network

In a second set of embodiments, a payment authority server system includes at least one processor and at least one memory communicatively coupled with the at least one processor. The at least one memory stores executable code that, when executed by the at least one processor, causes the at least one processor to: receive from a point of sale terminal a request to authorize a transaction using a payment code provided to the point of sale terminal via a mobile device, the payment code associated with a state of disconnection between the mobile device and a wireless network; determine that the received payment code matches a payment code contained within at least one set of stored payment codes; authorize the transaction to the point of sale terminal based on the determination; mark the received payment code as used in the at least one set of stored payment codes at the payment authority server system; and transmit a replacement payment code to the mobile device in response to the mobile device connecting to a wireless network.

In a third set of embodiments, a method for conducting a transaction includes: receiving a request from a user for a payment code at a mobile device; determining that a wireless network is unavailable to the mobile device; retrieving a payment code from a digital lockbox of the mobile device in response to the determination that the wireless network is unavailable, the payment code associated with a state of disconnection between the mobile device and a wireless network; providing the retrieved payment code to a point of sale terminal to authorize the transaction; and communicating with a payment authority server to receive a replacement payment code for the digital lockbox in response to the mobile device reconnecting to the wireless network.

DETAILED DESCRIPTION

In the systems, methods, and devices of the present application, a set of out-of-network payment codes may be stored both at an encrypted lockbox of a mobile device and a payment authority server. When a user of the mobile device chooses to conduct a transaction and the mobile device is out of range of a cellular or other wireless network, the mobile device may retrieve an out-of-network payment code for use in authorizing the transaction. The payment authority may receive the out-of-network payment code from a merchant point-of-sale terminal, authorize the transaction based on the out-of-network payment code, and render that particular out-of-network payment code invalid as the transaction is completed. When the mobile device reconnects to the wireless network, the mobile device may receive one or more replacement out-of-network payment codes for storage in the lockbox.

Thus, various embodiments may omit, substitute, or add various procedures or components as appropriate. For instance, it should be appreciated that the methods may be performed in an order different than that described, and that various steps may be added, omitted or combined. Also, aspects and elements described with respect to certain embodiments may be combined in various other embodiments. It should also be appreciated that the following systems, methods, devices, and software may individually or collectively be components of a larger system, wherein other procedures may take precedence over or otherwise modify their application.

As used in the present disclosure and appended claims, the term “merchant” is to be broadly construed as a provider of goods and services. In the following discussion, a merchant may be sometimes referred to as “the first user.”

A mobile-payment-card platform in accordance with these illustrative embodiments provides, among other things, a server-side digital wallet and a mobile device-side wallet for mobile payment cards that overcomes the shortcomings (e.g., risk of loss or theft) associated with other payment methods that reside within the mobile device itself. In these illustrative embodiments, no credentials (account numbers, balances, or other sensitive information) associated with the user's payment methods, i.e., cards, reside in the mobile device itself. Instead, a secure network infrastructure distributes and manages the payment methods and their associated credentials, the mobile device acting merely as one means for the user to communicate with the server-side digital wallet and the merchant point-of-sale to access a variety of flexible services surrounding use of the mobile payment methods.

FIG. 1illustrates a functional block diagram of a system100in which various illustrative embodiments of the invention can be implemented. In system100, distributor105, merchant's agent110, merchant115, payment authority120, wireless carrier125, and payment-card service provider140are able to communicate with one another via network135. A user's mobile device—e.g., a cellular or Personal Communication Service (PCS) phone—is also able to communicate with nodes connected with network135via wireless carrier125. In some embodiments, network135includes, but is not necessarily limited to, the Internet.

It will be understood that the wireless network utilized by the mobile device referred to herein can be a cellular communication network such as a GSM network, a COMA network, a 3G network, a 4G network, WiFi, WiMAX, etc. Further, it will be understood that the mobile device can communicate with the payment card management platform via the Internet or the World Wide Web. Also, the mobile device can connect to the payment card management platform via one or more wired or wireless Metropolitan Area networks (MANs); one or more wired or wireless local area networks (LANs); one or more wired or wireless Wide Area networks (WANs); one or more wired or wireless Personal Area networks (PANs); etc. Further, it will be understood that the various components are configured to communicate using the requisite communication protocols and signal schemes.

The system100inFIG. 1may build on existing payment systems operated by payment service providers140such as, without limitation, MOCAPAY, FIRST DATA and COMDATA. Payment service provider140, among other things, administers the financial aspects of payment cards, including keeping track of the balance associated with a particular payment method, settlement, reporting to merchants, and other functions.

Merchant115sells goods, services, or both to consumers either directly or with the assistance of merchant's agent110. That is, merchant's agent110may facilitate the distribution and sale of payment cards issued by merchant115by acting as an intermediary between merchant115and any of the following: (1) a payment-card service provider140, (2) mobile-payment-card distributors105, (3) mobile-payment-card purchasers (those giving the mobile payment cards to others), and (4) mobile-payment-card recipients (consumers who use the mobile payment cards in commerce). A consumer holding such a mobile payment card can use the mobile device to purchase goods or services from the particular merchant that issued the mobile payment card, as explained above. How the holder of a mobile payment card uses the mobile device to make purchases from the issuing merchant is discussed further below. As should be understood from one skilled in the art, the use of the mobile device described herein is not limited to the strict use of a payment card but can include the use of loyalty cards, coupons, gift cards, or other incentives.

Payment authority120processes the source of funds for transactions carried out from a user's mobile device such as the user's reloading of a mobile payment card or purchase of a mobile payment card on behalf of someone else. In such transactions, payment authority120acts as an agent of the merchant to collect funds from the user's credit card or other payment source. In some examples, an entity acting as a payment authority120in certain contexts may also be a distributor105in other contexts.

Distributor105markets mobile payment cards and, in some embodiments, is somewhat analogous to an entity such as a grocery store chain which markets conventional plastic, magnetically encoded payment cards for a variety of other merchants on racks in its grocery stores with the assistance of a conventional-payment-card merchant's agent. Distributor105can take on a variety of different forms, depending on the particular embodiment.

In one example, distributor105may be an entity (not necessarily a merchant) that operates a Web site or other electronic communication channel where payment cards for a number of different merchants are offered in an aggregated fashion. In another embodiment, a single merchant markets its payment cards via remote distribution channels, local distribution channels, or both. For example, a merchant may market its payment cards via a remote distribution channel such as a Web site or other networked electronic communication channel using Application Programming Interfaces (APIs) supplied by merchant's agent110or another entity. That is, a merchant may use flexible APIs provided by merchant's agent110to customize a Web site or other networked electronic communication channel to offer its payment cards in a manner consistent with the merchant's particular brand identify, logos, etc. A merchant may also employ local distribution methods in a store (at the point of sale). In such examples, the payment card can be “mobilized” (made accessible to the recipient via the recipient's mobile device) at the point of sale.

In yet another embodiment, distributor105may be a social networking Web site where the interests and preferences of a potential mobile-payment-card recipient are revealed to that person's friends and family. For example, John may discover on a social networking web site that his friend Alan likes to shop at a particular merchant, and John can purchase a mobile payment card for that merchant at the social networking site for Alan. The above are merely a few examples of distributors105. Mobile payment cards can be marketed in a wide variety of ways and settings.

In an illustrative embodiment, merchant115receives the funds from a user's purchase of a mobile payment card minus a predetermined fee that is paid to the merchant's agent110.

FIG. 2is a diagram showing interactions among various entities involved in the distribution and use of mobile payment cards in a system200, in accordance with an illustrative embodiment of the invention. InFIG. 2, payment card system210represents a system operated by a conventional payment-card service provider140such as, without limitation, FIRST DATA or COMDATA. Various embodiments of the invention preserve the existing payments infrastructure supporting the use of payment cards and overlay them with a payment authority205, which is explained below. Other entities involved are a merchant point of sale system225, a mobile device220, and carriers or other entities (“CARRIERS/OTHERS” inFIG. 2)215and their associated distribution systems (see distributor105inFIG. 1). In the discussion ofFIG. 2below, interactions among these entities are identified by their corresponding reference numerals in parentheses.

In some embodiments, mobile device220can use a variety of different access methods such as, without limitation, Short Message Service (SMS) messages, Multimedia Message Service (MMS) messages, Wireless Access Protocol (WAP), an application, or voice to obtain perishable authorization codes240from payment authority205in making payments from a variety of different tenders (forms of payment), including mobile payment cards. Mobile device220can also use a variety of methods, including Near Field Communications (NFC) and any of the above examples, to provide one-use perishable authorization codes to merchant point of sale systems225in making electronic purchases260.

For example, mobile device220may receive a perishable authorization code240for use with a specific transaction. Mobile device220may provide the perishable authorization code240to a merchant point-of-sale (POS) system225to pay for a transaction via NFC communications or another method, and the merchant POS system225may receive payment authorization from the payment authority based on the perishable authorization code. Additional details and examples regarding the use of perishable authorization codes240can be found, for example, in the aforementioned '489 patent.

A user of mobile device220may also receive targeted marketing messages250before, during, or after a mobile purchase via payment authority205and may purchase235mobile payment cards from a carrier215or other distributor105such as a social networking Web site. The targeted marketing messages are assisted by the ability of merchant point of sale system225to submit marketing rules, content, or both265to payment authority205.

Payment authority205may be an example of payment authority205described above with reference toFIG. 1. Payment authority205may facilitate the activation230of mobile payment cards sold by a carrier or other entity215(or other distributor105) in cooperation with payment card system210via communication link275. Payment card system210may also provide, among other things, settlement and reporting services270to the merchant.

When the user of mobile device220makes a purchase using a mobile payment card, mobile device220contacts payment authority205using any of a variety of access methods (e.g., SMS, MMS, WAP, HTTP, or other browser technology, application, voice) to provide an optional personal identification number (PIN) by which payment authority205authenticates mobile device220. Payment authority205provides mobile device220with one-time perishable (time-limited) authorization codes240and balances for various tenders available to that user, including mobile payment cards. In the present example, the user of mobile device220selects a specific mobile payment card to be used in making the purchase. The mobile-payments-enabled merchant point of sale system225submits255the authorization code provided by mobile device220and the transaction amount to payment authority205. Payment authority205routes the transaction parameters to payment card system210, which ensures that the requested amount is available on the indicated mobile payment card. If everything checks out, payment card system210informs payment authority205, which, in turn, conveys a return authorization to the merchant point of sale system225, completing the transaction.

With this high-level background in place, the remainder of this Detailed Description focuses primarily on the use of mobile payment cards when a wireless network is unavailable.

FIG. 3is a block diagram of an illustrative system300for conducting a transaction. System300may be an example of the system100or system200described above with respect toFIG. 1orFIG. 2. System300includes a payment authority server system205-a, the Internet135-a, cellular network135-b, mobile device220-a, and merchant point-of-sale (POS) terminal225-a. Each of these elements may be in communication, directly or indirectly. Payment authority server system205-amay be an example of payment authority120described above with reference toFIG. 1or payment authority server205described above with reference toFIG. 2. The Internet135-aand cellular network135-bmay be examples of network135described above with reference toFIG. 1. Mobile device220-amay be an example of the mobile device220described above with respect toFIG. 2. Merchant POS terminal225-amay be a component of the merchant POS system(s)225described above with reference toFIG. 2.

In the example ofFIG. 3, payment authority server system205-aincludes an out-of-network payment code generation module305, an out-of-network payment code receiving module310, a transaction authorization module315, and a data store320of out-of-network payment codes. Each of these components may be in communication, directly or indirectly. Each of the respective modules305,310,315,320in payment authority server system205-amay be implemented by hardware, software, or a combination of hardware and software. In certain examples, a single hardware device may implement the functionality of one or more modules305,310,315,320. Additionally or alternatively, the functionality of one or more modules305,310,315,320may be implemented by a distributed across a number of autonomous devices.

In the present example, the out-of-network payment code generation module305generates a number of out-of-network payment codes for a user of mobile device220-a. These out-of-network payment codes may be transmitted to mobile device220-aover the Internet135-aand cellular network135-b. Mobile device220-amay receive the out-of-network payment codes and store them in an encrypted lockbox. A corresponding set of matching out-of-network payment codes may be associated with the user of the mobile device220-aand stored in data store320.

While mobile device220-ais connected to cellular network135-band the user of mobile device220-awishes to conduct a transaction, mobile device220-amay request and receive dynamically generated perishable payment codes. These perishable payment codes may be associated with specific transactions, and provided to merchant POS225-a, which routes the perishable payment codes to payment authority205-aover the Internet135-afor authorization.

However, if mobile device220-ais disconnected from cellular network135-b(e.g., out of range), the user of mobile device220-amay still conduct transactions with merchant POS terminals using the generated out-of-network payment codes stored in the encrypted lockbox of mobile device220-a. When the user of mobile device220-adesires to conduct a transaction and mobile device220-adetermines that mobile device220-ais disconnected from cellular network135-b, mobile device220-amay prompt the user to authorize use of one of the out-of-network payment codes. If authorization is given, mobile device220-amay provide the out-of-network payment code to the merchant POS terminals225-avia NFC, the display of the mobile device220-a, or any other means. The merchant POS225-amay then route the received out-of-network payment code over the internet135-ato payment authority server system205-a, which receives the out-of-network payment code at out-of-network payment code receiving module310.

Transaction authorization module315may determine that the received out-of-network payment code matches one of the payment codes stored in data store320(e.g., by comparing the payment code to each of the payment codes stored in data store320to identify an identical match) and authorize the transaction based on the match. The transaction authorization module315may also mark the received out-of-network payment code used in the data store320, and render the used code unusable for a predetermined period of time. If payment authority server system205-areceives the same out-of-network payment code after it has been rendered unusable, or if the payment authority server system205-adetermines that a received out-of-network payment code does not match any of the out-of-network payment codes of data store320, the transaction may be rejected.

In certain examples, the out-of-network payment code may generate out-of-network payment codes having two components: a first component provided by payment authority server system205-a, and a second component known to the user of mobile device220-a. In these examples, only the first component of each out-of-network payment code may be provided to mobile device220-a, and the user will be expected to complete the out-of-network payment code as an added measure of security. In certain examples, the length of the out-of-network payment codes provided to mobile device220-amay be variable.

In certain examples, the out-of-network payment codes provided to and stored by mobile device220-amay have limited periods of validity. Thus, while mobile device220-ais connected to cellular network135-b, the out-of-network payment codes may be changed and updated as periods of validity expire. However, depending on the location of the user, it may be beneficial to adjust the period of validity for one or more of the out-of-network payment codes based on a location of the mobile device. For example, if payment authority server system205-adetects that mobile device220-ais near an area of low reception where a risk of disconnecting from the cellular network135-bis likely, the period of validity for one or more of the stored out-of-network payment codes provided to mobile device220-amay be extended. Additionally or alternatively, mobile device220-amay store one or more out-of-network payment codes that are valid indefinitely.

FIG. 4is a block diagram of another example system400for conducting a transaction. System400may be an example of system100, system200, or system300described above with respect toFIG. 1,FIG. 2, orFIG. 3. System400includes a payment authority server system205-b, the Internet135-c, cellular network135-d, mobile device220-b, and merchant point-of-sale (POS) terminal225-b. Each of these elements may be in communication, directly or indirectly. Payment authority server system205-bmay be an example of the payment authority120described above with reference toFIG. 1or the payment authority servers205described above with reference toFIG. 2orFIG. 3. The Internet135-cand cellular network135-dmay be examples of network135described above with reference toFIG. 1orFIG. 3. Mobile device220-bmay be an example of the mobile device220described above with respect toFIG. 2orFIG. 3. Merchant POS terminal225-bmay be a component of the merchant POS system(s)225described above with reference toFIG. 2and/or an example of merchant POS terminal225-adescribed above with reference toFIG. 3.

In the present example, mobile device220-bincludes payment code request receiving module405, wireless connectivity evaluation module410, payment code providing module415, cellular transceiver420, NFC transceiver425, and encrypted lockbox data store430, which stores out-of-network payment codes435. Each of these components may be in communication, directly or indirectly.

As described in the above examples, mobile device220-bmay communicate with payment authority205-bover cellular network135-dand the Internet135-cto receive perishable payment codes to authorize transactions with merchants. To conduct a transaction, the user may first request a payment code at payment code request receiving module405. Wireless connectivity evaluation module410may communicate with cellular transceiver420to determine whether mobile device220-bis connected to cellular network135-d.

When mobile device220-bis in communication with cellular network135-d, payment code providing module415may request and receive a dynamically generated perishable payment code from payment authority205-bin real-time by way of the Internet135-c, cellular network135-d, and cellular transceiver420. Payment code providing module415may then provide the received payment code to merchant POS terminal225-bfor processing over NFC transceiver425or another type of transceiver (e.g., Bluetooth, Wi-Fi, etc.). However, if mobile device220-bis disconnected from cellular network135-dpayment code providing module which decrypts the lockbox data store430, retrieves one of the out-of-network payment codes435previously provided by payment authority205-band transmits the out-of-network payment code to merchant POS225-bover NFC transceiver425for processing and approval. The out-of-network payment code may then be marked as used or invalid, and discarded immediately or at a future time. In certain embodiments, instead of using transceiver425to provide the payment code to merchant POS terminal225-b, mobile device220-bmay display the payment code to the user and/or the merchant, and the user and/or the merchant may provide the payment code to merchant POS terminal225-b.

In certain examples, mobile device220-bmay be configured to adjust a period of validity for one or more of the out-of-network codes435stored by encrypted lockbox data store430according to a location of mobile device220-bor another criterion. Additionally or alternatively, one or more of the out-of-network payment codes435stored by encrypted lockbox data store430may be valid for a fixed or indefinite amount of time.

In examples where the payment code includes a first component provided by payment authority205-band a second component known by the user of mobile device220-b, mobile device220-bmay prompt the user to enter the second component in order for the payment code to be provided to merchant POS terminal225-b.

Once connectivity with cellular network135-dis regained, mobile device220-bmay communicate with payment authority205-bto receive replacement out-of-network payment codes for used or expired out-of-network payment codes435stored by encrypted lockbox data store430.

FIG. 5is a flowchart diagram of an example method500of conducting a transaction. The method500may be performed, for example, by payment authority120ofFIG. 1or payment authority205ofFIGS. 2-4.

At block505, a request to authorize a transaction is received from a point of sale terminal using a payment code provided to the point of sale terminal via a mobile device. The received payment code is associated with a state of disconnection between the mobile device and a wireless network. At block510, it is determined that the received payment code matches a payment code contained within at least one set of stored payment codes at the payment authority server system. At block515, the transaction is authorized to the point of sale terminal based on the determination of block510. At block520, the received payment code is marked as used in the at least one set of stored payment codes. At block525, a replacement payment code is transmitted to the mobile device in response to the mobile device connecting to the wireless network.

FIG. 6is a flowchart diagram of an example method600of initializing a lockbox of out-of-network payment codes for a mobile device. The method600may be performed, for example, by payment authority120ofFIG. 1or payment authority205ofFIGS. 2-4.

At block605, the payment authority determines whether a particular merchant allows the use of out-of-network payment codes at the merchant's business. For the purposes of this discussion, the financial transaction is described as a purchase of goods or services. However, one of skill in the art will recognize that the method of the invention can be adapted to any financial transaction. If the merchant allows the use of out-of-network payment codes, the payment authority creates a set of out-of-network payment codes for a mobile device lockbox associated with a user at block610.

A set of payment codes may consist of one or more individual tokens; each token can be a randomly generated series of numbers provided by the payment authority. In addition, the token can include certain digits generated by the payment authority and certain digits known or selected by the mobile device user. The length of the token is determined by the overall number of payment codes activated by the payment card management platform. For the ease of identification and to ensure quick processing, the tokens that make up the out-of-network payment codes may be a defined length that is different from the defined length of real time payment codes. By way of example only, payment codes that are activated on a real time basis through communication with a wireless network may have a length of 5 digits. In order to readily distinguish the out-of-network payment codes, the out-of-network tokens may have a length of 9 digits.

Once the set of out-of-network payment codes is created at block610, the payment authority sets up encryption and a PIN or other access credentials for the lockbox at block615. The payment authority then transmits the lockbox to the mobile device at block620and stores a matching set of out-of-network payment codes at the payment authority at block625. For ease of organization, the payment card management platform can organize the out-of-network payment codes stored on the platform by merchant, or other category that makes matching payment codes received from merchants with stored payment codes.

FIG. 7is a flowchart diagram of an example method700of updating a set of out-of-network payment codes according to the principles of the present disclosure. The method700may be performed, for example, by payment authority120ofFIG. 1or payment authority205ofFIGS. 2-4.

At710, an initial set of out-of-network payment codes is transmitted a mobile device for storage in an encrypted lockbox. At block715, the initial set of out-of-network payment codes is stored on a server of the payment authority in a file associated with a specific merchant. At block720, a request is received from a mobile device to update the out-of-network payment codes stored at the lockbox of the mobile device. At block725, new out-of-network payment codes are generated if a lockbox is not present, if a predetermined expiration period for one or more stored out-of-network payment codes has expired, or if one or more stored out-of-network payment codes have been used. At block730, a user of the mobile device is prompted to decrypt the lockbox on the mobile device (e.g., by entering a decryption PIN or other credential). At block735, the new out-of-network payment codes are transmitted to the lockbox of the mobile device. At block740, the new out-of-network payment codes are stored on the server of the payment authority.

FIG. 8is a flowchart diagram of an example method800of conducting a transaction according to the principles of the present disclosure. The method800may be performed, for example, by payment authority120ofFIG. 1or payment authority205ofFIGS. 2-4.

At block810, a payment code is received from a point-of-sale terminal with a request to complete a financial transaction. At block815, the received payment code is compared to a current list of active real-time payment codes. If the received payment code is found in the list of active real-time payment codes, the transaction is authorized at block820. If the received payment code is not found in the list of active real-time codes, the received payment code is compared to a list of out-of-network payment codes stored by a server of the payment authority at block825. If the received payment code is found in the out-of-network payment code list, the transaction is authorized at block830, and the out-of-network payment code is marked on the as used and rendered inoperable at block835.

FIG. 9is a flowchart diagram of an example method900of conducting a transaction according to the principles of the present disclosure. The method900may be performed, for example, by mobile device225ofFIGS. 2-4.

At block905, a request is received from a user for a payment code at a mobile device. At block910, a determination is made that a wireless network is unavailable to the mobile device. At block915, a payment code is retrieved from a digital lockbox of the mobile device in response to the determination that the wireless network is unavailable. The payment code is associated with a state of disconnection between the mobile device and the wireless network. At block920, the retrieved payment code is provided to a point of sale terminal to authorize the transaction. At block925, the mobile device communicates with a payment authority server to receive a replacement payment code for the digital lockbox in response to the mobile device reconnecting to the wireless network.

FIG. 10is a flowchart diagram of an example method1000of conducting a transaction according to the principles of the present disclosure. The method1000may be performed, for example, by mobile device225ofFIGS. 2-4.

At block1010, an application with an encrypted lockbox is run on a mobile device. At block1015, a user request for a payment code for a financial transaction is received. At block1020, the user is alerted that a network is unavailable and queried as to whether an out-of-network payment code is to be used. At block1025, user authorization to use an out-of-network payment code is received. At block1030, the out-of-network payment code is provided to the user on the display of the mobile device. At block1035, the user provides the out-of-network payment code to a merchant for authorization of the transaction.

FIG. 11is a flowchart diagram of an example method1100of conducting a transaction according to the principles of the present disclosure. The method1100may be performed, for example, by mobile device225ofFIGS. 2-4.

At block1110, a request for a payment code is received from a user. At block1115, an availability of a network (e.g., a cellular network) is determined. At block1120, the user is queried as to whether an out-of-network payment code is to be used in response to the unavailability of the network. At block1125, a digital lockbox of the mobile device is decrypted, and an out-of-network payment code is selected in response to the user authorizing use of the out-of-network payment code. At block1130, the out-of-network payment code is transmitted to a merchant point of sale terminal via an NFC transceiver to authorize the transaction. At block1135, the out-of-network payment code is marked as used, and further use of that code is prevented. At block1140, the mobile device connects to a wireless network. At block1145, updates are requested from a payment authority server to inform the payment authority server of used out-of-network payment codes and replace used or expired out-of-network payment codes in the lockbox with newly generated out-of-network payment codes.

A device structure1200that may be used for one or more components of payment authority120or205, mobile device220, merchant POS terminal225, or for other computing devices described herein, is illustrated with the schematic diagram ofFIG. 12. This drawing broadly illustrates how individual system elements of each of the aforementioned devices may be implemented, whether in a separated or more integrated manner. Thus, any or all of the various components of one of the aforementioned devices may be combined in a single unit or separately maintained and can further be distributed in multiple groupings or physical units or across multiple locations. The example structure shown is made up of hardware elements that are electrically coupled via bus1205, including processor(s)1210(which may further comprise a DSP or special-purpose processor), storage device(s)1215, input device(s)1220, and output device(s)1225. The storage device(s)1215may be a machine-readable storage media reader connected to any machine-readable storage medium, the combination comprehensively representing remote, local, fixed, or removable storage devices or storage media for temporarily or more permanently containing computer-readable information. The communications system(s) interface1245may interface to a wired, wireless, or other type of interfacing connection that permits data to be exchanged with other devices. The communications system(s) interface1245may permit data to be exchanged with a network.

The structure1200may also include additional software elements, shown as being currently located within working memory1230, including an operating system1235and other code1240, such as programs or applications designed to implement methods of the invention. It will be apparent to those skilled in the art that substantial variations may be used in accordance with specific requirements. For example, customized hardware might also be used, or particular elements might be implemented in hardware, software (including portable software, such as applets), or both.

FIG. 13is a functional block diagram of a computer server (“server”)1300that distributes and manages mobile payment cards in accordance with an illustrative embodiment of the invention. The server1300may be an example of the device structure1200described above with reference toFIG. 12. In this embodiment, server1300may be a component of payment authority120or205. InFIG. 13, processor1210-acommunicates over data bus1205-awith input devices1220-a, display1225-a, communication systems1245-a, storage devices1215-a(e.g., hard disk drives, floppy disk drives, optical drives, flash memory, etc.), and memory1230-a. ThoughFIG. 13shows only a single processor, multiple processors or a multi-core processor may be present in some embodiments.

Input devices1220-ainclude, for example, a keyboard, a mouse or other pointing device, or other devices that are used to input data or commands to server1300to control its operation. Communication systems1245-amay include, for example, various serial or parallel interfaces for communicating with a network135(seeFIG. 1) or one or more peripherals.

Memory1230-amay include, without limitation, random access memory (RAM), read-only memory (ROM), flash memory, magnetic storage (e.g., a hard disk drive), processors, optical storage, or a combination of these, depending on the particular embodiment. InFIG. 13, memory1230-aincludes payment authority platform1305, which distributes and manages mobile payment cards and out of network payment codes. In doing so, payment authority platform1305accesses and manipulates mobile payment card data1310, which may reside, at least in part, on storage devices1215-a. In certain examples, memory1230-amay be implemented by one or more peripheral or network devices in communication with server1300.

As mentioned above, payment authority platform1305implements a server-side digital wallet for the mobile payment card data. A “mobile payment card” is, thus, a digital construct (stored digital data) that replaces a physical (e.g., plastic, magnetically encoded) payment card. In this illustrative embodiment, server1300stores account information for each mobile-payment-card holder. That is, each mobile payment card user initially creates an account on server1300. This account information includes, for each mobile payment card belonging to a particular user, (1) the user's mobile phone number, (2) the account number of the particular mobile payment card (analogous to a card number of a physical payment card), (3) the merchant that issued the mobile payment card, and (4) a server-side lockbox that houses a number of out-of-network payment codes. In some embodiments, server1300stores additional information or different information from that just indicated. Note, however, that, in this particular embodiment, the balance remaining on the payment card is not stored on server1300. Instead, the balance is tracked by the payment-card service provider that operates the applicable payment card system. As mentioned above, no credentials associated with a payment card reside on the user's mobile device.

In one illustrative embodiment, payment authority platform1305is implemented as software that is executed by processor1210-a. Such software may be stored, prior to its being loaded into RAM for execution by processor1210-a, on any suitable computer-readable storage medium such as a hard disk drive, an optical disk, or a flash memory. In general, the functionality of payment authority platform1305may be implemented as software, firmware, hardware, or any combination or sub-combination thereof. The methods carried out by payment authority platform340are explained more fully above.

Moreover, as disclosed herein, the term “memory” or “memory unit” may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices or other computer-readable mediums for storing information. The term “computer-readable medium” includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, a SIM card, other smart cards, and various other mediums capable of storing, containing or carrying instructions or data.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a computer-readable medium such as a storage medium. Processors may perform the necessary tasks.