AU770698B2 - Off-line remote lottery system - Google Patents

Description

S&F Ref: 416306D2

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT

ORIGINAL

Name and Address of Applicant Actual Inventor(s): Address for Service: Invention Title: Walker Digital, LLC One High Ridge Park Stamford Connecticut 06905 United States of America Jay Walker Bruce Schneier Spruson Ferguson St Martins Tower 31 Market Street Sydney NSW 2000 Off-line Remote Lottery System The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5845c

I/I

OFF-LINE REMOTE LOTTERY SYSTEM

BACKGROUND

The present invention relates generally to remote gaming systems, and more particularly, to a lottery system in which lottery games typically embodied in a ticket having multiple chances which represent a single outcome offered by a lottery authority are rendered on a gaming computer as an "electronic ticket," such as, for example, a dedicated hand-held device or programmed general personal computer, which enables a player to reveal the ticket outcome with the same convenience as typical paper scratch-off tickets at any location without the gaming computer ever having to be 15 physically or electronically connected to a lotterv system network during play, thereby providing enhanced play value for the player and greater revenues for the lottery authority.

in one type of common prior art paper instant ticket system, a computer generates a randomized prize datastream comprised of a finite series of win/lose outcomes. Each outcome is assigned to a lottery ticket, and each ticket contains one or more game chances which yield the assigned outcome. The 25 player cannot change the ticket outcome, he or she merely scratches off certain areas of the ticket in accordance with the rules of the game to reveal the outcome. The ticket contains indicia which provide the player with a means to determine win/lose results or prize status, and the cype of prize cash or a free ticket). The aggregate of all winning outcomes in any randomized prize dataszream is a predetermined. percencage payou: of the total revenues that would be generaced by tne sale of all of the tickets incorcprating that carcicular randomized prize datastream.

Each ticket is assigned a unique Zicke- serial number for validation purposes which identifies that ticket with a specific outcome, and a batch number which links the ticket to a master carton in which groups of tickets are shipped to lottery retailers in specific quantities. The ticket serial number is usually concealed beneath the foil cf the ticket.

The batch number is typically visible on the ticket in the form of a bar code. All tickets in a given master carton are part of the same ticket lot and are sold at the same price point. Each master carton is labeled with a unique master carton serial number which is tracked by a central computer associated with the lottery authority. The central 15 computer also stores every ticket serial number and the associated outcome for that ticket. When the instant tickets are to be sold to customers, the lottery retailer communicates the master carton serial number via his on-line agent terminal to the lottery central computer and thereby activates all of the paper instant tickets in each master carton.

This action activates all of the ticket serial numbers in that master carton, and typically causes the lottery retailer's lottery bank accoun: to be 25 automatically debited for the wholesale cost of that master carton within a specified time period.

To redeem a winning paper lottery ticket, the player presents the same to a redeeming agent, either at a lottery retailer or lottery office, or mails the ticket in for redemption. To effectuate the redemption process, the redeeming agent scans the bar code on the ticket which reoresents the batch serial number on the ticket through a bar code scanner associated with the agent terminal. The ticket agent also enters the ticket serial number into the agent terminal. These ticket serial numbers are transmitted to the central computer for

C)

-3purposes of validation. When the ce.nral comouter receives a validation request, it activates an on-line validation program which queries a ticket value database using the particular ticket and batch serial numbers to confirm that the ticket came from an activated master carton. If the ticke: value database confirms a payout, the validation program authorizes the lottery retailer to pay the player cash or provide another prize a free ticket) In other paper instant ticket systems, there is no lottery central computer which manages the system. The lottery retailer simply buys tickets from a printer, resells them to players, and then handles all aspects of validation and payment of 15 winnings.

aper instant ticket systems suffer from several drawbacks. These include the costs of ~printing tickets, the physical inventory costs, the costs to the lottery authority and retailer associated with unsold tickets, the inability to effectively offer low-price games $0.25, the limited game choices for the player, and the stigma associated with paper tickets as appealing toward lower income players, among others.

As an alternative to instant paper tickets, systems have been devised which replicate instant tickets on a computer terminal or gaming machine. An example is shown in U.S. Parent No. 5,324,035, which discloses an on-line video gaming system comprised of a plurality of slave terminals, a plurality of master processing units, and a central came processor. A plurality of slave erminals are networked to each master processing unit and all of the master processing units are networked to the central game processor. The central game processor downloads fixed pools of game plays to each master processing unit. The slave terminals reauest game O O -4- -s plays from the fixed pool in the master przcessinc unit. The group of slave terminals coupled to a particular master processing unitdisplay indications of the chances of purchasing one of the remaining winning plays in that pool to provide an element of competition between players situated at the various slave terminals. Thus, players at each slave terminal may decide to wait for the odds of purchasing a winning play to increase by allowing other competitors to purchase some of the remaining non-winning plays. Although this system is capable of rendering instant paper. tickets in a video 'format, its primary drawback is that it is a netwcrked on-line system. Every play (cutcome) 15 recuesced by the slave terminal must be downloaded on-line from the master processing unit.

Accordingly, this system is limited ir. that players can only engage in lottery play at specified ~locations.

Another on-line video gaming system is "disclosed in U.S. Patent No. 4,652,998. This system comprises a plurality of remote terminals networked to a central controller which generates a prize pool based upon a pool seed which is fed to a random 25 number generator. The central controller divides the prize pool into mini-pools, each of which has a known amount of low-end prize value all prizes of $25 or less). There are a selected number of larger prizes which are distributed among the mini-pools where some mini-pcols have a large prize and some have none. Mini-pools are assigned to each terminal for each game which is rendered on the terminal as needed. The remoce terminals have means for randomizing each mini-pocl assigned to the terminal using a mini-pool seed pr=vided by the central controller to feed a random number generator using a randomizing algorithm. When the central processor has assigned all mini-pools within a pool, the central processor creates a new pool. After players have played a sufficient number of cames to exhaust an entire mini-pool at a given remote terminal, it connects to the central controller and is assigned a new mini-pool. This system also -has significant limitations. Because the prize structure in the mini-pools is assigned to each remote terminal in a "dynamic state", the remote terminal is assigned active outcomes before a player engages in play, it is necessary to provide various security measures in the remote terminals to prevent an unscrupulous player from "looking ahead" "*by "hacking" the machine and determining the outcome 15 sequence in any given mini-pool. Otherwise, a player might learn at what point in the mini-pool a large win will occur for the game being played and then wait to play until when a favorable outcome is due to occur. This characteristic thus makes such a system unsuitable for an off-line arrangement where players are free to purchase "tickets" and view the outcomes at any location.

