Patent Application
20210358269
The present invention relates to technology for maintaining appropriate social distancing in casinos and other gaming establishments.
This section introduces aspects that may help facilitate a better understanding of the invention. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is prior art or what is not prior art.
In light of the Covid-19 virus pandemic, it is important to maintain appropriate physical separation between individuals to reduce the spread of the virus, referred to as social distancing. Casinos and other gaming establishments are introducing techniques for maintaining proper social distancing between their patrons. For example, some casinos are removing every other gaming machine (e.g., slot machine or poker machine) in each row of machines in the casino and the associated chairs to attempt to keep patrons separated. Such drastic measures are expensive to implement and even more expensive to reverse if and when social distancing is no longer needed.
Embodiments of the invention will become more fully apparent from the following detailed description, the appended claims, and the accompanying drawings in which like reference numerals identify similar or identical elements.
Detailed illustrative embodiments of the present invention are disclosed herein. However, specific structural and functional details disclosed herein are merely representative for purposes of describing example embodiments of the present invention. The present invention may be embodied in many alternate forms and should not be construed as limited to only the embodiments set forth herein. Further, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments of the invention.
As used herein, the singular forms “a,” “an,” and “the,” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It further will be understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” specify the presence of stated features, steps, or components, but do not preclude the presence or addition of one or more other features, steps, or components. It also should be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.
The '292 patent and the '899 application describe distributed gaming systems that allow casino patrons to purchase gaming credit at gaming machines using specially designed applications (referred to herein as the “gaming apps”) on their cell phones and other wireless devices. According to the current disclosure, those gaming systems and those gaming apps are modified to support social distancing between patrons in a casino.
Casino System with Tokenized Transaction Packages
In certain implementations, the gaming system 600 is a retrofit gaming system based on a legacy gaming system that was originally designed to support paper vouchers, but not virtual vouchers, and which has been upgraded to support the functionality described below. In particular, the gaming system 600 of
In certain other implementations, the gaming system 600 is provisioned with original OEM (original equipment manufacturer) components that were originally designed and built to support the functionality of system 600 described herein.
Also shown in
The ticket server 610/voucher database 612 may be any suitable legacy ticket server/voucher database for casinos, including (without limitation) an EZ Pay ticket server from IGT of Reno, Nev.; an SDS, SDG, or ACSC ticket server from Bally Technologies Inc. of Enterprise, Nev.; a SYNKROS ticket server from Konami Gaming, Inc., of Las Vegas, Nev.; or an Oasis ticket server from Aristocrat Technologies, Inc., of Las Vegas, Nev. The ticket server 610 creates a gaming voucher by assigning a unique voucher ID to a specified monetary value and storing the voucher ID and the monetary value for the gaming voucher as related entries in a table of the voucher database 612. In certain implementations of the gaming system 600 of
The kiosk 630 may be based on any suitable kiosk designed for casinos, including (without limitation) an LSK series kiosk from Global Payments Gaming Services, Inc., of Las Vegas, Nev.; an Everi kiosk from Everi Holdings Inc. of Las Vegas, Nev.; an M3T kiosk from M3 Technology Solutions, LLC, of Norman, Okla.; or a suitable kiosk from any of NRT Technology Corp. of Canada; Glory Global Solutions Limited of Japan; Automated Systems America, Inc., of Glendale, Calif.; or Diebold Nixdorf, Inc., of North Canton, Ohio. Depending on the particular implementation, the kiosk 630 may be based on a legacy kiosk whose software has been upgraded to support the functionality of system 600 or the kiosk 630 may be a new OEM kiosk that was originally designed and built to support that functionality.
The gaming machine 640 may be based on any suitable gaming machine for casinos, including (without limitation) a suitable gaming machine from any of IGT of Reno, Nev.; Scientific Games Corporation of Las Vegas, Nev.; Aristocrat Technologies, Inc., of Las Vegas, Nev.; Konami Gaming, Inc., of Las Vegas, Nev.; Ainsworth Game Technology Inc. of Las Vegas, Nev.; or Everi Holdings Inc. of Las Vegas, Nev. Here, too, depending on the particular implementation, the gaming machine 640 may be based on a legacy gaming machine that has been upgraded to support the functionality of system 600 (as described further below) or the gaming machine 640 may be a new OEM gaming machine that was originally designed and built to support that functionality.
Depending on the implementation, the tag 644 has associated with it a unique tag identification (ID) value. The tag 644 may be affixed to or mounted onto an outer surface of the gaming machine 640, e.g., on or near the input panel or mounted inside the gaming machine 640 itself, e.g., behind or near the input panel. The tag 644 may be (i) an optically readable tag that represents the tag ID using an optically readable code symbol, such as (without limitation) a one-dimensional barcode or a two-dimensional QR code, or (ii) a wirelessly readable tag, such as (without limitation) an RFID or NFC tag, that wirelessly transmits the tag ID, or any other suitable means for conveying the tag ID to the cell phone 650. Depending on the particular type of wireless tag used, the reading of the tag 644 by the cell phone 650 may involve two-way wireless communication (e.g., a query by the cell phone 650 followed by a response by the tag 644) or one-way wireless communication (e.g., the cell phone 650 detecting a beacon transmitted by the tag 644).
When the tag 644 is an optically readable tag, the cell phone 650 is able to optically read the code symbol to determine the tag ID. When the tag 644 is a wirelessly readable tag, the cell phone 650 is able to receive and process a wireless signal transmitted by the tag 644 to determine the tag ID. In either case, the tag ID uniquely identifies and distinguishes the gaming machine 640 from all other gaming machines in the casino, each of which is analogous to the gaming machine 640 and has its own unique tag. Note that the tag 644 may be both an optically readable tag having a code symbol representing the tag ID and a wirelessly readable tag that transmits a wireless signal representing that same tag ID.
As indicated in
The gaming system 600 enables a patron to use his cell phone 650 to request and facilitate the transfer of gaming credit (i.e., funds) corresponding to a specified monetary value to the gaming machine 640 selected by the patron to enable the patron to play the gaming machine 640 without having physically to insert into the gaming machine, money or other financial transaction means such as (without limitation) a paper TITO ticket, a player card, a credit/debit bank card. Note that, in some implementations, as described below and unlike a conventional virtual or electronic wallet (aka e-wallet), at no time during this process, do the funds associated with the gaming credit ever reside on the cell phone 650 itself or in an account associated with the patron. Moreover, at no time does the cell phone 650 or the patron have access to the voucher ID of any gaming voucher purchased by the patron or on behalf of the patron using the cell phone 650.
Prior to the operations associated with an individual transfer of gaming credit to the patron's selected gaming machine 640, the patron registers with the transaction server 620, which creates a user profile for the patron in the reporting database 622. In some implementations, the user profile includes a unique user ID associated with the patron, a unique cell phone ID associated with the patron's cell phone 650, information regarding one or more funding sources (for example, without limitations, credit or debit card bank accounts, existing gaming vouchers stored in the voucher database 612, or an e-wallet) for the patron, and authentication information for the patron (for example, without limitation, a PIN (personal identification number), finger print, thumb print, voice print, face print, retina print, transaction DNA, block chain, token, and/or certificate associated with the patron).
The transaction server 620 also maintains in the reporting database 622, for each registered patron, a transaction ledger that documents the transactions performed by the patron using the cell phone 650, where, for each transaction, the transaction ledger includes the voucher ID of the gaming voucher created for the transaction, the monetary value of the transaction, the type of the transaction (e.g., crediting a gaming machine vs. other types of transactions), a date-and-time stamp for the transaction, and a location associated with the transaction (e.g., the tag ID of the gaming machine's tag 644). With at least one viable funding source registered with the transaction server 620, the patron is able to use his cell phone 650 to have gaming credit transferred to the gaming machine 640 for use by the patron to play the gaming machine's game, according to the processing described below. When the patron's user profile identifies multiple funding sources, the patron can use the cell phone 650 to select a default funding source and be queried by the transaction server 620 to select a different funding source if the default funding source is deficient.
At step 1, the patron uses the gaming app on his cell phone 650 to transmit a gaming-credit purchase request via the wireless network 602 to the transaction server 620 to begin the process of having gaming credit transferred to a to-be-specified gaming machine on behalf of the patron. The purchase request includes the cell phone ID, the desired monetary value of the requested gaming credit, and authentication information for the patron.
At step 2, the transaction server 620 accesses the patron's user profile in the reporting database 622 using the received cell phone ID and determines whether to authorize the patron's purchase request by (i) comparing the received authentication information with the patron's authentication information stored in the patron's user profile and (ii) determining whether the requested monetary value is acceptable (e.g., within specified limits previously established by and/or for the patron).
Assuming that the purchase request is authorized, at step 3, the transaction server 620 creates a new transaction record in the patron's transaction ledger in the reporting database 622 for the new transaction and records the monetary value in the new transaction record. The transaction server 620 assigns a unique transaction ID that contains the patron's user ID and stores that transaction ID in the transaction record. Assigning a unique transaction ID associated with each transaction associated with the cell phone's unique ID enables the transactions to be uniquely batched and tracked using duplicate ledgers, where batch handling and backups can be continuously updated and appended without duplication.
At step 4, the transaction server 620 transmits a kiosk voucher request via the wireless network 602 to the kiosk 630, where the kiosk voucher request includes the transaction ID and the monetary value.
At step 5, the kiosk 630 receives the kiosk voucher request and transmits a ticket-server voucher request via the communication link 604 to the ticket server 610, where the ticket-server voucher request includes (at least) the monetary value and a local date-and-time stamp. Those skilled in the art will understand that some ticket servers may require additional information, such as (without limitation) a unique kiosk ID associated with the kiosk 630. The kiosk 630 maintains a voucher-request ledger that maps the kiosk voucher request received from the transaction server 620 to the ticket-server voucher request that the kiosk 630 sent to the ticket server 610.
At step 6, upon receiving the ticket-server voucher request from the kiosk 630, the ticket server 610 creates a new gaming voucher having the monetary value specified in the ticket-server voucher request, by (i) assigning a unique voucher ID, (ii) storing the voucher ID, the monetary value, the date-and-time stamp, and (if appropriate) the kiosk ID in the voucher database 612, and (iii) transmitting the voucher ID and the received date-and-time stamp via the communication link 604 to the kiosk 630.
At step 7, the kiosk 630 uses the received date-and-time stamp to retrieve the corresponding transaction ID from its local memory and transmits the voucher ID and the transaction ID via the wireless network 602 to the transaction server 620.
At step 8, the kiosk 630 starts a voucher-redemption timer having a specified duration (e.g., 3 seconds) for the new gaming voucher. If the voucher-redemption timer expires before the new gaming voucher is redeemed, then the kiosk 630 takes steps to cancel the transaction. These steps are described below with respect to steps 30-35.
At step 9, the transaction server 620 uses the transaction ID received from the kiosk 630 in step 7 to identify the corresponding transaction record in the patron's transaction ledger in the reporting database 622 and adds the received voucher ID to that transaction record.
At step 10, the transaction server 620 transmits to the cell phone 650 via the wireless network 602, a message indicating that a new gaming voucher has been successfully created for the requested transaction and that the patron needs to identify the gaming machine 640 that the patron wants to play.
At step 11, as instructed by the cell phone 650, the patron uses the cell phone 650 to read the tag ID associated with the tag 644 mounted on the gaming machine to be credited.
In a casino with many instances of the gaming machine 640, each having an instance of the BLE peripheral device 642, the cell phone 650 will simultaneously receive multiple BLE signals from nearby gaming machines 640. In order to read the tag 644 of the desired gaming machine 640, the patron places the cell phone 650 near that tag 644, thereby improving the probability that the BLE signal from the BLE peripheral device 642 of that gaming machine 640 will have a received signal strength at the cell phone 650 that is greater than the individual received signal strengths of the BLE signals from the BLE peripheral devices 642 of all of the other gaming machines 640 in the casino. When the cell phone 650 reads the tag 644, at step 12, the cell phone 650 selects the BLE signal with the strongest signal level and stores the peripheral device ID (e.g., the serial number of the BLE peripheral device 642) contained in that signal.
At step 13, the cell phone 650 transmits the tag ID, the transaction ID, and the phone ID to the transaction server 620 via the wireless network 602.
At step 14, the transaction server 620 adds the tag ID to the transaction record in the patron's transaction ledger in the reporting database 622. The transaction server 620 identifies the transaction ledger for the patron using the transaction ID and the phone ID received from the cell phone 650.
The transaction server 620 maintains a tag ID table registered by the casino, that maps tag IDs to peripheral device IDs and the type of transaction (e.g., funding a gaming machine vs. a different type of transaction). At step 15, the transaction server 620 uses the tag ID received from the cell phone 650 to access the tag ID table to determine if the type of transaction is funding a gaming machine. If so, then, at step 16, the transaction server 620 retrieves from the tag ID table, the peripheral device ID associated with the received tag ID. Note that the tag ID table also stores, for each tag, a business ID identifying the casino and an encryption key for the peripheral device 642 (if encryption is supported, as described below for step 17).
At step 17, the transaction server 620 generates a transaction package for the transaction. As used herein, the term “transaction package” is a formatted message that represents (at least) the voucher ID of the gaming voucher for the transaction. In one possible implementation, the transaction package contains the unencrypted voucher ID. In another possible implementation, the transaction package contains an encrypted value representing the voucher ID. In yet another possible implementation, the transaction package contains the unencrypted voucher ID and the unencrypted monetary value associated with that voucher ID. In a preferred implementation of
At step 18, the transaction server 620 transmits the TTP message along with the retrieved peripheral device ID to the cell phone 650 via the wireless network 602.
At step 19, the cell phone 650 compares the peripheral device ID received from the transaction server 620 to the stored peripheral device ID associated with the previously selected, strongest received BLE signal.
If there is not a match, then, at step 20, the cell phone 650 instructs the patron to move the cell phone 650 closer to the tag 644 to enable the cell phone 650 to re-select the BLE signal having the strongest received signal strength. Processing then returns to step 19. Moving the cell phone 650 closer to the tag 644 improves the probability that the strongest received BLE signal will be from the BLE peripheral device 642 of the selected gaming machine 640. The processing of steps 19 and 20 continues until the peripheral device IDs compared in step 19 match. If the IDs do not match quickly enough, then the voucher-redemption timer in the kiosk 630 will time out, the kiosk 630 will redeem the voucher (as described previously), and the cell phone 650 will instruct the patron to start over.
If and when there is a match, at step 21, the cell phone 650 establishes a Bluetooth connection with the BLE peripheral device 642 of the selected gaming machine 640 and transmits the TTP message to the BLE peripheral device 642. Note that, in some implementations, the cell phone 650 does not decrypt the TTP message. As such, neither the cell phone 650 nor the patron has access to the voucher ID.
At step 22, the BLE peripheral device 642 decrypts the received TTP message to recover the monetary value and the voucher ID.
At step 23, the BLE peripheral device 642 transmits the voucher ID and the monetary value to the gaming machine 640, which adds the monetary value to its running total of all of the recent purchases of its gaming credit.
Note that, in an alternative implementation, the bill validator of the gaming machine 640, and not the BLE peripheral device 642, decrypts the received TTP message to recover the monetary value and the voucher ID. In that case, steps 22 and 23 will instead involve the BLE peripheral device 642 transmitting the TTP message to the gaming machine's bill validator, which then decrypts the TTP message.
At step 24, the gaming machine 640 transmits the voucher ID to the ticket server 610 via the communication link 606.
At step 25, the ticket server 610 accesses the voucher database 612 to retrieve the monetary value associated with the received voucher ID, transmits the retrieved monetary value to the gaming machine 640, and updates the voucher database 612 to indicate that the voucher has been redeemed. In some implementations, updating the voucher database 612 involves deleting the voucher record from the database; in other implementations, it involves re-setting the monetary value of the voucher to be zero.
At step 26, the gaming machine 640 increases its gaming credit by the received monetary value, thereby enabling the patron to play or continue to play the gaming machine 640.
In one implementation, a transaction-funding business that operates the transaction server 620 is a check-underwriting service that keeps track of all of the different operations and gets paid off-line, as needed, by the casino and/or the different patrons. If the patron's funding source for the transaction was a credit/debit bank card, then, at step 27, the transaction server 620 communicates with the appropriate banking network 624 to reimburse the transaction-funding business that operates the transaction server 620 for paying for the gaming credit using conventional bank-to-bank ACH (automated clearing house) processing. If the patron's funding source was a different, previously created, but never redeemed gaming voucher, then, at step 28, the transaction server 620 instructs a kiosk, such as the kiosk 630, to redeem that voucher with the ticket server 610 at step 29. Note that fees may be charged by different entities to support the operations of the gaming system 600. For example, the transaction server 620 may charge a fee to the patron and/or the casino for each transaction.
When the voucher-redemption timer that was set in step 8 expires, at step 30, the kiosk 630 queries the ticket server 610 about the status of the gaming voucher, and the ticket server 610 responds by confirming whether or not the gaming voucher has been redeemed. Under normal circumstances, using processing described above, the gaming voucher will be redeemed by the gaming machine 640 well before the voucher-redemption timer times out, in which case, the ticket server 610 will respond to the kiosk 630 by indicating that the gaming voucher is has been redeemed. In that case, the kiosk 630 assumes that the gaming machine 640 properly redeemed the gaming voucher and so the kiosk 630 takes no further corrective actions.
If, however, the ticket server 610 indicates to the kiosk 630 that the gaming voucher has not been redeemed, then the kiosk 630 determines that something has gone wrong and takes action to un-do the transaction. In particular, at step 31, the kiosk 630 transmits a request to the ticket server 610 to redeem the gaming voucher, and the ticket server 610 retrieves and transmits the corresponding monetary value to the kiosk 630 and updates the voucher database 612 to indicate that the voucher has been redeemed. At step 32, the kiosk 630 then instructs the transaction server 620 to cancel or reverse the transaction. At step 33, the transaction server 620 (i) transmits a message via the wireless network 602 to the cell phone 650 indicating that the cell phone's gaming-credit purchase request has failed and (ii) updates the patron's transaction ledger accordingly. At step 34, the cell phone 650 informs the patron that the request for gaming credit has failed and (optionally) asks the patron to try again. If necessary, at step 35, the transaction server 620 also sends a message to the appropriate banking network 624 to reverse the transaction.
In one retrofit implementation, a legacy gaming system is upgraded to provide the gaming system 600 of
As understood by those skilled in that art, the game controller 804 controls the operations of the game that is played on the gaming machine 640, the network interface 806 enables the gaming machine 640 to communicate with the ticket server 610 of
As described previously with reference to step 23, the BLE peripheral device 642 transmits the voucher ID and the monetary value to the gaming machine 640. In particular, the BLE peripheral device 642 transmits the voucher ID and the monetary value to the bill validator 802, which (i) forwards the voucher ID to the game controller 804 in a way that is identical to how a legacy bill validator would forward a voucher ID associated with a received paper voucher to a legacy game controller and (ii) forwards the monetary value to the bill/voucher stack 810 in a way that is identical to how a legacy bill validator would forward a monetary value for a received paper voucher to a legacy, smart bill/voucher stack. The game controller 804 forwards the voucher ID to the network interface 806, and the network interface 806 transmits the voucher ID to the ticket server 610 of
Note that the kiosk 630 and the gaming machine 640 still support all of the legacy functionality associated with paper vouchers, including paper-based cash-in and cash-out operations.
Although the operations of the gaming system 600 have been described in the context of the gaming machine 640 of
Although the operations of the gaming system 600 have been described in the context of funding gaming credit at gaming machines such as (without limitation) slot machines and electronic poker machines, in certain implementations, the gaming system 600 can also support funding gaming credit at gaming tables such as (without limitation) blackjack tables and roulette tables. In those implementations, the transaction server 620 is able to instruct a voucher printer (not shown in
This section provides implementation details for the slot interface of a BLE peripheral device 642 according to one possible implementation of the gaming system 600 of
As described previously, the gaming system 600 enables a casino patron to purchase a gaming voucher using the cell phone 650 and have the corresponding gaming credit applied securely to a selected gaming machine 640 without the use of a paper ticket or currency. The patron interacts with the gaming machine's BLE peripheral device 642 and the transaction server 620 using a custom application installed on the patron's BLE-enabled cell phone 650.
The BLE peripheral device 642 is connected to the gaming machine's bill validator 802 within the locked cabinet of the gaming machine 640 such that radio signals can propagate through the cabinet to and from the BLE peripheral device 642. The BLE peripheral device 642 is near other instances of the BLE peripheral device 642, which broadcast the same advertised GATT Service. The proximity of nearby BLE peripheral devices is dependent on the layout of the casino floor and the positioning of the BLE peripheral device 642 within each gaming machine cabinet.
Each instance of the BLE peripheral device 642 is registered with the transaction server 620, which stores the following information in the reporting database 622 for each instance: a business ID identifying the casino, the serial number of the BLE peripheral device 642, and an encryption key for the BLE peripheral device 642 (if encryption is supported).
The patron has registered the cell phone 650 with the transaction server 620, and the cell phone 650 is capable of receiving a valid TTP message (containing the purchased voucher ID and the associated monetary value) from the transaction server 620. As described previously, the transaction server 620 has access to the kiosk 630, which in turn has access to the ticket server 610. The location of the casino is identified via a combination of assisted GPS plus the use of BLE beacons that are placed in the areas of the casino containing instances of the gaming machine 640, each of which is equipped with a BLE peripheral device 642 connected to its bill validator 802.
When the patron uses the cell phone 650 to read the tag 644 of a particular gaming machine 640, the cell phone 650 will be physically very near the BLE peripheral device 642 of that gaming machine 640. The typical distance between the cell phone 650 and the front of the gaming machine 640 is about 6 to 8 inches, with some transactions performed with the cell phone 650 almost directly on the front of the gaming machine 640 and other transactions with the cell phone 650 as far away as 12 inches. It is not expected that any transaction will be performed with the cell phone 650 more than 24 inches from the face of the selected gaming machine 640.
Unless the BLE peripheral device 642 has been connected to a cell phone 650 and is processing a TTP message, the BLE peripheral device 642 is repeatedly advertising its service by broadcasting its unique peripheral device ID, its transmit (TX) power level, the shared 128-bit Universal Unique Identifier (UUID) for the transaction service (i.e., purchasing gaming credit), and service data. The cell phone 650 measures the power level of the received (RX) signal and compares that measured RX power level to the received TX power level to estimate the distance from the cell phone 650 to the BLE peripheral device 642. The service data includes (at least) the manufacturer code and version number for the BLE peripheral device 642.
One exception is if the cell phone 650 connects and sends invalid data to the BLE peripheral device 642 three times consecutively; at which point, the BLE peripheral device 642 shuts down for one hour, driving a legacy suspected fraud response from the gaming machine 640. If the cell phone 650 connects but no data is received within 5 seconds, then the BLE peripheral device 642 disconnects and resumes advertising. The BLE peripheral device 642 connects to only a single cell phone 650 at a time; during which, the BLE peripheral device 642 stops advertising.
The following procedure is performed each time the patron requests funds for the purpose of transferring gaming credit to a gaming machine 640. Using the gaming application on the cell phone 650, the patron selects an option to transmit to the transaction server 620 a request for a TTP message that will be used to drive gaming credit to a selected gaming machine 640. The transaction server 620 interfaces with the kiosk 630, which in turn interfaces with the ticket server 610 to purchase a gaming voucher with a corresponding monetary value. The transaction server 620 bundles the authorized gaming voucher and associated information into a TTP message that is transmitted to the cell phone 650. TTP messages are short-lived and, if not redeemed by the selected gaming machine 640 within a specified time limit, will be auto-redeemed (reversed) back into the patron's account by the kiosk 630.
The patron uses the cell phone 650 to read the tag ID of the tag 644 on the selected gaming machine 640. The cell phone 650 transmits the tag ID to the transaction server 620, which uses the tag ID to access the reporting database 622 to retrieve and transmit back to the cell phone 650, the peripheral device ID associated with that same gaming machine 640. The cell phone 640 immediately begins to scan for nearby BLE peripheral devices 642. When the cell phone 650 determines that a nearby BLE peripheral device 642 is broadcasting the correct service UUID and a peripheral device ID that matches the peripheral device ID received from the transaction server 620, the cell phone 650 transmits a connection request to establish a connection with that BLE peripheral device 642.
If an encryption key exists for the BLE peripheral device 642, then the cell phone 650 exchanges random cryptographic data with the BLE peripheral device 642 to enable the cell phone 650 and the BLE peripheral device 642 to generate respective copies of an Initialization Vector (IV) that are exchanged between the two devices to secure a connection. If an encryption key is associated with the BLE peripheral device 642, then the TTP message will be encrypted using that encryption key; otherwise, the TTP message is non-encrypted.
The cell phone 650 transmits the TTP message to the BLE peripheral device 642 by writing the TTP message to a first specified characteristic “with response.” The BLE peripheral device 642 unbundles/decrypts the received TTP message to recover the voucher ID and the associated monetary value and transmits the monetary value back to the cell phone 650. Provided that the write of the TTP message is successful and the monetary value received from the BLE peripheral device 642 matches the monetary value originally requested by the cell phone 650, the cell phone 650 waits to be notified of an available response code on a second specified characteristic. The cell phone 650 continues to wait to be notified of a change in value of this response code until its length is non-zero, or until 10 seconds have elapsed. Example response codes are identified in the following table. If the BLE peripheral device 642 is not capable of sending any feedback data to the cell phone 650, then the BLE peripheral device 642 returns “00” as the default setting for the characteristic.
After the response code is read, the cell phone 640 will issue a disconnect request to the BLE peripheral device 642, at which time, the BLE peripheral device 642 immediately begins advertising for another connection request. In some implementations, if the response code returned from the BLE peripheral device 642 is “00,” then the cell phone 650 verifies that the gaming voucher has actually been redeemed by the gaming machine 640 by the cell phone 650 querying the ticket server 610 via the interface to the kiosk 630.
In some alternative embodiments, a BLE device could be connected direct to the gaming machine's interface board.
As mentioned previously, the gaming system 600 and the gaming app running on the cell phone 650 of
In certain implementations, a back-end server in the gaming system 600, such as the transaction server 620 of
In some implementations, to assist patrons in determining whether or not gaming machines are available for play, each gaming machine 640 is aware of whether or not it is available for play based on back-end messaging received from the transaction server 620. Each gaming machine 640 will intermittently transmit via its BLE device 642 a wireless BLE message indicating whether or not it is available for play. The range of BLE communications between a BLE device 642 and a cell phone 650 may be up to about 30 meters. Since there may be many gaming machines within 30 meters of the cell phone 650, the cell phone 650 can be configured to use BLE signal strength to select only those BLE messages having signal strengths greater than some specified threshold level, which selected BLE messages will typically correspond to the gaming machines that are closest to the cell hone 650.
For those selected BLE messages, the cell phone 650 will determine whether those BLE messages come from gaming machines 640 that are available or unavailable for play. If all of the selected BLE messages are from available gaming machines, then the cell phone 650 will indicate, e.g., by displaying corresponding information on the cell phone's screen, such as a green light, that all of the nearby gaming machines are available for play. If, however, all of the selected BLE messages are from unavailable gaming machines, then the cell phone 650 will indicate, e.g., by displaying corresponding information on the cell phone's screen such as a red light, that none of the nearby gaming machines are available for play. If the selected BLE messages indicate the presence of both available and unavailable gaming machines, then the cell phone 650 will indicate, e.g., by displaying corresponding information on the cell phone's screen such as a yellow light, that only a subset of the nearby gaming machines are available for play. As such, as the patron walks up and down the aisles adjacent to the rows of gaming machines 640, the cell phone 650 will provide some indication, such as a colored heat map, of the availability of nearby gaming machines for play.
In some implementations, the different gaming machines 640 are able to indicate whether or not they are available for play, e.g., by displaying corresponding information on the gaming machine's screen or turning on or off appropriate lights on the gaming machine.
In some implementations, the gaming system 600 logically disables and enables gaming machines for play. In other implementations, the gaming system 600 physically disables and enables gaming machines for play by controlling gaming machine's electronic hardware (e.g., the bill validator or the SAS controller).
Alternatively or in addition, as described further in the next section, a gaming app running on a cell phone could control which gaming machines are available, for example, by communicating directly with the BLE devices of neighboring gaming machines to cause them to disable their bill validators. Another possibility is to have a central cloud-based solution that determines the availability of gaming machines based on phone-to-phone-to-BLE-device communications. For example, when a patron uses his cell phone to secure play at a particular gaming machine, a centralized server (separate from the gaming system 600) transmits the ID numbers for gaming machines that are nearby the particular gaming machine to the patron's cell phone, which can then transmit BLE messages instructing those nearby gaming machines to disable their bill validators. Alternatively, the server could transmit the ID numbers to the particular gaming machine, which would then instruct those nearby gaming machines to disable their bill validators by having the BLE device of the particular gaming machine transmit BLE messages to the BLE devices of those nearby gaming machines.
In some embodiments, in addition to supporting the concept of social distancing as described in the previous section, the gaming system 600 of
In some implementations, to support social grouping, the transaction server 620 uses the gaming-machine database to keep track of the identity of each patron currently playing at a gaming machine. The transaction server 620 also maintains a social-group database to keep track of the members of each different social group. Note that social groups are typically defined by patrons using the gaming apps on their cell phones 650 and then used in real-time by the transaction server 620 to determine whether to allow two or more patrons to play at nearby gaming machines.
In some implementations, a first patron becomes authorized to play at a first gaming machine 640 using the functionality described in the previous section (with the addition of the transaction server 620 receiving the identity of the first patron (e.g., the first patron's cell phone ID) from the cell phone 650 and recording the patron's identity in the gaming-machine database). A second patron then uses his/her cell phone 650 to scan the tag 644 of a nearby, second gaming machine 640 and transmit a message to the transaction server 620 identifying both the second gaming machine and the second patron. The transaction server 620 initially accesses the gaming-machine database to determine that the second gaming machine 640 is identified as being currently unavailable for play due to its proximity to the first gaming machine. The transaction server 620 then accesses the social-group database to determine whether or not the second patron is in the same social group as the first patron. If not, then the transaction server 620 will transmit a message to the second patron's cell phone 650 indicating that the second gaming machine is not available for play. If, however, the transaction server 620 determines that the first and second patrons are in the same social group, then the transaction server 620, the cell phone 650, and other nodes in the gaming system 600 proceed to implement the steps involved in providing the second patron with gaming credit at the second gaming machine 640 as described previously. In addition, the transaction server 620 updates the gaming-machine database to indicate (i) that the second gaming machine 640 is currently being played and (ii) if appropriate, that one or more additional gaming machines that happen to be nearby the second gaming machine, but not the first gaming machine, are currently unavailable for play. As mentioned before, in some implementations, the first patron is able to identify other patrons as being in the first patron's social group, thereby enabling those other patrons to play at neighboring gaming machines.
In this way, multiple patrons who are members of the same social group and, in theory, less likely to need social distancing from one another, can enjoy playing at nearby gaming machines.
In some implementations, when a first patron of a particular social group becomes authorized play at a particular gaming machine, the gaming system 600 could transmit invitations to the other members of that social group to (i) join the first patron at that gaming machine and/or (ii) play at nearby gaming machines.
Note that, in some implementations, a patron may simultaneously be a member of two or more different social groups. Depending on the implementation, the gaming system 600 may allow such a patron to play at gaming machines nearby other members of those different social groups without necessarily allowing different members in those different social groups to play at nearby gaming machines. In other words, if a first social group includes Patrons A and B, but not Patron C, and if a second social group includes Patrons A and C, but not Patron B, then Patrons A and B can play at nearby gaming machines and Patrons A and C can play at nearby gaming machines, but Patrons B and C might not be allowed to play at nearby gaming machines.
In certain implementations, social groups may be dynamic. For example, the gaming app and/or the gaming system 600 may be able to set time limits for the memberships of individual members of social groups and/or for the entire social group, where the corresponding membership would automatically end at the expiration of a time limit, unless the time limit were manually extended. Furthermore, the gaming app may display options that enable a designated leader of a social group or any member of the social group to add new members to the social group in real time. The gaming app and/or the gaming system 600 may set a maximum limit on the number of members of a social group and/or a maximum number of members that are allowed to be present within a given area.
As described above, in some implementations, backend servers of the gaming system 600 manage the execution of social distancing and social grouping. In some implementations, in addition or instead, the execution of social distancing and social grouping is managed directly by the gaming apps running on patrons' cell phones without directly involving those backend servers. In those implementations, the gaming machines are configured to communicate directly with the gaming apps to prevent gaming at neighboring gaming machines except by members of the same social group.
In step 704, Phone A broadcasts a BLE “disable-BV” message instructing all gaming machines that receive that BLE message to disable their bill validators. The disable-BV message includes a unique identifier for Phone A. In response, in step 706, each neighboring gaming machine whose BLE device receives the disable-BV message will disable its bill validator and set a disable-BV timer for a preprogrammed period of time. While the bill validator of a gaming machine is disabled, that gaming machine cannot be played. Note that, using the cell-phone identifier in the disable-BV message, Machine A determines that it should not disable its bill validator because Machine A knows that it has been authorized to play by Phone A.
Note that, as long as Patron A continues to play at Machine A, Phone A periodically transmits the disable-BV message, and the neighboring gaming machines respond by resetting their disable-BV timers. In step 708, when Patron A cashes out from Machine A (or otherwise stops playing at Machine A), the BLE device of Machine A transmits a “stop-sending-disable-BV” message with the cell-phone identifier of Phone A in step 710, and, in response, Phone A stops transmitting the disable-BV messages.
In that case, in step 712, the disable-BV timer in each neighboring gaming machine will eventually time out, and, in step 714, each neighboring gaming machine will re-enable its bill validator to once again enable play by patrons.
In step 802, another patron (Patron B) uses her cell phone (Phone B) to scan the QR code of a disabled neighboring gaming machine (Machine B) whose bill validator was disabled due to Patron A playing at Machine A in an attempt to secure play at Machine B, for example, using the processing described previously with respect to
In step 804, since the bill validator of Machine B is disabled as a result of Machine B previously having received a disable-BV message from Phone A (in step 706 of
If, however, in step 806, the gaming app on Phone B determines that Patron A is not in Patron B's social group, then, in step 814, Phone B transmits a negative response message to the BLE device of Machine B informing Machine B that Patron A is not in Patron B's social group. As such, in step 816, Machine B keeps its bill validator invalidated to prevent Patron B from playing at Machine B.
Note that, if Machine B had previously received disable-BV messages from multiple nearby gaming machines (e.g., Machine A and Machine C, where Machines A and C are both neighbors of Machine B, but not of each other), then the query transmitted in step 804 would have to identify both Machine A and Machine C, and Phone B would have to determine that both Patrons A and C are in Patron B's social group in step 806 before Phone B will transmit a positive response in step 808.
In some implementations, in addition to or instead of Machine B querying Phone B about Patron A, Machine B transmits a BLE message to Phone A asking Patron A for permission to allow Patron B to play at Machine B. If Patron A agrees, then Phone A transmits a positive response back to Machine B, which then re-enables its bill validator to enable Patron B to play at Machine B.
Social distancing and social grouping can also be applied in a casino at gaming tables such as poker/blackjack tables, roulette tables, craps tables, and baccarat tables. For example, individual gaming tables can be designated for play only by members of a single social group. Certain types of tables, such as craps tables, may be able to be played by members of multiple social groups, for example, with members of one social group restricted to stand on one side of a craps table and members of a different social group restricted to stand on the other side of the craps table.
In some implementations, a patron may use the gaming app on his/her cell phone to reserve play at a gaming table for the patron's social group, possibly with a reservation fee being charged to the patron and/or divvied up among the patron's social group. When a first patron of a particular social group reserves play at a particular gaming table, the gaming system 600 could transmit invitations to the other members of that social group to join the first patron at that gaming table at the reservation time.
In some implementations, each gaming table (or each side of a craps table) would have a BLE device, analogous to the BLE device 642 of
Similar to what was described previously, the gaming app on the patron's cell phone could provide an indication to the patron of the availability of nearby gaming tables for play as the patron moves within the casino.
Alternative Casino System with Tokenized Transaction Packages
In addition to those analogous elements, the gaming system 900 of
As described above with respect to
Note that, in some implementations, there is one instance of the BLE device 942 and one instance of the first node 960 for each gaming machine 940, but there is one instance of the second node 970 for each bank of (e.g., eight) gaming machines 940, where the second node 970 aggregates and distributes the communications between the corresponding plurality of first nodes 960 and the ticket server 910. Note that, in other implementations in which there is one instance of the second node 970 for each gaming machine 940, the functionality of the first and second nodes 960 and 970 can be combined into a single node having communication links with the BLE device 942, the gaming machine 940, and the ticket server 910.
If and when there is a match at step 19, then, at step 21, the cell phone 650 establishes a Bluetooth connection with the BLE peripheral device 942 associated with the selected gaming machine 940 and transmits the TTP message to the BLE peripheral device 942 via the communication link 908. Note that the cell phone 950 does not decrypt the TTP message. As such, neither the cell phone 950 nor the patron has access to the voucher ID.
At step 22, the BLE peripheral device 942 decrypts the received TTP message to recover the monetary value and the voucher ID.
At step 23, the BLE peripheral device 942 transmits the voucher ID and the monetary value to the first node 960 via the communication link 962.
At step 24, the first node 960 transmits the voucher ID and the monetary value to the second node 970 via the communication link 966.
At step 25, the second node transmits the voucher ID and the monetary value to the ticket server 910 via the communication link 972.
Note that, in an alternative implementation, the first node 960, and not the BLE peripheral device 942, decrypts the received TTP message. In that case, steps 22 and 23 will instead involve the BLE peripheral device 942 transmitting the TTP message to the first node 960, which then decrypts the TTP message. In another alternative implementation, the second node 970, and not the BLE peripheral device 942 or the first node 960, decrypts the received TTP message. In that case, steps 22-24 will instead involve the BLE peripheral device 942 transmitting the TTP message to the first node 960, which then transmits the TTP message to the second node 970, which then decrypts the TTP message.
Note that, in alternative implementations, whichever element decodes the TTP message, that element recovers only the voucher ID, where the voucher ID, but not the monetary value, is then transmitted to the ticket server 910.
At step 26, the ticket server 910 accesses the voucher database 912 to retrieve the monetary value associated with the received voucher ID and transmits the retrieved monetary value to the second node 970 via the communication link 972.
At step 27, the second node 970 transmits the retrieved monetary value to the first node 960 via the communication link 966.
At step 28, the first node 960 transmits the retrieved monetary value to the gaming machine 940 via the communication link 964 as an electronic funds transfer (EFT).
At step 29, the gaming machine 940 increases its gaming credit by the received monetary value, thereby enabling the patron to play or continue to play the gaming machine 940.
Steps 30-38 of
In one retrofit implementation, a legacy gaming system is upgraded to provide the gaming system 900 of
In one implementation, the legacy gaming machine was modified by connecting the first node 960 to the SAS interface node 1114 of the game controller 1104 of the legacy gaming machine. Note that, in some implementations, neither the hardware nor the software of any of the bill validator 1102, the game controller 1104, the network interface 1106, the printer 1108, and the bill/voucher stack 1110 of the legacy gaming machine needs to be modified.
As described previously with reference to step 28, the first node 960 transmits the monetary value of the voucher to the gaming machine 940 as an EFT. In particular, the first node 960 transmits the monetary value to the game controller 1104 via the SAS interface 1112, and the game controller 1104 forwards the monetary value to the bill/voucher stack 1110 via the bill validator 1102 in a way that is identical to how a legacy bill validator 1102 would forward an EFT to a legacy, smart bill/voucher stack.
Note that the kiosk 930 and the gaming machine 940 still support all of the legacy functionality associated with paper vouchers, including paper-based cash-in and cash-out operations. Although the operations of the gaming system 900 have been described in the context of the gaming machine 940 of
Those skilled in the art will understand that the gaming system 900 and the gaming app running on the cell phone 950 of
In some embodiments, a method is for implementing social distancing at a gaming establishment having a plurality of gaming machines. The method comprises (i) enabling a first patron to play at a first gaming machine and (ii) disabling one or more neighboring gaming machines that are nearby the first gaming machine from being played while the first patron is playing at the first gaming machine.
In at least some of the above embodiments, a gaming system of the gaming establishment enables the first patron to play at the first gaming machine based on receipt of a request from the first patron using a gaming app running on a first wireless device.
In at least some of the above embodiments, a BLE device of the first gaming machine communicates with the first wireless device.
In at least some of the above embodiments, a neighboring gaming machine is disabled from being played by temporarily disabling a bill validator of the neighboring gaming machine.
In at least some of the above embodiments, a gaming system of the gaming establishment disables the one or more neighboring gaming machines from being played.
In at least some of the above embodiments, each neighboring gaming machine is disabled from being played upon receipt of a disable message from a first wireless device of the first patron.
In at least some of the above embodiments, each disabled neighboring gaming machine sets a timer such that (i) the disabled neighboring gaming machine re-sets the timer upon receipt of a subsequent disable message from the first wireless device and (ii) the disabled neighboring gaming machine re-enables itself upon expiration of the timer.
In at least some of the above embodiments, each neighboring gaming machine is disabled from being played upon receipt of a disable message from the first gaming machine.
In at least some of the above embodiments, the method further comprises, while the first patron is playing at the first gaming machine, enabling a second patron who is in a social group with the first patron to play at one of the one or more neighboring gaming machines.
In at least some of the above embodiments, when the second patron attempts to play at the neighboring gaming machine using a second wireless device, a gaming system of the gaming establishment determines whether the second patron is in the social group with the first patron.
In at least some of the above embodiments, when the second patron attempts to play at the neighboring gaming machine using a second wireless device, the neighboring gaming machine queries at least one of the first wireless device and the second wireless device to determine whether the second patron is in the social group with the first patron.
In some embodiments, a gaming machine is for a gaming establishment having a plurality of gaming machines. The gaming machine comprises (i) a game controller configured to control the gaming machine, (ii) a bill validator connected to the game controller and configured to enable a first patron to pay to play at the gaming machine, and (iii) a wireless communication component connected to at least one of the game controller and the bill validator and configured to communicate with a first wireless device of the first patron. The bill validator is configured to be temporarily disabled when a neighboring gaming machine is being played by a second patron.
In at least some of the above embodiments, the wireless communication component is a BLE device.
In at least some of the above embodiments, the gaming machine is enabled to be played by the first patron by a gaming system of the gaming establishment based on receipt of a request from the first patron using a gaming app running on the first wireless device.
In at least some of the above embodiments, the bill validator is configured to be temporarily disabled by a gaming system of the gaming establishment.
In at least some of the above embodiments, the bill validator is configured to be temporarily disabled upon receipt by the wireless communication component of a disable message from a wireless device of a patron.
In at least some of the above embodiments, the game controller is configured to set a timer upon receipt by the wireless communication component of the disable message such that (i) the game controller is configured to re-set the timer upon receipt of a subsequent disable message and (ii) the game controller is configured to re-enable the bill validator upon expiration of the timer.
In at least some of the above embodiments, the bill validator is configured to be temporarily disabled upon receipt by the wireless communication component of a disable message from the neighboring gaming machine's wireless communication component.
In at least some of the above embodiments, at least one of the game controller and the wireless communication component is configured to enable the bill validator to enable the first patron to play at the gaming machine when the second patron is playing at the neighboring gaming machine when the first patron is in a social group with the second patron.
In at least some of the above embodiments, the game controller is configured to receive an instruction to enable the bill validator from a gaming system of the gaming establishment that is configured to determine whether the first patron is in the social group with the second patron.
In at least some of the above embodiments, when the first patron attempts to play at the gaming machine using the first wireless device, the gaming machine is configured to query at least one of the first wireless device and the second wireless device to determine whether the first patron is in the social group with the second patron.
Embodiments of the invention can be manifest in the form of methods and apparatuses for practicing those methods. Embodiments of the invention can also be manifest in the form of program code embodied in tangible media, such as magnetic recording media, optical recording media, solid state memory, floppy diskettes, CD-ROMs, hard drives, or any other non-transitory machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. Embodiments of the invention can also be manifest in the form of program code, for example, stored in a non-transitory machine-readable storage medium including being loaded into and/or executed by a machine, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code segments combine with the processor to provide a unique device that operates analogously to specific logic circuits
Any suitable processor-usable/readable or computer-usable/readable storage medium may be utilized. The storage medium may be (without limitation) an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device. A more-specific, non-exhaustive list of possible storage media include a magnetic tape, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM) or Flash memory, a portable compact disc read-only memory (CD-ROM), an optical storage device, and a magnetic storage device. Note that the storage medium could even be paper or another suitable medium upon which the program is printed, since the program can be electronically captured via, for instance, optical reading of the printing, then compiled, interpreted, or otherwise processed in a suitable manner including but not limited to optical character recognition, if necessary, and then stored in a processor or computer memory. In the context of this disclosure, a suitable storage medium may be any medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Unless explicitly stated otherwise, each numerical value and range should be interpreted as being approximate as if the word “about” or “approximately” preceded the value or range.
It will be further understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated in order to explain embodiments of this invention may be made by those skilled in the art.
In this specification, the term “each” may be used to refer to one or more specified characteristics of a plurality of previously recited elements or steps. When used with the open-ended term “comprising,” the recitation of the term “each” does not exclude additional, unrecited elements or steps. Thus, it will be understood that an apparatus may have additional, unrecited elements and a method may have additional, unrecited steps, where the additional, unrecited elements or steps do not have the one or more specified characteristics.
It should be understood that the steps of the exemplary methods set forth herein are not necessarily required to be performed in the order described, and the order of the steps of such methods should be understood to be merely exemplary. Likewise, additional steps may be included in such methods, and certain steps may be omitted or combined, in methods consistent with various embodiments of the invention.
Although the elements in the following method claims, if any, are recited in a particular sequence with corresponding labeling, unless the claim recitations otherwise imply a particular sequence for implementing some or all of those elements, those elements are not necessarily intended to be limited to being implemented in that particular sequence.
Reference herein to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments necessarily mutually exclusive of other embodiments. The same applies to the term “implementation.”
The embodiments covered by the claims in this application are limited to embodiments that (1) are enabled by this specification and (2) correspond to statutory subject matter. Non-enabled embodiments and embodiments that correspond to non-statutory subject matter are explicitly disclaimed even if they fall within the scope of the claims.
This application claims the benefit of the filing date of U.S. provisional application No. 63/023,974, filed on May 13, 2020 as attorney docket no. 1231.042PROV, the teachings of which are incorporated herein by reference in their entirety. The subject matter of this disclosure is related to the subject matter of U.S. Pat. No. 8,845,416, filed as Attorney Docket No. 1231.001, U.S. Pat. No. 10,825,292 (“the '292 patent”), filed as Attorney Docket No. 1231.031, and U.S. patent application Ser. No. 17/029,899 (“the '899 application”), filed as Attorney Docket No. 1231.039, the teachings of all of which are incorporated herein by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63023974 | May 2020 | US |
