Patent Grant
11735003
The present application relates to systems and methods for redeeming value tickets.
The present invention relates to a system and method for performing ticket redemption transactions for a customer. Specifically, the invention relates to a system and method, used in a variety of environments including casinos, to facilitate cashless gaming. A gaming device, such as a slot machine, will issue a ticket rather than cash or coin, which is then redeemable by the customer through various mediums, such as a casino cashier or multi-function cashless gaming Automated Teller Machine, or ATM.
Because casinos have an interest in maintaining a high level of customer satisfaction, it is advantageous to provide customers with the ability to easily and effectively manage their winnings in a manner that empowers them to quickly collect their money in a form of their choosing. However, existing redemption methods require numerous steps and other burdens. Therefore, there is a need for a system and method of redeeming a customer's winnings in a prompt and seamless manner that provides the customer with the flexibility of deciding how and when to collect the money.
The present invention generally relates to a system and method for allowing a customer to redeem his or her winnings from a gaming machine, such as a slot machine, in a casino environment. After a player has accrued winnings at a gaming machine and has finished playing, the player indicates to the machine that he or she is ready to cash out. Rather than issuing cash, the method of the present invention includes issuing the customer a unique ticket that is associated with the amount the customer has won. This “cashless gaming” aspect of the present invention avoids issuing the player burdensome coins to lug about the casino. Then, at the player's convenience, the ticket is introduced into a multi-function cashless gaming ATM for redemption. Further objects, features, and advantages of the present invention over the prior art will become apparent from the detailed description of the drawings which follows, when considered with the attached figures.
The multi-function ATM is configured to perform traditional transactions such as cash withdrawal, credit/debit card cash advance transactions, and electronic fund transfers. The ATM of the present invention also provides for the additional task of ticket redemption transactions. The ticket includes encoded data, such as a barcode, which is read by the multi-function ATM as the ticket is introduced. The ticket may be introduced by a number of methods, such as swiping it through a ticket reader on the ATM. The encoded data on the ticket is electronically processed by the multi-function ATM to retrieve the information represented by the data. For instance, where the encoded data is a barcode the information retrieved is a number, or another unique identifier, represented by the barcode.
Once the number, or another unique identifier stored on the ticket, has been retrieved, the ATM validates the ticket. The unique identifier is verified against a redemption ticket database, which indicates whether the ticket has been previously redeemed. If the ticket has not yet been redeemed, the procedure continues. The redemption ticket database also stores multiple identifiers and associates each identifier with a predetermined dollar value based on players' winnings at various gaming machines. Once the redemption ticket database determines the predetermined dollar value associated with the specific identifier on the player's ticket, the dollar value is returned to the multi-function ATM.
Upon verifying that the ticket is valid and receiving the predetermined dollar value, the multi-function ATM transfers an award to the player that is equal to the predetermined dollar value associated with the ticket. If the system collects a commission for performing the redemption transaction, the award amount may be reduced by the commission fee. The player can select a redemption type for receiving the award, such as cash, credit, or deposit. Where the selected redemption type is cash, the multi-function ATM dispenses cash to the player that is equal to the predetermined dollar value, less applicable fees. Once the multi-function ATM has transferred the award to the player, the redemption ticket database is updated to indicate that the redemption ticket has been redeemed. Accordingly, an attempt to subsequently redeem the same ticket again will fail.
In another aspect of the present invention, the selected redemption type is credit. The player introduces his or her credit card into the multi-function ATM, and the credit card is then electronically processed. The ATM retrieves the machine readable information stored on the credit card, and electronically issues a credit request to a credit card authorization server. The credit request utilizes the machine readable information stored on the credit card and the predetermined dollar value as the basis of the request. If the request is approved, a credit card account, which is associated with the credit card, is credited an appropriate amount.
In yet another aspect of the present invention, the selected redemption type is deposit. The player introduces his or her ATM card into the multi-function ATM, and the ATM card is then electronically processed. The ATM retrieves the machine readable information stored on the ATM card and electronically issues a deposit request. The deposit request utilizes the machine readable information stored on the ATM card and the predetermined dollar value as the basis of the request. If the request is approved, a deposit is made in an appropriate amount to a banking account that is associated with the ATM card.
In one embodiment of a system and method for facilitating redemption of monetary value associated with a presented cashless gaming ticket to an account associated with a bank card, the system includes the ATM and a financial server. The ATM is configured to transmit a ticket validation request to a ticket redemption system in response to presentation of a cashless gaming ticket to the ATM by a user and when the cashless gaming ticket is validated and the ATM has received a request by the user to transfer the monetary value to a bank card account associated with a presented bank card, to read the bank card and transmit a request to transfer the monetary value associated with the cashless gaming ticket to the bank card account. The financial server is configured to receive the request to transfer monetary value from the ATM, to transmit to a financial network a request for the monetary value less a transaction fee to be credited to the bank card account of the user, to receive confirmation that the credit is applied to the bank card account, and when the confirmation is received, to cause the ATM to indicate to the user that the credit was successfully applied to the bank card account.
In one embodiment, the financial server transmits the request for the monetary value less the transaction fee to be credited via a financial gateway to an issuing bank associated with the bank card account. The request may be made via merchant category code 7995.
In another embodiment, the financial server transmits the request for the monetary value less the transaction fee to be credited to a processing bank which creates a wallet account for the transaction and transfers funds from the wallet account to an issuing bank associated with the bank card account. The request to transfer of funds from the wallet account to the issuing bank may be made via merchant category code 6012.
In addition, another aspect of the present invention allows a customer to use a player tracking card (“PTC”) to receive cash or credit from the multi-function ATM based on the points accumulated by the cardholder and associated with the PTC. It is common for casinos to issue player tracking cards, which are used to track players' activities in the casino and award points for certain actions. Typically, the points can be redeemed for a variety of goods and services, such as free or discounted meals, hotel accommodations, and gift shop items. In the system of the present invention, the points accumulated by a player can also be redeemed by the multi-function ATM for cash or credit. This process is similar to redeeming a redemption ticket, only rather than introducing a ticket to the ATM, the player introduces his or her PTC to the ATM. The ATM decodes the magnetic strip on the PTC, retrieves the associated player and point information, and redeems the points for the appropriate cash or credit.
One embodiment of a cashless gaming ticket redemption transaction system 100 is shown in
As described in more detail below, a player 120 that has been issued a ticket 125 can bring the ticket to a multi-function ATM 150. The player interacts with the ATM 150 through any methods known in the art such as buttons and touch-sensitive screens. The ATM 150 is configured to perform traditional transactions such as cash withdrawal, credit/debit transactions, and electronic fund transfers. These operations are well known in the art and are not elaborated on herein. The ATM 150 of the present invention is also configured to perform ticket redemption transactions. Accordingly, the ATM 150 reads, validates, and processes the ticket 125 to redeem the player's winnings.
To perform these functions, the ATM 150 communicates with the authorization server 130. The authorization server 130 in turn communicates with the redemption ticket database to validate the ticket 125 and retrieve information about the associated winnings. The redemption ticket database 140 stores multiple unique identifiers, each representing a redemption ticket issued to a player, and associates each identifier with a predetermined dollar value based on players' winnings at various gaming machines. The authorization server 130 many also communicate with various authorization centers 170 for redemption to credit card accounts and checking/savings accounts. It will be appreciated that the authorization server 130 may comprise more than one server or device. For example, a first authorization server might comprise a cashless ticketing server which is configured to generate cashless gaming ticket information and to receive and validate cashless ticket redemption requests, and a second authorization server might comprise a financial transaction server which is configured to receive requests for deposit of funds associated with a cashless gaming ticket to a financial account of the player 120.
The redemption transactions that are performed on the multi-function ATM 150 and the authorization server 130 are tracked and stored on a transaction database 160. In one embodiment, the customer transaction history on the transaction database 160 for specific customers can be accessed by the authorization server 130. In this embodiment, the customer must identify himself or herself to the ATM, for instance, by introducing a casino-issued “player tracking” or VIP card to the ATM that uniquely identifies the customer. The transaction database 160 can also store additional information regarding customers' credit history as well as marketing information. When a commission is collected for utilizing the cashless gaming ticket redemption transaction system 100, the appropriate commission information for each player is also stored on the transaction database 160 as well as commission fee overrides for certain players such as VIP's.
In operation, and with reference to
The gaming machine 110 also transmits pertinent winnings information to the authorization server 130, as shown in
At the player's convenience, he or she can take the ticket 125 to the multi-function cashless gaming ATM 150, which, in the preferred embodiment, is also located in the casino environment. Because the ATM 150 performs multiple types of transactions, the player selects a “redemption” transaction on the ATM 150 at step 210. At step 220, the player 120 introduces the ticket 125 into the multi-function ATM 150 for redemption. The ATM 150 may accept the ticket through a variety of means, such as a ticket reader (not shown) as is known in the art. In one embodiment, the ticket 125 may be swiped through the ticket reader. As the ticket 125 is introduced, the ATM 150 attempts to read the encoded data.
At step 230, the ATM 150 determines whether the encoded data is readable and correctly formatted. At step 240, if the encoded data is unreadable or the format is not recognizable, the transaction fails and the ATM 150 displays an error message to the player 120, indicating that the player 120 should see the cashier (not shown) at the casino. If the encoded data is readable and correctly formatted, the data is electronically processed by the multi-function ATM 150 to retrieve the information represented by the encoded data. In one embodiment, the encoded data is a barcode and the information retrieved from the ticket 125 is the unique number represented by that barcode.
Once the number, or another unique identifier stored on the ticket 125, has been processed, the ATM 150 validates the ticket 125 at step 250. The unique identifier is verified against the redemption ticket database 140. The ATM 150 communicates with the authorization server 130, which in turn communicates and issues queries to the redemption ticket database 140. The data from the redemption ticket database 140 is communicated to the authorization server 130 and then transmitted back to the ATM 150. At step 260, if the ticket 125 cannot be verified against the redemption ticket database 140, the transaction fails and the ATM 150 displays an error message to the player 120, indicating that the player 120 should see the cashier (not shown) at the casino.
If the ticket 125 is successfully validated, the ATM 150 prompts the player with the choice of transaction types for redeeming the winnings at step 270. In one embodiment, the transaction types include “Cash from ATM,” “Credit to Credit Card,” and “Deposit to Checking/Savings Account.”
With reference to
At step 320, if the ticket 125 has been previously redeemed, the ATM 150 displays a message to the player 120 indicating the previous redemption and that the player 120 may see the cashier (not shown) if the player believes an error has occurred. If the ticket 125 has not been previously redeemed, the ATM proceeds with the transaction by determining the player's winnings and the amount that will be awarded, step 330.
To ascertain this amount, the ATM 150 communicates with the authorization server 130, which queries the redemption ticket database 140. As previously described, the redemption ticket database 140 stores and associates information relating to the tickets 125 and the players' winnings. The redemption ticket database returns to the authorization server 130 the winnings associated with the ticket 125. In one embodiment, the ticket 125 contains winning value, which is confirmed against the redemption ticket database. The authorization server 130 then determines the amount to be redeemed, which is typically the player's winnings minus a commission or transaction fee. The appropriate commission may be determined based on the specific player redeeming the ticket. A player profile (not shown) may be stored on the transaction database 160, which indicates the player's preference level. For instance, while a new player may have a standard commission taken out of the winnings, a VIP player may have the commission waived altogether based on the player profile.
Once the winnings associated with the ticket 125, less the commission if any, has been established, the authorization sever 130 transmits this redemption value to the ATM 150. At step 340, the authorization server 130 issues a dispense message for the ATM 150 to dispense the appropriate redemption value to the player 120 in cash. In response to the message, the ATM 150 attempts to dispense the redemption amount in cash. At step 350, the authorization server 130 determines whether the ATM 150 acknowledges the dispense message. At step 360, if the ATM does not acknowledge the dispense message, the transaction fails, and the ATM 150 displays an error message to the player 120 that the ATM is unable to dispense the cash and that the player should see the cashier. At step 370, if the ATM does acknowledge the dispense message, the authorization server 130 updates the redemption ticket database 140 to indicate that the ticket 125 has been redeemed and the cash has been dispensed, thereby completing the cash redemption of the cashless gaming ticket 125.
Now with reference to
At step 430, the authorization server 130 electronically issues a credit request to the credit card authorization center 170. The credit request causes the authorization center 170 to attempt to credit a credit card account belonging to the player 120 for the redemption value, the amount of the player's winnings less any commission. If the credit request is successful and the player's credit card account is credited the appropriate amount, the authorization center 170 acknowledges the successful transaction to the authorization server 130. At step 440, the authorization server 130 determines whether the credit request was acknowledged by the authorization center 170. At step 450, if the request was not acknowledged, the ATM 150 displays a message to the player 120 indicating that the credit card account was not credited and that the player 120 may see the cashier (not shown) if the player believes an error has occurred. At step 460, if the request was properly acknowledged and the account was credited, the authorization server 130 updates the redemption ticket database 140 to indicate that the ticket 125 has been redeemed and the player's account has been credited.
At step 470, the authorization server 130 transmits a receipt message to the ATM 150, instructing the ATM to issue a receipt to the player 120 for the transaction. At step 480, the ATM issues a receipt, and returns the ticket 125 if necessary, to the player thereby completing the credit-type redemption of the cashless gaming ticket 125.
Now with reference to
At step 510, the player 120 swipes the ATM card through a card reader (not shown) of the ATM or otherwise introduces the ATM card to the ATM through a method known in the art. In a preferred embodiment, the card reader reads the magnetic strip on the ATM card, decodes the data therein, and transmits the data to the authorization server 130 as is known in the art. The ATM 150 prompts the player 120 to select between depositing to a checking account or a savings account that is associated with the ATM card, and the player selects the desired banking account. At step 520, as in step 330, the authorization server also determines the player's winnings and the amount that will be awarded.
At step 530, the authorization server 130 electronically issues a deposit request to an ATM authorization center 170. The deposit request causes the authorization center 170 to attempt to deposit the amount of the player's winnings, less any commission, into the selected banking account. In one embodiment, the transaction initiated by the deposit request is an Automatic Clearing House (“ACH”) transaction. If the ACH, or other transaction type, is successful and the player's banking account is credited the appropriate amount, the authorization center 170 acknowledges the successful transaction to the authorization server 130. At step 540, the authorization server 130 determines whether the deposit request was acknowledged. At step 550, if the request was not acknowledged, the ATM 150 displays a message to the player 120 indicating that the banking account was not credited and that the player 120 may see the cashier (not shown) if the player believes an error has occurred. At step 560, if the request was properly acknowledged, the authorization server 130 updates the redemption ticket database 140 to indicate that the ticket 125 has been redeemed and the player's account has been credited.
At step 570, the authorization server 130 transmits a receipt message to the ATM 150, instructing the ATM to issue a receipt to the player 120 for the transaction. At step 580, the ATM issues a receipt, and returns the ticket 125 if necessary, to the player thereby completing the deposit-type redemption of the cashless gaming ticket 125.
In another aspect of the present invention, the player 120 may also complete a redemption transaction using a player tracking card (“PTC”) (not shown) to receive cash or credit from the multi-function ATM 150. The PTC is a casino-issued card, which is used to track the player's actions in the casino. The casino awards points for certain player actions and associates the points with the PTC on the transaction database 160. The transaction database maintains each players' total award points and increments and decrements the total points according to the players' accumulation and usage of points. The player 120 is able to redeem the points associated with his or her PTC in a similar fashion to the ticket 125. For instance, with reference to
As described herein, when the player 120 is ready to redeem the PTC points for cash or credit, the player selects a redemption transaction on the multi-function ATM 150, step 610. At step 620, the player 120 introduces the PTC to the ATM 150, which reads the PTC. The PTC includes machine readable information, which is stored on the PTC by a storage means such as a magnetic strip, barcode, integrated circuit, digital image, optical memory, or finger imaging. The ATM 150 is configured to read the machine readable information through a means such as a card reader (not shown). If the machine readable information is encoded, the card reader attempts to decode the information into a format usable by the ATM 150. At step 630, the ATM determines whether the machine readable information on the card is readable and correctly formatted. At step 640, if the machine readable information is not readable and correctly formatted, the ATM 150 displays a message to the player 120 indicating the error.
At step 650, if the machine readable information is readable and correctly formatted, the ATM 150 attempts to identify the player 120 and determine whether the PTC can be validated against the transaction database 160 by transmitting the decoded information from the ATM 150 to the authorization server 130. The authorization server 130 then communicates with the transaction database 160 to verify that the PTC is valid and to identify the player 120. At step 660, if the PTC cannot be validated, the ATM 150 displays a message to the player 120 indicating the error.
At step 670, if the PTC is successfully validated, the ATM 150 prompts the player 120 with the choice of transaction types for redeeming the winnings. Upon selection of a transaction type, the ATM proceeds with redeeming the player's points, much like redeeming a player's winnings as described herein and illustrated in
Based on a point-to-dollar conversion provided to the authorization server 130, the server is able to calculate the dollar value represented by the points accumulated by the player 120. The ATM 150 prompts the player 120 to determine whether the he or she wishes to redeem all of the accumulated points or only a portion of the points. Upon determining the number of points to redeem, the ATM proceeds with the redemption transaction in accordance with player's selected transaction type.
In the preferred embodiment, a third party intermediary records audit information associated with any requests and approvals in order to support redemption and anti-fraud detection systems managed by a casino or by the third party intermediary. Following approval of the transaction and creation of an audit trail, a casino ticket (not shown) with the withdrawal value (or some portion thereof) is issued to the player 120 by the ATM 150. In this context, a casino ticket can be any number of identification cards or systems including a paper ticket with a bar code, a magnetic stripe card, a smart card, RFID or other portable digital memory that is encoded with personal and financial information. This casino ticket can then be used on a gaming machine as credit in connection with casino gaming or redeemed for cash. In the preferred embodiment, the customer 120 can either present the casino ticket for validation by a cashier at a cashier cage 720 or insert the casino ticket into a ticket redemption kiosk (including kiosks integrated with one or more casino game machines or other multi-purpose entertainment devices).
For example, a customer/player 120 could link a debit card with a player-tracking card in a casino database such that, whenever that same debit card is used to acquire a casino ticket, the ticket is encoded with that customer's player tracking code or ID. This could further be used to initiate certain security procedures or verifications that are stored in the casino's database and are associated with that player tracking code. A player could be asked to enter certain identification information (something they know, something they have or something they are) on certain types of types of machines. Likewise, gaming features could be provided at casino gaming machines in which such a casino ticket was entered. A customer that has entered a casino ticket onto a game machine could be provided with gaming audio and visual content that is associated with the user in the casino's player tracking/customer database.
In this embodiment, financial transactions, such as transfers of funds from a redeemed cashless gaming ticket 125 to a bank account of the player 120, may be processed by a financial processor FP. Such a processor might comprise, for example, Everi Payments Inc., of Las Vegas, Nev.
In the illustrated embodiment, the FP has a financial server 860 and an associated database 862, such as a database which stores accounting or other financial transaction data. The FP may also comprise a system 864, as illustrated in
In one embodiment, financial transactions are transacted by one or more elements of a financial network, such as the U.S. banking system. This system may include, but is not limited to, a financial processor bank FPB, the U.S. Federal Reserve F, an issuing bank IB, a gateway G, a network N and a casino bank CB. Of course, the various banks might comprise banks, savings and loans or other financial institutions. Further, various of the entities' banks might be the same bank.
It will be appreciated that in the embodiment illustrated in
One embodiment of a method of processing a gaming ticket 125 to a player's bank account will now be described with reference to
As described above, the ticket 125 is preferably validated. The ATM 150 may send a validation request (such as using data read from the ticket, such as a ticket ID read from an associated bar code) and transmit that request to the ticket authorization server 130, such as in step S2. As one example, a player might seek to redeem a ticket 125 having a $100 value. The ticket authorization server 130 preferably validates the ticket using ticket information stored in the database 140, such as at step S3. This may comprise determining that the ticket 125 has not previously been redeemed and confirming the value of the ticket. The validation is preferably transmitted back to the ATM 150. If the ticket 125 is not validated, the player may be so informed and the transaction may be ended.
If the ticket 125 is validated, a request may be transmitted from the ATM 150 to the financial server 860 of the financial processor FP to credit the amounts of funds from the ticket to the player's financial account, as in step S4. As noted below, the amount of funds which are credited to the player might comprise the amount or monetary value of the ticket 125 less a transaction fee. As one example, when the player is redeeming a ticket 125 having a monetary value of $100, the player might be charged a $7 transaction fee, whereby the amount of funds which the financial processor FP requests to be credited to the player's account is $93). At step S5, the financial server 860 may send a request for the funds credit to the gateway G for processing of the transaction. The gateway G might comprise a payment platform of a known/existing financial network, as is currently known in the art.
In a step S6, the gateway G generates and sends a request for the credit through the network N (which may again comprise a financial network, one or more portions of which may be public or private, including the Internet). In a step S7, the request is transmitted from the network N to the issuing bank IB (e.g., such as the bank that issued the player's bank card), and the issuing bank IB sends a response back (such as confirming receipt and acceptance of the requested credit).
Assuming that the transaction is confirmed by the issuing bank IB, in a step S8, the player may be notified that the funds have successfully been transferred to their bank card account. This may comprise, financial server 860 receiving transfer confirmation from the gateway G and then transmitting that confirmation to the ATM 150. The ATM 150 may then display the confirmation to the player 120 (such as the message “$93 funds have successfully been credited to your bank card). Of course, if the transaction is not confirmed, such a denial/failure may also be indicated to the player at the ATM 150 (thus allowing them, for example, to simply cash out the ticket into cash, etc.).
In one embodiment, the funds are then settled between the parties via the financial network. In a step S9, the gateway G transmits a settlement file to the financial network N and the financial processor system 864 (such as to the server or one of the workstations) for processing.
In a step S10, reconciliation process details are transmitted from the financial server 860 of the financial processor FP to the financial database 862 for storage. In a step S11, the network N generates and transmits settlement details to the Federal Reserve F. The Federal Reserve F then credits the issuing bank IB by an amount of the transaction (less any service fee charged by the FPB, etc.) in step S12 and debits the bank account of the financial processor FP at the financial processor bank FPB in step S13 (by the amount credited to the player's account, e.g. $93 in this example). In a step S14, the settlement file may be matched with reconciliation details stored in the accounting database 862.
In a step S15, the financial processor FP may request the Federal Reserve F to transfer funds from the casino C. The Federal Reserve F then debits the casino bank CB by the amount of the transaction, such as $100 in this example, at a step S16. This amount is credit to the financial processor bank FPB, such as at step S17 (thus, in this example, $93 was debited from the financial processor's account at the FPB to fund the player's account and then $100 was credited to the financial processor's account from the casino C, thus resulting in a gross revenue of $7 to the financial processor FP).
The financial processor FP or other processor might also share part of the transaction fee with other of the entities. For example, the financial processor FP might pay the casino a portion of each transaction fee (such as $2 of the $7 in this example). As one example, in a step S18, a request might be transmitted from the financial processor FP to the Federal Reserve F (such as from one of the workstations) to transfer such funds from the financial processor FP to the casino C. In a step S19, the Federal Reserve F may deduct the amount of these funds from the account of the financial processor FP at the financial processor bank FPB and then in step S20, those funds may be credited to an account of the casino C at the casino bank CB.
In one embodiment, when a player seeks to redeem a ticket to their financial account, various checks or validations may be performed. For example, the player's bank card is preferably validated (such as by determining that it is associated with a valid account; wherein if the card or account is not valid, the player may be prompted to insert another bank card), along with compliance with maximum transaction amount limits (for example, the financial processor FP might set a maximum transaction limit of $2500, where if the value of the ticket exceeds that amount, the transfer option might be blocked), acceptance of transaction charges by the player, and monetary velocity checks (including daily/weekly/monthly limits). In embodiment, if these checks or validations are not successful, the value of the ticket may be dispensed to the player from the ATM in the form of monetary funds, rather than by transferring the funds to their financial account. Of course, various of the prompts, notices and the like may be displayed to the player via a graphical user interface which is displayed on a display of the ATM.
In the above-described process, funds are directly credited to the player's bank card account using an existing financial processing network, such as an existing credit card network (and wherein the funds are then settled on the back end using existing financial banking networks). In one configuration, this is accomplished by pushing the player's bank card number to the gateway G using banking merchant category code 7995 to facilitate a “gambling” financial transaction in the financial network.
In other embodiments, funds might be indirectly credited to a player's financial account via a sweep wallet account. Such a transaction configuration might be utilized, for example, if MCC 7995 transactions are not supported or permitted.
In this alternate configuration, the transaction as it appears to the player is the same. However, when the financial processor FP receives the transaction request, the financial processor FP does not transmit a transaction request to the gateway G (such as via an MCC 7995 process as noted above). Instead, the financial processor FP may send a transaction request to a “wallet” bank WB (which could be the financial processor bank FPB or a third party bank). This request may include information regarding the transaction, such as the card data (including the financial account/card number) and/or other information (in the case where the transaction is processed using MCC 6012 as described below, preferably the information that is required for processing such a transaction is transmitted from the financial processor FP to the wallet bank WB). The wallet bank WB may create a non-reloadable sweep wallet account for the requested transaction, where the account number for the wallet/account may be created from the transmitted information. The wallet bank WB may then send a transaction request to the gateway G (and thereon to the issuing bank IB, as in the process described above), to process the transaction. This transaction request may be made using a different merchant category code, such as MCC 6012. The transaction may then be processed and reconciled in a similar manner to that described above.
In either embodiment of the above-described process, funds associated with a ticket 125 that is presented by a player for cash-out to their bank card account via a process in which funds are transferred directly to their account.
It will be appreciated that while a multi-function ATM may be used to facilitate a transfer of funds from a presented ticket to a player's financial account (such as via crediting to a player's credit card or deposit to the player's bank account), other devices might be used. For example, relative to the system 800 just described, instead of a multi-function ATM, a kiosk might be utilized. Such a kiosk might have similar functionality to the multi-function ATM, except that it might not be configured to dispense cash at all. Instead, the kiosk might only be configured to receive and process a presented ticket and transfer funds to a financial account, and/or provide other functionality (such as to receive paper currency and allow transfer/deposit of the currency funds, break the currency into other denomination, etc.). Thus, the term “ATM” as used herein, except as otherwise indicated, may include devices such as kiosks or the like which don't include the functionality of dispensing cash based upon a transfer or access of funds from a remote location (such as a credit or debit account).
This embodiment provides a number of advantages. The casino ticket provides a simple financial tool that is highly managed from both an access standpoint (through dynamic security), from a negotiation standpoint (where it can be used and how) that is still highly portable and personalized.
Those skilled in the art will further appreciate that the present invention may be embodied in other specific forms without departing from the spirit or central attributes thereof. In that the foregoing description of the present invention discloses only exemplary embodiments thereof, it is to be understood that other variations are contemplated as being within the scope of the present invention. For instance, the redemption types include not only cash/credit/deposit, but they may include any redemption type practicable on an ATM. Similarly, the unique identifier on the tickets is not limited to barcodes, but may take any form known in the art. Accordingly, the present invention is not limited in the particular embodiments, which have been described in detail therein. Rather, reference should be made to the appended claims as indicative of the scope and content of the present invention.
This application is a continuation of U.S. application Ser. No. 17/020,570, filed Sep. 14, 2020, which is a continuation-in-part of U.S. application Ser. No. 16/379,543, filed Apr. 9, 2019, now U.S. Pat. No. 10,839,647, which is a continuation of U.S. application Ser. No. 15/137,693, filed Apr. 25, 2016, now U.S. Pat. No. 10,275,983, which is a continuation of U.S. patent application Ser. No. 14/051,156, filed Oct. 10, 2013, now U.S. Pat. No. 9,324,210, which is a continuation of U.S. patent application Ser. No. 10/956,644, filed Oct. 1, 2004, now U.S. Pat. No. 8,556,707, which claims priority to U.S. Provisional Application Ser. No. 60/508,063, filed Oct. 1, 2003, which prior applications are incorporated by reference as if set forth fully herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4689742 | Troy et al. | Aug 1987 | A |
| 4764666 | Bergeron | Aug 1988 | A |
| 4882473 | Bergeron et al. | Nov 1989 | A |
| 5038022 | Lucero | Aug 1991 | A |
| 5179517 | Sarbin et al. | Jan 1993 | A |
| 5265874 | Dickinson et al. | Nov 1993 | A |
| 5429361 | Raven et al. | Jul 1995 | A |
| 5457306 | Lucero | Oct 1995 | A |
| 5470079 | LeStrange et al. | Nov 1995 | A |
| 5642160 | Bennett | Jun 1997 | A |
| 5663546 | Cucinotta et al. | Sep 1997 | A |
| 5679938 | Templeton et al. | Oct 1997 | A |
| 5741183 | Acres et al. | Apr 1998 | A |
| 5754655 | Hughes et al. | May 1998 | A |
| 5766075 | Cook et al. | Jun 1998 | A |
| 5770533 | Franchi | Jun 1998 | A |
| 5864623 | Messina et al. | Jan 1999 | A |
| 5902983 | Crevelt et al. | May 1999 | A |
| 5919091 | Bell et al. | Jul 1999 | A |
| 5959277 | Lucero | Sep 1999 | A |
| 5991410 | Mbert et al. | Nov 1999 | A |
| 5999624 | Hopkins | Dec 1999 | A |
| 6001016 | Walker et al. | Dec 1999 | A |
| 6048269 | Burns et al. | Apr 2000 | A |
| 6048271 | Barcelou | Apr 2000 | A |
| 6064987 | Walker et al. | May 2000 | A |
| 6081792 | Cucinotta et al. | Jun 2000 | A |
| 6124947 | Seo | Sep 2000 | A |
| 6162122 | Acres et al. | Dec 2000 | A |
| 6168522 | Walker et al. | Jan 2001 | B1 |
| 6244958 | Acres | Jun 2001 | B1 |
| 6275991 | Erlin | Aug 2001 | B1 |
| 6293866 | Walker et al. | Sep 2001 | B1 |
| 6302793 | Fertitta, III et al. | Oct 2001 | B1 |
| 6347738 | Crevelt et al. | Feb 2002 | B1 |
| 6352205 | Mullins et al. | Mar 2002 | B1 |
| 6361437 | Walker et al. | Mar 2002 | B1 |
| 6409595 | Uihlein et al. | Jun 2002 | B1 |
| 6431983 | Acres | Aug 2002 | B2 |
| RE37885 | Acres et al. | Oct 2002 | E |
| 6486768 | French et al. | Nov 2002 | B1 |
| 6487284 | Campbell | Nov 2002 | B1 |
| 6505772 | Mollett et al. | Jan 2003 | B1 |
| 6547131 | Foodman et al. | Apr 2003 | B1 |
| 6575832 | Manfredi et al. | Jun 2003 | B1 |
| 6579179 | Poole et al. | Jun 2003 | B2 |
| 6585598 | Nguyen et al. | Jul 2003 | B2 |
| 6601040 | Kolls | Jul 2003 | B1 |
| 6607441 | Acres | Aug 2003 | B1 |
| 6675152 | Prasad et al. | Jan 2004 | B1 |
| 6682421 | Rowe et al. | Jan 2004 | B1 |
| 6709333 | Bradford et al. | Mar 2004 | B1 |
| 6739972 | Flanagan-Parks et al. | May 2004 | B2 |
| 6800029 | Rowe et al. | Oct 2004 | B2 |
| 6843412 | Sanford | Jan 2005 | B1 |
| 6846238 | Wells | Jan 2005 | B2 |
| 6852031 | Rowe | Feb 2005 | B1 |
| 6866586 | Oberberger et al. | Mar 2005 | B2 |
| 6890258 | Weiss | May 2005 | B2 |
| 6951302 | Potts | Oct 2005 | B2 |
| 6997807 | Weiss | Feb 2006 | B2 |
| 7003496 | Ishii et al. | Feb 2006 | B2 |
| 7168089 | Nguyen et al. | Jan 2007 | B2 |
| 7366695 | Allen-Rouman et al. | Apr 2008 | B1 |
| 8096872 | Walker et al. | Jan 2012 | B2 |
| 8556707 | Potts et al. | Oct 2013 | B2 |
| 20010022849 | Simonoff | Sep 2001 | A1 |
| 20020002075 | Rowe | Jan 2002 | A1 |
| 20020039923 | Cannon et al. | Apr 2002 | A1 |
| 20020045476 | Poole et al. | Apr 2002 | A1 |
| 20020104878 | Seifert et al. | Aug 2002 | A1 |
| 20020107072 | Giobbi | Aug 2002 | A1 |
| 20020132664 | Miller et al. | Sep 2002 | A1 |
| 20020147047 | Letovsky et al. | Oct 2002 | A1 |
| 20020177479 | Walker et al. | Nov 2002 | A1 |
| 20030004876 | Jacobson | Jan 2003 | A1 |
| 20030033534 | Rand et al. | Feb 2003 | A1 |
| 20030036425 | Kaminkow et al. | Feb 2003 | A1 |
| 20030045353 | Paulsen et al. | Mar 2003 | A1 |
| 20030078094 | Gatto et al. | Apr 2003 | A1 |
| 20030087692 | Weiss | May 2003 | A1 |
| 20030104865 | Itkis et al. | Jun 2003 | A1 |
| 20030106769 | Weiss | Jun 2003 | A1 |
| 20030176218 | LeMay et al. | Sep 2003 | A1 |
| 20030186747 | Nguyen et al. | Oct 2003 | A1 |
| 20030211883 | Potts | Nov 2003 | A1 |
| 20030222153 | Pentz et al. | Dec 2003 | A1 |
| 20030228902 | Walker et al. | Dec 2003 | A1 |
| 20030236749 | Shergalis | Dec 2003 | A1 |
| 20040053693 | An | Mar 2004 | A1 |
| 20040173673 | Potts | Sep 2004 | A1 |
| 20040214643 | Parrott et al. | Oct 2004 | A1 |
| 20040229671 | Stronach et al. | Nov 2004 | A1 |
| 20050009600 | Rowe et al. | Jan 2005 | A1 |
| 20050015332 | Chen | Jan 2005 | A1 |
| 20050054417 | Parrott et al. | Mar 2005 | A1 |
| 20050054446 | Kammler et al. | Mar 2005 | A1 |
| 20050080728 | Sobek | Apr 2005 | A1 |
| 20050096124 | Stronach | May 2005 | A1 |
| 20050107155 | Potts et al. | May 2005 | A1 |
| 20050107156 | Potts et al. | May 2005 | A1 |
| 20060131395 | Potts et al. | Jun 2006 | A1 |
| 20060148559 | Jordan et al. | Jul 2006 | A1 |
| 20060160610 | Potts | Jul 2006 | A1 |
| 20070060309 | Yankton et al. | Mar 2007 | A1 |
| 20070066386 | Shields | Mar 2007 | A1 |
| 20070213124 | Walker et al. | Sep 2007 | A1 |
| 20090029763 | Schwartz | Jan 2009 | A1 |
| 20090048973 | DeCristoforo | Feb 2009 | A1 |
| 20090065573 | Potts et al. | Mar 2009 | A1 |
| 20110231314 | Sears et al. | Sep 2011 | A1 |
| 20160071373 | Anderson | Mar 2016 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 107 196 | Jun 2001 | EP |
| 2 380 687 | Apr 2003 | GB |
| 9323817 | Nov 1993 | WO |
| 9416781 | Aug 1994 | WO |
| 9713228 | Apr 1997 | WO |
| 0157617 | Aug 2001 | WO |
| Entry |
|---|
| Quinn, William, “Worth Their Weight in Gold,” pp. 24-26, Global Gaming Business, Apr. 1, 2003. |
| AAMVA National Standard for the Driver License/ldentification Card, AAMVA DL/ID-2000, American Association of Motor Vehicle Administrators, pp. 1-90, Jun. 30, 2000. |
| International Search Report and Written Opinion for International Application No. PCT/US04/32358, filing date Oct. 1, 2004, dated Feb. 26, 2007. |
| PSP Lab, What is original credit transaction (OCT)? Visa and Mastercard, https://psplab.com/kb/what-is-original-credit-transaction-oct/, dated Sep. 7, 2020, 3 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20220092931 A1 | Mar 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60508063 | Oct 2003 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17020570 | Sep 2020 | US |
| Child | 17544885 | US | |
| Parent | 15137693 | Apr 2016 | US |
| Child | 16379543 | US | |
| Parent | 14051156 | Oct 2013 | US |
| Child | 15137693 | US | |
| Parent | 10956644 | Oct 2004 | US |
| Child | 14051156 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16379543 | Apr 2019 | US |
| Child | 17020570 | US |
