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'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's personal computer 14, a user's mobile device 15, and a lottery director'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 19b can provide the user interface for lottery activities. In either case, the third party terminal 13 can additionally integrate a transaction handler 19a and a peripheral server 19c. The purpose of the transaction handler 19a 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 19a 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 19a. 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 19a 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 19c 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'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'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'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 540a-h for which the lottery transaction or message is designed. For example, acquirers 540a-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'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'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's wallet b) credit the winnings to the user'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'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'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.