It is therefore desirable to provide an off-line system in which a player can enjoy games 25 having a predefined outcome determined by a lottery authority or the like on a gaming device, without the need to be physically or electronically linked to a central computer associated with the lottery authority during play, where "ticket" purchase and redemption of winnings may be done a- virtually any location, and where the lottery authority is not at risk of being cheated since there are no secrets scored in the device.

-6- SUMMARY OF THE INVENTION According to a first aspect of the present invention, there is provided a method of facilitating a sale of a gaming outcome, comprising receiving at a remote computer a s request by a player for at least one gaming outcome; determining at least one gaming outcome; arranging for the player to provide payment in exchange for the at least one gaming outcome and transmitting to the player from the remote computer an encoded message containing the at least one gaming outcome, in which the encoded message is for input by the player to a gaming computer, the gaming computer being off-line with 1o respect to the remote computer.

According to a second aspect of the present invention, there is provided a method of facilitating a sale of a gaming outcome, comprising transmitting to a remote computer a request by a player for at least one gaming outcome; arranging for the player to provide payment in exchange for the at least one gaming outcome; receiving by the player from the remote computer an encoded message containing the at least one gaming outcome; inputting by the player the encoded message to a gaming computer, the gaming computer being off-line with respect to the remote computer and receiving by the player the at least one gaming outcome from the off-line gaming computer.

These and other features and advantages of embodiments of the present invention will be better understood with specific reference to the detailed description which follows and the appended drawings.

25 BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic of the remote lottery system showing an LCC, Ats and HTV in a first embodiment; FIG. 2 is a block diagram of the LCC; FIG. 3 is a diagram of an exemplary memory arrangement in the LCC; FIG. 4 is a block diagram of the components in an HTV; FIG. 5 is a block diagram of the controller in the HTV; FIG. 6 is a diagram of an exemplary memory arrangement in the HTV; FIGS. 7A and 7B are a flow chart of an exemplary outcome purchase; [R:\LIBCC]04026.doc:gmm -7- FIG. 8 is a flow chart of an exemplary redemption sequence; FIG. 9 is a schematic of a random prize datastream showing an example of purchased and standby outcomes; FIGS. 10A and 10B are a flow chart of an exemplary outcome purchase sequence with standby outcomes; FIG. 11 is a flow chart of an exemplary redemption sequence with standby outcomes; r r (THE NEXT PAGE IS PAGE [R:\LIBCC]03449.doc:wxb were not lodged With this application FIG. 12 is a schematic of an alternative embodiment of the invention; and FIG. 13 is a schematic of another alternative embodiment or tne invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS With reference to the several views of the drawings, there is depicted a lottery system generally characterized in a first embodiment by the reference numeral 10, and principally comprised of a lottery authority 11 having. a LCC 12, a telecommunications network 14 which provides remote terminal access to the LCC 12, a plurality of agent terminals (AT) 16 associated with various lottery retailers 18, and a plurality of HTV units 20 which 15 reveal curchased "tickets" outcomes. The term "lottery authority" is used in the general sense and is intended to include any wagering authority which sells no choice scratch-off lottery tickets, bingo or a sweepstakes) or psuedo-choice video poker) games or races of skill having a predetermined outcome if the player plays correctly. The term "lottery retailers" includes any merchant where an AT 16 is located. As described in the foregoing, the term "ticket" as 25 used herein means a single outcome. Thus, the player is really purchasing outcomes from the LCC which are transferred to the HTV 20 and revealed through games generated on the HV 20. As will be explained in more detail below, the player need not go to a given lottery retailer to purchase outcomes.

It is anticipated that, in alternative embodiments, the LCC 12 and AT 16 may be combined inco a single unit or even into a system which enables outcomes tc be purchased over the telephone cr any iteractive communications network. Alternatively, outcomes could be purchased through RF communications between a transceiver associated with the LCC 12 and a transceiver associated with the HTV 20. These embodiments are described further below.

FIG. 1 is a schematic block diagram depicting an overview of the system components in the first embodiment. The LCC 12, telecommunications network 14 and ATs 16 are connected in similar fashion as those in the prior art used to dispense instant paper tickets. With respect to the present invention, each AT 16 may include a printer 22, bar code scanner or other scanning device 24, a communications interface 26 for physically coupling the HTV 20 to the AT 16 to electrically communicate signals with the HTV 20 through a compatible communications interface 92 in the HTV 20, and/or a 15 read/write interface 27 for reading and writing data to data memory media such as a smart card 26. These are used to transfer outcomes to the HTV 20 through an outcome transfer message OTM and will be described in more detail below. The smart card 28 20 may also be used to update game programs in the HTV to allow for the aeneration of new games. In this regard, new games may be transferred to the HTV 2C to inexpensively test them for market acceptance by players. The smart card 28 may also be used tc 25 transfer advertisina information in connection with lotteries in general.

