METHOD AND APPARATUS FOR FACILITATING COMMERCE

Abstract

A method and apparatus facilitate financial transactions using sources of pre-established funds. A source of pre-established funds can be uploaded to a secure server using an app that is operable on a mobile electronic device. The source of pre-established funds can be used by an owner to initiate a financial transaction, such as by using the app to open a tab at a venue, in which the venue might apply a number of charges for the purchase of food, beverage, merchandise, and the like, and can also permit the owner of the source of pre-established funds to add a gratuity to the tab for final charging to the source of pre-established funds. The source of pre-established funds is usable to complete a financial transaction and to thereby cause a financial obligation that arises from the financial transaction to be paid using the source of pre-established funds.

Claims

1. A method of using a source of pre-established funds to perform a financial transaction with another, the another employing a payment processor, the financial transaction including a number of charges, at least a subset of the charges of the number of charges being added by the another during the financial transaction, the financial transaction including an obligation to pay the another for the number of charges, the source of pre-established funds having an amount of available funds, comprising: receiving an initiation input that requests an initiation of the financial transaction; detokenizing a token that is stored in a storage and that is representative of the source of pre-established funds to form a set of data that comprises a Primary Account Number (PAN) of the source of pre-established funds; communicating to at least one of a credit card company and an issuing bank the PAN and an authorization request that the issuing bank authorize use of at least a portion of the amount of available funds to pay the obligation; receiving an authorization code that is representative of an agreement by the issuing bank to make available the at least portion of the amount of available funds; and responsive to the receiving of the authorization code, sending to the another an initiation notification that the financial transaction has been initiated.

2. The method of claim 1, further comprising: storing a mirror copy of the transaction; receiving a charge notification that the another has added a charge from among the number of charges to the financial transaction with a Point Of Sale (POS) system; and updating the mirror copy to include the charge.

3. The method of claim 2, further comprising, responsive to the receiving of the charge notification, communicating to the at least one of the credit card company and the issuing bank another authorization request that the issuing bank authorize an additional amount that includes the charge to pay the obligation.

4. The method of claim 3, further comprising: receiving a decline message that is representative of a notification by the issuing bank that the additional amount will not be available; generating a transaction token that is based at least in part upon the authorization code and that can be detokenized to form a set of data that includes the authorization code; and sending the transaction token to the payment processor in partial payment of the obligation.

5. The method of claim 2, further comprising forwarding the mirror copy to a mobile electronic device subsequent to the updating of the mirror copy.

6. The method of claim 1, further comprising sending to the another as the initiation notification a name of an owner of the source of pre-established funds.

7. The method of claim 1, further comprising: detecting a location of a mobile electronic device that is used by an owner of the source of pre-established funds; determining that the location is within a predetermined proximity of the another; and performing at least one of the detokenizing, the communicating, and the sending responsive at least in part to the determining.

8. The method of claim 1, further comprising triggering the outputting on a mobile electronic device that is used by an owner of the source of pre-established funds an invitation to make the initiation input, the triggering being responsive to at least one of: a determination that a location of the mobile electronic device is within a predetermined proximity of the another, and a determination that the owner is traveling to the another.

9. The method of claim 1, further comprising: receiving another initiation input that requests an initiation of another financial transaction; making a determination that the obligation is unpaid and, responsive thereto, refraining from initiating the another financial transaction while the obligation remains unpaid.

10. The method of claim 1, further comprising receiving as a part of the initiation input a selection input that selects the source of pre-established funds for use in paying the obligation.

11. The method of claim 1, further comprising: detecting a closing input; communicating to at least one of the credit card company and the issuing bank another request that the issuing bank authorize use of another at least portion of the amount of available funds to pay the obligation; receiving another authorization code that is representative of an agreement by the issuing bank to make available the another at least portion of the amount of available funds; and sending the another authorization code to the payment processor in payment of the obligation.

12. The method of claim 11, further comprising: again detokenizing the token to form another set of data that comprises the PAN; communicating the PAN to the at least one of the credit card company and the issuing bank as a part of the another request; generating a transaction token that is based at least in part upon the another authorization code and that can be detokenized to form a further set of data that includes the authorization code; and sending the transaction token to the payment processor as the another authorization code.

