System and method for generation and validation of multigame printed tickets using multidimensional barcodes

According to various embodiments, a system for implementing a predetermined multigame is disclosed. The system includes a plurality of tickets each having one or more multidimensional barcodes representing information about a plurality of predetermined game outcomes and information about game security and game data integrity. The one or more multidimensional barcodes are configured to be optically scanned to have a result displayed by a computing device to allow a player to determine whether the information about a plurality of predetermined game outcomes comprises a winning outcome.

FIELD OF THE INVENTION

The present invention relates generally to games of chance and, more particularly, to a gaming system and method for providing tickets that encode predetermined multigame game results stored in a multidimensional barcode.

BACKGROUND OF THE INVENTION

The gaming and lottery industries have enjoyed a steady increase in popularity over time. This increase has produced a competitive marketplace for instant win type games of chance.

FIG.1depicts an example of a prior art game card1offered by the Texas lottery. The game is based on the game of poker. The technology used for this prior art game card is a “scratch off technique”. The game player removes a top layer of deposited material to reveal the card images underneath the opaque scratch off material. The area denoted by2is the five card predetermined poker hands. There are ten “games” on a card. The area defined by4is the five cards denoted as the “dealer hand”. According to the rules of the game of poker, the player must reveal a hand “combination” that is ranked higher than the dealer hand in order to win any of the ten “games”. The hidden area3indicates the dollar amount won by the player. The area defined by5is the game instructions. The area defined by6identifies a reference number for the scratch off card. However, this approach can lead to limited game play, requires a specialized printing process, additional expenses to produce a scratch off ticket, and uses what some would consider antiquated “paper” technology.

As such, there is a need for a predetermined multigame that can contain a higher density of game outcomes on an inexpensive, easy to produce game ticket where the game play is transposed into an electronic form for a more interactive experience, especially with instant win type games. It can be easy for users to download software applications onto smart devices, effectively allowing them to be a personal gaming device. With the abundance of “smart” communication devices, such as the Apple or Android smart devices, it can be possible to read an instant win type printed ticket using the smart device's camera and the internet to lookup or download information associated with the instant game on the smart device.

A key element when matching a smart device to an instant win ticket is the ability to represent the predetermined outcomes of a game with limited printing space on the ticket. Error control and verifiability are also desirable attributes of the information placed on the printed ticket. As such, an optically encoded read-only information approach is desirable for encoding the information printed on a low cost to manufacture ticket.

SUMMARY OF THE INVENTION

According to various embodiments, a system for implementing a predetermined multigame is disclosed. The system includes a plurality of tickets each having one or more multidimensional barcodes representing information about a plurality of predetermined game outcomes and information about game security and game data integrity. The one or more multidimensional barcodes are configured to be optically scanned to have a result displayed by a computing device to allow a player to determine whether the information about a plurality of predetermined game outcomes comprises a winning outcome.

According to various embodiments, a method for implementing a predetermined multigame is disclosed. Them method includes generating a total plurality of predetermined game outcomes for the predetermined multigame via a game specification file of a computer system and shuffling the total plurality of game outcomes for the predetermined multigame via a random number generator of the computer system. The method further includes causing each of a plurality of predetermined multigame tickets to be produced with one or more multidimensional barcodes representing information about a plurality of predetermined game outcomes of the total plurality of predetermined game outcomes and information about game security identification and game data integrity. The one or more multidimensional barcodes are configured to be optically scanned to have a result displayed by a computing device to allow a player to determine whether the information about a plurality of predetermined game outcomes comprises a winning outcome.