FIG. 2 is a block diagram showing details of the LCC 12, which generally includes a CPU memory 32, an I/O interface 34 for loading programs into memory 32, and a communications interface for communicating through the nectork 14 with the ATs 16. The LCC 12 may also communicate through a base station network 15 with a clurality of base stations having transceivers for broadcasting and receiving RF signals to communicate messages directly between the LCC 12 and the H7V 20 in an alternative embcdiment described below and illustrated in FIG. 13. The LCC has software or firmware (hereinafter referred to as "programs" and "data") which are used to implement various functions in tne system. FIG. 3 depicts an exemplary memory arrangement of programs and data stored in the LCC 12. Memory 32 includes an operating system program 33 which controls the LCC 12 in a conventional manner and need not be described in detail. The LCC 12 has a memory area 36 in memory 32 for each HTV 20 in which specific information is stored to enable the LCC 12 to assign outcomes to that HTV 20 and to keep track of what has been assigned to that HTV 20 to provide for the "redemption of winnings and to ensure that the HTV 15 is a verified unit in connection wi:h a given *transaction. Data in memory 36 may be retrieved and updated as required in order to perform the desired functions. For purposes of convenience, the following description describes an HTV which is 20 registered to a single player. However, it is anticipated that an HTV 20 may contain multiple accounts for different players where access to the HTV 20 is made available through different passwords. An HTV 20 must be initially 25 registered with the lottery authority 11 prior to use. In this connection, identification information is initially stored in memory 32 of the LCC 12. The identification information includes a unit identifier or HTV ID szored in a field 37 and optionally a chaining variable stored in a field 38. I may constitute a 64-bit identifier which is unicue to each -HT 20. Similarly, C may constitute a 64-bit..representation of the histzry cf outcomes which have been purchased and transferred to the particular HTV 20. Accordingly, C is updated every time purchased outcomes are assigned to the particular HTV 20 as a one-way function of the -a23 outcomes purchased. Thus, C is unique to each 7TV because it is a record of all transactions made with respect to tha: HTV 20. In one exemplary embodiment, C is used as a way to prevent fraud by generating an outcome purchase request message OPRM as a function of both I and C in the HTV 20 where 0PRM is used to identify the particular HTV 20 during purchase and/or redemption transactions. In this regard, the current OPRM for that HTV 20 is stored in field 40 in the HTV memory area 36 in LCC memory 32 to enable the LCC 12 to compare the generated OPRM with the one stored in memory (which is updated each time outcomes are sold to the HTV 20) from the last transaction to verify the identity of the HTV 15 20. C and I may also be used as encryption or authentication keys as described below.

The LCC includes a program 42 for generating a random prize datastream 44 which is a pool containino a finite series of win/lose outcomes 0 n win lose, lose, win $10, lose, lose.... etc) The aggrecate cf all winning outcomes in any RPD 44 is a predetermined percentage payout of the total revenues to be generated by the sale of all "tickets" represented 25 by the outcomes in the RPD 44. When a purchase is made, the LCC 12 utilizes a "ticket" (outcome) purchase program 48 which randomly selects the next m outcomes from the RPD 44 (and possibly "standby outcomes" x to allow for reinvestment of winnings, this will be described below) to be assigned to a particular HTV 20. The outcome purchase program 48 then directs the LCC 12 co zenerate the c-tcome transfer messace OTM which is subsecently communicated to and read by the HTV 20 to enable the HTV 20 to reveal the outcomes. There are several ways in which this car be implemented. The outcome purchase program 48 will also direct the LCC 12 to 0 store the outcome transfer message OTM in field a record of the outcomes m assigned in field 52, and the standby outcomes x assigned in field 54.

Accompanying this data may be the price point for a given "ticket" (outcome) such as etc., in field 56, the net payoff in field 58, and the time/date in field 60. Thus, a record is generated in the LCC 12 for each transaction with a given HTV In one embodiment, each HTV 20 may be assigned a unique reference string ("HTVRS") which is stored in field 46. An identical HTVRS is stored in the particular EHT 20 as described below. The HTVRS is a random series of win/lose outcomes. When a 15 purchase is made, the outcome purchase program 48 directs the LCC 12 to find the same outcomes or a series of outcomes having the same net payoff in the HTVRS. These outcomes or the net payoff may be represented by one or more memory addresses in the 20 HTVRS. The outcome purchase program directs the LCC 12 to generate an outcome transfer message OTM which represents that address or addresses in the HTVRS.

The :TV 20 can interpret OTM to find the same outcomes or a series of outcomes with the same net 25 payoff in its very own HTVRS. This will be exclained in more detail below.

Another way in which the LCC 12 can assign outcomes is through the use of a one-way function which utilizes a seed value to generate a secuence of outcomes that are selected from the RPD 44. The HTV memory area 36 in the LCC memory 32 includes such a one-way function in field 62. An identical one-way function is stored in the HTV 20 as described below. The seed value for this one-way function becomes part cf an outcome transfer message

OTM.

Still another way the LCC can assign outcomes to the HTV 20 is by simply compressing the outcome sequence into a smaller code which is then decompressed in the RTV 20. Specifically, the LCC 12 has a compression/decompression program 64 which takes a series of m outcomes selected 3 3 +M by the outcome purchase program 48 and comDresses that sequence into a smaller variable which is part of an outcome transfer message OTM. As part of the compression process, the outcomes may 3 j+m be rearranged into a hierarchal order, number of losers, number of $1 winners, number of $2 winners, etc) if desired. Compression is useful in embodiments where the outcome transfer messace OT0 15 is printed on a receipt or rendered in the form of a bar code, to allow for manual entry of the outcome Stransfer message OTM into the HTV 20 or scanning the OTM as described below. Compression is also useful in the telephone embodiment shown in FIG. 12 and 20 described below where the player may communicate messages over the telephcne in response to suitable prompts. In this regard, compression and decompression may be used in combination with any of the other methods of transferring outcomes, such as 25 for example, where the HTVRS address is transferred.

In still another embodiment, the outcome purchase program 48 calculates the expected net payoff of the m outcomes and generates an outcome transfer message OTM which represents that net payoff. In this case, the HTV would randomly generate games which yield outcomes havinc that net paycff. This method is non suitable fcr standby outcomes.

In order tc provide for added security in the system, the outcome transfer messages OTM may he encrypted using keys known only to the LCC 12 and the particular HTV 20 stored in field 65. An authentication/encryption program 68 provides for the encryption and decryption of messages communicated from the LCC 12 and communicated to the LCC 12. Similarly, messages generated by the LCC 12 may be made authenticatable by appending message authentication codes stored in field 70 such tha: only a particular HTV 20 using keys known only to the LCC 12 and that HTV 20 can use the message. As described above, the chaining variable C and the unit identifier I may be used as keys to perform encryption/decryption and authentication.

