Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND APPARATUS FOR STORING A PLURALITY OF WAGER DATA FROM A PLURALITY OF INDIVIDUAL WAGERS IN A LOTTERY DRAW GAME
Document Type and Number:
WIPO Patent Application WO/2019/008424
Kind Code:
A1
Abstract:
A plurality of wager data is stored from a plurality of individual wagers in a lottery draw game using n number of non-volatile data storage devices, and a volatile data storage device. The wager data for each individual wager includes wager selection, wager amount, draw game identifier, and a unique wager identifier. A mathematical operation, such as a modulus function, is performed on at least a portion of wager data for each of the individual wagers which causes the plurality of wager data to be distributed among n sets. The wager data for each of the individual wagers is stored in the nth non-volatile data storage device as distributed among the n sets. After the wager data is stored in the n non-volatile data storage devices, at least a portion of the wager data for each of the individual wagers is stored in the volatile data storage device. The stored portion of the wager data includes at least the wager selection, and the unique wager identifier.

Inventors:
HOPKINS, Alistair (Berthen Gron, Deiniolen, Gwynedd LL553LU, LL553LU, GB)
TUFAIL, Tariq (Tan Twr, Ffordd Caergybi, Llanfairpwllgwyngyll LL615YL, LL615YL, GB)
Application Number:
IB2017/056378
Publication Date:
January 10, 2019
Filing Date:
October 13, 2017
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INSPIRED GAMING (UK) LIMITED (1-2 Berners Street, London W1T3LA, W1T3LA, GB)
International Classes:
G07F17/32
Domestic Patent References:
WO2014066986A12014-05-08
WO1995023383A11995-08-31
Foreign References:
US20110289351A12011-11-24
US7788482B22010-08-31
US8037307B22011-10-11
US20090131132A12009-05-21
US20030050109A12003-03-13
US20040058726A12004-03-25
US20090227320A12009-09-10
US20100222136A12010-09-02
US20110281629A12011-11-17
US20130244745A12013-09-19
US8747209B22014-06-10
Download PDF:
Claims:
CLAIMS

1. A method for storing a plurality of wager data from a plurality of individual wagers in a lottery draw game using (i) n number of non-volatile data storage devices, and (ii) a volatile data storage device, wherein the wager data for each individual wager includes wager selection, wager amount, draw game identifier, and a unique wager identifier, the method comprising:

(a) performing, in a computer processor, a mathematical operation on at least a portion of wager data for each of the individual wagers, the mathematical operation causing the plurality of wager data to be distributed among n sets;

(b) storing the wager data for each of the individual wagers in the nth non- volatile data storage device as distributed in step (a); and

(c) after the wager data is stored in the n non-volatile data storage devices, storing at least a portion of the wager data for each of the individual wagers in the volatile data storage device, the stored portion of the wager data including at least (i) the wager selection, and (ii) the unique wager identifier.

2. The method of claim 1 further comprising:

(d) receiving and storing bets in a non-volatile data storage bet queue.

3. The method of claim 2 where the non-volatile data storage bet queue receives bets in real time from a wager interface.

4. The method of claim 2 further comprising:

(d) during a system outage for the lottery draw game, the non-volatile data storage bet queue receives saved bets from the non-volatile data storage devices to expedite reconstruction of the wager data in the volatile data storage device.

5. The method of claim 1 further comprising:

(d) generating, in a report processor, summary data of at least a portion of the wager data for each of the individual wagers, the summary data being a subset of the wager data and including at least (i) the wager selection, and (ii) the unique wager identifier, wherein the wager data stored in the volatile data storage device is the summary data.

6. The method of claim 1 wherein the wagers are embodied by tickets, and the unique wager identifier is a unique ticket identifier.

7. The method of claim 1 wherein the draw game identifier includes (i) draw date, (ii) type of draw game, and (iii) bet type.

8. The method of claim 1 wherein the distribution is about even among the n sets, the wager data for each of the individual wagers thereby being about evenly distributed among the n numbers of non-volatile data storage devices.

9. The method of claim 1 wherein the mathematical operation is a modulus function.

10. A system for storing a plurality of wager data from a plurality of individual wagers in a lottery draw game, wherein the wager data for each individual wager includes wager selection, wager amount, draw game identifier, and a unique wager identifier, the system comprising:

(a) a computer processor configured to perform a mathematical operation on at least a portion of wager data for each of the individual wagers, the mathematical operation causing the plurality of wager data to be distributed among n sets;

(b) n number of non- volatile data storage devices that store the wager data for each of the individual wagers in the nth non- volatile data storage device as distributed in accordance with the mathematical operation; and

(c) a volatile data storage device that stores at least a portion of the wager data for each of the individual wagers therein after the wager data is stored in the n non-volatile data storage devices, the stored portion of the wager data including at least (i) the wager selection, and (ii) the unique wager identifier.

11. The system of claim 10 further comprising:

(d) a non-volatile data storage bet queue that receives and stores bets.

12. The system of claim 11 where the non- volatile data storage bet queue receives bets in real time from a wager interface.

13. The system of claim 11 wherein during a system outage for the lottery draw game, the nonvolatile data storage bet queue receives saved bets from the non-volatile data storage devices to expedite reconstruction of the wager data in the volatile data storage device.

14. The system of claim 10 further comprising:

(d) a report processor that generates summary data of at least a portion of the wager data for each of the individual wagers, the summary data being a subset of the wager data and including at least (i) the wager selection, and (ii) the unique wager identifier, wherein the wager data stored in the volatile data storage device is the summary data.

15. The system of claim 10 wherein the wagers are embodied by tickets, and the unique wager identifier is a unique ticket identifier.

16. The system of claim 10 wherein the draw game identifier includes (i) draw date, (ii) type of draw game, and (iii) bet type.

17. The system of claim 10 wherein the distribution is about even among the n sets, the wager data for each of the individual wagers thereby being about evenly distributed among the n numbers of non-volatile data storage devices.

18. The system of claim 10 wherein the mathematical operation is a modulus function.

Description:
METHOD AND APPARATUS FOR STORING A PLURALITY OF WAGER DATA FROM A PLURALITY OF INDIVIDUAL WAGERS IN A LOTTERY DRAW GAME

COPYRIGHT NOTICE AND AUTHORIZATION

[0001 ] Portions of the documentation in this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

1. FIELD OF THE INVENTION

[0002] The present invention relates to lottery draw game network systems that are typically installed within a lottery's jurisdiction and are normally controlled from a central site with a large infrastructure such as Storage Area Networks ("SANs"), databases, application servers, and network infrastructure that is managed with a team of skilled system administrators, network specialist, and technicians. Specifically, the present invention provides efficient and scalable methods of constructing draw game network systems at a substantial cost savings with hitherto unknown real time monitoring and status capabilities.

2. BACKGROUND

[0003] Whenever a lottery is established in a jurisdiction, a network comprising special purpose lottery terminals, communications links, and central site system(s) are installed. In large jurisdictions, the costs of installing this system can be onerous. Thus, the lottery network system is extensive with lottery terminals physically placed in every lottery retailer's place of business, a closed communications link (e.g., Virtual Private Network— "VPN"), and a central site. This equipment and a closed network system is typically created, installed, and maintained by a lottery vendor at significant expense. In some lottery jurisdictions (e.g., Florida, New York, California, France, Pennsylvania) the number of field terminals and associated individual closed network connections can number in the tens of thousands. In fact, it is not unusual for lottery vendors to report decline in revenue the next fiscal quarter or two after winning a major lottery system contract due to the substantial upfront investment required to manufacture and place the multiplicities of lottery terminals in the field, setup the network, and develop the central site.

[0004] In addition to the significant costs to the lottery vendor, the lotteries themselves are also burdened with the size and complexity of the lottery network system.

Flattening sales curves for lottery products have forced lotteries to negotiate smaller and smaller margins from lottery vendors. However, given the significant draw game lottery network system infrastructure costs, there are limits to the margin reductions offered by vendors.

