System and method for managing payment in transactions with a PCD

A system and method for managing payment in a transaction using a portable computing device (“PCD”) includes a mobile wallet token being received from an account issuing entity. Next, the mobile wallet token is stored in memory within a PCD payment platform (i.e., a cloud payment solution). A PCD token that corresponds with the mobile wallet token is generated by the PCD payment platform. The PCD token is transmitted over a communications network to a PCD. The mobile wallet token corresponds to at least one of: a credit card account, an alternative or non-traditional payment account, a stored value account, an account from a financial institution, and a merchant based card account. A mobile wallet token may be generated in response to receiving input from an on-line portal that future use of a payment account with a PCD is desired or in response to input received from a point-of-sale terminal.

DESCRIPTION OF THE RELATED ART

Portable computing devices (PCDs) are becoming necessities for people on personal and professional levels. These devices may include cellular telephones, portable digital assistants (PDAs), portable game consoles, palmtop computers, and other portable electronic devices.

PCDs are often utilized to conduct financial transactions. For example, PCDs may be used to check bank account balances, transfer funds between bank accounts, and for paying bills. While PCDs are useful for these types of transactions, there is a growing need in the art for utilizing PCDs in other types of transactions.

These other types of transactions may include those in which physical tokens, such as credit cards, gift cards, and stored value cards, are typically used. One problem faced by many consumers is that each consumer may be issued a separate account corresponding to a single merchant or single service provider. Often, the merchant or service provider will send each consumer a physical token that corresponds to the account. Each physical token typically has account information provided on it as well as machine-readable codes so that point-of-sale (“POS”) terminals can easily process these machine-readable codes.

In addition to machine-readable codes, each physical token usually has human-readable codes as a back-up for the machine-readable code if the machine-readable code fails for a particular transaction. In some instances, a merchant or service provider may not have a machine reader to read the machine-readable code. In such scenarios, the human-readable code may be used.

Physical tokens may also be required by merchants or service providers as a form of identification of the consumer and his or her corresponding account. Often, physical tokens may be required by a merchant or service provider so that any value associated with the token may be redeemed by the consumer.

If a consumer has a plurality of accounts, such as on the order of five or more, then the consumer will likely carry the same amount of physical tokens on his or her person. This can be problematic because the physical tokens do consume space and do require the consumer to remember to carry them on his or her person. If a consumer has ten or more accounts which corresponds to ten or more physical tokens, then the management of these physical tokens becomes significantly burdensome and problematic for the consumer.

Accordingly, what is needed is a system and method that may overcome the problems associated with physical tokens. Specifically, a system and method is needed for eliminating the use of physical tokens for various types of transactions so that a consumer may track one or more accounts with merchants and/or service providers with ease using a single PCD.

SUMMARY OF THE DISCLOSURE

According to one exemplary aspect of the system and method, a mobile wallet token is received from an account issuing entity. Next, the mobile wallet token is stored in memory within a portable computing device payment platform. A portable computing device token that corresponds with the mobile wallet token is generated by the portable computing device payment platform. The portable computing device token is transmitted over a communications network for use in transactions in which an operator selects a portable computing device to make a payment. The mobile wallet token corresponds to at least one of: a credit card account, an alternative or non-traditional payment account, a stored value account, an account from a financial institution, and a merchant based card account.

Each mobile wallet token may be generated in response to receiving input from a point-of-sale system that future use of a payment account with the portable computing device is desired. Alternatively, a mobile wallet token may be generated by an account issuing entity in response to receiving input from an on-line portal that future use of a payment account with the portable computing device is desired.

With the mobile wallet tokens and PCD tokens managed by the PCD payment platform, this structure offers at least two layers of security for credit card or other type of payment account data. The mobile wallet tokens and the PCD tokens may not contain any relevant account data. The correspondence or relevance of PCD tokens to their matching mobile wallet tokens is only known to the PCD payment platform. Similarly, the correspondence or relevance of mobile wallet tokens to actual payment accounts (i.e. credit card accounts, gift card accounts, bank accounts, etc.) is only known to the account issuing entity, like the alternative payment systems, credit card systems, bank card systems, and vaults. As described above, these account issuing entities are responsible for generating the mobile wallet tokens.

DETAILED DESCRIPTION

In this description, the terms “communication device,” “wireless device,” “wireless telephone,” “wireless communication device,” and “wireless handset” are used interchangeably. With the advent of third generation (“3G”) wireless technology and four generation (“4G”), greater bandwidth availability has enabled more portable computing devices with a greater variety of wireless capabilities. Therefore, a portable computing device may include a cellular telephone, a pager, a PDA, a smartphone, a navigation device, or a hand-held computer, like a tablet PC, with a wireless connection or link.

Referring initially toFIG. 1, this figure is a diagram of a wireless portable computing device (“PCD”)100coupled to a communications network142via a wireless communication link103A which are integral parts of a system101(also referred to herein as a transaction management system101) for managing transactions with the portable computing device100.

Many of the system elements illustrated inFIG. 1are coupled via communication links103to the communications network142. The communication links103illustrated inFIG. 1may comprise wired or wireless links. Wireless links include, but are not limited to, radio-frequency (“RF”) links, infrared links, acoustic links, and other wireless mediums. The communications network142may comprise a wide area network (“WAN”), a local area network (“LAN”), the Internet, a Public Switched Telephony Network (“PSTN”), a paging network, or a combination thereof.

The communications network142may be established by broadcast RF transceiver towers (not illustrated). However, one of ordinary skill in the art recognizes that other types of communication devices besides broadcast RF transceiver towers are included within the scope of this disclosure for establishing the communications network142.

The PCD100is shown to have a RF antenna872(seeFIG. 8) so that a respective PCD100may establish a wireless communication link103A with the communications network142via RF transceiver towers (not illustrated). The portable computing device (PCD)100may support a payment application113that may reside in memory803(SeeFIG. 8) of the PCD100. The PCD100may also include PCD token storage117that may be part of and/or in addition to memory803. The PCD token storage117may contain PCD tokens issued by the PCD payment platform (cloud)50as will be described in further detail below.

The payment application113may allow the PCD100to communicate with the PCD payment platform50over the communications network142. The payment application113may also allow the PCD100to collect information from a machine-readable tag124(also referred to herein as tag124) that may be coupled to an electronic cash register (“ECR”)412(not illustrated inFIG. 1, but seeFIG. 4) of a check-out system90B. Further details about the check-out system90B will be described below in connection withFIG. 3A.

The machine-readable tag124may comprise a unique merchant identifier and a unique terminal (or electronic cash register) identifier that helps the PCD100to manage point-of-sale (POS) transactions. Further details about the machine-readable tag124will be described below in connection withFIG. 2I. The ECR412(not illustrated inFIG. 1, but seeFIG. 4) of the Merchant POS system12may comprise a mechanical or electronic device or combination thereof for calculating and recording sales transactions. The ECR412of the merchant POS system12may produce a physical receipt127at the end of a transaction that lists goods and/or services purchased with the portable computing device100. Further details about the merchant POS system12will be described below in connection withFIG. 4.

The merchant POS system12may be coupled to the merchant enterprise system16via the communications network142. The merchant enterprise system16may support the completion of transactions when credit cards or when bank cards have been selected as a form of payment for a particular transaction. The merchant enterprise system16may be coupled to a vault13. Vault13may be coupled both to the merchant enterprise system16and the merchant acquirer. The vault13may comprise a secure database of credit card data that may be used in later/future transactions as desired by an account holder. The vault13may also issue mobile wallet tokens that are sent to module77of the PCD payment platform as will be described in further detail below. Further details about the merchant enterprise system16will be described below in connection withFIG. 4.

The merchant enterprise system16may be coupled to a merchant acquirer10and one or more credit card systems20A. The merchant acquirer10may be coupled to one or more bank card systems20B supported by financial institutions like banks. Further details about the merchant acquirer10, the credit card systems20A, and bank card systems20B will be described below in connection withFIG. 5.

The merchant enterprise system16may also be coupled to alternative payment systems18. Alternative payment systems18may include, but are not limited to, such systems like PAYPAL™, Google payments, etc. that currently exist as of this writing. The alternative payment systems18may be coupled to a gateway14. Further details about the alternative payment systems18and gateway14will be described below in connection withFIG. 6.

A PCD payment platform50, which may also be referred to as a cloud payment solution as understood by one of ordinary skill in the art, is coupled to the portable computing device100via the communications network142. The PCD payment platform50is responsible for connecting or linking the portable computing device100to the merchant POS system12and merchant enterprise system16.

The PCD payment platform may further comprise a mobile wallet token receiver-storage/PCD token generator module77. Module77of PCD payment platform50may be responsible for receiving and storing mobile wallet tokens that are generated by the vault13of a merchant, alternative payment systems18, credit card systems20A, and bank card systems20B.

The vault13of a merchant may issue a mobile wallet token to module77if an account holder indicates during a payment transaction with a traditional credit card, gift card, bank card, etc, using the merchant POS system12that he or she desires the payment account to be used in future transactions with the account holder's PCD100. The POS system12may prompt the account holder for this information during a routine transaction.

The alternative payment systems18, credit card systems20A, and bank card systems20B, may issue a mobile wallet token to module77if an account holder indicates such action by using an online payment portal, such as portals28,30,32as illustrated inFIG. 1. Specifically, each online payment portal28,30,32may have an option for allowing payments in transactions using a PCD100as illustrated inFIG. 7C, described in further detail below.

The generation and delivery of the mobile wallet tokens are illustrated by dashed lines66that exist between module77and these account issuing entities (vault13, alternative payment systems18, credit card systems20A, and bank card systems20B). Module77is also responsible for generating PCD tokens that correspond with the mobile wallet tokens which are received from the account issuing entities. The PCD tokens are transmitted to a PCD100for storage on the PCD100. The PCD tokens represent the payment accounts which may be accessed with the PCD100when the operator of the PCD100desires to complete a transaction with the PCD100, such as at the point-of-sale system12.