Other programs resident in the LCC memory 32 include an accounting program 72 which calculates the running cash balance for each HTV 20 and stores 15 the same in an account 73 in field 74. The accounting program 72 is used to track the cumulative value of player winnings and losses after the player has cashed-out. The accounting program 72 enables the LCC 12 to duplicate a player's credit S 20 balance at any point in the outcome sequence.

The LCC memory 32 further contains an audit program 78 which stores a record of all transactions with a particular HTV 20 in field 76.

The LCC memory 32 also includes a redemption 25 program 79 which provides for verifying winnings to enable a player to cash-cut. The redemption program 78 is used to cash-out any winnings in a player's current credit balance. The redemption program 79 directs the LCC 12 to read a redemption request message RRM provided from the HTV 20. The redemption program also determines the number of standby outcomes which were actually used by the player. All of .this will be explained in more detail below.

In order to provide for tracking player history, data concerning a particular player may be stored in field 81 and bonus award data may be stored in field 80. In this manner, the lettery authority 11 can provide players with loyalty rewards such as free outcomes for total "tickets" purcnased or the like.

Referring now to FIGS. 4 and 5, the HTV 20 in a preferred embodiment is a hand-held unit having a controller 82, a display 84, and player controls 86.

Preferably the HTV 20 includes one or more cf the following: a printer interface 8Ea for connecting the HTV 20 to an external printer, an incernal printer 88b, a bar code scanner 90, a communications interface 92 compatible for connecting the HTV 20 to the communications interface 26 associated with an AT 16 to enable the HTV 20 to electrically 15 communicate directly with the AT 15, a read/write interface 94 for reading data from and writing daca to smart card 28, a modem 96 for connecting the HTV directly to a telecommunications network 14 coupled to the LCC 12 in an alternative embodiment shown in FIG. 12 and described below, and an antenna 115 coupled to a transceiver 113 for broadcasting and receiving messages to and from a base station 600 associated with LCC 12 in another alternative embodiment shown in FIG. 13 and described below.

The player controls 86 may be integrated into display 84 in a touch-screen arrangement of the type known in the art. The display 84 may also include the capability to render messages in a bar code readable format to enable them to be scanned by the bar code scanner 24 coupied to tne AT 15. The player controls 86 allow che player ct select various game, outcome transfer and redenmpion functions. The controller 82 includes a CPJ 93, a clock 101 and memory 100 comprised of RCM and RAM in a conventional arrangement. The controller 82 may be optionally housed in a tamer-eviden: enclosure to reveal to the lottery authority 11 any suspected tampering with the device. The CPU 98 communicates with the player controls 86 through a control interface 103, and with video generation hardware 104 for driving the display 84, and sound generation hardware 106 coupled to a speaker 108 for communicating game sounds. A voice activated circuit 110 of the type known in the art may be coupled to a microphone 112 to enable messages to be communicated to the CPU 98 by spoken commands. The CPU 98 communicates with the printer interface 88a or the internal printer 88b, bar code scanner 90, interface 92, read/write interface 94, and modem 96 through conventional I/O interfaces shown generally in the block diagram at 114. The CPU 98 may communicate 15 with RF circuitry 113 coupled to an antenna 115 for communicating messages directly with the LCC 12 via the base station as shown in the alternative embodiment in FIG. 13. In another application, the HTV 20 may have a GPS receiver 111 coupled to 20 antenna 115 which communicates position information to the CPU 98. In this manner :he HTV 20 can be prevented from operating unless it is located in a certain venue where gaming is permitted by a position enabling/disabling program in memory.

25 The outcome transfer message OTM may be communicated to the HTV 20 using the following protocols. In a first embodiment, the AT 16 prints the outcome transfer message OTM cn a receipt 30 and the agent provides the OTM to the player. The player simply enters the outcome transfer message OTM into the HTV 20 using the player controls 86.

Alternatively, the AT 16 may print the cuzcome transfer message OTM in a bar code readable format to enable the bar code scanner 24 to simply scan thr same. In either case, the receipt can be printed without ink using a carbonless two-part form which the player tears off to prevent anyone else from viewing the outcome transfer message 074 and then trying to input it to another HTV 20. In an alternative embodiment, the HTV 20 can connect to the AT 16 at interface 92 and the outcome transfer message OTM may be communicated directly to the HTV In another embodiment, the OTM may be written to memory in the smart card 28 through the read/write interface 27 connected to the AT 16. The player then plugs the smart card 28 into the HTV and the OTM may be read by the HTV 20 from the smart card 28. In a further embodiment, the outcome transfer message OTM may spoken into the microphone 112, either by the player, the agent or by an automated voice over the telephone in a telephone 15 embodiment shcwn in F:G. 12, and processed through the associaced voice activated circuit 110. In another telechone embodiment, the HTV 20 may be connected to the telephone network 514 directly and the outcome transfer message OTM may be communicated S 20 to the HTV 20 through the modem 96. In the embodiment shown in FIG. 13, the outcome transfer message OTM may be communicated from the LCC 12 0. through an RF transmission from either the AT 16 or the LCC 12. Redemption request messages RRM from the 25 HTV 20 to enable players to cash-out winnings may be similarly communicated.

Referring now to FIG. 6, there is depicted an exemplary memory arrangement 100 of programs and data in the HTV 20. Memory 100 includes an operating system generally indicated by the reference numeral 117 which controls the HTV 20 in a conventional manner. With respect to the present invention, the ocher programs and data in memory 100 enable the HTV 20 to read outcome transfer messages OTM from the LCC 12 and to process these messages in order to generate games which yield the outcomes. The HTV memory 100 may also include a position enable/disable program 101 which disables the HTV 20 when position information from the GPS receiver 111 indicates that the HTV 20 is located in a venue where gaming is impermissible. Information on gambling venues for use by the position enable/disable program may be stored in field 105.

As described above with respect to the LCC memory 32, each HTV stores a unit identifier I in field 116 and optionally a chaining variable C in field 118.

The HTV 20 may also store a serial number S in field 120. A password (or multiple passwords for multiple players on a single HTV 20) is stored in field 122.