[0005] Another cost element is the lottery draw game ticket itself. In most instances, mere possession of a winning lottery ticket entitles the holder to the winnings. Thus, authentication of the presented lottery ticket is critically important. For example, lottery draw game tickets which are common in many countries and states are, by necessity, printed and presented to the purchaser in real-time with transactional data printed on the lottery ticket via a thermal or impact printer. To enhance security, lotteries typically use preprinted ticket stock with serial numbering on the back of the printing substrate as well as fluorescent and other inks on the ticket substrate to help prove authenticity and integrity. The preprinted serial numbering provides much of the security in determining the authenticity of a winning ticket because the distribution of the preprinted serial number ticket stock is maintained by an entity separate from the one controlling the printing of transactional data. When a winning ticket is presented for redemption, an audit trail can be established between the ticket stock serial number and the transactional data.

[0006] However, this added paper stock security has the disadvantage of high cost, as well as the logistics of tracking the ticket stock. Also, the labor-intensive nature of correlating the ticket stock to a draw game lottery ticket printed at a given retailer at a given time typically prohibits the method's use for all but high-tier winning tickets. Finally, it may be possible for an insider with access to the system controlling the printing of transactional data to simply purchase a lottery ticket from a retailer shortly after it was determined that that a high tier winner was sold at that location to thereby gain illicit knowledge of the appropriate ticket stock serial number range. While some notable attempts have been made to eliminate the need for security paper stock for bet tickets— e.g., U.S. Patent Nos. 7,788,482 (Irwin) and 8,037,307 (Irwin)— the industry has been reluctant to adopt these cost savings technologies primarily due to the complexity of the draw game system and network with the inherent concern that any realized savings in paper will be offset by increased latency times when issuing draw game tickets.

[0007] In addition to costs, traditional lottery draw game lottery network systems tend to be relatively static and inflexible designs comprised of Oracle or other SQL

(Standardized Query Language) database cluster for software with high end servers and storage SANs for the storage infrastructure. System scalability with this type of configuration is notoriously difficult, typically with a "one size fits all" design approach with most lottery central sites being scaled for the largest conceivable system perhaps with smaller systems receiving slower processors. As is apparent to one skilled in the art, this type of system configuration does not readily accommodate economies for smaller lotteries and can potentially introduce problems in the future if new draw games are introduced that were not foreseen by the original system architects. Furthermore, this relatively inflexible system design also does not readily

accommodate redundancy with backup central sites that are basically a copy of the primary site typically located in a different geographical location with high speed communications channels linking the two sites to ensure synchronization.

[0008] Furthermore, the relatively static and inflexible designs typical of Oracle or SQL database clusters of the prior art, prohibit draw game cancellation of a bet or wager once it is made. At the very least, this probation on canceling already logged wagers is an

inconvenience to the retailer often forcing him or her to pay for wagers if the consumer claims to "not have wanted those numbers" or simply walks away.

[0009] Aside from cost, scalability, and operability issues, the complexity of traditional lottery network systems inherently prohibits accessing draw game betting data in real time— i.e., the requirements to print bet tickets within a relatively short time period (e.g., less than three seconds) typically prohibit most types of real time data mining for fear of slowing bet processing and ticket printing. This prohibition of real time data mining other than cursory information (e.g., total number of tickets or bets sold) impacts potential features that could possibly increase sales.

[0010] For example, most large draw games (e.g., Powerball ® , Mega Millions ® ) are parimutuel in nature (i.e., where the pools of winnings are equally shared amongst all winners of a particular level) with the consequence of a large number of winners for any given drawing will result in each winner realizing a significantly reduced prize. Frequently, the most played numbers in Powerball are "01-11-21-31-41 with a Powerball of 09" because on many lottery Powerball bet slips coloring in these areas produces a diagonal line pattern. Additionally, on one occasion, one hundred and ten winning Powerball players all played "22-28-32-33-39 with a Powerball of 40" due to a collective fortune cookie prediction— i.e., each player making the "22-28-32-33-39 with a Powerball of 40" wager did so because of the same fortune cookie ticket. If it were possible to inform a player before making a bet that "X" number of players have already made this wager, the correspondingly decreased return on investment of a group of winners sharing a common prize fund would be flagged, potentially increasing sales.

[0011 ] In addition to potential sales enhancements, real time data mining during draw game wagering also has the potential to increase security. For example, at least one United States (US) national draw game (i.e., "Hot Lotto""') was compromised by an insider who fraudulently purchased on the 23 of December 2010 a draw game ticket that ultimately won $14,300,000 in a subsequent "Hot Lotto" drawing. Apparently, the fraud was committed by the insider installing a software "root kit" that forced the outcome with the Random Number Generators (RNGs) used for the errant "Hot Lotto ® " drawing to generate predetermined numbers. However, since there were two RNGs employed with the output of only one RNG used for the "Hot Lotto" drawing, the insider not knowing which RNG would be used for the official drawing was forced to purchase winning tickets for both possible RNG outcomes. Thus, a realtime search through all purchased draw game ticket bets for a given drawing that was conducted immediately after the drawing was concluded, but before the results were made public, could potentially flag fraud in this type of situation assuming winning tickets when both RNG outcomes were purchased for the same drawing.

[0012] Prior art related to providing real time processing and updates of bets for parimutuel wagering systems tend to be focused on horse race tracks— e.g., U.S. Published Patent Application No. 2009/0131132 (Kohls et. al.). However, horse race tracks are relatively small networks where delivering parimutuel odds and other data in real time or near rear time does not pose any significant computational challenge. Lottery systems however are a different matter, the sheer scale of typical lottery systems dwarf horse race track parimutuel wagering systems with a network of thousands and tens of thousands field terminals continuously accepting bets for draw games. Thus, prior art horse race track parimutuel wagering systems do not address the fundamental problem of providing real time data for larger scale systems.

Lottery-related draw game systems prior art tends to exclusively focus on new types of games and the systems to support them with no regard to processing efficiencies— e.g., U.S. Published Patent Application Nos. 2003/0050109 (Caro et. al.); 2004/0058726 (Klugman); 2009/0131132 (Kohls et. al.); 2009/0227320 (McBride); 2010/0222136 (Goto et. al.); 2011/0281629 (Meyer); 2013/0244745 (Guziel et. al.); and U.S. Patent No. 8,747,209 (Badrieh).

[0013] Therefore, it is desirable to develop scalable methods of constructing efficient draw game network systems. Given the ubiquitous presence of lottery terminals distributed throughout a jurisdiction, these draw game lottery network system efficiencies can be potentially leveraged to provide hitherto unknown lower costs. Ideally, these draw game network system efficiencies could enable real time updating of betting data and associated data mining.

SUMMARY OF THE INVENTION

[0014] Objects and advantages of the present invention will be set forth in part in the following description, or may be obvious from the description, or may be learned through practice of the present invention.

[0015] A method and system are provided for efficient draw game network systems utilizing commodity hardware. The efficiency of the present invention is principally derived from preprocessing of all necessary metrics when a wager is made, as well as a scheme to allow volatile in-memory data to be used safely for financial calculations, even in the event of a total system outage. Because of the efficiencies enabled from the present invention, hitherto unknown operational abilities (e.g., real time feedback, canceling of wagers before a drawing) are enabled.

[0016] Described are mechanisms, systems, and methodologies related to constructing efficient draw game network systems utilizing commodity hardware thereby enabling methods of inexpensive operation while also enabling hitherto unknown real time betting feedback. The efficiency of the present invention is principally derived from

preprocessing all bet data into metrics and storing the metrics primarily within volatile memory — i.e., high-speed and volatile Random Access Memory ("RAM"). Despite the primary utilization of volatile RAM processing, in the event of a system outage, volatile RAM data can be reconstructed with 100% accuracy from non-volatile data— i.e., from slower speed non- volatile memory (e.g., disk data, flash data). The non-volatile data is first processed by a mathematical operation for each wager at the time the wager is made, essentially allowing the non-volatile wager data to be distributed and stored among n sets of non-volatile storage devices. The key innovations are the preprocessing of all necessary metrics at the time a wager is made, thereby enabling high-speed volatile data processing while enabling techniques to allow all wager data to also be stored safely in parallel non-volatile memory for betting. This process enables 100% recovery even in the event of a total system outage while still enabling real time bet processing.

[0017] In a general embodiment, a draw game network system is disclosed that provides significantly greater throughput while utilizing lower cost commodity hardware than is commonly available via prior art systems. The efficiencies of the present invention are achieved from data preprocessing at the time of sale as well as maintaining a copy of the summation of all bet data in volatile memory.

[0018] As an inherent aspect of this general embodiment, the disclosed efficient draw game network architecture readily accommodates horizontal scalability and redundancy without the need for extensive reengineering or expensive hardware additions. The preprocessing of data at the point and time of sale inherent in the design permits draw game bet data to coexist in both high-speed volatile (e.g., RAM) memory as well as lower-speed non- volatile memory (e.g., disk or flash) that is distributed by an arbitrary modulus function into n units of persistent storage. These n units of persistent non- volatile storage are typically spread over multiplicities of low-cost processors and data storage devices thereby enabling horizontal expansion and redundancy without the need to redesign the underlying hardware system architecture.

[0019] This inherent aspect of horizontal scalability is further maintained after the drawing process is completed— i.e., after sales for a particular draw game are closed and the winning sequence of numbers is determined. After the drawing process is completed, the highspeed volatile memory is utilized to calculate the minimal data necessary to allow each ticket to be settled without attempting to settle all tickets at that time. When individual winning tickets are presented for redemption, this pre-calculated settlement data is compared to the ticket data presented for validation thereby allowing rapid settlement. Thus, the pre-calculated settlement data along with the inherent sporadic presentation of winning tickets for redemption ensures that any system architectural design that is scaled to be capable of accommodating sales volume will also easily accommodate supplementary redemptions. As part of this settlement process and overall design, the hereto unknown ability to cancel wagers before a given drawing may be supported by the present invention.

[0020] In a specific embodiment, the efficient draw game network system enabled by the present invention provides real time queries of bet data allowing previously unknown methods of real time data mining. These real-time data mining methods thereby facilitating potential processes for increasing sales via real time customer engagement as well as the potential for enhanced security.

[0021 ] In another specific embodiment, the efficient draw game network system supports the creation and maintenance of a dynamic hash chain ledger that establishes a foundation for the creation of digital Message Authentication Codes ("Macs") or digital signatures that can be appended to bet ticket serial numbers and ancillary data printed on the ticket. These Macs or digital signatures providing digital authentication for bet tickets presented for redemption such that the need for secondary authentication via secure ticket stock becomes unnecessary.

[0022] Described are a number of mechanisms and methodologies that provide practical details for reliably developing an efficient draw game network system from commonly available (i.e., low cost) hardware that also provides for scalability. Although the examples provided herein are primarily related to lottery draw games, it is clear that the same methods are applicable to any type of parimutuel wagering system.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] FIG. 1A is a representative example hardware block diagram of an efficient draw game network system embodiment as enabled by the present invention;