13. A method of enabling a financial transaction using a source of pre-established funds having an amount of available funds to pay an obligation that is owed to another who employs a payment processor, comprising: responsive to a predetermined event, communicating to at least one of a credit card company and an issuing bank an authorization request that the issuing bank authorize use of at least a portion of the amount of available funds to pay the obligation; receiving an authorization code that is representative of an agreement by the issuing bank to make available the at least portion of the amount of available funds; generating a transaction token that is based at least in part upon the authorization code and that can be detokenized to form a set of data that includes the authorization code; and sending the transaction token to the payment processor in payment of the obligation.

14. The method of claim 13 wherein the generating of the transaction token comprises generating the transaction token based at least in part upon the authorization code and at least a portion of a Primary Account Number (PAN) of the source of pre-established funds and that can be detokenized to form a set of data that includes the authorization code and the at least portion of the PAN.

15. The method of claim 13, further comprising employing as the predetermined event at least one of: a detection of a closing input on a mobile electronic device that is used by an owner of the source of pre-established funds, a determination that a location of the mobile electronic device has moved from within a predetermined proximity of the another to beyond the predetermined proximity of the another, and a predetermined hour at the another has been exceeded.

16. The method of claim 13 wherein the financial transaction includes a number of charges, at least a subset of the charges of the number of charges being added by the another during the financial transaction, and further comprising adding a gratuity to the number of charges to form the obligation.

17. The method of claim 16, further comprising adding the gratuity responsive to a detection of a gratuity input.

18. A method of making available a source of pre-established funds to perform a number of financial transactions, the source of pre-established funds having an amount of available funds, comprising: receiving a registration input that comprises a Primary Account Number (PAN) of the source of pre-established funds; communicating to at least one of a credit card company and an issuing bank the PAN and a request that the issuing bank authorize use of at least a portion of the amount of available funds; receiving an authorization code that is representative of an agreement by the issuing bank to make available the at least portion of the amount of available funds; responsive to the receiving of the authorization code, generating a token that is representative of the source of pre-established funds and that can be detokenized to form a set of data that includes the PAN; storing the token in a secure storage; and outputting an indication that the source of pre-established funds is available for use.

19. The method of claim 18, further comprising: receiving a selection input that selects the source of pre-established funds for use in paying an obligation that is owed to another who employs a payment processor, the obligation being a part of a financial transaction of the number of financial transactions; communicating to at least one of the credit card company and the issuing bank another request that the issuing bank authorize use of another at least portion of the amount of available funds to pay the obligation; receiving another authorization code that is representative of another agreement by the issuing bank to make available the another at least portion of the amount of available funds; and sending the another authorization code to the payment processor in payment of the obligation.

20. The method of claim 19, further comprising: generating a transaction token that is based at least in part upon the another authorization code and that can be detokenized to form a set of data that includes the authorization code; and sending the transaction token to the payment processor as the another authorization code.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0090] A further understanding of the disclosed and claimed concept can be gained from the following Description when read in conjunction with the accompanying drawings in which:

[0091] FIG. 1 is a schematic depiction of a system that includes a mobile electronic device that is in communication with an enterprise data system in accordance with the disclosed and claimed concept;

[0092] FIG. 2 is a flowchart depicting certain aspects of an improved method in accordance with a first embodiment of the disclosed and claimed concept;

[0093] FIG. 3 is a flowchart depicting certain aspects of an improved method in accordance with a second embodiment of the disclosed and claimed concept; and

[0094] FIG. 4 is a flowchart depicting certain aspects of an improved method in accordance with a third embodiment of the disclosed and claimed concept.

[0095] Similar numerals to similar parts throughout the specification.

DESCRIPTION

[0096] An improved system 2 in accordance with the disclosed and claimed concept is depicted generally in FIG. 1 as including a mobile electronic device 4 that is in accordance with the disclosed and claimed concept that is in communication with a wireless data network 5 that is connected with an enterprise data system 6 that is likewise in accordance with the disclosed and claimed concept. The enterprise data system 6 is an improved apparatus that can perform a number of improved methods that are also in accordance with the disclosed and claimed concept. The mobile electronic device 4 and the system 2 likewise each constitute an apparatus that is in accordance with the disclosed and claimed concept and that likewise can perform improved methods that are also in accordance with the disclosed and claimed concept.