With the mobile wallet tokens and PCD tokens managed by module77of the PCD payment platform, this structure offers at least two layers of security for credit card or other type of payment account data. The mobile wallet tokens and the PCD tokens may not contain any relevant account data. The correspondence or relevance of PCD tokens to their matching mobile wallet tokens is only known to the PCD payment platform50.

Similarly, the correspondence or relevance of mobile wallet tokens to actual payment accounts (i.e. credit card accounts, gift card accounts, bank accounts, etc.) is only known to the account issuing entity, like the alternative payment systems18, credit card systems20A, bank card systems20B, and vaults13. These account issuing entities13,18,20A,20B are responsible for generating the mobile wallet tokens. Further details about the PCD payment platform50will be described below in connection withFIG. 7A.

An operator (also referred to as a PCD consumer) of the PCD100may physically enter an establishment of a merchant, such as a store. The operator may “check-in” with the merchant's enterprise system16using his or her PCD100.

Once “checked-in”, the payment application113running on the PCD100may provide a unique or personalized list of products/services, such as “daily specials,” for the PCD consumer available for purchase that is generated by the merchant enterprise system16working in conjunction with the PCD payment platform50.

The payment application113may allow the PCD consumer to scan-in bar codes associated with products/services44that the PCD consumer may desire to purchase which are located within the establishment of the merchant. After a PCD consumer scans-in a product and/or service, the payment application113working in conjunction with the PCD payment platform50may provide personalized prices for the product and/or service which are significantly less than the ticketed price of the product or service. Further, the payment application113may suggest an ensemble of products or services that may or may not be related to the scanned-in product or service which may be of interest to the PCD consumer.

The payment application113running on the PCD100may support a wishlist of products and/or services that a PCD consumer is interested in but may not purchase until a future time. The payment application113may also support a virtual shopping cart or virtual shopping basket that may contain products and/or services that the PCD consumer desires to purchase before leaving the establishment of the merchant. The payment application113may track a running total cost for the goods/products that the PCD consumer intends to purchase.

When the PCD consumer is ready to purchase the products and/or services in the virtual shopping cart or shopping basket, the PCD consumer may proceed to check-out where the products and/or services may be scanned with a product scanner132(SeeFIG. 4). Prior to or in parallel to the operation of scanning products with the product scanner132, the operator of the PCD100may retrieve the unique terminal identifier and the merchant identifier associated with a tag124of a check-out system90B which is affixed to the ECR412of the Merchant POS system12.

The machine-readable tag124may comprise a machine-readable code222which may be scanned with a camera848(SeeFIG. 8) of the PCD100. A payment application113running on the PCD100may be able to process the scanned machine-readable code222. The machine-readable code222may comprise either a one dimensional or two-dimensional barcode. Further, other machine-readable codes are included within the scope of the invention and may include contactless technologies, such as near-field communications (NFC), WiFi, acoustic, which may or may not be linked to a secure-element, and RFID cards as understood by one of ordinary skill in the art. For these contactless technologies, the tag124may comprise an antenna224coupled to an integrated-circuit chip (not illustrated).

This unique terminal (or ECR) identifier and merchant identifier retrieved by the PCD100may be relayed back to the PCD payment platform50along with a personal identification number (“PIN”). In response to receiving the terminal identifier, merchant identifier, and PIN, the PCD payment platform50may send messages to merchant enterprise system16that may include an identifier corresponding to the operator of the PCD100. The PCD payment platform50may request the merchant enterprise system16for the product scan data being generated by the product scanner132of the merchant POS system12.

In response to this request from the PCD payment platform50, merchant enterprise system16may forward the product scan data to the PCD payment platform50. The PCD payment platform50, in turn, may relay the product scan data to the PCD100so that the product scan data may be displayed on the display device of the PCD100. The PCD100may provide an option that may be selected by an operator to turn off this product scan data from being displayed on the display device of the PCD100while the products130A are being scanned. This product scan data may be displayed adjacent to the personalized pricing that was previously calculated and displayed while the PCD consumer was shopping.

Meanwhile, when the product scanner132of the merchant POS system12is finished scanning the products/services44for purchase, the ECR412may generate a final total of money due for payment in connection with the purchase of the products/services44. This final total data is communicated from the merchant POS system12to the merchant enterprise system16. Based on the identifier associated with the operator of the PCD100received from the PCD payment platform50, the merchant enterprise system16and/or vault13may determine if the operator has one or more accounts stored in the vault13. The merchant enterprise system16then relays the final total to the PCD payment platform50along with a message which indicates if the operator has one or more accounts in vault13. In addition to relaying this final total data to the PCD100, the PCD payment platform50may also retrieve payment accounts available to the operator and that may have been selected by an operator in a predetermined order for display on the PCD100and/or which were identified by the merchant enterprise system16and/or vault13. Alternatively, or in addition, the system101via the tender steering module744of the PCD payment platform50may list the payment accounts in a predetermined order or sequence as will be described below in connection withFIG. 7A.

At this time, or any time during the transaction cycle, an operator of the PCD100may select from one of a plurality of payment methods supported by the PCD payment platform50and which are displayed on the PCD100. Alternatively, an operator of the PCD100may select a plurality of payment methods in order to pay the final total due in connection with the purchased products/services44. Once a payment method or a combination of methods are selected by an operator of the PCD100, the PCD100relays one or more PCD tokens corresponding to the selected accounts to the PCD payment platform50.

When any form of payment is selected by the operator of the PCD100, such as the selection of a credit card account, then the PCD payment platform50may match the PCD token that it receives from the PCD100with a mobile wallet token that was previously loaded in the mobile wallet token receiver/PCD token generator module77. The PCD payment platform may then relay the mobile wallet token matching the PCD token over a secure channel to the merchant enterprise system16.

The merchant enterprise system16may relay the mobile wallet token to the vault13. If there is a matching merchant acquirer token in the vault13corresponding to the mobile wallet token received from the PCD payment platform50, then the vault13may relay the merchant acquirer token to the merchant acquirer10for bank card systems20B. Alternatively, the vault13and/or merchant enterprise system16may relay the mobile wallet token to credit card networks for credit card systems20A. If an alternative payment mobile wallet token is received, such as corresponding to PAYPAL™, then the merchant enterprise system16may relay this mobile wallet token to the alternative payment systems18via the gateway14.

Exemplary credit card networks, may include, but are not limited to, the VISA™ credit card network, the MASTERCARD™ card network, the DISCOVER™ credit card network, the AMERICAN EXPRESS™ credit card network, and other similar charge card proprietary networks. One of ordinary skill in the art recognizes that transactions for merchant gift cards may also follow the same flow with the merchant enterprise system16directing the transaction to the merchant's stored value processor that may be part of the credit card systems20A or alternative payment systems18.

If payment is approved by one of the traditional payment systems20or the alternative payment system18, then the merchant enterprise system16may relay this approval message to the merchant POS system12. The merchant POS system12relays the approval message to the electronic cash register126and to the PCD payment platform50. If payment is approved by one of the alternative payment systems18, the PCD payment platform50may relay this information to the PCD100and the merchant enterprise system16.

The PCD payment platform50may send any payment approval messages to the PCD100for display on the display device of the PCD100. The PCD payment platform50may generate an electronic receipt that can be forwarded and displayed on a display device of the PCD100. Meanwhile, the ECR412may also generate a hard copy receipt127.

FIG. 2Ais a diagram of a screen202A of the PCD100for entering a user's log-in credentials, such as a user name204on the PCD100to access the system101. The user's log-in credentials204may comprise a unique user name selected by an operator of the PCD100. When the user name is entered by the operator of the PCD100, the PCD payment platform50may verify that the user name entered and a unique identifier assigned to the PCD100match by checking client profiles which may be stored in the eWallet module732F (SeeFIG. 7A). One of ordinary skill in the art recognizes that authentication of the operator of the PCD100at this stage may include other security measures beyond just a user name/password. Other security measures which may be used as alternatives or as supplemental security measures to those already described include, but are not limited to, biometrics, secure elements such as integrated-circuit (IC) cards or smart cards, and other like methods in the art of multi-factor authentication.

If the user name and unique identifier assigned to the PCD100do not match, then the PCD payment platform50may deny entry to the system101and prompt the user for correct credentials for a predetermined number of times. If the user name and unique identifier assigned to the PCD100do match, then the PCD payment platform50may prompt the operator of the PCD100for a password206associated with the user name on the account such as illustrated inFIG. 2B.

FIG. 2Bis a diagram of a screen202B for entering additional log-in credentials such as a password206on the PCD100to access the system101. If the correct password206is not entered by an operator of the PCD100after a predetermined number of times, the PCD payment platform50may lock out the account associated with the user name that was entered in the screen202A ofFIG. 2A. If the correct password206is entered by an operator of the PCD100, then the PCD payment platform50may generate a welcome screen202C such as illustrated inFIG. 2C.

FIG. 2Cis a diagram of a screen202C for the PCD100confirming access to system101. The welcome screen202C may also comprise an execution button208that may activate the payment application113residing on and supported by the PCD100. Upon selecting the execution button208, the PCD100may launch the payment application113running on the PCD100which causes the PCD100to generate the next screen202D as illustrated inFIG. 2D.

Instead of a two dimensional bar code, a one dimensional bar code may be employed to provide the unique electronic cash register identifier and the unique identifier associated with the merchant. Exemplary one-dimensional bar codes may include, but are not limited to, U.P.C., Codabar, Code 25—Non-interleaved 2 of 5, Code 25—Interleaved 2 of 5, Code 39, Code 93, Code 128, Code 128A, Code 128B, Code 128C, Code 11, CPC Binary, DUN 14, EAN 2, EAN 5, EAN 8, EAN 13, Facing Identification Mark, GS1-128 (formerly known as UCC/EAN-128), GS1 DataBar formerly Reduced Space Symbology (“RSS”), HIBC (HIBCC Bar Code Standard), ITF-14, Latent image bar code, Pharmacode, Plessey, PLANET, POSTNET, Intelligent Mail Bar code, MSI, PostBar, RM4SCC/KIX, JAN, and Telepen. Other machine readable codes for retrieving the unique identifiers associated with the electronic cash register126and merchant are well within the scope of the invention such as contact-less or wireless communication methods such as near-field communications (NFCs) used with smart cards and RF-ID cards as understood by one of ordinary skill in the art. Further, in another exemplary embodiment, the operator of the PCD100may key-in a human-readable code223associated with the unique identifier of the electronic cash register126and the merchant.