[0024] FIG. IB is a representative example high level architecture swim lane diagram of the key components associated with processing and redeeming bets on the efficient draw game network system embodiment of FIG. 1 A;

[0025] FIG. 1C is a representative example swim lane block diagram highlighting the parallel utilization of volatile and non- volatile data storage which is compatible with the embodiments of FIGS. 1A and IB; [0026] FIG. 2A is a front elevation representative example of a prior art draw game ticket supported by preferred embodiments of the present invention;

[0027] FIG. 2B is a front elevation representative example of a draw game ticket that is compatible with a specific embodiment of the present invention;

[0028] FIG. 3A is an overall logical state machine rendering representative example of the processes associated with operating a draw game compatible with the embodiments of FIGS. 1A, IB, and 1C;

[0029] FIG. 3B is an overall logical state machine rendering representative example of the processes associated with issuing, canceling, and redeeming a draw game ticket compatible with the specific embodiment of FIGS. 1A, IB, 1C, 2B, and 3A;

[0030] FIG. 3C is a representative example table listing the various states associated with the life cycle of a draw game ticket that is compatible with the embodiments of FIGS. 3A and 3B;

[0031 ] FIG. 4A is a representative example matrix defining the draw game data that is stored that is compatible with the general embodiments of 1A, IB, and 1C;

[0032] FIG. 4B is a representative example of the data sets that are stored and is compatible with the embodiment of FIG. 4A; and

[0033] FIG. 5 is a sequence diagram, illustrating ticket queue functionality as an integral part of volatile memory data recovery that is compatible with the general embodiments of FIGS 1A, IB, and 1C.

DETAILED DESCRIPTION OF THE INVENTION

[0034] Certain terminology is used herein for convenience only and is not to be taken as a limitation on the present invention. The words "a" and "an", as used in the claims and in the corresponding portions of the specification, mean "at least one." In the context of the present invention, "volatile" data or memory refers to computer memory that requires power and uninterrupted processing to maintain the stored information— i.e., it retains its contents while powered on but when the power or processing is interrupted, the stored data is lost immediately or very rapidly. "Volatile" data or memory is typically utilized as main memory. The principle advantage of "volatile" data or memory is that it is typically much faster than forms of "nonvolatile" memory or mass storage (e.g., hard disk drive, flash drive). Additionally, volatile memory can protect sensitive information as it becomes unavailable on power-down. Most of the general-purpose computer Random Access Memory (RAM) is volatile. In contrast, "nonvolatile" memory or mass storage is a is a type of computer memory that can retrieve stored information even after having been power cycled (i.e., turned off and back on) or the primary processing is interrupted. Examples of "non-volatile" memory include read-only memory, flash memory, ferroelectric RAM, most types of magnetic computer storage devices (e.g., hard disk drives, floppy disks, and magnetic tape), optical discs, and the like. "Non-volatile" memory is typically used for the task of secondary storage, or long-term persistent storage. Typically, nonvolatile memory costs more, provides lower performance, or has worse write endurance than volatile random access memory.

[0035] This patent application includes an Appendix. The Appendix is incorporated by reference into the present patent application. One preferred embodiment of the present invention is implemented via the source code in the Appendix. The Appendix is subject to the "Copyright Notice and Authorization" stated above.

[0036] The Appendix includes the following parts:

[0037] Part 1 : A representative example code snippet for ticket structure memory storage compatible with the embodiment of FIGS. 4 A and 4B.

[0038] Part 2: A representative example code snippet for establishing a Bet Queue and Bet Process that is compatible with the general embodiments of FIGS 1A, IB, and 1C.

[0039] Part 3: A representative example code snippet for determining winning tickets that is compatible with the general embodiments of FIGS 1A, IB, and 1C.

[0040] Part 4: A representative example code snippet for establishing a Message Authentication Code (Mac) that is compatible with the general embodiments of FIGS 1A, IB, and 1C.

[0041 ] A "wager" or "bet" as used in the claims and in the corresponding portions of the specification, means a gamble on predicting the outcome of a drawing in the future. A "ticket" denotes a "payable on demand" document either printed (e.g., FIG. 2A or FIG. 2B) or virtually transferred certificate authenticating the wager transaction. A "draw game identifier" refers to information or data that uniquely identifies a specific wager while not necessarily identifying the identity of the individual or consumer making the wager. Examples of "draw game identifier" data would be the type of drawing (e.g., Keno, Pick 3, Pick 4, Powerball, Kentucky Derby ® ), the time and date of the wager and the scheduled drawing, a unique serial number assigned to the particular wager, the numbers or indicia wagered to appear in the scheduled drawing, the wager amount, and the like. In most embodiments, the "draw game identifier" data would not include any information about the consumer, since these embodiments typically produce a "payable on demand" ticket that can be redeemed after a winning drawing occurs. In other embodiments, the consumer's identity can be linked directly to the "draw game identifier" data. These embodiments are typically associated with Internet wagering with pre- established accounts, where no anonymous "payable on demand" ticket is produced.