According to various embodiments, a non-transitory computer-readable medium having stored thereon a computer program for execution by a processor configured to perform a method for implementing a predetermined multigame is disclosed. The method includes generating a total plurality of predetermined game outcomes for the predetermined multigame via a game specification file of a computer system and shuffling the total plurality of game outcomes for the predetermined multigame via a random number generator of the computer system. The method further includes causing each of a plurality of predetermined multigame tickets to be produced with one or more multidimensional barcodes representing information about a plurality of predetermined game outcomes of the total plurality of predetermined game outcomes and information about game security identification and game data integrity. The one or more multidimensional barcodes are configured to be optically scanned to have a result displayed by a computing device to allow a player to determine whether the information about a plurality of predetermined game outcomes comprises a winning outcome.

DETAILED DESCRIPTION OF THE INVENTION

Generally disclosed herein are embodiments for a gaming system and method for generating and playing predetermined multigame tickets (i.e. a ticket containing multiple games or multiple rounds of a single type of game). The tickets encode the predetermined game outcomes in a multidimensional barcode. The player scans the barcode on their smart device and plays the encoded multigames using an internet downloaded software application program.

Embodiments of the present invention preserve the advantages of the prior art approaches for the production and playing of multigame tickets while providing for a denser storage capability of predetermined outcomes using standard ticket printing techniques, as well as providing for a security system and method for ticket verification.

The denser storage capability is provided by generating predetermined game outcomes and encoding them into a multidimensional barcode. A nonlimiting example of a multidimensional barcode is a quick response (QR) code, as seen inFIG.4.

The predetermined outcomes are generated using outcome results from specification tables and a random number generator. The predetermined outcomes are shuffled and batched into subgroups. The size of a subgroup is defined in the predefined game rules. A security code is generated for each batch of predetermined outcomes. The batch sequence number is encoded into the security code and stored in a secure database for the eventual ticket verification process.

Important technical advantages of certain embodiments of the present invention include generating batched game predetermined outcomes, generating security codes, and encoding the outcomes and security codes into a multidimensional printed code suitable for optical scanning.

Additional technical advantages of embodiments of the present invention will be readily apparent to one skilled in the art from the following figures, description, and claims. Moreover, while specific advantages have been enumerated above, various embodiments may include all, some, or none of the enumerated advantages. The game of Poker is used as a nonlimiting example of how the method and system perform. However, any predetermined multigame can be used in conjunction with this system and method, such as Black Jack, Craps, and slot machines, as nonlimiting examples.

FIG.2is a pictorial overview of a multigame system using multidimensional barcodes, such as but not limited to a 2-dimensional barcode. WhileFIG.2and subsequent figures may refer to the multigame system as “lottery” based, the reference to “lottery” is intended to be a nonlimiting example of a multigame system or method. A game specification50and the game rules (not shown) define the characteristics of the multigame ticket. The game specification50may be developed at a secure site external to the main multigame office51. Communication of the game specification may occur using a secure data network52. The main office51uses the game specifications50and game rules along with a hardware random number generator55to create and shuffle the game outcomes. The main office51generates batches of the game outcomes as defined in the game specification file50and stores the batch information in a database server62. The main office51coordinates with the secure ticket printing facility53to print the multigame ticket57with the batch information as stored in the database server62. The main office51may utilize a courier, a delivery service, or other means to physically distribute54the printed multigame game tickets57to authorized retailers56,61,63(such as lottery retailers). Players59,60can purchase the multigame game ticket57from any of the authorized retailers56,61,63. Using the camera on their smart device58, the player is able to display all the available game outcomes and determine the winning amount associated with the multigame game ticket57.

FIG.3is an example of a ticket100for the predetermined multigame using a 2-dimensional (2D) barcode system. The ticket100contains three 2D barcodes101,102,103. The first 2D barcode103may contain a uniform resource locator (URL) link which allows the player to download the application on their smart device, allowing the player to display the outcomes associated with the ticket100. The second barcode102may contain a URL link which will direct the player to the specific page on the multigame organization's website which describe the game specifications and game rules. The third 2D barcode101contains a nonlimiting 217 bytes of data. This data contains various game and ticket security identification information (i.e. game security and data integrity information) as well as encoded game outcomes. The amount of data varies with game complexity variations.

