Off-line remote lottery system

<u style="single">Background of the invention</u>The present invention generally relates to remote gaming systems, in particular a lottery game typically embodied in a ticket (lottery, lottery ticket) with multiple winning opportunities representing a single result presented by a lottery institution. For example, a lottery system performed as an "electronic lottery" on a game computer such as a dedicated handheld device or a programmed general-purpose personal computer, which has traditionally been physically or electronically connected to the lottery system network during play. The result of the lottery can be shown to the player anywhere, with the same convenience as a typical paper scratch-off lottery, without the need for a game computer that had to be used. It is about a lottery system that brings more play value and increases income for lottery institutions. In one example of a common traditional paper instant lottery (speed lottery) system, a computer produces a randomized prize data stream with finitely continuous win / lose results. Each result is assigned to a lottery ticket, and each lottery ticket has one or more gaming opportunities that result in the assigned result. Players cannot change the outcome of the lottery, they simply scrape off a given spot in the lottery according to the rules of the game to see the outcome. The lottery includes a means of determining the outcome of the win / loss and the status of the prize, and a display that gives the player the type of prize (eg, cash or free lottery). The total amount of winning results for any randomized prize data stream is a given percentage of the total revenue that will be formed by the total sales of the lottery that incorporates that particular randomized prize data stream. Equivalent to the expenditure of. Each lottery is assigned a unique lottery ticket serial number for determining the validity of the lottery ticket having a specific result and a batch number for linking the lottery ticket to the master carton. A certain amount of lottery groups are treasure It will be shipped to the same store. The lottery ticket serial number is usually hidden under the metal leaf of the lottery ticket. The batch number can generally be viewed in bar code format on top of the lottery. All lottery tickets in a given master carton are part of the same lottery ticket lot and are sold at the same price points. Each master carton is labeled with a unique master carton serial number that is tracked by the lottery agency's central computer. The central computer also stores every lottery ticket serial number and the results associated with that lottery. When the speed lottery is sold to the customer, the lottery dealer sends the master carton serial number to the lottery central computer via the online agent terminal, thereby activating all of the paper speed lottery of each master carton. To be ready for use). This action makes all of the lottery serial numbers in the master carton available, typically debiting the lottery dealer's lottery bank account automatically only the wholesale price of the master carton within a certain period of time. To redeem a winning paper lottery ticket, the player presents it to the redemption agent at the lottery store or lottery office, or mails the lottery ticket for redemption. To carry out the redemption process, the redemption agent scans the bar code on the lottery representing the batch serial number of the lottery with the bar code scanner of the agent terminal. The lottery ticket agent also inputs the lottery serial number into the agent terminal. These lottery numbers are sent to the central computer for validity. When the central computer receives a validity check request, it uses a specific lottery and batch serial number to ensure that the lottery is derived from a ready-to-use master carton. Launch an online validity judgment program that queries the lottery ticket value database. If the lottery ticket value database confirms the payment, the validity determination program will either pay the lottery dealer cash to that player, or another prize (eg, another prize). Approve to give a free lottery). Other paper speed lottery systems do not have a central lottery computer to manage the system. The lottery dealer simply buys the lottery from the printer, sells it to the player, and handles the entire status of validity judgment and payment to the winner. Paper speed lottery systems have some drawbacks. These include, for example, lottery ticket printing costs, physical inventory costs, unsold lottery costs to lottery agencies and retailers, inability to effectively offer low-priced games (such as quarters and 10 cents), games for players. Includes limited choices and the drawbacks of paper lottery that attracts low-income earners. As an alternative to paper speed lottery, a system that replicates speed lottery on computer terminals and game consoles has been devised. One example is US Pat. No. 5,324, Shown in No. 035, the publication discloses an online video game system composed of a plurality of slave terminals, a plurality of master arithmetic processing units, and a central game processing unit. A plurality of slave terminals are network-connected to each master arithmetic processing unit, and all of the master arithmetic processing units are network-connected to the central game processing unit. The central game processor downloads fixed pool gameplay to each master arithmetic processor. The slave terminal requests gameplay from the fixed pool of the master arithmetic processing unit. A group of slave terminals connected to a particular master processing unit indicates the possibility of purchasing one of the remaining winning plays in the pool to give players on various slave terminals a competitive element. To do. Therefore, the player at each slave terminal can have other competitors buy some of the remaining out-of-plays and wait for them to be more likely to buy a winning play. This system can produce paper speed lottery in video format, but the main drawback is that it is a networked online system. Any play (result) requested by the slave terminal must be downloaded online from the master processing unit. For this reason, the system is limited in that players can only participate in lottery play in certain locations. Another Online Video Game System US Pat. No. 4,652, Disclosure in 998. The system consists of multiple remote terminals networked to a central controller that creates a prize pool based on pool seeds sent to a random number generator. The central controller divides the prize pool into mini-pools, each with a known amount of low-end prize value (eg, all commodities are $ 25 or less). A certain number of jackpots are assigned to the mini-pools, some mini-pools have jackpots and others do not. A mini-pool is assigned to each terminal for each game played on the terminal if necessary. The remote terminal has means for randomizing each minipool assigned to the terminal using a minipool seed provided by a central controller that sends each minipool to a random number generator using a random algorithm. When the central processing unit allocates all the mini pools in the pool, it forms a new pool. After the player has played enough games on a given remote terminal to consume the entire minipool, it is connected to a central controller and assigned a new minipool. This system also has major limitations. That is, it is unscrupulous because the minipool prize structure is assigned to each remote terminal in a "dynamic state", that is, it is assigned a result that the remote terminal can use before the player participates in play. Various security measures need to be put in place at the remote terminal to prevent players from "preempting" by "hacking" the machine and determining the outcome sequence for a given minipool. Players can also know that a jackpot will appear in the game they are playing at any point in the minipool, and can suspend play until a favorable result is obtained. Therefore, due to this feature, such a system is not suitable for offline arrays where players are free to buy "lottery" and view the results anywhere. Therefore, the player can enjoy the game having the result defined in advance by the lottery institution or the like on the game device without having to physically or electronically link to the central computer of the lottery institution during play.<u style="single">Abstract of the invention</u>Therefore, a main object of the present invention is to play a speed "lottery" or pseudo-selection game having a predetermined result on a game computer (where the game computer may be any personal computer, personal digital assistant, or the like. , Hereafter referred to as the Handheld Lottery Ticket Viewer (HTV)), which allows players to participate in the lottery anywhere, just like the paper speed lottery, and provides a full play value to the HTV computer from beginning to end. To provide a lottery system like that provided through a simulation game. A further object of the present invention is a lottery system to prepare for duplication of results on an HTV, in which the results are recorded on a lottery central computer (LCC) along with the ID data of the HTV in order to eliminate the need for confidentiality of the HTV. To provide a stored lottery system. A further object of the present invention is to provide a lottery system in which the results can be duplicated on an HTV and redeemed at a lottery store with the same convenience as a paper speed lottery. A further object of the present invention is to provide a lottery system that provides a portable supply in exchange for the purchase of results via any interactive communication network such as the Internet or a mere telephone. A further object of the present invention is to provide lottery institutions with increased sales and profits, more competitive and entertaining alternatives and lottery systems that provide higher customer satisfaction. A further object of the present invention is to provide a lottery system that eliminates printing costs, inventory costs and delays in cash circulation associated with paper speed lottery. A further object of the present invention is to provide a lottery system that eliminates the disposal cost associated with a paper speed lottery. A further object of the present invention is to provide a lottery system in which the HTV provides a longer play time than a paper speed lottery. Further, a further object of the present invention is that many games are played on HTV so that people with poor insight can play the games more easily. It is to provide a lottery system that can be offered in a multi-branch format that produces a number of game formats. A further object of the present invention is to provide a lottery system for expanding the play area through sales of speed lottery-type games in places where sales of paper lottery are not practical, such as restaurants. That is. A further object of the present invention is to provide a lottery system that allows a player to remember a new lottery game by using HTV's game learning guidance and help screen. A further object of the present invention is to provide a lottery system in which a game is played on an HTV and a machine reports a win to a player. A further object of the present invention is to provide a lottery system capable of transferring a new lottery game to an HTV by a plug-in module. A further object of the present invention is a lottery in which a lottery institution can inexpensively test a new game and transfer the new game for the user experience to the HTV via a plug-in module to obtain user feedback. To provide a system. A further object of the present invention is to provide a lottery system capable of transferring advertisements related to the lottery game to the HTV and replicating the lottery game on the HTV. A further object of the present invention is to provide a lottery system in which skill racing games such as crossword puzzles and word discrambler games, which must be completed within a predetermined time but have a predetermined result, are played on the HTV. Is. Another object of the present invention is to provide a lottery system that increases lottery sales and player game value by dealing with winning reinvestments in HTV. A further object of the present invention is to provide a lottery system that allows a lottery institution to track players and their playing frequency in a database to provide bonus prizes and inspiration. A further object of the present invention is to allow the player to HTV regardless of the predetermined result purchased from the lottery institution. By being able to choose from multiple games above, it is to provide a lottery system that reduces player fatigue. A further object of the present invention is to provide a lottery institution with a lottery system that reduces the cost of lottery tickets and the cost of determining validity through electronic batch processing and the "occurrence" of reduced claims. A further object of the present invention is to provide a lottery system for creating attractive speed lottery-style lottery games for a wider range of participants who enjoy playing games on machines and personal computers. Further, a further object of the present invention is to use a global positioning system (Global Positioning System:) by HTV to promote in-flight games. By providing a lottery system that can use GPS) receivers to play and disable depending on the location and prevent the HTV from operating the game unless it is in a permitted location. is there. According to the above objectives, and further objectives as revealed below, the first embodiment of the present invention generally refers to a "lottery ticket" (result) purchased from a lottery or gambling institution ("lottery institution"). Remote terminal access to the LCC from at least one HTV, LCC, and multiple agent terminals (ATs) located at various lottery stores where players buy results and redeem their wins. Provides an offline remote lottery system with a communication network that gives. The LCC includes software or firmware that produces a randomized prize data stream (RPD) with finitely continuous hit / miss results. For any RPD, the sum of the winning results is the amount paid for a given percentage of the total revenue formed by the total sales of the RPD results. LCCs can store ID data records along with lottery agencies in memory that registers multiple HTVs, store information about individual players, and prepare bonus prizes and exciting programs. In the first embodiment, the player goes to a lottery store with an AT and requests to purchase m "lottery tickets". The agent obtains the ID information from the HTV in the form of the result purchase request message ORPM and inputs it to the AT that sends this information to the LCC, and the LCC confirms that the HTV is a properly registered unit. To. The agent then gives a few meters of the requested result. The LCC randomly assigns the next m results from the PRD and stores a record of the purchased results together with the ID data of the HTV. Therefore, the LCC knows exactly which HTV was given which result in preparation for future wins. The LCC then forms a result transfer message OTM and sends it to the AT. Result transfer message OTM is AT It is printed on the receipt and given to the player for manual input to the HTV. The result transfer message OTM can be created on the receipt in barcode format so that it can be scanned by the HTV's barcode scanner. Alternatively, if the HTV has a read / write interface for reading the result transfer message OTM from the smart card, the result transfer message OTM is written to an information storage medium such as a smart card by the AT read / write interface. You may. In yet another embodiment, both the AT and the HTV include means of physically binding the HTV to the AT so that the HTV can read the result transfer message OTM directly from the AT. .. In yet another embodiment, the result transfer message OTM can be voice input to the HTV's microphone if the HTV is equipped with a voice drive circuit for reading the message. Yet another example below that does not require an AT is the use of a telephone, in which the player either obtains the result transfer message OTM from the telephone and manually inputs it into the HTV, or the HTV calls. I have a modem to get the result transfer message OTM directly on the line. In yet another embodiment, the HTV has a transceiver that receives a result transfer message transmitted between the LCC base station and the HTV via radio frequency (RF) communication. The HTV includes software or firmware that can generate a game indicating the purchased result expressed in the result transfer message OTM. The game can be updated within the HTV by transferring the new game program to the HTV, such as via a smart card. The software also prepares for the formation of practice period games and game learning guidance to teach players how to play. The game may show a given result and may be "no choice", such as a paper lottery, a bingo game or a lottery where the winner wins all prizes (sweep sticks). However, you may have pseudo-options (such as video poker with a given result if the player plays every move correctly). The result transfer message OTM may represent the result selected from the RPD in the form of a compressed sequence. As a result, a simple code is printed on the receipt and used for manual input or barcode scanning. Also, in another embodiment, the reference sequence HTVRS containing very long and continuous random results is stored equally in both LCCs and HTVs. The result transfer message OTM represents in HTVRS an address containing a sequence of results that exactly matches the result selected from the RPD or the net payment amount of the selected result. Also, in other embodiments, both LCCs and HTVs store unidirectional algorithms that produce results in response to seed values. The seed value is chosen by the LCC to generate the result sequence from the RPD. The result transfer message OTM represents this seed value. Once the HTV is given the result transfer message OTM by any of the above methods, it produces a game that results in a result or a net payment of the result. To prevent the Result Transfer Message OTM from being used on the wrong HTV, the Result Transfer Message OTM is encrypted by the LCC by using a key known only to the LCC and the specific HTV that decrypts it. Can be transformed. Similarly, the result transfer message OTM can have a message authentication code that the HTV authenticates by using a key known only to the LCC and the HTV. LCCs and HTVs can store chaining variables for that particular HTV that are updated as a one-way function of all results already purchased or played on that HTV. The chaining variables are updated by the LCC each time a result purchase is made and by the HTV each time the HTV receives a new result transfer message. The chaining variable is then changed each time the resulting purchase request is made to the LCC, and / or Can be used to generate a new OPRM as a cryptographic or message authentication key. In one embodiment, additional results are given to prepare the player for reinvestment. These results are hereinafter referred to as "waiting results". Thus, a given result purchase for m results can have x wait results that allow the player to reinvest the winnings for that m purchased results. The number of wait results contained in a given purchase can ultimately be selected by the lottery agency to either consume all the wins or give a jackpot above a certain threshold. This will be explained in more detail later. When the HTV generates a game that shows the results, the cash balance of the account stored in the HTV is updated. Similarly, the LCC recognizes the net payment for a given purchase. When the player wishes to redeem, he or she either gives the redemption request message RRM to the AT's agent or sends the redemption request message RRM directly to the AT using one of the methods described above for the result transfer message OTM. .. The AT sends a redemption request message RRM to the LCC confirming the identity of the HTV and the expected payment to that HTV. If a wait result has been assigned, the redemption request message RRM will include an indication of which wait result has already been shown on the HTV. Also, wait results not shown are invalid during the redemption process. The player may then be required to receive payment from the lottery retailer, or if the prize has a large monetary value, the player may be required to mail it in a form for further payment from the lottery agency. Absent. In one alternative embodiment, the LCC is coupled to a communication network with interactive voice capabilities so that the purchase and redemption of results can be made over the phone, such as by dialing a pay phone number, including 900. It is accessible. Players simply key in information on the phone in response to prompt instructions from the system. Therefore, The player first sends the HTV ID information to the LCC. Once the HTV's ID is confirmed, the LCC gives the player a "ready" indication with instructions to select the number of results purchased for each price point. The LCC then generates a forwarding message OTM as a result of the player manually keying into the HTV, as described above. The system also operates to redeem the winnings. The HTV generates a redemption request message RRM, and the player keys the redemption request message into the phone. The redemption request message RRM is sent to the LCC, which confirms the identity of the HTV and the expected payment amount. The LCC's HTV / player account is then credited. In a variant of this embodiment, the HTV includes a modem that allows the HTV to communicate directly with the communication network, such as sending a result transfer message OTM from the LCC to the HTV. In this regard, the system could operate on any interactive communication network such as the Internet. Alternatively, HTVs can be combined with mobile phones for similar purposes. This embodiment is still considered as an offline array because it does not require an online connection between the HTV and LCC during play. In a further embodiment, the LCC and each HTV include a transceiver for sending and receiving RF communications for each message. Therefore, the player does not have to go to the lottery store to buy the results and redeem the winnings. These and other advantages of the present invention will be more fully understood with particular reference to the following detailed description and accompanying drawings. To. The system also operates to redeem the winnings. The HTV generates a redemption request message RRM, and the player keys the redemption request message into the phone. The redemption request message RRM is sent to the LCC, which confirms the identity of the HTV and the expected payment amount. The LCC's HTV / player account is then credited. In a variant of this embodiment, the HTV includes a modem that allows the HTV to communicate directly with the communication network, such as sending a result transfer message OTM from the LCC to the HTV. In this regard, the system could operate on any interactive communication network such as the Internet. Alternatively, HTVs can be combined with mobile phones for similar purposes. This embodiment is still considered as an offline array because it does not require an online connection between the HTV and LCC during play. In a further embodiment, the LCC and each HTV include a transceiver for sending and receiving RF communications for each message. Therefore, the player does not have to go to the lottery store to buy the results and redeem the winnings. These and other advantages of the present invention will be more fully understood with particular reference to the following detailed description and accompanying drawings. To. The system also operates to redeem the winnings. The HTV generates a redemption request message RRM, and the player keys the redemption request message into the phone. The redemption request message RRM is sent to the LCC, which confirms the identity of the HTV and the expected payment amount. The LCC's HTV / player account is then credited. In a variant of this embodiment, the HTV includes a modem that allows the HTV to communicate directly with the communication network, such as sending a result transfer message OTM from the LCC to the HTV. In this regard, the system could operate on any interactive communication network such as the Internet. Alternatively, HTVs can be combined with mobile phones for similar purposes. This embodiment is still considered as an offline array because it does not require an online connection between the HTV and LCC during play. In a further embodiment, the LCC and each HTV include a transceiver for sending and receiving RF communications for each message. Therefore, the player does not have to go to the lottery store to buy the results and redeem the winnings. These and other advantages of the present invention will be more fully understood with particular reference to the following detailed description and accompanying drawings. HTVs can be combined with mobile phones for similar purposes. This embodiment is still considered as an offline array because it does not require an online connection between the HTV and LCC during play. In a further embodiment, the LCC and each HTV include a transceiver for sending and receiving RF communications for each message. Therefore, the player does not have to go to the lottery store to buy the results and redeem the winnings. These and other advantages of the present invention will be more fully understood with particular reference to the following detailed description and accompanying drawings. HTVs can be combined with mobile phones for similar purposes. This embodiment is still considered as an offline array because it does not require an online connection between the HTV and LCC during play. In a further embodiment, the LCC and each HTV include a transceiver for sending and receiving RF communications for each message. Therefore, the player does not have to go to the lottery store to buy the results and redeem the winnings. These and other advantages of the present invention will be more fully understood with particular reference to the following detailed description and accompanying drawings.<u style="single">[Simple explanation of drawings]</u>FIG. 1 is a schematic diagram of a remote lottery system of the first embodiment showing LCCs, ATs, and HTVs. FIG. 2 is a block diagram of the LCC. FIG. 3 is an array diagram of an exemplary memory of an LCC. FIG. 4 is a block diagram of the components of the HTV. FIG. 5 is a block diagram of the control device in the HTV. FIG. 6 is an array diagram of an exemplary memory in an HTV. 7A and 7B are flowcharts of an exemplary result purchase. FIG. 8 is a flowchart of an exemplary redemption sequence. FIG. 9 is a schematic diagram of a random prize data stream showing an example of purchased and wait results. 10A and 10B are flowcharts of an exemplary result purchase sequence with wait results. FIG. 11 is a flowchart of an exemplary redemption sequence with a wait result. FIG. 12 is a schematic diagram of an alternative embodiment of the present invention. FIG. 13 is a schematic diagram of another alternative embodiment of the present invention.<u style="single">Detailed description of preferred embodiments</u>Some of the drawings show the lottery system collectively characterized by reference number 10 in the first embodiment, primarily with the lottery institution 11 having the LCC12 and the communication giving the LCC12 remote terminal access. A lottery system with a network 14, multiple agent terminals (AT) 16 coupled to various lottery dealers 18, and multiple HTV units 20 showing the results of purchased "lottery" is illustrated. There is. The term "lottery institution" is used in a general sense and is used by games or players with no choices (such as scratch-off lottery tickets, bingo or sweep stakes) or pseudo-choices (such as video poker). It is intended to include any gambling institution that sells skill races, etc. that, if played correctly, have a given result. The term "lottery store" includes any retail store where the AT16 is located. As mentioned above, the term "lottery" used here means a single result. Therefore, the player is actually purchasing from the LCC the results that were transferred to the HTV20 and shown through the game generated by the HTV20. As described in more detail below, players do not have to go to the given lottery store to purchase the results. In an alternative embodiment, it will be found that the LCC12 and AT16 can be combined into a single unit or a system whose results can be purchased by telephone or interactive communication network. Alternatively, the results can be purchased through RF communication between the LCC12 transceiver and the HTV20 transceiver. These examples will be described later. FIG. 1 is a block diagram showing an overview of the system components of the first embodiment. The LCC12 and the communication networks 14 and AT16 are connected in a manner similar to the prior art methods used to distribute paper speed lottery. In the present invention, each AT16 converts the printer 22, the bar code scanner and other scanning devices 24, and the HTV 20 into AT16. A communication interface 26 for physically coupling and electrically communicating signals to the HTV 20 through the HTV 20 compatible communication interface 92, and / or a read for reading and writing data to an information storage medium such as a smart card 28 / It can be equipped with a light interface 27. These are used to transfer results to the HTV20 through the result transfer message OTM, which are described in detail below. The smart card 28 can also be used to update the HTV20 game program to generate new games. In this regard, the new game can be transferred to the HTV20 in order to cheaply determine the market acceptability of the player. The smart card 28 can also be used to generally transfer lottery-related advertising information. FIG. 2 is a block diagram showing the details of the LCC 12, which is generally a CPU 30, a memory 32, an I / O interface 34 for loading a program into the memory 32, and a communication interface for communicating with the AT 16 over the network 14. Has 35 and. In an alternative embodiment described below shown in FIG. 13, the LCC 12 communicates with a plurality of base stations having transceivers that transmit and receive RF signals through the base station network 15 to directly communicate messages between the LCC 12 and the HTV 20. be able to. The LCC has software or firmware (hereinafter referred to as "program" and "data") used to perform various functions in the system. FIG. 3 shows an exemplary memory array of programs and data stored in LCC12. The memory 32 has an operating system program 33 which is not detailed here for controlling the LCC 12 in the conventional way. The LCC 12 has a memory area 36 for each HTV 20 in the memory 32. Because of the specific information stored here, the LCC12 can assign the results to its HTV20 and prepare in exchange for the winnings. To be sure that the HTV20 is a confirmed unit for a given transaction, the LCC12 can track what was assigned to that HTV20. The data in memory 36 can be searched and updated as needed to achieve the desired function. For convenience, the following description describes an HTV registered for one player. However, the HTV20 can have multiple accounts for different players, in which case access to the HTV20 will be possible through different passwords. The HTV20 must first be registered with the lottery agency 11 before it can be used. Regarding this, first, the ID information is stored in the memory 32 of the LCC 12. The ID information includes the unit identifier or HTV ID (I) stored in the field 37 and the chaining variable (C) stored in the field 38. I can configure each HTV20 with its own 64-bit identifier. Similarly, C can configure a 64-bit representation of the history of purchase transfers to a particular HTV20. Therefore, C is updated as a one-way function of the purchased result each time the purchased result is assigned to a particular HTV20. Thus, C is unique to the HTV20 as it is a record of all transactions made for each HTV20. In one exemplary embodiment, C is used as a way to prevent fraud by generating a result purchase request message OPRM on the HTV20 as a function of both I and C, in which case the OPRM is used for purchase and / Or used to identify a particular HTV20 during a redemption transaction. In this regard, the current ORPM for that HTV20 is stored in field 40 of the HTV memory area 36 of the LCC memory 32, and the LCC12 gives the generated OPRM to verify the identity of the HTV20 (results sold to the HTV20). Can be compared to that of the last transaction stored in memory (updated each time). C and I can also be used as encryption or authentication keys, as described below. Wear. LCCs have a finite number of consecutive hits (wins) and misses (losses) that result in O1 to On (eg, per $ 2, per $ 2, miss, miss, per $ 10, miss, miss, ... Etc.), which contains a program 42 for generating a random prize data stream (RPD) 44, which is a pool containing. For any RPD44, the sum of the winning results is the amount paid for a given percentage of the total revenue generated by the total sales of the "lottery" represented by the RPD44 results. Upon purchase, LCC12 randomly selects the next m results from RPD44 (and, in some cases, only x x "wait results" to prepare for a winning reinvestment, as described below). Use the "lottery ticket" (or result) purchase program 48. The result purchase program 48 then instructs the LCC12 to send and read into the HTV20 and generate a result transfer message OTM such that the HTV20 can indicate the result. There are several ways this can be done. The result purchase program 48 also stores the result transfer message OTM in field 50, the recorded m assigned results in field 52, and the x assigned wait results in field 54. Instruct. This data is accompanied by the price points of a given "lottery ticket" (or result) such as 25 cents, $ 1 or $ 2 in field 56, the net payment amount in field 58, and the date and time in field 60. Therefore, a record is generated for each transaction with a given HTV20 in LCC12. In one embodiment, each HTV 20 can be assigned its own reference sequence (HTVRS) stored in field 46. The same HTVRS is also stored in a particular HTV20, as described below. HTVRS is the result of randomly consecutive hits (wins) and misses (losses). When a purchase is made, the Results Purchase Program 48 directs LCC12 to find a series of results within the HTV RS that have the same result or the same net payment amount. These results or net payments may be represented by one or more memory addresses within the HTV RS. In addition, the result purchase program will be on LCC12. Instructs it to generate a result forwarding message OTM representing that address in HTVRS. The HTV20 can interpret the OTM as finding a series of results with the same result or the same net payment amount within the very own HTVRS. This will be explained in more detail later. Another way LCC12 can assign results is by using a one-way function that utilizes the seed value to generate a sequence of results selected from RPD44. The HTV memory area 36 of the LCC memory 32 has a one-way function for field 62. The same one-way function is also stored in the HTV20, as described below. The seed value of this one-way function becomes part of the result transfer message OTM. Yet another way the LCC can assign results to the HTV20 is simply to compress the result sequence into smaller code and then decompress it on the HTV20. In particular, LCC12 provides a compression / decompression program 64 that takes a series of m results Oj to Oj + m selected by the result purchase program 48 and compresses the sequence into smaller variables that are part of the result transfer message OTM. I have. During compression, if necessary, rearrange the results Oj through Oj + m in a hierarchical order (ie, the number of people who missed, the number of people who won $ 1, the number of people who won $ 2, etc.) It is possible to do. As described below, in an embodiment where the result transfer message OTM is printed on a receipt or created in bar code format in order to manually enter the result transfer message OTM into the HTV or prepare to scan the OTM. Compression is valid. Compression is also effective in the telephone-based embodiment shown in FIG. 12, which will be described below, in which the player can send a message by telephone in response to an appropriate prompt instruction. In this regard, compression and decompression can be used in combination with any other method of transferring the results, such as when the HTVRS address is transferred. In yet another embodiment, the result purchase The incoming program 48 calculates the expected net payment amount of m results Oj to Oj + m and generates a result transfer message OTM representing the net payment amount. In this case, the HTV randomly generates a game that results in having its net payment. However, this method is not suitable for the waiting result. To provide additional confidentiality in the system, the result transfer message OTM is stored in field 66 and can be encrypted using a key known only to LCC12 and certain HTV20s. The authentication / encryption key program 68 helps encrypt and decrypt messages sent to and received from LCC12. Also, the message generated by LCC12 is a message stored in field 70 so that only a particular HTV20 can use that message by using a key known only to LCC12 and that HTV20. Authentication can be enabled by attaching an authentication code. As mentioned above, the chaining variable C and the unit identifier I can be used as keys to perform encryption / decryption and authentication. Another resident program in LCC memory 32 is the accounting program 72, which calculates the current cash balance of each HTV20 and stores it in account 73 in field 74. Accounting program 72 is used to track the accumulated value of a player's wins and losses after the player has cashed. Accounting Program 72 allows LCC12 to duplicate a player's deposit balance at any point in the outcome sequence. The LCC memory 32 also has an audit program 78 that stores a record of all transactions with a particular HTV 20 in field 76. The LCC memory 32 also includes a redemption program 79 that allows players to see what they have won and cash it. Redemption Program 78 is used to cash any winnings out of a player's current deposit balance. Is the redemption program 79 HTV20 against LCC12? Instructs to read the given redemption request message RPM. The redemption program also determines the number of wait results the player has actually used. All of these will be explained in more detail later. Data about a particular player can be stored in field 81 and bonus prize data can be stored in field 80 to track the player's history. In this way, the lottery agency 11 can give the player a patronage reward, such as providing free results for the entire purchased "lottery ticket". Now, referring to FIGS. 4 and 5, the HTV 20 in the preferred embodiment is a handheld unit having a control device 82, a display 84, and a player control unit 86. Preferably, the HTV 20 comprises one or more of the following: That is, the printer interface 88a for connecting the HTV20 to an external printer, the internal printer 88b, the barcode scanner 90, and the HTV20 for allowing the HTV20 to communicate electrically and directly with the AT16 are connected to the communication interface 26 of the AT16. A particularly compatible communication interface 92, a read / write interface 94 that reads and writes data to and from the smart card 28, and an HTV 20 that connects directly to the communication network 14 coupled to the LCC 12 in an alternative example shown in Figure 12 below. A modem 96 for, and an interface 115 coupled to a transceiver 113 that sends and receives messages to and from base station 600 coupled to LCC 12 in another alternative embodiment shown in FIG. 13 below. The player control unit 86 may be integrated with the display 84 in a touch screen array of a format known in the art. The display 84 may also have the ability to create a message in a barcode readable format so that it can be scanned by the barcode scanner 24 coupled to the AT16. Through the player control unit 86, the player can perform various games and result transfer and redemption functions. Can be selected. The control device 82 has a CPU 98, a clock 101, and a memory 100 composed of a conventional array of ROM and RAM. Optionally, the control device 82 may be housed in a tamper-proof enclosure to indicate to the lottery engine 11 allegations of tampering with any device. The CPU 98 communicates with the player control unit 86 via the control interface 103, the video forming hardware 104 for driving the display 84, and the sound generation hardware 106 coupled to the speaker 108 for communicating the game sound. To do. A voice drive circuit 110 of a form known in the art may be coupled with a microphone 112 to allow a message to be sent to the CPU 98 by voice command. The CPU 98 has a printer interface 88a or an internal printer 88b, a barcode scanner 90, an interface 92, a read / write interface 94, and a modem through a conventional I / O interface, which is collectively shown as 114 in the block diagram. Can communicate with 96. The CPU 98 can communicate with the RF circuit 113 coupled to the antenna 115 for communicating messages directly to the LCC 12 via the base station as shown in the alternative embodiment shown in FIG. .. In another application, the HTV 20 may have a GPS receiver 111 coupled to an antenna 115 that transmits location information to the CPU 98. In this way, the HTV20 can interfere with its operation if it is not in place where the game is allowed by the in-memory operational / inoperable location program. The result transfer message OTM can be sent to the HTV20 using the following protocol. In the first embodiment, the AT16 prints the result transfer message OTM on the receipt 30, and the agent gives the OTM to the player. The player simply inputs the result transfer message OTM to the HTV20 using the player control unit 86. this Apart from that, the AT16 may print the result transfer message OTM in a barcode readable format so that the barcode scanner 24 can simply scan it. In any case, to prevent someone else from seeing the resulting forwarded message OTM and then trying to enter it into another HTV20, the receipt is a carbon-free two-part that the player throws away. The format allows you to print without using ink. In an alternative embodiment, the HTV20 can connect to the AT16 at interface 92 and send the result transfer message OTM directly to the HTV20. In another embodiment, the OTM can be written to the memory of the smart card 28 through the read / write interface 27 connected to the AT16. The player then plugs the smart card 28 into the HTV20, and the OTM is read from the smart card 28 by the HTV20. In yet another embodiment, the result transfer message OTM is voice input to the microphone 112 by the player or agent, or by automatic voice through the telephone in the telephone embodiment shown in FIG. 12, and by voice drive circuit 110. Can be processed. In an embodiment using another telephone, the HTV 20 can be directly connected to the telephone network 514 and a result transfer message OTM can be sent to the HTV 20 via a modem 96. In the embodiment shown in FIG. 13, the result transfer message OTM can be transmitted from LCC12 through RF transmission of AT16 or LCC12. A redemption request message RRM from HTV20 that allows players to cash their wins can be sent in the same way. Now, referring to FIG. 6, an exemplary memory array 100 of HTV20 programs and data is shown. The memory 100 includes an operating system that is collectively referred to as reference number 117 and controls the HTV 20 in a conventional manner. In the present invention, in order to generate a game that produces results Other programs and data in memory 100 allow the HTV20 to read the result transfer message OTM from the LCC12 and process these messages. The HTV memory 100 also includes an operable / incapacitating location program 101 that renders the HTV 20 inoperable if the location information from the GPS receiver 111 indicates that the HTV 20 is in a location where games are not permitted. You may be. The gambling place information used by the operable / inoperable position program 101 is stored in the field 105. As described above for the LCC memory 32, each HTV stores the unit identifier I in field 116 and optionally the chaining variable C in field 118. Further, the HTV 20 may store the serial number S in the field 120. The password (or multiple passwords when one HTV20 is used by multiple players) is stored in field 122. When the player activates the HTV 20, the secret secret program 124 checks the player's secret in the conventional manner before allowing the player to continue using it. The HTV memory 100 generates ID information to be transferred to the LCC 12, for example, the result purchase request message OPRM, and instructs the HTV 20 to read the result expressed in the result transfer message OTM. Result purchase program 126 Further has. When read by the HTV20, the result transfer message OTM is stored in field 128 of memory 100. When the result transfer message OTM is compressed by the LCC, the compression / decompression program 130 is called by the result purchase program 126 to decompress the result transfer message into the result sequence. The m results Oj to Oj + m are stored in field 132. If there are x assigned wait results Os to Os + x, they are stored in field 134. This data shows the price points for each result in field 136, the net payment amount to field 138, and the date and time to field 140. May be accompanied by an input of. As mentioned above for LCC12, the result transfer message OTM may represent a memory address of one or more of the reference columns HTVRS. Therefore, each HTV20 can store the HTVRS in field 142. In such an embodiment, the result purchase program 126 directs the HTV 20 to find a sequence of results Oj to Oj + m or the net payment amount for that sequence in the HTV RS. Alternatively, the result transfer message OTM may represent the seed value of the one-way function of field 144. Therefore, the result purchase program 126 instructs the HTV20 to use its one-way function to produce the desired result Oj to Oj + m. The same one-way function is also stored in LCC memory 32. As mentioned above, the result transfer message may be encrypted by LCC12 to prevent it from being used by another HTV20. The authentication / encryption program 146 prepares for the encryption and decryption of such messages sent to and received from the HTV 20 by using a type of algorithm known in the art. In this regard, the HTV 20 may store a special key in field 148 for encrypting and decrypting such messages. Similarly, a message from LCC12 having a message authentication code may be authenticated by authentication / encryption program 146 using a key stored only in field 150 and known only to LCC12 and the special HTV20. As described above for the LCC memory 32, each HTV20 may use its own chaining variable C as a key for encryption, decryption and authentication. The HTV 20 has a game generation program (game program) 152 that generates various games and displays the wins and losses on the display 84 as a score. The game generation program may include learning guidance and help functions for teaching the player how to play the game for each game. These games Can be generated with a win-loss result that corresponds exactly to each result Oj to Oj + m represented by the result transfer message OTM. Therefore, the game only interprets or displays the results. Alternatively, the games can be generated such that m games have a net payment equal to the net payment of Oj to Oj + m in a row. However, the latter is not suitable for the embodiment to which the waiting result is assigned as described later. A game can have multiple winning opportunities, but only one result. Game program 152 is a "no choice" game, such as a tab-drawing speed lottery, sweep stakes, or a common format for bingo, a skill-free game with a given result, or video poker. Generate a game with pseudo-choices that have a given result. In the latter case, the outcome for a particular poker game is predetermined to have the maximum amount of payment that the player can recover if he or she plays every move correctly. If the player plays incorrectly, the payment will be less than the maximum represented by the result for a particular game. In addition, the game program 152 can generate skills races, such as games such as crossword puzzles and word discrambler games that must be completed within a predetermined period of time. If the player completes the game within the specified time period, the player will be paid a predetermined amount of payment for the result selected for the game. Otherwise, the winnings will not be credited to the HTV account 155 described below. Programs that generate such games are known in the art. Game program 152 may be scheduled to request a game identifier so that the lottery agency 11 selects the game in which the lottery agency 11 is played in relation to the results sold. In this regard, the result transfer message OTM may include instructions to the game program 152 to generate specific games for those results. it can. To prepare for game updates on the HTV20, as mentioned above, new game programs can be launched through the smart card 28 or in the traditional way by plugging the HTV20 into the AT16 and uploading the appropriate software instructions. It could be loaded into memory 100. HTV memory 100 also includes an accounting program 154 that instructs HTV 20 to calculate the current cash balance stored in account 155 in field 156. If some players are assigned to a given HTV20, each player may have a separate account. HTV Memory also has a redemption program 158 that is used to cash the player's current deposit balance in the player's account 155. The redemption program 158 allows players to select the cashing feature on the HTV20. The redemption program 158 then instructs the HTV20 to generate a redemption request message RRM that is sent to the LCC12 in the same way that the result transfer message OTM is sent to the HTV20. .. Redemption Request Message RRM is an LCC12 redemption program 79 to confirm a cashing request by comparing the HTVID data for a given HTV20 with the result data (net wins, number of games played, etc.). Used by. The redemption request message RRM can also be generated on the display 84 of the HTV20 and verbally given to the agent of the lottery dealer 18 for manual input to the AT16. The redemption request message RRM can also be printed on the receipt 30 by the printer 22 of the lottery dealer via the internal or external printer 88b or printer interface 88a of the HTV20, which receipt 30 is then sent to the agent. Given. In this regard, a redemption request message RRM is created on display 84 or a bar on AT16. It can also be created in a barcode-readable format on the receipt 30 so that it can be scanned by the code scanner 24. Also, in another embodiment, the redemption request message RRM is written to the smart card 28 and can be read by the AT16 from there. In yet another embodiment, the redemption request message RRM can be sent to the LCC 12 through the telephone network 14 via the modem 96. In yet another embodiment, the redemption request message RRM can be transmitted from the HTV 20 to the LCC 12 by RF transmission to the AT 16 or LCC 12. The redemption request message RRM can be encrypted by the HTV 20 using the memory 100 password / encryption program 146 for decryption by the LCC 12 using the memory 32 authentication / encryption program 68. The redemption request message RRM can be encrypted using an encryption key known only to LCC12 and certain HTV20s. These may include the unit identifier I and the chaining variable C. The HTV Memory 100 also provides field 161 for all activities performed on the HTV 20 to help protect the security of the data and ensure that various programs in the Memory 100 have not been tampered with. Includes an audit program 160 that stores records. The audit program 160 also provides a record of a player's activities to the player and the lottery agency 11 in the event of a problem. Now, with reference to FIGS. 7A and 7B, an exemplary result purchase flowchart of m "lottery tickets" (or results) from LCC12 is shown through AT16 of the lottery store 11. For convenience, the following assumes that all results are purchased at a single price point. However, the results purchased from RPD44 can represent different price points, and by retrieving a result transfer message for each price point, the result transfer message represents the result with different or different price points. It can be purchased together by generating a sage OTM. To initiate the purchase sequence, the player first activates the HTV20 and enters the password checked by the security secret program 124. After that, the player selects the "lottery ticket" purchase function in step 300. In step 302, the result purchase program 126 instructs the HTV 20 to generate the result purchase request message OPRM as a one-way function of I and C. The player gives the OPRM to the lottery dealer's agent in step 304. Then, in step 306, the agent inputs the OPRM into the AT16, which sends the OPRM to the LCC. Also, the serial number OPRM could have been given to the agent by either the method described above for communicating the result transfer message OTM or the redemption request message RPM described above. In step 308, the LCC 12 executes a result purchase program 48 that extracts I and C from S for its HTV20. In step 310, the LCC compares I and C with the values of I and C stored in fields 37 and 38 in the HTV 20 memory area 36, respectively. As mentioned above, I and C are first stored in the LCC 12 when a particular HTV is registered with the lottery agency 11. C for a given HTV20 is updated by a one-way function each time the result is transferred to that HTV20. If I and C match, LCC12 sends a ready code to AT16 in step 312. In the case of a discrepancy, LCC12 rejects the resulting purchase request in step 314 because the HTV20 was not registered or was modified in some way. If the HTV ID is valid, the player gives the agent a few meters of the result to be purchased at a given price point in step 316. The agent enters m and price points into AT16 in step 318. AT16 is m in step 320 And send the price points to the LCC. Then, in step 322, the result purchase program 48 of the LCC memory 32 randomly selects the next m unsold results Oj to Oj + m from the RPD 44 for that price point. It also tells LCC12 to store the results Oj to Oj + m in field 52, the price points in field 56, the net payment amount in field 58, and the date and time in field 62, respectively. To do. Then, in step 324, the LCC 12 uses one of the methods described above to generate a result transfer message OTM. The LCC12 can also store the result transfer message OTM for a given purchase in field 50 of memory. As mentioned above, the LCC 12 can use the authentication / encryption program 68 to encrypt the result transfer message OTM, in this example in step 326, first using I as the encryption key and then C is used as the encryption key. (Note that OTM does not need to be encrypted and can be authenticated by attaching a message authentication code that is authenticated by HTV20 with a key known only to LCC12 and HTV20). Then, in step 328, it updates C (C = f (OTM)) as a one-way function of the result transfer message and stores the new value of C in field 38. The LCC12 then sends a result transfer message OTM to the AT16 in step 330. At step 332, the AT prints a receipt 30 that includes the OTM, date and time, price points, and m. Then, in step 334, the agent gives the player a receipt 30 containing the result transfer message OTM, and the player pays the agent. At this time, in step 336, a result purchase confirmation message is transmitted from AT16 to LCC12 indicating that the player has purchased the result "immutably", which is expressed in the result transfer message OTM. After that, step At 338, the player inputs the result transfer message OTM into the HTV20. In step 340, the HTV 20 executes an authentication / encryption program 146 to decrypt the result transfer message OTM, first using C as the key and then I as the key. Then, in step 342, the result transfer message OTM is stored in field 128 of HTV memory 100. If the result is simply compressed into sequences Oj through Oj + m (Figure 9), the decompression / compression program 130 decompresses the sequence and stores it in field 132. The result purchase program 130 also stores the price points in field 136 and the net payment amount in field 138. If the result transfer message OTM represents an HTVRS address, the result purchase program 130 will use that address or a series of results for an address that exists with the same net payment as Oj to Oj + m. And search for the HTVRS stored in field 142. If the result transfer message OTM represents the seed value of the one-way function stored in field 144, the result purchase program 130 uses that seed value to produce the same set of results Oj through Oj + m. Generate. Alternatively, the result transfer message OTM can simply represent the net payment amount for the number of m results Oj to Oj + m, in which case the game program 152 will make the same net payment amount. Generate some games that have. Once the result message OTM is stored in step 342, the result purchase program 126 updates C as a one-way function of the OTM in step 344 to store the new value of C in field 118. In this way, the HTV20 and LCC12 store the new C value in memory. Then, in step 346, the player plays a game on the HTV 20 that results in the results Oj to Oj + m generated by the game program 152 or the net payment for those results. In step 348 The layer's account balance is updated by accounting program 154 and stored in account 155 in field 156 each time each result is shown. FIG. 8 is an exemplary monetization sequence in the above embodiment. Essentially, the HTV20 queries the LCC12 for its own identity, and the LCC12 approves payments for the resulting sequences Oj through Oj + m sold to the HTV20. To initiate the redemption sequence, the player first activates the HTV20 and enters a password that is checked by the security secret program 124 as described above. The player then selects the cashing function in step 350. In step 352, the redemption program 158 of the HTV memory 100 generates a redemption request message RRM as a function of I and C in this example. Therefore, the redemption request message RRM is similar to the result purchase request message OPRM described in the result purchase sequence of FIGS. 7A and 7B. The RRM can also include the cash balance of the renewed account 155, which represents the payment amount of the indicated result. The value of C has already been updated as a one-way function of the result transfer message OTM in step 344 above. Further, the value of C has already been updated in the LCC memory 322 in step 328 above. In step 354, the player gives the redemption request message RRM to the agent. The agent then activates the AT16 redemption function in step 356. In step 358, the agent inputs the redemption request message RRM to AT16, which sends the RRM to LCC12. The LCC12 then confirms the redemption request message RRM in step 360 by extracting I and C and comparing the values of I and C with the values stored in fields 37 and 38 of memory 32, respectively 79. To execute. If, in step 362, I and C do not match the expected values, LCC12 rejects the monetization request in step 364. If, in step 362, I and C match the expected values, then in step 364, LCC12 calculates the cash balance embodied in the redemption request message RRM from the resulting sale to its HTV20. Then check the amount already stored in the HTV account 73 in field 74 (the amount paid for the resulting sequence stored in field 58). The LCC12 then sends a validity determination message to AT16 in step 368, and the amount is debited in account 73. At step 370, the player may choose to purchase more results with the current cash balance of account 73, in which case the result purchase sequence shown in FIG. 7 is repeated. Alternatively, the player may receive payment from an agent in step 372. As briefly mentioned above, a result purchase request for m results Oj to Oj + m can be accompanied by x wait results Os to Os + x. Wait results are given in sufficient numbers to eliminate all wins, or to generate jackpots above a certain amount at some point in the sequence, in the latter case the result of HTV20. The purchase program 126 instructs the HTV 20 to stop generating the game and give a cashing instruction to the display 84. Now, referring to FIG. 9, a portion of 5 RPD44s with purchase results Oj to Oj + m with a net payment of $ 16 is shown. In this example, the LCC12 result purchase program 48 selects 24 wait results Os to Os + x in two groups, as shown. The wait result can be selected from anywhere in RPD44, but the groups are played in sequence. The relative position between the purchased result m and the wait result x shown in RPD44 is only an example. For convenience of this example, all results are purchased for $ 1. Players will earn $ 16 for Oj to Oj + m as a result of their purchase. Players have 16 waiting connections in the first group If you spend $ 16 on the fruit and the result results in a net payment of $ 8, the next group will have 8 pieces with a net payment of 0 in the first example (to cancel the win). You can compose the results, or in the second example, you can compose eight results that result in some jackpot (eg $ 500) represented by the fourth result in the second group. To refer to the second example, if the result sequence of the second group is played in sequence and the result sequence is off, per $ 2, per $ 1, per $ 500, the player is in the first After the waiting group has been played, only $ 4 wins are stored, and the second group stores only $ 2 + $ 1 + $ 500, resulting in a net win of $ 507. HTV20's game program 152 instructs HTV20 to generate a cashing message when such a jackpot result is shown. If some wait results remain, these are four outliers in this example, which are invalidated by redemption program 158 on that HTV20. Similarly, those four wait results are given a redemption request message RRM to LCC12 that represents all the results transferred to the HTV20, including m purchased results and x wait results. Disabled in LCC12. Since the player can choose to cash at some point in the sequence before all wait results are shown, the redemption request message RRM generated by HTV20 tells which wait result is already shown on HTV20. It makes it possible for the LCC12 to calculate a fair payment and to invalidate any unused wait results within the LCC12. Now, with reference to FIGS. 10A and 10B, an exemplary flowchart of a result purchase sequence containing m purchased results Oj to Oj + m and x waiting results Os to Os + x is shown. There is. The protocol in this example is similar to that in Figure 7, so redundant steps are repeated. Do not return. In step 400, the result purchase program 48 in the LCC memory randomly selects m purchased results Oj to Oj + m and x wait results Os to Os + x from RPD44. The LCC12 then generates a result transfer message OTM in step 402 that represents m results and x wait results. The result transfer message can consist of a compressed sequence, an address for the HTVRS result, or a one-way function seed value, as described above. In step 404, the LCC 12 can update C as a function of the result transfer message OTM and store it in memory, as described above. In step 406, when the result transfer message OTM is read, authenticated (if authenticateable), or decrypted (if encrypted), it is stored in field 128 of memory 100 of the HTV 20. .. In this regard, m results Oj to Oj + m can be stored in field 132, and standby results Os to Os + x can be stored in field 134 of the HTV memory 100. The same data is already stored in the LCC memory 32. In step 408, the HTV updates C as a one-way function of OTM. Then, in step 410, the HTV 20 produces a game that yields m results Oj to Oj + m or a net payment for those results. In step 412, HTV20 utilizes an accounting program to update the cash balance of account 155. Up to this point, the protocol is generally the same as that shown in Figure 7. In step 414, the result purchase program 126 instructs HTV20 to display the option to reinvest the cash balance (wins) of account 155. If the player wishes to cash in, the cashing sequence shown in Figure 7 will be made. If the player wishes to reinvest, in step 416 the game program 152 also has a wait result Os to Oj + x. Generate a game to play. In step 418, HTV20's accounting program 154 updates account 155 with a new cash balance, depending on whether the wait result is a hit or miss, and displays the updated balance on the display 84 for that hit. In step 420, the result purchase program 126 then invalidates the last indicated wait result and updates the result state (to "shown") in the sequence of wait results stored in field 54. .. In step 422, if the final wait result shown forms a jackpot greater than or equal to a predetermined threshold, the result purchase program 48 must cash the player against HTV 20 in step 424. Instruct them to display a message that they must. The player executes the redemption sequence shown in FIG. If not, in step 426, the result purchase program 48 determines and checks if there are any unused wait results left in field 54. In step 428, if not left, the player has already used up the cash balance in account 155 and the HTV 20 generates zero cash balance on display 84. If the wait result remains, the player chooses whether to continue the reinvestment in step 430. If the player chooses to reinvest, the HTV20 forms another game in step 416 that results in the next wait result. If the player chooses to cash, HTV20 displays the cash balance of account 155 in step 432 and the player performs the redemption sequence shown in FIG. Now, referring to FIG. 11, an exemplary monetization sequence in the presence of a wait result is shown. To initiate the redemption sequence, the player first activates the HTV20 and enters the password checked by the secret secret program 124, as described above. The player initiates the cashing function in step 500. HTV Memory 100 Redemption Pro Gram 158 generates a status record of the wait result and the cash balance associated with the account 155 RSBY in step 502, and generates a redemption request message RRM as a function of I and C with RSBY attached in step 504. The redemption program 79 also invalidates any unused wait results stored in field 54. If the redemption request message RRM is displayed on the HTV display 84 or printed on the receipt 30 (either in alphabetical or bar code readable format), the recording of the wait result may be redundant, so the RRM is It can be compressed into smaller messages by the HTV memory 100 compression / decompression program 146. In this example, in step 506, an embodiment in which the player gives the redemption request message RRM to the agent of the lottery store 18 is described. As mentioned above, the redemption request message may be sent to AT16 through other methods. The agent selects the redemption function of AT16 in step 508. Then, in step 510, the agent inputs the redemption request message RRM into the AT16, and the AT16 sends the redemption request message RRM to the LCC12. The LCC then confirms the redemption request message RRM in step 512 by extracting RSBY, I and C and comparing the values of I and C with those stored in fields 37 and 38 of memory 100, respectively. Therefore, the redemption program 79 is executed. If, in step 514, I and C do not match the expected values, LCC12 rejects the monetization request in step 516. If, in step 514, I and C match the expected values, the LCC12 will calculate the payment amount of the waiting result expressed in RSBY and credit the HTV account 155 in field 156. Use accounting program 154. The LCC12 is then unused as represented in RSBY in step 520. Disables all wait results for. The LCC12 then sends a validation message to the AT16 in step 522. Now, referring to Figure 12, the LCC12 is coupled to a communication network 14'with interactive voice capabilities and can be accessed by dialing to pay phone numbers, etc., including 900, in exchange for the purchase of the result. Is made possible by telephone 13. Alternatively, the communication network 14'may be any interactive communication network, including the Internet. The protocol is similar to that described above for purchases and redemptions at AT16, except that the player here only has to key in the information over the phone 13 in response to prompt instructions from the system. Therefore, the player first sends the HTV ID information to the LCC 12 in the form of the result purchase request message OPRM. Once the HTV ID / registration is confirmed, LCC12 gives the player a "ready" indication, along with instructions to select the number of results to be purchased for each price point. The LCC12 then generates a forwarding message OTM as a result of the player keying into the HTV20, as described above. Also, the system operates to redeem the winnings. The HTV20 generates a redemption request message RRM, and the player keys the redemption request message into the phone. A redemption request message RRM is sent to the LCC, which confirms the identity of the HTV 20 and the expected payment. The HTV / player's account is then credited at LCC12. In a variant of this embodiment, the HTV20 sends a result transfer message OTM from LCC12 to HTV20 and a redemption request message RRM from HTV20 to LCC12, so that it is a communication network 14'. Includes a modem 96 that allows you to communicate directly with. Alternatively, the HTV20 can have a mobile phone (not shown) for the same purpose. This embodiment is still considered an offline sequence because no online connection between the HTV and LCC is required during play. In yet another embodiment shown in FIG. 13, the LCC 12 communicates with a plurality of base stations 600 that send and receive RF messages through the base station network 15. The HTV20 also has a transceiver 113 that sends and receives RF communications so that players can perform all purchase and redemption functions without having to go to a lottery store. The protocol is similar to that described above for other embodiments.