When a player activates the HTJ 20, a password security program 124 checks the player's password in 15 a conventional manner before allcwinc the player to continue. The HTV memory 100 further includes an outcome purchase program 125 which directs the HTI to generate identification information to be S. transferred to the LCC 12, such as the outcome 20 purchase recuest message OPRM, and to read the outcomes represented in the outcome transfer message OTM. When read by the HTV 20, the outcome transfer message OTM is stored in memory 100 in field 129. If the outcome transfer message OTM is compressed by 25 the LCC 12, a compression/decompression program 130 is called by the outcome purchase program 126 to decompress the outcome transfer message OTM into the outcome secuence. The m outcomes are ]+m stored in field 132. If there are x standby outcomes O O assicned, these are stored S S+X in field 134. Accompanying this data may be the price point for each outcome in field 136, the nee payoff in field 138, and the time/date of enrry in field 140.

As described above with respect oc the LCC 12, the outcome transfer message OTM may represen: one or more memory addresses in a reference string -3 HTVRS. Accordingly, each HTV 20 may store an HTVRS in field 142. In such an embodiment, the outcome purchase program 126 directs the HTV 20 to find the sequence of outcomes or the net S 3j+m payoff on that sequence in the HTVRS.

Alternatively, the outcome transfer message OTM may represent a seed value for a one-way function in field 144. Thus, the outcome purchase program 126 directs the HTV 20 to generate the desired outcomes using the one-way function. The same 3 3 m one-way function is stored in the LCC memory 32.

As described above, the outcome transfer messages OTM may be encrypted by the LCC 12 to prevent them from being used in another HTV 20. A 15 authenticaticn/encryption program 146 using algorithms of the type known in the art provides for the encryption and decryption of such messages communicated to and from the HTV 20. In this *u connection, the HTV 20 may store special keys for 20 encrypting and decrypting such messages in field 148. Similarly, messages from the LCC 12 having message authentication codes may be authenticated by the authentication/encryption program 146 using keys known only to the LCC 12 and the particular HTV 25 stored in field 150. As described above with respect to the LCC memory 32, the chaining variable C which is unicue zo each HTV 20 may be used as a key to perform encryption/decryption and authenzication.

The HTV 20 includes a game generation program ("game program") 152 which provides for the generation of various games and win/lose scoring on the disolav 84. The game generation program may also include a tutorial for teaching players how to play the games and a help function for each game. These games can be generated with each having either a win .or lose outcome exactly corresponding to each outcome represented by :he outcome j ]+m )0 transfer messaae OTM. Thus, the ame merely interprets or reveals the outcome. Alternatively, the games may be generated such that an m number of games have a net payoff equal to the net payoff in the series O Oj+m. The latter is not suitable for embodiments where standby outcomes are assigned as described below. A single game may have multi-le chances but only one outcome. The game program 152 generates "no-choice" or non-skill games with a predetermined outcome such as, for example, the type commonly associated with pull-tab type instant lottery tickets, a sweepstakes, or bingo; or suedo-choice games with a predetermined outcome such as video poker. In the case of the latter, the 15 outcome for a particular poker game is predetermined with a maximum payoff which is recovered if the player plays every hand correctly. If the player plays incorrectly, the payout is less than the 20 maximum represented by the outcome for a particular game. In addition, the game program 152 may generate games which are races of skill such as crossword puzzles or word descrambler games which must be completed within a specified period of time. If the player completes the game in the time allotted, the 25 player is paid the predetermined payoff on the outcome selected for that game. If not, a win is not credited to the HTV account 155 described below.

Programs for generating such games are known in art.

The game program 152 can be designed to require a game identifier such that the lottery authority 11 selects which games are to be played in connection with any outcomes that are sold. n this reard, the outcome transfer message OTM may include an instruction for the game program 152 to generate a specific game for those outcomes. In order to provide for updating games in the HTV 20, new came programs could be loaded into memory 100 in a -33 conventional manner through the smart card 23 cr by plugging the HTV 20 into the AT 16 as described above and then uploading the appropriate software instructions.

The HTV memory 100 also includes an accounting program 154 which directs the HTV 20 to calculate the running cash balance which is stored in an account 155 in field 156. If there are several players assigned to a given HTV 20, there may be individual accounts for each player.

The HTV memory further includes a redemption program 158 which is used to cash-our the player's current credit balance in the player's account 155.

The redemption program 158 enables the player to S 15 select a cash-out function on the HTV 20. The redemption program 158 then directs the HTV 20 to c generate a redemption request message RRM which is communicated to the LCC 12 using methods similar to the way in which outcome transfer message OTM was 20 communicated to the HTV 20, but in reverse.

Redemption request messages RRM are used by the redemption program 79 in the LCC 12 to verify cash-out requests by comparing HTV identification data and outcome data (net winnings, the number of 25 games played) for a given HTV 20. The redemption request message RRM may be generated on the display 84 of the HTV 20 and orally provided to the agent at a lottery retailer 18 for manual entry into the AT 16. The redemption requesz message RRM can be printed onto a receipt 30, either by an internal or external printer 88b associated with the HTV 20, or by a printer 22 at the lttcery retailer via the printer interface 88a, which receipt 30 is then provided to the agent. In this connection, the redemption request message RPJ4 may be rendered on the display 84 or on the receipt 30 in a bar code readable format and scanned by the bar code scanner 3 24 at the AT 16. In another embcdimenz, the redemption request message RRM may be written to the smart card 28 and then read therefrom by the AT 16.

In yet another embodiment, the redemption reauest message RRM can be communicated to the LCC 12 over the telephone network 14 via the modem 96. In still another embodiment, the redemption request message RRM may be communicated from the HTV 20 to the LCC 12 through an RF transmission to either the AT 16 or the LCC 12. The redemption request message RRM may be encrypted by the HTV 20 using the authentication/encryption program 146 in memory 100 for subsequent decryption by the LCC 12 using the authentication/encryption program 68 in memory 32.

15 The redemption request message RRM can be encrypted using encryption keys known only to the LCC 12 and the specific HTV 20. These may include the uni: identifier I and the chaining variable C.