FIG.4shows an example of a 2D barcode150that could be used in the multigame system. The 2D barcode150contains 217 bytes of data, including 8 bytes for the security identification code, 4 bytes for identifying the game series code, and 1 byte identifying the number of encoded game outcomes stored in the 2D barcode150. The next 200 bytes stored in the 2D barcode150are the encoded game outcomes. The final 4 bytes of data are used as verification data to ensure the information contained in the 2D barcode150is valid.

FIG.5is a flow diagram representing a simplified overview of the life cycle for the multigame ticket. The flow diagram starts200after the 2D barcode has been created, the ticket has been printed, and the ticket has been distributed to an authorized retailer. The player visits the authorized retailer and in step201purchases the multigame ticket at the price documented in the game rules. In step202the player “pairs” or associates the ticket to their smart device by having the smart device read the information stored in the 2D barcode using a built in camera or other optical scanning device in the smart device. A separate optical scanning device connected (by wire or wirelessly) to the smart device may also be used if the smart device does not have optical scanning capabilities. The previously downloaded software application running on the smart device will decode the game outcome and create the game board for player interaction in step203. If the software application is not downloaded yet, the player will be able to download the application using a link embedded in a barcode on the ticket. Once the player has concluded interaction with the game outcome (game is finished), the software application determines if the outcome is a winner based on the game specifications in step204. If the outcome includes a winning combination, the software application branches to step205to add the prize amount to the accumulated winnings of the multigame ticket thus far. In step206the software application determines if there are game outcomes left to display. If there are, the program loops back to step203. If all game outcomes have been displayed, the software application proceeds to step207and displays a “ticket complete” message. The next step208is for the player to return the multigame ticket (if there is one or more winning outcomes). Dependent on the game rules, the player may return the ticket to an authorized retailer, return the ticket directly to the main office, or redeem electronically (if permitted). Once the ticket has been returned, in step209the ticket information will be validated and the database will be updated to indicate the multigame ticket has been completed and retired. The final step210is for the player to receive the accumulated winning amount from the multigame. This could be in various forms such as but not limited to cash, check, or electronic transfer based on the game rules. The process completes in step211.

FIG.6provides a game specification breakdown250for a sample game of Quick Poker. There will be a total of 10,800,000 game outcomes created for the game. The prize schedule251inFIG.6shows the individual prize counts for each monetary prize tier. From the total number of games and the tier level prize counts, the odds of each specific prize tier can be calculated. By example, there are just ten $500 tickets available. This defines the odds of the top tier prize level that wins $500 at 10/10,800,000 or 1 in 1,080,000.

As seen inFIG.6, there are 10 possible winning outcomes. The 10 outcomes are “tokenized” (encoded) into a single 8-bit numeric value (byte). With just 10 of 256 possibilities used, there is an opportunity to add further winning possibilities to a game “hand”. A nonlimiting example would be to add 1 wild card joker, allowing an odds change to the existing winning hands (tokens). There will only be 10 game outcomes with a value of $500 (Top Tier) for the sample game. This is also the case for the $250 prize tier.

FIG.7is a flowchart for the population and randomization of one hundred prize pool arrays. It should be noted this flowchart, as well as the following flowcharts, is based on the game specification example inFIG.6for the numbers used, and that aspect is not intended to be limiting. The function begins at “start”300. The first step in the process is a software call to the prize_pool_determination function in step301. A table is loaded into the database's memory which assigns a token number to each prize level in step302.

Variables called Pool_ID and Array_Pointer are respectively initialized to zero in step303,304. The subfunction Prize Pool Population is called next in step305. Once the prize pool array is populated with the appropriate prize tokens, another subfunction is called to perform a Durstenfeld Shuffle in step306to randomize the prize pool array. When the randomization is completed, the prize pool array is stored in step307into the main database. The variable Pool_ID is incremented by one in step308. The variable is then checked to see if it is equal to one hundred in step309, indicating if there are more prize pool arrays to populate and shuffle. If there are more arrays to populate, the method begins to populate the next array by returning to step305, otherwise the method ends in step310.

