Preprinted game tickets, such as instant game lottery tickets or pull-tab tickets are known in the art. To create preprinted game tickets, a “deal” of game results is created using a computer program and the tickets are subsequently printed to match the deal, or a portion thereof. There are a fixed amount of predetermined wins in each deal. The type and amount of wins in the deal or deal portion are used to create the content of the tickets.
Instant game lottery tickets may be dispensed by clerks who manually retrieve the tickets from a stack, roll or pool of tickets. As is also known in the art, vending machines are sometimes used to dispense instant game lottery tickets directly to patrons. One example of a vending machine that dispenses preprinted game tickets, such as pull-tab tickets or lottery tickets, generated from a deal, is disclosed in U.S. Pat. No. 8,002,622 (Breslo), which is incorporated by reference herein. The deal typically includes one or more jackpot tickets. These jackpot tickets are not associated with a progressive jackpot since their jackpot value is predetermined when the deal of tickets is printed, and the jackpot value is preprinted on the ticket(s).
Draw game tickets, such as draw game lottery tickets are also known in the art. In a typical draw game lottery, tickets are sold by clerks (over-the-counter) via dispensing machines which are all connected to a central computer. The clerk then physically hands the tickets to the customers. The tickets may be purchased at a plurality of different physical locations. A set of numbers are selected at the time of purchase and are physically printed on the draw game ticket at the time of purchase via a printer in the dispensing machine. In some draw games, the customer may select the numbers or the customer may request that the clerk allow the central computer to randomly select the numbers. In other draw games, the central computer always selects the numbers. A “drawing” is then held to pick the set of winning numbers. The drawing is selected at periodic intervals, such as once per day, or once per event (e.g., Powerball® drawing).
In one prior art gaming system, a plurality of pull tab machines (Lucky Tab II machines, available from Diamond Game Enterprises, Inc., Chatsworth, Calif.) situated at a single physical location were joined together to form a progressive jackpot. A progressive jackpot display was publicly visible at the location so that players in the location could view the current status of the progressive jackpot. The deal of tickets included one or more jackpot tickets, the value of which was determined by the progressive jackpot, which would reset to a predetermined seed amount after each jackpot ticket was dispensed from a machine.
It would be desirable to provide a progressive jackpot gaming experience for use with preprinted instant game tickets, such as instant lottery tickets or pull-tab tickets, in the retail environment on a distributed basis (i.e., in a plurality of retail locations separated geographically). The present invention fulfills such a need by solving the technological hurdles inherent in the integration of preprinted game tickets with predetermined outcomes and a progressive jackpot that spans multiple locations.
There is a potential for clerk misconduct regarding misappropriation of winning jackpot tickets. If the clerk has just completed a ticket transaction for a player, but has not yet physically handed the purchased ticket to the player, and then becomes aware that the progressive jackpot was just reset, the clerk may set the ticket aside for him or herself or for a friend, and then give the player the next ticket in the batch. In this manner, the player is cheated out of a legitimately purchased winning jackpot ticket, without even having any idea that it has happened. Similar misconduct may occur if the clerk discovers that the ticket is a non-jackpot winning ticket for a fixed value before physically handing the purchased ticket to the player. It would be further desirable to provide measures to reduce the potential for clerk misconduct. The present invention fulfills such a need by enhancing the functionality of a conventional player-operated ticket checker.
A ticket checker is provided for activating a player's previously purchased ticket that is preprinted with game content and which is associated with a deal of tickets that includes at least some winning tickets. A previously purchased winning ticket cannot be redeemed until it is activated. Machine readable indicia is scanned on the previously purchased ticket at a ticket checker that is in communication with a ticket results database. A ticket activation database electronically records that the winning ticket was scanned at the ticket checker, thereby activating the winning ticket. Redemption of the winning ticket includes electronically verifying in the ticket activation database that the winning ticket was scanned at the ticket checker.
Preferred embodiments of the present invention will now be described by way of example with reference to the accompanying drawings:
Certain terminology is used herein for convenience only and is not to be taken as a limitation on the present invention.
The words “a” and “an”, as used in the claims and in the corresponding portions of the specification, mean “at least one.”
I. Clerk-Assisted Multiple Location (Multi-Location) Progressive Instant Ticket (MLPIT) Embodiment (Jackpot Resetting Upon Dispensing of Progressive Jackpot Winning Ticket)
A MLPIT deal is generated with “X” number of tickets and “Y” number of progressive winners. The progressive jackpot is seeded at the seed amount. “X” tickets and “Y” progressive winners are printed and then delivered to vendors, after which a clerk loads the batch of tickets into a MLPIT dispenser. The system validates the batch and determines whether or not the batch of tickets is good. (see steps 1-8)
If the batch of tickets is not validated as good, the clerk must go back to the previous step to load a new batch of tickets into the MLPIT dispenser. If the batch of tickets is validated as good, then the customer may purchase “Z” number of tickets by communicating the desired number of tickets to be purchased to the clerk and the clerk then enters “Z” number of tickets purchased into the system. The MLPIT dispenser then scans the barcode of the next ticket in order using the internal scanner and dispenses the ticket. The MLPIT dispenser notifies the system of the ticket number and the system increments the progressive pool by “x” amount and displays update results. (see steps 9-13)
If the ticket is a progressive jackpot winner, the system records the progressive win, resets the progressive pool to the seed amount, and resets all progressive displays. (see steps 14-17). There are a plurality of options for resetting the progressive displays.
Option 1: The progressive displays at each of the multiple locations are all simultaneously reset immediately after the progressive win is recorded.
Option 2: The progressive displays at each of the multiple locations are all simultaneously reset a short time after the progressive win is recorded.
Option 3: The progressive displays at each of the multiple locations, other than the location where the winning ticket was sold, are all simultaneously reset immediately after the progressive win is recorded, and the progressive display at the location where the winning ticket was sold is reset a short time after the progressive win is recorded. The short time period may range from multiple seconds to minutes after the progressive win is recorded. One advantage of the third option is that it inhibits clerk misconduct regarding misappropriation of winning jackpot tickets. If the clerk has just completed a ticket transaction for a player, but has not yet physically handed the purchased ticket to the player, and then becomes aware that the progressive jackpot was just reset, the clerk may set the ticket aside for him or herself or for a friend, and then give the player another ticket. In this manner, the player can be cheated out of a legitimately purchased winning jackpot ticket, without being aware that it has happened. To thwart this process, the short time period needs to be at least the time period necessary to complete a typical ticket purchase, plus a buffer for safety (e.g., multiple seconds to minutes). If there are very large number of clerk-assisted ticket purchasing locations and a sufficiently high volume of steady ticket sales throughout the day, the odds that a particular clerk would be able to cheat the system in this manner is reduced because a plurality of purchased tickets may be in the process of being physically handed the purchased ticket to the player when a jackpot is reset. However, the overall integrity of the system may still be enhanced by this third option for resetting the progressive displays.
The above-described second and third options of the progressive display resetting process are illustrated in the flowcharts of
If the ticket is not a progressive jackpot winner and the customer continues to make purchases, the aforementioned cycle of MLPIT dispenser barcode scanning and ticket dispensing continues. When all of the purchased tickets have been dispensed, regardless of whether the last ticket was or was not a progressive jackpot winner, the clerk will give “Z” tickets to the customer and the customer will reveal the result (e.g., opening a pull-tab or removing the cover layer on a scratch-off ticket). If the ticket is not a progressive win, then play has ended, at least with respect to the progressive jackpot steps. (see steps 18-21) Since there are other non-jackpot-type winning tickets in a deal, the player may still potentially reveal a winning ticket of a preprinted fixed amount. If the ticket is a winner, but not a jackpot winner, the player may return it to the clerk for redemption.
If the ticket is a progressive winner, then the customer will give the winning ticket to the clerk to claim the progressive jackpot. The clerk then scans the barcode using an external scanner and the system will determine whether the ticket is a progressive jackpot winner. If the system determines that the ticket is not a progressive jackpot winner, play has ended, at least with respect to the progressive jackpot steps. If the system determines that the ticket is a progressive jackpot winner, the system will mark the progressive win as “claimed”. The system will then alert the clerk to the progressive jackpot amount that existed when the ticket was purchased (not the current jackpot amount) and print a receipt with the jackpot amount, date, and time of purchase. The progressive jackpot is then paid to the customer. (see steps 22-29) (The terms “claim” and “redeem” are used herein interchangeably.)
The game tickets may be any type of preprinted ticket, such as the tickets shown in FIG. 1 of U.S. Pat. No. 8,002,622, coded tickets (i.e., tickets with an optical machine-readable representation of data relating to the ticket or a sequence of exposed alphanumeric characters which represents data relating to the ticket), scratch-off tickets, peel-open tickets, break-open tickets or tickets with physical pull-tabs.
Because this is a multiple location progressive embodiment, additional sets of elements within the dashed lines are located at one or more other physical locations L1, L2, Ln, as schematically depicted in
As discussed above, the clerk operates the MLPIT dispenser 24. To facilitate ticket scanning, when a customer gives a presumed winning ticket to the clerk to claim the progressive jackpot, the clerk scans the barcode of the ticket using external scanner 79 and the system will determine whether the ticket is a progressive jackpot winner. There is an external scanner 79 in proximity to each MLPIT dispenser 24. The external scanner 79 is preferably connected to the logic board 76 of the MLPIT dispenser 24 as shown in
If the ticket is a winner, but is not a jackpot winner, the customer and clerk follow a similar process, except that the progressive jackpot is not reset.
II. Alternative Version of Multi-Location Clerk-Assisted Embodiment (Jackpot Resetting Upon Customer Redemption of Progressive Jackpot Winning Ticket)
In an alternative version of the embodiment described above, steps 14-17 of
In this alternative version, the customer will not necessarily receive the same jackpot as in the first-described embodiment because the jackpot can increase between the time that the jackpot-winning ticket was dispensed and redeemed as more patrons may purchase tickets. In some instances, this time lag may benefit the customer if no other jackpot winner has redeemed a ticket in this time window because the jackpot will continue to grow during this period. In other instances, the time lag between the purchase of a progressive jackpot winning ticket and redemption of that progressive jackpot winning ticket may hurt the customer if another progressive jackpot winner has redeemed a progressive jackpot winning ticket in this time window, thereby reducing the progressive jackpot available for redemption by the first ticket buyer. The other progressive jackpot winner may have even received his or her progressive jackpot winning ticket at a later point in time, but was quicker in redeeming it.
In this alternative version, a predetermined time period (e.g., 90 days) is preferably designated for redemption of a progressive jackpot winning ticket, so that a customer cannot intentionally and repeatedly delay redeeming such a ticket until the progressive jackpot is more favorable. If the predetermined time period is exceeded, then the progressive jackpot winning ticket becomes null and void. This alternative version would require full disclosure to the customers so that they are aware of the risks, rewards, and severe penalties for delaying redemption of a progressive jackpot winning ticket.
To summarize, there are two different potential jackpot amount resetting embodiments, one wherein resetting of the progressive jackpot amount occurs immediately upon dispensing of a progressive jackpot winning ticket and another wherein resetting of the progressive jackpot amount occurs upon customer redemption of a progressive jackpot winning ticket.
III. Alternative Version of Multi-Location Clerk-Assisted Embodiment (Jackpot is Incremented by Winning Tickets and Jackpot is Reset Upon Customer Redemption of Progressive Jackpot Winning Ticket)
This alternative version differs from versions I and II described above in that the progressive jackpot is incremented when a winning (non-jackpot) ticket is claimed, not necessarily when a ticket (winner or loser) is dispensed. Upon claiming a winning ticket, the progressive jackpot is incremented by a portion of the value of the winning ticket. Since not all tickets are winners, the portion of the value allocated to the progressive jackpot for winning tickets is preferably set to a sufficiently high value so that the progressive jackpot grows in a similar manner as if a portion of every ticket (winner or loser) was allocated for the progressive jackpot.
In this alternative version, the progressive jackpot is claimed and reset in the same manner as described in version II, with the same considerations for the holder of a winning jackpot ticket.
In this alternative version, unclaimed winning (non-jackpot) tickets will reduce the amount of funds that would have been contributed to the progressive jackpot.
In this alternative version, the progressive jackpot is reset to a starting value (e.g., base value) or to a starting value, plus a percentage or fixed amount of the value of the jackpot that was just awarded. The percentage or fixed amount may be the same percentage or fixed amount that is used for incrementing the progressive jackpot when a winning (non-jackpot) ticket is claimed.
In this alternative version, the progressive jackpot is preferably incremented only by a portion of the value of a winning ticket. However, in a modified version of this alternative embodiment, the progressive jackpot is incremented by a portion of the value of a winning ticket, as well as by a portion of the value of a dispensed ticket (whether it is a winner or a loser), as is well-known in the art.
One physical implementation of this alternative version is the same as
IV. Hardware/Software for Embodiments I-III
V. Ticket Activation Via Self-Service Ticket Checker
As discussed above, instant game lottery tickets may be dispensed by clerks who manually retrieve the tickets from a stack, roll or pool of tickets. As also discussed above, there is a potential for clerk misconduct regarding misappropriation of winning jackpot tickets. If the clerk has just completed a ticket transaction for a player, but has not yet physically handed the purchased ticket to the player, and then becomes aware that the progressive jackpot was just reset, the clerk may set the ticket aside for him or herself or for a friend, and then give the player the next ticket in the batch. In this manner, the player is cheated out of a legitimately purchased winning jackpot ticket, without even having any idea that it has happened. Similar misconduct may occur if the clerk discovers that the ticket is a non-jackpot winning ticket for a fixed value before physically handing the purchased ticket to the player. As discussed above, to inhibit clerk misconduct regarding progressive jackpot tickets, the progressive display at the location where the winning ticket was sold may be reset a short time after the progressive win is recorded. However, additional measures may be desirable to further reduce the potential for clerk misconduct.
The kiosk 100 may optionally include a camera 106 for capturing images of the players who scan the tickets, wherein images of players who scan a winning ticket, and especially, a high value winning progressive jackpot ticket, are stored and used for fraud prevention auditing, if necessary.
A sample description for a lottery game that incorporates the player kiosk is as follows, although this embodiment is not limited to any particular type of instant lottery ticket:
1. Player buys a pre-printed, two-ply $10 pull-tab ticket from the clerk
i. Ticket has ten $1 plays
ii. Game symbols (indicia) for all ten plays are printed inside the ticket
2. Player scans the barcode on the ticket at the ticket checker
i. Video display shows an image of the ticket
ii. Player touches the screen to reveal, one at a time, the ten plays on the ticket
iii. Game results are shown in an entertaining way, with animations and sound
iv. Prizes accumulate and the number of plays left are displayed
3. Progressive jackpot is displayed on the monitor
i. Jackpot increments as each play is revealed
ii. Celebration animation occurs when a jackpot is hit
iii. Jackpot resets when it is hit, and increments up again upon each play (that is, the jackpot resets during the ticket checking process, not upon purchase of the ticket)
4. Player takes winning ticket to the clerk for payment (with knowledge that the ticket is a winner)
i. Clerk scans the ticket
ii. The win amount matches the accumulated win amount revealed on the checker
While the above-described ticket has ten plays, the ticket may have any number of plays, including a single play.
5. Security and accountability
i. Secure ticket validation & fraud prevention
ii. Tickets activated only upon scanning by the player
iii. Tickets cannot be cashed without first being activated at the kiosk
iv. Central accounting system tracks all tickets activated and cashed, and the progressive jackpot.
In certain states, the ticket checker is not a gaming device or a slot machine as defined by state statute because no cash or other consideration is inserted into the ticket checker and the ticket checker does not apply the element of chance or deliver a prize. Presently, many state lotteries provide ticket checker machines which allow a player to check whether a lottery ticket is a winning ticket. These types of ticket checker machines typically read a bar code on the ticket and provide a display that indicates whether the ticket is a winner. However, other than looking up the result of the scanned ticket, no action is taken as a result of the scanning (e.g., verifying that the ticket was validly purchased, activating the ticket so it can be redeemed, or resetting a jackpot) and the player may redeem winning tickets without ever using a ticket checker.
1. Scan ticket (step 200).
2. Access deal database to determine if the ticket was previously purchased (step 201). If not, an error message is displayed and no further action is taken (step 202).
3. If the ticket was previously purchased, access the deal database to determine if the ticket is a winning ticket, which can be either a non-jackpot winning ticket or a progressive jackpot ticket (step 203). If not, display no winner result (step 204). If so, display winner results and increment progressive jackpot display if non-jackpot winning ticket or reset progressive jackpot if progressive jackpot winning ticket (step 205) and activate the ticket in the ticket activation database (step 206). The winner results include the amount of the non-jackpot winning ticket or the amount of the progressive jackpot winning ticket. Any other ticket checkers in the same system are also immediately updated to display the reset progressive jackpot amount.
Referring to
This activation embodiment may use the same hardware/software as shown in
Ticket activation may differ depending upon the preferences of the gaming operator and the type of game ticket. In one embodiment, referred to herein as “ticket-by-ticket activation,” the mere act of scanning the ticket at the kiosk 100 automatically activates all game plays on the ticket, regardless of whether the player requests to see the results of each of the games on the ticket on the kiosk display screen 102. For example, if the 5th game play of a 10 game play ticket is a progressive jackpot winner, the 5th game play is activated immediately after scanning the ticket.
In an alternative embodiment, referred to herein as “game-by-game activation,” the player must actually play through each game of a multi-game ticket (e.g., a lottery ticket that has ten plays per ticket) in order to perform the activation step, and thus be permitted to subsequently redeem the winning games (if any) on the ticket. To facilitate this process, the kiosk display screen 102 may prompt the player to press a button to see the next game results after showing the game results of the first game, and so on. If the ticket is a single play ticket (i.e., one game play per ticket), the player scans the ticket at the kiosk 100 and the ticket results may automatically appear on the kiosk display screen 102 in which case the ticket becomes activated, or the player is prompted to press a button to cause the ticket results to appear. If the player does not press the button to view the ticket results, the ticket remains in an unactivated state. The kiosk 100 may also be programmed to automatically display the results of a ticket having multiple games in an automated sequence without the necessity for the player to press any buttons or even physically remain in front of the kiosk 100. The scanning of ticket may initiate this process. Again, any winning tickets become activated only after the ticket results are displayed.
Another alternative embodiment is a hybrid of the “ticket-by-ticket activation” and “game-by-game activation.” In this embodiment, the player is only required to play a subset of the multiple game on a multi-game ticket to cause activation of the entire ticket, including any unplayed games. The kiosk 100 or some other source of information informs the player of the minimum number of games that must be played on a multi-game ticket (e.g., one game of a ten game ticket, three games of a ten game ticket) for complete ticket activation.
The deal database in
Regarding a multi-game ticket that include a progressive jackpot winner, in a game-by-game activation mode, the preferred embodiment is that (i) the progressive jackpot portion of the ticket is activated, (ii) the player is informed that the ticket includes a progressive jackpot winner, and (iii) the progressive display is reset, only after the game play occurs that has the progressive jackpot winner. In an alternative version of game-by-game activation mode, the player is informed upon initial scanning of the multi-game ticket that the ticket includes at least one winning game, but the type and amount of the winning game (non-jackpot fixed amount or progressive jackpot) is not communicated to the player, thereby encouraging the player to play through and activate all of the game plays in the ticket.
Regarding a multi-game ticket that include a progressive jackpot winner, in a ticket-by-ticket activation mode, the preferred embodiment is that (i) the progressive jackpot portion of the ticket is activated, (ii) the player is informed that the ticket includes a progressive jackpot winner, and (iii) the progressive display is reset, immediately after scanning the ticket. This process thwarts subsequent clerk fraud since the player is aware that he or she is in possession of a jackpot winning ticket when it is presented to a clerk for redemption. If the ticket checker does not automatically play through the multiple games as discussed above, the player may do so manually and learn if any of the other game plays are winners and the amounts of the win(s), as well as to be informed of the exact amount of the progressive jackpot win.
Regardless of whether ticket activation is performed ticket-by-ticket or game-by-game, the mere fact that the player has presented the ticket to the ticket checker is a sufficient action to thwart the potential clerk misconduct discussed above, especially if the ticket checkers are located remotely from the clerk dispensing locations.
The ticket checker may be implemented in an application (“app”) executing on a mobile device or a local computer. For example, the Washington State lottery provides a “Check Your Ticket” app that allows players to scan their tickets to see if they are winners. However, there is no requirement that a ticket must be checked with the app before it can be redeemed. When implementing the ticket checker embodiment of the present invention, an app of this nature may substitute for the requirement that the player scan the ticket at a physical kiosk before redemption is permitted.
The ticket checker embodiment significantly inhibits clerk fraud that may occur during a clerk-assisted ticket purchasing process. If a clerk learns that a ticket that was just purchased by a player is a jackpot winner, such as by noticing that the jackpot display just decremented, the clerk may surreptitiously swap the winning ticket with a non-winning ticket and set the winning ticket aside for subsequent redemption by themselves or a friend, while handing the player another ticket from the stack, roll or pool of tickets. In another type of clerk fraud, a player hands a previously purchased ticket to a clerk to determine if the ticket is a winner by scanning the ticket at a clerk-accessible ticket checker. If the clerk-accessible ticket checker shows that the ticket is a winner (which can be a jackpot or non-jackpot winner), the clerk may inform the player that the ticket is not a winner and if the player does not ask for the ticket back, the clerk may then keep the ticket for subsequent redemption by themselves or a friend. Alternatively, the clerk could surreptitiously swap the winning ticket with a non-winning ticket and inform the player that the ticket is not a winner.
In this ticket checker embodiment, the progressive jackpot only decrements upon scanning of the ticket at the ticket checker, not upon ticket purchasing. Since the player is informed by the ticket checker that the ticket is a jackpot winner, the player cannot be tricked by a clerk when redeeming the ticket because the player knows that it is a jackpot winner. The same benefit goes for players redeeming non-jackpot winning tickets. In this embodiment, if there is a clerk-accessible ticket checker, this ticket checker is not able to perform ticket activation. That is, ticket activation can only occur at player-accessible self-service ticket checkers.
VI. Multi-Theme Games and Multi-Type Games for Ticket Activating Self-Service Ticket Checker
Game tickets typically have a single “game type” expressed via a single “game theme.” However, a single game type may be expressed by a plurality of different game themes. For example, Diamond Game Enterprises distributes game machines and software that enable a single game type to be played on two or more game machines which are displayed to the respective players as two or more different game themes. More specifically, one game type can be played using the “Dynamite Diamonds” game theme on one game machine and can also be played on another game machine using the “Hot N Saucy” theme. The same type of preprinted tickets are loaded into both machines. The tickets may be from the same deal and, thus, the pay table for both machines is the same. One example of such a ticket is shown in FIG. 1 of U.S. Pat. No. 8,002,622.
One preferred embodiment extends the concept of a multi-theme game to the display of ticket results at a single ticket checker, wherein the player selects the desired theme from a plurality of choices. In this manner, game play is enhanced because the player can select a desired theme. The ticket checker is preprogrammed to show game play results using a plurality of different themes, and thus no programming changes need to be made to the ticket checker after its initial configuration to provide this functionality. The monetary outcome (i.e., winning ticket amount, if any) for a particular ticket is not affected by the theme selected by the player.
In yet another embodiment, different game types may be selected based on the monetary outcome of the scanned ticket. After scanning the ticket, the ticket checker would determine the game types that could generate the monetary outcome of the ticket from each game type's play results and present the applicable game types to the player. Once a game type is selected, the player may optionally be provided with a choice to select a particular theme for the chosen game type. Alternatively, a preselected game theme may be used for each player-selected game type to streamline the ticket activation process performed at the ticket checker. In this manner, game play is enhanced because a player may select a desired game type. The ticket checker is preprogrammed to show game play results using a plurality of different game types, and thus no programming changes need to be made to the ticket checker after its initial configuration to provide this functionality.
Examples of different game types include reel-based games (e.g., slot machine), card games (e.g., draw poker), simulated lottery ticket (e.g., representation of a scratch ticket) and bingo. Since the same preprinted game ticket is used for all of the game types, there is no need to change the installed software on the ticket checker after its initial configuration to translate a given ticket's monetary outcome into appropriate game results for the chosen game type. As discussed above, the ticket checker is preprogrammed to present game results in multiple game type formats.
In
The flowcharts for these embodiments (not shown) are similar to the flowcharts of
Conventional preprinted game tickets which have a predefined monetary outcome, such as instant game lottery tickets or pull-tab tickets, are typically preprinted with a specific game type and game theme, and thus there is no ability for the player to alter the game type or game theme of the ticket, either before or after purchase. As discussed above, one type of preprinted game ticket shown in FIG. 1 of U.S. Pat. No. 8,002,622 is preprinted with a designated game type (e.g., lottery pull-tab game type), but not with a designated theme. These game tickets may be loaded into two different game machines that have different game themes. In such game machines, the player is provided with the physical ticket only after game play based on the theme of the game machine selected by the player.
Unlike any of these conventional gaming processes for preprinted tickets, the ticket activating self-service ticket checker described herein provides a new paradigm for preprinted game tickets wherein a ticket having no predesignated game type and/or game theme is purchased and physically given to a player, who can then select the game type and/or game theme at a single, ticket activating ticket checker machine which is preprogrammed to provide game results in a plurality of different game types and/or game themes.
The ticket checker described herein may handle game tickets that have a predetermined game type and game theme, as well as generic game tickets that do not have a predetermined game type and/or game theme. Thus, if a player scans a ticket that has a predetermined game type and game theme (e.g., a lottery pull tab game type with the “Dynamite Diamonds” theme), the ticket scanner will automatically present the results in the expected manner for the applicable game type and game theme. However, if a player scans a generic ticket, the player will be initially prompted with an option to select a game type and/or game theme before the play results are displayed. In such an embodiment, the ticket checker performs the following initial steps after the player scans the ticket's barcode:
1. Identify whether the ticket is a generic ticket or not.
2a. If the ticket is not a generic ticket, identify the game type and game theme based on information contained within the barcode or otherwise derived from that information (i.e., the game type and game theme may be explicitly coded into the barcode, or other information such as the deal and/or ticket number which is coded into the barcode may be associated with a specific game theme and/or game type); OR
2b. If the ticket is a generic ticket, prompt the player to select a game type and/or game theme, as discussed above. A generic ticket may be identified by either the absence of information in the barcode indicating a specific game theme or game type, or other information coded into the barcode, such as the deal and/or ticket number, may be associated with a generic ticket (e.g., all tickets from a particular deal or within a certain ticket number range are previously designated as being generic tickets when they are printed).
3. Once the appropriate game theme and game type is identified, the appropriate software is invoked to present the play results at the ticket checker.
If no generic tickets are used in the system (i.e., all tickets issued by the system have a predetermined game type and game theme), then the initial step of determining whether or not a scanned ticket is a generic ticket is skipped and the system logic only functions to identify the predetermined game type and game theme, so as to render the appropriate display.
VII. Additional Considerations
Instant game tickets, such as lottery tickets and pull-tab tickets, which are created from deals come in a large variety of types and form factors. The scope of the present invention includes all such types and form factors of instant game tickets.
The embodiments above use an MLPIT deal generated with “X” number of tickets and “Y” number of progressive winners. When the MLPIT deal is completed, various options are available for handling any amounts left in the progressive jackpot, including the following options:
i. If no new MLPIT deal is generated and put into play, any amounts left in the progressive jackpot are handled at the discretion of the applicable regulator or lottery administrator.
ii. If a new MLPIT deal is generated and put into play, any amounts left in the progressive jackpot are rolled over to the new MLPIT deal.
If all of the jackpot tickets in the current deal have been dispensed, various options are available regarding funding of the progressive jackpot, including the following options:
i. Stop funding the progressive jackpot for subsequently purchased tickets and suppress all displays of the progressive jackpot amount so as to avoid communicating to players that a progressive jackpot is currently available to be won.
ii. Continue funding the progressive jackpot for subsequently purchased tickets and continue displaying the progressive jackpot. This option may be used when the progressive jackpot rolls over to a new deal, as described above.
As discussed above, in one embodiment wherein the jackpot resets upon customer redemption of a progressive jackpot winning ticket, a predetermined time period (e.g., 90 days) is preferably designated for redemption of a progressive jackpot winning ticket, so that a customer cannot intentionally and repeatedly delay redeeming such a ticket until the progressive jackpot is more favorable. However, this embodiment may also use conventional lottery rules for unclaimed prizes. For example, the Rhode Island state lottery requires that all lottery prizes for instant game prizes must be claimed within one year of the game end date. In the Michigan state lottery, some instant game tickets print the date by which all prizes must be claimed directly on the ticket. By using either of these conventional processes, it is not necessary to track the date on which the tickets were sold because the sale date has no direct bearing on the ticket expiration date. This simplifies the ticket sales process because no scanning or recording of ticket identifying indicia on individually dispensed tickets is required.
If either of these conventional processes were used in the progressive jackpot of the present invention and the progressive jackpot was funded by a portion of each ticket sale, the recordation of a ticket sale by a clerk, such as by ringing up the ticket purchase using a generic SKU or the like for a ticket, as is known in the art, becomes the triggering event for funding the progressive jackpot.
One aspect of relying upon these conventional rule-based redemption expiration deadlines and not scanning or recording dispensed tickets is that if the “stop funding” option described above is desired to be used, the suppression of the displays will be triggered based on redemption activity, not dispensing activity, because the system does not definitively know when all of the progressive jackpot tickets for a deal were dispensed.
The present invention may be implemented with any combination of hardware and software. If implemented as a computer-implemented apparatus, the present invention is implemented using means for performing all of the steps and functions described above.
When implemented in software, the software code for the servers can be executed on any suitable processor or collection of processors, whether provided in a single computer or distributed among multiple computers.
The present invention can also be included in an article of manufacture (e.g., one or more non-transitory, tangible computer program products) having, for instance, computer readable storage media. The storage media has computer readable program code stored therein that is encoded with instructions for execution by a processor for providing and facilitating the mechanisms of the present invention. The article of manufacture can be included as part of a computer system or sold separately.
The storage media can be any known media, such as computer memory, one or more floppy discs, compact discs, optical discs, magnetic tapes, flash memories, circuit configurations in Field Programmable Gate Arrays or other semiconductor devices, or other tangible computer storage medium. The storage media can be transportable, such that the program or programs stored thereon can be loaded onto one or more different computers or other processors to implement various aspects of the present invention as discussed above.
The computer(s) used herein for the servers may be embodied in any of a number of forms, such as a rack-mounted computer, a desktop computer, a laptop computer, or a tablet computer. Additionally, a computer may be embedded in a device not generally regarded as a computer but with suitable processing capabilities, including a Personal Digital Assistant (PDA), a smart phone or any other suitable portable, mobile, or fixed electronic device.
The computer(s) may have one or more input and output devices. These devices can be used, among other things, to present a user interface. Examples of output devices that can be used to provide a user interface include printers or display screens for visual presentation of output and speakers or other sound generating devices for audible presentation of output.
Examples of input devices that can be used for a user interface include keyboards, optical scanners, and pointing devices, such as mice, touch pads, and digitizing tablets. As another example, a computer may receive input information through speech recognition or in other audible format.
Such computers may be interconnected by one or more networks in any suitable form, including as a local area network or a wide area network, such as an enterprise network or the Internet. Such networks may be based on any suitable technology and may operate according to any suitable protocol and may include wireless networks, wired networks or fiber optic networks.
The various methods or processes outlined herein may be coded as software that is executable on one or more processors that employ any one of a variety of operating systems or platforms. Additionally, such software may be written using any of a number of suitable programming languages and/or programming or scripting tools, and also may be compiled as executable machine language code or intermediate code that is executed on a framework or virtual machine.
The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of computer-executable instructions that can be employed to program a computer or other processor to implement various aspects of the present invention as discussed above. The computer program need not reside on a single computer or processor, but may be distributed in a modular fashion amongst a number of different computers or processors to implement various aspects of the present invention.
Computer-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or distributed as desired in various embodiments.
Data structures may be stored in computer-readable media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a computer-readable medium that conveys relationship between the fields. However, any suitable mechanism may be used to establish a relationship between information in fields of a data structure, including through the use of pointers, tags, or other mechanisms that establish relationship between data elements.
Preferred embodiments of the present invention may be implemented as methods, of which examples have been provided. The acts performed as part of the methods may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though such acts are shown as being sequentially performed in illustrative embodiments.
It will be appreciated by those skilled in the art that changes could be made to the embodiments described above without departing from the broad inventive concept thereof. It is understood, therefore, that this invention is not limited to the particular embodiments disclosed, but it is intended to cover modifications within the spirit and scope of the present invention.
This application claims the benefit of U.S. Provisional Patent Application No. 62/207,602 filed Aug. 20, 2015, the entire disclosure of which is incorporated by reference herein. This application is related to U.S. application Ser. No. 15/218,854 concurrently filed on Jul. 25, 2016 entitled “Ticket checker for activating winning pre-printed game tickets so as to permit redemption of the tickets.”
Number | Name | Date | Kind |
---|---|---|---|
6554710 | Olson | Apr 2003 | B1 |
7883405 | Robb | Feb 2011 | B2 |
8002622 | Breslo | Aug 2011 | B2 |
8197325 | Wright | Jun 2012 | B2 |
20020147047 | Letovsky | Oct 2002 | A1 |
20060040722 | Manz | Feb 2006 | A1 |
20060052160 | Saffari | Mar 2006 | A1 |
20060079320 | Erickson | Apr 2006 | A1 |
20060111170 | Hornik | May 2006 | A1 |
20060211470 | Walker | Sep 2006 | A1 |
20090194988 | Wright et al. | Aug 2009 | A1 |
20090198662 | Prabhakar et al. | Aug 2009 | A1 |
20090224476 | Grauzer | Sep 2009 | A1 |
20090227318 | Wright et al. | Sep 2009 | A1 |
20090270168 | Englman | Oct 2009 | A1 |
20100051708 | Behm et al. | Mar 2010 | A1 |
20100093419 | Wright et al. | Apr 2010 | A1 |
20100120497 | Weber | May 2010 | A1 |
20160026972 | Bhalodwala | Jan 2016 | A1 |
20170004671 | Connolly et al. | Jan 2017 | A1 |
Entry |
---|
Office Action dated Feb. 16, 2018 in U.S. Appl. No. 15/218,854, by Breslo. |
Number | Date | Country | |
---|---|---|---|
20170053494 A1 | Feb 2017 | US |
Number | Date | Country | |
---|---|---|---|
62207602 | Aug 2015 | US |