[0097] The enterprise data system 6 is depicted in FIG. 1 as being in communication with a pair of venues that are each indicated at the numeral 8 and as also being in communication with a merchant processor that is indicated at the numeral 10. The two venues 8 are representative of any number of venues with which the enterprise data system 6 can be connected and with which a user who uses the mobile electronic device 4 can perform financial transactions using one or more sources of pre-established funds. The venues 8 can be any type of business or other operation that is capable of performing financial transactions that involve an obligation to pay an amount of money to the venue 8 and thus can include bars, restaurants, theaters, stadiums, and the like without limitation.

[0098] As will be set forth in greater detail elsewhere herein, the exemplary venues 8 are places where the user can open a tab, also known as a check or a bill, in which the venue 8 applies charges as part of the financial transaction, with the charges being based upon purchase of food, beverages, services, merchandise, and the like without limitation, and which are typically applied over a period of time while the tab is open, i.e., active and chargeable. The merchant processor 10 is similar to a venue 8, except that the financial transaction that is conducted with the merchant processor 10 typically is more in the nature of a single purchase. That is, whereas a tab might be opened at a venue 8 and over the course of a number of hours the user might gradually accrue charges that are applied to the tab for the gradual purchase of beverages, food items, pieces of merchandise, etc., with the tab being opened and capable of being charged over a period of time, such as while the user is physically situated at the venue 8, the transaction with the merchant processor is typically orchestrated by a merchant app that is executed on the mobile electronic device 4. That is, and as will be set forth in greater detail elsewhere herein, a mobile vendor app may be executable on a mobile electronic device 4 than enables the user to place items or other things for purchase into a virtual shopping cart and can then execute a purchase command wherein the mobile vendor app initiates operations that result in a payment to the merchant processor 10 via operation of the enterprise data system 6. The merchant processor 10 is representative of any of a wide variety of different merchant processors that are used by merchants and merchant apps to conduct financial transactions with credit card companies and issuing banks on behalf of the merchants, with each such merchant selecting a corresponding merchant processor, it being understood that a plurality of merchants likely will be using the same merchant processor to conduct their respective credit card transactions.

[0099] The mobile electronic device 10 can be said to include a processor apparatus 14, an input apparatus 16, and an output apparatus 20. The input apparatus 16 provides input signals to the processor apparatus 14, and the output apparatus 20 receives output signals from the processor apparatus 14. The input apparatus 16 can include any of a wide variety of input devices such as keys the keypad, a camera, a touch sensitive overlay on a touchscreen, and the like without limitation, and also includes a receiver portion of a wireless transceiver that is in communication with the wireless data network 5 and a GPS receiver. The output apparatus 20 likewise can include any of variety of output devices such as a visual display portion of a touchscreen, a loudspeaker, lights, and the like without limitation, and also includes a wireless transmitter portion of a wireless transceiver that is in wireless communication with the wireless data network 5.

[0100] The processor apparatus 14 can be said to include a processor 24 that can be in the nature of a microprocessor or other processor and that is in communication with a storage 28. The storage 28 can be any of a wide variety of storage devices such as RAM, ROM, EEPROM, FLASH, and the like without limitation and functions as an internal storage area of a computer. The storage 28 has stored therein a number of routines that are indicated generally at the numeral 32 and also has stored therein various data that are indicated generally at the numeral 34. The routines 32 are executable on the processor 24 to cause the mobile electronic device for to perform various operations. As such, the storage 28 can likewise be said to constitute a non-transitory computer readable storage medium having stored thereon software instructions that, when executed by the processor 24, cause the processor 24 to generate control signals for controlling various operations of the mobile electronic device 4. The routines 32 can include various mobile applications, also known as mobile apps, that can be downloaded via the wireless transceiver on the mobile electronic device for the interface with the wireless data network 5. Such mobile apps can include an improved app such as which enables a tab to be opened on behalf of the user at one of the venues 8. The mobile apps can further include any number of merchant apps, also known as vendor apps, that enable commerce with a particular merchant and which enable a financial transaction to be completed with a corresponding merchant processor that is used by the merchant, such as the exemplary merchant processor 10.

[0101] The enterprise data system 6 can be cloud-based or can be in the form of a set of dedicated servers with processors and the like, depending upon the needs of the particular application. The enterprise data system 6 can be said to include and I/O subsystem 35 that interfaces with the wireless data network 5, the venues 8, and the merchant processor 10. The I/O subsystem 35 also communicates with credit card companies such as Visa, Mastercard, Discover, American Express, and the like and potentially could communicate directly with issuing banks, i.e., banks such as Bank of America, Capital One, Barclay's, and the like, by way of example, who issue the credit cards that become the basis for pre-established sources of funds.