The HTV memory 100 also includes an audit 20 program 160 which stores a record of all activity performed on the HTV 20 in field 161 to assist in protecting data integrity and to verify that the various programs in memory 100 have not been tampered with. The audit program 160 further provides a record of player activity for the player "and the lottery authority 11 in the event of any discute.

Referring now to FIGS. 7A and 7B, there is shown a flowchart of an exemplary outcome purchase of m "tickets" (outcomes) from the LCC 12 through an AT 16 at a lottery retailer 11. For convenience, the following assumes all outcomes are purchased at a single price point. However, the outcomes purchased from the RED 44 may represent different price points and may be purchased separately by obtaining an outcome transfer message for each price point, or together by generating an outcome transfer message OTM which represents outcomes having different price points. To begin the purchase sequence, the player first activates the ETV 20 and enters his or her password which is checked by the password security program 124. The player then selects the purchase "ticket" function at step 300.

The outcome purchase program 126 directs the HTV to generate an outcome purchase request message OPRM as a one-way function of I and C at step 302. The player provides the OPRM to the agent at the lcttery retailer 11 at step 304. The agent then enters the OPRM into the AT 16 which transmits the OPRM to the LCC at sceD 306. The serial number OPRM could alsc have been provided to the agent by any of the above 15 described methods of communicating an outcome transfer message OTM or a redemption request message RRM as described above. The LCC 12 runs its outccme purchase program 48 at step 308 which extracts I and C from S for that HTV 20. At step 310, the LCC compares I and C with the values for I and C stored in fields 37 and 38, respectively, in the HTV memory area 36 for that HTV 20. As described above, I and C nare initially stored in the LCC 12 when the particular HTV is registered with the lottery 25 authority 11. C for a given HTV 20 is updated using a one-way function every time outcomes are transferred to that HTV 20. If I and C match, then the LCC 12 sends a ready code to the AT 16 at sce 312. If not, then the LCC 12 denies the outcome purchase request because the H/T 20 is not registered or has been altered in some way at step 314. If the iTV identification is valid, the player then provides the agent with the numr~er of outcomes m to be purchased for a given pice point a: step 316. The agent enters m and the price point into the AT 16 at step 318. The AT 16 transmits m and the price point to the LCC at step 320. The outcome purchase program 48 in LCC memory 32 then randomly selects the next m unsold outcomes 3 3+m for that price point from the RPD 44 at step 322. I: also directs the LCC 12 to store the outcomes in field 52, the price point in field 56, the net-payoff in field 58 and the time/date in field 60. The LCC 12 then generates an outcome transfer message OTM at step 324 using any one of the methods described in the foregoing. The LCC 12 can also store the outcome transfer message CTM for the given purchase in memory in field 50. As discussed in the foregoing, the LCC 12 can use the authentication/encryption program 68 to encrypt the outcome transfer message OTM, in this example firs: 15 using I as an encryption key and then using C as an ~encryption key at step 326 (the OTM need not be encrypted, it could be made authenticatable by appending message authentication codes which are Sauthenticated in the HTV 20 by keys known cnly to 20 the LCC 12 and the HTV 20). It then updates C as a one-way function of the outcome transfer message C=f(OTM), and scores the new value for C in field 38 at step 328. The LCC 12 then transmits the outcome transfer message OTM to the AT 16 at step 330. The 25 AT prints a receipt 30 containing the OTM, the date, time, price point and m at scep 332. The agent then provides the receipt 30 containing the outcome transfer message OTM to the player, and the player pays the agent at step 334. At this time, an outcome purchase confirmation message is communicated from the AT 16 to the LCC 12 at sceD 336 which indicates that the player has "irrevocably" purchased the outcomes represented by the outcome tra.nsfer message OTM. The claver then enters the cuccome transfer message OT. into the HTV 20 at scep 338. The HTV runs the authentication/encryption program 146 to decrypt the outcome transfer message CTM firs: using -37 C as the key and again using I as the key a: step 340. The outcome transfer message CTM is then scored in field 128 in HTV memory 100 at step 342. If the outcomes are simply compressed into a sequence (FIG. the decompression/ 3 3+m compression program 130 will decompress the sequence and store the same in field 132. The outcome purchase program 130 may also store the price point in field 136, and net payoff in field 138. If the outcome transfer message OTM represents an address in the HTVRS, the cuccome purchase program 130 will search the HTVRS stored in field 142 for that address or an address where a series of outcomes reside with the same net payoff as If 3 15 the outcome transfer message OTM represents a seed value for a one-way function stored in field 144, the outcome purchase program 130 will use the seed value to generate the same series of outcomes 0 Alternatively, the outcome transfer ]+mj m message OTM may simply represent the net-payoff on a number of m outcomes in which case 3 ]+m the game program 152 generates a number of cames with the same net pavoff. Once the outcome messace OTM has been scored in step 342, the outcome purchase proaram 126 updates C as a one-way function of OTM and stores the new value for C in field 118 at step 344. Thus, both the H7T 20 and the LCC 12 have new values for C scored in memory. The player then plays games on the HTV 20 generated by the game program 152 which yield the outcomes cr the net payoff on those outcomes a: stec 346.

The player's account balance is updated by the accounting prcgram 154 as each outcome is revealed and stored in account 155 in field 156 a: ste 348.

FIG. 8 is an exemplary cash-ouc sequence Ln the embodiment described above. Essencially, the 2C identifies itself co the LCC 12 and the LCC 12 -3 authorizes a payoff cn the outcome sequence sold to that HTV 20. To begin the redemption sequence, the player first activates the HTV 20 and enters his or her password which is checked by the password security program 124 as described above. The player then chooses the cash-out function at step 350. The redemption program 158 in HTV memory 100 generates the redemption request message RRM, in this example, as a function of I and C at step 352. Thus, the redemption request message RRM is similar to the outcome purchase request message OPRM described in the outcome purchase sequence of FIGS. 7A and 7B.