FIG. 2Eis a diagram of a screen202E that shows merchant information212relevant to a transaction and a line item listing214of products during check-out being scanned by a product scanner132coupled to an ECR412(SeeFIG. 4). The merchant information212may comprise information such as, but not limited to, a merchant name, a mailing address of the store, date and time data relevant to the transaction, a store number, and an electronic cash register number, and other like information. The line item listing214of product scan data may comprise information such as, but not limited to, a product number, a short name for the product, a price and other similar information. According to an exemplary embodiment, an operator of the PCD100may shut “off” the line item listing214as a user defined preference which may be stored in the second storage device146B.

While the product scanner132(ofFIG. 4) is scanning the machine-readable product codes from the products/services44, the PCD payment platform50may match these machine-readable product codes with coupon data retrieved from the offer/coupon system (not illustrated), which was made while the PCD consumer was shopping previously. The offer/coupon system may include one or more client profiles associated with the PCD100.

FIG. 2Fis a diagram of a screen202F that shows merchant information relevant to a transaction and a coupon option216that may be selected by an operator of the PCD100. Screen202F may be generated in response to the PCD payment platform50determining a match between a coupon retrieved from the offer/coupon system and products/services44being scanned. Screen202F may list merchant information212and the coupon option216which prompts the operator of the PCD100to decide whether or not to use a coupon that matches a product130which was scanned by the product scanner132A. This coupon option216may be turned off by an operator of the PCD100so that this screen202F is not generated when a match is found by the PCD payment platform50.

An operator of the PCD100may allow automatic matching of coupons as they are discovered by the PCD payment platform50. In the exemplary screen202F, the operator of the PCD100is asked to decide whether or not to use a manufacturer's coupon that may reduce the price of purchase for products/services44to zero. If the operator of the PCD100decides not to use the coupon, then the coupon data may remain in storage accessible by the PCD payment platform50until another match is found by the PCD payment platform50.

FIG. 2Gis a diagram of a screen202G that shows merchant information212relevant to a transaction and a total bill for a purchase along with a plurality of payment options218A that may be selected by the operator. In the example illustrated inFIG. 2G, the total amount due for the purchase is $16.90. The payment options218A allow a user to select the expense as a business expense towards taxes. The payment options218A also allow an operator of the PCD100to select among a plurality of payment methods that may have been previously selected by the operator and stored in a user's profile.

In other words, prior to conducting any transactions, an operator of the PCD100may arrange a predetermined listing of the sequence of payment methods which should be displayed to an operator of the PCD100whenever the operator employs the PCD100for a transaction. The operator of the PCD100may also create an association with the predetermined order of payment methods for particular merchants. This means that an operator of a PCD100may have a first sequence of payment methods for a first merchant and a second different sequence of payment methods for a second merchant that are stored in a client profile of the PCD payment platform50.

The PCD payment platform50via a tender steering module744(SeeFIG. 7A) may also display payment options218A. These payment options218A may provide the operator of the PCD100with additional benefits such as credit cards affiliated with a current merchant which may award more loyalty points if the affiliated credit card is used for a purchase.

In other exemplary embodiments, the PCD payment platform50via the tender steering module744as described below in connection withFIG. 7Amay allow the merchant to control the payment options218A that are presented to the operator of the PCD100. In this way, the merchant may be provided with a form of payment steering—an indirect control of how an operator of a PCD100may decide on how to pay for a products/services44through the intelligence provided by the tender steering module744.

The operator of the PCD100may also select one or more different payment methods to pay the total final amount due for a particular purchase which are displayed on the PCD100. So, for example, an operator may select a credit card to pay a portion of the final bill along with payment from a stored value card and payment from a debit card. According to one exemplary aspect of the invention, the current balances of stored value accounts as well as remaining credit on credit card accounts may be displayed in conjunction with the payment options218A that are available for selection by the operator with the PCD100as illustrated inFIG. 2G.

According to another exemplary feature of the system101, credit card issuers as well as debit card issuers and stored value account issuers do not need to send any physical tokens to an operator of the PCD100when new account numbers may be assigned to a particular operator of the PCD100. Instead of mailing physical tokens bearing the new account numbers, the issuers of the new account numbers may update the data a storage device or the secure vault13. A corresponding message may be transmitted from the PCD payment platform50to the operator of the PCD100when new account numbers have been stored in the secure vault13or a storage device in place of old account numbers.

FIG. 2His a diagram of a screen202H that shows an electronic receipt220A that may be provided upon completion of a transaction with a merchant. The electronic receipt220A may comprise a product listing as well as the total price paid for the products/services44which were purchased. The payment method(s) selected by the operator (though not illustrated) may also be displayed on the electronic receipt220A.

FIG. 2Iis a diagram of an exemplary machine-readable tag124that may be coupled to an electronic cash register126of a merchant that is part of a check-out system90B. The machine-readable tag124may comprise a machine-readable code222which may be scanned with a camera848of the PCD100. The payment application113running on the PCD100may be able to process the scanned machine-readable code222.

As noted above, the machine-readable code222may comprise either a one dimensional or two-dimensional barcode. Further, other machine-readable codes are included within the scope of the invention and may include contactless technologies, such as near-field communications (NFC) which may or may not be linked to a secure-element, and RFID cards as understood by one of ordinary skill in the art. For these contactless technologies, the tag124may comprise an antenna224coupled to an integrated-circuit chip (not illustrated).

For check-out scenarios with system90B, the tag124may provide a unique identifier associated with the electronic cash register126and a unique identifier associated with a merchant that operates the electronic cash register126. These unique identifiers may be contained within the machine-readable code and/or associated with the code. The tag124may also comprise a human-readable code223that may be keyed-in by the operator of the PCD100instead of scanning the machine-readable code222with the PCD100.

FIG. 3Ais a diagram of hardware components and software components running on a portable computing device100for supporting transactions with the portable computing device100. The components may include a device identification module302, a communication hub module310, an operating system platform (“O/S”) module312, a global positioning satellite (“GPS”) module322, a geo-positioning/triangulation module324, a WiFi detector module326, a scan module328, a secure element module877, and a near field communication module330.

One of the software components may include the payment application113. The payment application113may further comprise additional modules for rendering visuals on the device display908. These additional modules may include, but are not limited to, a common display module314, a retail display module316, a restaurant display module318, and other display modules #N320. Further details about the additional modules that are part of the payment application113will be described below in connection withFIG. 3B. The PCD100may also comprise PCD token storage177. PCD token storage117may contain PCD tokens generated by module77of the PCD payment platform50. PCD token storage177may comprise hardware and/or software.

The device identification module302may also comprise submodules such as a device identifier or International Mobile Equipment Identity (“IMEI”) module304, a subscriber identity module (“SIM”) serial number module306, and/or a subscriber identifier module or international mobile subscriber identity (“IMSI”) module308. Usually, a portable computing device100would usually have only one of these modules to uniquely identify the portable computing device100to the communications network142and the PCD payment platform50as understood by one of ordinary skill in the art.

The communication hub module310is responsible for relaying information between the device identification module302and the PCD payment platform50as well as between the GPS module322and the PCD payment platform50. The communication hub module310may support conventional mobile phone communication protocols as understood by one of ordinary skill in the art.

The GPS module322and geo-positioning/triangulation module324may assist the PCD payment platform50with determining the physical location of the portable computing device100. Once the PCD payment platform50is aware of the physical location of the portable computing device100, the PCD payment platform50may determine in which merchant location the portable computing device100is located.

The WiFi detector module326may communicate with a WiFi local area network (“LAN”) router142A. The Wifi LAN router142A may allow an operator of the portable computing device100to alert the PCD payment platform50when the portable computing device has entered into the location of a merchant. In this way, the PCD payment platform50may be able to provide unique offers to the operator of the portable computing device100before the operator decides to complete a transaction for products/services44.

The check-out system90B may also comprise machine-readable tags124that are positioned at each point-of-sale terminal or electronic cash register (“ECR”)126. Each machine-readable tag124of the check-out system90B, like the check-in system90A, may comprise a 2-D QR barcode124A and/or an RFID tag124B.

The scan module328may work in conjunction with the camera848of the portable computing device100. The scan module328may process scans of the 2-D QR barcodes that are present on respective machine-readable tags124. Similarly, the secure element module877and NFC module330may work with RFID tag124B that may be part of either the check-in system90A or the check-out system90B. The O/S module312may comprise any one of conventional mobile phone operating systems known as of this writing. For example, the O/S module312may comprise an android operating system, an iPhone operating system, a Java 2 Platform Micro Edition (“J2ME”) operating system, a Research-In-Motion (“RIM”) operating system, and a Binary Runtime Environment for Wireless (“BREW”) MP operating system as understood by one of ordinary skill in the art.

FIG. 3Bis a diagram of several software components for a payment application113running on a portable computing device100. The software components may form the common display module314, the retail display module316, and the restaurant display module318ofFIG. 3A. The software components for the common display module314may include, but are not limited to: a splash module314A, a home screen module314B, a sign-in module314C, a password module314D, a scanning module314E, a manual scan module314F, a personal identification number (“PIN”) module314G, a locations module314H, an NFC tap module314I, a search module314J, a show map module314K, a store receipts module314L, a search receipt module314M, a “my account” module314N, a preferences module314O a devices module314P, a sign-account module314Q, and a disable account module314R as understood by one of ordinary skill in the art.

