Patent Publication Number: US-2003228910-A1

Title: Lottery management system

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
     [0001] The present application claims priority of U.S. patent application No. 60/386,740, filed Jun. 10, 2002, entitled “Lottery Management System”. 
    
    
     
       FIELD OF THE INVENTION  
       [0002] The present invention relates to lottery systems, and more particularly to a lottery management system and platform for distributing dynamic lottery system services and functionality across an open communications network.  
       DESCRIPTION OF THE RELATED ART  
       [0003] Lottery ticket sales generate large revenues for government-run programs. Typically, the state lottery organization will authorize lottery sales agents to sell lottery tickets in exchange for a commission on overall sales and winning ticket sales. Lottery sales agents include common retailers, such as gas station and convenience store operators, who are typically provided with one or more of a variety of lottery-dispensing technologies covering various types of lottery games. For example, a 24-hour convenience store may have a point-of-sale (POS) lottery terminal behind the counter for management by a clerk, as well as a self-service lottery kiosk available to customers elsewhere in the store. The method of purchase and delivery usually depends on the type of purchase being made. For example, the purchaser of an instant scratch ticket, for example, may pay for the ticket at the POS counter, or through a self-service kiosk. Since instant win scratch tickets can be pre-printed and issued in bulk to the lottery sales agents, no formal registration of the ticket purchase is necessary. Validation of a winning ticket occurs when the ticket bearer provides the ticket to an attending clerk, who can scan the ticket serial number for authentication.  
       [0004] Alternatively, for large lottery pools such as the BIG GAME™ or POWER BALL™, where purchasers pick a series of numbers for a chance to win a large jackpot, the numbers must be recorded with the centralized lottery operators. In this case, a lottery form can be filled out by the purchaser and presented to the clerk or self-service kiosk. The form is then read by a computer reader and the selected numbers sent over a network connection to a central transaction processor, which records the numbers and sends acceptance information back to the POS terminal or kiosk. The local lottery machine then prints the now-registered lottery ticket for the purchaser.  
       [0005] The advantages to having an electronic network to receive and issue lottery information are many. First, the registration of purchased tickets ensures the lottery service provider knows important information, such as the exact number of winning tickets and their location of purchase, for example. Second, the lottery service provider can print special codes or provide elements of authentication to prevent unauthorized forgery or copying of lottery tickets. Third, the information recorded can provide valuable business management insight, such as what games are selling well in which locations and at which times, for example.  
       [0006] Past lottery systems have employed proprietary system architectures communicating over a “closed network.” While such systems fulfill the requirements of high-performance lottery transaction engines, they do not allow for easy integration with outside networks. Such systems typically include applications and operating systems written in procedural languages, tightly integrated with their hardware platforms. Efforts to port current software applications to alternative hardware platforms have proven costly and time-consuming. Thus, current lottery systems have difficulty communicating with external networks and non-lottery applications.  
       [0007] What is needed is a networked lottery system that can enable existing and future lottery service providers and sales agents with a simple means for incorporating lottery retail services and related management functionality. Such a lottery system would enable the lottery service providers to immediately address system management needs, such as activating or deactivating a lottery sales agent, initiating or discontinuing a particular lottery game, and isolating system network or fraud problems. The system would further provide enhanced business management information, at the lottery service provider level as well as the lottery sales agent level. The system would operate using network communication and programming standards so as to enable simple scalability and expansion. These and other features are addressed by the present invention.  
       [0008] It is thus one object of the present invention to provide a substantially open standard, electronic lottery platform, which enables current and future lottery service providers to easily integrate with and establish a customized package of lottery system features.  
       SUMMARY OF THE PRESENT INVENTION  
       [0009] The system of the present invention ensures lottery service providers can provide a highly reliable, extremely secure, fast and standardized system enabling all their mission-critical business needs. In addition, through plug-and-play architecture, the system of the present invention ensures a high degree of re-usability, thereby ensuring shorter time to market and providing a cost-effective solution to support the lottery community. In one embodiment of the invention, the system of the present invention can employ the Internet for providing a new range of on-line customer services. The system of the present invention is platform-, operating system- and database-independent and allows for easy integration of third party applications. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0010]FIG. 1 is a diagram showing one conceptual architectural layout of the present invention.  
     [0011]FIG. 2 is a diagram showing information flow between a third party terminal and the system of the present invention.  
     [0012]FIG. 3 shows a diagram illustrating the different device types and access methods in accordance with one embodiment of the present invention.  
     [0013]FIG. 4 is a simplified block diagram of the lottery platform architecture layers in connection with one embodiment of the present invention.  
     [0014]FIG. 5 is a block diagram of the operational components of one embodiment of the present invention.  
     [0015]FIG. 6 is a flow chart illustrating the implementation steps associated with a lottery service provider in accordance with the present invention.  
     [0016]FIGS. 7 and 8 are detailed architectural diagrams showing example logical architectures in connection with thin and thick client embodiments, respectively, of the present invention.  
     [0017]FIG. 9 is a diagram showing the various actors and interactive capabilities in accordance with one embodiment of the present invention.  
     [0018]FIG. 10 shows a diagram of the components involved in connection with an interactive component of the present invention. 
    
    
     PREFERRED MODE(S) FOR CARRYING OUT THE INVENTION  
     [0019] As shown in FIGS. 1 through 10, there is provided a lottery management and delivery system  10 , which can integrate legacy lotteries as well as new lottery systems so as to allow customization of lottery system attributes. The lottery management system of the present invention can be used to enable various lottery service providers (e.g., state lotteries), to implement their lottery network. In one embodiment, the lottery management service is an isolated provider of the necessary hardware, software, and network components to enable lottery operations, while in another embodiment, the lottery management system provides and supports such components electronically, to the extent possible over network connections. Among other things, the present platform assists in lottery system administration, network management, transaction processing for multi-state games, reporting, and integration and communication with lottery service providers and third party application developers.  
     [0020] As shown in FIG. 1, the lottery management system of the present invention can include at least one lottery engine or host component (indicated generally at  20 ), a message exchange component  30 , a transaction processing component  40 , a commerce services component  60 , a system services component  80 , and a channel processing component  90 . In one embodiment, the platform of the present invention is based on the Model-View-Controller (MVC) architecture, known to those skilled in the art. MVC is the core architectural model for any Java 2 Platform, Enterprise Edition™ (J2EE) based system. The channel component  90  represents the “View”, the commerce services component  60  represents the “Model”, and the transaction processing component  40  represents the “Controller” of the system.  
     [0021] In one embodiment, the lottery management system and the lottery service provider processing components include a series of PC servers which individually handle transaction processing, communications, data storage, game management and network management functions. For example, the transaction processing engine  40  processes, logs, and stores all transactions on a real-time basis. The transaction processing engine can communicate using Internet protocol (IP) over one or more secure local area networks (LANs) or wide area networks. In one embodiment, the communications servers can integrate the variety of communications networks (POTS, dial-up, frame relay, x.25, Internet) used by the lottery service provider and provide the interface to the lottery terminals. The gaming platform services ( 200  in FIG. 5) connect to the transaction processing engines over LANs or WANs and host all instant and online game validation, retailer management, accounting, instant ticket distribution management and reporting functions. This is the lottery service provider&#39;s direct interface into the lottery system. In one embodiment, games are stored locally in a fat client arrangement. In another embodiment, terminals are thin clients provided with browsers for accessing game applications via a web server/application server combination, as shown in FIG. 1 and described in more detail hereafter.  
     [0022] Access to the system of the present invention can occur via a private or public network  35  through a variety of network-enabled user interfaces. For example, the lottery system of the present invention may be accessed by a chain store  11  for retailer management purposes, a “point of lottery” (POL) device  12  (e.g., a lottery terminal or kiosk at a convenience store), a retail checkout terminal  13  adapted with programming and network connectivity to enable lottery system processing activities (e.g., a “Lottery Inside”™ terminal), a user or player&#39;s personal computer  14 , a user&#39;s mobile device  15 , and a lottery director&#39;s personal computer  16 . Devices  11 - 16  access the lottery system of the present invention via a respective channel  91 - 96 , as shown in FIG. 1, so as to facilitate execution of various lottery and non-lottery transaction types.  
     [0023] The lottery sales agent POS devices or other lottery terminals can be “thin” client or “thick” client terminals. In a thin client implementation, a web browser such as Microsoft Internet Explorer™ resides on the POS device and accesses appropriate gaming applications available on the network from an application server (or combination web server and application server). The POS device can be a PC, electronic cash register, web appliance or lottery terminal, such as an Altura™ combination lottery reader/printer commercially available from GTECH Corporation, West Greenwich, R.I. When a transaction occurs, inputs from the thin client are transmitted to the application server where they are processed and transmitted to the lottery central system for logging. The serial number is then transferred back to the IP printer at the agent location, where the lottery ticket is printed. In a thick client implementation, a complete lottery application resides on the lottery terminal and the data can be communicated throughout the network such as from the lottery terminal to the central system. It will be appreciated that the present invention can be used by current lottery service providers having an existing thin or thick client topology in place. It will further be appreciated that the present invention can accommodate a variety of input and output devices.  
     [0024] As shown in FIG. 2, third party software applications  18  or a standard Internet browser  19   b  can provide the user interface for lottery activities. In either case, the third party terminal  13  can additionally integrate a transaction handler  19   a  and a peripheral server  19   c.  The purpose of the transaction handler  19   a  is to abstract system communications and security details from the third party application  18 , which is necessary to keep future updates or modifications to system communications and/or security isolated to one controllable component. To do this, the transaction handler  19   a  provides an interface that the third party application  18  must conform to, by defining how and what data will be exchanged with the transaction handler  19   a.  The transaction handler exchanges data with the retailer channel  93  in a defined format, as will be understood in the art.  
     [0025] The transaction handler  19   a  can have different functionality depending upon the user interface used. In one embodiment, the transaction handler can provide methods for passing sales information only, while in another embodiment, methods for exchanging data for all lottery activities can be provided. The peripheral server  19   c  provides services to devices such as printers. The peripheral server can be local to the printer and can be running in the device itself, in the POS or in a “black box” type of device separate from device  13 . The server can provide security and services for printing tickets, for example.  
     [0026] Device  13  can be designed with a browser interface that accesses the appropriate channel server when lottery functionality is desired. The channel server then provides the lottery user screens that are displayed on the POS device. In one embodiment, the POS device can be provided with touch screen input capabilities, allowing the retailer to perform the normal lottery sales transaction by touching areas on the screen. The lottery transaction is then processed through the IP network, channel server  93  and the transaction processing engine  43 . The transaction is processed and logged in the same secure manner (e.g., through processor  50 , the message exchange component  30  and to the host processor  20 ), and then sent back through the secure system directly to the secure lottery printer where the ticket is presented to the retailer.  
     [0027] A channel (e.g.,  91 ) is the interface to the system of the present invention from a user-device access perspective. The channel operates based on the system actor, the device being used and the communication method. Upon receiving requests from the point of contact device, the channel identifies the type of request, validates the input, and routes the request to the appropriate acquirer. The channel is also responsible for managing user session data and will pass any errors back to the point of contact device. In one example implementation, each channel can comprise an application server for performing the required programmatic functions and a web server for providing the appropriate user interfaces for data input and output.  
     [0028] The lottery engine or host  20  can comprise one or more different types of lottery hosts. Lottery hosts such as the AlphaGOLS™, EuroGOLS™ and ProSyS™ systems are examples of hosts for use with the present invention. EuroGOLS™, AlphaGOLS™ and ProSys™ are commercially available from GTECH Corporation, West Greenwich, R.I., USA. EuroGOLS™ and AlphaGOLS™ hosts provide online and instant ticket processing functions, and ProSyS™ provides video lottery processing functions for lottery games such as bingo, blackjack, poker and keno, for example.  
     [0029] The hosts can operate using a multitude of stored procedures. In one embodiment, the stored procedures are sets of SQL statements that perform a logical group of database operations. For example, the Video ProSys system uses the stored procedures extensively to maintain and manage the video games, video lottery terminals (VLTs) and VMTs. The Video ProSys (VPS) management application use these stored procedures to access, display and update the data on the database. Thus, in one embodiment, the VPS management application communicates with the database server using stored procedures. The Video Lottery System (VLS) database server processes the stored procedures using an SQL server. The definitions for the stored procedures are kept in the database server and accessed through the SQL server. The results of the request are returned to VPS management application.  
     [0030] The transaction processing engine  40  ensures the integrity of the system of the present invention by automating the transfer of data between the back-end lottery host and storage components and the front end point-of-contact devices. In part, the transaction engine can cache and asynchronously send requests when the host is unavailable, and can also cache responses. As shown in FIG. 1, the transaction engine includes a series of acquirers  41 - 46  corresponding to respective channel components  91 - 96 . A transaction acquirer (e.g.,  41 - 46 ) acquires transactions and processes them with a suitable processor (e.g.,  51 - 59 ). The acquirer is responsible for identifying the message request from the channel and forwarding the message to the appropriate processor. In one embodiment, the acquirer exists in the form of a command and is the placeholder for the business logic for authentication and coordination of game play. The command locates the correct game processor for the request and forwards the game option information to that processor. The acquirers can also pre-process some of the acquirer transactions, such as performing the management and accounting functions for the actors, for example. As shown in FIG. 1, the acquirers communicate with each other, within the system and across multiple systems. The acquirers are in communication with the commerce services component  60 , as well as transaction processors  51 - 59 .  
     [0031] A transaction processor manages and account for the products used in accordance with the present invention. The role of processors is product management. In one embodiment of the present invention, the games use a transaction processor, which is the placeholder for the business logic for wagers, validations, and cancellations. The current generation of processors is lightweight and most of the transaction processing is done at an external host that is connected to the system of the present invention. These processors delegate their processing functions to external systems through message exchange. For example, lightweight processors can delegate their processing functions to external systems through message exchange component  30 . In one embodiment, processors can include a sports processor  51 , numbers processor  53 , lotto processor  55 , PowerBall processor  57  and Instant game processor  59 .  
     [0032] Message Exchange (MX)  30  provides the interface between the internal processing in accordance with the present invention and the external processing systems such as provided by hosts  20 . MX can be based on an application programming interface/service provider interface (API/SPI) model. SPI is the programming interface for interfacing with the external processing systems. In one embodiment, a product routing code can direct the system to route the transaction to the transaction engine via Message Exchange (MX), for example, whereupon a timer can be set for transaction timeout while waiting on the transaction engine. Message Exchange (MX) is a communications protocol that enables the transaction engine to communicate with a lottery host. In one embodiment, the MX resides partially on the lottery host  20  and partially on the transaction engine  40 . The MX can take data received via Internet protocol (IP) and makes it interpretable by the lottery host  20  and vice versa. The MX client/server architecture supports both push and pull message flow models, allowing both client and server systems to initiate message traffic and act as senders and receivers of messages. The client and server side processes implemented via MX are well-known in the art and do not necessitate detailed explanation.  
     [0033] As shown in FIG. 1, system services component  80  can include system database  82 , e-mail server  84 , Java naming and directory interface (JNDI) server  86 , and business object repository  88 , as well as other system services elements such as policy server and database management programming. The database tables used by the present invention can include the retailer profile, game parameters, and device profile, for example. Retailer profile can contain values for agent, teller, terminal number, wager units, validation units, and CDC date, for example. Game parameters can contain values specific to each game and device profile contains information about the terminals connected to the system.  
     [0034] As part of the commerce services  60  in connection with the present invention, the system of the present invention provides for a claims and settlement system  61  in connection with the acquiring processor or transaction engine. The claims and settlement system  61  provides transaction settlement, auto-reconciliation, and claims management for retail operators and service providers. The system also performs adjustments processing, transaction fee processing, and balancing, monitoring and reporting functions, while further supporting multiple settlement entity types  68 , such as institutions, interchanges, banks, merchants, operators and terminals. The commerce services component further provides for the management of user and device profiles  62 , accounts  63 , product catalogs  64 , electronic wallet functionality  65  and electronic fund transfer  66 , as shown in FIG. 1.  
     [0035]FIG. 3 illustrates the various device types and access methods used in connection with one embodiment of the system of the present invention. As shown in FIG. 3, device types capable of accessing the system  210  of the present invention can include a retailer terminal  212 , an in-store cash register or kiosk  213  (including those provided with internal lottery processing capabilities), a wireless phone  215 , a home computer  214 , an interactive television  217  and a management terminal  216 , for example. Retailer terminal  212  can access the system  210  via private or virtual private IP network  231 , for example. In-store register  213  can access the system via in-store network  232  and the private IP network  231 , for example. Wireless device  215  (which can be a personal digital assistant (PDA) in one embodiment) can access the system via cellular network  233  which can ultimately connect to the system  210  via the public Internet  335 , for example. It will be appreciated that the present invention can accommodate wireless access by a number of devices using a variety of communications protocols. For example, the present invention can transmit communications via short-messaging service (SMS), multimedia messaging service (MMS), I-Mode™, wireless access protocol (WAP), unstructured supplementary service data (USSD), and interactive voice response (IVR), among others. Home computer  214  can also connect to the system via the Internet. Interactive television  217  can access the system via the Internet  235  and a cable service provider network  234 , for example. Management terminal  216  can access the system  210  via an intra-site local area network (LAN)  236 , for example.  
     [0036] Upon access, the system  210  of the present invention can provide system and commerce services  260  as well as gaming and other applications  270 . System and commerce services can include programming for device management, retailer management, other user management, general accounting, e-commerce components, file transfer, transaction acquisition, security implementations, static web pages, player management, presentation primitives, wallet management, electronic funds transfer, batch report repository, general repository and a product catalog, for example. Such programming may be designated as accessible only to particular user types, in one embodiment. Applications  270  can include, for example, game presentation, retailer invoicing, check printing, wagering games (instant and draw-based), and a report manager. The system and commerce services and other applications can further communicate with a host processor as previously described. In one embodiment, as shown in FIG. 3, hosts  221  and  222  represent a primary hosting site, and host  229  represents a backup site in case of failover. Hosts  221  and  222  can perform a multitude of functions, including providing batch reports, product information, traditional game processing, and storing the business object repository, for example.  
     [0037] As shown in FIG. 4, the system is logically comprised of three separate software layers. The base layer  150  (Layer  1 ) is the system interface layer, which defines the communication and hardware functions and other system components. The base layer can comprise a network of servers  152  which facilitates communication between PC-based client terminals and a transaction processing engine. In one embodiment, the base or network layer can include a proprietary IP (Internet protocol) network  155 . In an IP-based network, a server on the network logically and dynamically supplies POS device addresses. Data packets are routed/switched within the network based upon source and destination information contained within each packet. An IP network such as can be used in the present invention provides inherent flexibility in deploying client terminals and routing transactions throughout the network. Full redundancy of the network, advanced recovery mechanisms, and network operations and customer support services ensure the continuous network availability necessary for lottery service providers. In one embodiment of the invention, the core network can be a virtual private network (VPN).  
     [0038] At the base or network layer, security can be implemented in order to provide authentication, authorization, and integrity services for data carried on the network. Such security can assist in protecting the network and its users from network-based attacks, which may be conducted by outsiders attempting to read data, modify data, deny service such as by exhausting network resources, and probe network configurations. Such protection against external attacks can be provided, for example, by firewalls, IP filtering, IP tunneling, hub authentication and line encryption, as well as by the physical and logical protection of the associated servers and routers within the lottery sales agent and lottery service provider equipment.  
     [0039] As shown in FIGS. 4 and 5, the middle layer  200  (Layer  2 ) is the gaming platform services layer, which resides above the base or network layer. With a secure, reliable network in place, the present invention provides for the reliable, secure information transfer required by lottery service providers. The gaming platform services layer is the middleware layer that provides the most commonly needed middleware services for a lottery system.  
     [0040] This includes the transaction processing engine  40 , network management  210 , sales agent management  220 , communication services  230 , game management  240 , reporting  250 , security  260  and other management functions such as system administration, hotline application administration, point of sale administration, and retail management functionality. As shown in FIG. 5, for the lottery service provider, gaming platform services can include adding and removing lottery sales agents, adding and removing game applications, adding and removing back-office business applications, restoring faulty network connections, and monitoring the security and efficiency of the lottery system. The lottery transaction processing engine can host traditional lottery applications and can process, log, and store lottery transactions from each lottery sales agent for the lottery service provider. In one embodiment of the present invention, the transaction processing engine can be a ProSys™ or AlphaGOLS™ transaction processing engine. In a further embodiment of the invention, electronic funds transfer (EFT) applications can be accommodated, as described elsewhere herein.  
     [0041] The middle layer for each lottery service provider can include a web server, an application server, a message exchange component and a lottery engine or transaction processing engine  40 . The application server and web server can comprise a channel component as described earlier. The message exchange component takes data delivered via Internet protocol and makes it interpretable by the lottery transaction engine component. The web server can act as an HTTP server, thereby serving as a conduit for devices (e.g., 12) containing browsers for accessing applications as provided by the present invention. The application server provides the applications for use with the present invention, including lottery game applications in the thin client embodiment of the present invention. Lottery game applications can alternatively be stored on a separate lottery server. In one embodiment of the invention, the application server functions are allocated across numerous application servers.  
     [0042] As described earlier, the application server is, in one embodiment, J2EE (Java 2 Enterprise Edition) compliant. Typically, the application server can interface with system databases in order to retrieve and store transaction information. The web servers and application servers can operate in a variety of operating systems, including Windows™, LinUX™ or Unix™ operating systems, and can interface with various types of commercially available databases, including Sybase™, Oracle™, Informix™, IBM™ and Microsoft SQL™.  
     [0043] As shown in FIG. 4, the top layer (Layer  3 ) is the application or gaming platform API layer  300 . The top layer  300  provides the communication methods for accessing the gaming platform services layer. It is at this layer that third party developer applications  350  can communicate and be integrated with the system of the present invention.  
     [0044] At the lottery sales agent level, the system administration capabilities depend upon the sales agent and the types of lottery dispensing technologies employed. For example, a particular retailer may have stores in multiple locations and may desire to centrally manage the lottery operations of each store. Such a lottery sales agent can be provided with system and network management capabilities, reporting and interfaces for non-lottery third party applications.  
     [0045] Lottery sales agents can communicate directly with their particular state lottery via private network or over a public network such as the Internet. The communications between the state lottery service provider and the lottery sales agent generally pertain to the purchase and recordation of lottery drawing tickets. For example, a particular state lottery may offer instant scratch tickets as well as various types of lottery drawing games, including a Pick-3 game, a Pick-4 game, a Super Lotto game, and a multi-state game. For the lottery drawing games, it is necessary to record different fields of information to determine the ultimate cash prize distributions. Thus, the communication from a particular sales agent may include the purchaser&#39;s selected numbers, the store in which the purchase was made, the game related to the purchase, and the date and time of purchase. Once sent to the lottery service provider, this information is processed by the game&#39;s transaction processing engine and stored in a database, and information is sent back to the lottery sales agent for the printing of a lottery ticket receipt.  
     [0046] As shown in the method  600  in FIG. 6, in operation, the system of the present invention can be used to integrate new or legacy lottery systems as follows. First, the lottery service provider is registered with the lottery distributor or management system as at  605 . The lottery service provider is then provided with necessary hardware and networking equipment to support network, client and server functions, as at  610 . For each lottery sales agent, the appropriate number and type of POS devices are determined and are configured as at  620  so as to be a thin or thick client implementation. The lottery service provider is also provided with the appropriate network of servers to support IP communications, appropriate security, lottery game applications, a lottery transaction processing engine, network management and reporting functions, as at  625 . Next, the management services can be established and the types of lottery game applications can be selected by the lottery service, as at  630 . The lottery service provider may choose games based upon various business strategies.  
     [0047] As at  635 , the lottery service provider may also choose to integrate third party applications, which can be lottery-related or non-lottery related. Such non-lottery applications may include business applications designed to mine the lottery service provider&#39;s collected data to determine which game applications are most profitable, for example. Because of the open nature of the system architecture of the present invention, interfacing with third party applications is readily achievable while preserving data integrity, volume and speed. In one embodiment of the invention, third party applications can be provided as plug and play web services, enabling the lottery management service, lottery service provider, or lottery sales agent to select the most appropriate or desirable lottery or non-lottery application to assist with appropriate level business operations. As examples, a lottery sales agent can be enabled for inter-agent communications for consumables exchange, or the lottery sales agent can be enabled to view motion video using its POS web browser, such as might be useful in reporting and displaying winning ticket numbers.  
     [0048] Through these capabilities, it can be appreciated that the present invention provides an enhanced platform for lottery integration. In one embodiment, the platform of the present invention can be based upon the Java 2 Platform, Enterprise Edition (J2EE), and can allow lottery service providers to integrate their internal information systems with those of partners, suppliers, and distributors, while further enabling the placement and tracking of orders, the reporting of problems, and manipulation of account information. This may include, for example, connectivity to other internal or external data sources for increased business intelligence.  
     [0049]FIGS. 7 and 8 illustrate sample thin and thick client implementations, respectively, of the system of the present invention. In the thin retail terminal example implementation  500  shown in FIG. 7, there is provided a POS terminal (indicated generally at  502 ) which can be a non-browser based terminal  505  or a browser based terminal  510 . Examples of a non-browser based terminal can include kiosks and retail convenience store POS devices. Browser-based terminals can operate using a standard Internet browser, such as Mozilla 1.0™, Netscape Navigator™, or Microsoft Internet Explorer™ version 5.0 or later, for example. Terminal  505  can access retail channel  590  via SOAP (simple object access protocol) request and a POS servlet  515 . In this embodiment, the retail channel  590  is shown as part of the MVC architecture described earlier. The POS servlet can access an action servlet  522  with the instructions from the terminal  505 , which may be to sign on or perform a lottery activity, for example. Based on the instruction, the POS servlet can return the appropriate instruction to the terminal  505 . Terminal  510  can send an HTTP (hypertext transfer protocol) request to action servlet  522  which can-initiate action  525  and action form bean  532  so as to return a Java server page implemented HTTP response for display on the terminal  510  browser. Such SOAP and HTTP communications will be well understood to those of skill in the art.  
     [0050] As further shown in FIG. 7, lottery transactions initiated by the terminals  505 ,  510  are acquired by the acquirer  540 , including the specific acquirer  540   a - h  for which the lottery transaction or message is designed. For example, acquirers  540   a - h  can include acquirers for processing sign-on commands, Lotto commands, validation commands, cancellation commands, reprint commands, wager cost commands, home commands and print commands. The acquirer processes according to the message and delivers the message to the appropriate processor represented generally as  550  for further processing. Processors  550  communicate with system host  520  via message exchange component  530  as previously described.  
     [0051] Acquirers  540  and processors  550  are also in communication with other system and commerce services  560 . The commerce services used by the retail channel and POS channel are the retail profile  562 , game parameters  564  and the device profile  566 . The retail profile provides a placeholder for the terminals state and services available to that particular retailer. This information is stored in the database. A sign on retail bean  542  can be created in the retail channel  590  so as to allow the retail channel application to access the profile of a retailer. Similarly, a sales bean  545  can allow the retail channel application to access a player&#39;s sales list or grand total of winnings. The game parameters is the placeholder for managing the product parameters for all games. This information is stored in the database and can be updated by the message exchange. The device profile is the placeholder properties specific to the devices like printers, signs, readers etc. This information is stored in the database. Upon the system receiving a print request, such as may be entered by a lottery terminal upon a player&#39;s purchase of a lottery ticket. The acquirer associated with the print function can communicate with a peripheral server  519  at the retailer location, which can instruct a local printer  521  to print the ordered ticket.  
     [0052] As shown in FIG. 8, in the thick client embodiment, the terminal  312  may be an Altura™ or other similar terminal, which can access the system via IP network  335  or other known means, such as via satellite connection  333 , for example. The retailer channel  390  receives the communication from the terminal (e.g., thick client retail channel  394  or a “satellite optimized” thick client retail channel  392 , in FIG. 8). The channel  390  communicates with commerce  360  and system  380  services, and further communicates with acquirer  340  (specifically thick client transaction acquirer  342 ) and processor  350  (specifically thick client transaction processor  352 ) as previously described. Acquirer  340  and processor  350  are in communication with commerce  360  and system  380  services as well as with message exchange component  330 . Message exchange component translates and delivers the processed messages between processor  350  and host  320 , which can be a ProSyS™ or AlphaGOLS™ host as previously described.  
     [0053] In this embodiment, commerce services  360  can include, for example, query management system component  361  for handling queries, marketing component  362 , user profile component  363 , account management component  364 , product catalog  365 , ticket/order processing component  366  and electronic wallet component  367 . System services component can include database component  381 , repository component  382 , naming and directory component  383 , policy server  384 , e-mail component  385 , business object repository  386  and electronic fund transfer component  387 . It will be appreciated that networks  333 ,  335  can also provide direct connection to system broadcast services  375 , which can include network management  371 , device management  372  and commercial value-added services management  373 , for example. It will further be appreciated that the various components described facilitate the ease of implementation, management, communication and transaction processing of the lottery system of the present invention.  
     [0054] Operation  
     [0055] In operation, the system of the present invention allows interaction by game participants, lottery distributors, lottery providers (e.g., states), lottery retailers and third party application developers. These actors can interact with game selection and delivery, game management, system setup and commerce services. An example diagram showing the various actors and interactive capabilities in one embodiment of the invention is shown in FIG. 9. As shown therein, a lottery system distributor  905  such as GTECH Corporation provides new system infrastructure  907  in the form of system hardware, software, network connectivity and related services to establish a network-enabled lottery system  910 . It will be appreciated that components of the present invention can be adapted for use with existing lottery systems to enable desired functionality and access features. Distributor  905  also can interact with system services, game selection and commerce services as indicated at  915 .  
     [0056] A lottery provider  925 , such as a state, for example, can also interact with system services, game selection and commerce services as at  930  in providing one or more lottery games for retail distribution. A third party application provider  940  can interact with the system  910  by providing business or gaming software applications  945 , for example, to expand the management capabilities and game selection capabilities for other users of the system. Example third party applications and functionality include: (1) authentication service software, such as Experian™, which is especially advantageous in environments where there is no national authentication or identification scheme; (2) electronic fund transfer linking software, such as SolvSE™ which provides a link to the Royal Bank of Scotland; (3) high tier wagering and claims software, such as IPS™; (4) various lottery and draw-based game applications.  
     [0057] A commissioned lottery retailer  950  can interact with game selection and commerce services as at  955  and, in one embodiment, the level of interaction permitted by a specific retailer can be determined by the lottery provider  925  commissioning the specific retailer. Lottery or game players  965  can interact as at  970  with the game selection and commerce services of the present invention to enjoy the game offerings and track winnings, account information and other player information.  
     [0058] It will be appreciated that one aspect of the present invention enhances the interactivity of the lottery system. The interactivity of the present invention provides the ability to play electronic instant style and draw based games via the Internet. In one embodiment, Internet capabilities include providing an informational web site having programming to provide results-based services such as the broadcast of winning numbers by way of email and/or short messaging service-based (SMS-based) text messages to personal computers or mobile phones, for example, as is well known in the art. In another embodiment, the system of the present invention provides a fully interactive system and wagering engine with a web-based front end and the capability to wager on electronic instant tickets. This embodiment can comprise two applications, a player application and a full administration application, both of which have a web based front end. In a further embodiment, connectivity is provided to a host wagering system  21  such as AlphaGolS™ using message exchange component  30 , thereby providing the ability to play a suite of draw based games.  
     [0059] In one embodiment, the framework for providing instant games can de-couple the game play and presentation from the mechanics of the game and how it is recorded. This can be achieved by separating the presentation of the game at the front end (browser), from the system and the data generation programming (e.g., XML) at the backend, by clearly defined interfaces. This means that the range of games that can be developed is endless and will not require a change to the system itself, thereby allowing independent game developers to interact with the system of the present invention.  
     [0060] In one embodiment, the instant game framework operates such that the presentation layer, the game processor and the ticket generator are de-coupled. A predefined generic API can be defined that allows any number of instant game types to be added with ease. In one embodiment, the present invention can make use of Macromedia Flash™ for the presentation layer and XML can be used as a standard conduit. Additionally, the draw game framework can support Lotto games, including for example, Lotto™, Lotto Extra™, Thunderball™, Hotpicks™ and Big Draw™. The framework will also handle other game types (e.g. numbers) together with the handling of draw-based promotional tickets. Wallet management provides the ability to load, unload and adjust wallet balances. Both the player and administrative personnel have the ability to view financial (e.g., loads, wins, adjustments) transactions. Additionally, both the player and administrative personnel have the ability to view game (wager and winning) transactions. The application has a separate site that provides administration functions for both accounts and the application itself. Further administrative facilities provided by the-present invention can include such features as checking system availability, searching for user or prospect, managing user accounts and games, and creating/editing authorized users, for example.  
     [0061] It will be appreciated that the present system allows players and administrative personnel to create accounts. Account management includes the ability to log in, log out, reset passwords, provide for inactivity timeouts, access bookmarks, close, suspend and reinstate accounts, for example. There are a number of facilities provided by the system that allow appropriately privileged individuals to load, disable, re-enable or expire a game. Before an individual registers with the system and accesses the site they are known as prospects. Registration can be a long process. The system tracks the information being entered by a prospect and allows administrative staff to view details to give support during the registration process if required. The life cycle of both instant and draw tickets is carefully managed by the interactive system to ensure integrity and for repudiation reasons.  
     [0062] To encourage prospects to register and become familiar with the game offerings, the present invention incorporates a facility which present instant games that can be played without the need to be registered or wager using funds from a wallet. Similarly for draw games, players can fill in and save a playslip without the requirement to be registered. This extremely important facility has been added to ensure the integrity of the system and protect the player. The system saves details of the unfinished plays and presents them to the player for completion on next log in.  
     [0063] For draw-based games the rules of cancellation can mimic those present at the retailer terminal. In one embodiment, cancellations can only be executed by a suitably privileged person at the contact center. Cancelled tickets can be shown in the financial and game histories of the player. The interactive component of the present system provides extensive configurable logging capabilities. The system provides the ability for a user to create favorites (e.g., playslips) for Lotto™ and Thunderball™, for example, and save them under unique names. Once the favorites have been saved, the user can then recall them based on name in order to pre-populate or edit playslips in the future.  
     [0064] Upon completion of a winning ticket, the system can either a) credit the winnings to the user&#39;s wallet b) credit the winnings to the user&#39;s debit card or c) allow the user to arrange an appointment at a regional center to pick up a check (e.g., for high tier wins). Prior to the check being printed, a suitably privileged person can be required to log the claim in the interactive system, which then sends the necessary information to host (e.g., IPS) for check processing. The host can then send confirmation of the check payment back to the interactive component, which logs this to complete the cycle.  
     [0065] For draw-based games, the interactive component of the present system accepts a file from the host (e.g., AlphaGOLS™) that identifies and updates all draw-based tickets with either a winner or loser status after each draw. The present system also provides a ‘rollback’ facility in the unlikely event that the host has produced incorrect details. All draw-based game orders in an unknown state in the system can be tagged as cancelled in the host. In order to ensure this, the present system can create and send a file to the host containing all unknown orders for processing. This file can be sent regularly (e.g., twice daily).  
     [0066] In one embodiment, a standalone application can be used by game developers to test the presentation and ticket generator without the need for access to the instant game processor of the present invention. This can assist in helping to speed the delivery of new instant games, as problems are identified early in the delivery. Synchronization between the host and the interactive component of the present invention can be handled by way of a “heartbeat” message. At a configurable interval, the system can poll the host to check for any system status changes. If changes have been made, these can be requested and updated within the system. An authorized user can turn “throttles” on and off as well as configure the concurrent user limits used by the throttles. Throttles are configured per function in the database, and each function can map to a page or set of pages on the site. When one of these pages is requested and if the throttle for the function is turned on, then the number of concurrent users is checked. If the number of concurrent users is greater than or equal to the configured number of allowed concurrent users, then a standard error page is returned. A given player can elect to be a member of a trial group who will try new games and provide feedback. The system provides the ability to assign or unassign a player from a pre-defined trial group. The system provides a very flexible means of limiting the functional areas available to named groups.  
     [0067] For wagering users (player) the system can display a number of different notifications directed specifically to the player. These notifications inform the player about important issues regarding their account status and game playing states. The system allows for the loading and use of tokens as a method of payment for wagers. The system also allows suitably privileged personnel to adjust a player&#39;s token balance. The system further allows for player and system limits on instant games. It also provides the ability for players to elect to exclude themselves from playing an instant game or all instant games. A suitably privileged person via the administration interface can reset this setting. In one embodiment, the system provides the ability for an authorized user to execute a series of Unix commands to initiate “end of day” and “end of week” processes. The interactive component can provide a plurality of reports that cover the system sales, liabilities, player transactions and game statuses, for example. The system further allows for limited campaign management such as managing retail outlets, tokens and promotions, for example.  
     [0068] The interactive component of the present invention facilitates access to games on existing OLTP (Online Transaction Processing) wagering systems (e.g., AlphaGOLS™ and ProSys™) from interactive wagering systems. The term “interactive” in the present context can apply to any channel that does not include a retailer. An interactive player-based wagering system could consist of several channels, such as mobile, Internet, and interactive television channels, for example. The present invention places no restrictions on these channels. This interactivity across multiple channels can be provided in accordance with the present invention by using application programming interfaces (APIs). In a commercial implementation, such APIs can be offered as part of a software development kit (SDK). As seen from FIG. 10, this aspect of the present invention can incorporate three message exchange components. First a message exchange interactive component  745  can introduce the capability for communication from interactive channels to OLTP Systems. Message exchange client  750  can reside on the application server  742  and can be part of the software/system development kit (SDK). In one embodiment, the message exchange client uses the underlying J2EE connector architecture to communicate with a message exchange server  760 , as is well known in the art. The message exchange server  760  can reside on the host system  720  to allow the exchange of messages between the SDK and the host.  
     [0069] The transaction processing in accordance with the present invention is based on the concept that each transaction arrives from a terminal (e.g.,  712 ) communicating over a network  735 . The retailer places the wagers on behalf of the players and is accountable for all sales. In an interactive channel, however, the player can place his wagers directly using a mobile phone (e.g.,  714 ) or a web browser or any interactive channel and is accountable only for his wagers. The present invention bridges the gap between the two systems by creating and managing a pool of virtual terminals for the wagers coming from the interactive channel. It then forwards these transactions to the message exchange server  760  and appropriate OLTP host  722 , which in one embodiment are expecting transaction information to come from a terminal.  
     [0070] When a player places a wager, it passes through the Internet cloud and reaches the game processor  740  offered by the lottery system provider or a third party. The game processor application  740  carries out the initial processing and passes the wager on to the message exchange interactive component  744 . The wager is now allocated a virtual terminal by the present invention, which subsequently translates the wager, using message exchange client  750 , into a format compatible with the host system and passes it to the host  720 . The host processes the wager and sends a response back to application server  740 . The response is translated back into a format understood by component  740 , which de-allocates the virtual terminal from the response. The response is sent back to the player across the interactive channel.  
     [0071] In the thin client embodiment, applications no longer have to be downloaded to terminals. They reside on an application server located near the central system. Game parameters no longer have to be downloaded to a terminal. All application changes are immediately available to the POS and all game parameter changes are immediately available to the POS. Nevertheless, application performance is comparable to a thick client application. Applications can be run on many thin client devices starting from a full size POS to a small handle POS. All business logic is shared and identical at all POS devices. Presentation (GUI) is the only thing that changes. Thin client implementations reduce the cost of implementation, reduce the maintenance for each terminal device type and provide secure transaction and ticket printing. In one embodiment, third party POS devices can provide their own presentation (GUI) using the POS channel and still use the same business logic as the Retail Channel for processing wagers.  
     [0072] It will be appreciated that the present invention provides heretofore unavailable communications and revenue opportunities for lottery retailers servicing a lottery service provider (e.g., a state). For example, retailers can be provided with telecommunications network services via the lottery system of the present invention. While at least part of the network would be dedicated to the lottery system transaction processing, any available network bandwidth can be used by the lottery retailer as it sees fit. Further, the present invention provides lottery retailers with the opportunity to view its own inventory management system using an interface in accordance with the present invention. The integration of lottery product and commercial product inventory data will enable store or corporate management to run daily accounting and shift balancing reports from a single source.  
     [0073] For lottery managers or the lottery director, the present invention can leverage the present invention&#39;s lottery infrastructure to provide additional management advantages. For example, retailer reporting functions can be kept separate from the lottery reports, by providing retailers with secure access to reports from a separate web site than the lottery controlled web sites. Additionally, the present invention can enable electronic distribution of data exported or extracted from the retailer accounting system and automatically generate and transfer electronic reports via the NACS-approved standard format for extensible markup language (XML EDI).  
     [0074] The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the claims of the application rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.