Electronic wagering
11670138 · 2023-06-06
Assignee
Inventors
- John F. Acres (Las Vegas, NV)
- Warren White (Reno, NV, US)
- Mark N. Dailey (Las Vegas, NV, US)
- William Dale Hermansen (Reno, NV)
- Anthony Morelli (Reno, NV, US)
- Alex White (Las Vegas, NV, US)
- Cyrus A. Luciano (Reno, NV, US)
- John G. Schmitz (Henderson, NV, US)
- Andrew King (Las Vegas, NV, US)
- Patrick B. Ferguson (Las Vegas, NV, US)
Cpc classification
G07F17/3234
PHYSICS
G07F17/3225
PHYSICS
G07F17/329
PHYSICS
G07F17/3227
PHYSICS
International classification
Abstract
The present system incorporates mobile computing devices to play games, such as electronic pull-tabs, in a plurality of venues, each having a local wireless network. Each network communicates with a central system that generates decks of game outcomes and associated awards. All wagers and awards for each game are tracked on the central system, which also provides each game award and associated outcome from a deck stored on the central system.
Claims
1. A gaming system comprising: a plurality of games implemented on a network of mobile computing devices; at least one computer processor operatively connected to the network, the at least one computer processor configured to: account for money deposits made by players of the games; generate an optical machine-readable code for each player, the code including data corresponding to the amount of each player's deposit; associate a different one of the mobile computing devices with each of a plurality of players; provide each player with his or her respective code; receive an image of one of the generated codes via the camera on one of the mobile computing devices; apply a wagering credit to the game on the one mobile computing device related to the generated code; permit play of the wagering game on the one mobile computing device responsive to wagers made using the applied credit; transmit on the network data related to a current activity level of each mobile computing device to a computer system; track the current activity level of each of the mobile computing devices at the computer system by determining how long each mobile computing device is idle for longer than a predefined time; vary the predefined time as a function of how many mobile computing devices are associated with players; and send a message over the network to one of the mobile computing devices when the current activity level falls below a predefined level.
2. The gaming system of claim 1 wherein the at least one computer processor further causes the at least one computer processor to: continue to track the current activity level of the one mobile computing device; and generate an indication that the current activity level fails to meet at least one predefined criterion.
3. The gaming system of claim 2 wherein the indication that the current activity level fails to meet at least one predefined criterion comprises an indication to dispatch a person to the one mobile computing device.
4. The gaming system of claim 1 wherein the predefined time is longer when fewer mobile computing devices are associated with players and shorter when more mobile computing devices are associated with players.
5. The gaming system of claim 1 wherein the message indicates to the player that he or she should play a game on the mobile computing device.
6. The gaming system of claim 1 further comprising: an operator terminal connected to the network and wherein the at least one computer processor, further cause the at least one computer processor is further configured to: display at the operator terminal an entry for each mobile computing device; and display at the operator terminal indicia associated with at least one of the mobile computing devices indicating time between games played on the at least one mobile computing device.
7. The gaming system of claim 6 wherein the indicia comprises one of a plurality of colors for the entry.
8. The gaming system of claim 1 wherein the at least one computer processor is further configured to deduct wagers that resulted in a loss from the applied credit to produce a credit balance.
9. The gaming system of claim 8 wherein the at least one computer processor is further configured to apply prizes that result from a win to the applied credit thereby augmenting the credit balance.
10. The gaming system of claim 9 wherein the at least one computer processor is further configured to track the credit balance at a location remote from the mobile computing device.
11. The gaming system of claim 10 wherein the at least one computer processor is further configured to account for a withdrawal of the credit balance.
12. The gaming system of claim 11 wherein the at least one computer processor is further configured to account for a withdrawal of the credit balance, at least in part, by receiving an image of the generated code at a cashier's terminal.
13. The gaming system of claim 12 wherein a sheet of material having the image of the generated code thereon is provided to the player and wherein receiving an image of the generated code via the camera at one of the mobile computing devices comprises reading the code from the sheet when the player presents the sheet to the camera.
14. A gaming system comprising: a first mobile computing device having a wagering game thereon and being constructed and arranged to read an optical machine-readable code; a computer network on which the mobile computing devices are implemented; at least one computer processor operatively connected to the network, the at least one computer processor configured to: account for a money deposit associated with a first mobile computing device; generate an optical machine-readable code that includes data related to the amount of the deposit; associate such a first mobile computing device with a person and the generated code to the person; receive an image of the generated code via the camera; apply a credit to the wagering game related to the generated code; permit a player to play the wagering game on the first mobile computing device responsive to wagers made using the applied credit; display at least two images on the touch-sensitive screen as part of play of the wagering game; and reveal game outcomes in one of two ways, namely: (i) change one of the images to display one of a winning outcome or a losing outcome of the game responsive to the player touching the screen adjacent the one image; or (ii) change the at least two images to display one of a winning game outcome or a losing game outcome responsive to a player swiping along an axis adjacent both images; generate data related to a current activity level of the first mobile computing device; transmit the generated data to a computer system; receive additional data at the computer system related to the current activity level of each of a plurality of additional mobile computing devices; determine how long each mobile computing device is idle for longer than a predefined time; vary the predefined time as a function of the number of mobile computing devices; and send a message over the network to the first mobile computing device when the first mobile computing device is idle for longer than the predefined time.
15. The gaming system of claim 14 wherein the at least one computer processor is further configured to deduct wagers that resulted in a loss from the applied credit to produce a credit balance.
16. The gaming system of claim 15 wherein the at least one computer processor is further configured to apply prizes that resulted from a win to the applied credit thereby augmenting the credit balance.
17. The gaming system of claim 16 wherein the at least one computer processor is further configured to track the credit balance at a location remote from the mobile computing device.
18. The gaming system of claim 17 wherein the at least one computer processor is further configured to account for a withdrawal of the credit balance.
19. The gaming system of claim 18 wherein the at least one computer processor is further configured to account for a withdrawal of the credit balance, at least in part, by receiving an image of the generated code.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
DETAILED DESCRIPTION
(20) Turning now to
(21) In the present embodiment of the invention, device 24 comprises an iPod™, which is made by Apple Inc. Any suitable computing device may be so used. In
(22)
(23) A first row 36 of pay table 34 indicates that the combination of four symbols of a woman's head appear four times in the deck, and each time the combination appears, the player wins $500. (This top-paying symbol corresponds to the portrait 33 featured at the top of the display.) Similarly, in the next row down, the combination of four rings appear four times with each win receiving a $200 award. In the last row, the combination of four hearts appears 500 times, with each occurrence resulting in an award of $1.
(24) At the bottom of display 32, there is a touch-sensitive menu button 38. A denomination panel 40, also at the bottom of the display, is not touch sensitive. Rather, it indicates the denomination of the game, i.e., how much is wagered for each play of the game. In this case, each play costs $1. In the present embodiment, this indication does not change during game play, but other embodiments could permit selecting different denominations. An adjacent credit meter 42 indicates the number of remaining credits that the player has on the game. In the present embodiment, this equates to the number of dollars because it is a $1 wager. But this meter could indicate the remaining dollars, which would be different from the number of credits for other wager denominations. These credits are initially applied to the game as a result of the player depositing an initial amount to begin game play. Any wins during play are applied to the credit meter. And the total amount on the meter is returned to the player at the conclusion of game play—more about how credits are applied and redeemed shortly.
(25) Finishing the description of display 32 on screen 31, a downwardly directed arrow 44 appears on the right side of the display. As can be seen, the words SWIPE TO PLAY appear on arrow 44.
(26)
(27) In
(28) Another noteworthy feature is that finger 28 can rapidly swipe downwardly on arrow 44 thus moving from the display of
(29) The player may alternatively slowly move his or her finger down the arrow while maintaining contact with the screen. In this mode of play, the player may stop and hold his or her finger as shown, e.g., in
(30) This slow motion reveal can be repeated for each of the rows, i.e., stopping finger movement on the screen or lifting the finger from the screen after each row is revealed holds the display as shown in
(31) Once, however, the finger is lifted from the screen after all rows are displayed, one of two things happen depending on whether any of the revealed rows comprise a winning combination of symbols, i.e., four-of-a-kind. In the view of
(32) If, however, there is no winning combination in the three rows, once all three are revealed and finger 28 lifts from the screen, the display depicted in
(33) In an alternative embodiment, whether or not any of the revealed rows comprise a winning combination of symbols, either or both of the game responses described above may occur at the end of the swipe, even before the finger is lifted from the screen.
(34) Still another noteworthy feature is sound effects. One such effect accompanies the appearance of each row. In the present embodiment, an audio effect generated by device 24 comprises a drip sound, each drip sound varying slightly in pitch and tone quality from the preceding one. Downward swiping slowly reveals the portion of the display where the symbols appear. The sound occurs simultaneously with the appearance of the symbols. This provides the user with some satisfying audio feedback to indicate the appearance of the current row.
(35) Another sound effect occurs substantially simultaneously with the appearance of border 52 and balloon 54, namely a brief audio fanfare. This combination of display and sound effects highlight the winning game play and gives the player a brief opportunity to celebrate.
(36) In still another game feature, the player may review the results of the previous game with an upward finger swipe in the direction of arrow 56 from the bottom of screen 31 as shown in
(37) Finally, the player may select a different game theme with a lateral swipe of the finger, in the direction of an arrow 58 as shown in
(38) Here each of the games has the same pay table with the result of the move to the new game of
(39) Depicted in
(40) Turning now to
(41) Device 62 includes a screen 64 upon which a game-display home screen 65 is shown, namely the Mystic Sevens game. Device 64 also includes a built-in camera having a lens 66 and a home button 68 for controlling various aspects of the device. Additional controls, not visible, control volume, screen rotation, power, etc.
(42) The displays in
(43) As can be seen in
(44) When a user wishes to play one of these games, the home screen display for that game is positioned front and center as shown for each game in
(45) Big Money Heist is a multiple pull-tab game that incorporates pull-tabs 82, 84, 86. In
(46) The lower portion of display 80 includes both touch-sensitive buttons and display panels. Starting at the left, a menu button 90 when pressed exits the Big Money Heist game and returns the screen to Cover Flow® mode as shown in each of
(47) A game info button 92 when pressed presents information (not shown in the drawings) about the current game, in this case Big Money Heist. Such information may includes game rules, total number of outcomes in the current deck of outcomes (about which, more later), total outcomes remaining, and any other information about the game it might be desirable to communicate to the player.
(48) A denomination button 94 serves both to indicate the amount of each wager and, in some games, to permit the player to change the amount wagered. In games with a changeable wager, each time button 94 is touched, it cycles through the possible denominations, e.g., $1, $5, $10, in sequence. This changes the amount that appears on button 94, and the amount that is wagered on each game. In other embodiments, the wager amount is fixed, and button 94 functions only as a display panel, i.e., it is not touch sensitive. In such embodiments, it serves merely to inform that player of the amount of the wager for all games played.
(49) Credit meter 96 indicates to the player the amount of credit available for game play. This includes an initial amount applied to the game when the player first begins play using device 62. The way in which initial credits are applied is described in more detail after this initial description of game play. Credit meter 96 also includes credits that result from game awards. As a result, the credit meter decrements in the amount of the wager each time a game is played. And it increases by the amount of an award when a winning outcome is produced.
(50) A win meter 98 indicates the total win for each game played. In other words, it indicates the amount that is applied to credit meter 96.
(51) Finally, a touch-sensitive button 100 is used to play a game. At the outset, after Big Money Heist is loaded and before any games are played, the message on button 100 reads: “Buy Tab.” Regardless of how tabs 82, 84, 86 appear when the game is first loaded, pressing button 100 decrements credit meter 96 by the amount of the denomination button 94. It also results in each of tabs 82, 84, 86, appearing as tab 86 in
(52) Tabs 82, 84, 86 may be opened in at least two ways as a result of the touch sensitivity of screen 64. First, as instructed by the message on each tab, the player can touch the screen over the image of each tab, one at a time. Each time a tab is so touched, an image of the outcome associated with that tab appears. This image will be a combination of symbols that appear in pay table 88, although it is possible for additional symbols not shown in the pay table to appear. Those symbols, however, will always be part of a losing outcome for the tab in question.
(53) Second, the tabs may be opened much more rapidly with a single vertical swipe of the player's finger. The finger may be placed on the screen on the top tab 82 or the bottom tab 86 and swiped vertically down or up, respectively, across both of the other two tabs. As the finger crosses the tab the outcome is revealed, thus providing for rapid game play.
(54) In this variation, the swipe can start either above or below the top or bottom tab, respectively and swipe across that tab, through the middle tab, and onto the remaining tab. The swipe need not entirely cross the tab to open it; it need only come onto the screen above the image of the tab for the tab to open.
(55) In addition, swiping can start on middle tab 84 and go either up or down across the other tab thereby opening only two tabs with a single swipe.
(56) Once the results associated with each tab are displayed, i.e., tab 86 also includes four symbols, like tabs 82, 84 in
(57) Once all the tabs are revealed, and any credits resulting from a win are added to credit meter 96 as described above, the display on screen 64 can be a rotating view of symbols in each of the symbol position, which functions as an attract screen. Or it can simply display the outcome of the preceding game. Either way, button 100 now displays the “Buy Tab” message, and when pressed, a new game is initiated and played as described above.
(58) When the player wishes to play a different game, e.g., Mystic Sevens, he or she pushes menu button 90, and the screen returns to the Cover Flow® mode as shown in each of
(59) Mystic Sevens is a single pull-tab game that includes a pull-tab 102, the outcome of which is obscured (i.e., the pull-tab is closed) in
(60) It also includes a bonus feature 106, which is triggered from time to time during game play. Game play is initiated by pushing button 100 when it displays the “Buy Tab” message (not shown).
(61) Doing so, as in Big Money Heist, decrements credit meter 96 by $1, the amount of the wager displayed on button 94. In addition, the screen image at pull-tab 102 is as shown in
(62)
(63) Alternatively, the bonus can be provided as a multiplier of the wagered amount. Whichever way the bonus is presented, after the win presentation, the “Buy Tab” message again appears on button 100, and the game is ready for further play as described above.
(64) As a further alternative, the bonus feature may start automatically after conclusion of the game in which the bonus symbol appears as one of the revealed symbols.
(65)
(66) Turning now to
(67) Then the player can touch each tab or swipe to open as described above in connection with playing Big Money Heist. In the screen image of
(68) After further continued play, not shown, the bonus feature is triggered when one or more tiki-head symbols 114 appear on each of pull-tabs 108, 110, 112 (also not shown). Immediately thereafter, a bonus-screen image 116 appears as shown in
(69) As soon as screen image 120 appears the words “Choose a Treasure Chest” are superimposed over the image thus prompting the player to touch one of the treasure chests, like treasure chest 122, in
(70) The dollar amount also appears in a bonus meter 124 in the upper left corner of
(71) In some bonus rounds, there might be the opportunity to choose only one treasure chest, after which the game reverts to regular play as described in connection with
(72) Turning now to
(73) The Slideways game includes a grid of differently cut and colored jewels on a game-board image 126. Image 126 is touch sensitive and produces an impression of movement of one jewel in the grid to an adjacent spot in the grid in one of four directions: up, down, left, or right. Such movement is accomplished when a player touches the selected jewel and drags it to its new location. When so moved, the jewel stays at its new location, and the jewel previously there automatically moves to the location of the moved jewel. In short, the jewels trade places.
(74) The object here is to align three or more identical jewels in a single straight row. For example, opals 128, 130, 132 are not aligned as shown in
(75) Screen image 78 includes a game-score meter 136, which increments each time jewels are aligned as described above. In addition, a horizontal bar graph 138 increments proportional to the score displayed in the game-score meter. As game play continues, each time an alignment of three or more jewels is made, score meter 136 increments, as does bar graph 138, and the player is presented with a three-symbol pull-tab, which he or she touches to open thereby revealing the symbols as shown in
(76) A touch-sensitive hint button 140 may be used to receive a hint of where a jewel may be moved to create an alignment of three or more jewels. In response to depressing button 140, red brackets (not shown) appear around a jewel that could be so moved.
(77) After the symbols are revealed, the credit meter reflects an award, if any, and the aligned jewels disappear. The jewels immediately above the empty positions drop to fill those spaces, and new jewels appear to fill the resulting empty spaces in the top line of jewels, when the player-created alignment was horizontal, or in the top several lines, when the player-created alignment was horizontal.
(78) In addition, when the newly appearing jewels create additional alignments of three or more jewels, score meter increments accordingly, although in the present embodiment, additional opportunities to reveal the pull-tab are not presented until the player makes a further alignment by touching and dragging a jewel, as described above.
(79) The Slideways game may incorporate the features of U.S. application Ser. No. 12/718,792 filed on Mar. 5, 2010, for Entertainment Game-Based Gaming Device which is hereby incorporated herein by reference for all purposes.
(80) Before turning attention to the details of operating pull-tab games according to the present invention, consideration will first be given to the structure containing the system used to control, operate, and account for the games. This structure is implemented primarily in two locations, the first at a venue where the games are played and the second at a central location that provides data needed to play the games; that accounts for credits applied to the games, wagers made, and awards granted; and that maintains logs for virtually all transactions on the games. Of course, this structure could be implemented at a single location.
(81) In
(82) In the present embodiment, the terminals are substantially identical to device 62 described above. A person affiliated with venue 142 or with a charity that benefits from the gaming conducted there operates a cashier terminal 150. Of course, any person, regardless of affiliation, could operate the cashier terminal. A ticket printer 152, which communicates in a known manner with cashier terminal 150, may be used in some embodiments to purchase credits and redeem credits and awards as will be shortly described. A computer 154 can access data generated by the system to review status and/or to print reports based on data collected by the system. Finally, terminals 146-150 and computer 154 each communicate via the Wi-Fi standard with a wireless router 156, which in turn communicates with the Internet via a secure connection in the present case SSL.
(83) Another computer 159 also communicates with the Internet to obtain reports and logs. Computer 159 may be used by regulators, a charity that benefits from the gaming at venue 142, by a manager or operator of the system, or different computers so connected may be used by all or any of them.
(84) A central system, indicated generally at 160 in
(85) The firewall server is connected to each of a plurality of real-time servers 166, 168, 170, 172. As can be seen by the dots between servers 170, 172, there may be any number of such servers, which reflects the load on central system 160. Put differently the more venues, like venue 142, are associated with system 160, the more real-time servers are required. It is possible, but not necessary, for each venue to be associated with a different one of the real-time servers, i.e., there is one-to-one correspondence of each venue with an associated real-time server. In addition to collecting data from each venue, there is a real-time server dedicated to each of the following tasks: receiving initial traffic (in some embodiments) from all of the venues and routing it to the real-time server associated with the venue from which the data in TCP/IP data packets was received (referred to as Usher thus suggesting the function served); manufacturing of decks from which game outcomes are selected in response to a wager placed at a venue with which the deck is associated, consolidation of data from selected venues, as stored on different ones of the real-time servers, and web interface; processing client download requests; a logger for logging all transactions; and utility operation.
(86) As a result of the possibilities associated with distributed computing using virtual servers, these tasks may be divided in many ways among virtual or real servers and may be provided from different locations.
(87) Each real-time server is associated with a SQL database 174, 176, 178, 180. Finally, each of the real-time servers communicates with a central server 182 that collects accounting data and other information that can be used to generate reports. All of the servers can be implemented in a virtual environment using commercially available software. This provides a scalable and extensible platform that is backed up on a separate physical machine that can accommodate the software components in the event of a hardware failure. Central system 160 also includes a storage area network (not shown) in which data can be stored and from which it is accessed.
(88) Before describing a typical gaming session and the functions performed by a game operator at a gaming venue such as a bar or restaurant, consideration will first be given to how a venue, such as venue 142, is initially configured and installed and the manner in which information flows between the venue and central system 160.
(89) After a venue agrees to install the components shown in
(90) Before transporting the equipment to the venue, the distributor associates a serial number with each terminal, like terminals 144, 146, 148, 150 in
(91) In addition to the iPads, additional hardware, such as printer 152, when required, and router 156 are pulled from the distributor's inventory. The router is set with an SSID, which identifies the local area network at the venue. In addition password protection is also set up, and the iPads are configured to communicate with router 156.
(92) Next the software that implements the games described above is installed, and the terminals are locked down. This limits the ability of the iPad to run programs other than the games described above.
(93) The hardware so configured is delivered to the venue and installed. First, router 156 is connected to the Internet via and Internet Service Provider, which is typically contracted for by the hosting venue. The ISP assigns an IP address, which may be a CIDR (Classless Inter-Domain Routing) block address. After the address is assigned, the installer determines the address by, e.g., using web service such as www.whatismyip.com. After the address is determined, it is entered into central system 160. Security can be increased by placing a phone call to a work place maintained by the distributor, verbally communicating the IP address, and having that person manually enter the address into system 160 thereby associating it with the venue, which has already been identified in system 160, and with the other information that was entered by the distributor, which is described above.
(94) In addition, system 160 associates one of real-time servers 166-172 with the site. This designates the server upon which data received from the site is first stored as it arrives at system 160. This is accomplished by assigning a different virtual port number for each site, which will be soon described. Finally, the venue is enabled and ready for play.
(95) Before describing the procedure for initiating game play and the interaction of the hardware, further consideration needs to be given to the data packets that are generated at venue 142, the manner in which they are communicated to system 160, and how they are processed there. Venue 142 and system 160 are implemented with client-server architecture. The clients at venue 142 connect to central system 160 over Internet 158 using HTTPS over TCP/IP. None of the terminals can communicate with central system 160 unless their MAC addresses have been entered as described above. The Wi-Fi service enabled by router 156 uses WPA encryption.
(96) The central system provides various web services that may be accessed in remote sites as well as a suite of functions that supply or support supply of games to players as described above. Data generated as a result is stored at central system 160 and may include financial data, player credit balances, game play history, and electronic pull-tab decks from which game outcomes are selected and delivered to a player terminal at venue 142 in response to game play there.
(97) Here is an example to illustrate how data flows as described above. Assume the CIDR block address assigned to the venue is 8.2.4.2/31, and the IP address for firewall 164 is 66.172.18.11. In addition to each of these addresses, each real-time server 166-172 has an associated private-network address. Here assume real-time server 166 has the private-network address 10.1.8.2, real-time server 168 has 10.1.8.3, with each successive server continuing with additional private-network addresses.
(98) It will be recalled that when venue 142 was configured, it was associated with a port number different from the virtual port number for any other venue. Every data packet coming from venue 142 includes that virtual port number, as part of the data carried by the packet but not as a socket address on firewall 166. Firewall 166 listens for packets from all of the venues on a single dedicated port, e.g., port 8080. As a result, the real socket to which all data from all of the venues is addressed is 66.172.18.11: 8080. What might be thought of as a virtual socket comprises the real IP address, 66.172.18.11, combined with the virtual port address, e.g., 66.172.18.11: 10,000.
(99) When a data packet comes from venue 142 to system 160, firewall 160 checks its memory to determine whether the source address for the data packet is in the table that is created by adding each venue CIDR block address as the venue is configured and enabled for play. If the source address for the packet is not in this table, the packet is rejected. If it is in the table, the usual TCP handshake is performed to establish a connection.
(100) Once the connection is established, the data packet is passed to the Usher real-time server, which controls packet distribution to the real-time server that is associated with the venue from which the packet originated. The Usher server receives all packets passed by the firewall. It maintains a table that associates the virtual port number in each data packet with the real-time server associated with the venue from which the data packet originated.
(101) Considering the sequence described above, the data packet bearing socket destination address 66.172.18.11: 8080 is received at the firewall. Its origination address is the CIDR block number assigned to the venue, e.g., 8.2.4.2/31. The data packet also includes a port from which the packet originated, which is not relevant for our purposes. Once the packet is confirmed to be from a venue that is registered with system 160 it immediately routes to the Usher real-time server, which includes a table that associates each packet with a real-time server that is in turn associated with the venue from which the packet originated.
(102) For example, two consecutive incoming data packets each have a real socket address of 66.172.18.11: 808. But the virtual socket addresses are 66.172.18.11: 10,000 and 66.172.18.11: 10,001. The port number 10,000 is associated with a first venue, e.g., Joe's Bar & Grill, from which that data packet originated; and the port number 10,001 is associated with a second venue, e.g., Katy's Fine Dining, from which that data packet originated.
(103) Each of the virtual sockets is mapped to real socket on a different one of the real-time servers. Here, for example, are mappings on each of the two consecutive addresses: 66.172.18.11: 10,000.fwdarw.10.1.8.2: 8080 66.172.18.11: 10,001.fwdarw.10.1.8.3: 8080
(104) As a result, data from each venue is routed to an associated real-time server. As an alternative to associating a virtual port number to a venue when the venue is configured, as described above, the system 160 can assign a virtual port number to the first packet received at firewall 164 from the site. The virtual port number can then be returned to the venue via the Internet, and all future communications from the venue can include the virtual port number. It should be noted that different types of services beyond providing pull-tab games could be provided to each or some of the venues. If so, other servers besides the pull-tab server, or in addition thereto, could be made available to the incoming data packets via appropriate entries in the Usher tables.
(105) Some of the data collected from the venues and routed to the respective real-time servers is moved from there to central server 182. This permits the central server to be used to generate reports without slowing the real-time servers, which must be available to transact wagering and game play at each server's associated venue. All of the data is routed from each real-time server to the central server in a guaranteed delivery queue. This queue backs up if central server 182 is busy, and therefore slow to receive new data, or slow for a technical reason, or down, i.e., not receiving any data. When the central server is down, the queue for delivery of data from one of the real-time servers to the central server can back up and be quite long. It can take many minutes to clear the queue if the central server has been down.
(106) Some data, e.g., all financial and wagering transactions, must be delivered and stored at the central server. As a result, this data goes only in the guaranteed-delivery queue. There is a second queue from each real-time server to the central server known as the priority delivery queue. Certain types of data that are not critical, e.g., are sent in a priority queue. Critical data, such as financial and wagering transactions must be delivered ultimately even if the central server is down. If down, the guaranteed delivery queue backs up and can take as much as three hours, or even longer to deliver once the central server is again operational. But this data is critical and must be preserved and stored regardless of the time when it arrives.
(107) Data in the priority queue, however, is desirable to deliver quickly but would not prove disastrous if lost. One example of such data is related to employees who operate the cashier terminal. Because some venues operate multiple locations, e.g., a chain of restaurants, and have employees move from one location to another, records for each employee are stored on central server, including records relating to logging in and out as an operator of cashier terminal 150, which must occur before he or she can process transactions there. Each log-in command is sent via router 156, the Internet, and firewall 164 as described above to one of the real-time servers 166-172 associated with the venue at which the employee is attempting to log-in, and from there to central server 160, which stores employee records and responds to log-in commands.
(108) If data in the guaranteed delivery queue is backed up, and the log-in commands were in that queue, the employee could not log-in as a result of the backed up queue that delays delivery to central server 160, which tracks and controls logging in and out. But log-in commands are in the priority queue. As a result, when the guaranteed delivery queue is backed up, e.g., after the central server has been down for a while, the priority queue delivers the log-in command much more quickly, thus allowing the employee to log-in.
(109) On the other hand, if the central server is down, when the log-in attempt is made, the log-in command is lost as is any other data in the priority queue. That queue does not store and back up waiting commands; it just rapidly delivers whatever is in the queue, and if the server on the receiving end is down, that data is lost. But if the command were in the guaranteed-delivery queue, the log-in command could not happen either, so no harm is done, and logging in occurs quickly once the central server is up again, and a log-in command is sent.
(110) But loss of financial data is unacceptable, and it must go in the guaranteed delivery queue. In some embodiments, certain types of data can go in both queues. In addition, some embodiments enable communications in both directions for both the priority and guaranteed queues.
(111) Following are exemplary reports that can be compiled from data contained on the system and especially in the database associated with central server 160.
(112) Minnesota Electronic Pull Tab System
(113) TABLE-US-00001 Report 1 Active Deck Report Sep. 9, 2012 12:34 AM Active Decks Site Game Deck Games Game ID ID ID Remaining Name Wager 20012 1 1001 6 Slideways 3 $1.00 20012 1 1002 450 Slideways 3 $1.00 20013 2 1003 564 Slideways 4 $1.00 20012 2 1004 123 Slideways 4 $1.00 20012 2 1005 1234 Slideways 4 $1.00 20012 3 1006 6543 Slideways 5 $1.00 20012 3 1007 7412 Slideways 5 $1.00 20012 4 1008 4563 Slideways 3 $0.25 20012 4 1009 5412 Slideways 3 $0.25 20013 4 1010 256 Slideways 3 $0.25 20012 5 1011 7456 Slideways 4 $0.25 20012 5 1012 1756 Slideways 4 $0.25 20012 6 1013 368 Slideways 5 $0.25 20012 6 1014 356 Slideways 5 $0.25 21024 1 1101 6 Slideways 3 $1.00 21024 1 1102 450 Slideways 3 $1.00 21024 2 1103 564 Slideways 4 $1.00 21024 2 1104 123 Slideways 4 $1.00 21024 2 1105 1234 Slideways 4 $1.00 21024 3 1106 6543 Slideways 5 $1.00 21024 3 1107 7412 Slideways 5 $1.00 21024 4 1108 4563 Slideways 3 $0.25 21024 4 1109 5412 Slideways 3 $0.25 21024 4 1111 256 Slideways 3 $0.25 21024 5 1111 7456 Slideways 4 $0.25 21024 5 1112 1756 Slideways 4 $0.25
(114) Minnesota Electronic Pull Tab System
(115) TABLE-US-00002 Report 2 Closed Deck Report Sept. 4, 2012 thru Sept. 4, 2012 Site ID Name Game ID Name Deck ID Wager 141 Roseville Bingo Hall 3 Slideways 3 $1.00 121 $1.00 141 Roseville Bingo Hall 3 Slideways 3 $1.00 122 $1.00 142 Memphis 3 Slideways 3 $1.00 123 $1.00 142 Memphis 3 Slideways 3 $1.00 124 $1.00 141 Roseville Bingo Hall 4 Slideways 3 $0.50 126 $0.50 141 Roseville Bingo Hall 4 Slideways 3 $0.50 127 $0.50 142 Memphis 4 Slideways 3 $0.50 128 $0.50 142 Memphis 4 Slideways 3 $0.50 129 $0.50 141 Roseville Bingo Hall 30 Slideways 3 $2.00 131 $2.00 141 Roseville Bingo Hall 30 Slideways 3 $2.00 132 $2.00 142 Memphis 30 Slideways 3 $2.00 133 $2.00 142 Memphis 30 Slideways 3 $3.00 134 $2.00 141 Roseville Bingo Hall 12 Treasures of the Jungle $1.00 136 $1.00 141 Roseville Bingo Hall 12 Treasures of the Jungle $1.00 137 $1.00 142 Memphis 12 Treasures of the Jungle $1.00 138 $1.00 142 Memphis 12 Treasures of the Jungle $1.00 139 $1.00 141 Roseville Bingo Hall 34 Treasures of the Jungle $2.00 141 $2.00 141 Roseville Bingo Hall 34 Treasures of the Jungle $2.00 142 $2.00 142 Memphis 34 Treasures of the Jungle $2.00 143 $2.00 142 Memphis 34 Treasures of the Jungle $2.00 144 $2.00 141 Roseville Bingo Hall 15 Old Glory $1.00 146 $1.00 141 Roseville Bingo Hall 15 Old Glory $1.00 147 $1.00 142 Memphis 15 Old Glory $1.00 148 $1.00 Site ID Sold Unsold Payout Open Close 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 141 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012 142 0 7500 0.00% Aug. 30, 2012 Sept. 4, 2012
(116) Minnesota Electronic Pull Tab System
(117) TABLE-US-00003 Report 3 Charity List With Sites Sep. 9, 2012 12:34 AM Address City/State/Zip Phone License Number Website Charity Manager Email Phone Charity Name Site ID Site Name Address City/State/Zip Phone American Legion 123ABC 1234 Legion Drive Somewhere, MN 98765-4321 (987) 555-1212 www.americanlegion.org Charles Smith csmith@americanlegion.org (234) 567-8900 21010 Joe's Bar 123 Second Street Somewhere, MN 98765 (897) 321-9876 21013 Clay's Club 223 Second Street Somewhere, MN 98765 (897) 321-9855 21014 Vacation Bar 128 Second Street Somewhere, MN 98765 (897) 321-4566 21017 Mary's Lounge 143 Second Street Somewhere, MN 98765 (897) 321-3456 Minnesota School 456XYZ 5678 Minnesota Street Elsewhere, MN 98745-4321 (456) 555-1212 for the Deaf www.mndeafandblindschool.org Andrea Longeens andreal@gmail.com (654) 598-1123 21011 Frank's Bar and Grill 376 Third Street Elsewhere, MN 98745 (827) 221-9226 21023 Piano Lounge 223 Third Street Elsewhere, MN 98745 (827) 322-9225 21034 Golf Bar 6548 Country Club Drive Elsewhere, MN 98745 (896) 326-6666 Veterans of 7890LMNOP 9876 Veterans Road Someplace, MN 98654-4321 (447) 544-1442 Foreign Wars www.vfw.org Captain John Johnson cjj@vfw.org (254) 565-8955 21035 Blarney Club 113 Broadway Someplace, MN 98654 (867) 363-9676 21038 Viking's Den 223 Underbelly Drive Someplace, MN 98654 (797) 371-7755 21047 The Brass Bar 7762 Second Street Someplace, MN 98654 (887) 821-4588
(118) Minnesota Electronic Pull Tab System
(119) TABLE-US-00004 Report 4 Deck Inventory Report Sep. 9, 2012 12:34 AM Deck Inventory Game Name Wager Game ID Inventory Slideways 3 $1.00 1 30 Slideways 4 $1.00 2 30 Slideways 5 $1.00 3 30 Slideways 3 $0.25 4 30 Slideways 4 $0.25 5 30 Slideways 5 $0.25 6 30
(120) Minnesota Electronic Pull Tab System
(121) TABLE-US-00005 Report 5 View Game Details Sep. 9, 2012 12:34 AM Game Name: Slideways 3 Wager: $1.00 Game ID: 1 Manifest File: games/slide3.txt Status: Approval Pending Games Per Deck: 7500 Total Cost Of Games: $7500.00 Total Prize Value: $6375.00 Prize %: 85.00% Prize Frequency: 4.43% Prize Table Number Prize 1 $599.00 5 $500.00 20 $100.00 40 $20.00 15 $5.00 150 $2.00 101 $1.00
(122) Minnesota Electronic Pull Tab System
(123) TABLE-US-00006 Report 6 Game Performance Report Period: Jan. 1, 2013-Jan. 31, 2013 Average Net Game Name Wager Game ID Win Per Day Sales # Sales $ Prizes # Prizes $ Prize % Active Games Slideways 3 $1.00 1 $765.43 543 $543.00 23 $460.00 84.71% Slideways 4 $1.00 2 $654.32 1678 $1678.00 265 $1460.00 87.00% Slideways 5 $1.00 3 $543.21 2103 $2103.00 245 $1765.00 83.93% Slideways 3 $0.25 4 $432.10 1543 $385.75 29 $320.25 83.02% Slideways 4 $0.25 5 $321.98 2285 $571.25 123 $485.50 84.99% Slideways 5 $0.25 6 $219.87 11026 $2756.50 1012 $2333.25 84.65% Disabled Games Tic-tac-toe $0.25 7 $12.34 6543 $1635.75 578 $1382.00 84.49% Chess $0.25 8 $10.98 10567 $2641.75 1011 $2235.75 84.63%
(124) Minnesota Electronic Pull Tab System
(125) TABLE-US-00007 Report 7 Pull Tab Games Sep. 9, 2012 12:34 AM Games Game Game Name Wager ID Manifest File Status Action Slideways 3 $1.00 1 games/slide3.txt Active Slideways 4 $1.00 2 games/slide4.txt Active Slideways 5 $1.00 3 games/slide5.txt Active Slideways 3 $0.25 4 games/slide3.txt Active Slideways 4 $0.25 5 games/slide4.txt Active Slideways 5 $0.25 6 games/slide5.txt Active Tic-tac-toe $0.25 7 games/ttt.txt Disabled Chess $0.25 8 games/chess.txt Disabled Tic-tac-toe $1.00 9 games/ttt.txt Approval Pending Chess $1.00 10 games/chess.txt Approval Pending
(126) TABLE-US-00008 Report 8 Minnesota Electronic Pull Tab Financial Report Period: Sept. 4, 2012-Aug. 4, 2012 Charity Name License Site ID Site Name License PTs Tickets Prizes Net Pay % Sells $/ Jarrod's Charity C00023 144 Jarrod's Place s00023 1 286.50 193.20 93.30 87.43% 1.100.00/ Charity Total 1 286.50 193.20 93.30 87.43% 1.100.00/ Lions Club #10 1200-23 142 Memphis 012- 0 0.00 0.00 0.00 0.00% 0.00/ 143 O'Malley's Irish 012- 0 0.00 0.00 0.00 0.00% 0.00/ Charity Total 0 0.00 0.00 0.00 0.00% 0.00/ MN Cancer 012-548-RC 141 Roseville Bingo 012-465- 0 0.00 0.00 0.00 0.00% 0.00/ Charity Total 0 0.00 0.00 0.00 0.00% 0.00/ Muscular Dystrophy 002 137 Elks Lodge 102 4 94.00 128.00 −34.00 136.17% 100.00/ 139 VFW Hall #121 1975- 0 0.00 0.00 0.00 0.00% 0.00/ Charity Total 4 94.00 128.00 −34.00 136.17% 100.00/ Rotary Club #2 of 2100-105 140 White Stag Bar & 012-546- 0 0.00 0.00 0.00 0.00% 0.00/ Charity Total 0 0.00 0.00 0.00 0.00% 0.00/ Sanitary Fund 10900 136 Duffy's Tavern 162990 2 0.00 0.00 0.00 0.00% 0.00/ Charity Total 2 0.00 0.00 0.00 0.00% 0.00/ Travis Travis 135 Travis's Site 42424242 0 0.00 0.00 0.00 0.00% 0.00/ Charity Total 0 0.00 0.00 0.00 0.00% 0.00/ Total 7 380.50 321.20 59.30 84.42% 1,200.00/3 Total Number of Charities 7 Total Number of Sites 9 Charity Name License Site ID Site Name License # Redms $/ # Exp $/ # Jarrod's Charity C00023 144 Jarrod's Place s00023 2 919.10/ 1 87.60/ 1 Charity Total 2 919.10/ 1 87.60/ 1 Lions Club #10 1200-23 142 Memphis 012- 0 0.00/ 0 0.00/ 0 143 O'Malley's Irish 012- 0 0.00/ 0 0.00/ 0 Charity Total 0 0.00/ 0 0.00/ 0 MN Cancer 012-548-RC 141 Roseville Bingo 012-465- 0 0.00/ 0 0.00/ 0 Charity Total 0 0.00/ 0 0.00/ 0 Muscular Dystrophy 002 137 Elks Lodge 102 1 0.00/ 0 134.00/ 1 139 VFW Hall #121 1975- 0 0.00/ 0 0.00/ 0 Charity Total 1 0.00/ 0 134.00/ 1 Rotary Club #2 of 2100-105 140 White Stag Bar & 012-546- 0 0.00/ 0 0.00/ 0 Charity Total 0 0.00/ 0 0.00/ 0 Sanitary Fund 10900 136 Duffy's Tavern 162990 0 0.00/ 0 0.00/ 0 Charity Total 0 0.00/ 0 0.00/ 0 Travis Travis 135 Travis's Site 42424242 0 0.00/ 0 0.00/ 0 Charity Total 0 0.00/ 0 0.00/ 0 Total 919.10/1 221.60/2 Total Number of Charities 7 Total Number of Sites 9
(127) Minnesota Electronic Pull Tab System
(128) TABLE-US-00009 Report 9 Site Configuration Sheet Sep. 9, 2012 12:34 AM Site details for Acres 4.0 Bar and Grill Site Information Name: Acres 4.0 Bar and Grill Address: 1234 Tenaya Way City/State/Zip: Las Vegas, NV 12345-6789 Phone: (702)555-1212 Email: manager@a4barandgrill.com Website: www.a4barandgrill.com Site ID: 20001 License Number: 654POI Site Cashier Username: Acres 4.0 Bar and Grill Cashier 1 Site Cashier Password: 9876 Site status: Disabled Site Install Date: Sep. 1, 2012 Equipment Details WiFi Router SSID: Acres20001 WiFi Router Username: Acres 4.0 WiFi Router Password: AcresRocks GLA MAC Address: 11:22:33:44:55:66 Number of Point of Sale Terminals: 1 Point Of Sale Terminal Serial Number: CVX45LJ32Z Number of Player Terminals: 6 Player Terminal Serial Number: CVX45LJ33Z Player Terminal Serial Number: CVX45LJ34Z Player Terminal Serial Number: CVX45LJ35Z Player Terminal Serial Number: CVX45LJ36Z Player Terminal Serial Number: CVX45LJ37Z Player Terminal Serial Number: CVX45LJ38Z
(129) Consideration will now be given to the manner in which game outcomes are generated and selected. The basic game play unit in a pull-tab game is referred to as a deck of pull-tab outcomes, i.e., symbol combinations and associated prize amounts, if any. In a deck every card, i.e., outcome and any associated prize amount, has the same purchase price. There are a predefined number of winning cards as well as a predefined cumulative prize amount in the deck. A plurality of decks may be generated using a single set of deck criteria, which may be referred to as a game ID. In some jurisdictions the criteria for generating a deck may be known as a Form Number or Game Set. Regardless of nomenclature, the game ID typically includes the following: Number of tickets in the deck Name of the game Description Version Manufacturer Price of a card/ticket Table of prize amounts, each with a total number of occurrences in the deck
(130) Each deck generated with a game ID has the same predefined number of winning cards and the same cumulative prize total. The game ID may be generated using known mathematical techniques for designing wagering games. Different game IDs can be used to create decks that provide different prize-amount volatility and different wager amounts.
(131) To create a deck, a copy of the prize table from a game ID is made. The prize table includes the number of occurrences for each different game prize amount, including outcomes that are a loss. Put differently, the prize table is a list of all possible prize amounts—including a loss where $0 is awarded—in the deck to be generated and the number of times each prize amount occurs in the deck. In the present embodiment, each deck includes 7,500 possible outcomes.
(132) Next, a different one of the prizes is randomly selected from the prize table and placed in the deck under construction. Each prize, including the losses, is placed in sequential order until all of the prizes are gone from the copy of the prize table. In other words, these selections are made without replacement. This leaves a deck with 7,500 records, each of which includes a prize amount.
(133) A rendering table associated with the game ID includes a plurality of different game outcomes, which are often in the form of symbol combinations for a revealed tab, but may also include bonus outcomes, such as those associated with Treasures of the Jungle. The outcomes are grouped according to the prize amount associated with each. In other words, each outcome within a group has one and only one prize amount. After the game ID is used to initiate the deck build as described above, each of the 7,500 entries (each defining a prize amount) is considered in sequence. For each entry, a random selection of a game outcome is chosen from the group of outcomes that have the current prize amount in the deck. After being so chosen, the outcome is associated with the entry under consideration. After moving through the entire deck, the cards each include a prize amount and an outcome that corresponds to the prize amount.
(134) During game play, each time a player wagers, a card is chosen in sequence and the outcome and associated prize are displayed to the player.
(135) As an example, suppose a game ID has the following prize-amount distribution:
(136) TABLE-US-00010 TABLE 1 Weight (Number of Prize Level Occurrences) Prize Amount 0 5 $0 1 2 $1 2 1 $5 Total 8
(137) In the above table, the prize level is a number for linking prize amounts in a deck to a game outcome, as will be shortly seen. First, create a working distribution based upon the game ID:
(138) TABLE-US-00011 TABLE 2 Prize Level Weight 0 5 1 2 2 1 Total 8
(139) The algorithm for randomly populating a deck with prize values begins with choosing a random number, N, from 0 to X−1, where X is the sum of the weights in the working distribution. Next, loop through all the weights, and consider whether N is less than the current weight. If so, the prize associated with this weight is chosen. If not, then advance the current weight from N to the next weight. Keep repeating, until N is less than the current weight. When that happens, chose the prize at that weight, save it in the current position, and deduct 1 from the weight in the working distribution. This process is repeated for each prize until the working distribution is empty.
(140) For example, considering the above table, begin with choosing a random number between 0 and total weight (8) minus 1 (7). A Java based RNG using the well-known KISS algorithm is used for random selection. Suppose 3 is randomly chosen. Start by looping through the prize levels, first inspecting prize level 0. The current weight for prize level 0 is 5. The random number chosen was 3. 3 is less than 5, so prize level 0 is the prize being drawn. Deduct 1 weight from Prize level 0, which results in the following working distribution:
(141) TABLE-US-00012 TABLE 3 Prize Level Weight 0 4 1 2 2 1 Total 7
(142) The deck at this point has one prize and it looks like:
(143) TABLE-US-00013 TABLE 4 Prize Index Prize Level 0 0
(144) To draw the next prize, choose a random number between 0 and the current weight (7) minus 1 (6). Suppose 6 is chosen. Again loop through the prize levels, first inspecting prize level 0. The current weight for prize level 0 is 4. The random number chosen was 4. 6 is not less than 4, so prize level 0 is not the prize being drawn. Subtract from the random number the weight of the current prize level (4), which yields a difference of 2. Iterate to the next prize level. 2 is not less than 2, so prize level 1 is not the prize being drawn. Subtract from the random number the weight of the current prize (2), which yields a difference of 0. Iterate to the next prize level. 0 is less than 1, so prize level 2 is the prize being drawn. Deduct 1 weight from Prize level 2, which results in the following working distribution:
(145) TABLE-US-00014 TABLE 5 Prize Level Weight 0 4 1 2 2 0 Total 6
(146) The deck at this point has one prize and it looks like:
(147) TABLE-US-00015 TABLE 6 Prize Index Prize Level 0 0 1 2
(148) This process is repeated until the total weights reaches 0, which means that all the individual weights have amounts of 0.
(149) Continuing the process, a final deck may have an arrangement as:
(150) TABLE-US-00016 TABLE 7 Prize Index Prize Level 0 0 1 2 2 0 3 0 4 1 5 1 6 0 7 0
(151) Joining the game ID prize amounts, which correspond to the Prize Index, with the resulting Deck would yield the following:
(152) TABLE-US-00017 TABLE 8 Prize Index Prize Level Prize Amount 0 0 $0 1 2 $5 2 0 $0 3 0 $0 4 1 $1 5 1 $1 6 0 $0 7 0 $0
(153) Now a game outcome must be rendered for each prize index. Suppose that that the rendering table for prize level 0 is as follows:
(154) TABLE-US-00018 TABLE 9 Render # Weight Rendering 0 2 bar-bar-seven 1 2 bar-seven-bar 2 2 seven-bar-bar 3 1 bar-seven-seven 4 1 seven-bar-seven 5 1 seven-seven-bar Total 9
(155) The rendering table is typically a subset of all the possible renderings for a prize level, which correlates to a prize amount. It is a subset because there can be many, sometimes billions, total possible outcomes, e.g., for a multiple tab game with a bonus. The above rendering table in Table 9 can be used to associate a game outcome, symbol combinations and/or bonus result, with each award in the partially completed deck shown in Table 8.
(156) This is accomplished using the same algorithm that populated the deck with prize values. Choose a random number from 0 to total weight (9) minus 1 (8). Suppose 4 is chosen. Iterate though all the renderings. Render 0 has a weight of 2. 4 is not less than 2, so deduct the weight of render 0 (2) from the random number (4) to yield 2. Iterate to the next render (1). Inspect the weight of Render 1, which is 2. 2 is not less than 2, so deduct the weight of render 1 (2) from the random number (2) to yield 0. Iterate to the next render (2), which has a weight of 2. 0 is less than 2, so render 2 is the rendering to apply to the current prize level 0 in the deck. So, this prize will use the rendering of “seven-bar-bar”. This same process is completed for each prize index until the deck is complete. The processes for generating the prize values and associated rendered outcomes can be done in any order, e.g., one first entirely and then the second, or each can be completed one after the other when generating each record in the deck.
(157) In the present embodiment of the system, decks are generated and stored in an inventory of decks in the system memory. This memory is automatically monitored and when decks run low, new decks are automatically generated according to the algorithm above, mostly after 2 AM and before 8 AM when gaming is either light or non-existent due to regulations that limit gaming hours.
(158) Finishing now the description of one more aspect of the present implementation, a session ticket 186 in
(159) Each ticket has the information printed as shown on ticket 186, including a QR code 188. After purchasing the session ticket, a player uses it with a player terminal, like device 62 from
(160) When the player, not shown in
(161) In addition to applying credits to a game, a QR code can be used to scan a player's card for player tracking purposes. This is necessary here, because these devices do not have card readers, and it may be desirable not to add them.
(162) The system stores all wagers and awards, and debits or credits the account created by the deposit for ticket 186 accordingly. At the conclusion of play, the player returns with ticket 186 to the game manager who scans it, in a manner similar to that described in connection with
(163) Alternatively, instead of issuing a ticket, the game manager receives money from a player and opens an account with an initial cash deposit made by the player. This account is opened on cashier terminal 150, which communicates with the system to apply a credit in the amount of the deposit to a player's account, which is on the central system. The account is identified by the manager with a play terminal, which the manager then gives to the player with the associated credit. The amount of this credit is reflected by the central system to the credit meter on the device. The player then commences wagering and playing as described above. When the player concludes gaming, he or she returns their player's terminal to the game manager who reviews the amount stored in the account by the system, using the cashier terminal. This amount is given to the player when the player terminal is returned to the game manager.
(164) Consideration will now be given to some of the screen displays that appear on cashier terminal 150 in the course of selling sessions, during active sessions, and cashing out a player.
(165) As can be seen in
(166) Player terminals can be powered up at any time. They may be connected to power or run on batteries. When they are powered up, each terminal may request an update download. If an update is available, an ACCEPT button (not shown) is presented to the operator. After pressing the download button, an update is downloaded from the central system to the player terminal.
(167) In
(168) When the player desires to use a player terminal, the player needs to buy a session from the manager, i.e., the operator of cashier terminal 150. When buying a session or adding cash to an ongoing session, either the player or the operator must press the HELP button in
(169) When a player desires to cash out, he or she selects that function button in one of the displays of
(170) The system can monitor the condition of each player terminal because it is receiving wagers and providing cards from the deck in play. Each player terminal generates a token that is included with each data packet sent to the system. This permits the system to track wagers, awards, and game play. If the player terminal remains idle for longer than a predefined time, a message appears indicating to the player that he or she should play or return the terminal and cash out. The predefined time can vary depending on how many terminals are out. If 3 of 6 are out, a longer time can be used. But if all terminals are out, a shorter time is more effective to keep game play going on the terminals.
(171) Also, this could escalate. In other words, if the initial message doesn't either get the player to start playing or return the terminal and cash out, the operator or a staff person who is notified by the operator or by the color codes on cashier terminal 150 could track the player down and inquire about problems, desire for further gaming, etc.
(172) Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention can be modified in arrangement and detail without departing from such principles. I claim all modifications and variation coming within the spirit and scope of the following claims.