In this example, the splash module314A performs the user and device authentication check on the display808, such as a touch screen display, of the PCD100. The home screen module314B allows the operator to return to a home screen or default screen for the PCD100. The sign-in module314C allows manages any credentials that the operator enters into the PCD100. The password module314D reviews any received credentials for a match with the password selected by the operator. The scanning module314E activates an automatic scanning feature supported by the PCD100so that the camera may automatically focus the camera for848for reading a tag124. The manual scan module314F activates a manual scanning feature in which the operator may control the focus of the camera848for reading a tag124.

The personal identification number (“PIN”) module314G allows the operator to change his or her PIN as understood by one of ordinary skill in the art. The locations module314H supports a function in which the PCD100may display the closest merchants who support the PCD payment features. The NFC tap module314I allows an operator to activate NFC functionality of the PCD100. The search module314J allows an operator to search for specific transactions that were made using the PCD100. The show map module314K may support functions such as a geographical map relative to the location of the PCD100as well as maps of building plans for merchants who support payments with the PCD100.

The store receipts module314L allows an operator to pull up copies of electronics receipts for any transaction completed by the PCD100. The search receipt module314M allows the operator to search for specific electronic receipts that were generated by the PCD100. The “my account” module314N allows an operator to review the current balances and pending payments supported by the PCD100for transactions completed with the PCD100. The preferences module314O allows an operator to display preferences for the account associated with the PCD100, such as allowing the operator to select a preferred sequence of payment accounts to use with the PCD100for a transaction.

In some embodiments, the preferences module314O ofFIG. 3Bmay allow the operator of the portable computing device100to preconfigure the sequence or order of payment accounts that are displayed by the portable computing device100. This preconfiguration impacts when the operator is ready to make a payment using the portable computing device100. This preconfiguration of sequence or order of payment accounts may be a setting that cannot be overridden by the merchant via the tender steering module744. In other words, this preconfiguration setting or option supported by the preferences module314O of the PCD100may deactivate or disable some or all of the functions of the tender steering module744which is described below in connection withFIG. 7A.

This preconfiguration may also allow the operator of the PCD100to make a purchase with a one touch or single touch action instead of multiple actions to scroll through available payment account options. However, if an operator does not set up this preconfiguration, a default setting of the portable computing device100may allow the sequence or order of payment accounts to be controlled by the merchant as described below in connection with the tender steering module, which is a focus ofFIG. 7A.

The devices module314P allows an operator to review the multiple PCDs100that may be used by the operator to complete transactions. For example, if the operator had a plurality of mobile phones, then the devices module314P may display a listing of the mobile phones associated with use of the mobile payment account. The sign-account module314Q may allow operator to enter his or her electronic signature for completing transactions such as ACH transactions which may require an electronic signature. The disable account module314R may support a function in which an operator may turn off his or her mobile payment account so that unauthorized use may not occur with other PCDs100that may be associated with the account.

The software components for the retail display module316may include, but are not limited to: a scan tag module316A, a PIN module316B, a first waiting module316C, pay module316D, a paid module316E, and in-store module316F, a list items module316G, a second waiting module316H, a paying module316I, a paid module316J, a receipt module316K, and a check-in module316L as understood by one of ordinary skill in the art.

The scan tag module316A may automatically activate the camera848for focusing on a tag124. The PIN module316B may allow operator to change his or her PIN that may be associated only with retail transactions. The first waiting module316C may activate a timer that an operator may select when he or she is waiting for the ECR412to communicate with the PCD payment platform50. The pay module316D may allow the operator to automatically pay a balance when the balance is displayed by the PCD100. The paid module316E notifies the operator of the authorization or decline of each form of payment previously selected as well as the overall success or decline of the full transaction.

The in-store module316F may allow the operator to indicate that he or she is present within the store of a merchant prior to checking-in or checking-out using a tag124. The list items module316G may allow operator to redisplay any items being checked out for a payment transaction associated with the PCD100. A second waiting module316H may be activated by an operator of the PCD100when he or she is waiting for their payment options after a total bill for the transaction has been displayed. The paying module316I, which works with the tender steering module744ofFIG. 7A, may display the amount due along with a selection of applicable tender/payment methods previously loaded to the PCD payment platform50.

The operator of the PCD is given the opportunity to select one or more methods of payment to satisfy the amount due. The receipt module316K allows an operator display the electronic receipt associated with the last transaction or the current transaction being processed by the PCD100. The check-in module316L may be activated by the operator when she or he is about to use the check-in system90A ofFIG. 1A.

The software components for the restaurant display module318may include, but are not limited to: an in-store module318A, an items full module318B, an items check module318C, a partial pay module318D, a partial paid module318E, a split check module318F, an items partial module318G, and an items remaining module318H as understood by one of ordinary skill in art.

The in-store module318A may allow operator to alert the PCD payment platform50that the PCD100is present within a restaurant. The items full module318B displays the full list of items scanned in or otherwise entered by the “sales associate”. The items check module318C allows an operator of the PCD100start a payment process associated with a restaurant transaction so that the operator does not need to wait for a waiter or waitress.

The partial pay module318D allows the operator of the PCD100to pay with the PCD100in addition to another form of payment not supported by the PCD100such as by a physical token like a credit card carried by the operator of the PCD100. In the case where multiple parties each identify themselves as payors of the full amount due, the partial paid module318E notifies the each operator of the approval or decline of their portion of the entire amount due.

The split check module318F allows an operator to split a check with another person who may be dining with the operator of the PCD100. The items partial module318G displays only the items that have been identified by the operator of the PCD as his/her portion of the full bill. The items remaining module318H displays all items and remaining amount due that has not yet been satisfied during a split check.

The skinning capability module332provides a function for enabling a third party to utilize the full functionality of the system but with the look-n-feel of their choosing.

FIG. 4is a diagram illustrating details for the merchant point-of-sale (“POS”) system12and the merchant enterprise system16ofFIG. 1for completing a sales transaction with a portable computing device100. The merchant POS system12may comprise a store controller410and an electronic cash register (“ECR”)412. The ECR412may comprise a drawer for storing cash currency. The ECR412may also print a receipt127for a customer with a printing device, like a printer (not illustrated).

The ECR412may be coupled to a handheld (or fixed) scanner132which may be used to scan other machine-readable labels attached to one or more products/services44. The scanner132may comprise a bar code reader or any type of similar device used to collect information from machine-readable labels attached to products/services44.

The ECR412may also be coupled to a reader (or terminal)128, such as a mag-stripe reader or other such device for reading any one of a number of tokens123such as credit cards, debit cards, loyalty cards, stored value cards such as gift cards, and the like.

For example, the reader128may comprise a device that reads magnetic stripes on cards, integrated circuit cards, and near-field-communication (NFC) cards as understood by one of ordinary skill in the art. The reader128may be coupled with a keypad129so that a consumer may enter appropriate information relative to any token that may be scanned or read by the reader128.

The ECR412is also coupled to the store controller410. The store controller410may support one or more electronic cash registers (ECRs)126for a particular location of a merchant. The store controller410, as understood by one of ordinary skill in the art, may comprise a computer server for tracking and matching scanned product codes with a product inventory database (not illustrated separately) which is maintained by the store controller410.

The store controller410may receive product data that is produced by the product scanner132and which is relayed by the ECR412. The store controller410may be responsible for securing authorization for payment from a consumer after a token is read by the POS terminal128B. The store controller410may support one or more product specific languages as understood by one of ordinary skill in the art such as, but not limited to, unified POS and JAVA™ POS.

To secure authorization for payment, such as for a credit or debit card, the store controller410communicates the merchant enterprise system16via the communications network142. The merchant enterprise system16may comprise an Ewallet system402, a credit switch404, a data update module406, and an enterprise router408.

As illustrated inFIG. 4, the store controller410communicates with the enterprise router408of the merchant enterprise system16. The router408may comprise a device that interconnects two or more computer networks, and selectively interchanges packets of data between them, as is understood by one of ordinary skill in the art.

The router408ofFIG. 4couples the store controller410to credit card system20A, the vault13, and merchant acquirer10for traditional payment processing. The router408ofFIG. 4also couples the store controller410to alternative payment systems18. Traditional payment processing may include, but is not limited to, processing payments from accounts associated with traditional credit cards and debit cards. The credit card system20A may comprise exemplary networks such as the VISA™ credit card network, the MASTERCARD™ card network, the DISCOVER™ credit card network, the AMERICAN EXPRESS™ credit card network, and other similar charge or debit card proprietary networks.

Meanwhile, the alternative payment systems18may be responsible for handling and managing non-traditional or alternative payment processing. For example, alternative payment processing may include, but is not limited to, processing payments from accounts associated with certain online financial institutions or other service providers, like PAYPAL™, BILL ME LATER™, Wii™, APPLE™, GREEN DOT™, and mobile phone carriers like SPRINT™ and VERIZON™.

The eWallet system402may provide information and support functions for one or more stored value accounts as well as other types of accounts, such as, but not limited to, credit card accounts and bank accounts, as understood by one of ordinary skill in the art. The data update module406may allow the merchant enterprise system162update its records for any new mobile payment accounts that were used by consumers to pay for transactions.

The electronic cash register (“ECR”)412may comprise a plurality of components. These components may include hardware and software modules. Exemplary components include, but are not limited to, a loyalty module414, a credit module416, a private-label module418, a coupons/discounts module420, a PIN/debit module422, a check module424, an item entry module426, a gift card module428, a cash module430, and a mobile payment module432. The aforementioned components may be selected by an operator of the ECR412in order to complete payment for a transaction.

The ECR412may be coupled to a product scanner132for scanning one-dimensional and two-dimensional barcode labels. The ECR for12may also be coupled to a reader128that may comprise a magstripe and/or an NFC reader. The ECR412may also be coupled to a PIN pad129as well as a receipt printer134for printing a receipt127, a sale total monitor133, and a graphical customer display131that may list one items purchased during a transaction.