[0102] The enterprise data system 6 further includes a storage 36 and a processor 38 that are in communication with one another and in communication with the I/O subsystem 35. The storage 36 has a number of routines 40 stored therein and various data stored therein that are indicated at the numeral 44. The storage 36 includes a UTV that is a secure storage and which has stored therein a number of smart tokens that are each representative of the Underlying Sensitive Information (USI) of a corresponding one of the number of pre-established sources of funds, some of which are owned by the user of the mobile electronic device 4, and others of which are owned by other users of other mobile electronic devices, by way of example. Pre-established sources of funds can include credit cards (which, in the examples given herein are deemed to include debit cards) and can include other sources of funds such as gift cards, merchant credits, and the like without limitation.

[0103] The routines 40 can be in said to include a token service that is in the form of an API that performs various operations with tokens. For instance, the user of the mobile electronic device 4 can employ the improved app that is executable thereon to upload the USI of a credit card, for example, for storage in the form of a smart token in the UTV. The user can key in the USI information using a keypad of the input apparatus 16 or potentially can take a photo of the credit card using a camera of the input apparatus 16 in order to provide the Primary Account Number (PAN), the expiration date, the name of the card, and the CVC or CVV, which together form the USI, to the token service API. The token service API tokenizes the USI into a smart token, and the smart token is stored in the UTV. In this regard, it is understood that the smart token bears little resemblance to the USI, and thus the USI is secure since it is saved in the UTV only in tokenized form.

[0104] The process of adding a source of pre-established funds, such as a credit card, into the UTV is depicted generally in FIG. 2. The operation can begin, such as at 104, where a registration input is received at the enterprise data system 6, with the registration input including the USI of the credit card, by way of example, that the user wishes to add to his or her token profile in order to be able to use the credit card as a source of pre-established funds for use in performing future financial transactions. The USI typically will include the PAN, the expiration date, the CVC or CVV, and the name on the credit card. In doing so, the USI is communicated from the improved app on the mobile electronic device 4 to the enterprise data system 6 using HTTP basic authentication, and thus the data is encrypted when being communicated through the wireless data network 5 to the enterprise data system 6.

[0105] Processing continues, as at 108, where the enterprise data system 6 communicates to the credit card company of the user's credit card a request that the issuing bank that issued the credit card authorize the use of funds. In the depicted exemplary embodiment, the request is communicated from the data system 6 to the credit card company, and the credit card company forwards the request to the issuing bank. A credit card or other source of pre-established funds will have an amount of funds that are available, and this first request is to establish that with the issuing bank that the card is valid and chargeable at that time. If the issuing bank determines that the credit card is valid and chargeable, the issuing bank will generate an authorization code which typically is a numeric code, and which is communicated back to the credit card company and thereafter to the enterprise data system 6.

[0106] Processing continues, as at 112, where the authorization code is received at the enterprise data system 6. Processing then continues, as at 116, in which, responsive to the receiving of the authorization code at the enterprise data system 6, the token service API generates a smart token that is representative of the source of pre-established funds and that is based upon the USI of the credit card, most typically the PAN. In particular, the smart token that is generated by the token service API is capable of being detokenized by the token service API into a set of data that includes the PAN. The smart token is then stored in the UTV, as at 120. In this regard, the token service will generate a token profile of the owner, and the smart token that represents the pre-establish source of funds will be stored as part of the token profile.

[0107] The enterprise data system 6 then outputs an indication, as at 124, that the credit card that has been uploaded is now stored as a pre-established source of funds and is available for use by the user in the conducting of financial transactions. This indication is then communicated over the wireless data network 5 to the mobile electronic device 4 and is received by the improved app that is running on the electronic device 4, and this results in the improved app outputting some type of a notification, such as a visual notification that is output on the visual display of the mobile electronic device 4, or other such notification, advising that the credit card is now usable on the app.

[0108] With the credit card now stored in the UTV in the form of a smart token and thus usable as a source of pre-established funds that are usable in order to conduct financial transactions, the user is now able to use that source of pre-established funds to, for instance, start a tab at a venue such as one of the venues 8. For instance, the user may start the improved app on the mobile electronic device 4 and may receive a visual listing of various venues that are available for selection and for the creation of the tab using the improved app. For instance, the various available venues might be output in terms of preference, frequency of use, geographic proximity, etc. When the user selects a particular venue 8 for which to generate a tab, the improved app communicates through the wireless data network 5 an initiation input that is received, as at 204, at the enterprise data system 6 and is seen as a request for an initiation of a financial transaction at that particular venue 8. The token service then detokenizes, as at 8, the smart token into a set of data that comprises a PAN of the source of pre-established funds.