[0042] Also, in the context of the present invention, "bet type" refers to variations on the type of wager for a given drawing where more than one possible wager or bet type is possible. Examples of various "bet types" include the Power Play option in Powerball add-on for an additional $ 1 per play where a separate drawing is performed to select the Power Play number (i.e., "2", "3", "4", or "5") for all prizes except the jackpot; the Match 5 prize; Pick 3 or Pick 4 straight or boxed wagers; standard bets and way bets in Keno; and the like.

[0043] Constructing efficient draw game network systems utilizing commodity hardware requires multiple data depositories, segmentation, synchronized release of information, and coordination. Dividing data archival functionality across among n sets of non-volatile storage devices while simultaneously preprocessing all bet data into metrics and storing the metrics within volatile memory enables greater efficiency and reduced system latency than has been previously realized. Segregating non-volatile storage devices among n sets allows for ready compartmentalizing of data storage for efficiency and security as well as horizontal scalability. Preprocessing all bet data into metrics and storing the metrics within volatile memory dramatically increases speed and correspondingly real time data accessibility. This increased real time data accessibility in turn enables hereto unknown marketing and sales information (e.g., number of consumers wagering the same number or indicia) availability both to the consumer and the lottery staff as well as potentially enhanced security— e.g., flagging when parallel RNG outcomes were purchased for the same drawing, adding central site generated Message

Authentication Codes (Macs).

[0044] Reference will now be made to one or more embodiments of the system and methodology of the present invention as illustrated in the figures. It should be appreciated that each embodiment is presented by way of explanation of aspects of the present invention, and is not meant as a limitation of the present invention. For example, features illustrated or described as part of one embodiment may be used with another embodiment to yield still a further embodiment. These and other modifications come within the scope and spirit of the present invention.

[0045] FIGS. 1A, IB, and 1C taken together, illustrate the general embodiment 100 of the present invention, which seamlessly integrates commodity hardware into an efficient draw game network system. FIG. 1 A is an overall representative example block diagram of the general embodiment 100 illustrating generic Point Of Sale (POS) devices as well as personnel devices that register wagers made by the consumer through a network to a primary and backup central site where the wagers are recorded and a confirmation is relayed back to the consumer. FIG. IB depicts a swim lane flowchart providing a schematic graphical overview of the general embodiment of the present invention. As illustrated in FIG. IB embodiment 100', system-level division of data storage, segregation, and augmentation of digital databases is conceptually divided into five groups (i.e., Wagering Interfaces 151, Tickets 152, Draw 153, Real Time Data 154, and Verification Code 155) by the five "swim lane" columns from left to right. Whichever "swim lane" a flowchart function appears within its functionality is limited to the data category of the associated swim lane— e.g., web portal 161 is within the segregated domain of user 151. FIG. 1C depicts another swim lane flowchart 100" providing a schematic graphical overview highlighting the parallel utilization of volatile and non- volatile data storage as an integral part of the present invention. The four swim lanes illustrated in FIG. 1C are Wagering Interface 15 , Time of Wager processing 175, volatile data storage 176, and non-volatile data storage 177.

[0046] A representative example diagram 100 of a general efficient draw game network system embodiment is illustrated in FIG. 1 A. Similar to prior art draw game systems, embodiment 100 can be logically divided into three portions:

• Wagering Interface Portion— the system portion (101 through 105) that accepts wagers from consumers and typically provides "payable on demand" documentation

• Network Portion— the system network portion 110 that provides secure communications links between the Wagering Interface Portion and the Central Site 115 • Central Site Portion— the system portion 115 that generates the ledger of record for all wagers received, generates bet ticket data, generates summary reports, determines winning wagers and/or tickets, and provides overall security monitoring

[0047] Like prior art draw game systems, embodiment 100 can accept wagers from multiplicities of different types of devices including different types of lottery terminals (103 through 105), lottery kiosks 102, and consumer devices 101 via the Internet. Also, the network 110 utilized by embodiment 100 is similar to prior art draw game systems.

[0048] The principle difference between prior art draw game systems and embodiment 100 lies in the central sites 1 15. Rather than relying on high performance servers that are an integral part of a SAN with a large infrastructure that is managed with a team of skilled system administrators, network specialist, and technicians, embodiment 100 utilizes commodity computers or servers (1 16 through 118 and 126 through 128) configured in a cluster draw game network architecture that readily accommodates horizontal-scalability and redundancy when needed, as well as optional enhanced geographical redundancy realized from spreading the central site cluster 1 15 over at least two different physical locations (130 and 131). This preferred optional cluster spreading over multiple physical locations (130 and 131) inherently provides greater fault tolerances such that any physical location would automatically continue operations (e.g., 131) if another site (e.g., 130) suffers a catastrophic failure.

[0049] This horizontal-scalability and redundancy is possible since all wager or bet data is preprocessed into metrics with the resulting metrics stored primarily within volatile memory (i.e., high-speed RAM) with the volatile RAM metrics retrievable with 100% accuracy from slower speed non-volatile memory (e.g., disk data, flash data). The non-volatile memory records each bet or wager by first applying a mathematical operation for each wager at the time the wager is made, essentially allowing the non-volatile wager data to be distributed and stored among n sets of horizontally scalable non-volatile storage devices.

[0050] As shown in the high level architecture swim lane diagram 100' of FIG. IB, there are five functional components (i.e., Wagering Interface 151, Tickets 152, Draw 153, Real Time Data 154, and Verification Code 155) of the present invention typically residing in separate devices or computing devices. The Wagering Interface 151 (i.e., POS 160 and Web Portal 161) provides the transaction portal(s) that interact with specific consumers and/or operational staff, thereby enabling wagers or bets to be sold. All wagers or bets received by the Wagering Interface 151 are passed to the Tickets component's 152 Bet service 162. After a given drawing is closed and the winning numbers or indicia are determined, any apparent winning wager tickets presented for redemption to the Wagering Interface 151 are passed to the Check & Settle 166 service for validation and payment authorization. Optionally, the Wagering Interface 151 devices may also interface with the Verification Code 155 component's Verification 171 service for generating, storing 172, and validation ticket Message Authentication Codes (Macs).

[0051 ] Once a pending wager or bet is received by the Bet service 162 a unique serial number is assigned to the wager and the wager is passed to the Non- Volatile Bet Queue database 163 (also referred to as a "non-volatile data storage bet queue"), which effectively maintains the pending wager in a First In First Out (FIFO) buffer while waiting for initial processing by the Bet Process service 164. When ready, the Bet Process service 164 receives the pending wager and performs two functions correlated to the pending wager's data:

• Generate key metrics— calculate key metrics from the pending wager that essentially compress all data necessary to: log a specific wager or bet, flag the specific drawing associated with the wager or bet, verify if a given wager is a winner after the drawing occurs, support global summary reports, and the like, ultimately resulting in a structure for each wager or bet of minimal settlement data that can be stored in high-speed volatile (e.g., RAM) memory in multiplicities of servers or processors, preferably (for added redundancy) over different geographical locations.

• Assign each wager to one of n sets of non- volatile storage devices— use an arbitrary mathematical operation on the unique wager serial number assigned by the Bet service 162 to store the wager in any one of n sets of Non- Volatile Ticket Storage devices 165 (e.g., disk data, flash data). In a preferred embodiment, this mathematical operation is a modulus function.

[0052] Once the Bet Process service 164 has completed the previously described two pending services, it logs the wager in both high-speed volatile Data Storage memory 169 (i.e., as embodied by the key metrics) via the Real Time Data service 170, as well as lower-speed Non- Volatile Ticket Storage memory 165 (i.e., all raw bet data assigned to one of n sets). After the wager is initially logged in the non-volatile Bet Queue 163, the Bet Process service 162 transmits an acknowledgement of the completed wager back to the wagering interface 151 (POS 160 and Web Portal 161) that initiated the wager request, ultimately culminating in a "payable on demand" ticket (i.e., POS terminals 160) or a log on a Web Portal 161 with a unique ticket serial number, to ensure that responsiveness is maintained. After the Bet Process service 164 has completed its processing, it removes the ticket from the Bet Queue 163.