FIG. 5is a diagram illustrating details of a merchant acquirer10, vault13, bank card systems20B, and credit card systems20A ofFIG. 1for completing a sales transaction. Account issuing entities, such as the vault13, bank card systems20B, and credit cards systems20A may be coupled to the mobile wallet token receiver-storage/PCD token generator module77. As explained above in connection withFIG. 1, each of these account issuing entities may issue mobile wallet tokens that are sent to and stored in module77. These mobile wallet tokens are transmitted by module77back to account issuing entities when a PCD user desires to pay a transaction with his or her PCD100.

The merchant acquirer10may comprise a pass-through module502and an authorization/settlement module504. The pass-through module502may pass request for payment authorization information directly to a selected bank card system20B. Meanwhile, the authorization/settlement module504may perform some authentication prior to sending request for payment authorization onto a bank card system20B.

The merchant acquirer10usually supports credit card systems that are provided by financial institutions such as banks. For example, credit card20B1may comprise a first bank card like a CHASE™ card from CHASE™ bank while credit card20B2may comprise a second bank card like a bank card from the BANK OF AMERICA™ lender. These institutions usually offer their brand of VISA™ and MASTERCARD™ type cards.

Other credit card systems20A may comprise private-label cards20A1as well as traditional travel and entertainment cards20A2. Private-label cards may include, but are not limited to, merchant based cards20A1asuch as those for specific retail establishments like, THE HOME DEPOT™, WALMART™, NORDSTROM™, SAKS™, etc. Traditional travel and entertainment cards20A2may include, but are not limited to, DINERS CLUB CARD™, AMERICAN EXPRESS™, and DISCOVER™.

While a direct connection is illustrated between the merchant enterprise system16and the credit card systems20A as well as the merchant acquirer10, one of ordinary skill in the art recognizes that such a connection may be a virtual one which is supported by the communications network142. Similarly, a direct connection is illustrated between the merchant enterprise system16and the PCD payment platform50. This direct connection may also comprise a virtual one supported by the communications network142as illustrated inFIG. 1.

FIG. 6is a diagram illustrating details of a gateway14and alternative payment systems18illustrated inFIG. 1. The gateway14may comprise a traditional gateway module14A, a gateway vault14B, and a high-security firewall633. The high-security firewall633provides a secure communication channel between the PCD payment platform50and the gateway14. A traditional gateway module14A may comprise a credit switch602and a transaction transport module604.

The traditional gateway module14A may comprise a payment server as understood by one of ordinary skill in the art. Communications between the PCD payment platform50and the gateway14may comprise a secured socket layer (SSL) encrypted connection and may pass through the high-security firewall633as understood by one of ordinary skill in the art. Usually, the PCD payment platform50issue commands to the gateway vault14B to relay account information to the gateway module14A. The payment gateway module14A may forward the transaction information to one of the alternative payment systems18via the credit switch602.

Specifically, the credit switch602may be responsible for exchanging data with each of the different alternative payment systems18illustrated inFIG. 6. The transaction transport module604may be responsible for exchanging data with a secure data transport module618of the gateway vault14B.

The gateway vault14B may comprise track1/track two data606, card not present (“CNP”) data608, merchant gift card data610, automated clearinghouse (“ACH”) data612, loyalty data614, and credentials616. The gateway vault14B may also comprise a tokenizer620. The tokenizer620may receive a payment authorization request from the PCD payment platform50in format according to specific industry rules based on the payment accounts stored with or associated with the gateway vault14B.

The alternative payment systems18may comprise various different methods of payment available to the operator of the portable computing device100for completing a transaction. The alternative payment systems18may comprise internal systems18A, mobile phone carrier billing18B, e-commerce vendors18C, alternate deposit systems18D, demand deposit schemes18E, and stored value systems18F.

These systems18may also be characterized or described as account issuing entities. These account issuing entities may also generate mobile wallet tokens which are transmitted to the mobile wallet token-receiver/PCD token generator module77via the PCD payment platform50. The systems18may issue mobile wallet tokens if an account holder requests use of an account with his or her PCD100by selecting one or more options via an account management page such as illustrated inFIG. 7Cdescribed below.

An internal system18A may comprise accounts from an Ewallet system for the portable computing device100, such as SWAGG™ brand of mobile payments offered by Outlier (a subsidiary of QUALCOMM, Incorporated). Mobile phone carrier billing systems18B may include, but are not limited to, accounts from wireless carriers as of this writing such as, SPRINT™ accounts, AT&T™ accounts, VERIZON™ accounts, etc. E-commerce vendors18C may include, but are not limited to, accounts from e-commerce vendors like iTUNES™ accounts, GOOGLE™ check out accounts, AMAZON™ payments, BILLMELATER™ accounts, and PAYPAL™ accounts. Alternate deposit systems18D may include be coupled debit systems18D1and the like. Demand deposit systems18E may include ACH transfers18E1and checks18E2. And stored value systems18F may include gift cards18F1offered by a merchant.

FIG. 7Ais diagram illustrating details for the PCD payment platform50illustrated inFIG. 1. The PCD payment platform50manages data between the PCD100and the merchant enterprise system16. The PCD payment platform50may support industry standard compliance measures. For example, the PCD payment platform50may be compliant with Payment Card Industry (“PCI”) standards. In this way, the merchant enterprise system16and the PCD100do not store any sensitive data such as credit card information and personal information like social security numbers, home addresses, etc. Such sensitive data may be stored in the PCD payment platform50.

The PCD payment platform50is also responsible for communicating with a gateway14for establishing a connection with alternative payment systems18. The PCD payment platform50may also relay product scan data sent from the merchant enterprise system16over the communications network142to the PCD100. In this way, the PCD100may display products individually (merchandise/service stock keeping unit—“SKU”) on the display of the PCD100as they are scanned in by the product scanner132of the merchant POS system12. The PCD payment platform50may also relay identification (loyalty), promotions (offers/discounts), and payment information between the PCD100and merchant POS system12as described in further detail below.

The PCD payment platform50may comprise a payment communication module730, a user data store module732, a system datastore module734, a merchant data store module736, a rules engine737, an advertising API720B, an advertising transport module728, a loyalty API720C, a loyalty transport module746, a portal API720D, a portal communications module748, a client API720E, a client device communications module750, a merchant API720F, and a merchant enterprise communications module752.

The payment communications module730may support the communications between the PCD payment platform50and the gateway14that is coupled to the alternative payment systems18. While a direct connection between the PCD payment platform50and the gateway14is illustrated, one of ordinary skill in the art recognizes that this direct connection may be a virtual one using the communications network142ofFIG. 1. The user data store module732may comprise a plurality of submodules that include, but are not limited to, a demographics submodule732A, a device management module732B, a line item and purchase data module732C, a preferences module732D, a vault mappings module732E, and an Ewallet module732F.

The demographics submodule732A may track preferences of the operator of the PCD100as well as characterizations made by the PCD100about the possible race, age, and gender of the operator. The device management module732B may support functions for associating multiple PCDs100with the mobile payment accounts of a single operator. The line item and purchase data module732C may track all purchases made with the portable computing device100. The preferences module732D may store and support any new preferences requested by the operator using a PCD100. The vault mappings module732E may support request for payments from payment accounts associated with the gateway vault14B ofFIG. 1. An Ewallet module732F supports request for managing in a walled account associated with a particular PCD100.

The system datastore module734may comprise a plurality of submodules that include, but are not limited to, a transaction log module734A, a merchant management module734B, a user management module734C, a device management module734D, and a vault mappings module734E.

The transaction log module734A may automatically record and store the line items associated with each transaction paid with the portable computing device100. The merchant management module734B may automatically record and store the various merchants which received payment from the portable computing device100.

The user management module734C may allow the operator of the PCD100to manage various functions and options that are selectable for a given mobile count. The device management module734D may support functions for associating multiple PCDs100with the mobile payment accounts of a single operator. The vault mappings module734E may support request for payments from payment accounts associated with the gateway vault14B ofFIG. 1.

Similarly, the merchant data store module736may comprise a plurality of submodules that include, but are not limited to, a location demographics module736A, a graphic assets module736B, tag mappings module736C, and accepted payment options module736D, a preferences module736E, and MID mappings module736F.

The location demographics module736A may track the various merchant locations that are receiving payments with the PCD100for completing transactions. The graphic assets module736B may support the various graphical elements such as artwork and icons associated with the credit cards. The tag mappings module736C may store the various specific tags124that may be scanned with the PCD100.

The accepted payment options module736D may control the listing of payment options that are displayed on the PCD100when a final amount is listed as due for a transaction. The preferences module736E may store various preferences from merchants such as payment types and costs associated with each payment type that may be selected by an operator of a PCD100. The merchant ID (“MID”) mappings module736F associates the system's single “enterprise” relationship to each of the merchant's individual store locations.

The rules engine737may also comprise a plurality of modules. Exemplary modules include, but are not limited to, a loyalty sign-in module738, a balance display module740, the personalized pricing module742, a tender steering module744, and a product ensemble engine781. The loyalty sign-in module738may be responsible for automatically retrieving loyalty data associated with the portable computing device100. The balance display module740may be responsible for sending the data to the display808of the portable computing device100. Such data may include product scan data received from the merchant enterprise system16as well as the final total do for products/services44that are to be purchased using the portable computing device100.

The personalized pricing module742may be responsible for automatically retrieving offers and coupons from an offer/coupon system (not illustrated) based on the current location of the portable computing device as well as any products/services44that have been scanned in for purchase by the PCD user and/or the merchant POS system12. The offer/coupon system may include a third party offer generators, a consumer package goods (“CPG”) module, and a manufacturer's module.

The rules engine737working in conjunction with the personalized pricing module742may provide the unique and customized or “personalized” pricing for products and/or services displayed by the payment application113. The rules engine737may comprise software or hardware or both.