[0109] In this regard, it is assumed that the user is employing the aforementioned source of pre-established funds in order to start the tab at the venue 8, it being understood that the user can upload a plurality of credit cards and the like according to the flowchart of FIG. 2 in order to have a plurality of sources of pre-established funds that are selectable for use in generating tabs at venues 8 and for use in conducting other financial transactions. In such a situation, the user might input a selection input to select a preferred source of pre-established funds from among a plurality of sources of pre-established funds for the creation of a particular tab in a particular venue 8. All such sources of pre-established funds will be stored in the UTV as smart tokens under one token profile that corresponds with the owner.

[0110] Processing continues, as at 212, wherein the enterprise data system 6 communicates to the credit card company of the source of pre-established funds the PAN and potentially other USI, along with an authorization request. The authorization request is actually a request that is directed to the issuing bank and is communicated from the credit card company to the issuing bank to see if the source of pre-established funds remains valid and chargeable for the purpose of paying an obligation that arises from a financial transaction. If the issuing bank determines that the credit card remains valid and chargeable, it will generate an authorization code that is sent back to the credit card company, and the credit card company sends the authorization code back to the enterprise data system 6. The authorization code is therefore received, as at 216, at the enterprise data system 6 and, responsive to such receiving of the authorization code, the token service API generates a transaction token and sends, as at 220, an initiation notification to the venue 8 indicating that the financial transaction, i.e., the tab, has been initiated. This notification typically is sent to the POS system at the venue 8 and includes the first and last name of the user to enable the venue 8 to match the newly created tab with the user.

[0111] The aforementioned transaction token that was generated by the token service API is the result of an API call using, in the depicted exemplary embodiment, the PAN, the authorization code, and an argument value in the form of a random number. The transaction token is stored in the token profile of the owner of the source of pre-established funds. The transaction token can be detokenized to form a data set that includes the authorization code, the random argument, and whatever USI was used in the creation of the transaction token, typically the PAN. While the transaction token was created at the initiation of the financial transaction, it is not necessarily sent to the venue 8 since the authorization code that was received at 216 would have been an authorization code that was responsive only to a nominal credit authorization. That is, the initial authorization for the credit card would have been for a nominal amount, typically $1 or $10, by way of example, or other such nominal amount, and would be the same amount for all such initial authorizations that are sought by the enterprise data system 6. It is expected that the user typically will charge to the existing tab more than the nominal $1 or $10, by way of example. Furthermore, the initiation notification that was sent, as at 220, to the venue 8 was merely a notification to the venue 8 that a tab has been opened and it is backed up by a valid and chargeable credit card.

[0112] With the tab being opened at the venue 8, charges can then be applied to the tab by the venue 8, such as for the purchase of food, beverages, merchandise, services, and the like without limitation. The routines 40 of the enterprise data system 6 advantageously mirror the financial transaction as items are added to the tab at the venue 8. The enterprise data system 6 thus at all times has in its storage 36 a mirror copy of the financial transaction, i.e., the tab, in its current and updated state. That is, as an item is added to the tab at the venue 8, the POS system at the venue 8 communicates the added item to the mirror copy of the tab that is stored in the storage 36 of the enterprise data system 6 by sending a charge notification or other signal to the enterprise data system 6. Such updated mirror copy is advantageously forwarded via the wireless data network 5 to the mobile electronic device 4 for viewing thereon. As such, the inventive app that is executed on the mobile electronic device 4 can be opened by the user and the current tab with details for all charges can be visually displayed on the visual display of the mobile electronic device 4, by way of example.

[0113] As charges are added to the tab, the enterprise data system 6 advantageously can again authorize the pre-established source of funds for progressively greater amounts of available funds, i.e., money. The initial authorization of the card was for a nominal $1 or $10 or other nominal amount. If it turns out that the credit card only had $11 of funds available, the initial authorization of $10 would have occurred because the issuing bank saw that the credit card had available the requested $10 of funds. If insufficient funds are available when the tab is sought to be closed for a higher dollar amount than the original authorization amount, i.e., an amount that exceeds the amount of available funds, the credit card will at that point be declined. If the tab is of an excessive amount, a declined credit card charge is undesirable due to potential financial loss by the venue 8.

