The present invention relates to a system and method for performing checkless cash advance settlement transactions, particularly in a casino environment.
A number of aspects related to casino gaming and operation are becoming increasingly sophisticated. Casino patrons enjoy playing the plethora of unique video slot, poker, and other electronic games of chance. Other technological advancements, such as card shuffling machines, chip handling devices, etc., enhance the customer's perception of casino security and fairness. Each of these factors contributes to a heightened desire to visit and participate in gaming activities at a particular casino, a result clearly desired by casino operators.
As a result of these activities, casino gaming is a highly popular activity in today's society. Often times, a particular individual's enjoyment of the casino gaming experience is predicated upon having a sufficient supply of money that in turn allows the patron to participate in gaming activities for a desired length of time. In a most basic form, the customer simply brings a sufficient amount of currency (or “cash”) with him/her to the casino that can be exchanged for negotiable chips/casino issued gaming cards and/or used with various gaming machines. Invariably, a customer may forget to bring a desired amount of currency with him/her to the casino, and/or depletes the supply of currency brought to the casino before he/she is ready for their gaming experience to end. Under these circumstances, the customer will desire to access additional monies otherwise available through one or more financial institutions at which the customer maintains an account. For example, the customer can utilize an automatic teller machine (“ATM”) located on the casino's premises.
An additional mechanism by which a casino customer can access an off-site financial account is via a cash advance transaction from a credit-type account owned by the customer. Most casinos are equipped to handle cash advance transactions, whereby the customer presents a financial institution card to a casino employee. As used throughout this specification, the phrases “financial institution card” or “financial card” are in reference to a credit card, debit card, or bank card. To this end, casinos often provide a central “cage” station at which a teller is available for processing a financial card cash advance transaction. Regardless, the customer's financial card is processed by a designed electronic processing unit that is otherwise connected (such as via a phone line) to a financial transaction processing service provider. The service provider automatically reviews the relevant financial card information and desired cash advance amount, and either authorizes or denies the requested transaction. If approved, the casino employee (or other person designated by the casino for performing cash advance transactions, such as third party cash advance cash advance service provider) then prepares a quasi-cash document for the customer to execute and then exchange for cash and/or casino-issued chips or gaming card (e.g., a magnetic swipe card issued by the casino that, via interaction with a central database, maintains a credit account for the customer with the casino). In general terms, and as is known in the art, a quasi-cash document is akin to a check or money order and represents a negotiable instrument once signed by the customer. Thus, the quasi-cash document must include not only the cash advance dollar amount, but also customer identification information including full name, street address, and in some instances state identification number (e.g., driver license number) and telephone number.
While the casino employee (or other designated person/service provider) likely has access to a computerized system that facilitates automatic printing of the quasi-cash document, the customer identification information must be manually entered into the system by the casino employee. Unfortunately, this can be a relatively time-consuming task, especially where the customer has a unique name and/or address. In this regard, it is commonplace for multiple casino customers to virtually simultaneously desire to perform a cash advance transaction. Thus, even if the manual entry of customer identification information requires only a few minutes of the casino employee's time, where several patrons are waiting in line, the cumulative delay can become discouraging. Clearly, casinos have a vested interested in maintaining a high level of customer satisfaction, but also to avoid situations that might otherwise dissuade a customer from obtaining additional funds that in turn are used to participate in casino gaming activities.
Financial institution card cash advance transactions are a common place in casinos. However, existing cash advance systems require manual entry of customer identification information as part of the quasi-cash document generating process. This requirement entails unacceptable delays in completing an individual transaction. Therefore, a need exists for a system and method of performing a quasi-cash transaction for a customer, such as a casino customer, in an expedited fashion.
In addition to the issues outlined above, certain additional drawbacks remain related to cash access. In particular, casino customers are presently unable to perform a monetary advance transaction directly from the gaming area at which the customer is located. Instead, the casino customer is required to walk away from the gaming activity in which he/she is engaged, locate an appropriate transaction machine/station, and perform the desired financial transaction. For example, while convenient, ATMs are typically dispersed at various locations within the casino, away from individual gaming areas. Alternatively, a credit card-type transaction can be performed as outlined above (i.e., through a casino teller, or other designated individual, otherwise residing at a central “cage” station). Even further, while cash advance kiosks have recently become highly popular and provide certain conveniences to customers, the customer is still required to leave the gaming area to perform the desired financial transaction.
Casino customers can be frustrated when having to leave a gaming area to perform a monetary advance transaction. A popular gaming strategy is to continue playing a particular gaming activity after successive losses based upon a belief that the customer is “due” to win in the near future. For example, slot machine players often enjoy remaining at a particular slot machine for an extended length of time, theorizing that the slot machine will produce a large jackpot after a certain number of plays. Similarly, black jack, roulette, craps, etc.; players often desire to stay at a particular gaming table to “ride out” a losing streak, assuming that one or more winning wagers are soon to occur. Being forced to leave the gaming area to obtain additional funds undermines this gaming strategy, and is thus disconcerting to the casino customer. The casino also has a vested interest in not only keeping customers happy, but also encouraging customers to continue playing at a particular gaming area.
Therefore, a need exists for a system and method of performing a financial transaction at a gaming area in a manner that satisfies prescribed security regimens.
One aspect of the present invention relates to a method of performing a quasi-cash transaction for a customer. The method includes receiving information from the customer relating to a desired transaction dollar amount. A State or government identification card issued to the customer is electronically processed to retrieve machine-readable information stored on the identification card. Customer identification information is electronically parsed from the retrieved machine-readable information. Quasi-cash document information is electronically generated utilizing the desired dollar amount and at least a portion of the electronically parsed customer identification information. Finally, a quasi-cash document is printed, with the quasi-cash document including and displaying the generated quasi-cash document information. In one preferred embodiment, the parsed customer identification is the customer's name. In another preferred embodiment, additional customer identification information is parsed from the retrieved machine-readable information, including customer address. In yet another preferred embodiment, processing of the machine-readable information includes determining a format of the machine-readable information based upon reference to a database.
Another aspect of the present invention relates to a system for performing a quasi-cash transaction for a customer. The system includes a card reader, a processor, and a printer. The card reader is adapted to read machine-readable information stored on a State identification card issued to the customer. The processor is electrically connected to the card reader and is adapted to receive information from the customer relating to a desired transaction dollar amount and receive the machine-readable information from the card reader. Further, the processor is adapted to parse customer identification information from the machine-readable information, and to generate quasi-cash document information based upon the desired dollar amount and the parsed customer identification information. Finally, the printer is electrically connected to the processor and is adapted to print a quasi-cash document based upon the generated quasi-cash document information as provided by the processor. In one preferred embodiment, the card reader is further adapted to read machine-readable information stored on a financial institution card provided by the customer, and the processor is adapted to perform a transaction approval operation. In another preferred embodiment, the processor is adapted to recognize a format of the machine-readable information based upon reference to a database maintained by the processor.
Yet another aspect of the present invention relates to a method of performing a quasi-cash transaction for a customer in a casino. The method initially includes receiving information from the customer relating to a desired transaction dollar amount. A State or government identification card, otherwise issued to the customer, is delivered from the customer to a casino designee. The casino designee operates a card reader to retrieve machine-readable information stored on the State identification card. Customer identification information is then electronically parsed from the retrieved machine-readable information. Quasi-cash document information is electronically generated utilizing the desired dollar amount and the electronically parsed customer identification information. A quasi-cash document is then printed that includes and displays the quasi-cash document information. Finally, the casino designee delivers the quasi-cash document to the customer. In one preferred embodiment, the customer executes and exchanges the quasi-cash document for a cash or casino-issued negotiable items such as chips or casino gaming card.
Another embodiment of the present invention provides a method of performing a financial transaction within a casino by a casino customer located at a casino gaming area. The method includes providing a portable, remote control unit (RCU) to the casino customer at the casino gaming area. Transaction information is entered into the RCU relating to a financial transaction desired by the casino customer from an account owned by the customer. The transaction information is signaled from the RCU to a base processor via a wireless transmission. The RCU is operated to electronically capture a signature of the casino customer, with this electronically captured signature being signaled from the RCU to the base processor via a wireless transmission. Finally, the base processor is operated to print, via a printer electronically connected to the base processor, a negotiable financial document based upon the transaction information. In this regard, the printed negotiable financial document includes the customer's signature, generated by the base processor based upon the electronically captured signature. In one preferred embodiment, the RCU designates to the base processor a location of the gaming area, and a negotiable item is delivered to the casino customer following printing of the negotiable financial document based upon the designated gaming area location. In this regard, and in yet another preferred embodiment, the delivered negotiable item includes at least one of cash, casino-issued chips, casino-issued gaming card, a check, or the printed negotiable financial document to be exchanged for such.
A further aspect of the present invention relates to a system for performing a financial transaction within a casino by a casino customer located at a casino gaming area. The system includes a remote control unit (RCU), a base processor, and a printer. The RCU is deliverable to the gaming area, and is adapted to receive transaction information relating to a financial transaction desired by the casino customer from an account owned by the customer. The RCU preferably includes a card reader to process financial cards and State issued ID cards in order to streamline the receipt of information. Further, the RCU is adapted to electronically capture a signature of the casino customer, and wirelessly signal the transaction information and the electronically captured signature. The base processor is adapted to receive wireless signals from the RCU and generate negotiable financial document formatting information based upon the transaction information and the electronically captured signature. Finally, the printer is electronically connected to the base processor. The printer utilizes the negotiable financial document formatting information to print a negotiable financial document that includes the customer's signature. With this system, a casino customer can perform a desired financial transaction without leaving the gaming area at which he or she is participating in a gaming activity.
One embodiment of a quasi-cash transaction system 10 in accordance with the present invention is shown in block form in
As part of a quasi-cash transaction, the casino designee 14 obtains a State or government identification card 24 from the customer 16. Although a State identification is discussed below, it is understood that other types of identification cards could also be used. As described below, the State identification card 24 provides identification information in a machine-readable form. The card reader 18 is operated to retrieve the machine-readable information from the State identification card 24, with this information being signaled to the processor 20. The processor 20, in turn, compares the retrieved machine-readable information with formatting information provided by an identification card database 26 (denoted as “ID DB” in
The card reader 18 is of a type known in the art and is adapted to read and decode machine-readable information stored on a State identification card 24. In this regard, the State identification card 24 can assume a wide variety of forms, but is generally in reference to an identification card, such as a driver's license, issued by a State of the United States of America. To this end, most State identification cards provide identification information in machine-readable form. Exemplary technologies for presenting this machine-readable information include magnetic stripe, integrated circuit, finger imaging, optical memory, bar code (two-dimensional), and digital images. The card reader 18 is thus adapted to read and decode information provided by the particular card technology. Magnetic stripe and bar code techniques are most common, such that the card reader 18 is preferably a magnetic card swipe reader that reads and decodes information on the magnetic strip provided by the State identification card 24. The card reader 18 sends information to a decode logic module (not shown) which converts a serial bit stream from the card reader 18 into a byte-wide stream for input to the processor 20. Alternatively, the card reader 18 can be a “dip” card reader, etc. Because most financial cards also include a magnetic stripe with machine-readable information, the card reader 18 is further preferably adapted to read and decode information from a financial card 28 of the customer 16.
The processor 20 is a microprocessor-based device, capable of storing information and performing desired operations. In this regard, the processor 20 preferably includes and/or is connected to a display screen 30, a keypad 32, a transmission line 34, RAM 36, ROM 38, and the identification card database 26. The software used to control operation of the processor 20 is stored in the ROM 38. Further, the identification card database 26 (as well as other databases such as a customer database 40) are preferably stored in the ROM 38 (it being noted that
Operation of the processor 20 to process financial card information is known. However, electronic processing of State identification card information in accordance with the present invention represents a distinct advancement in the art. In general terms, the processor 20 is adapted to parse desired customer identification information from the State identification card 24 (as otherwise read and decoded by the card reader 18) based upon reference to the identification card database 26. As described in greater detail below, the identification card database 26 preferably includes a listing of format designations for identification cards associated with multiple States (preferably, the identification card database 26 includes formatting designations for all fifty States) or other identification card issuing bodies.
As a starting point, the American Association of Motor Vehicle Administrators (AAMVA) has established certain general formatting standards for machine-readable information stored on a State identification card. These standards are outlined in a publication entitled “AAMVA National Standard for the Driver's License/Identification Card” (2000), commonly referred to as “AAMVA DL/ID 2000”. As previously described, virtually all current State identification cards present the machine-readable information via a magnetic stripe or a bar code. In this regard, current magnetic stripe technology presents three tracks containing certain identification information; bar codes are typically read in a two-dimensional format. The AAMVA DL/ID 2000 recites required and optional data elements for each of the tracks, as well as preferred format conventions. Within each required data element and format convention, however, numerous variations are acceptable such that a universal “standard” does not exist. In fact, the formatting of the machine-readable information distinctly varies from State-to-State. Thus, the processor 20 must be adapted to recognize the originating State of the customer's State identification card 24 and, based upon reference to the identification card database 26, determine the formatting utilized by the particular State identification card 24 and thus the “location” of relevant information.
For example,
The characters presented between the first field delimiter (the “ ” at Position 12) and the second field delimiter (the “ ” at Position 26) represents {Field 2}, and provides the cardholder's name. Thus, with respect to the example of
Finally, the characters presented between the second field delimiter (e.g., the “ ” at Position 26) and the stop sentinel (e.g., the “?” at Position 40) is designated as {Field 3} and provides the cardholder's street address. Thus, with reference to the example of
Track 2 (52b of
Finally, Track 3 (52c) is not found on many State-issued identification cards. For those State identification cards that do provide a Track 3, of particular interest is the zip code information presented a certain number of positional spaces after the start sentinel (“#”). Minnesota State identification cards, for example, provide the zip code three positional spaces after the start sentinel (e.g., Positions 4-8). Thus, with the example of
As described below, the system and method of the present invention 25 addresses the wide-ranging differences in identification card information formatting to provide a universally applicable system (i.e., not limited to reviewing identification card information from only one State). An additional complication addressed by the system and method of the present invention is that many states have issued multiple identification card versions having varying machine-readable information formatting. Over time, with the evolution of technology, more information can be supplied within the machine-readable component of an issued State identification card. However, it is impossible to remove “older” versions from circulation. Thus, for example, Minnesota has two identification card versions currently available, with the older version (Version 1) providing only two tracks and the new version (Version 2) providing three tracks. The Version 1 identification information formatting does not correlate with the Version 2 formatting.
With the above designations in mind, the identification card database 26 (
Specific formatting designations for an exemplary Version 2 Minnesota-issued State identification card, otherwise provided within the format column 62, are shown in
During use, and with reference to
In particular, the casino designee 14 operates the card reader 18 to process the machine-readable information provided with the State identification card 24. Once again, this machine-readable information can be provided in a variety of formats, but is conventionally provided as a magnetic stripe or bar code. The card reader 18 decodes the machine-readable information (e.g., hexadecimal machine-readable information) provided with the State identification card 24 into an ASCII format, with this data stream being signaled to the processor 20. The processor 20, in turn, determines whether the state/entity otherwise issuing the State identification card 24 is available in the identification card database 26 at step 88. In particular, the processor 20 retrieves the state identifier code found in Track 1 of the machine-readable information. As previously described, the state identifier code is a two-alpha character component found at Positions 2 and 3 of Track 1 (e.g., with reference to the example of
If, at step 88, it is determined that the identification card database 26 does not include formatting information relating to the particular State identification card 24, the casino designee 14 is prompted, at step 90, to manually enter customer identification information via the keyboard 32 and/or the display 30. Conversely, where the identification card database 26 does provide formatting information for the State identification card 24 being processed, requisite customer identification information is parsed from the data stream at step 92.
In particular, the processor 20, with reference to the formatting requirements identified by the identification card database 26, reviews the information presented in Tracks 1, 2, and 3 (where three tracks are present). In this regard, the customer identification information required for a “complete” quasi-cash document can vary, but will normally include at least the customer's 16 name. The customer's name must be presented in proper order (e.g., first name, middle name, last name); based upon the formatting parameters presented by the identification card database 26, the processor 20 will accurately parse each component of the customer's name from Track 1 and assign proper order to the parsed customer name information, regardless of the unique presentation of customer name information employed by the State issuing the State identification card 24.
Additional customer identification information can also be parsed from the track data streams, including, for example, address, identification card number, expiration date, date of birth, telephone number, etc. In a most preferred embodiment, the customer's full name, address and identification card number are parsed. The identification card database 26 facilitates the processor 20 accurately parsing this information and storing in proper order, along with addressing idiosyncrasies of certain State identification card formatting. For example, where the identification card number includes an alpha prefix component and the associated Track 2 data stream presents the alpha prefix in numeric form offset from the numeric component, the processor 20, based upon reference to the identification card database 26 formatting instructions, parses the alpha prefix component, converts to alphabetic form, and properly orders the alpha prefix relative to the parsed numeric component.
The desired, parsed customer identification information (or the customer identification retrieved from the customer database 40 at previous step 82) is then verified by the casino designee 14 at step 84. In particular, the processor 20 generates quasi-cash document information required for proper issuance of a quasi-cash document. To ensure that the later-printed quasi-cash document is accurate, the casino designee 14 verifies the information, such as by reviewing the generated quasi-cash document information via the display 30. If errors are noted and/or if additional information is needed, the casino designee 14 can manually enter/edit the information, such as via the keyboard 32 and/or the display 30. Further, and in one preferred embodiment, the casino designee 14 verifies that a photograph appearing on the State identification card 28 is that of the customer 16.
Once the quasi-cash document information has been verified, the customer identification information is preferably stored in the customer database 40 provided by the processor 20 at step 94. Subsequently, the quasi-cash transaction is finalized at step 96.
In particular, the quasi-cash document information, as otherwise generated by the processor 20, is formatted in conjunction with the desired (and approved) dollar amount for printing on a quasi-cash document. An exemplary quasi-cash document is shown at 100 in
The processor 20 prompts the printer 22 to print the quasi-cash document 100. Once printed, the quasi-cash document 100 is presented to the customer 16 in an un-signed form. The customer 16 can then, if he/she so chooses, execute the quasi-cash document 100 and provide it to the casino designee 14 who then exchanges the executed quasi-cash document 100 for cash and/or casino-issued negotiable items (e.g., chips, casino gaming card, etc.).
The quasi-cash document can take a number of forms, including a physical negotiable instrument or a non-negotiable receipt. In one embodiment, where the document is a negotiable instrument such as a money order, the cash advance transaction flow of funds proceeds as follows: (1) the customer initiates a Debit or Credit POS transaction via one of several possible systems, e.g., Kiosk or ATM; (2) the customer receives authorization or denial from the selected system; (3) if authorized, the customer proceeds to the cashier's cage or central cage station and provides to a cashier identification and the credit/debit card used to initiate the transaction; (4) the cashier validates the customer's identity based on the identification, retrieves the transaction information using the selected system or a cash advance application that is networked to and interfaces with the selected system, and completes the cash advance application; (5) the selected system or the cash advance application prints a negotiable instrument presentable to the casino or a third-party facilitator of the process; (6) the customer endorses the negotiable instrument payable to the casino or the third-party facilitator, (7) the casino reimburses the customer for amount of the negotiable instrument, less a commission if appropriate, with cash or another casino-issued negotiable item (e.g., chips, casino gaming card, etc.); and (8) the casino deposits the negotiable instrument into its financial institution to receive funds from the financial institution or the third-party facilitator for the amount of the instrument.
As described above, the physical instrument is generated and then endorsed by the customer conducting the transaction. The negotiable instrument provides at least two functions: (1) the document is a negotiable item that the casino can use to receive reimbursement from a financial institution or a third-party facilitator; and (2) the document serves as proof that the transaction was completed and the customer received his cash. Casinos typically deposit such negotiable instruments with a financial institution at the end of each business day. The checks then follow the typical processing and clearing process involved with posting such items. Another embodiment is now described that requires even less paperwork and processing steps involved in depositing a physical instrument.
In another embodiment, a receipt is printed in lieu of a negotiable instrument. This is a “checkless” cash advance transaction. As described in more detail herein, the “checkless” cash advance transaction generates a non-negotiable draft rather than an actual negotiable instrument as a transaction receipt. The casino customer is still required to sign the draft or a receipt to complete the transaction (this signed receipt provides proof of cash dispersal should a dispute arise), but rather than filing it for subsequent deposit, the document is stored physically or electronically scanned via a scanner, e.g. a Magtek check scanner, and the image is electronically stored by the casino or sent to a third-party facilitator. These physical receipts or electronic images can then be used for reference when resolving transaction disputes. Additionally, the transaction data can be used to automatically determine the net settlement amount for a casino property for a given settlement period, and the funds deposited electronically (e.g., via an ACH file) in lieu of depositing the physical instrument.
In this “checkless” embodiment the quasi-cash document is a non-negotiable instrument, such as a receipt, and cash advance transaction flow of funds proceeds as follows: (1) the customer initiates a Debit or Credit POS transaction via one of several possible systems, e.g., Kiosk, ATM or wireless device; (2) the customer receives authorization or denial from the selected system; (3) if authorized, the customer proceeds to the cashier's cage or central cage station and provides to a cashier identification and the credit/debit card used to initiate the transaction; alternatively, if the customer initiated the transaction on a wireless device, e.g. a remote control unit (RCU), the customer does not need to leave the gaming area where he is located, but rather the customer provides his identification and the credit/debit card to a cashier/attendant, or “runner,” at the gaming area (the specific functionality of the RCU is further described below); (4) the cashier or attendant validates the customer's identity, retrieves the transaction information using the selected system or a cash advance application that is networked to and interfaces with the selected system, and completes the cash advance application; (5) the selected system or the cash advance application prints a transaction receipt; (6) the customer signs the receipt confirming the transaction took place (the customer's signature may be acquired on the physical receipt or it may be captured electronically through an electronic signature pad); (7) the receipt image is either physically stored or scanned and retained electronically and stored for subsequent transmittal to a central server (the central server may be maintained by the casino or a third-party facilitator that maintains the cash advance application); (8) the transaction information, including the receipt image if applicable, is recorded on the central server; and (9) the central server generates an ACH file containing all the cash advance transactions completed for a predetermined specified settlement period and electronically transmits the ACH file to the casino's designated financial institution for processing and successive posting of the deposits.
The “checkless” cash advance transaction has numerous advantages over existing systems. The casino benefits from the checkless transaction because all deposits are made electronically. The casino's financial institution typically receives funds for the current day's cash advance transactions within two business days. Additionally, the casino will not have the burden of physically depositing hardcopy drafts with the financial institution. Moreover, a casino that does not have a means to immediately transmit a paper document to the third-party facilitator or its financial institution can quickly transmit an ACH file electronically through various means (e.g., satellite from a cruise ship casino). The third-party facilitator benefits from the checkless transaction because research and retrieval of transaction receipts in the event of a cardholder dispute can be completed online with the option to display and print the electronic image of the signed customer receipt. There is no need for the third-party to managed or handle physical checks.
The system and method of the present invention provides a distinct improvement over previous configurations. In particular, the time requirements for performing a quasi-cash transaction (such as a cash advance transaction) are greatly minimized as necessary customer information need not be manually entered. In this regard, the system and method of the present invention preferably accounts for all formatting idiosyncrasies associated with the multitude of issued State identification cards. In one preferred embodiment, a customer database is automatically provided with customer identification information parsed from a State identification card.
As mentioned above, an alternative embodiment of a casino financial transaction system 210 in accordance with the present invention includes the use of wireless technology. As shown in block form in
One embodiment of the portable RCU 212 is shown in greater detail in
The power source 232 is adapted to supply requisite power to other components of the portable RCU 212 (e.g., the microprocessor), and renders the RCU 212 truly portable. Thus, in one preferred embodiment, the power source 232 is a battery, although other types of self-contained power supply devices are acceptable. Alternatively, the RCU 212 can be adapted to be powered by a separate power supply provided within the casino 218 (
The touch-screen display 234 and the keypad 236 provide a means for interaction between the customer 222 (
The touch-screen display 234 is further preferably formatted to provide a signature-capturing feature. In particular, the touch-screen display 234 in conjunction with the microprocessor 230 is preferably adapted to designate a signature box (shown generally at 254 in
The software used to control operation of the microprocessor 230 is stored in the ROM 240. Conversely, information entered via the touch-screen display 234, the keypad 236, and/or the magnetic card swipe reader 242 is stored by the microprocessor 230 in the RAM 238 for further processing. In particular, the microprocessor 230 formats the data and signals information via the IR transmitter 246.
The magnetic card swipe reader 242 reads and decodes information on a magnetic stripe provided by a financial card and/or an identification card (not shown) otherwise swiped through the reader 242. The swipe reader 242 sends information to the decode logic module 244 that converts the serial bit stream from the reader 242 into a byte-wide stream for input to the microprocessor 230. Alternatively, other configurations for converting information provided by the financial card and/or identification card otherwise swiped (or dipped) through the reader 242 can be incorporated.
Finally, in one embodiment, the RCU 212 includes a printer module 258 that is otherwise connected to the microprocessor 230. As described in greater detail below, the microprocessor 230 is adapted to operate the printer module 258 to print a transaction receipt that in turn is provided to the customer 222 (
In one preferred embodiment, the RCU 212 is a remote control unit available under the trade name “ICE 4000” from Hypercom Corp., of Phoenix, Ariz. Alternatively, other forms are equally acceptable.
Further detail regarding the base processor module 214 is provided in
The display 274 is adapted to inform a user of a particular operational status, whereas the keypad 276 affords the ability to enter desired information.
The transmitting/receiving device 272 is adapted to transmit and receive wireless signaled information to and from the RCU 212 (
A preferred method of operating the system 210 in accordance with the present invention is provided in flow diagram form in
The customer 222 then desires to obtain cash or other negotiable item to continue playing at the gaming area 220. With this in mind, at step 102, the portable RCU 212 is provided to the customer 222 at the gaming area 220. For example, where the gaming area 220 is a card table, the portable RCU 212 can be located on the table itself, or can be stored within arm's reach of an attendant (e.g., dealer, pit boss, etc.) who then provides the portable RCU 212 to the customer 222. Alternatively, casino “runners” are normally dispersed throughout the casino 218 who constantly walk about the casino 218, and are available to assist customers. With this in mind, where the customer 222 is located at a discrete gaming area (e.g., slot machine, video poker, etc.), the runner or other casino personnel can hand deliver the portable RCU 212 to the customer 222. Regardless, the customer 222 is not required to exit or otherwise leave the gaming area 220 to access or interact with the portable RCU 212.
In one preferred embodiment, the RCU 212 then prompts the customer 222 (or casino attendant) to enter location identification information indicative of the particular casino location (or gaming area) at which the RCU 212 and the customer 222 are currently located at step 103. As described in greater detail below, documentation and/or a negotiable item may be delivered from a location of the base processor module 214 to the customer 222 upon completion of the financial transaction. To ensure that the document(s) and/or instrument is correctly delivered to the customer 222 (and not to a different customer using a separate RCU), an indication is preferably provided to the base processor module 214 (and thus a casino attendant otherwise responsible for delivering document(s)/instruments from the base processor module 214) of the casino location at which the financial transaction is being performed. The location identification information can assume a wide variety of forms, such as cashier number/designation, table number/designation, gaming machine number/designation, etc. Alternatively, the RCU 212 can be programmed to automatically provide pre-determined location identification information (e.g., where the RCU 212 is permanently located at a specific gaming table, the corresponding table number/designation information can be entered into, and saved by, the RCU 212). Where appropriate, the proper location identification information is entered at step 104. Alternatively, where identifying a specific location of the RCU 212 and/or the customer 222 is of little or no concern, steps 103 and 104 can be omitted.
The customer 222 enters information derived from a financial institution-issued card otherwise owned by the customer 222 at step 105. As is known, various financial institutions issue cards to their customers that include account information based upon which the customer can utilize to access funds otherwise maintained in that account. Examples of available financial institution cards include credit cards, debit cards, bank cards, etc. The account information can be manually entered by the customer 222 (and/or an attendant) via the touch-screen display 234, or by simply swiping (or dipping) the card through the magnetic card swipe reader 242 (
The RCU 212 then prompts the customer 222 to enter transaction information into the RCU 212 at step 106. In particular, the customer 222 is requested to enter a desired amount of the proposed financial transaction. At step 108, the customer 222 provides the transaction information to the RCU 212, such as by the touch-screen display 234.
In one preferred embodiment, the RCU 212 is adapted to determine a transaction fee to be paid by the customer 222 based upon the previously-entered desired amount (e.g., 7% of the desired amount). Alternatively, a predetermined “standard” transaction fee can be stored by the RCU 212 (e.g., $25). Regardless, the determined transaction fee is displayed to the customer in conjunction with the desired transaction amount at step 109, along with a request that the customer 222 confirm that the desired transaction amount is correct and that he or she agrees to pay the transaction fee (e.g., pressing a designated key on the RCU 212). Alternatively, the financial transaction of the present invention can be performed without a transaction fee.
The financial card information and transaction information (including the transaction fee where applicable) are signaled from the RCU 212 to the base processor module 214 via wireless transmission at step 110. In a preferred embodiment, the previously entered location identification information is also signaled from the RCU 212 to the base processor module 214, and in particular the transmitting/receiving device 272, at step 110. The base processor 270 is then operated to obtain approval for the desired financial transaction (including the transaction fee where applicable) from the financial institution that otherwise issued the particular financial card at step 112. For example, the base processor 270 can be connected (such as via a phone line) to a financial transaction processing service provider. Again, one such service provider is Vital Processing Services of Tempe, Ariz. In general terms, the requested transaction amount (including the transaction fee where applicable) is either authorized or denied by the service, with this decision then being provided to the base processor 270. The base processor 270, in turn, signals (via the transmitting/receiving device 272) the approval or denial of the transaction request to the portable RCU 212 at step 114.
Assuming the requested transaction amount (including the transaction fee where applicable) has been approved, the portable RCU 212 then prompts the customer 222, at step 116, to enter personal identification information, such as the customer's 222 name, address, zip code, etc. In one preferred embodiment, the base processor module 214 maintains a personal identification database. In the event the customer 222 has previously performed a financial transaction through the system 210 (as indicated, for example, by previously processing a financial institution card matching the financial card information previously provided at step 104), the base processor module 214 can signal saved personal identification information to the RCU 212 that in turn displays it to the customer 222. The customer 222 need only confirm the accuracy of the displayed information. Alternatively, the personal information is retrieved from a personal identification card, as outlined below. Regardless, at step 118, the requested information is entered (or confirmed or updated if necessary), either manually via the touch-screen 234 and/or the keypad 236, or by swiping an appropriate identification card (e.g., a driver's license formatted to include a magnetic strip). An attendant, at step 120, then verifies the entered information.
At step 122, the RCU 212 prompts the customer 222 to enter his/her signature into the RCU 212. The customer 222 personally provides this signature at step 124. Once again, the customer 222 can enter his/her signature into the RCU 212 in a variety of fashions, but is preferably accomplished via the electronic pen 256 and the designated box 258 provided on the touch-screen display 234. Regardless, at step 126, the RCU 212 electronically captures and stores the entered signature. The RCU 212 then signals the identification information and the electronically captured signature to the base processor module 214 via a wireless transmission, as previously described, at step 128.
With the relevant identification and electronically captured signature information in hand, the base processor 270 is operated, at step 130, to print a negotiable financial document via the attached printer 216. The negotiable financial document can assume a variety of forms, such as a check or money order, but will include the customer's 222 signature (reproducing in ink on the printed document the electronically captured signature). In one preferred embodiment, the printed negotiable document is a financial note issued by a provider of the system 210, that, when cashed by the casino, is drawn upon the system provider's bank account. With this approach, the customer's signature is necessary to satisfy draft completion requirements set forth by most, if not all, financial institutions that issue financial cards. Thus, the customer's signature ensures that the system provider (or other third party provider) will not be held liable in the event the customer 222 later disputes the transaction.
The printed negotiable financial document will have a negotiable monetary value equivalent to a value of the desired financial transaction. In one preferred embodiment, where the financial transaction includes a transaction fee, the negotiable financial document will have a monetary value equal to the desired amount, along with a notation that the financial transaction fee has been charged against the customer's 222 designated account, with this transaction fee having been transferred to a separate designated financial account (e.g., the provider of the system 210) by the base processor module 214. Notably, this type of financial transaction processing is normally carried out through an automated clearing house (ACH) as is known in the art. In a further preferred embodiment, the printed negotiable financial document includes the previously provided location identification information for reasons described below.
Regardless of the exact content, once printed, the casino 218 can process the negotiable financial document in accordance with its internal procedures. In one preferred embodiment, multiple copies of the negotiable financial document are printed, with only one of the printed documents be validly negotiable. For example, the document can be printed in triplicate, with two of the three versions being denoted as “non-negotiable”. In any event, at step 132, a negotiable item is delivered to the customer 222 having a monetary value equal to the monetary value of the printed negotiable financial document. The negotiable item delivered to the customer can assume a variety of forms, and can include for example cash, chips, a separately prepared money order, or the previously printed financial document. Delivery of the negotiable item can take a variety of forms. For example, the attendant or runner (or other casino personnel) can review the approved information provided by the portable RCU 212 and provide the customer 222 with an amount of cash or chips equivalent to the approved amount or a casino-issued gaming card programmed to provide an account with the casino having a balance equivalent to the approved amount. Alternatively, an operator of the base processor module 214 can, after reviewing and processing the printed negotiable financial document, personally deliver, or direct another casino employee or other designee to deliver, chips, cash, or a casino-issued gaming card to the customer 222. In one preferred embodiment, the portable RCU 212 is further operated to print a transaction receipt that is given to the customer 222. In addition, or alternatively, a copy of the previously printed negotiable document is provided to the customer 222. In this regard, the location identification information, otherwise preferably printed on the document, provides a clear indication to the casino employee of where in the casino the document (and/or negotiable item) is to be delivered. This is especially useful in a casino having multiple RCUs 212 in operation.
Additionally, the RCU 212 is also capable of processing a checkless transaction as discussed above. In this embodiment, printed receipts are provided by RCU 212 at the completion of the transaction.
The system and method of the present invention provides a marked improvement over previous designs. In particular, casino customers are able to conveniently obtain additional monetary funds via an off-site financial institution account without ever having to leave the gaming area at which the customer is located. The all-to-common frustration of prematurely terminating a gaming activity is avoided and casinos are better able to keep a customer engaged in a gaming activity.
Although the present invention has been described with reference to preferred embodiments, workers skilled in the art will recognize that changes can be made in form and detail without departing from the spirit and scope of the present invention. For example, the identification card used could be any card deemed to be a reliable source of identification. Often, these include government issued cards such as driver's licenses, passports, etc. Additionally, while the system and method of the present invention has been described in the context of a casino, other environments are equally acceptable. The quasi-cash transaction can be performed in other locales, such as a racetrack, bingo parlor, nightclub, etc.
This application is a continuation of Ser. No. 14/231,029, filed Mar. 31, 2014, which is a continuation of U.S. patent application Ser. No. 13/245,516, filed Sep. 26, 2011, which is a continuation application of U.S. patent application Ser. No. 12/268,857, filed Nov. 11, 2008, now U.S. Pat. No. 8,025,216, which is continuation application of U.S. patent application Ser. No. 11/223,708, filed Sep. 9, 2005, now U.S. Pat. No. 7,461,780, which claims the benefit of U.S. Provisional Application No. 60/608,196, filed Sep. 9, 2004.
Number | Name | Date | Kind |
---|---|---|---|
4390968 | Hennessy et al. | Jun 1983 | A |
4567358 | Takamatsu et al. | Jan 1986 | A |
4689742 | Troy et al. | Aug 1987 | A |
4764666 | Bergeron | Aug 1988 | A |
4882473 | Bergeron et al. | Nov 1989 | A |
5025373 | Keyser, Jr. et al. | Jun 1991 | A |
5038022 | Lucero | Aug 1991 | A |
5157717 | Hitchcock | Oct 1992 | A |
5179517 | Sarbin et al. | Jan 1993 | A |
5223699 | Flynn et al. | Jun 1993 | A |
5265874 | Dickinson et al. | Nov 1993 | A |
5285382 | Muehlberger et al. | Feb 1994 | A |
5321241 | Craine | Jun 1994 | A |
5326960 | Tannenbaum | Jul 1994 | A |
5350906 | Brody et al. | Sep 1994 | A |
5386104 | Sime | Jan 1995 | A |
5429361 | Raven et al. | Jul 1995 | A |
5457306 | Lucero | Oct 1995 | A |
5470079 | LeStrange et al. | Nov 1995 | A |
5477038 | Levine et al. | Dec 1995 | A |
5613912 | Slater | Mar 1997 | 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 |
5813912 | Shultz | Sep 1998 | A |
5864623 | Messina et al. | Jan 1999 | A |
5897625 | Gustin et al. | Apr 1999 | A |
5902983 | Crevelt et al. | May 1999 | A |
5916024 | Von Kohorn | Jun 1999 | A |
5919091 | Bell et al. | Jul 1999 | A |
5959277 | Lucero | Sep 1999 | A |
5987132 | Rowney | Nov 1999 | A |
5991410 | Albert et al. | Nov 1999 | A |
5999624 | Hopkins | Dec 1999 | A |
6001016 | Walker et al. | Dec 1999 | A |
6038553 | Hyde, Jr. | Mar 2000 | A |
6044360 | Picciallo | Mar 2000 | A |
6045039 | Stinson et al. | Apr 2000 | 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 |
6164528 | Hills 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 | 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 |
6577733 | Charrin | 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 |
6609978 | Paulsen | Aug 2003 | B1 |
6628939 | Paulsen | Sep 2003 | B2 |
6675152 | Prasad et al. | Jan 2004 | B1 |
6676522 | Rowe et al. | Jan 2004 | B2 |
6682421 | Rowe et al. | Jan 2004 | B1 |
6709333 | Bradford et al. | Mar 2004 | B1 |
6800029 | Rowe et al. | Oct 2004 | B2 |
6846238 | Wells | Jan 2005 | B2 |
6851607 | Orus et al. | Feb 2005 | B2 |
6852031 | Rowe | Feb 2005 | B1 |
6866586 | Oberberger et al. | Mar 2005 | B2 |
6869362 | Walker et al. | Mar 2005 | B2 |
6951302 | Potts | Oct 2005 | B2 |
6997807 | Weiss | Feb 2006 | B2 |
7003496 | Ishii et al. | Feb 2006 | B2 |
7094149 | Walker et al. | Aug 2006 | B2 |
7168089 | Nguyen et al. | Jan 2007 | B2 |
7311605 | Moser | Dec 2007 | B2 |
20010020638 | Uematsu | Sep 2001 | A1 |
20010022849 | Simonoff | Sep 2001 | A1 |
20010044337 | Rowe et al. | Nov 2001 | A1 |
20010050311 | Avellino | Dec 2001 | A1 |
20020002075 | Rowe | Jan 2002 | A1 |
20020026426 | Bennett | Feb 2002 | A1 |
20020039921 | Rowe et al. | Apr 2002 | A1 |
20020039923 | Cannon et al. | Apr 2002 | A1 |
20020045476 | Poole et al. | Apr 2002 | A1 |
20020068624 | Ellis | Jun 2002 | A1 |
20020103027 | Rowe et al. | Aug 2002 | A1 |
20020132664 | Miller et al. | Sep 2002 | A1 |
20020147047 | Letovsky et al. | Oct 2002 | A1 |
20020175207 | Kashef et al. | Nov 2002 | A1 |
20020177479 | Walker et al. | Nov 2002 | A1 |
20020193099 | Paulsen | Dec 2002 | A1 |
20030033534 | Rand et al. | Feb 2003 | A1 |
20030036425 | Kaminkow et al. | Feb 2003 | A1 |
20030045353 | Paulsen | Mar 2003 | A1 |
20030078094 | Gatto et al. | Apr 2003 | A1 |
20030087692 | Weiss | May 2003 | A1 |
20030104865 | Itkis et al. | Jun 2003 | A1 |
20030105710 | Barbara | Jun 2003 | A1 |
20030106769 | Weiss | Jun 2003 | A1 |
20030119585 | Walker et al. | 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 |
20030236749 | Shergalis | Dec 2003 | A1 |
20040049401 | Carr et al. | Mar 2004 | A1 |
20040053693 | An | Mar 2004 | A1 |
20040063494 | Oram et al. | Apr 2004 | A1 |
20040093303 | Picciallo | May 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 |
20050054417 | Parrott et al. | Mar 2005 | A1 |
20050054446 | Kammler et al. | Mar 2005 | A1 |
20050080728 | Sobek | Apr 2005 | A1 |
20050091161 | Gustin | Apr 2005 | A1 |
20050096124 | Stronach | May 2005 | 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 |
Number | Date | Country |
---|---|---|
1107196 | Jun 2001 | EP |
2380687 | Apr 2003 | GB |
20011294100 | Oct 2001 | JP |
9323817 | Nov 1993 | WO |
9416781 | Aug 1994 | WO |
9713228 | Apr 1997 | WO |
Entry |
---|
“AAMVA National Standard for the Driver License/Identification Card—AAMVA DL/ID-2000”, American Association of Motor Vehicle Administrators (AAMVA). (c) 2000 AAMVA/AAMVAnet, 104 pages. |
Burbank, Jeff, “Despite Critics, new ATMs roll in”, Las Vegas Business Press, Jun. 28, 1999, 3 pages. |
Neal, Emily, “Casino credit under fire”, Journal Starr, May 8, 2000, 3 pages. |
Quinn, William, “Worth Their Weight in Gold”, Global Gaming Business Apr. 1, 2003, pp. 24-26. |
Number | Date | Country | |
---|---|---|---|
20160098809 A1 | Apr 2016 | US |
Number | Date | Country | |
---|---|---|---|
60608196 | Sep 2004 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 14231029 | Mar 2014 | US |
Child | 14969916 | US | |
Parent | 13245516 | Sep 2011 | US |
Child | 14231029 | US | |
Parent | 12268857 | Nov 2008 | US |
Child | 13245516 | US | |
Parent | 11223708 | Sep 2005 | US |
Child | 12268857 | US |