The product/service ensemble engine781may suggest additional products and/or services that may be related to products/services44that have been scanned-in by the PCD consumer and/or those that are maintained in a wishlist for the PCD consumer. Similar to the personalized pricing module742, while the product/service ensemble engine781has been illustrated inFIG. 7Ato be part of the rules engine737, one of ordinary skill in the art will recognize that the rules engine737could be designed to be part of the product/service ensemble engine781. Alternatively, the product/service ensemble engine may be completely separate from the rules engine737so that two processing entities exist.

The tender steering module744may be responsible for automatically displaying the options for paying for a particular transaction. The options would include those associated with the alternative payment systems18as well as the traditional payment systems20that are associated with the operator of the portable computing device100.

Specifically, with the tender steering module744ofFIG. 7Aworking with the paying module316I ofFIG. 3B, a merchant is provided with the ability to arrange payment accounts in a predetermined order or a predetermined sequence so that they are displayed to an operator of a portable computing device100so that the merchant may steer or influence the operator of a portable computing device100towards one or more payment accounts favored or desired by the merchant.

These payment accounts may be presented in the predetermined order or sequence once the tender steering module744receives a signal that indicates the consumer/operator is ready to make a payment on his or her purchase with the portable computing device100. These payment accounts may include merchant branded or otherwise known as private brand payment accounts which may permit a merchant to collect a rebate on the purchase made by the consumer/operator. Such rebates are usually percentage based and are usually on the order of about 5% of a purchase made by consumer as understood by one of ordinary skill in the art. Other payment accounts may include those accounts in which the merchant may pay a lower interchange rate for processing payments for a transaction. Other accounts that may lower interchange rates for merchants may include stored value accounts like merchant branded gift card accounts.

The tender steering module744may promote the use of partial payment with gift cards that do not have value equal to the purchase price. The operator may then select from the portable computing device100another form of payment account in addition to the stored value account if the stored value account does not have sufficient value to cover the entire purchase price. In this way, merchants may ensure that low value gift cards are utilized by the consumer so that the merchant may clear out gift card accounts. When merchants clear out gift card accounts, then this may substantially minimize account reporting services required for gift card accounts, especially for low value gift card accounts (such as those under a value on the order of $10 where the cost of the reporting service may approach or exceed the amount of the value maintained in the stored value account).

The system101through the tender steering module744may order or sequence the payment accounts on a portable computing device100in such a fashion so that the most desirable or favored payment accounts by the merchant are presented first to the consumer while the least favored or less desirable payment accounts are pushed or placed at the very end of a list for display on the portable computing device100. Accounts presented at the end of the list may require additional scrolling effort for the consumer to reach by utilizing a series of sequenced displays as understood by one of ordinary skill in the art.

For example, if the consumer had a merchant branded gift card account, a merchant branded credit card account, and a non-merchant branded credit card account, then the system may allow the merchant to present the merchant branded gift card account first, the merchant branded credit card account second, and the non-merchant branded credit card account third—assuming that this ranking or listing of payment accounts favors the merchant in which the least expensive is displayed first while the most expensive is displayed last relative to the transaction costs which may be assessed against the merchant. This ranking of payment accounts may also prove beneficial for those non-merchant branded credit card accounts, such as rewards cards, which may have a significantly higher amount of fees that are charged to the merchant and may be used by the consumer.

The system101via the tender steering module744may also support an intelligence in which payment accounts are presented in a sequence on the PCD100that is determined by the actual purchase price for the transaction. For example, the consumer may have a debit card payment account as well as a gift card account. Certain fixed transactional fees may apply to the debit card account while no fees or a percentage of fees may apply to the gift card account. If transaction fees which apply to the debit card account far exceed the percentage of fees corresponding to the gift card, then the system101via the tender steering module744may select the gift card as the first option to present to the consumer for completing a transaction for the benefit of the merchant.

For example, if a consumer's final purchase price is $1.03 and his debit card charges a fixed fee of $0.50 per transaction to the merchant while the gift card account may only charge 5% of the transaction to the merchant, then the tender steering module744may strongly favor or present the gift card as the top choice for the consumer on the portable computing device instead of the higher fee debit card relative to the final purchase price.

In addition to presenting or sequencing the payment accounts for display on a portable computing device100in such a fashion so that the most desirable or favored by the merchant are presented first to the consumer while the least favored or less desirable payment accounts are pushed or placed at the very end of a list, the system101via the tender steering module101will enable merchants to promote or supply additional offers in order to steer or influence consumers towards a payment account desired by a merchant.

For example, the merchant may provide personalized and unique offers to consumers on the PCD100after the system101via the tender steering module744looks-up the consumer's history with the merchant or on other transactions. These personalized and unique offers may be presented adjacent to the payment accounts on the PCD100desired by the merchant for the consumer to use to complete a transaction. A merchant may present a reward, like a certain percentage discount, on the PCD100in order to persuade a consumer to use a payment account desired by the merchant. These personalized and unique offers may be random in nature or presented in sequences depending on the frequency of use or frequency of transactions completed by the consumer with a merchant.

The merchant may set up certain business rules with the tender steering module744in order to control the development of the personalized and unique offers presented to each consumer on his or her PCD100. For example, the merchant may set up a rule that if a transaction is greater than a predetermined amount of money, then the tender steering module744via the pay modules316D and/or316I may present a certain desired payment account coupled with a percentage discount on the transaction to the consumer.

As another example, the merchant may set up a rule in the tender steering module744that reviews the loyalty program participation of the consumer and what the history of the consumer has been in the program. If the consumer has reached a certain number of visits and/or transaction volume (like money spent and/or or number of items) with the merchant, then the tender steering module744may offer a unique and personalized discount that could include a percentage discount on the transaction for the consumer if they use a specific payment account, like a merchant branded payment account. This allows the merchant to influence the payment account selection habits of the consumer since the consumer will likely want to use a payment account that generally may provide occasional discounts beyond other forms of payment accounts.

By looking at the first six digits of payment accounts available to the consumer, the system101via the tender steering module744may determine a status of the payment account such as its benefits level (i.e. whether the payment account qualifies as a gold level, a platinum level, a diamond level, etc.) and what corresponding interchange rates may apply based on that benefits level. Depending upon what fees will be assessed for the merchant for a particular payment account, the system101via the tender steering module744may organize or sequence the payment accounts in order from least expensive to most expensive relative to the fees assessed against the merchant for each payment account.

Usually payment accounts with lower status such as regular credit cards without any elite status (like diamond, gold, or platinum levels) will have lower interchange rates because there are fewer benefits provided to the payment account holder. As of this writing, merchants may pay on the order of between about 2.14% to about 5.00% on interchange rates for cards with elite status. Meanwhile, cards without this elite status, especially the merchant branded credit cards or gift cards, will usually be significantly less and, in some instances, the merchant may even receive rebates with their own branded credit card or gift card account.

According to another exemplary aspect, the rules maintained and executed by the tender steering module744may determine that the consumer does not have a certain merchant branded payment accounts that would be desirable for the merchant. Since the tender steering module744has access to the consumers contact information through a loyalty program, the rules in the tender steering module744may allow the merchant to offer the consumer to accept a new payment account starting with the current transaction at hand. If the consumer decides to accept the offer for the new payment account offered by the merchant via the tender steering module744, then the system101via the tender steering module744and other modules may run an immediate credit and/or background check to determine if the consumer should be approved for this new payment account. This credit and background check may happen on-the-fly and may be completed within a few minutes upon acceptance by the consumer to take this new merchant branded payment account offered by the merchant through the tender steering module744.

The client device communications module750may support communications between the PCD payment platform50and the portable computing device100. While a direct connection between the PCD payment platform50and the portable computing device100is illustrated, one of ordinary skill in the art recognizes that this direct connection may be a virtual one using the communications network142ofFIG. 1. The client device communications module750may establish communications with the portable computing device100through a client API720E. Specifically, the client device communications module750may establish a persistent communication with the portable computing device100that may be characterized as a form of secure chat messaging.

The merchant enterprise communications module752may support communications between the PCD payment platform50and the merchant enterprise system16. While a direct connection between the PCD payment platform50and the merchant enterprise system16is illustrated, one of ordinary skill in the art recognizes that this direct connection may be a virtual one using the communications network142ofFIG. 1. The merchant enterprise communications module752may establish communications with the merchant enterprise system16by using a merchant API720F. A secure communication channel may be established over the communications network142between the merchant enterprise communications module752and the merchant enterprise system16as understood by one of ordinary skill in the art.

All of the inbound and outbound communications for the PCD payment platform50may pass through firewall/security layers722A-F as understood by one of ordinary skill in the art. Each firewall/security layer722may comprise a device or set of devices designed to permit or deny network transmissions based upon a set of rules.

FIG. 7Bis a diagram illustrating several online portals28-32for managing a payment account according to one exemplary embodiment of the invention. The payment account portals28-32may allow a consumer to open a new account. The payment account portal28may comprise an enrollment module28A, a cards module28B, a devices module28C, a favorites module28D, an account preferences module28E, a reporting module28F, and a mobile wallet token generator module28G. The mobile wallet token generator module28G may create a mobile wallet token that is transmitted to module77of the PCD payment platform when an account holder desires to allow payments for transactions using his or her PCD100.

FIG. 7Cis a diagram illustrating an exemplary account on-line (web) management portal28,30,22for generating mobile wallet tokens. The on-line portal28,30,32may provide a user interface for managing any type of an account online. An account that may be designated for payments using a PCD100may include, but are not limited to, traditional credit card accounts, like VISA™, MASTERCARD™, DISCOVER™, AMERICAN EXPRESS™, DINERS CLUB™ accounts; alternative payment accounts like PAYPAL™, GOOGLE™, AMAZON™, BILL ME LATER™, Wii™, APPLE™, GREEN DOT™; and mobile phone carrier accounts like SPRINT™, VERIZON™, AT&T™ type accounts; accounts from financial institutions like banks, such as, but not limited to, CHASE™ accounts, BANK OF AMERICA™ accounts; as well as private-label type accounts, such as, but not limited to, merchant based card accounts such as those for specific retail establishments like, THE HOME DEPOT™, WALMART™, NORDSTROM™, SAKS™, etc.