[0114] In order to avoid this problem, the routines 40 on the enterprise data system 6 advantageously can repeatedly reauthorize the card as the tab grows in amount. Such reauthorization can occur at specific dollar amounts, i.e., $50, $100, $150, etc., or such reauthorizations can occur when each new item is added to the tab, and other variations will be apparent. Such reauthorizations do not incur any kind of transactional fee from the credit card company and are not treated as suspicious activity. As each such reauthorization occurs and the issuing bank returns to the enterprise data system 6 a new authorization code, the token service API creates a new transaction token that is stored in the UTV, and the earlier transaction token for that tab is deleted. If at some point during the course of the financial transaction the charge on the credit card is declined, such as when the enterprise data system 6 receives a decline message from the issuing bank, the current transaction token (i.e., the one previously created from the most recent authorization code) can be sent to the venue 8 to charge the credit card for whatever amount has most recently been authorized by the issuing bank. This would be done as partial payment for the tab. This advantageously avoids the user from running up a large tab without available funds to pay the tab. This reduces the risk of financial loss to the venue 8.

[0115] It is also understood that a given venue 8 might have a plurality of revenue center IDs. For example, a stadium might include numerous kiosks each of which sell food, beverages, and merchandise, by way of example, and which is a separate revenue center ID. The tab that is opened through the use of the improved app on the mobile electronic device 4 is advantageously operable at all of the kiosks, by way of example. When the tab is opened as a result of the sending of the initiation notification at 220, the enterprise data system 6 sends as part of the initiation notification the name of the user, i.e., the owner of the pre-established source of funds, and the user gains access to the tab by telling an employee at the kiosk, or at the bar or at the restaurant, by way of example, that a tab has been opened under the user's name and gives the user's name to the employee. The employee finds the tab and applies the charge for whatever food, beverage, etc., is being purchased at that time onto the tab.

[0116] The tab can remain open until the user affirmatively closes it, at which time the transaction will be closed, and the various entities involved with the credit card transaction will apply their charges as the funds are transferred from the issuing bank to the receiving bank that was established to receive funds that are being transferred to the venue in order to satisfy the obligation that arises from the financial transaction. As is understood, the charges typically are in the nature of a percentage of the total charge plus a fixed fee. By closing one tab only one time, the fixed fee is charged only one time. This saves money since, in the absence of the tab staying open for multiple purchases from multiple kiosks, each purchase of a food or beverage item at a different kiosk would be a separate credit card transaction with the percentage charge and the fixed fee charged with each credit card purchase. The percentage charge will be the same whether the total charges are the result of a plurality of individual credit card transactions or single credit card transaction. However, the multiple fixed fees that would be charged as a result of each of the plurality of credit card transactions are saved by having all of the charges charged in a single credit card transaction. Even though the amount of money that is charged in the fixed fee is relatively small in comparison with the total amount that is being charged, the repeated saving of this fixed fee can accumulate as a large overall savings, such as if 100,000 patrons at a sporting event each purchase two items. If the two items are charged in a single credit card transaction instead of two credit card transactions, savings to the venue 8 of one instance of the fixed fee saved multiplied by 100,000 patrons at a single sporting event is significant. Such savings are advantageous.

[0117] When it is desired to close the tab, processing can occur, as in FIG. 4. For instance, and as at 304, responsive to a predetermined event the enterprise data system 6 will communicate to the credit card company a final authorization request that the issuing bank authorizes use of a final amount of funds to pay the final amount of the obligation to the venue 8. In this regard, the final amount of funds will be the total of the charges that have been applied by the venue 8 for the purchase of food, beverage, merchandise, etc. by the user, plus an amount for sales tax, if applicable, and an amount of any gratuity that the user may have added. In this regard, the user may have employed the improved app on the mobile electronic device 4 and may have entered a closing input such as by selecting an option such as CLOSE TAB or other such command, which would open a dialog box that might provide a complete listing of all items on the tab and might provide an option for the user to enter a gratuity. Once the user enters the gratuity via a gratuity input, whatever that amount might be, that amount is added to the aforementioned charges and sales tax to result in a final amount that is to be charged to the credit card.