The RRM may also include the updated cash balance in 15 account 155 which represents the payoff on the outcomes which were revealed. The value for C was undated as a one-way function of the outcome transfer message OTM at step 344 above. The value for C was also updated in the LCC memory 32 at scep 20 328 above. The player provides the redemption request message RRM to the agent at step 354. The agent then activates a redemption function on the AT 16 at step 356. The agent enters the redemction request message RRM into the AT 16 which transmits 25 the RRM to the LCC 12 at step 358. The LCC 12 tnen runs the redemption program 79 which verifies the redemption request message RRM by extracting I and C and comparing the values for I and C with the values stored in memory 32 in fields 37 and 38, respectively, at step 360. f I and C do noc matcn the expected values at step 362, the LCC 12 denies the cash-out request a- step 364. If I and C ma:cn the excected values at step 362, then at step 364 the LCC 12 checks the cash balance embcdied in ze redemption request message RFM against the amcunt i calculated (the payoff stored in field 58 for that outcome sequence) as a result of the sale of the outcomes to the HTV 20 and s:ored previously in the ETV account 73 in field 74. The LCC 12 chen sends a validation message to the AT 16 a: step 368 and the amount is debited in account 73. The player may opt to purchase more outcomes with the present cash balance in account 73 a: step 370, in which case the outcome purchase sequence shown in FIG. 7 may be repeated. Alternatively, the player is paid by the agent at step 372.

As described briefly above, an outcome purchase request for m outcomes may be j 3+m accompanied by x standby outcomes 0 O0 The standby outcomes are suoplied in a number sufficient to exhaust all winnings, or so as to generate a 15 large win at some point in the sequence above a predetermined value where the outcome purchase 9**9 program 126 in the HTV 20 will direct the HTV 20 to stop generating games and provide a cash-out instruction on the display 84. Referring now to 20 FIG. 9, there is shown a portion of an RPD 44 with five purchased outcomes which have a net-payoff of $16. In this example, the outcome purchase program 48 in the LCC 12 has selected twenty four (24) standby outcomes 25 O O in two groups as shown. The standby s s+x outcomes can be selected from anywhere in the RPD 44 but the groups are played in order. The relative positions between the purchased outcomes m and the standby outcomes x shown in the RPD 44 are merely exemplary. For the purpose of this example, all outcomes are curchased for The player wins $16 on the purchased outcomes O 0 If the player spends that $16 on the first group of sixteen (16) standby outcomes and those outcomes yield a net payoff of the next group may constitute eight outcomes which yield a net payoff of zero in the first example (full exhaustion of winnin-gs) r some large prize $500 represented by the fourth outcome in the order showr in the second example for the second group.

Referring to the second example, if the outcome sequence in the second group is played in order, and the sequence of outcomes is lose, win win $1, win $500, the player retains $4 in winnings after the first standby group is played and $2+$1+$500 in the second group for a net win of $507. The game program 152 in the HTV 20 will direct the HTV 20 to generate a cash-out message when such a large outcome is revealed. If there are any remaining standby outcomes, in this example four losers, these will be voided in the HTV 20 by the redemption program 158. Similarly, those four standby outcomes will be voided in the LCC 12 when the LCC 12 is provided with a redemption request message RPR which .represents all outcomes transferred to that HTV including the m purchased outcomes, and the x S. 20 standby outcomes. Since the player may choose to cash-out at some time during the sequence before all standby outcomes are revealed, the redemption ."request message RR-. generated by the HTV represents which standby outcomes were revealed by the HTV 20 and enables the LCC 12 to compute the o proper payoff and to void any unused standby S~ outcomes in the LCC 12.

Referring now to FIGS. 10A and 10B, there is shown an exemplary flowchart of an outcome purchase sequence including m purchased outcomes and x standby outcomes 0 O 3 3+m s s+x The protocol in the example is similar to what happens in FIG. 7, so redundant steps will not be repeated. At step 400, the outcome purchase program 48 in LCC memory randomly selects m purchased outcomes C .O and x standby outcomes 1 j+m 0 0 fr=m the RPD 44. The LCC 12 then s s+x 4-/ generates an cuccome transfer message OTM representinc the m outcomes and x standby outcomes at step 402. The outcome transfer message may consist of a compressed sequence, address for outcomes in the HTVRS or a seed value for a one-way function as described above. The LCC 12 can update C as a function of the outcome transfer message OTM and store the same in memory as described above at step 404. Once the outcome transfer message OTM has been read and authenticated (if authenticatable) or decrypted (if encrypted), it is stored in memory 100 in field 128 in the ETV 20 at step 406. In this regard, the m outcomes may be stored j 3+m in field 132 and the standby outcomes 15 0 0 may be stored in field 134 of the S- s s+X S.E1 HTV memory 100. The same data has been stored in the LCC memory 32. At step 408, the HTV updates C as a Sone-way function of OTM. The HTV 20 then generates games which yield the m outcomes O 0 or 20 the net payoff on those outcomes at step 410. The HTV 20 utilizes the accounting program to update the cash-balance in account 155 at step 412. Up to this point, the protocol is generally the same as shown *CC* in FIG. 7. At step 414, the outcome purchase program 126 directs the HTV 20 to display the option to reinvest the cash-balance (winnings) in account 155.

SIf the player wishes to cash-out, the cash-out sequence in FIG. 7 may be followed. If the player wants to reinvest, the game program 152 will generate a game which yields a standby outcome in 0 0 at step 416. The accounting program s s+x 154 in the HTV 20 updates account 155 with a new cash-balance and displays the updated balance to the winner on the display 84, depending upon whether the standby outcome was a winner or loser a: step 418.

The outcome purchase program 126 then voids the last standby outcome revealed at step 420 and updates the status (to "revealed") of that outcome i. the sequence of standby outcomes stored in field 54. If the last standby outcome revealed generates a large prize over some predetermined threshold a: step 422, the outcome purchase program 48 directs the HTV to display a message to the player that he or she must cash-out at step 424. The player goes through the redemption sequence in FIG. 11. If not, the outcome purchase program 48 checks to determine whether there are any unused standby outcomes remaining in field 54 at step 426. If not, the player has exhausted the cash-balance in account 155 and the HTV 20 generates a zero cash-balance on the S*.o display 84 at step 428. If standby outcomes remain, 15 the player chooses whether to continue to reinvest at step 430. If the player selects reinvestment, the ETV 20 will generate another game which yields the next standby outcome at step 416. If the =layer elects to cash-out, the HTV 20 indicates the 20 cash-balance in account 155 at step 432 and the player goes through the redemption sequence in FIG.