As illustrated inFIG. 7C, an operator may select whether an account may be used for a PCD payments or not with a simple user interface28G that includes, but is not limited to, a checkbox or drop-down menu as understood by one of ordinary skill in the art. If the operator of the user interface28G selects an account for PCD payment use, then in block1210, the corresponding account issuing entity, such as a financial institution20B or credit card issuer20A, via the mobile wallet token generator module28G ofFIG. 7Bmay issue a mobile wallet token that is destined for the PCD payment platform50as illustrated inFIG. 1. The delivery of mobile wallet payment tokens from account issuing entities to the PCD payment platform are illustrated with dashed lines66between the vault13, the alternative payment systems18, the credit cards20A, the bank cards20B, and the mobile wallet token receiver-storage/PCD token generator77.

Referring toFIG. 8, an exemplary, non-limiting aspect of a portable computing device (“PCD”) is shown and is generally designated100. As shown, the PCD100includes an on-chip system822that includes a multicore CPU802. The multicore CPU802may include a zeroth core810, a first core812, and an Nth core814.

As illustrated inFIG. 8, a display controller828and a touch screen controller830are coupled to the multicore CPU802. In turn, a display808external to the on-chip system822is coupled to the display controller828and the touch screen controller830. An NFC antenna879may be coupled to the CPU802and may support functions that work in combination with a secure element module877. The secure element module877may comprise software and/or hardware and/or firmware as understood by one of ordinary skill in the art. The CPU802may also be coupled to the PCD token storage117which may comprise separate hardware and/or software or which may be part of memory803.

FIG. 8further shows that a video encoder834, e.g., a phase alternating line (“PAL”) encoder, a sequential color a memoire (“SECAM”) encoder, or a national television system(s) committee “(NTSC”) encoder, is coupled to the multicore CPU802. Further, a video amplifier836is coupled to the video encoder834and the touch screen display108. Also, a video port838is coupled to the video amplifier836. As shown inFIG. 8, a universal serial bus (“USB”) controller840is coupled to the multicore CPU802. Also, a USB port842is coupled to the USB controller840. Memory404A and a subscriber identity module (“SIM”) card846may also be coupled to the multicore CPU802.

Further, as shown inFIG. 8, a camera848may be coupled to the multicore CPU802. In an exemplary aspect, the camera848is a charge-coupled device (“CCD”) camera or a complementary metal-oxide semiconductor (“CMOS”) camera.

As further illustrated inFIG. 8, a stereo audio coder-decoder (“CODEC”)850may be coupled to the multicore CPU802. Moreover, an audio amplifier852may coupled to the stereo audio CODEC850. In an exemplary aspect, a first stereo speaker854and a second stereo speaker856are coupled to the audio amplifier852.FIG. 8shows that a microphone amplifier858may be also coupled to the stereo audio CODEC850. Additionally, a microphone860may be coupled to the microphone amplifier858. In a particular aspect, a frequency modulation (“FM”) radio tuner862may be coupled to the stereo audio CODEC850. Also, an FM antenna864is coupled to the FM radio tuner862. Further, stereo headphones866may be coupled to the stereo audio CODEC850.

FIG. 8further illustrates that a radio frequency (RF) transceiver868may be coupled to the multicore CPU802. An RF switch870may be coupled to the RF transceiver868and an RF antenna872. As shown inFIG. 4C, a keypad874may be coupled to the multicore CPU802. Also, a mono headset with a microphone860may be coupled to the multicore CPU802. Further, a vibrator device878may be coupled to the multicore CPU802.FIG. 8also shows that a power supply880may be coupled to the on-chip system822. In a particular aspect, the power supply880is a direct current (DC) power supply that provides power to the various components of the PCD100that require power. Further, in a particular aspect, the power supply is a rechargeable DC battery or a DC power supply that is derived from an alternating current (AC) to DC transformer that is connected to an AC power source.

FIG. 8further shows that the PCD100may also include a network card888that may be used to access a data network, e.g., a local area network, a personal area network, or any other network. The network card888may be a Bluetooth network card, a WiFi network card, a personal area network (PAN) card, a personal area network ultra-low-power technology (PeANUT) network card, or any other network card well known in the art. Further, the network card888may be incorporated into a chip, i.e., the network card888may be a full solution in a chip, and may not be a separate network card888.

As depicted inFIG. 8, the display808, the video port838, the USB port842, the camera848, the first stereo speaker854, the second stereo speaker856, the microphone860, the FM antenna864, the stereo headphones866, the RF switch870, the RF antenna872, the keypad874, the mono headset876, the vibrator device878, and the power supply880are external to the on-chip system822.

In a particular aspect, one or more of the method steps described herein may be stored in the memory803as well as in the PCD payment platform50, merchant enterprise system16, merchant POS system12, and other storage devices as computer program instructions. These instructions may be executed by the multicore CPU802, PCD payment platform50, merchant enterprise system16, and merchant POS system12in order to perform the methods described herein. Further, the multicore CPU802, merchant enterprise system16, merchant POS system12, other storage devices, and memory803of the PCD100, or a combination thereof may serve as a means for executing one or more of the method steps described herein.

FIG. 9Ais a diagram of a screen900A that shows merchant information228relevant to a transaction and a total bill for a purchase along with a plurality of offers230which were generated by a tender steering algorithm executed by the tender steering module744. In this exemplary embodiment, the options230were generated by the tender steering module744. Specifically, the tender steering module744of this embodiment generated a 10% off the purchase price if the operator of the PCD100uses a new merchant payment account that may be established relatively instantaneously with the portable computing device100. The tender steering module744also produced a 5% off the purchase price if the operator of the PCD100utilizes a merchant branded gift card.

FIG. 900Bis a diagram of a screen1200B that shows merchant information relevant to a transaction and a total bill for a purchase along with a plurality of payment options218B that may be selected by user and which were re-ordered by a tender steering algorithm744. The payment options218B may also be characterized as the ranked list of payment account types and the tender steering module744. As illustrated inFIG. 9B, the tender steering module744has presented the merchant gift card payment option first, the merchant branded payment account second, and another type of payment account third. The payment options218B may be a result of the tender steering module744weighing the payment options available to the operator as determined from the data the PCD payment platform50receives from the merchant enterprise system16. As noted previously, the merchant enterprise system16and/or the vault13determine if an operator of a PCD100has an existing merchant payment account, like a credit card account or stored value account, contained in the vault13and which may be used as payment for a current transaction.

The final purchase price listed inFIG. 9Bis $63.92. Meanwhile the balance remaining on the merchant branded gift card is $8 and the credit limit of the merchant payment account is listed as $1000. In this way, the operator of the PCD100may select the merchant branded gift card payment option to be used in combination with the merchant branded payment account. Such a selection of payment options, in some cases, would not require any interchange fees from the merchant. In fact, in some cases, the selection of these two payment options could provide rebates for the merchant as understood by one of ordinary skill the art. By controlling the sequence of display for the payment options, a merchant through the tender steering module744may influence or “steer” a consumer towards the payment options which are most beneficial to the merchant.

FIGS. 10A-10Bare flowcharts illustrating a method1000for loading merchant card account data into a vault13for future PCD use with a point-of-sale terminal/system12. Block1005is the first step of method1000A illustrated inFIG. 10A. In block1005, the point-of-sale system12, which may include a graphical customer display131and a MSR/pinpad129as described above in connection withFIG. 4, may receive input designating that a merchant account should be saved in a vault13maintained by the merchant for future payment via a PCD100. In other words, the point-of-sale system12may receive a keystroke from an operator of a PCD100to indicate that the operator desires data from a current merchant credit card being scanned or swiped to be stored in vault13for later use by the PCD100.

Next, in block1010, the point-of-sale system12encrypts the account data extracted from the credit card scan or swipe. In block1015, the point-of-sale system transmits a first authentication code and the encrypted credit card account data to the merchant enterprise system16.

In block1020, the merchant enterprise system16retransmits the encrypted credit card account data with a second authentication code to the vault13. In block1025, the vault13creates a merchant acquirer token with the encrypted credit card account data. The vault13also creates a mobile wallet token destined for the PCD payment platform (cloud)50.

In block1030, the vault13encrypts the merchant acquirer token and the mobile wallet token. In block1035, the vault13transmits the merchant acquirer token with the transaction data to the merchant acquirer10in the mobile wallet token to the PCD payment platform50. Specifically, the vault13transmits the mobile wallet token to the mobile wallet token receiver storage/PCD token generator module77.

In block1040, the mobile wallet token receiver storage/PCD token generator module77stores the mobile wallet token and creates a PCD token corresponding to the mobile wallet token. Subsequently, in block1045, the mobile wallet token receiver storage/PCD token generator module77transmits the PCD token to the PCD100for future use.

In block1050, the merchant acquirer10determines if payment for the transaction should be authorized based on the merchant acquirer token received from the vault13and the transaction data. Block1050may further comprise additional steps in which the merchant acquirer10communicates with the issuing bank for the particular bank card20B used in the transaction.

The method1000A continues as method1000B via block1055inFIG. 10B. in block1055, the merchant acquirer10may generate an authorization response and transmit the merchant acquirer token and the response to the merchant enterprise system16. In block1060, the merchant enterprise system16may store the authorization response in the merchant acquirer token in memory. In block1065, the merchant enterprise system16may transmit the authorization response to the merchant point-of-sale system12. Then method1000B may end.

FIGS. 11A-11Bare flowcharts illustrating a method1100for using a preloaded merchant account from a vault with a PCD100for completing a payment transaction. Block1105is the first step of the method1100A. In block1105, the point-of-sale system12may receive input that payment via a PCD100as desired and transmit a message to the merchant enterprise system16. For example, a cashier operating an electronic cash register412may key-in that a customer desires to pay for a transaction with her PCD100and the electronic cash register412may relay a message to the merchant enterprise system16.