[0118] In such a situation, the predetermined event to communicate with the credit card company might be, for example, an input by the user to CHARGE CREDIT CARD or other such command that would trigger the enterprise data system 6 to send another authorization call to the credit card company which requests that the issuing bank authorize a charge for the final amount. If the issuing bank approves the charge, the issuing bank will return an authorization code to the credit card company, which will forward the authorization code to the enterprise data system 6 which will be received, as at 308, by the enterprise data system 6.

[0119] The enterprise data system 6 will then cause its token service API to generate, as at 312, a final transaction token that is based upon the final authorization code, the PAN, and argument in the form of a random number, and the transaction token is stored in the token profile. As before, the transaction token is capable of being detokenized to form a data set that includes the authorization code and the USI. Prior such detokenization, however, the transaction token is sent, as at 316, to a payment processor that is used by the venue 8 in payment of the obligation. Such payment processor, which is also known as a merchant processor, is in the form of a revenue center ID which is in the form of a URL to where the transaction token is sent. When the transaction token arrives at the revenue center ID, the transaction token automatically detokenizes into the PAN, the authorization code, and the argument value since the revenue center ID has been white listed by the enterprise data system 6. Such detokenization occurs automatically, which is to say that the detokenization operation is automated and occurs as a result of an API call by the merchant processor to the enterprise data system 6 which performs its own API call and forwards the argument to the payment processor. The payment processor API uses the argument to detokenize the transaction token into the PAN, the authorization code, and the argument.

[0120] The venue's payment processor then sends to the credit card company the authorization code that was generated by the issuing bank in response to the request for authorization of the final charge, the credit card company forwards the authorization code to the issuing bank, and the issuing bank transfers the funds in the amount of the final charge to the receiving bank and adds a corresponding entry for the final charge into the user's credit card bill. It is understood that the funds that are transferred to the receiving bank are not all fully available to the venue 8 until the various transactional charges are withdrawn on behalf of the credit card processor, the credit card company, and the issuing bank. The remaining funds are then available to the venue 8.

[0121] It is understood that various events can constitute the predetermined event at 304. For instance, the system may be set up such that all tabs are closed at a predetermined time, such as if the particular venue 8 closes at 2 AM, which will trigger the closing of all tabs at that time. It is also noted that each venue 8 has a geo-fence 48 which is a predefined region with respect to the venue and might be, for instance, a region within 100 feet of the front door of the venue or, by way of further example, anywhere within a one block radius of the street address, or other such predefined region. The mobile electronic device 4 includes the GPS receiver as part of the input apparatus 16, and location data of the mobile electronic device 4 is regularly being communicated via the wireless data network 5 to the enterprise data system 6, so the enterprise data system 6 generally always knows location of the mobile electronic device 4 and thus also know the proximity of the user of the mobile electronic device 4 with respect to the various venues 8.

[0122] The geo-fence 48 of venue 8 might additionally or alternatively be employed in the creation of the initiation input as at 204. For instance, an initiation input might be considered to be detected when a user provides a requesting input to start a tab at a venue 8 and is either physically present at the venue 8 or is on the way to the venue 8, such as by purchasing a private vehicle transport to that particular venue via Uber vehicle or other such service. In closing the tab, the geo-fence 48 could again be employed if, for instance, the user moves from a location within the geo-fence 48 while the tab is active to a location outside the geo-fence 48. Such movement to outside the geo-fence 48 might trigger the closing the tab.

[0123] Furthermore, an initiation input as at 204 might be prevented in certain circumstances. For instance, if a tab that was created via the enterprise data system 6 remains unpaid, in whole or in part, the enterprise data system 6 might not allow another tab to be opened by the user under any of the pre-established sources of funds until the unpaid tab is paid in full. The unpaid tab might be unpaid because it was never sought to be closed, because a credit card was declined, or for any of a variety of reasons.

[0124] Further regarding the initiation of the tab, as at 204, it is understood that the user might be prompted or otherwise invited to provide the initiation input to initiate the opening of tab at a given venue 8. For instance, if the user is in an Uber vehicle with the pre-established destination being the location of the venue 8, the enterprise data system 6 or the improved app on a mobile electronic device 4 might detect the pre-established destination as being the same as or close to the location of the venue and might prompt the user to open a tab at the venue 8. Other occurrences might prompt the opening of tab, such as if the user is situated nearby a particular venue 8 where a sporting event is about to begin, and the user may be prompted to purchase a ticket for the sporting event and be prompted to open a tab. Still alternatively, the mere physical presence of the user within the geo-fence 48 of a given venue 8 might prompt the user to open a tab for the venue 8. Other variations will be apparent.