1..

~Referring now to FIG. 11, there is shown an exemplary cash-out sequence when there are standby 25 outcomes. To begin the redempticn sequence, the player first activates the HTV 20 and enters his or her password which is checked by the password security program 124 as described above. The player initiates the cash-out function at stec 500. The redemption program 158 in HTV memory 100 generates a status record of the standby outcomes and the accompanying cash balance in account 155 RSEY at step 502 and a redemption request message RR as a function of I and C which appends RS3Y a: stec 504.

The redemption program 79 also voids any unused standby outcomes stored in field 54. The redemotion request message RRM may be compressed by the -43decompression/compression program 146 in HTV memory 100 into a smaller message since the record of standby outcomes may be lengthy if the RRM is to be displayed on the HTV display 84 or printed out on a receipt 30 (either in alphanumeric form or in a bar code readable format). This example describes an embodiment where the player provides the redemption request message RRM to an agent at the lottery retailer 18 at step 506. As described above, the redemption request message may be communicated to the AT 16 through other methods. The agent selects a redemption function on the AT 15 at step 508. The .acent then enters the redemption request message RRM into the AT 16 and the AT 16 communicates the S 15 redemption request message RRM to the LCC 12 a: stec 510. The LCC then runs the redemption program 79 to verify the redemption request message RFM by extracting RSBY, I and C and comparing the values for I and C with those stored in memory 100 in 20 fields 37 and 38, respectively, at step 512. If I and C do not match the expected values at steo 514, the LCC 12 denies the cash-out recuest a: step 516.

If I and C match the expected values at step 514, then the LCC 12 uses the accounting program 154 tc 25 calculate the payoff on the standby outcomes represented in RSBY and credits the HITV account 155 in field 156. The LCC 12 then voids any unused standby outcomes represented in the RSBY at step 520. The LCC 12 then sends a validation message tc the AT 16 at step 522.

Referrinc now to FIG. 12, an LCC 12 is coumled to a telecommunications network 14' havinc interactive voice capability and is accessible by dialing a 90C number or the like to enable the outcome purchase and redemption to be effec:uated over the telephone 13. Alternatively, the telecommunications network 14' may be any interactive communications network, includinz the Internet. The protocol is similar to that described above with regard to purchase and redemption at an AT 16, except here the player simply keys the information into the telephone 13 in response to prompts from the system. Thus, the player firs: communicates the HTV identification information in the form of an outcome purchase request messace OPRM to the LCC 12. If HTV identification/registration is confirmed, the LCC 12 then provides a "ready' indication to the player with instructions to select the number of outcomes to be purchased for each price point. The LCC 12 then generates an cutcome transfer message OTM as described above which the player manually keys into the HTV 20. The system operates Similarly to redeem winnings. The HTV generates a redemption request message RRM, and the player keys the redemption request message inzo the telephone. The redemption request message RRM is 20 communicated to the LCC 12, which verifies the identity of the HTV 20 and the expected payoff. A credit is then made to an account for the HTV/player in the LCC 12. In a modification of this embodiment, the HTV 20 contains a modem 96 which enables it ts 25 communicate directly over the telecommunications network 14' to communicate outcome transfer messages OTM from the LCC 12 to the HTV 20 and redempticn request messages RRM from the HTV 20 tc the LCC 12.

Alternatively, the HTV 20 may incorporate a cellular phone (not shown) for the same purpose. This embodimen- is still considered to be an off-line arrancement as there is no need to have an cn-line connection between the HTV and the LCC during play.

In a further embodimen: shown in FIG. 13, te LCC 12 communicates through a base station network with a cluraliyv of base stations 630 for broadcasting and receiving RF messages. The HTV -4 also includes a transceiver 113 for broadcasting and receiving RF communications such that all purchase and redemption functions may be implemented without the need for the player to travel to a lottery retailer. The protocol is similar to that described above with respect to the other embodiments.

.i 320

Claims (14)

1. A method of facilitating a sale of a gaming outcome, comprising: receiving at a remote computer a request by a player for at least one gaming outcome; determining at least one gaming outcome; arranging for the player to provide payment in exchange for the at least one gaming outcome; and transmitting to the player from the remote computer an encoded message 1o containing the at least one gaming outcome, in which the encoded message is for input by the player to a gaming computer, the gaming computer being off-line with respect to the remote computer.

2. The method of claim 1, in which receiving comprises: Is receiving the request from the player via a numeric keypad of a telephone.

3. The method of claim 1, in which transmitting comprises: transmitting the encoded message to the player via a telephone.

4. The method of claim 1, in which at least one of the at least one gaming outcome is a lottery outcome.

5. The method of claim 1, further comprising: receiving a financial account identifier that is associated with the player.

6. The method of claim 1, in which the remote computer has no electronic 6% o communication link with the gaming computer.

7. The method of claim 1, in which the encoded message is in human recognizable 30 format.

S8. A method of facilitating a sale of a gaming outcome, comprising: transmitting to a remote computer a request by a player for at least one gaming •outcome; [R:\LIBCC]04026.doc:gnUn -47- arranging for the player to provide payment in exchange for the at least one gaming outcome; receiving by the player from said remote computer an encoded message containing the at least one gaming outcome; inputting by the player the encoded message to a gaming computer, the gaming computer being off-line with respect to the remote computer; and receiving by the player the at least one gaming outcome from the off-line gaming computer. 1o

9. The method of claim 8, in which transmitting comprises: transmitting the request via a numeric keypad of a telephone.

The method of claim 8, in which receiving comprises: receiving the encoded message from the remote computer via a telephone.

11. The method of claim 8, in which at least one of the at least one gaming outcome is a lottery outcome.

12. The method of claim 8, further comprising: transmitting to the remote computer a financial account identifier that is associated with the player.

13. The method of claim 8, in which the remote computer has no electronic i communication link with the gaming computer.

14. The method of claim 8, in which the encoded message is in human recognizable format. o. o• ooo [R:\LIBCC]04026.doc:gmm