Abstract:
A production method and system are provided for enabling the secure sharing of a common prize fund across multiple lottery or contest games and/or sub games. By sharing common inventory control and validation files the multiple games will validate on existing lottery or contest systems without the need for any software or hardware modifications. These methods and systems enhance the games, as well as potentially expand the consumer base for the games.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims the benefit of U.S. Patent Application No. 62/292,120, filed Feb. 5, 2016, the disclosure of which is hereby incorporated herein by reference in its entirety. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention is the innovation of control mechanisms for enabling contests or lotteries preferably utilizing tickets or documents with variable indicia determining winning and losing tickets or documents that are hidden under a Scratch-Off Coating (SOC) comprised of a very small number of tickets or documents sharing a larger prize pool and thereby enabling games including a very small number of tickets or documents to nevertheless enjoy the benefits of substantial prizes. Specifically, this innovation resolves the problem of producing customized games or contests for small groups with correspondingly small sales while still offering large prizes on a fixed or parimutuel basis. 
       BACKGROUND 
       [0003]    Lottery games have become a time honored method of raising revenue for state and federal governments the world over. Traditional scratch-off and draw games have evolved over decades, supplying increasing revenue year after year. However, after decades of growth, the sales curves associated with traditional games seem to be flattening out. This flattening of lottery sales curves is typically attributed to a fixed base of consumers that routinely purchase lottery products with very few new consumers choosing to participate in the lottery marketplace. Various analyses of state lottery sales data tend to support the hypothesis that lotteries rely heavily on an existing consumer base and more specifically on lottery “super users.” Three states (Rhode Island, South Dakota and Massachusetts) had 2014 lottery sales that topped $700 per capita. While ten states had per capita sales below $100, per capita sales for all state lotteries averaged almost $250. Demographically speaking, this existing base of lottery consumers is aging with younger consumers showing very little interest in participating in existing lottery offerings. Thus, the potential for ever-increasing lottery sales is increasingly problematic with the existing fixed base of consumers saturated. Consequently, both lotteries and their service providers are presently searching for new forms of gaming. 
         [0004]    In addition to flattening sales, a static lottery consumer base is often cited as exploiting problem gamblers with various legislatures debating restrictions or probations being placed on lotteries. For example, “Stop Predatory Gambling”, which advocates an end to state-sponsored gambling recently stated: “State lotteries have a business model that&#39;s based on getting up to 70 to 80 percent of their revenue from 10 percent of the people that use the lottery . . . .” In Minnesota, a pending bipartisan bill would require 25% of lottery billboards to be dedicated to a warning about the odds of winning, cautions about addiction, and information on where problem gamblers can seek help. 
         [0005]    In an attempt to diversify their base and increase sales, United States lotteries have come to appreciate the virtues of producing games with more entertainment value that can be sold at a premium price. For instance, ten-dollar instant ticket (i.e., scratch-off) games with higher paybacks and more ways to win now account for over $5 billion a year in United States lottery sales. But by their nature, high-volume, generic, higher priced instant games are a minor part of overall game offerings and although they have their place, they have limited potential for assisting in consumer base diversification. The high-priced and high-volume nature of these games tends to drive the lotteries to generic (i.e., proven) type of play (i.e., appealing to existing player base) with very little experimentation possible. Lastly, these higher priced and high-volume games also typically add little unique entertainment value relative to lower priced instant tickets and consequently do not to attract many new consumers. 
         [0006]    In addition to lotteries, there are numerous contests and raffles that are classically used both as promotions and alternative methods for charitable organizations to raise funds. However, unless these contests and raffles are very large in scale they will by necessity offer only smaller prizes, thereby limiting their broad appeal. 
         [0007]    Moreover, as gaming technology and systems continue to evolve and become more sophisticated, numerous new types of games and products become available that require discrete new methods of funding and enabling. Gaming trends no longer support gaming to the masses, rather differentiation through information is favored with gaming systems tracking and targeting using such concepts as: predictive value, frequency, platform game choice, average bet, etc. However, tracking and targeting gaming platforms to these concepts necessitates segmenting the player base into smaller and smaller groups or pools with each group or pool too small to sustain a viable prize fund by itself. 
         [0008]    Some attempts have been made to enable funding of smaller lottery and other types of games. U.S. Pat. Nos. 6,588,747; 6,793,219; 7,213,811; 7,635,302; 7,635,304; 8,216,045; and 8,845,409 and United States Application Publications 2005/0164767 and 2010/0093419 all teach offering optional secondary or additional games or tiers with lottery tickets with a correspondingly smaller player base and associated prize fund. However, these optional secondary games as envisioned simply employ a subset prize fund of the primary game that is preordained with the creation of the primary game and do not anticipate prize funds across multiple smaller games. U.S. Pat. No. 7,407,436 teaches expanding the expected return of a game by dividing funds received into both a prize pool and an investment fund where assets are purchased with the investment fund, such that the overall expected return of the game over a given period of time is positive when compared to a static prize fund; but, this reference fails to specifically address increasing prize funds for multiple small lots of games or tickets. United States Application Publication 2005/0164767 teaches enhancing a prize fund by selling the risk to an outside entity; but again, this reference fails to specifically address increasing prize funds for small lots of games or tickets. 
         [0009]    United States Application Publications 2003/0080507 and 2003/0125108 disclose that for the gaming industry, such as lottery-type games, games can be more exciting for consumers if larger payouts (e.g., one billion dollars) are offered. These larger payouts, with correspondingly long odds of winnings, are not necessarily won during any specific game genera play, but would essentially be offered as an additional drawing. Consequently these larger prizes require some entity to assume the risk. The &#39;108 application discloses the use of financial instruments to hedge the risk with the &#39;507 application expanding on the risk mitigation concept by essentially having insurance companies issue an insurance policy covering the large prize. However, neither of these applications addresses a fixed prize fund where prizes are financed solely by ticket sales, nor do they envision financing mid-tier prizes (e.g., $50, $100, $500, etc.) for small lots of games or tickets. Furthermore, neither application addresses the vexing problem of backward compatibility of their disclosed larger payout drawings with existing lottery validation systems. 
         [0010]    Finally, United States Application Publication 2014/0187305 teaches sharing of a common prize fund across multiple Internet games with the various games employing different play styles, indicia, etc. by all drawing from a common prize fund. However, the &#39;305 application still envisions a fixed prized fund with a priori knowledge of all game details (e.g., number of games, number of plays, types of prizes, etc.) established at the time of prize fund creation. While this type of a priori knowledge of game details is possible for Internet gaming due to the low production costs (i.e., practically zero) of per game play, the &#39;305 application does not readily accommodate games with physical embodiments like instant tickets with a SOC where production costs and logistics are higher and economies of scale assume large print runs in the tens of millions. Additionally, the &#39;305 application does not envision accommodating existing lottery retail venues of physical ticket redemption. 
         [0011]    Thus, it is highly desirable to develop gaming systems platforms that provide methods of funding new gaming opportunities, particularly more customized and consequently smaller volume games. Ideally these gaming platforms should accommodate smaller pools of tickets that are not necessarily manufactured at the same time thereby allowing for flexibility and creativity for game designers to tailor games to a wide variety of small targeted segments as they become available hereunto not served by existing gaming offerings, in turn appealing to a broader base of consumers. 
       SUMMARY OF THE INVENTION 
       [0012]    Objects and advantages of the invention will be set forth in part in the following description, or may be apparent from the present description, or may be learned through practice of the invention. 
         [0013]    In accordance with aspects of the invention, secure gaming systems are established that enable multiple individual games from pico (“pico”&lt;10), nano (10&lt;“nano”≦100), and micro (100&lt;“micro”≦10,000,000) through standard macro (“macro”&gt;10,000,000) game sizes to share a common prize fund. In certain embodiments the multiple individual games may be instant lottery ticket games with a SOC hiding the indicia. 
         [0014]    In a particular embodiment, multiple pico, nano, micro, etc., games are linked to a common fixed prize fund where the prize payout is assured to be within predefined limits yet offering chances at large prizes (e.g., $500,000) on games with very few or even only one player. This linking of pico, nano, and micro games to a common (larger) prize fund is accomplished in a manner that ensures backward compatibility with existing validation systems such as lottery instant ticket systems. 
         [0015]    In another embodiment, the pico, nano, and/or micro games are created on-demand and linked to a pre-established prize fund that maintains security against pick-out—i.e., an insider attempting to illicitly leverage the on-demand gaming feature to pick-out winning tickets in advance of purchase. This particular embodiment accommodates dynamic game allocation—i.e., where a priori knowledge of the games to be linked or pooled to the common prize fund is not necessarily known at the time of prize fund creation. This embodiment also has the advantage of supporting gaming systems employing contextual marketing to gaming prospects. 
         [0016]    In yet another embodiment, multiple pico, nano, and/or micro games share a predefined pay-in criteria (e.g., percentage of retail sales), thereby enabling differing prizes from game-to-game so long as each game&#39;s payout is within predefined criteria. In a preferred embodiment, these pay-in and payout criteria are weighted via the retail costs of game play. Additionally, this predefined pay-in criteria may be utilized to create a progressive prize fund similar to progressive jackpots for slot machines (e.g., U.S. Pat. Nos. 5,048,833; 5,280,909; 5,249,800; and 8,348,754, the disclosures of which are hereby incorporated herein by reference in their entireties) where a macro, micro, nano, or pico instant ticket&#39;s top prize entitles the winner to a percentage of the accumulated progressive jackpot from multiple games. In a preferred embodiment, the percentage of the progressive jackpot that the winner receives is determined by the ticket retail price. 
         [0017]    In all of these embodiments, the linked pico, nano, micro, and/or macro games share a common prize fund and gaming validation system. The essential concept of the invention is to utilize the common prize fund and gaming and validation system to enable mid- and high-tier prize awards for multiple unique games with small volumes. 
         [0018]    Described are a number of validation mechanisms and methodologies that provide practical details for reliably producing secure pooling of prize funds across multiple games. Although the examples provided herein are primarily related to instant tickets, it is clear that the same methods are applicable to any type of small number specialized games (e.g., American Legion Post drawing) pooling a common prize fund. 
         [0019]    Various embodiments of the present invention relate to the following aspects:
       1. An electronic computerized system for sharing a common prize fund across at least two different instant ticket sub games of a game, wherein:       
 
         [0021]    a first portion of the sub games is assigned winning status and a second portion larger than the first portion is assigned losing status; 
         [0022]    the sub games are digitally generated by a common shuffle of variable indicia; 
         [0023]    the sub games are manufactured in at least one print run to produce physical tickets; 
         [0024]    the respective winning and losing status of each of the sub games is displayed via printed variable indicia hidden under a Scratch-Off Coating (SOC) on unplayed physical tickets; 
         [0025]    the sub games are divided into packs with prize funds balanced by grouping sets of packs into pools, wherein the pools are supportable by an Expected Value (EV) of the game; and 
         [0026]    at least one process creates divergent thread reiterative shuffles during subsequent ticket generation to balance the common prize fund to a predetermined expected value; 
         [0027]    such that a final shuffle for at least one sub game will produce each of a corresponding validation data file, ship file, and stolen pack list, and physical tickets.
       2. The system of aspect 1, wherein an interim variable image file is generated for each sub game.   3. The system of aspect 1, wherein different prize tiers are respectively associated with different sub games.   4. The system of aspect 1, wherein different pack sizes are printed for and are respectively associated with different sub games.   5. The system of aspect 4, wherein when the packs comprise smaller sized packs and larger sized packs, at least one phantom non-winning ticket entry having a phantom ticket number is included in the validation data file and the ship file of at least one smaller sized pack whether or not the phantom ticket number is ever physically printed, thereby ensuring backward compatibility.   6. The system of aspect 5, wherein the at least one phantom non-winning ticket entry is listed as a non-winner in the validation data file.   7. The system of aspect 1, wherein various sub games are respectively associated with different retail pricing.   8. The system of aspect 1, wherein the sub games share a common game number with sub game differentiation achieved by respectively associated different pack numbers.   9. The system of aspect 1, wherein different game numbers are respectively associated with different sub games.   10. The system of aspect 1, wherein respective phantom pack numbers are associated with at least one sub game is in the validation data file and the ship file at the time of printing a first sub game, thereby enabling the respective phantom pack numbers to function as digital place holders for future printing of at least one additional sub game.   11. The system of aspect 10, wherein the phantom pack number place holders that remain unproduced after an associated additional sub game is printed are voided in the already produced ship file and the already produced validation data file by adding any unused pack numbers to a stolen pack list.   12. The system of aspect 1, wherein isolated variable indicia pools are maintained for and to be respectively associated with at least two sub games.   13. The system of aspect 1, wherein at least one sub game variable indicia image file, ship file, and validation data file, is separately generated from the at least one other sub game variable indicia image file, ship file, and validation data file.   14. The system of aspect 13, wherein the at least one sub game variable indicia image file, ship file, and validation file is encrypted for secure storage.   15. The system of aspect 14, wherein the at least one sub game variable indicia image file, ship file, and validation file is encrypted via the Advanced Encryption Standard (AES).   16. The system of aspect 14, wherein the game variable indicia image file, the ship file, and the validation file are encrypted with a separate encryption key different than the variable indicia, the validation data file, and the ship file of the at least one other sub game.   17. The system of aspect 13, wherein a stolen pack list is separately generated from the at least one other sub game variable indicia image file, ship file, and validation data file.   18. The system of aspect 17, wherein the stolen pack list is encrypted for secure storage.   19. The system of aspect 18, wherein the stolen pack list is encrypted via the Advanced Encryption Standard (AES).   20. The system of aspect 17, wherein the stolen pack list is encrypted with a separate encryption key different than the variable indicia, the validation data file, and the ship file of the at least one other sub game.   21. The system of aspect 1, wherein an interim image file is generated for each sub game that contains winning and losing variable indicia for all possible prize levels of the sub game, with multiple variable indicia for each prize fund.   22. The system of aspect 21, wherein winning variable indicia that were generated in excess of what is specified by the prize fund are removed from the interim image file via a plucking algorithm.   23. The system of aspect 1, wherein cleartext validation file data available for audit has at least a portion of its ticket-by-ticket order shuffled.   24. The system of aspect 23, wherein the shuffling of the cleartext validation file data is performed by a Linear Congruential Generator (LCG) or Mersenne Twister algorithm.   25. The system of aspect 1, wherein when the subgames are of smallest size, smaller size and larger size, the pool of all sub games has a size that is determined by the sub game of the smallest size.   26. The system of aspect 1, wherein prize balancing is achieved by a reserved prize fund portion that is created by reserving a small portion of the prize fund from multiple games that is pooled in a common progressive jackpot.   27. The system of aspect 26, wherein the reserved prize fund portion is 1%.       
 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0054]    The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings embodiments which are presently preferred. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. 
           [0055]    In the drawings: 
           [0056]      FIG. 1  is a back elevation view of a representative example of a traditional, prior art lottery-type instant ticket showing a human readable inventory control number and an associated machine readable barcode; 
           [0057]      FIG. 2  is a front elevation view of the representative example of a traditional, prior art lottery-type instant ticket of  FIG. 1  with views of both validation data secured by a SOC and validation data accessible after the SOC is removed; 
           [0058]      FIG. 3  is a block diagram of a representative example of traditional, prior art lottery-type instant tickets as logistically arranged with respect to the activation and validation system; 
           [0059]      FIG. 4  is a block diagram providing a schematic graphical overview of a first embodiment as applied to reliably producing secure pooling of a prize fund across multiple pico, nano, micro, and macro games; 
           [0060]      FIG. 5  is a flowchart providing a schematic graphical overview of the first embodiment of  FIG. 4  as applied to enabling pooling of a prize fund across multiple pico, nano, micro, and macro games via reiterative shuffles in the game generation and shuffle process and how the embodiment seamlessly integrates into the existing prior art production process; 
           [0061]      FIG. 6  is a block diagram providing a schematic graphical overview of a second embodiment for reliably producing secure pooling of a prize fund across multiple pico, nano, micro, and macro games; 
           [0062]      FIG. 7  is a flowchart providing a schematic graphical overview of the first embodiment of  FIG. 5  as applied to enabling pooling of a prize fund across multiple pico, nano, micro and macro games via reiterative shuffles in the game generation and shuffle process as well as segregated variable indicia databases; 
           [0063]      FIG. 8  is a block diagram providing a schematic graphical overview of a third, preferred, embodiment for reliably producing secure pooling of a prize fund across multiple pico, nano, micro, and macro games; 
           [0064]      FIG. 9  is a flowchart providing a schematic graphical overview of the first embodiment of  FIGS. 4 and 5  as applied to enabling pooling of a prize fund across multiple of pico, nano, micro, and macro games via reiterative shuffles in the game generation and shuffle process, as well as segregated variable indicia databases and a plucking algorithm; 
           [0065]      FIG. 10  is an exemplary illustration of a typical, prior art instant ticket prize fund subdivided into pools; 
           [0066]      FIG. 11  is an exemplary illustration of a preferred embodiment according to the present invention of an instant ticket prize fund subdivided into nano pools; and, 
           [0067]      FIG. 12  is a system architecture diagram corresponding to the flowcharts of  FIG. 5 ,  FIG. 7 , and  FIG. 9 . 
       
    
    
     DETAILED DESCRIPTION 
       [0068]    Before describing the present invention, it may be useful to first provide a brief description of the current state of the art of instant ticket production and validation. The concept is to ensure that a common lexicon is established of existing systems prior to describing the present invention. This description of the current state of the art of instant ticket production and validation is provided in the discussions of  FIG. 1  through  FIG. 3 . 
         [0069]      FIG. 1  depicts a representative example of the variable human readable inventory control number  101  and the associated barcode  102  on the back  100 ′ of a traditional macro printed lottery-type instant ticket  100 . As shown in  FIG. 1 , the variable printed human readable inventory control number and the associated barcode are imaged on the ticket back  100 ′ and therefore accessible (by design) to the retailer prior to purchase of the ticket. Also presented in  FIG. 1  is a taxonomy of a typical instant ticket&#39;s human readable inventory control number&#39;s  101  data: starting with a three or four decimal digit game number  103  identifying the game, followed by a variable length pack number  104  (six decimal digits as shown in  FIG. 1 ), a one or two digit modulo check number  105 , and a variable digit ticket number  106  (three decimal digits as shown in  FIG. 1 ) uniquely identifying the ticket in a pack. The taxonomy of the instant ticket&#39;s barcode  102  data is similar to the human readable inventory control number  101  with the barcode  102  and human readable images embodying identical inventory control data  103  through  106 ; however, the barcode  102  can embody other data in addition to the inventory control data. 
         [0070]    As previously stated, the instant ticket inventory control data  103  through  106  typically found on the back  100 ′ of a lottery ticket  100  are accessible via human readable inventory control number  101  and barcode  102  to the retailer and others prior to purchase and play of the ticket. This is because, as its name implies, the instant ticket inventory control data  103  through  106  embodied as human readable inventory control number  101  and barcode  102  indicia are used for tracking the individual ticket through its life cycle of production, warehouse storage, shipping, pack activation by the retailer, and sale to and redemption by the consumer. Therefore, for security reasons against retailer pick-out, there is no cleartext win or lose information embedded in the instant ticket human readable number  101  or machine-readable barcode  102 . However, in some embodiments, win or lose validation information is included in the machine-readable barcode  102 , but this information is always encoded as ciphertext and never accessible in cleartext from an unplayed ticket. 
         [0071]      FIG. 2  depicts representative examples of prior art front elevation views of a virgin (i.e., unplayed) instant lottery ticket  110  and a played instant lottery ticket  110 ′ with all SOC removed. As shown in  FIG. 2 , the variable validation number  111  is imaged beneath the ticket&#39;s SOC  113  and is therefore only accessible after the ticket has been purchased and played. Typically included as part of the validation number  111 , is a series of three or four boxed decimal digits  112  that can be used to verify that the ticket has been properly played during validation and redemption. Again, since the validation number  111  and associated boxed digits  112  are covered by the SOC of unpurchased tickets, this data is theoretically inaccessible until the ticket is purchased and played. In addition to the validation number  111 , human readable game play variable indicia  116  (sometimes referred to herein simply as “indicia”) are also imaged under the SOC, providing the human game play and associated win or lose information. In some embodiments, a validation barcode  115  is also imaged under the SOC, thereby enabling expedited redemption of winning tickets by scanning. As before, this validation barcode  115  is covered by the SOC on unsold tickets, thereby preventing it from being scanned until the ticket is purchased and played. 
         [0072]    Also typically found on both ticket front views  110  and  110 ′ is the imaged ticket number  106 ′ that should be identical to the ticket number  106  ( FIG. 1 ) imaged on the ticket back  100 ′. This double back  100 ′ and front  110  and  110 ′ ( FIG. 2 ) ticket number  106  and  106 ′ imaging is presented to aide the retailer in inventory control, as well as to provide a quality assurance check during production to ensure that the front and back imagers are in synchronization. 
         [0073]    Referring to  FIG. 3 , at the system level  125 , logistical tracking, activation, and validation of lottery-type instant tickets  100  are accomplished by grouping tickets together in packs  126 . The number of tickets per pack (one-hundred as illustrated by the human readable ticket numbers  106 , incrementing from “000” to “099”) will vary depending on the game and ticket retail value, but all tickets  100  in a pack  126  will typically have sequential inventory control numbers  106  and  101  ( FIG. 1 ). There are several reasons for arranging lottery-type instant tickets in packs. A primary reason is that instant tickets  100  ( FIG. 3 ) are ordered and shipped in packs  126  with the pack  126  being the fundamental unit of reconciliation. Since instant tickets  100  are shipped in packs  126 , the pack  126  is also the fundamental unit of activation on the overall instant ticket system  125 —i.e., there is typically no individual (ticket) level of activation; the smallest quantization of activation on a typical instant ticket system  125  is at the pack  126  level. Thus, when a retailer receives a new pack of tickets  126 , he or she must first activate the pack  126  on the system  125  before placing the tickets on sale. Pack  126  level activation thereby enables instant tickets to be shipped via common carrier since un-activated or stolen packs  126  would be automatically flagged on the system  125  with any tickets  100  in the pack  126  flagged when redemption was attempted. 
         [0074]    In addition to shipping, reconciliation and activation, some games may be structured such that there are a specified minimum number and/or types of winners within a pack  126 . In these embodiments, the arrangement of winning tickets is not truly random, but are randomly distributed within a defined structure to ensure that all retailers receive approximately the same number of low- and mid-tier winners per pack as well as to aid in ensuring sufficient cash is on hand for paying low- and mid-tier prizes. 
         [0075]    A given number of packs  126  is then arranged on the system  125  as a pool  129 . The purpose of a pool  129  is to reconcile all low- and mid-tier (and possibly high-tier) prizes into a predetermined prize structure. While the size of a pool  129  can vary from game-to-game, it is essential that a pool  129  be sufficiently large to inhibit tracking unsold winning tickets by the public. 
         [0076]    All of the produced packs  126  for a given game are logged in a digital ship file  127  by the ticket manufacturer and loaded on the system  125  prior to the game being placed on sale. The ship file contains a listing of all the manufactured packs  126  identifying (typically by omission) any pack  126  numbers that were destroyed or omitted in the manufacturing process. As a game is placed on sale the ship file is routinely expanded with information such as: “pack ‘X’ shipped to retailer ‘Y’, “pack ‘X’ activated,” “pack ‘X’ stolen,” etc. Thus, the ship file enables logistical tracking of all manufactured packs  126  in an instant ticket game; however, the ship file  127  does not contain any win or lose information and cannot be linked (without appropriate cryptographic seeds or keys) to the validation data file  128  (sometimes referred to herein as simply the “validation file”). 
         [0077]    The validation file  128  contains the validation codes  111  ( FIG. 2 ) for all tickets within a game with the validation codes  111  effectively providing pointers to the prize value (if any) of a ticket  110  and  110 ′ on the system  125  ( FIG. 3 ). As previously discussed, the validation code  111  ( FIG. 2 ) is effectively inaccessible with unplayed or unsold tickets due to it being covered by SOC  113 . In some embodiments, the validation code is also embodied in a barcode  115  hidden under the SOC  113  that cannot be scanned until the ticket is played; in other embodiments there is additional validation file  128  information (other than inventory control) in the ticket back barcode  102  ( FIG. 1 ) in an encrypted format where the boxed digits  112  ( FIG. 2 ) enable decryption, etc. However, in all embodiments, the cleartext validation code  111  is inaccessible on unplayed or unsold tickets  100 . Therefore, the security of the system  125  ( FIG. 3 ) is derived from the validation file  128  being unassociated with the ship file  127 , as well as the physical unplayed tickets&#39; inventory control information  101  and  102  ( FIG. 1 ). 
         [0078]    Both the ship file  127  ( FIG. 3 ) and the validation file  128  are generated by the instant ticket manufacturer before the tickets are shipped to the lottery. All lottery logistical and validation systems  125  currently require the ship file  127  and validation file  128  to be loaded on the system  125  prior to instant tickets being shipped to retailers and placed on sale. Once loaded onto the system  125 , the basic validation file  128  typically cannot be altered (other than flagged additions—e.g., redeemed tickets in the validation file, stolen packs in the stolen pack list, etc.), thereby ensuring the integrity of the instant ticket game and its predetermined payout. 
         [0079]    Reference will now be made in detail to examples of the invention, one or more embodiments of which are illustrated in the drawings. Each example is provided by way of explanation of the invention, and not meant as a limitation of the invention. For example, features illustrated or described as part of one embodiment, may be used with another embodiment to yield still a further embodiment. This invention includes these and other modifications and variations that come within the scope and spirit of the invention. 
         [0080]    A first embodiment of the present invention for reliably and securely sharing a common prize fund across multiple games is provided in  FIG. 4 . In this first embodiment of the system  150  of  FIG. 4 , an instant ticket prize fund, ship file  127 , and validation file  128  are generated for a standard macro (i.e., ≧10,000,000) instant ticket  110  print run with extra pack entries added to the ship file  127  and validation file  128  for pico (i.e., &lt;10) games  151  and  152  as well as nano (i.e., 10&lt;“nano”≦100) game  153 . Thus, in the embodiment of the system  150 , pico games  151  and  152  and nano game  153  are printed at the end of the standard macro game  110  press run with prize fund sharing and logistical validation file compatibility achieved by simply keeping the same game number  103  ( FIG. 1 ) and format of inventory control numbers  103  through  106  of game  100  or  110  across pico games  151  and  152 , as well as nano game  153 . However, the ticket front display and overprint  110 ,  151 ,  152 , and  153  ( FIG. 4 ) as well as variable indicia (not shown) differ for the pico games  151  and  152 , the nano game  153 , as well as the macro game  110 . The underlining assumption is that most consumers would not detect (or care) about the shared inventory control and validation format of their pico games  151  and  152  and nano game  153  with a macro game  110 , especially when it is realized that the shared format enables their pico games  151  and  152  and nano game  153  to share the prize fund enabled by the large volume of tickets of the macro game  110  with an associated higher prize fund. Thus, by inserting pico games  151  and  152  and nano game  153  into a prize fund pool for the macro game  110 , the pico games  151  and  152  and nano game  153  can offer better odds (e.g., 1:5 to win a prize) and a higher payout (e.g., top prize of $50,000 as illustrated in  151  and  152 ) than would be possible with pico, nano, or micro games, each with its own discrete prize fund. 
         [0081]    Thus, pico games  151  and  152  and nano game  153  become a part of the prize fund of the larger macro game  110  by simply occupying special pack numbers  104  and ticket numbers  106  ( FIG. 1 ) in the ship file  127  and validation data file  128  for the macro game  110  ( FIG. 4 ). These pack numbers  104  and ticket numbers  106  ( FIG. 1 ) are reserved for the pico games  151  and  152  and nano game  153  ( FIG. 4 ) at the time the prize fund of the macro game  110  is generated. Consequently, a single pack number  104  ( FIG. 1 ) would represent the entire production of pico game  151  ( FIG. 4 ) and a second single pack number  104  ( FIG. 1 ) would represent the entire production of the pico game  152  ( FIG. 4 ) with several pack numbers  104  ( FIG. 1 ) representing the nano game  153  ( FIG. 4 ). Lottery retailer validation of winning tickets would then be accomplished by the usual process with the central site system processing the tickets for the pico games  151  and  152  and nano game  153  as winning tickets from the larger prize fund of the macro game  110 . Different prize levels (e.g., “$1,000,000” top prize  154  for the macro game  110  and “$50,000” top prize  155  for the pico games  151  and  152 ) are accommodated by reserving multiple prize levels in the overall prize fund (e.g., “$1,000,000”  154  for the macro game  110  and “$50,000”  155  for the pico games  151  and  152 ), some of which may not be used in some sub games or may not be awarded prizes at all. For example, if the “$50,000” top prize  155  can be exclusive to the pico games  151  and  152  and the prize generation shuffle does not select a top prize winner for the tickets associated with the pico games, then the $50,000 top prize  155  will not be awarded. These reserved prize levels for different games need not only be associated with high-tier prizes. For example, a “Lucky 7&#39;s” themed game typically features a prize award of “$7” while a “Crazy 8&#39;s” game typically features a prize award of “$8”. If the macro game were “Lucky 7&#39;s” with an associated nano game being “Crazy 8&#39;s,” the “$7” and “$8” prizes would only appear in the appropriately themed game. 
         [0082]    In one embodiment, some prize levels are simply withheld (i.e., programmed to never be selected for some sub games) by flagging certain pack numbers as not eligible for certain prizes. For example, the pico games  151  and  152  are illustrated with a top prize  155  of $50,000, with the macro game  110  having a top prize  154  of $1,000,000. In this embodiment, the $1,000,000 top prize  154  would simply be flagged as ineligible on the system  150  for the pico games  151  and  152  (and therefore not imaged), with the $50,000 prize also occurring in the macro game  110  as a high-tier prize, but not the highest-tier prize for that game. 
         [0083]    In a preferred embodiment, some prizes will only be allocated for some sub games—e.g., the $50,000 top prize  155  for the pico games  151  and  152 . In this embodiment, the system  150  prize fund generator will flag any missing prize tier awards (e.g., the $50,000 top prize  155  of  FIG. 4  in the previous example) and balance the overall prize fund to the desired payout (e.g., 65% of sales) by increasing the number of winning low-tier and mid-tier tickets in the overall prize fund. Conversely, if the system  150  prize fund generator shuffle happens to award a significant high-tier prize to a pico game  151  or  152  or to a nano game  153 , the number of winning low-tier and mid-tier tickets in the overall prize fund will automatically be reduced to balance the overall payout to the desired amount. This preferred embodiment thereby enables the system  150  prize fund generator to feedback and analyze its own shuffle output and correspondingly award low-tier and mid-tier prizes along divergent threads once significant prize awards are known so as to achieve the same desired payout. 
         [0084]    As would be apparent to one skilled in the art in view of the present disclosure, there are many possible combinations of macro, micro, nano, and pico games sharing a common prize fund that may omit various categories—e.g., macro and nano games only, or macro, nano, and pico games, etc. In some embodiments, there may be a sufficient number of nano and/or pico games that there are no macro or micro games sharing the common prize fund. These embodiments are desirable, assuming that a sufficiently large enough volume of various nano and/or pico games is available to sustain an overall prize fund with significant prizes. 
         [0085]      FIG. 5  illustrates the previous preferred embodiment of the system  150  in a flowchart format  150 ′. Existing standard practice game generation functionality is shown along with the preferred invention addition of divergent thread reiterative shuffles highlighted in the dashed area  229 , representing additional digital computer processing according to this invention. As shown in the figure, the instant ticket game starts with generation of working papers (i.e., per a contract between the lottery and the instant ticket provider, as well as any pico and nano game purchasers) and associated ticket artwork  225  that the lottery and provider agree and sign. The executed working papers  225  are then used to specify game generation  226  programming (i.e., the digital variable indicia imaging of instant tickets and associated winner or loser distribution), as well as the manufacture of any fixed plates  227  (e.g., flexographic, offset, etc.) used to possibly print the display and security areas of instant tickets. After game generation  226  is completed, variable indicia (i.e., the numbers, symbols, artwork, etc., that reveal if a ticket is a winner after the SOC is removed) are digitally imaged  228  for each instant ticket of the print run and saved. 
         [0086]    At this point, the additional digital computer processing  229  enabled by the disclosed invention is added to the instant ticket production process and system  150 ′. First, the previously generated digital indicia  228  is audited  230  to specifically determine if any pico and nano games  151  through  153  ( FIG. 4 ) included in the game generation  226  ( FIG. 5 ) has been awarded a significant prize award with the initial shuffle such that the prize award would result in the macro game  110  ( FIG. 4 ) having an insufficiently financed prize fund with respect to its Expected Value (EV), also known as “total payout”—i.e., the actual payout of the macro game prize fund would be less than specified in the executed working papers  225  ( FIG. 5 ). Depending on the outcome of this computational audit and evaluation  230 , the logic thread of the game generation process will be directed down one of two logical forks. One fork (i.e., “Yes”— 231  and  232 ) is evoked if a pico or nano game  151  through  153  ( FIG. 4 ) has been dealt a significant prize, and the other fork (i.e., “No”— 233 ,  FIG. 5 ) is evoked if no significant prize was awarded in a pico or nano game  151  through  153  ( FIG. 5 ). 
         [0087]    Assuming a pico or nano game  151  through  153  ( FIG. 4 ) has been dealt a significant prize, the logical thread proceeds with step  231  ( FIG. 5 ) reducing or plucking the number of low-tier and mid-tier winners in the other game(s) to exactly balance the overall prize fund to match the EV. This balancing process is achieved by reducing the total number of low-tier and mid-tier winners in the macro game  110  ( FIG. 4 ), such that the overall prize fund EV pays out as specified. The reduction process causes either the elimination of some prizes and/or the reduction of some prizes from higher tier to lower tier winners. Either way, the reduction in winners would have an insignificant impact on the overall game play style due to the large number of tickets printed for the macro game  110  combined with any other games (that did not encounter a significant prize award) compared to the relatively small number of reductions. 
         [0088]    In one embodiment, the reduction process in winners of the other game(s) is executed on the post-shuffled arrangement of winners in the other game(s) with the selected reduced winning ticket variable indicia either being substituted for non-winning or reduced prize value variable indicia. In a second, preferred embodiment, the reduction process in winners of the other game(s) is executed on the pre-shuffled prizes to be awarded in the macro game  110 —i.e., the raw specified number of winners for each prize tier for the entire game prior to being assigned to a specific ticket. The second embodiment is preferred, since it theoretically ensures a more homogeneous distribution of winners throughout the other game(s), as well as compliance with any non-random prize distributions as specified by the working papers. Assuming the second preferred embodiment is implemented, once the reduced number of winners process is completed for the other game(s) in which the nonstandard significant win did not occur, a second-generation digital shuffle  232  occurs ( FIG. 5 ), allocating the revised number of winners to the tickets in the other games (i.e., no revised shuffle for the pico or nano game that received the significant prize) with the resulting digitally imaged data  235  archived for the printing process or preferably routed for a second prize fund balancing audit  133 . Thus, the overall prize fund pays out to its EV by revising the number of winners in sub games without a nonstandard significant win. 
         [0089]    If no pico or nano game  151  through  153  ( FIG. 4 ) were dealt a significant prize, the logical thread proceeds with secondary audit  233  ( FIG. 5 ), which audits and reviews the overall prize fund with respect to the specified EV to determine if the prize fund needed adjustment to properly balance to the specifications of the working papers  225 . Depending on the outcome of this review, the logic thread of the game generation process will now be directed down a second logical fork unique to this invention. One fork (i.e., “Yes”— 234 ) is evoked if the EV of all of the pico and/or nano game(s)  151  through  153  ( FIG. 4 ) significantly matches the EV as specified in the working papers  225  ( FIG. 5 ). The other fork (i.e., “No”— 241  and  242 ) is evoked if the pseudorandom distribution of the shuffle did not include a sufficient number of winners to ensure that the pico and/or nano game(s)  151  through  153  ( FIG. 4 ) or if a modified (i.e., plucked or reshuffled) macro game from steps  231  and  232  pays out to expected EVs. In the event the fork is selected where the prize fund balances out to the EV (i.e., “Yes”— 234 ), then no modifications would be required and the existing shuffle(s)  234  of the digitally imaged variable indicia is archived for the printing process  235 . However, if the step  233  determines that in order for the prize fund to balance out to the EV, the low-tier and mid-tier prizes of the other sub game(s) must be adjusted via a process (i.e., “No”) to increase the number of low-tier and mid-tier winners in these game(s) to balance the overall prize fund to match the EV via step  241  which audits and reviews all games in the generation to determine where the anomaly occurred. This type of anomaly can occur, since this invention essentially spreads a common prize fund across multiple games where the normal shuffle may result in a distribution that is incompatible with the specifications of the working papers  225  for each game. Regardless of the reason, once it is determined at step  233  that all of the games in the generation do not match the EV, the games are audited at step  241  to find the anomaly. Once the anomaly is determined, procedure at step  241  either modifies the winners in the post-shuffled arrangement of winners (one embodiment) or reduces the number of winners in the pre-shuffled prizes to be awarded in the macro game—i.e., the raw specified number of winners for each prize tier for the entire game prior to being assigned to a specific ticket (the second, preferred embodiment). The second embodiment is preferred, since it theoretically ensures a more homogeneous distribution of winners throughout the other game(s), as well as compliance with any non-random prize distributions as specified by the working papers. Assuming the second, preferred embodiment is implemented, once the revised number of winners is determined for the game(s), a second-generation digital shuffle occurs at step  242 , allocating the revised number of winners to the tickets in the games, with the resulting digitally imaged variable indicia data archived for the printing process at step  235 . 
         [0090]    Once the review  230  of the pico or nano game(s) and possible adjustment (steps  231 ,  232 ,  241 , and  242 ) are completed and archived at step  235 , the instant ticket production process returns to the existing standard of performing a game audit at step  236  on the archived digitally imaged indicia data at step  235 , with the audited data ultimately transmitted to on-press digital images for printing the instant tickets at step  237  in association with the associated fixed plates generated at the start of this process at step  227 . When the physical printing of step  237  is completed, a final audit of the printed product is conducted at step  238  with the correlated ship and validation files generated at step  239  after the audit. Once the final audit at step  238  is complete and the ship and validation files are generated at step  239 , the physical tickets printed at step  237  and the ship and validation files of step  239  are dispatched to the lottery at step  240 . 
         [0091]    The preferred basic embodiments of the system  150  and  150 ′ have the advantage of enabling differing odds for pico and/or nano games sharing a common prize fund with a macro game. As explained herein, these differing odds can be higher or lower than the macro game, depending on the specifications—e.g., a higher ticket price for the pico or nano games resulting in better payoff odds. The differing odds with potentially high top prizes become possible by the addition of the divergent thread reiterative shuffles invention as described regarding the process  229 . 
         [0092]    It should also be noted, that with the above embodiments of the system  150  and  150 ′, the pack sizes may differ from the macro to the nano and pico sub games. Any differences in pack sizes can be accommodated in the ship and validation files by simply inserting phantom ticket entries (i.e., digital tickets that are never physically printed) that are all non-winners to make up the difference between the smaller pack(s) sizes and the largest pack size—e.g., pico sub games with only ten tickets to a pack would include forty phantom ticket entries in the ship and validation files for each pack, assuming that the largest pack size in the prize fund were fifty tickets. This addition of non-winning phantom ticket entries is necessary to ensure backward compatibility with existing lottery validation systems that assume a common size for all packs with the same game number  103  ( FIG. 1 ). 
         [0093]    While the embodiments of the system  150  and  150 ′ have the advantage of simplicity in implementation, these embodiments also have numerous potential disadvantages primarily related to manufacturing and logistics. For example, the embodiments of the system  150  and  150 ′ require that any pico, nano, or micro tickets be printed at the same time as a macro press run to ensure an accurate ship file. From a manufacturing perspective, this may be considered inefficient and problematic. Printing presses designed to extract maximum efficiencies from macro press runs rarely can be changed economically to print micro, nano, or pico game runs—with smaller runs being more readily accomplished with different printing technology. Additionally, there are potential problems with printing differently themed variable indicia and display overprints for the micro, nano, or pico games—e.g., the “BONUS $50”  116  ( FIG. 2 ) display indicia feature of the macro game  110  would be inconsistent if utilized with the custom birthday card themed pico games  151  and  152  ( FIG. 4 ). Aside from printing, the embodiments of the system  150  and  150 ′ also require separate handling and distribution for micro, nano, or pico games that may not be readily compatible with the handling and distribution employed for macro runs. 
         [0094]    Another system embodiment  160  of  FIG. 6  overcomes many of the potential shortcomings of the first embodiments of the system  150  and  150 ′ ( FIG. 4  and  FIG. 5 ) associated with manufacturing. Principally, when the ship file  127 ′ and the validation file  128 ′ ( FIG. 6 ) are generated, extra packs or possibly pools are digitally created and registered virtually in the ship file  161  and the validation file  162 . However, these virtual ship file  161  and validation file  162  entries are simply digital placeholders for future pico sub games  151  and  152  and/or nano sub game  153  and are not physically printed at the same time as the macro game  110 , thereby only sharing the same prize fund. The generation of a complete ship file  127 ′ and validation file  128 ′ including virtual placeholder entries  161  and  162  allows the ship file  127 ′ and validation file  128 ′ to be loaded onto a legacy instant ticket validation system (e.g., system  125 — FIG. 3 ), thereby enabling immediate sales for the macro sub game  110  ( FIG. 6 ) and support for the shared prize fund, even if the pico sub games  151  and  152  and/or nano sub game  153  are not yet printed. Thus, the micro, nano or pico sub games are free to either be generated at the same time as the macro game  110  via a different printing system or sometime in the future with the smaller games&#39; shared prize fund being buttressed by sales of the macro game  110 . 
         [0095]    By printing the pico sub games  151  and  152  and the nano sub game  153  at a later time and/or on a different press than the macro game  110 , the problem of printing press efficiencies is greatly mitigated, since the press hardware and procedures that are optimum for the macro game  110  do not necessarily need to be employed for the micro or smaller sub games (e.g., the sub games  151  through  153 ) with the micro or smaller sub games utilizing printing technologies better suited to their smaller press run sizes. Furthermore, printing micro, nano, or pico print runs at a later time also allows for each sub game to be packaged and shipped separately with optimal equipment and packaging for the sub game size, thereby encountering no inefficiencies or reducing inefficiencies that typically arise when packaging and shipping micro, nano, or pico sub games on a macro sub game packaging and shipping system. Any pico, nano, or micro packs that are either not printed or destroyed during future production are voided from the preexisting ship file  127 ′ by logging those packs as stolen and listed in a stolen pack list on the validation system  160 . 
         [0096]    With further reference to  FIG. 6 , problems associated with printing differently themed indicia for the macro, micro, nano, or pico games are also mitigated with the embodiment of the system  160 , with the implementation of virtual placeholder ship entries  161  and validation entries  162 . With this embodiment, separate variable indicia imaging files  164  can be created from a pool of appropriately themed variable indicia for the given pico sub game  166 , nano sub game  167 , or micro sub games, with each sub game&#39;s indicia pool isolated from the others, thereby ensuring consistency within a sub game. For example, if a given ticket of a pico sub game&#39;s shared prize fund&#39;s validation file  162  calls for a $5 winner, the associated pico generation system  168  will simply fetch suitable winning $5 indicia from the isolated pico pool  166  with the assurance that the fetched indicia will be compatible with the sub game&#39;s theme—e.g., birthday party themed indicia  166  for the pico games  151  and  152 . Likewise, if a given ticket of a nano sub game&#39;s validation file  162  calls for a $5 winner, the associated nano generation system  169  would fetch suitable winning $5 indicia from the different nano pool  167 , thereby providing fetched indicia with ensured compatibility with the sub game&#39;s theme. 
         [0097]    In one embodiment, the generation of the sub games&#39; variable indicia image files occurs as part of the same process as the macro sub game shuffle. This embodiment essentially incorporates the same processes as illustrated in the system  150 ′ of  FIG. 5  with one exception being the ultimately archived digitally imaged variable indicia data  235  are structured to contain multiple different databases—i.e., as illustrated in  FIG. 7 , there is one database for the macro game  228  and individual databases  250  for each of the micro, nano, or pico games that share the common prize fund highlighted in dashed box  229 ′ (also part of the invention). With this embodiment, the sub games&#39; variable indicia image file  164 , ship file  161 , and validation file  162  ( FIG. 6 ) generated in advance would be encrypted, preferably with a low-overhead symmetrical encryption algorithm, such as with the Advanced Encryption Standard (AES), well known to those skilled in this art, thereby reducing security threats resulting from these linked data being stored until the tickets are physically printed. 
         [0098]    This relatively long term storage of any micro, nano, and pico sub games&#39; variable indicia image file  164 , ship file  161 , and validation file  162  potentially can be problematic, since the ship file  161  and validation file  162  are generated at the same time as when the macro sub game is physically printed. The encryption of the indicia image data  235  provides additional security to mitigate this risk. In a preferred embodiment, the encryption keying of the micro, nano, and/or pico games would be implemented with separate encryption keys. 
         [0099]    In another embodiment, the actual generation of the sub games&#39; variable indicia image files  164  could occur at the time of printing the pico, nano, and/or micro sub games, rather than at the time the ship files  127 ′ and  161  and validation files  128 ′ and  163  are generated. This embodiment has the advantage of reducing potential security problems that could arise from maintaining an image file  164  with human readable win or lose variable indicia linked at schematically indicated at step  165  ( FIG. 6 ) to a portion of a validation file  162  on a server over an extended time period with multiple sub games accessing the file. However, both of these embodiments have the potential disadvantages of requiring processing at the time of the press run, which can introduce errors or overload the production system. Generating a variable indicia file real time or generating it in advance and encrypting it could be problematic for both internal and external audits that are typically required by lotteries for instant ticket games. When it is realized that since the shared prize fund employs multiple games that may require multiple independent internal and external audits at different times, the potential audit problem&#39;s complexity grows practically exponentially. 
         [0100]    In the preferred embodiment of the system  175  of  FIG. 8 , both of the potential problems of real time print processing and auditing of the games are solved by first generating at step  168  an interim image file  176  for each game that contains winning and losing variable indicia for all possible prize levels of the game, with multiple variable indicia arrangements for each prize category to ensure the appearance of variability from ticket to ticket (not shown in  FIG. 8 ). By generating an interim image file  176  with all possible game outcomes prior to a game&#39;s press run, both internal and external audits can be conducted to ensure that winning and non-winning variable indicia are correct. Since this interim image file  176  includes all possible outcomes, its persistence on servers over time poses no security risks, because the actual win or lose imaging would be performed by a separate pluck process at step  177  that would only execute during the game&#39;s printing process to generate the variable indicia imaging file  164  real time. The structure of plucking algorithms used at step  177  are inherently less complex than game indicia generation algorithms used at step  168 , hence the real time execution of a pluck algorithm is less burdensome on the system and the processes of auditing and checking the pluck algorithm at step  177  to ensure proper prize selection are therefore greatly simplified. 
         [0101]    In the context of this invention, the terms “pluck algorithm” or “plucking algorithm” refer to an algorithm that selectively removes or “plucks” excessive winning ticket images from a given game. The general concept is to initially generate more prizes in a given game than are specified by the working papers  225  ( FIG. 9 ), thereby allowing for excessive prizes to be culled (i.e., plucked) from the database at a later time. Traditionally, plucking algorithms are utilized to compensate for waste during the printing process—i.e., extra (above the number specified by the working papers) winning tickets are imaged to ensure that a sufficient number of winning tickets are printed after press out-of-register and other printing errors responsible for press waste are taken into consideration. The overall concept is that the plucking algorithm culls excess winners (above the number specified by the working papers), ensuring a set of physically printed tickets with winners exactly within the specifications of the working papers  225 . However, with this invention, plucking algorithms are employed to balance the micro, nano, or pico game winners to a specified outcome. 
         [0102]    A flowchart  175 ′ associated with a preferred embodiment of the system  175  of  FIG. 8  is provided in  FIG. 9 . As illustrated in the flowchart  175 ′, the addition of the plucking algorithm  251  allows the micro, nano, and pico databases  250  to be accessed at different times than during the macro print run. The balancing of the prize funds at steps  230  through  234  and  241 ,  242 ,  235  still occurs prior to the macro print run, with the variable indicia imaging occurring at a later time. 
         [0103]    Embodiments of the system  160  ( FIG. 6 ) and the system  175  ( FIG. 8 ) both illustrate links  163  between the inventory control data file  161  and the validation data file  162 , as well as links  165  between the validation data file  162  and the variable indicia imager data file  164 . From a security perspective, these links  163  and  165  are potentially problematic. The same potential security problems associated with multiple games accessing variable indicia imaging file(s)  164  as a persistent image on a server ahead of a press run(s) are present with links  163  between the ship file data  161  and the validation file data  162 , as well as the links  165  between the validation file data  162  and the variable indicia imager file data  164 . With the presently preferred embodiment  175 , the variable indicia imager file data  164  are plucked real time and therefore, the security risks associated with the variable indicia imager file data  164  and its link  165  to the validation file data  162  are mitigated. However, the link  163  between the inventory control ship file data  161  and the validation file data  162  still persists in the preferred embodiment of system  175 . If accessed by nefarious personnel, this link  163  could be exploited to determine winning tickets. Both the ship file  161  and the validation file  162  could be encrypted, with access to the decryption key closely guarded, but then internal and external audits potentially could prove problematic. In a preferred embodiment, the ship file data  161  are stored as plaintext and only the validation file data  162  are stored as ciphertext. This embodiment has the advantage of the plaintext ship file data  161  remaining accessible for audits with the link  163  to the validation file data  162  mitigated, since the data  162  are stored as ciphertext. If it is necessary to audit the validation file data  162 , a separate cleartext audit validation file would be decrypted with its link  163  to the ship file data  161  broken and the validation file ticket-by-ticket order shuffled, preferably by a Linear Congruential Generator (LCG) or Mersenne Twister algorithm, both well known to those skilled in the art such that the original arrangement of the validation file ticket-by-ticket order cannot be deduced unless the shuffle algorithm&#39;s starting seed is known. Thus, with a special detached and shuffled validation file (i.e., without link  163 ) available for audit, the exact number of winners and losers may be readily audited, with the auditor unable to deduce the associated inventory control data since the link was broken, thereby maintaining security. As would be apparent to one skilled in the art in view of this disclosure, it may be necessary to redact portions of the validation file pointer information in the audit file, depending on the security requirements. 
         [0104]    With standard instant ticket print runs, the prize fund itself is comprised of a percentage (e.g., 65%) of the total retail value of a game&#39;s print run—e.g., 10 million tickets with a retail value of $1 each—would have a 65% prize fund of $6,500,000.  FIG. 10  provides an exemplary illustration of this typical, prior art example 200 with: 10 million tickets printed, at a retail cost of $1 each, with a 65% prize fund of $6.5 million, with overall odds of winning≈1:6, and logistically broken down into ten pools of 1 million tickets each. The overall prize structure  201  for the entire game features ten prize levels ranging from $2 to $50,000. This overall prize structure is further broken down into ten pools  202  of one million tickets each. Thus, for a standard instant ticket run, the prizes are mostly evenly distributed among pools  202  with large top prize(s) being inserted into one or more pools. While the prize structure can vary from game-to-game, the essential concept is that a prize fund is established based on a percentage of the total projected retail value of the game with a portion of the prize fund ($645,000 in pool  202 ) being allocated to each pool (without a top prize present in every pool). 
         [0105]    As a practical matter, instant lottery games rarely sell completely out, thus a portion of the anticipated revenue to the prize fund is usually missing. Typically, lotteries attempt to sell out in levels of pool quantization, thereby enabling ready balancing of the prize fund at the pool level with unsold pool prize payouts and revenue being deleted from the ledger. 
         [0106]    In one embodiment, this general concept of balancing by pool can be extended to provide support for macro, micro, nano, and pico sized games. By reducing the pool size (e.g., one hundred) to accommodate the smallest game, each pool can represent a different game with revenue all rolled up into a shared common prize fund for the multiple games and sub games.  FIG. 11  provides an example according to the present invention of one possible common prize fund supporting nano pool sizes, where multiple different games prizes are supported by at least one pool each. As shown in the figure, the same basic prize fund  203  as in  FIG. 10  can be spread over multiple micro, nano, and pico games with each game buying into the prize fund via nano pools  204 . In this example, the actual buy-in per game would be $42 with prizes distributed over multiple pools. 
         [0107]    In another embodiment, the balancing can be achieved by reserving a small portion of the prize fund (e.g., 1%, 0.1%, etc.) from multiple games and sub games, wherein the reserved portion is pooled in a common progressive jackpot. This progressive jackpot could be similar to slot machines (e.g., U.S. Pat. Nos. 5,048,833; 5,280,909; 5,249,800; and, 8,348,754), where a macro, micro, nano, or pico instant ticket&#39;s top prize entitles the winner to a percentage of the accumulated progressive jackpot from multiple games and sub games. The common progressive jackpot value could be advertised by lotteries as an enticement for ticket sales with the winner of a “jackpot” in a macro, micro, nano, or pico instant ticket game entitling the holder to a percentage of the overall jackpot (e.g., 10%, 20%, 50%, or 100%). In a preferred embodiment, the percentage of the progressive jackpot that the winner receives is determined by the ticket retail price. 
         [0108]      FIGS. 5, 7, 9, and 12  taken together, illustrate scalable prize funds enhancement embodiments, with a common corresponding system architecture flowchart diagram  300  illustrated in  FIG. 12 . In these figures, the added functionality unique to scalable prize funds enhancements is shown in dashed areas  229  and  229 ′ with the typical existing game generation functionality outside of the dashed areas. 
         [0109]    Referring to  FIG. 12 , the process begins, as previously with the flowcharts of  FIGS. 5, 7 and 9 , with generation of working papers and associated ticket artwork  225  that the lottery and any other purchasers agree and sign. The executed working papers and artwork  225  are then used to specify game generation programming at step  226 . After game generation at step  226  is completed, variable indicia are digitally imaged at step  228  for each instant ticket of the print run and saved. 
         [0110]    At this point, the additional digital computer processing  229  enabled by the disclosed invention is added to the instant ticket production process. This process can be conducted in a physically common server and Central Processing Unit (CPU) as the game generation at step  226  or executed on a separate server and CPU. Regardless of the physical implementation, the CPU  301  receives the generated game variable indicia and performs an audit to ultimately balance the prize fund. The logic associated with this prize fund balancing is resident in memory  302  as is the logic to reduce, keep, or increase the number of winners in the linked micro, nano, and/or pico games or sub games. After the audit and prize fund logic completes, the CPU  301  optionally (i.e., if the prize fund did not initially balance) completes a second game generation (logic also stored in memory  302 ) with the resulting modified digital variable indicia stored in database  235 . This second game generation digital variable indicia database  235  is then audited at step  236  in a traditional process well known within the art with all other processes (e.g., physical printing, generation of ship file, etc.), proceeding as is standard for instant ticket manufacturing step  304 . 
         [0111]    In alternative and preferred embodiments of processing  229 ′, multiple micro, nano, and pico digital indicia databases  250  are stored separately for future print runs, possibly seeded with extra winning variable indicia that can be culled or plucked at step  303  at the time of printing. The memory associated with the plucking algorithm at step  303  ideally is isolated from the memory of the reiterative game generation threads in memory  302  or in other game generation processes at step  228 . 
         [0112]    Of course, there are other variations of the disclosed embodiments (e.g., prize fund comprised exclusively of a large number of pico and nano games with no supporting macro game, pack size of one ticket, shared prize fund between multiple macro games, etc.) that would be apparent to anyone skilled in the art in view of this disclosure.