[0053] At some time before the actual drawing (e.g., one hour), the draw game system will no longer accept new wagers with the system effectively assuming a "No More Bets" state. After the No More Bets state is implemented and all pending wagers are secured, a drawing (e.g., ping pong ball selection, RNG) will occur to determine the winners. Once the drawing is completed and certified, the drawing results are logged into the Draw service 167 (usually by two lottery personnel keying in identical numbers or indicia on two different keyboards with the Draw service 167 verifying that both entries were identical). The entered draw results are first saved in Non-Volatile Draw Storage 168 to enable the system to identify winners for the completed drawing. The Draw service 167 and associated non-volatile Draw Storage 168 record the given draw results with the associated time and date as well as various aggregate details (e.g., hash of all bet data for the drawing, size of the winning pool of tickets, number of total bets, payout per ticket, potential anomalies of the drawing) while typically (for reasons of efficiency) recording no individual information of the wager tickets or serial numbers issued.

[0054] When a winning ticket or serial number is presented to a Wagering Interface 151 device (POS 160 and Web Portal 161) for redemption, the Check & Settle service 166 receives the redemption request and queries the non- volatile Ticket Storage 165 to determine if the ticket or serial number presented is a valid winner and if it has not already been paid. Assuming the ticket or serial number is valid, the Check & Settle service 166 may optionally query the Draw service 167 to verify a ticket's winning status and if so, how much it won.

Additionally, the Draw service 167 may check for any anomalies or updates, ultimately relaying the payment approval or rejection back to the Wagering Interface 151 that initially made the request. Assuming the ticket is in fact a winner and has not already been paid, the Check & Settle service 166 relays a payment authorization back to the Wager Interface device (POS 160 and Web Portal 161), and writes the paid status to the non-volatile Ticket Storage 165 memory. [0055] Optionally, the Verification Code 155, which is an independent component that preferably is hosted in an entirely different location and/or by a third party, will respond to requests from a Wagering Interface 151 device with its Verification service 171 to generate a Mac and log the wager's Mac data in non- volatile Verification Storage 172 ultimately returning a Mac which can later be used to demonstrate that a winning ticket is legitimate.

[0056] FIG. 1C is an alternative swim lane diagram 100" of the same embodiment 100 (FIG. 1A) that highlights the processing that occurs when a wager is made and what portions of the wager data are saved in volatile 176 (FIG. 1C) and non-volatile 177 memory. As shown in the swim lane diagram 100", there are four functional components (i.e., Wagering Interface 15 , Time of Wager Processing 175, Volatile Data Storage 176, and Non- Volatile Data Storage 177) of the highlighted diagram's high level architecture. As previously discussed, the Wagering Interface 15 (i.e., handheld user device 10 , lottery POS kiosk 102', lottery POS terminal 104', and alternate lottery POS terminal 105') devices provide the transaction portal(s) that interact with specific consumers and/or sales staff, thereby enabling wagers or bets to be sold. All wagers or bets received by the Wagering Interface 15 from the consumer are passed to the Time of Wager Processing component 175. The two services within component 175 (i.e., Modulus Function to "n" Units 182 and Metrics Processing 181) perform the initial processing of the wager request such that hereto unknown draw game system efficiencies and scalability can be achieved while at the same time maintaining 100% recovery capabilities in the event of a system outage.

[0057] The Modulus Function to "n " Units service 182 (also, referred to herein as a "computer processor") employs an arbitrary mathematical operation (preferably modulus) on the pending wager' s previously generated ticket serial number thereby allowing the complete wager data to be distributed and stored among n sets of non-volatile Ticket Storage memory 165'. Since this non-volatile Ticket Storage memory 165' is typically slower in response to processor requests, this complete copy of the wager data maintained in Non- Volatile Ticket Storage memory 165 'is primarily intended for archival purposes only. Additionally, the nonvolatile Bet Queue 163 also maintains a copy of all received wagers which have not yet been processed. The Bet Queue 163 primarily reduces the processing time for new wagers, as well as greatly reducing the time taken before bets may be accepted when recovering from a catastrophic failure. The high-speed volatile Data Storage memory 169' maintains the record or ledger of wagers for essentially all real time processing. One skilled in the art will recognize that other mathematical functions or algorithms may be utilized to save the complete wager data among n sets of Non- Volatile Ticket Storage memory 165". The essential concept is to ensure an approximate homogeneous distribution of wagers among the n sets of Non-Volatile Ticket Storage memory 165'.

[0058] The same pending wager data that was stored in one of n sets of the Non- Volatile Ticket Storage memory 165' is also applied to the Metrics Processing service 181. The Metrics Processing service 181 calculates key metrics (i.e., a compressed subset of minimal data necessary to record and redeem bets) of the pending wager data preserving a variety of specific data structures that can support all real time functional requirements. These key metrics are consequently calculated on ticket creation, rather than on query, thereby facilitating storage in high-speed volatile Data Storage memory 169'. In the event of a system outage and subsequent Data Storage memory 169' loss, the key metrics for a given drawing can be reconstructed from the persistent data maintained in the Non- Volatile Ticket Storage memory 165'. In an alternative embodiment, a copy of the key metrics generated at the time of the wager could also be stored in the Ticket Storage memory 165' with the complete wager data. This alternative embodiment has the advantage of a theoretical faster recovery time in the event of a system outage than recalculating the key metrics at the time of recovery. In another alternative embodiment, only the key metrics are stored in the Non- Volatile Ticket Storage memory 165 'instead of maintaining a copy of the complete wager data. This embodiment has the advantage of faster recovery and smaller storage requirements with the possible disadvantage of incompatibility with legacy lottery audit, security, and forensic requirements.

[0059] FIGS. 2A and 2B provide alternate renditions of "payable on demand" draw game tickets 200 and 200' that are typically printed on lottery POS devices (e.g., 102 through 105 of FIG. 1A) at the time a wager is purchased. FIG. 2A provides a front elevation representative example of a legacy (prior art) draw game ticket 200 and FIG. 2B provides an optional enhanced draw game ticket 200' that would also support a specific embodiment of the present invention that includes appending a Mac for digital ticket authentication. Both the legacy 200 and enhanced 200' draw game tickets are supported by the present invention.