[0125] As suggested hereinbefore, the routines 32 might include a number of vendor apps, also known as merchant apps, that enable the user to engage in commerce with a particular vendor. By interfacing the vendor app with the enterprise data system 6, the token service and the UTV that are afforded under the enterprise data system 6 are cooperable with the vendor app. As such, the user might use the vendor app to purchase an order of food from a restaurant for carryout. When the user issues a command to place an order and to thereby charge a pre-established source of funds, the token service detokenizes the smart token for that pre-established source of funds into a set of data that includes the USI for that credit card. The USI is then sent using HTTP basic encryption to the relevant credit card company along with an authorization request for the amount of the bill. If the issuing bank returns an authorization code via the credit card company, that authorization code and the smart token, along with a random number argument, are used to create a transaction token that is stored in the UTV and that is sent to the merchant processor 10 for that vendor in payment of the obligation. Upon the transaction token arriving at the merchant processor 10, the transaction token automatically detokenizes into a set of data that includes the USI, particularly the PAN, and the authorization code. The merchant processor 10 then communicates the authorization code to the credit card company, and the issuing bank transfers the funds to the acquiring bank set up by the merchant processor 10. By advantageously using the smart token that is already stored in the UTV, this avoids repeated entering of the same credit card for each vendor app that the user might wish to install on the mobile electronic device 4. This saves time and effort. Moreover, the retention of the smart tokens and the transaction tokens under the token profile of the owner and within the UTV avoids retaining USI, and rather results in retaining only a tokenized version of the USI, which is a secure way of storing such data and is thus advantageous.

[0126] As a general matter, it can be seen that the enterprise data system 6 performs much of the interaction with the credit card company and thus with the issuing bank through the credit card company, such as by requesting and receiving authorizations to charge credit cards. By sending to a revenue center of the venue 8 or the merchant processor 10 merely the authorization code as part of the transaction token, this avoids the need for the venue 8 and the merchant processor 10 to themselves perform such authorization calls with the credit card companies and waiting for authorization codes. By offloading such processing from the venues 8 and merchant processors 10, and by performing it with the enterprise data system 6, the costs incurred by the venues 8 and the merchant processors 10 in terms of computer cycles, communications bandwidth, and time are reduced, which provides for better functionality and provides for reduced cost, both of which are advantageous.

[0127] Further savings are obtained in the scenario where the credit card transaction is of the type where a gratuity would ordinarily be added by a user, but where the gratuity is not actually added to the charge until the tab is cashed out at the end of the night. In the conventional scenario which involves cashing out, the credit card processor was required to process the card twice, once when the tab was initially closed with an authorization code being returned by the issuing bank, and again when the gratuity was added during the cashing out operation and the card is again authorized for the full amount including the gratuity. While such double authorization of a single tab does not necessarily result in multiple transaction fees, it still requires the entire process of authorization request routed to the issuing bank and authorization code returned to the POS system to be performed twice. By avoiding such dual processing by the payment processor used at the venue, this reduces processing cycles and processing bandwidth, and if the credit card processor is not required to perform such operations twice for each tab, savings in processing effort is achieved, which is advantageous.

[0128] It thus can be seen that the system 2 and the various methods presented herein are advantageous because they reduce the risk and they reduce expense. They reduce risk by retaining smart tokens and transaction tokens in the UTV in the form of a token, which is secure. They reduce expense by reducing processing bandwidth and processing time by interfacing directly with the credit card companies, rather than requiring the credit card processor of each venue to perform such interfacing. Further expenses saved by reducing the quantities of credit card transactions by enabling a plurality of charges by a person to be charged a single credit card transaction rather than in multiple credit card transactions, with resultant savings of fixed fees and further savings of processing bandwidth and time. Multiple processing of a credit card charge to add a gratuity is also avoided since with the inventive app the gratuity is added by the user before the credit card is ever charged. Other benefits will be apparent.

[0129] While specific embodiments of the disclosed concept have been described in detail, it will be appreciated by those skilled in the art that various modifications and alternatives to those details could be developed in light of the overall teachings of the disclosure. Accordingly, the particular arrangements disclosed are meant to be illustrative only and not limiting as to the scope of the disclosed concept which is to be given the full breadth of the claims appended and any and all equivalents thereof.