Patent Grant
10586428
1. Field of the Invention
The present invention relates generally to implementing wagering games via an electronic network and more particularly to implementing such games via computing devices used by a player.
2. Description of the Related Art
Some types of wagering games are known as reveal games because the outcome of the game is known when the wager is placed. As a result, the point of the game is to disclose the outcome to the player in a manner that creates interest. One such type of game uses a pull-tab ticket, sometimes referred to a break-open card. Some states authorize gaming to be conducted by and for the benefit of charitable organizations, and sales of pull-tab tickets are a popular type of charitable gaming.
A pull-tab ticket is typically a multi-layered paper ticket containing symbols hidden behind perforated tabs on the top layer on one side of the ticket. The other side of the ticket lists winning combinations of symbols, the number of tickets that contain each winning combination, and the cash payout for each combination. Sometimes the total number of tickets in the game is also disclosed.
Tickets may be sold for any amount, but typical costs vary from S0.25 to $5.00. Prizes may also be any amount but usually range up to S1,000. After a player purchases a pull-tab ticket, he or she pulls the perforated tab to reveal the symbols. If there is a combination of symbols that matches one of the listed winning combinations, the player may redeem the ticket with the seller to collect the prize.
A game manager is responsible for selling pull-tab tickets. The manager must account for money received and paid to a variety of people and entities. These include revenues for tickets sold and prizes redeemed when a winning ticket is presented, and often also includes money paid to taxing authorities, to the venue hosting the game, and to the manager. These games are usually operated in small venues such as restaurants and bars according to state charitable-gaming regulations.
One of the costs of operating a pull-tab game is purchasing boxes of tickets. Each box includes a predefined number of winning combinations, an award amount associated with each winning combination, a total number of tickets, and a sales price for each ticket. As a practical matter, the total number of tickets for each box is limited due to the difficulty of managing and accounting for a large number of tickets.
Turning now to
A pay table printed on the backside of ticket 10 is shown in
In operation, a game manager sells ticket 10 to a player for a predetermined amount. When received by the player, each of the tabs remains unopened, i.e., the portion of layer 12 that is perforated or cut to define each tab border remains intact. As a result, each of the tabs is in the position shown for tab 22 in
So doing reveals three symbols that are printed on layer 14 beneath each of the unopened tabs. When these symbols match one of the winning combinations shown in
It would be desirable to implement pull-tab and other types of gaming using an electronic network of computing devices via which games are played.
Turning now to
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
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 5500. (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.
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.
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.
In
Another noteworthy feature is that finger 28 can rapidly swipe downwardly on arrow 44 thus moving from the display of
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
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
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
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
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.
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.
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.
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
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
Here each of the games has the same pay table with the result of the move to the new game of
Depicted in
Turning now to
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.
The displays in
As can be seen in
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
Big Money Heist is a multiple pull-tab game that incorporates pull-tabs 82, 84, 86. In
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
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.
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.
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.
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.
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
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.
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.
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.
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.
Once the results associated with each tab are displayed, i.e., tab 86 also includes four symbols, like tabs 82, 84 in
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.
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
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
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).
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
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.
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.
Turning now to
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
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
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
The dollar amount also appears in a bonus meter 124 in the upper left corner of
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
Turning now to
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.
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
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
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.
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.
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.
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.
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.
In
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.
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.
A central system, indicated generally at 160 in
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:
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.
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.
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.
After a venue agrees to install the components shown in
Before transporting the equipment to the venue, the distributor associates a serial number with each terminal, like terminals 144, 146, 148, 150 in
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
Following are exemplary reports that can be compiled from data contained on the system and especially in the database associated with central server 160.
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:
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.
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.
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.
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.
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.
As an example, suppose a game ID has the following prize-amount distribution:
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:
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.
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:
The deck at this point has one prize and it looks like:
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:
The deck at this point has one prize and it looks like:
This process is repeated until the total weights reaches 0, which means that all the individual weights have amounts of 0.
Continuing the process, a final deck may have an arrangement as:
Joining the game ID prize amounts, which correspond to the Prize Index, with the resulting Deck would yield the following:
Now a game outcome must be rendered for each prize index. Suppose that that the rendering table for prize level 0 is as follows:
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.
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.
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.
Finishing now the description of one more aspect of the present implementation, a session ticket 186 in
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
When the player, not shown in
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.
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
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.
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.
As can be seen in
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.
In
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
When a player desires to cash out, he or she selects that function button in one of the displays of
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.
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.
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.
This is a divisional of and claims priority to U.S. patent application Ser. No. 13/621,528, filed Sep. 17, 2012, which is incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7470183 | Wishart | Dec 2008 | B2 |
| 7611407 | Itkis et al. | Nov 2009 | B1 |
| 8157635 | Hardy et al. | Apr 2012 | B2 |
| 20020098883 | Packes, Jr. et al. | Jul 2002 | A1 |
| 20030078094 | Gatto | Apr 2003 | A1 |
| 20070243928 | Iddings | Oct 2007 | A1 |
| 20090131146 | Arezina | May 2009 | A1 |
| 20090170594 | Delaney et al. | Jul 2009 | A1 |
| 20110086693 | Guziel | Apr 2011 | A1 |
| 20110165932 | Rommerdahl | Jul 2011 | A1 |
| 20120315978 | LeMay et al. | Dec 2012 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20170236366 A1 | Aug 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13621528 | Sep 2012 | US |
| Child | 15586676 | US |