[0060] Among other graphics, the legacy draw game ticket 200 of FIG. 2A displays the numbers or indicia 201 that were wagered for a specified upcoming drawing 203. Also printed on the legacy ticket is a human readable serial number 202 as well as machine readable indicia 204 that typically embodies information similar to the human readable serial number 202. Both the human 202 and machine 204 readable serial number were generated by the Bet service 162 (FIG. IB) after the wager was transmitted from the Wagering Interface 151. When a winning draw game ticket is redeemed, either the human 202 (FIG. 2A) or machine 204 readable serial (via keyboard entry) number is transmitted from the Wagering Interface 151 (FIG. IB) to the Check & Settle service 166 which, in turn, queries the high-speed volatile Data Storage memory (169 of FIG. IB and 169' of FIG. 1C) and Real Time Data service 170 (FIG. IB) to determine if the ticket is a legitimate winner and not previously paid.

[0061 ] The optional enhanced draw game ticket 200' of FIG. 2B is almost identical to the legacy ticket 200 of FIG. 2A. As before, the optional enhanced draw game ticket 200' of FIG. 2B is printed with the numbers or indicia 20 that were wagered for a specified upcoming drawing 203'. However, with the enhanced draw game ticket 200', both the human readable 202' and machine readable indicia 204' serial numbers are modified to accommodate a much larger serial number. The human readable 202' serial number changed from a simple decimal encoding to alphanumeric, and the machine-readable indicia 204' serial number changed from a one dimensional (e.g., Interleave 2-of-5) to two-dimensional (e.g., PDF-417) barcode. This expansion of data capacity accommodates the optional appending of a 128, 256, or 512-bit Mac to support the optional Validation Code 155 (FIG. IB) Verification service 171.

[0062] FIGS. 3 A, 3B, and 3C taken together, describe the various states for drawing and draw ticket subsystems or machines of the present invention. FIG. 3A is an overall logical state machine rendering representative example of the processes or states associated with operating a draw game compatible with the general embodiment of the present invention. FIG. 3B is an overall logical state machine 320 representative example of the processes associated with issuing, canceling, and redeeming a draw game ticket (e.g., 200 of FIG. 2A and 200' of FIG. 2B) compatible with the specific embodiment 300 of FIG. 3A. Finally, FIG. 3C is a table 340 listing the various states associated with the life cycle of a bet ticket compatible with the state machine embodiment 320 of FIG. 3B.

[0063] The state machine example 300 of FIG 3A graphically depicts the various logical states of a given draw game progressing from initialization 301 through the final close out 309. From its Initial state 301, a typical draw game progresses to a Planned state 302 where the future draw game is registered on the draw game system along with programmed rules for the drawing (e.g., select five ball numbers from a master set of sixty-nine possible, time deadline to stop sales for a pending drawing, "Doubler" enabled), but not necessarily accepting wagers. From this Planned state 302 the state machine can progress to one of two possible states. In some special circumstances a Cancelled state 303 (when for whatever reason the planned drawing is cancelled) would be adopted that effectively removes associated data from the draw system, then progresses to the Final state 309. However, normally, the drawing Planned state 302 progresses to the Current state 304, which effectively means that the drawing is available to accept bets or wagers. This Current state 304 will persist accepting wager sales until a predefined time (e.g., one hour) before the schedule drawing. At that time, the state machine will progress to its No More Bets state 305, meaning that the Bet service 162 (FIG. IB) will no longer allow a wager to be placed on the pending drawing. This state continues until the actual drawing (e.g., ping pong balls, RNG) is conducted, at which point the state machine advances to its Ready state 306 (FIG. 3A) indicating that the draw game system (i.e., Draw service 167 and Draw Storage 168, both of FIG. IB) has received and logged the drawing results, but the results are not yet certified (i.e., drawing results made official and publicly announced). Once the drawing results are certified, the state machine proceeds to its Results state 307 (FIG 3A), thereby allowing the system to redeem winning tickets via its Check & Settle 166 service (FIG. IB). After the period for redeeming tickets for a given drawing has expired, the state machine progresses to its Closed state 308 (FIG. 3A) where final accounting and archiving is performed for the existing drawing and all key metrics for wagers associated with the existing drawing are deleted from Data Storage 169 (FIG. IB) high-speed volatile memory before the state machine concludes in its Final state 309 (FIG. 3A) for the existing drawing.

[0064] Running in parallel with state machine 300 while it maintains the various states associated with establishing a specific drawing, state machine 320 of FIG 3B also runs providing the various logical states of a given draw ticket (e.g., 200 of FIG. 2A and 200' of FIG. 2B) progressing from initialization 321 (FIG. 3B) through the final close out 331. A graphic depiction of the various states 322' through 330' of the draw game ticket state machine 320 is illustrated in the table matrix 340 of FIG. 3C. In the matrix 340, the various ticket machine states are listed in the Ticket State 341 column with the associated Description 342, Draw State 343, Ticket Data 341, Winner? 345, Cancellation Data 346, and Redemption Data 347 descriptions located in the row associated with the given ticket state— e.g., all information associated with the Accepted state is shown in row 322'. Accordingly, for brevity the subsequent discussion will freely cross-reference FIGS. IB, 3A, 3B, and 3C with the unique callout reference numbers also denoting the associated figure and no figure numbers specified.

[0065] A key concept in the draw ticket state machine 320 architecture is that the state of a wager may not be simply referenced from one central database - i.e., it will be deduced from data stored in multiple locations. Thus, the draw ticket state machine 320 avoids updating records, as this is a relatively expensive operation (both in terms of computation and time) and has poor uniformity in modern databases. For example, when a draw game ticket is redeemed, the old record is not updated. Instead, a new record is created in the same non- volatile n storage unit.

[0066] The draw ticket state machine 320 advances from its Initial state 321 (where no draw game ticket processing occurs) to its Accepted state 322 when a new pending wager is received. As described in the corresponding matrix row 322', the Accepted state 322 is when a pending wager has been received by the Bet service 162 where a unique serial number is assigned with the pending wager waiting in the Bet Queue 163. At the Accepted state 322 in the draw game ticket process, no Draw State 343 has been effected and consequently: no draw game Ticket Data logged 341, no Winning status 345 determined, no Cancellation 346, and no Redemption 347 statuses determined.

[0067] Once the pending wager progresses to the Bet Process service 164 and is logged in both volatile 169 and non-volatile 165 memory, an acknowledgement is sent back to the Wager Interface 151 that initiated the wager request, a draw game ticket is typically printed, and the state of the draw ticket state machine 320 changes to Open 323. In this Open state 323', all initial wager processing is completed with ticket data recorded on the system that is now part of the Current state 304 of the draw game state machine.

[0068] From the Open state 323 for a draw game ticket, there are two possible future states: Cancelled 325 or Pending 324. As its name implies, the Cancelled state 325 exists to enable the hereto unknown ability to cancel draw game tickets after the wager was logged, but before the No More Bets state 305 time -period begins. If a cancellation is requested within the allowable time -period (i.e., before the Open state 323 progresses to the No More Bets state 305), the draw ticket state machine 320 will change the associated draw game ticket's data from the Open state 323 to the Cancelled state 325. This cancelled state 325' leaves extant persistent data of the draw game ticket, as well as a new data entry, flagging that the associated draw game ticket has been canceled. This Canceled state 325 persists until the associated draw game's redemption period has expired and the associated draw game data is archived for long term storage and taken off the real-time system in its Final state 331. For draw game tickets that were not cancelled, their data persists in the Open state 323 until the No More Bets state 305 is achieved on the draw game state machine 300. At this point, the draw ticket state machine 320 changes all remaining ticket Open states 323 to Pending states 324 for all tickets associated with the No More Bets 305 drawing. This Pending state 324' remains so long as the No More Bets state 305 persists in the game state machine 300 with the ticket data remaining in memory.

[0069] Once the drawing is completed and made official, the draw game state machine 300 progresses to its Results state 307 with all tickets associated with the given drawing changing to either a Non- Winner 326 or Winner 327 state. The Non-Winner state 326 is the state reserved for all tickets that did not win any prize after the drawing occurred and its results were made official. This Non-Winner state 326' is the state of all tickets after a drawing that did not win a prize. All Non-Winner state 326' ticket data is maintained in both volatile 169 and nonvolatile 165 memory until the time -period for redemption of the related drawing expires and the associated draw game data archived for long term storage is removed from the real-time system in its Final state 331.

[0070] Winning 327 tickets are another matter. Initially, after a drawing is concluded and the results are made official (i.e., the draw game state machine 300 advances to the Results 307 state), the ticket state machine 320 advances all winning tickets to the Winning state subclass of Unclaimed 328— i.e., Winner.Unclaimed 328'. This is the subclass 328 for all tickets from a closed drawing that have won a prize, but have not been redeemed. Of course, the data persists for these tickets in the system. From the Unclaimed 328 state, the ticket state machine 320 can progress to either Claimed 329 or Expired 330 subclass states. If the consumer redeems his or her ticket, that ticket changes to the Winner.Claimed subclass state 329'. Thus, in this state 329' the drawing has been concluded, the associated ticket has won a prize, and the prize has been paid. Naturally, the data associated with the ticket persists in both volatile 169 and non-volatile 165 memory until the time -period for redemption of the related drawing expires and the associated draw game data is archived for long term storage as it is removed from the real- time system in its Final state 331. In addition, redemption data is added to the ticket history in both volatile 169 and non-volatile 165 memory documenting facts (e.g., time, place) of the redemption. If a given ticket has won a prize, but was never redeemed during the draw game state machine's 300 Results state 307 (i.e., the period for winning redemptions for a given drawing has expired), the ticket will culminate in an Expired subclass state 330. The

Winner.Expired subclass state 330' then documents that no prizes were paid for this particular ticket with the associated draw game data archived for long term storage and taken off the realtime system in its Final state 331.

[0071 ] Preferably, the volatile Data Storage 169 incorporates a key-value database system (e.g., REmote Dictionary Server or "Redis") thereby readily accommodating this added data. Key- value or Dictionary databases are a data storage paradigm designed for storing, retrieving, and managing associative arrays. Key-value databases contain a collection of objects, or records, which in turn have many different fields within them, each containing data. These records are stored and retrieved using a key that uniquely identifies the record (e.g., draw game ticket serial number), and is used to quickly find the data within the database. For example, if multiple bet numbers are stored, the numbers could be stored as a bitmap of a set number of bits— e.g., the selection of balls "1,2,3,4,5,6" could be stored as 59-bits:

"0,0,0, ,0,0,1,1,1,1,1,1." In contrast, the non-volatile Bet Queue 163 and Ticket Storage

165 would preferably be maintained in a document database— e.g., as MongoDb ® , Google BigTable™, or Apache Cassandra ® .

[0072] This key-value database system would typically be shared according to various functions applied to the unique draw game ticket serial number or "ticketid." A preferred key-value database storage architecture is illustrated in matrix 400 of FIG. 4A. Matrix 400 is arranged in four columns (i.e., Name 401, Description 402, Key 403, and Values 404) by three rows (i.e., All Numbers 405, Each Number 406, and Redemption 407) with each row describing the type of data. The overall matrix 400 therefore defines the specific arrangement of the wager data (408 and 406) to the Redemption data 407. The All Numbers 405 row of the matrix 400 provides a listing of the high-tier winning numbers or indicia for the associated drawing "drawid" and the specific ticketid with the key-value database structure of

"<drawid>_t_ <number>" via a GET function. The Each Number 406 row provides a listing of the wagered numbers or indicia for the associated drawing "drawid" and the specific ticketid with the key-value database structure of "«drawid>_n_[1...59]>" via a SINTERSTORE function. Finally, the Redemption 407 row provides a listing of redeemed tickets for the associated drawing drawid and the specific ticketid with the key-value database structure of "<drawId>.redemption.<prizeLevel>." Examples of these three data sets 410 (i.e., All Numbers 415, Each Number 416, and Redemption 417) are provided in FIG. 4B. The All Numbers 415 key-value is shown to be a combination of the drawid 421 and high-tier winning numbers or indicia 422. The Each Number 416 key-value is illustrated as a combination of the drawid 423 and bet number or indicia 424. Finally, the Redemption 417 shows a combination of the drawid 425 and prize level 426 redeemed.

[0073] Ideally, three classes of data would be maintained in non- volatile memory. The preferred classes of data stored would be "Bet", containing the wager data, "Cancel", containing cancellation data, and "Redeem", containing redemption data. Part 1 of the Appendix is a simplified representative example of a code snippet 440 for executing data storage with the correct key-value. Each draw ticket would be stored with a partition key derived from the drawid and a modulus on the ticketid, which would be a generated 128-bit "UUID" (Universal Unique Identifier) consisting of the ticketid and the class of data stored, as well as an attribute consisting of textured data representing all the necessary data for the ticket itself.

[0074] One example modulus function would be to use the last bits in the ticketid to assign to 1, 2, 4, 8... units— e.g.,

• Ticketid: "641d8f94-0323-l le7-93ae-92361f002671"

• Binary representation, e.g., "...10111101"

• Units (when using eight units): "101" (binary) or "5" (decimal)

A unique feature of this data storage arrangement is that the modulus function can be readily changed so long as legacy functions are stored against the draw which used them - thus readily enabling horizontal scaling of the system if real world data requirements exceed expectations.

[0075] The accepting and processing of wagers involves first loading a pending wager into the Bet Queue 163 (FIG. IB), performing initial processing on the pending wager in the Bet Process 164, which stores the processed data in both volatile (169 and 169' of FIG. 1C) and non-volatile (165 of FIG. IB and 165' of FIG. 1C) memory. Part 2 of the Appendix provides an exemplary code snippet 500 that reads pending wagers from the Bet Queue 163 (FIG. IB) and ultimately stores the pending wager into both volatile (169 and 169' of FIG. 1C) and non-volatile (165 of FIG. IB and 165' of FIG. 1C) memory. Part 3 of the Appendix provides an exemplary code snippet 525 that processes winning wagers stored in memory. Code snippet 525 provides part of the Draw service functionality.

[0076] The sequence diagram 500 of FIG. 5 illustrates how the non-volatile Bet Queue 503 (also 163 in FIG. IB) is fundamental to allowing the draw game system's volatile memory (169 and 169' of FIG. 1C) to recover safely and swiftly from an outage while maintaining correct accounting. The sequence diagram 500 includes six objects— i.e., Bet Process 501, <Service> Draw 502, Bet Queue 603, <Database> Ticket Storage 604, <In

Memory> Number Storage 605, and Bet Process Worker 506. The internal loop 520 that is an integral part of the Bet Process Worker 506 portions are highlighted as a gray rectangle in FIG. 5.

[0077] On system initialization after volatile memory was lost, the Bet Process 501 will first determine and acquire the current draw games pending 510 from the Draw 502 non-volatile memory via the "getCurrentDrawO" synchronous interface. Immediately after the current draw game(s) have been determined, the Bet Processor 501 will message the Ticket Storage 504 non-volatile memory via "loadCurrentTicketsO" and load all tickets which exist in the current draw into volatile memory 511. Additionally, during this recover process the Bet Process 501 messages the Number Storage 505 through "reloadNumbersStorage()" to also reload the volatile memory 512. However, depending on communication bandwidth, the recovery time to complete these tasks may be substantial— e.g., with commodity cloud infrastructure up to thirty minutes. Fortunately, new wagers can be accepted during this recovery period without any human perceivable delays with the new wagers being processed by the Bet Queue 503 and saved as a batch.

[0078] When the recovery is complete (i.e., Bet Process 501 ensures all data has been transferred to volatile memory and that the states of Number Storage and Ticket Storage match), the Bet Process Worker 506 process is started to transfer the real-time consumer wagers received during the recovery period into homogeneous volatile and non-volatile memory 520. The Bet Process Worker 506 accomplishes this task by first messaging the Bet Queue 503 with "readBatchO" to relay all new wagers back 513. Next, the Bet Process Worker 506 messages Ticket Storage 504 via "insertTicketsQ" to append the received new wagers into its volatile and non-volatile memory 514 followed by a similar messaging— i.e., "updateNumbers ()"— with Number Storage 505 to append the new numbers 515. Upon completion of these tasks, the merged data becomes the restored volatile and non-volatile database 516 through

"commitBatchO".

[0079] Optionally, a preferred embodiment of the present invention is also capable of producing Macs for validation of draw game tickets (155 of FIG. IB) presented for redemption. This validation service is intended to replace the serial number preprinted on the back of the ticket paper stock, thereby allowing cheaper (i.e., generic) thermal paper stock to be utilized. Additionally, this validation function provides a higher level of ticket authentication, for any ticket presented for payment (i.e., all prize tiers) as well as for wagers originating from consumer digital devices (e.g., iPhone ).

[0080] For security concerns, this validation service and associated data should be hosted at an independent physical location with separate personnel access than the rest of the system since the authentication data must be kept secret from all personnel with access to the rest of the system. The security goal is to increase the level of collusion necessary to an impractical level necessary to defraud the overall system. Thus, the validation system security is preferably designed with strict whitelists access.

[0081 ] The validation system will have a service which will accept three items of data:

1. The location or device that placed the wager

2. The drawid and the set of numbers selected

3. The time at which the wager was requested

When this data is received, the validation system will perform a plausibility test on the time (e.g., was the wager received within one minute?) of the initiated request. Assuming this timing test passes, the validation system will then use a privately held randomly generated set of data with a suitable trapdoor function to create a response token or Mac which can later be used to prove that a ticket sale was correctly verified at the appropriate time by the verification subsystem.

[0082] Thus, the security features of the validation system will result in a failure of verification if any of the following is detected:

1. Modification of the bet selection 2. Creation of a ticket after the draw has been made

3. Creation of a ticket from a location not registered with the authentication system

[0083] Part 4 of the Appendix is a simplified representative example of a code snippet 700 for executing ticket validation. In the actual software, it would be preferred to offer a different API (Application Programming Interface) to each entity accessing the validation module.

[0084] Preferred embodiments of the present invention may be implemented as methods, of which examples have been provided. The acts performed as part of the methods may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though such acts are shown as being sequentially performed in illustrative embodiments.

[0085] It should be appreciated by those skilled in the art in view of this description that various modifications and variations may be made present invention without departing from the scope and spirit of the present invention. It is intended that the present invention include such modifications and variations as come within the scope of the appended claims.

APPENDIX

Part 1.

/**

* This class will store a ticket in the correct set of keys.

* It also provides utility methods for retrieving the correct key name for different classes of key sets.

*/

public class TicketDAO { public static void storeTicket(Pipeline pipeline,Lottery Ticket ticket) {

pipeline. sadd(getTicketKey(ticket.getDraw(), ticket.getBalls()), ticket.getID()); for (int n : ticket.getBalls().getBalls()) {

pipeline. sadd(getNumberKey(ticket.getDraw(), n), ticket.getID());

}

} public static void storeTicket(Jedis jedis,Lottery Ticket ticket) {

Pipeline p = jedis.pipelined();

storeTicket(p, ticket);

p . sync AndRe turn All() ;

} public static String getTicketKey(LotteryDraw draw, BallSelection balls) {

return draw.getDrawId() + "_t_" + balls.toString();

} static String getNumberKey(LotteryDraw draw, int number) { return draw.getDrawId() + "_n_" + number;

} public static String getMatchKey(LotteryDraw draw, int[] numbers) {

return draw.getDrawId() + "_m_" + Array Utils.toString(numbers);

} public static String getPrizeKey(LotteryDraw draw, String description) {

return draw.getDrawId() + "_p_" + ArrayUtils.toString(description);

}

}

END of Part 1.

Part 2.

public class BetProcessWorker {

SalesQueueDao myQueue;

TicketDao myStorageDao;

RealTimeTicketDAO myRealTimeDao;

/**

* We will have many of these instantiated and reading tickets off the queue - ideally, the number would auto scale

*/

public BetProcessWorker () { /**

* The ticket processor will sit in a continuous loop.

* The dequeueTicket method will block until a ticket is available

*/

while (true) {

//read the next available ticket from the queue, and ensure no other processor reads it concurrently

Lottery Ticket ticket = myQueue.dequeueTicket();

try {

//place the ticket in the storage

myStorageDao.storeTicket( ticket);

//update the real time accounting

myRealTimeDao.storeTicket(ticket);

//notify the queue that the ticket has been successfully committed to both storage systems and may therefore be deleted form the queue

myQueue.commitDequeue(ticket);

} catch (Exception e) {

//If any of the writes fail, this block is invoked, and then the ticket is returned to the queue

//Note that the two storeTicket methods must be idempotent - ie, it must be invokable twice with the same ticket without incorrect maths

//Note also that the dequeueTicket method will have a timeout and autorollback in order to ensure correct accounting occurs if the BetProcessWorker service itself fails

//The following call just exists to ensure that reprocessing of a failed ticket can occur as quickly as possible

myQueue.rollbackDequeue(ticket);

}

}

}

} END of Part 2.

Part 3.

/ * The static instances of this class takes the set of possible n from y matches, and stores the indices of each of them.

* It is then able to take a BallSelection and return the actual numbers which are matched.

* So if {2,4,6} is a possible match 3 from 6, and the BallSelection is { 12,15,45,48,56,59} then getMatches will return { 15,48,59}

*/

public class MatchEnumerator {

private int[][] myMatchlndices; public static final MatchEnumerator ThreeFromSixMatchEnumerator = new

MatchEnumerator(

new int[][] { { 1, 2, 3 }, { 1, 2, 4 }, { 1, 2, 5 }, { 1, 2, 6 }, { 1, 3, 4 }, { 1,

3, 5 }, { 1, 3, 6 },

{ 1, 4, 5 }, { 1, 4, 6 }, { 1, 5, 6 }, { 2, 3, 4 }, { 2, 3, 5 }, { 2,

3, 6 }, { 2, 4, 5 },

{ 2, 4, 6 }, { 2, 5, 6 }, { 3, 4, 5 }, { 3, 4, 6 }, { 3, 5, 6 }, { 4,

5, 6 } }); public static final MatchEnumerator FourFromSixMatchEnumerator = new

MatchEnumerator(

new int[][] { { 1, 2, 3, 4 }, { 1, 2, 3, 5 }, { 1, 2, 3, 6 }, { 1, 2, 4, 5 }, { 1, 2,

4, 6 }, { 1,2, 5,6}, { 1,3,4,5 }, { 1,3,4,6}, { 1,3, 5, 6 }, { 1,

4,5,6}, {2,3,4,5 },

{2,3,4,6}, {2,3,5,6}, {2, 4, 5, 6}, {3, 4, 5,6}

}); public static final MatchEnumerator FiveFromSixMatchEnumerator = new

MatchEnumerator(

new int[][] { { 1, 2, 3, 4, 5 }, { 1, 3, 4, 5, 6 }, { 1, 2, 4, 5, 6 }, { 1, 2, 3, 5, 6

}, { 1,2,3,4,6},

{ 2, 3, 4, 5, 6 } }); public MatchEnumerator(int[][] matchlndices) {

myMatchlndices = matchlndices;

}

? public int[][] getMatches(BallSelection balls) {

int[][] myMatches = new int[getMatchCount()][getBallCount()]; for (int n = 0; n < getMatchCount(); n++) {

for (int i = 0; i < getBallCount(); i++) {

myMatches [n][i] = balls.getBalls()[getMatchIndices()[n][i] - 1];

}

}

return myMatches;

}

END of Part 3. Part 4.

private Map<String, String> myPrivateCodes = new HashMap<String, String>(); public boolean register(String locationid) {

// the location is already registered

if (myPrivateCodes.containsKey(locationld))

return false;

// generate and store a random piece of data

myPrivateCodes.put(locationId, UUID.randomUUID().toString()); return true;

} public String getVerificationCode(String locationid, String drawld, int[] balls, Date timeOfRequest)

throws Exception {

String privateCode = myPrivateCodes. get(locationld);

if (privateCode == null)

throw new Exception(" locationid not held in database: cannot verify"); // check that the request is less than a minute old

if (System.currentTimeMillis() > timeOfRequest.getTime() + 60 * 1000)

throw new Exception("Time of request is more than a minute ago: cannot verify");

String plainText = generatePlainText(privateCode, locationid, drawld, balls, timeOfRequest);

return Verificationlmpl.digest(plainText);

} public boolean verifY(String verificationCode, String locationid, String drawld, int[] balls, Date timeOfRequest) throws Exception {

String privateCode = myPrivateCodes.get(locationld);

if(privateCode == null) throw new Exception ("locationid not held in database: cannot verify");

String plainText = generatePlainText(privateCode, locationid, drawld, balls, timeOfRequest);

return VerificationImpl.digest(plainText).equals(verificationCode);

} private String generatePlainText(String privateCode, String locationid, String drawld, int[] balls,

Date timeOfRequest) {

return privateCode + "_" + locationid + "_" + drawld + "_" +

ArrayUtils.toString(balls) + "_"

+ timeOfRequest.getTime();

}

END of Part 4.

END OF APPENDIX

[0086] What is claimed is:




 
Previous Patent: LOCKING DEVICE

Next Patent: SMART CONTAINERS OR JARS