Next, in block1110, the merchant enterprise16may receive confirmation from the PCD payment platform50that the customer desires to pay for the transaction with her PCD100. For example, after the customer informs the cashier operating the electronic cash register412that she desires to pay for her transaction with her PCD100, then the operator of the PCD100may scan in the tag124of the checkout system90B as illustrated inFIG. 1andFIG. 2I. The PCD100transmits the data from the tag124to the PCD payment platform50. The PCD payment platform50, in turn, transmits the data from the tag124as well as an identifier for the operator of the PCD100to the merchant enterprise system16.

Next, in block1115, the merchant enterprise system16receives the identifier associated with the operator of the PCD100. In block1120, the merchant enterprise system16determines if the identifier associated with the operator of the PCD100matches any accounts in the vault13. Next, in block1125if a match exists in the vault13, then the merchant enterprise system16transmits a message to the PCD payment platform50which contains a list of the matching accounts listed in the vault13. This list may enumerate mobile wallet tokens that were created previously as described above in connection with block1025ofFIG. 10A.

Next, in block1130, the PCD payment platform50may apply tender steering rules based on its internal data, such as preferences expressed by the operator of the PCD100, as well as the messages the PCD payment platform50receives from the merchant enterprise system16about matching accounts in the vault13. Further details about the tender steering process are described above in connection withFIG. 9A-9B.

Subsequently, in block1135, the PCD payment platform50transmits the payment options for completing the transaction to the PCD100for selection by the operator. In block1140, a merchant account for payment for completing the transaction is selected by the operator of the PCD100.

Next, in block1145, the PCD token corresponding to the merchant account selected in block1140is transmitted by the PCD100to the PCD payment platform50. In block1150, the PCD payment platform50matches the PCD token with the mobile wallet token in its database which was previously created and sent by the vault13in block1035ofFIG. 10A.

In block1155, the PCD payment platform50transmits the mobile wallet token associated with the selected merchant account to the merchant enterprise system16. The method1100A then continues to block1160as illustrated onFIG. 11B.

FIG. 11Billustrates a continuation flowchart diagram of the method1100B which corresponds with method1100A ofFIG. 11A. Block1160is the first block of continuation method1100B ofFIG. 11B. In block1160, the merchant enterprise system16receives the mobile wallet token transmitted from the PCD payment platform50. The merchant enterprise system16matches the mobile wallet token with the transaction data it has received from the point-of-sale system12in block1165.

Next, in block1170, the merchant enterprise system16transmits the mobile wallet token and the transaction data to the vault13. In block1175, the vault13matches the mobile wallet token with the merchant acquirer token stored in its database within the vault13. The vault13then transmits the merchant acquirer token with the transaction data to the merchant acquirer10in block1180.

In block1185, the merchant acquirer10in communication/combination with the bank card system20B, determines if the payment for the transaction should be authorized based on the merchant acquirer token and the transaction data received. If the transaction should be authorized, then in block1190, the merchant acquirer10and/or the bank card system20may generate an authorization response and transmit the merchant acquirer token and the response to the merchant enterprise system16where this response is logged/stored (block1195).

In block1197, the merchant enterprise system16transmits the authorization response to the merchant point-of-sale system12for proving the payment for the transaction. The process then ends.

FIG. 12is flowchart illustrating a method1200for loading bank issued card data, financial institution (“other card issuer”) credit card data, or alternative payment account data for PCD payments via a secure online portal (i.e., a website)28,30,32. Block1205is the first block of method1200. In block1205, a message may be received from an online portal28,30,32that an account may be used for payments via a PCD100. For example, as illustrated inFIG. 7Cdescribed above, an online portal28,30,32may provide a user interface for managing any type of an account online. As described above, an account that may be designated for payments using a PCD100may include, but are not limited to, traditional credit card accounts, like VISA™, MASTERCARD™, DISCOVER™, AMERICAN EXPRESS™, DINERS CLUB™ accounts; alternative payment accounts like PAYPAL™, GOOGLE™, AMAZON™, BILL ME LATER™, Wii™, APPLE™, GREEN DOT™; and mobile phone carrier accounts like SPRINT™, VERIZON™, AT&T™ type accounts; accounts from financial institutions like banks, such as, but not limited to, CHASE™ accounts, BANK OF AMERICA™ accounts; as well as private-label type accounts, such as, but not limited to, merchant based card accounts such as those for specific retail establishments like, THE HOME DEPOT™, WALMART™, NORDSTROM™, SAKS™, etc.

As illustrated inFIG. 7C, an operator may select whether an account may be used for a PCD payments or not with a simple user interface28G, that includes, but is not limited to, a checkbox or drop-down menu as understood by one of ordinary skill in the art. If the operator of the user interface28G selects an account for PCD payment use, then in block1210, the corresponding account issuing entity, such as a financial institution20B or credit card issuer20A, may issue a mobile wallet token that is destined for the PCD payment platform50as illustrated inFIG. 1by the dashed lines66between the alternative payment systems18, the credit cards20A, the bank cards20B, and the mobile wallet token receiver-storage/PCD token generator77.

In block1215, the PCD payment platform50via the mobile wallet token receiver-storage/PCD token generator77receives the mobile wallet token from the account issuing entity. In block1220, the PCD payment platform50, and specifically the mobile wallet token receiver-storage/PCD token generator77, creates the PCD token corresponding to the mobile wallet token received from the account issuing entity.

In block1225, the mobile wallet token receiver-storage/PCD token generator77transmits the PCD token to the PCD100for future use in a payment transaction. Method1200then ends.

FIGS. 13A-13Bare flowcharts illustrating a method1300for using preloaded bank issued card data, financial institution (“other card issuer”) credit card data, or alternative payment account data with a PCD100for a payment transaction. Block1305is the first block of method1300A. In block1305, the point-of-sale system12may receive input that payment via a PCD100is desired by the customer who would like to complete a payment transaction for a good or service.

Next, in block1310, the merchant enterprise16may receive confirmation from the PCD payment platform50that the customer desires to pay for the transaction with her PCD100. For example, after the customer informs the cashier operating the electronic cash register412that she desires to pay for her transaction with her PCD100, then the operator of the PCD100may scan in the tag124of the checkout system90B as illustrated inFIG. 1andFIG. 2I. The PCD100transmits the data from the tag124to the PCD payment platform50. The PCD payment platform50, in turn, transmits the data from the tag124as well as an identifier for the operator of the PCD100to the merchant enterprise system16.

Next, in block1315, the merchant enterprise system16receives the identifier associated with the operator of the PCD100. In block1320, the merchant enterprise system16and/or vault13determines if the identifier associated with the operator of the PCD100matches any accounts in the vault13. Next, in block1325if a match exists in the vault13, then the merchant enterprise system16transmits a message to the PCD payment platform50which contains a list of the matching accounts listed in the vault13. This list may enumerate mobile wallet tokens that were created previously as described above in connection with block1025ofFIG. 10A.

Next, in block1330, the PCD payment platform50may apply tender steering rules based on its internal data, such as preferences expressed by the operator of the PCD100, as well as the messages the PCD payment platform50receives from the merchant enterprise system16about matching accounts in the vault13. Further details about the tender steering process are described above in connection withFIG. 9A-9B.

Subsequently, in block1335, the PCD payment platform50transmits the payment options for completing the transaction to the PCD100for selection by the operator of the PCD100. In block1340, a bank issued, a financial institution, or an alternative payment provider account may be selected for payment to complete the transaction by the operator of the PCD100.

Next, in block1345, the PCD token corresponding to the account selected in block1340by the operator is transmitted by the PCD100to the PCD payment platform50. In block1350, the PCD payment platform50matches the PCD token with the mobile wallet token in its database which was previously created and sent by account issuing entity in block1210ofFIG. 12.

In block1355, the PCD payment platform50transmits the mobile wallet token associated with the selected account to the merchant enterprise system16. The method1300A then continues to block1360as illustrated onFIG. 13B.

FIG. 13Billustrates a continuation flowchart diagram of the method1300B which corresponds with method1300A ofFIG. 11A. Block1360is the first block of continuation method1300B ofFIG. 13B. In block1360, the merchant enterprise system16receives the mobile wallet token transmitted from the PCD payment platform50. The merchant enterprise system16matches the mobile wallet token with the transaction data it has received from the point-of-sale system12in block1365.

Next, in block1370, the merchant enterprise system16transmits the mobile wallet token and the transaction data to the appropriate account issuing entity. The account issuing entity may be a bank, such as bank card system20B, another type of financial institution or credit card issuer, such as credit card system20A, or an alternative payment provider, such as alternative payment systems as illustrated inFIG. 1.

In block1375, the account issuing entity matches the mobile wallet token with its account data in its database. The account issuing entity then determines if payment for the transaction should be authorized based on the mobile wallet matching and the transaction data in block1380.

In block1385, the account issuing entity may generate an authorization response and transmit the mobile wallet token and the response to the merchant enterprise system16where this response is logged/stored (block1390).

In block1395, the merchant enterprise system16transmits the authorization response to the merchant point-of-sale system12for proving the payment for the transaction. The process then ends.

Certain steps in the processes or process flows described in this specification naturally precede others for the invention to function as described. However, the invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps may performed before, after, or parallel (substantially simultaneously with) other steps without departing from the scope and spirit of the invention. In some instances, certain steps may be omitted or not performed without departing from the invention. Further, words such as “thereafter”, “then”, “next”, etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the exemplary method.

Additionally, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example.

Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the Figures which may illustrate various process flows.

Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL”), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.

Disk and disc, as used herein, includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Although selected aspects have been illustrated and described in detail, it will be understood that various substitutions and alterations may be made therein without departing from the scope of the disclosure, as defined by the following claims.