FIG.8is a flowchart for the process used to determine which prize pools will contain the prizes, which are less than one per pool as defined in the game specifications. In this example, the prize determination method will determine which prize pool array will contain the token numbers for the $500 (token #9) and $250 (token #8) prizes. The function enters at start350and creates a temporary array of 100 elements and populates the positions with values between 0 to 99, representing the 100 prize pool arrays in step351. The method next performs a Durstenfeld Shuffle in step352to randomize the values of the array. When the shuffle is completed, the first 10 array elements are retrieved in step353and will be used to indicate which prize pool will contain the token number for the prize of $500. The next ten elements are retrieved and will be used for the assignment of the $250 token numbers in step354. In step355, the method returns the values to the software calling routine.

FIG.9is a flowchart for the process which populates each of the 100 prize pool arrays with the tokens for the prizes available to win. The process starts at step400. The process then begins creating a pool_array with 108,000 elements all assigned to zero in step401, which is the token number for a non-winning game outcome. The process then checks if the Pool_ID variable (which is passed from the calling array) indicates this is a pool array which receives the token for a $500 ticket in step402. If yes, the method replaces the element in the pool array at the location of the array pointer with token #9 in step403before incrementing the array pointer in step404. Next, the process checks to see if this pool_array will contain the token for a $250 winner in step405. If yes, the method updates the current element to #8 in step406before incrementing the array pointer in step407. As there is one $75 winner per prize pool, the process populates the next index with token #7 in step408. Not shown is the process of incrementing the array_pointer by the number of indexes updated, in this case the pointer is incremented by one. The next 90 indexes are populated with token #6 for the $40 winners in step409and the array_pointer is incremented by 90 (also not shown). The process populates the next 180 indexes with token #5 in step410, increments the array_pointer (not shown) before populating the following 1080 indexes with token #4 in step411. The process continues the population of the specified number of indexes in steps412,413, and414of the array and incrementing of the array pointer (not shown) for each prize level. The remaining indexes in the pool_array have already been initialized to zero, which is the token number for non-winning game outcomes tickets. The method returns to the calling method in step415.

FIG.10shows a process flowchart for the Durstenfeld Shuffle function used to randomize the various data arrays. The process enters the function through the “Start” block in step450. Since numerous sequences of routines utilize this function, the Shuffle_Count variable must be set to equal the Array_Size in step451and the Array_Pointer variable is set to Array_Size-1 in step452. Once a 32-Bit true random number is generated in step453, a modulus function is performed in step454to ensure the random number generated is within the range of 0 to the Array_Pointer. The result of the modulus function is set to the Swap_Pointer in step455and the values in the array stored at Array_Pointer and Swap_Pointer are transposed in step456. The variable shuffle_count is decremented by one in step458and checked to see if it is equal to zero in step459. If shuffle_count is not equal to zero, there are more elements to shuffle so Array_Pointer is decremented by one in step457and the process repeats from the selection of the 32-bit number in step453. Once shuffle_count equals zero, the shuffle of the array has been completed and the function can return to the calling routine in step460.

There are many ways to shuffle data including but not limited to the Fisher and Yates' method, Durstenfeld shuffle, “inside-out” algorithm, and Sattolo's algorithm. However, the Durstenfeld shuffle is one of the most effective algorithms for shuffling. One of the advantages of performing a Durstenfeld shuffle is the speed at which it performs. It requires a decrementing pointer that reduces the size of the swap field. A random number generator is used to select a pair of swap pointers to perform a single swap. As the swap field is reduced, a modulus is applied to the random numbers. In order to achieve optimal shuffle results, a true random number (hardware) should be used and truncation bias must be accounted for when applying a modulus function to the random number outcome.

FIG.11is a flowchart for the process of generating a true random number between the values of 0 and “N”. This flowchart produces the random numbers, which can later be “shuffled” into further random order utilizing the Durstenfeld Shuffle method. The term “true” indicates that some physical source of noise or random behavior is being measured and an unsigned 32-bit digital number is produced. Some examples of physical random sources are nuclear decay of a radioactive material, white noise voltages produced by a resistor at a specific temperature, randomly phased oscillators being sampled, or semiconductor “shot” noise. The key attribute of the various “noise” sources is that they are non-deterministic in terms of behavior and can only be described on a statistical basis. Usually the physical noise source is “whitened” using software to decorrelate sample values. By example, if left as an unsigned 32-bit integer, the random values would vary from 0 to 4,294,967,296.

When targeting specific probabilities, a modulus function is used to set the upper limit on the random outcome, by example 1 in 100. A modulus of 100 applied to the 32-bit raw random number value will produce a random value of 0-99. The modulus function is based on an arithmetic decision function generally expressed as: N/D, remainder R. By example, if N is 10 and D is 8, then R=2. For the purpose of random number generation, the modulus function introduces “truncation bias” which will affect the statistical outcome. The effect of truncation bias must be compensated for when producing a random integer value between 0 and “N”.

The process starts in step500. In step501the function of generating a 32-bit unsigned random number between a value of 0 to “N” starts, where N is an input variable defining the upper limit of the random number return. Step502determines an “ANDing” logical mask to be applied to the modulus “N” to correct for truncation bias, to be described further inFIG.12. Step503traps an error whereby, the modulus is 0 and returns to the calling function at step504.

Step505starts the process of requesting an unsigned 32-bit hardware generated random number. Step506executes a suitable function to access the true random number generator. Step507applies the truncation correction bit mask. Step508determines if the random number exceeds the modulus limit defined by the bit mask.

If the random number is within the limits of the bit mask, the value is returned at step511. If the random number exceeds the bit mask limit, the loop_count is incremented in step509and the loop_count limit is checked in step510. If loop_count is exceeded, then an error is declared in step512, otherwise a new random number is selected by returning to step506.

FIG.12provides details on creating a modulus bit mask in flowchart form. The modulus value is in a 32-bit unsigned format, which can be broken into four 8-bit groups (bytes). Each byte of the modulus is checked for a non-zero value in steps551,554,557,560. If found, a bit mask will be resolved in respective steps553,556,559,562and the function exits in step564. If all four groups are set to 0, then the modulus is set to 0, which is an illegal value. If a 0 modulus is detected, an error flag is set (zero_flag) in step563and the function exits564.

FIG.13is a flowchart depicting the routine for creating the batches of encoded game outcomes to be used in the 2D barcodes. The routine enters at step600. The variables PoolCnt and IndexPtr are initialized to zero in steps601and602, respectively. The 108,000 byte Pool_Array(poolcount) is copied to a temporary array named CardArray in step603. In step604, a Durstenfeld shuffle is performed on CardArray. A temporary working array named DataCode with a size of 217 bytes is created and initialized in step605. A local variable named CardCnt is initialized to zero at step606. In step607, the security identification code is generated. The 8 byte security identification code is stored in the DataCode array. The 4 byte game series code as defined in the game specification and rules is retrieved and stored in the array in step608. Next, in step609, the game count is stored in the DataCode array. In the current embodiment, the Game Count is set to a fixed 200 games, but in other embodiments the count could be variable or fixed to a different value. The game outcomes previously copied to the CardArray are copied to another temporary array named PrizeOutcomes in step610and encoded prior to being copied into the DataCode array in step611. A 4 byte checksum to guarantee data integrity is calculated over the 213 bytes previously stored in the DataCode array and stored in the final 4 bytes of the DataCode array in step612(nonlimiting example is CRC-32 or more formally, Cyclic Redundancy Check Character). The full DataCode array is stored as a record in the master database file in step613for later retrieval for printing and verification purposes. The CardCnt variable is incremented by 1 in step614and compared to 540 in step615. 540 is the number of barcodes created from each of the prize pools. Referring back to the table inFIG.6, a prizepool contains 108,000 game outcomes and each barcode contains 200 outcomes. Therefore, 108,000/200=540. If CardCnt is less than 540, the program loops back to step607, otherwise all outcomes in the current prize pool have been grouped. The program increments the PoolCnt variable in step616and checks to see if it is equal to 100 in step617. If the count is not equal to 100, indicating there are more prize pools remaining, the program loops to step602; otherwise, the program exits the routine at step618.

The system and method for a multigame game ticket as described herein utilizes a security method and system defined by embodiments of the invention found in U.S. Pat. No. 8,870,084 ('084 patent), which is herein incorporated by reference in its entirety. The following is a summary of the '084 invention operating as a security system and method for a multigame game ticket and system.

FIGS.14and15illustrate a security key generation and validation system according to the embodiment of the present invention. The security generation process includes the following: An index number generator652is connected to a symmetrical encryption/decryption unit653. Private key #1650selects the index number security ordered pairs generated by the symmetrical encryption/decryption unit653. Also, acting as control elements to the encryption/decryption unit are the word size control655and mode inputs656. The word size control input defines the number of bits used as a digital word for both the input and output ports of the symmetrical encryption/decryption unit653. The mode input656identifies the mode of operation as encryption. The input of the key security module654is connected to the output of the symmetrical encryption/decryption unit653. Private key #2651controls the generation of a security code that is concatenated with the input of the key security module654and placed into the extended key output buffer657. The output of extended key output657is an 8-byte extended key658.

The security validation process starts with the contents of extended key output buffer657(e.g. the 8-byte extended key704) being placed into the extended key input buffer705. This is done by any means, such as a wired or wireless communications path, disk file, or human keyboard input, as nonlimiting examples. The contents of the extended key input buffer705act as an input to the extended key code validator706. The extended key code validator706produces a validity status711, indicating if the key is valid. The validity status of the extended key code validator706will indicate if the content of the extended key input buffer705were produced by a key generator whereby private key #2651matches that of private key #2700. If the validity status is affirmative, a process sequencer (not shown) will proceed to convert the extended key to a number index value by way of the symmetrical encryption/decryption unit707. The symmetrical encryption/decryption unit has two control inputs, word size712and mode713. Word size712defines the number of bits that are operated upon. Mode713is a single bit control defining encryption or decryption mode. The operation and functionality of the symmetrical encryption/decryption unit707is identical to that of653except that the mode is set to decryption. If the validity status is negative, indicating the extended key was not generated by an authorized key generator as defined by this invention or not utilizing the same private key #2651,700, the process sequencer (not shown) will abort any further processing and take appropriate actions to indicate the invalidity of the processed contents of the extended key input buffer705.

The output of the symmetrical encryption/decryption unit707is connected to both the input of a number range verifier709and a bit vector management process702. The number range verification709generates a range status710, which indicates whether the number is within an upper708and lower bound714. The process sequencer may optionally use the index value output from the symmetrical encryption/decryption unit707to verify if a bit is set in a bit vector (not shown) located within the bit vector management process. If the process sequencer determines the bit is set, it would indicate that the key code in the extended key input buffer705had been processed at a previous time and should abort any further processing of the extended key as well to take appropriate actions to invalidate the extended key input. The number range verifier709will determine if the input of the number range verifier709is greater than or equal to the “B” input to the number range verifier709and less than or equal to the “C” value of the number range verifier709. The range status710of the number range verifier709will provide a binary status if the input is within the range of values “B” and “C”. The bit vector management process702will set a bit within a bit vector (not shown) as specified by the index value output from the symmetrical encryption/decryption unit707. Setting the bit within the bit vector indicates that the extended key was valid and has been processed.

Symmetric, secret-key, and block encryption/decryption methods (symmetric-key) are defined as a class of algorithms for cryptography that use identical cryptographic keys for both encryption of plaintext and decryption of ciphertext. In practice, the keys represent a shared secret. Other terms for symmetric-key encryption are secret-key, single-key, shared-key, one-key, and private-key encryption.

Symmetric-key cryptography transforms (scrambles) a message into something resembling random noise. The key determines the precise transformation. Mathematically, a cryptographic algorithm is a function that maps a message onto a ciphertext (an encrypted message). By using keys, it is possible to encrypt many different messages using one particular cryptographic algorithm with a different outcome for each key.

Some cryptographic algorithms that operate on fixed word lengths are referred to as block ciphers. Block (word) sizes of 32, 64, and 256 bits are commonly used. Some nonlimiting examples of popular and well-respected symmetric encryption/decryption algorithms are Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, DES, Triple-DES, and IDEA.

FIG.16is a flowchart for the routine which encodes the game outcome tokens stored in the prize pool arrays. The routine enters at750. The variable GameCnt is initialized to zero in step751. In step752a random number between 0-255 is generated. The bit mask modulus function is called in step753to eliminate truncation bias. The random number is assigned to the variable tableptr in step754as the index into a 256 byte table stored in memory. The value stored in the table at tableptr is retrieved and exclusive ORed with the value at location GameCnt in the PrizeOutcomes array in step755. The encoded value is stored in the DataCode array in step756. The process of “exclusive ORing” obscures the value of the tokenized predetermined game outcomes with random data. This is equivalent to adding an opaque “scratch off” layer to a conventional scratch off game ticket. To retrieve the original token value, the “obscured” taken value is exclusive ORed again with the same random value. The variable GameCnt is incremented in step757and compared to 200 in step759. 200 is the number of game outcomes that are being encoded for the barcode. If the variable equals 200, indicating all game outcomes have encoded, the routine ends and returns to the calling program in step761. If the variable does not equal 200, tableptr is incremented in step760. The variable is then AND'd with 255, producing a value between 0-255, in step758, before looping back to step755.

The outcome token encoding process described above and inFIG.16provides a randomizing process to obscure the actual token values. It should be noted that at step752a software based random number is used. A nonlimiting example is the linear congruential random number generator: 13*X+1. This simple random number generator when restricted to 8 bit unsigned numbers will appear to produce random number values between 0 and 255. No two numbers will be repeated until the cycle starts over. When the game parameters are downloaded from the host during the card installation process a “seed” 8 bit value is identified as a starting value for the software based random number generator. Downloading the random number seeds for each game outcome occurs at step856inFIG.18, to be describe in further detail below.

FIGS.17(a)-(d)represent an example of the rules associated with a predetermined multigame ticket game800. The rules indicated the name of the associated game and a game ID number along with the cost to purchase a multigame ticket from an authorized retailer. The play symbols which may appear in the “Game Board” area (FIG.19, element905) are defined. Also defined are the available prizes that can be won on a multigame ticket and the total number of game outcomes that will be produced for this game.

How and which prize a player wins is defined next in the rules. There is a table included in the rules that shows in more detail the prizes available to win, the odds of winning each prize and the number of outcomes produced for each of the prizes.

Some lotteries may offer retailer incentive awards and bonuses for selling lottery tickets, specifically winning lottery tickets. If so, the details of these awards and bonuses will be described in the game rules. There is also a disclaimer indicating the time frame to redeem a winning scratch off ticket, which laws will be in effect for this game (this is typically the state where the lottery office is located), and how the player may redeem their winning scratch off tickets.

There is a disclaimer that the main office may announce a termination date which would end the sale of this game's scratch off tickets. A termination date may be announced for several reasons such as a predetermined date or all top prize tickets have been redeemed.

FIG.18is a top level flowchart of the application for a smart device. The program begins at step850and checks to see if there are game outcomes left from a previously scanned ticket in step851. If there is a game in progress, the program skips forward to step857. Otherwise the program waits for the player to “scan” the barcode with the camera or other optical scanner at step852. The program decodes the information stored in the 2D barcode in step853to determine if the barcode contains game information. If it is not game information, the program displays the URL link to the game rules for the player to read in step854before looping to step852.

If the barcode did contain game information in step855the software application determines, based on the game series code, if this is the first time this game variation has been accessed on this device. If yes, the software application branches off to the routine to download game information for the applicable online resource in step856, before returning. In step857, the software application restores (if a previous game was in progress) or initializes (if a new ticket) the various game variables. The software application then retrieves and decodes the next (or first) game outcome to be displayed in step858. Based on the game outcome and game information downloaded, the software application in step859calculates the appropriate card hand to display to achieve the proper game outcome. The software application then displays the game screen in step860, with all cards “turned face down”. The software application waits for the player to select a card to display (not shown) before revealing the selected card in step861. If all cards have not been displayed in step862, the software application loops back to step861. Otherwise the software application continues to step863and adds the winning amount for the hand, if any, to the accumulated winnings thus far earned for the ticket. The games remaining count is decremented in step864and the software application determines if there are any remaining counts at step865. If yes, the program waits for the player to initiate a new hand (not shown) before looping back to step858, otherwise it continues to step866and displays a game over message. The software application then connects via the internet to the ticket database to change the status of the ticket to complete in step867. The program ends at step868.

FIG.19is a pictorial representation of an implementation of a nonlimiting game. The display on the smart device900shows the game screen. On the game screen is the play board905which contains the 5 individual game cards906. When the game begins, all 5 cards are “face down” and are turned face up as the player taps the individual cards. Also located on the play board is the “quick draw” virtual button903. This can be used by the player to quickly reveal all the remaining cards in the hand. Once all 5 cards are revealed, the player selects the “new game” virtual button904to display the next hand. The games remaining count901is displayed to indicate to the player how many hands are left to display, also displayed in the accumulated winnings of the ticket902. These values are automatically updated when each hand is finished.

FIG.20depicts an example of a server farm associated with the main office51. The server farm is illustrated simply for exemplary purposes and is not intended to be limiting. The server farm includes any number of web devices 1 through N, illustrated here as web device925A and web device925B. The web devices are connected via the internet926to a hardware load-balancing server930through a router929, firewall928, and TCP/IP927. The hardware load-balancing server930and a raid disk subsystem932are connected to any number of webserver computers, illustrated here as computers933A-D, via a LAN switch931.

FIG.21depicts an example of a specification computer system associated with the game file specification50. The specification computer system is illustrated simply for exemplary purposes and is not intended to be limiting. A computing system952is connected to the Internet955through a firewall953and is also connected to a printer950. The computing system952includes a hardware based true random number generator951, as well as a multigame ticket specification file954, a specification image print file957, and custom application software956.

FIG.22depicts an example of a printing computer subsystem associated with the printing facility53. The printing computer subsystem is illustrated simply for exemplary purposes and is not intended to be limiting. A computing system976is connected to the Internet978through a firewall979and is also connected to a standard high resolution printer977. The computing system976includes a print file utility980for receipt of a specification image print file for multigame ticket975printing.

As such, generally disclosed herein are embodiments for a gaming system and method for generating and playing multigame tickets. The tickets encode the predetermined game outcomes in a multidimensional barcode. The player scans the barcode on their smart device and plays the encoded multigames using an internet downloaded software application program.

It is understood that the above-described embodiments are only illustrative of the application of the principles of the present invention. The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope. Thus, while the present invention has been fully described above with particularity and detail in connection with what is presently deemed to be the most practical and preferred embodiment of the invention, it will be apparent to those of ordinary skill in the art that numerous modifications may be made without departing from the principles and concepts of the invention as set forth in the claims.