US20090143128A1 - Providing centralized services to game operators - Google Patents

Abstract

Some example embodiments of the present invention address growing demand by lottery customers for expanded gaming options and new gaming concepts. Example embodiments may include methods and systems for providing a shared centralized gaming host which implements software as a service concepts for lottery and other wagering games.

Description

• This application claims priority to U.S. Provisional Patent Application No. 61/005,386, filed on Dec. 3, 2007, and entitled SYSTEM AND METHOD FOR PROVIDING CENTRALIZED SERVICES TO GAME OPERATORS, the entirety of which is incorporated by reference herein.
BACKGROUND
• Regulated wagering games are common throughout the world. Typical examples are various games offered by state lotteries. Those games, which are offered on a large scale, are operated using centralized transaction processing systems to collect and/or redeem wagers. Most state lotteries and similar entities operate their own central host system, or have it operated by a contractor such as GTECH Corporation. The host systems are typically located within the jurisdiction of the lottery provider. The state lotteries also deploy their own client equipment to operate various channels for delivering games to player customers, such as agent-operated lottery game sales terminals, unattended lottery game sales terminals, vending machines, kiosks, electronic access via the Internet from personal computers, mobile phone access, and interactive TV terminal access, etc. They also operate, or have operated on their behalf by a contractor, their own customized administration systems, such as accounting, reporting, fraud control, prize redemption systems, etc.
• Deploying new games on state lottery systems or in other gaming operations typically requires significant custom programming and the rollout of new features in all the various customized administration systems. This can take large amounts of time and resources. When a lottery has a successful new game, other lotteries want to emulate the game, which then requires additional custom work.
• There are a few cases of multi-jurisdictional games, but generally, when the same game is offered in multiple jurisdictions, each jurisdiction has its own implementation (often with variations to the business rules or play style). Even for multi-jurisdictional games like Powerball, each jurisdiction that participates has its own instance of the game and the process of determining winners for the shared jackpot is done separately in each jurisdiction—often with “low tech” exchange of data like fax or email for winning numbers, share values, etc.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a set of conventional lottery gaming systems.
• FIG. 2 illustrates an example of a gaming system, according to an example embodiment of the present invention.
• FIG. 3 illustrates another example of a gaming system, according to an example embodiment of the present invention.
• FIG. 4 illustrates another example of a gaming system, according to an example embodiment of the present invention.
• FIG. 5 illustrates another example of a gaming system, according to an example embodiment of the present invention.
• FIG. 6 illustrates an alternative example system E where a shared host system has direct access to players and retailers, according to an example embodiment of the present invention.
• FIG. 7 illustrates an example game framework, according to an example embodiment of the present invention.
• FIG. 8 illustrates another example of a gaming system including an example subsystem facilitating the interaction of content developers with the shared host system, including an example channel content framework, according to an example embodiment of the present invention.
• FIG. 9 illustrates another example of a gaming system including an example subsystem facilitating the interaction of content developers with the shared host system, according to an example embodiment of the present invention.
• FIG. 10 illustrates an example randomization service, according to an example embodiment of the present invention.
• FIG. 11 illustrates an example of a gaming system including an example back office normalization engine.
• FIG. 12 illustrates another example of a gaming system including an example back office normalization engine.
• FIG. 13 illustrates another example of a gaming system including an example back office normalization engine.
• FIG. 14 illustrates an example procedure for making a new game available, according to an example embodiment of the present invention.
• FIG. 15 illustrates an example procedure for activating a game, according to an example embodiment of the present invention.
• FIG. 16 illustrates an example procedure for revenue sharing, according to an example embodiment of the present invention.
• FIG. 17 illustrates an example procedure for playing a game on a player client, according to an example embodiment of the present invention.
• FIG. 18 illustrates an example game archive.
• FIG. 19 illustrates an example reporting module.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS
• Some example embodiments of the present invention address growing demand by lottery customers for expanded gaming options and new gaming concepts. These example embodiments include methods and systems for providing a shared centralized gaming host which implements software as a service concepts for lottery and other wagering games. The operator of the shared host, the various lotteries or game operators, and third parties, may all develop standard software new game concepts and deposit them in a repository, e.g., at the central host. Game operators may choose to activate any or all of the deposited game software and customize the deposited games in a limited way for use in their jurisdiction. Operations procedures may also be standardized and shared in some parts of the system. In this way, content developed by or for one game operator may more easily be transferred, customized, and re-used by other gaming operators, reducing the time and cost needed to develop and deploy new game content and facilitating an increase in the number of types of games which are available to game players.
• These example embodiments make it easier to provide new games and game content to lottery operators, which in turn may help lotteries acquire new players and increase sales to existing players. These example embodiments may help lotteries better enable their customers, the game players, to choose the games they want to play, through the channel they prefer, in the most responsible way, in a trustworthy environment. Players will be able to choose games with different entry systems, different ways of displaying wager outcomes, and with different odds structures, e.g., a game with a higher probability of any win versus a game with a lower probability of winning and a much higher payout.
• In other example embodiments, a centralized player registration and tracking system may be provided. This system may be used to help insure responsible gaming, both to protect players from themselves and unscrupulous retailers or third parties. The player registration system may also be used to provide frequent player or player reward programs.
• Unfortunately, the architecture of today's lottery systems presents a number of difficult challenges. Lottery systems architecture and technology vary from jurisdiction to jurisdiction. The many types of devices in the various access channels are even more diverse.FIG. 1 illustrates a prior art lottery system whereseparate jurisdictions110,120 and130 have separate host systems connected to their ownrespective retailer terminals111,121, and131,customer devices112,122, and132, andback office systems113,123, and133. Retailer terminals, other customer access systems, and back office systems are typically not shared. Lottery games and their associated content are also not isolated entities (like video games), but rather have components in many parts of the lottery infrastructure including the host transaction processing systems, retailer terminals, player channel devices and lottery back office applications. To add to this burden, many governmental game operators, such as state lotteries, are required to place their system platforms out to bid every seven to ten years, requiring a resource-hungry and time-consuming process to be followed from preparing an RFP through to the final acceptance of the deployed system. This process has become steadily more challenging as the system complexity has increased. In addition, after the initial system deployment, the lotteries spend years tailoring their systems to meet their needs only to be forced to start over again on the next cycle of system renewals. Unfortunately, all this effort in renewing the systems largely detracts from the focus of delivering on growth and ‘player choice’. Example embodiments of the present invention may help solve many of these problems, in part by allowing development efforts to be shared across jurisdictions.
• In some example embodiments of the present invention, systems may be provided that contain a suite of applications residing on a secure network, provided by a service provider. Game applications and content may be provided and owned by the creators of the content, including the various game operators. Providing content from different sources may increase the amount choice which is available to both game operators and to game players. To help increase the number of available games, there are a vast number of content providers who could participate in developing new gaming content to participate and broaden the access to their content. For example, content such as new games or new presentation schemes for existing games could be provided by existing game operators, video game companies, music and video producers, owners of well-known branded properties such as sports leagues or game and toy companies, etc. By providing new approaches to deployment of content, example embodiments of the present invention may facilitate the increase in available content.
• Rather than having separate instances of games deployed on the disparate systems of each lottery or game jurisdiction or other game operator, some example embodiments of the present invention employ a centrally hosted multi-tenant service model where games are developed and stored once in a central system. The games may then be activated and deployed by all the game operators in different jurisdictions that connect to the service. In some example embodiments, the example systems may be provided in parallel with existing legacy lottery gaming systems, providing an evolutionary path that allows existing lotteries to keep all of their existing local games and other applications while enabling simultaneous access to new games provided by the example system.
• Over time, a lottery or other game operator may be able to migrate to a total shared host environment where not only the games, but also the back office and other supporting applications, are provided as shared multi-tenant centrally hosted services. Alternatively, lotteries or other game operators that have complex, custom or special back office processes may be allowed to keep their back office systems with interfaces to the shared host, or to migrate only a portion of their back office systems to the shared host environment.
• Some example embodiments of the present invention may also include content frameworks in channel devices that enable games on the shared host environment to be accessed across existing and new channels without the need to deploy new custom software for each new game. The share host environment may also allow content to be managed across multimedia devices driven off the lottery retail network and devices, such as interactive displays in social locations in bars, on multimedia kiosks or vending machines, or even on consumer's client devices like personal computers and cellular telephones. This will allow game operators to be more proactive in managing the content presented to customers across the retailers, opening up sources of other incomes such as advertising.
• Some example embodiments of the present invention may include an independent, third party player registration and customer-relationship management (CRM) tool. By providing this tool at the shared host, this may offer greater player anonymity and protection while offering the individual game operators control and the ability to reward and protect the players.
• In some example embodiments, a shared standardized platform and tools for the provisioning of new games in the shared host environment may enable third party content developers to provide a broad range of new games and content that will be available to the various game operators. This approach may also allow the various game operators to collaborate on the creation of new content, to create or have created their own content, and then to share it with or rent it to other game operators.
• In some example embodiments, the game operators use the shared multi-tenant host platform, and share common game logic. In some alternatives, the game logic may be customizable by the game operators, e.g., when games are activated. For example, odds, payout levels, schedules, and other parameterizable aspects of game logic may be tuned by the game operators for some games. The presentation of the games, e.g., the way the wager and game outcome are presented to users, may also be customized, e.g., simple things like the branding of a game or the name of the game operator, or more complicated elements like the entire presentation of the game to players. In some cases, the game logic and the game presentation may be separate, so that multiple different game presentations may employ the same game logic. These presentations may be shared by different game operators, or may be customized by a particular game operator.
• Some example embodiments allow lotteries and other game operators to more easily provide greater player “choice”, more different game play styles, more channels of game distribution, more variation in payouts and presentations for the same game logic or play style. By allowing game operators to more easily share content, and by facilitating the provisioning of content by third party content providers, some example embodiments described here may significantly increase the quantity and quality of available game content, while at the same time reducing the cycle time for the deployment of new games, or for the spread of successful games from one operator to another. Moreover, the cost of development of new games may be more easily amortized or shared across multiple game operators, reducing costs. Some example embodiments may also facilitate the spread of games to alternative channels, such as mobile devices.
• Some example embodiments also facilitate cooperation and information sharing between different game operators, or between game operators and content providers or retailers. Common solutions to responsible gaming, e.g., age verification, player tracking, etc., may also be shared between game operators. Back office processes, e.g., reporting, accounting, market analysis, may also be shared between game operators. Moreover, because the content is provided from a shared host in a standardized way, new content may be added without the need to modify back office processes.
• Some example embodiments of the present invention take a fundamentally different approach to both the implementation model and the business model for lottery and other wagering games. A single, centrally hosted service may be provided where games implemented in software can be deployed and accessed in a Software as a Service (SaaS) model. A set of platforms and common services may be provided to allow developers to create all of the components of a game including the game logic, presentation and content components for all of the necessary channels and devices. Games that are implemented and deployed into the example service architecture may be accessed by any game operator, e.g., a regulated state lottery or other wagering game provider, that subscribes to the service from an enabled system.
• Some example embodiments of the present invention may eliminate the need for redevelopment and redeployment of a game on a site by site basis, e.g., for different game operators. A new business and revenue model for game development and deployment, and the associated processes enabling the implementation of that model may also be provided. A game operator could develop software and procedures for a new game concept either alone, with the operator of the shared host, or with a third party game developer. The game could then be distributed via the shared host to all other participating game operators. The original game operator and/or the third party game developer could get either a fixed license fee or percentage of sales from the other game operators participating in the game. The operator of the shared host could also obtain revenues by either a one time license, a percent of sales license, or from fees paid by the content developers to allow them to distribute content.
• Some example embodiments include systems and methods for providing services directly to the players independent of any of the participating game operators. In these embodiments, players may directly access the shared host via the Internet and manage a global player account and profile that can be tied to any of the game operators participating in shared host. This means that a player needs to manage only one set of preferences and one financial account or electronic wallet. Similar hosted services can also be provided directly to retailers for applications like lottery inventory management and financial accounting. This can enable multi-jurisdiction retailer chains to manage their global retailer base via the single hosted service rather than having to consolidate and manage the information for multiple jurisdictions themselves.
• Some example embodiments include systems and methods for implementing a service architecture using a set of basic platforms and services. A game logic and OLTP engine hosts the instances of “back end game logic”—the equivalent to what is on a current lottery or other wagering game host systems today. The games can be flexibly implemented either as single instance, multi-jurisdictional games (with the appropriate level of jurisdictional segregation of wagers, pools and financials to satisfy regulatory requirements) or as separate game instances per jurisdiction, depending on performance and configuration requirements. A hosted application for configuration and control of the game may provide a software as a service solution to that aspect of the game. The service also provides a content server that allows hosting all of the content assets associated with the various game channels and devices. This content server may provide a centralized publishing and distribution mechanism and may allow associating all of the various assets associated with a game and deploying and controlling them in one place.
• A set of channel devices may also provide a set of content frameworks that allow content to be downloaded to an end user device (or centrally accessed) without needing to change any code in the device itself to support a new game. This applies to both the wager interface and reveal presentation portions of content. The game developer may be shielded from the need to deal with security, reliability, and performance concerns by a set of frameworks and APIs provided in the shared host system. A Game Development Kit (GDK), tools, test environments and documentation may be provided to enable consistent implementation and minimize the testing required to deploy and go live with a game with least risk to the game developer, the game operator, and the game players.
• One example embodiment of the present invention provides a system for providing services to a plurality of lottery operators each associated with one of a plurality of jurisdictions. The example system may include a shared lottery host accessible to a plurality of lottery game terminals in each of the plurality of jurisdictions; a game archive accessible to the shared lottery host storing software code configured to operate a plurality of wagering games selectively activatable by the plurality of lottery operators, the shared lottery host configured to communicate with the plurality of terminals to enable the terminals in a particular jurisdiction to allow the sale of tickets for the games which have been selectively activated by the lottery operator for that jurisdiction; and an activation engine in communication with the shared lottery host, the activation engine configured to receive instructions from a lottery operator from the plurality of lottery operators to activate one of wagering games stored in the game archive. The example system may further include a game operator host in one of the plurality of jurisdictions and a plurality of point of access devices in the one of the plurality of jurisdictions. In addition the example system may further include a local game provided by the game operator host, and a router configured to route communications from the plurality of point of access devices concerning the local game to the game operator host and configured to route communications from the plurality of point of access devices concerning the games provided by the shared host to the shared host. In addition, communications between the shared host and the point of access devices may be routed through the game operator host. In addition, the example system may further include a normalization engine in communication with the shared lottery host and a back office system of a lottery operator in the plurality of lottery operators, the normalization engine configured to convert data communicated between the back office system and the shared lottery host from a legacy format specific to the lottery operator to a shared standard format used by the shared lottery host.
• Another example embodiment of the present invention may provide a system for providing services to a plurality of lottery operators. The example system may include a shared lottery host including at least one computer system, the shared lottery host accessible to a plurality of lottery agent terminals and lottery customer clients in a plurality of jurisdictions; a game archive accessible to the shared lottery host, the game archive storing software code for operating a plurality of wagering games selectively activatable by the plurality of lottery operators; an activation engine accessible to the plurality of lottery operators, the engine configured to allow the plurality of lottery operators to selectively activate the wagering games; a customization engine accessible to the plurality of lottery operators, the customization engine configured to allow the plurality of lottery operators to alter attributes of the wagering games; a network providing connectivity between the plurality of lottery agent terminals and lottery customer clients and the shared lottery host, the lottery customer clients including at least one of a mobile phone, a personal computer, and an interactive television device; a database accessible to the shared lottery host storing wagers placed at the plurality of lottery agent terminals and lottery customer clients; a charging engine configured to receive information regarding wagering game usage by the plurality of lottery operators and to determine charging fees for the lottery operators based at least in part on the received information; a lottery level financials reporting system configured to report sales information to the plurality of lottery operators for their respective activated games; an agent-level financials reporting system, configured to report sales, invoices, and commissions to lottery agents for the games activated in a particular jurisdiction; and a lottery game results reporting system configured to report the outcomes of wagering games to the game operators.
• Another example embodiment of the present invention may provide a procedure for providing services to wagering game operators. The example procedure may include providing a shared host in communication with a plurality of game operators; providing a shared library of wagering games accessible to the shared host, and available for selective activation by the plurality of game operators; receiving a request from a game operator from the plurality of game operators to activate a game; responsive to the request, activating the game for the game operator on the shared host; and charging the game operator based at least in part on the amount of usage that is made of the game by customers of the game operator. The example procedure may further include receiving software modules for a new game from a content developer; storing the software modules in the shared library; receiving a request, at the shared host, from the game operator to activate the new game; responsive to the request, activating the new game, on the shared host, for the game operator; and paying a portion of the revenue received from the game operator for the new game to the content developer. In addition, the content developer may be one of the plurality of game operators. The example procedure may also include distributing software modules from the shared library which are associated with the game to point of access devices operated by the game operator. In addition, the game operator may have a game operator host, and the example procedure may further include passing communications relating to operation of the game between the shared host and a plurality of point of access devices through a game operator host. Additionally, the game operator may have a game operator host providing a second game not provided by the shared host, and the example procedure may further include routing communications, related to the game, from a plurality of point of access devices to the shared host; and routing communications, related to the second game, from the plurality of point of access devices to the game operator host.
• Another example embodiment of the present invention may provide a system including a game repository storing software code for a plurality of wagering games accessible to a plurality of game operators, the wagering games being selectively activatable by the plurality of game operators and having a plurality of tunable parameters; and a game customization engine configured to allow a game operator from the plurality of game operators to select values for the tunable game parameters when a wagering game from the plurality of wagering games is activated by the game operator. The example system may further include a content server configured to distribute the software code for an activated wagering game which has been customized by the game operator to the game operator's point of access devices. In addition, the tunable parameters may include at least one of a wagering game payout percentage, a wagering game name, a wagering game operator name, and a legal notice. In addition, the game customization engine may be further configured with default parameter settings for each game operator from the plurality of game operators which are automatically applied to wagering games activated by that game operator.
• Another example embodiment of the present invention may provide a system including a game repository accessible to a plurality of wagering game operators, the game repository configured to allow the wagering game operators to select games from the game repository to offer to their respective customers; a game repository deposit system configured to allow the entry of new games in the game repository; a game adoption system configured to allow the wagering game operators to adopt the games in the game repository; and an accounting system configured to determine the amount charged to the game operators based at least in part on adoption of the games in the game repository by the game operators. In addition, the accounting system may be further configured to determine an amount due to content developers for games deposited in the game repository based at least in part on adoption of the game by the game operators. In addition, the amount charged to the game operators for a particular game is based at least in part on an amount of usage made by the game operator's player customers of the particular game.
• Another example embodiment of the present invention may provide a system including a game repository accessible to a plurality of lottery game operators, the game repository configured to allow the lottery game operators to select lottery games from the game repository to offer to their respective customers; a game repository deposit system configured to allow the entry of new games in the game repository by content developers; a game adoption system configured to allow the lottery game operators to adopt the games in the game repository; and an accounting system configured to determine an amount due to game depositors, for games deposited in the game repository, based at least in part on an amount of use made of the games by the lottery game operators' player customers for games the lottery game operators have adopted from the games in the game repository, the accounting system further configured to determine an amount due to content developers, for the games deposited in the game repository, based at least in part on adoption, by the lottery game operators, of the games deposited in the game repository, and further configured to determine an amount charged to the lottery game operators for a particular game, based at least in part on an amount of usage made by the lottery game operators' player customers of the particular game.
• Another example embodiment of the present invention may provide a procedure for providing wagering games to wagering game operators including receiving deposits in a game repository from game depositors of game software modules for a plurality of games; providing the wagering game operators access to the game software modules in the game repository; collecting fees from the game operators based on their player customers' use of the games in the game repository and recording the fees in an accounting system; and issuing a payment to the game depositors, using the accounting system, based on a pre-arranged portion of the fees from the game operators for the use of games deposited by the game depositors. In addition, the fees collected from the game operators may be based on at least one of a number of times a game is played, the number of players who play the game, an amount of revenue received by a game operator, and an amount of profit earned by the game operator for the game.
• Another example embodiment of the present invention may provide a player customer relationship management system for a plurality of wagering game operators including a customer relationship management server, configured to communicated with a plurality of wagering game operator servers, each associated with a wagering game operator from the plurality of wagering game operators, where the customer relationship management server is configured to receive from each of the wagering game operator servers information regarding player customers collected by the wagering game operator servers; and the customer relationship management server is configured to aggregate the information into a common wageror database containing information received from each of the wagering game operator servers. The example system may further include a plurality of games from third party content providers selectively accessible by the plurality of wagering game operators; and an interface configured to provide information to a third party content provider associated with a game from the plurality of games regarding player customers associated with at least two of the wagering game operators who have played the game. In addition, the interface may be configured to provide aggregated information to the third party content provider while preventing access to information related to individual player customers. In addition, the information regarding player customers in the common wageror database may not identify individual player customers. In addition, the wagering game operators may be governmental lotteries in different respective jurisdictions operating independently of each other. In addition, the player customers may be permitted to access information related to themselves in the common wageror database. In addition, the information related to a player customer may include a player account with a monetary balance that can be accessed to play games provided by the plurality of wagering game operators.
• Another example embodiment of the present invention may provide a retailer management system for wagering games including a plurality of wagering games offered by a plurality of wagering game operators through a plurality of retailers which are associated with a retailer organization; and a host in communication with the plurality of wagering game operators and the plurality of retailers, the host configured to receive information regarding wager sales made by the plurality of retailers for the plurality of wagering games and to report aggregated sales data for the plurality of wagering games made at the plurality of retailers to the retailer organization. In addition, the wagering games may be provided from the host to the plurality of wagering game operators, at least a subset of the wagering games are operated by more than one of the wagering game operators, and the host is configured to aggregate the sales data for the retailers of the retailer organization from multiple wagering game operators. In addition, a plurality of pluralities of retailers may be operated by a respective plurality of retailer organizations, and where the host may be configured to report aggregated sales data for the plurality of wagering games to each retailer organization for their respective retailers. In addition, the wagering games used by multiple wagering game operators may be customized by each wagering game operator. In addition, software code for operating the wagering games by the plurality of wagering game operators may be provided on the host. In addition, the host may be a single centralized computer system.
• Another example embodiment of the present invention may provide an article of manufacture comprising a computer-readable medium having stored thereon a series of instructions executable by a processor, the instructions configured to cause the performance of any of the example procedures described herein.
Access to the Shared Host System
• Some example embodiments of the present invention provide a flexible, evolutionary approach to accessing the hosted games. In lottery systems, where each game operator has their own independent system and local games, the legacy system may be transitioned to using the shared host system described herein, using the example pass-thru system using a first example embodiment, described below in reference toFIG. 2. The legacy host system may act as an acquirer for transactions from all of its channels and devices and pass the transaction to the shared game host for processing. The local legacy host may be responsible for retailer and terminal accounting. A one time change may be needed to each of the channels and devices in the jurisdiction to incorporate the content frameworks, also described below for the game content available from the shared host system. In a second alternative embodiment, described below in reference toFIG. 3, a transaction router may be provided in front of the existing legacy host system which may be configured to route the existing transactions to the current legacy host and route transactions related to games provided by the shared host to the shared host service. A hosted acquirer service is used in this model to do the point of access accounting for shared host games. Combined accounting for the existing legacy services and shared host may be done by the existing legacy host accounting system, e.g., by providing a feed from shared host. Alternatively, accounting may be kept completely independent for the local games and the COD games.
• Multiple approaches may be provided to accommodate the back office application game touch points in the legacy game operator's systems and jurisdictions. One approach is to treat shared host games as a single game category for reporting and financials in a manner similar to what is now done with instant ticket games, where there are a very large number of similar games that are handled in the same fashion. Information for individual shared host games may be made available as a data feed from the shared host service; to allow local lottery applications to do game specific analysis and reporting. For other back office applications including retailer management, player services applications and promotions, a content framework that allows shared games to be included in the back office applications may be provided by creating data driven interfaces in the local applications that utilize configuration information from the shared host service to dynamically configure shared game interfaces or utilization of shared hosted services that provide the needed functionality for shared host games.
• When all games are implemented in the shared host service, e.g., after a migration period, the legacy host system may no longer be needed and may be replaced by a transaction acquirer illustrated inFIG. 5. The acquirer may be configured to manage the channel or channels it controls (e.g., retailer, internet, etc.) and to handle the accounting and financial reconciliation for this channel. It will be appreciated that acquirer could be in a position in the game operator's system or jurisdiction, or alternatively could be provided as another hosted service provided by the shared host.
• In some example embodiments, back office applications may be provided using a software as a service model by the shared host. This approach may permit an unbundled model of procurement for back office applications which are permanently purchased and supported by a third party and/or integrated with the shared host services where needed. This may permit the local game operators to deploy only the channel devices and their supporting communication, while all remaining functions are handled by the shared host service.
• From a player customer perspective, access to the games or other player services provided by the shared host may be obtained in multiple ways. For example, player customers may be provided a central account and electronic wallet that is usable across all of the game operators. This account may be accessed directly from the shared host service on the Internet, via a retailer, or via one of the various player access channels provided by any of the game operators providing services using the shared host. Direct access by the player customer to the shared host services (such as a game operator or jurisdiction specific player account) may also be provided directly from the shared host service or through any of the game operator specific services provided by the shared host.
• Although games and game content from the shared host may be used by multiple game operators, game customization may also be provided, e.g., with a customization interface and engine that is accessible to the game operators when shared games are activated. This may allow the game operators to provide unique attributes to games and branding in the content that makes their version distinct and hopefully most desirable to their player base, but without having to redevelop the game code and content for each game operator or jurisdiction as is the case today. Localization and branding capabilities may be provided in the various games, e.g., using standard tools or re-usable objects that may be included in the different games. Each participating game operator may then configure the aspects of the games provided through the shared host that content developers have made available. The game operators can also develop and publish their lottery branding components (e.g., the game operator name, slogans, logos, legal disclaimers, etc.) as discussed below. These game operator specific components may be combined with the common shared content published by the content developers to create a unique game experience for each game operator.
• Some example embodiments also provide features which allow games provided by the shared central server, operated by a first service provider, to be provided via a proprietary host system, e.g., a lottery operated under contract by another service provider. Within the current lottery industry, it is difficult or impossible for games from one vendor to be accessed via another vendor's system. Instead, each vendor develops their own version of any common games. However, in the example embodiments, by the addition of a pass-through engine or other add-on feature, content from the shared host may be provided through the proprietary legacy host system of another vendor. Also, multi-jurisdiction games can be provided more efficiently from a single shared host.
Example System Architectures
• Example embodiments of the present invention, some of which are described below, can be used to support regulated state or governmental lotteries, private gaming corporations, both physical and Internet casinos, or other entities that provide legal gaming to customers. While the examples are described principally with reference to regulated state lotteries, it will be appreciated that the same solutions may be applied in other wagering or regulated gaming applications. The example embodiments described below include references to host systems. Host systems may be implemented as a single computing system or as a collection of computing systems which are communicatively coupled. Thus, each component of the exemplary shared hosts may be implemented in hardware, software, or a combination thereof.FIG. 2 illustrates an example System A, according to an example embodiment of the present invention. In this example, new games and channel content are provided for existing game operator systems with their own legacy central hosts. On the left side of the illustration, thebox200 represents the central shared host. The shared host may be provided on a single large mainframe computer system or in a distributed fashion with a collection of smaller computer systems, e.g., connected by a high speed local area network. The shared host may provide game services to multiple game operators, shown on the right side of the illustration as Jurisdictions A220,B230, andC240. Each of the jurisdictions may access games located in the sharedhost200. Each jurisdiction may also host its own games via legacy central hosts, for example221. Thus, the various game operators, e.g. in Jurisdictions A220 andB230, may be provided access to shared games in addition to legacy games, while other game operators, e.g., theJurisdiction C240, may access only shared games.
• The sharedhost200 may include a configuration andcontrol system201. Thissystem201 may handle management and reporting functions, e.g., the distribution of real time, daily, or monthly accounting reports of various types, the control of system configurations, and monitoring and service level agreement metric monitoring and control, e.g., performance management, availability management, etc.
• The sharedhost200 may include an onlinetransaction processing system202. TheOLTP system202 may be configured to process wagers, e.g., lottery ticket purchases or game entries in a large variety of games. In particular, the game transactions may include purchases for entries in future draw games, or “online” or “instant” games where the outcome of the game is also determined as part of the initial transaction, as well as other variations and combinations of game logic.
• TheOLTP system202 may include abasic OLTP Platform203 which the games are based around. Although the implementations of theOLTP Platform203 may vary among different shared hosts, eachOLTP platform203 generally includes a set of specifications to which each game must conform. For instance, the games may be programmed for a specific operating system (OS) environment or programmed using a specific language (e.g., C, C++, JAVA, etc.). This provides a standard to which developers may need to comply with when developing new games.
• TheOLTP platform203 may interface with agame services component204. Thegame services component204 may provide a uniform set of services which may be accessed bygames206,206 and207 located in theOLTP system202. For example, a basic service may include wager processing. Other services may include a validation service to verify winning wagers, a randomization service to provide a uniform method of generating random numbers requested by a game, a player registration service to identify users and manage user profiles, and a reporting service to report the results of a gaming transaction to the user or the operator. In addition to generic services that are accessible to each game, theOLTP platform203 may include specific services tailored to the requirements of a particular game.
• It is noted that the games may be stored in a data archive orrepository1800, such as that illustrated inFIG. 18, or in some other fashion.FIG. 18 illustrates a number ofgames1802 stored in agame storage1801.Games1802 may include software code and libraries, presentation information, configuration information, and other information necessary for presentation and use of a game. Thegame archive1800 may provide asecurity system1803 that may control access to the games. In addition, thegame archive1800 may provide an interface through which the games may be accessed1804 and a module to facilitate the deposit of new games into thearchive1805, or the update of existing games. Thegame archive1800 may also provide an interfaces to various other systems, including forexample reporting systems1806.
• An additional game service that may be provided by thegame services component204 is a storage service for maintaining records of games. Operators may opt to keep a record of winning numbers, names and contact information of winning users. Storage may also be provided for games that have not yet ended. For example, users may place wagers on a game which has a drawing time in the near future. The storage service may keep a record of the users' identities (e.g., through player registration, self-provided contact information, credit card information, etc.). Other game parameters, such as user-selected numbers and wager amounts may also be stored. If a game requires multiple user interactions over time (e.g., video poker), the storage service may dynamically update stored records in accordance with changes made by such interactions.
• The game services may in turn interface with a variety of game transaction logic components, e.g., software codes stored on the sharedhost200. These game transaction logic components may include game-specific components associated with each game in addition to generic logic components, each of which may be configured to perform transactions for particular games. The logic components may be codified in the form of executable math and business rules which may be executed by the game services. Results of the execution are then provided to games that request a service associated with these rules.
• TheOLTP system202 may provide financial accounting services for account reconciliation between an owner of the shared host and the game operators. As will be discussed further below, the owner and the game operators may establish a revenue sharing arrangement based on a licensing scheme or a usage-based agreement.
• Also provided in the sharedhost200 may be acontent server208 which may deliver channel content between the sharedhost200 and the operators. Thecontent server208 may include achannel configuration engine209, which may be constructed to enable the operators of the shared host to create configuration data relating to individual game operators. The configuration data may, for example, include game operator-requested game customizations, such as a format in which in-game graphics are displayed to player customer users (e.g., specific fonts, graphics menus, operator-specific logos and messages, and other graphics elements). Thecontent server208 may also include achannel content engine210, which may include a database of channel content corresponding to the configuration data. Accordingly, the channel content may include logos, font libraries, billing records, usage records (e.g., the number of times each game was requested by a user or an amount of bandwidth used by a game operator during current and past billing cycles).
• Although each game operator may have systems with different architectures, a typical example architecture is shown inJurisdiction A220. The jurisdictional computer systems of the game operator may be connected to the shared host via a network, for example a secure internet, virtual private network, high speed satellite network, or dedicated lines.
• In the example embodiment illustrated inFIG. 2, the game operator's own legacy host system continues to operate in parallel with the shared host, providing legacy games and legacy content in the game operator's jurisdiction. For example,lottery host221 may have software enabling the operation of existinggames222 in a conventional fashion. The conventional lottery host may be modified with apassthru engine223, which may be configured to allow game content from the sharedhost200 to be distributed to channel devices and/or player customers through the existinggame operator host221 over the existing legacy game operator network. Thepassthru engine223 may be configured to provide interfaces and conversion that allows the standard transactions and communications from the sharedhost200 to be processed by the existing game operator's systems.
• Thepassthru engine223 is configured to operate as a transaction acquirer which serves as an intermediary between the sharedhost200 and the channel users. Transaction requests are received at thepassthru engine223, which determines whether the requested transaction corresponds to a legacy game or a shared game. Transactions are then processed accordingly. Thus, requests for legacy games are handled locally within the game operator'shost221, whereas requests for shared games are forwarded to the sharedhost200.
• The game operator'shost221 may be connected to conventional retailers, e.g., lottery agent terminals and/or dedicated self-service lottery terminals located at a point of acquisition (POA)224, via a secure network. The game operator'shost221 may also be connected via a network, e.g., the Internet, directly to a game player's client device such as apersonal computer225, amobile phone226, and aninteractive television terminal227.
• In addition to thegame operator host221, the game operator may also have a management system for back office applications such as reporting and accounting, which may be connected via a network connection to the configuration andcontrol system201 in the sharedhost200. The back office system may includevarious applications228 and229, e.g., report generators for generating and distributing retailer reports, overall financial reports, reports on individual games, or segmented marketing data on customers and customer behavior. These back office applications may access the OLTP system's financial and accounting services to coordinate revenue sharing and billing. Alternatively, the example embodiment described above may make use of existing legacy system features for transaction acquisition, accounting, channel management. For example, theOLTP system202 may include an agent-level financial reporting system configured to report sales, invoices, and commissions to lottery agents for the games activated in a particular jurisdiction, whereas the back office applications may be configured to report sales information, at the lottery level, to the lottery operators for their respective activated games.
• Such reporting systems may be provided for in the form of reporting modules such as the example depicted inFIG. 19.FIG. 19 illustrates anexample reporting module1900 including a data archive for storingfinancial data1901. The financial module also may provide adata aggregator1903 to facilitate the gathering of data across multiple sources and systems. For example, the reporting systems may be able to aggregate sales data across an entire game, which may be operated by more than one operator. The reporting module may also include aninterface1904 allowingreport users1907 to select and generate reports. The reports could be created using aquery mechanism1902, which may be configured to allow for the use of standard queries as well as custom created queries. In addition, the reporting systems may includescheduler systems1905 which may be configured to provide specific reports at pre-selected times, or time intervals.
• In the example system, and in the other example systems described below, games may have at least three components: (1) the game logic, which may include a set of game rules and mathematics that control the execution of the wagering on the game and determination of game outcome (winners and payouts), (2) game play presentation, which depending on the channel type may be either player facing or retailer facing, but in either case involves a user interface to gather (and in some cases distribute) the information related to wagering on the game, (3) results reveal presentation, which is the part of the game that delivers the information about game results to the player. Each of these elements may have technical implementation components which together make up the overall technical implementation of a game.
• The game logic (math and business rules) may be implemented almost entirely on the host (OLTP) system. This system provides a set of fundamental services for processing online transactions (independent of the games), a set of non-game-related functions like financial accounting for transactions and a set of generic gaming services or functions used by many or all games. The games themselves are then built on top of this platform and set of services.
• The presentation aspect of the wagering on lottery and other games may be provided within the devices that support each of the sales channels. The primary current channel for lotteries is a lottery retailer or sales agent. In this case, the lottery terminal in the retailer location provides the presentation interface. This interface may be adapted to facilitate the retailer or agents placing wagers (and cashing winners) on behalf of the player. The inputs, e.g., player choice of type of bet and numbers to bet in a future draw lottery game, may include bet slips, manual entry of player selections by the retailer or quick picks (random selections by the terminal or host system) via retailer input. In some cases, player cards or other devices can be used by players as a part of the process to place favorite bets or communicate other input information. The results of the wagers and other game transactions may generally be communicated to the player via printed receipts that include all of the relevant information about the wager.
• In other player facing channels, e.g., self service terminals, Internet, iTV, mobile phones, etc., a different transaction procedure may be provided. While the same information about the wager is being gathered as described above in relation to the agent-operated process, e.g., game type selected, the particular instance of the game, such as a drawing time, player number selections or other choices, amount wagered, etc., the information may come directly from the player, or some application controlled by the player, such as an intelligent agent, rather than secondhand through the retailer. It will be appreciated that an intuitive and efficient interface for entry of data by a retailer is likely not the same as for an individual player. Further, the physical display and input capabilities of each type of device varies and may dictate not only a different set of visual properties but possibly a different overall flow for the interaction. Entering information on a self service terminal, a web browser and a cell phone are generally not the same. From the development perspective, it is also likely that an identical presentation and flow on two devices of a particular type (e.g., different models of retailer terminal) will use different sets of code and graphical assets due to the technology differences of the devices.
• Once a wager has been placed and a game outcome determined, the results may be revealed to the player in a variety of approaches, depending on the particular game and on the channel employed. Reveal aspects of games may be provided using similar procedures to wager presentation—with some additional features. Because the reveal is where the most “entertaining content” is often included as a part of the game, challenges may be faced in creating code and assets that can be used across different game channels and devices. This content may include complicated graphics and animation, e.g., as described in U.S. patent application Ser. No. 11/140,403 to Carney et al., entitled RACING GAME AND METHOD. In some embodiments, a complete secondary reveal game playing experience may be provided, as described in U.S. Patent Application Publication No. 2004/0229677 to Gray et al., entitled GAMING SYSTEM AND METHOD, where the reveal may include complicated logic and even additional input from the player which the reveal game reacts to or takes into account in order to enable the player to play the secondary game. This type of content may be made more portable by development within environments like Adobe Flash, which is available for multiple channels and devices. However, many of the legacy devices that are now in the field between the retailer and player based channels for various game operators, do not support such environments, however, so separate assets and implementations may be needed for each of these legacy devices.
• In the example systems herein, as well as some other example embodiments, a control and management system including a control and management interface may be provided. The interface may provide the operator of the shared host system, as well as the game operator management with a user interface to configure the various games, monitor game information and enter control information such as winning numbers, enter management information, and adjust policies and parameters. While this may be a simple interface for many traditional lottery games, it may be much more complicated in cases such as sports games that require entry of teams, odds and other such information. In the most complicated cases with sports betting, complete applications and management systems may be provided for setting odds, risk management, and other related functions.
• Other features that may be provided in the example embodiments described herein are not parts of the game implementation found on the shared host, but are rather all of the other applications in the overall example systems that games interact with that are not directly involved in game play, referred to for convenience in the present application as “game touch points”. For example, the applications may include most or all of the back office applications, such as financial and accounting reporting, fraud detection, retailer management, fault management, maintenance, etc.
• For example, data warehouses and reports that include game information are affected by each new game in the system. In some cases, these may be provided by simply collecting and reporting on the same common attributes for each game (e.g., total sales). In other cases, updating data warehouses and reports may involve collecting and reporting on a specific set of attributes related to the type of game (e.g., wager counts and amounts by bet type). In some cases, there is specific programming work that may need to be done to existing reports when games are added (or removed) in the system. Similarly, a retailer management application manages retailer and terminal related privileges for games and these privileges can potentially vary from game to game.
• Claims and payment applications also may need to have information about games in order to allow cashing of game tickets or other sorts of redemption of wager prizes.
• Promotions applications may need intimate knowledge of games and game configuration in order to allow promotion definition. For example, in a Buy X Get Y type promotion, all of the parameters of game X that trigger the promotion must be configurable along with the parameters that control the attributes of the game Y promotion result. This means that user interfaces which are specific to the game may be needed, along with methods of communicating with the games that are involved.
• Player card applications that involve features like recording a player customer's favorite numbers may need information about all the games and the configurations for those features that the player cards support.
• Subscription applications may need all the information and user interface components to allow entering subscriptions for each eligible game. This may include all of the same type of information necessary to place a wager in a retailer or player channel, but may introduce new requirements for input method and flow when accessed by a back office user or via some batch interface.
• FIG. 3 illustrates an alternative example System B, according to an example embodiment of the present invention.
• Example System B may provide features similar to those of System A. For example, users in different jurisdictions may access shared and legacy games through a variety of retailer and player channels. Similar to System A, System B may handle requests for legacy games locally within each jurisdiction rather than at a shared host.
• In example System B, anAcquirer Service engine301 may be provided as part of a sharedhost300, between theservice interface engine211′ and alegacy lottery host322. TheAcquirer Service engine301 may be configured to communicate with a plurality of Jurisdictions A320,B330 andC340, each of which may include a legacy host.
• Also, separate from thelegacy host322, arouter321 may be provided specifically for handling transactions from customers and agent terminals that involve games provided on the sharedhost300. These transactions may be handled without passing directly through thelegacy lottery host322 on the way to the sharedhost300. Therouter321 may receive transaction requests and forward the requests to either the sharedhost300 or thelegacy host322 depending on whether the request is for a shared game or a legacy game. Requests for legacy games may be handled by searching for an appropriate game within a list of existinggames222′. In this manner, game transactions may be routed to create greater separation from a retailer's perspective.
• Accounting in example System B may be performed through a reconciliation of financial and accounting information located in both the sharedhost300 and thelegacy host322. The sharedhost300 may keep records relating to usage of shared games while anaccounting engine323 in thelegacy host322 may track usage of legacy games. Channel management may be performed by local applications and sent to theAcquirer Service engine301 for reconciliation.
Channel Content Management
• In the example systems described above, new games and channel content associated with those games are provided for existing lottery systems. The shared host provides hosted services including the OLTP platform and common game services, individual game instances for the OLTP engine, configuration and control for game environments, in addition to a content server that distributes hosted channel content. Each of the services may be accessed through the Service interface engine, thereby enabling lottery systems in each jurisdiction to retain existing legacy host systems and any legacy content (e.g., legacy games) contained therein. Both example System A and example System B may be suitable for use in situations involving a variety of users such as retailers who wish to carry out the remainder of the contracts for legacy games and services, game operators who wish to keep existing products, but want to add shared access to those products, start-up game operators who may now quickly launch a new operation by accessing shared content, and existing retailers who are not under a contract but want access to shared content.
• FIG. 4 illustrates an alternative example System C, according to an example embodiment of the present invention. The example System C may provide features similar to those of System A. For example, users in different jurisdictions may access shared and legacy games through a variety of retailer and player channels. System C may handle requests for both shared and legacy games at a sharedhost400 rather than separating handling duties between a shared host and a legacy host. Thus, game transactions may be handled at the sharedhost400 rather than locally. Such a system may be beneficial to existing game operators who have entered into a contract with the operator of the shared host and wish to retain existing local back office and other support applications by renewing their contracts rather than entering a new contract for access to shared (and possibly customized) applications.
• In the example System C, alocal acquirer engine421 may be provided within each of several Jurisdictions A420,B430 andC440. Thelocal acquirer421 may be configured to manage all of the channels (both player and retailer) and to forward gaming transactions to a sharedhost400. The local acquirer service may also include alocal service interface422 which may be configured to request gaming services from the sharedhost400. When a transaction request is received, thelocal acquirer421 may automatically forward the request to the sharedhost400, which may then fulfill the request by, for example, distributing a requested game along with any associated services back to thelocal acquirer421.
• It may be that no handling of legacy gaming transactions occurs on the jurisdiction side of system C. Optionally, each jurisdiction may include one or moreback office applications228″ and229″. In addition, accounting may be performed substantially remotely at the sharedhost400. Management users423 at each jurisdiction may receive accounting information by communicating with the sharedhost400 through an accounting back office application. In addition to back office applications, transaction acquisition applications such as the management of access channels and devices may also be located locally. In some embodiments, similar applications may be provided at the sharedhost400, allowing the management users to choose between the local applications and the hosted applications.
• The sharedhost400 may also include a hostedservices engine401 which may provide hosted services for player, retailer and back office applications. For example, an accounting back office application may request an accounting service provided by the hostedservices engine401. Other hosted services may, for example, include player registration services, game activation services and management services.
• FIG. 5 illustrates an alternative example System D, according to an example embodiment of the present invention. In example System D, gaming transactions may be handled entirely at a sharedhost500. Communication between the sharedhost500 and each channel may be direct in that transactions may not have to be acquired before being forwarded to the sharedhost500. The example systems may provide access to a large library of shared content. Furthermore, host services may be selectively packaged to provide a turnkey game operation package. This may be particular beneficial to small game operators, or game operators who want minimal local hosting, backup or data storage, or game operators implementing services for the first time.
• In example System D, player and retailer transaction requests are received at acommunications service engine501 located at the sharedhost500. Thecommunications service engine501 may provide a set of communication protocols along with a corresponding communications arrangement for interfacing with the channel devices. Thecommunications service engine501 may extract the requests from the communications and pass the requests to anacquirer service engine502.
• In System D, theacquirer service engine502 directs the transactions to an appropriate component of the sharedhost500 for processing. For example, a gaming transaction may be directed to theOLTP202 while a back office transaction may be directed to a hostedservices engine503. Thus, no local transaction processing may occur. Legacy games and existing supporting applications under System D may be required to undergo development or customizations before they can be eliminated locally and transferred to the sharedhost500. However, once this software is developed, retailers may access it without any perceived difference between the features of the new and legacy software.
• The hostedservices engine503 may provide all of the retailer, player and back office applications required by each of the jurisdictions. Initially, the hostedservices engine503 may only include a set of generic services that are generally applicable to any retailer and/or player. However, retailers may, over time, request additional or customized services. These additional services may include commercially available software applications or customized software tailored to the individual needs of the retailer.
• FIG. 6 illustrates an alternative example System E, where a sharedhost600 has direct access to players and retailers, according to an example embodiment of the present invention. In example System E, transactions can be conducted directly between the sharedhost600 and players/retailers650. Additionally, the sharedhost500 enables access across channels other than traditional online lottery channels. These additional channels may include access to other gaming systems such as avideo lottery system630 and acasino system640. Access to further venues may also be possible in other embodiments.
• The sharedhost600 may include components similar to those of the sharedhost500, including acommunication service engine501 which may facilitate communications with lottery operators located indifferent jurisdictions620, and anacquirer service engine502, which may be configured to direct transaction requests to an appropriate shared host component. In the example, System E dataflow is indicated with dashed lines to show that the sharedhost600 allows multiple access paths depending on the particular channel being accessed.
• Aservice interface602 may provide direct access to games located in theOLTP202 by communicating with avideo host631 or acasino server641. Games and game services may be delivered from thevideo host631 and thecasino server641 to a channel device such as avideo lottery terminal632 or aslot machine642. Additionally, theservice602 interface may be configured to deliver channel content directly to the channel devices.
• The shared host may also include a direct retailer andplayer services engine601 which may be configured to provide direct service to players/retailers650. Direct service may occur over the Internet or any other communications network to which a player or retailer's device (e.g., a cell phone or a personal computer) has access. The sharedhost600 may be coupled to the hostedservices engine503, enabling direct access to such services as accounting, player registration and game subscription.
Gaming Asset Framework
• In legacy lottery and other gaming systems, game logic is typically spread out across many major software components, including: Point of Access (POA), Retailer Management, Retailer Accounting, Internal Control System (ICS), a Transaction Engine, Game Control (GC), and Reporting. When a new game is added, these components may each need to be modified to support it. This is generally a time consuming and expensive process.
• In addition to the software effort, a major quality assurance and testing effort may also be required with the introduction of a new game. Not only does the new game need to be tested, but significant regression testing is frequently required. This is the result of software changes made to shared logic, which can potentially affect the operation of existing games. In addition to the increased quality assurance costs, a new game's affect on existing software increases the overall risk associated with deploying a new game. In some example embodiments, content frameworks may be used to produce one set of code and assets (graphics, etc.) for game content to be used across all supported channels and devices, and for multiple game operators. Game content may be packaged using a custom or standard electronic file type, e.g., Adobe Flash, which provides “containers” for running content and user interface applications on many types of devices. Other methods of content display including printing, and various other ways of displaying information to customers, may also be provided in the standard interface. Thus, content can be downloaded to any of the various channel devices in the system and displayed to a player customer or other person.
• FIG. 7 illustrates an example game framework, according to an example embodiment of the present invention. In some example embodiments, game frameworks may be used in all parts of the example gaming and lottery systems, both as a framework for content, and also for other game elements such as game logic and/or back office processes. Anasset manager701 may store various game assets forvarious games702, which may include various software libraries, e.g., A, B, and C forgame1 and D, E, and F forgame2. These assets may be distributed to various game operators or lottery jurisdictions for use in facilitating the integration of various components of the game operator's systems with the shared hosting and shared asset system. In particular, various components in the game operator's legacy system, such as point of access terminals or interfaces710, orgame control engines720 in the local host may be provided withabstraction layers711 and721, which may allow these components to use the various assets provided from the sharedasset manager701. The abstraction layers711 and721 may provide a standard API and conversion between a standard shared asset or library from the asset and the device or software component interface on the component, such as the point of access or game control module. When an asset is needed at a component, the appropriate library or libraries from the asset may be loaded onto the component and interpreted via the abstraction layer. For example, in the illustration, one point of access has been given access to libraries A, B, C, and E, which may include executable codes, graphical or video data, or other digital information needed by the point of access to support the games which the point of access has been configured to provide to customers. For example the point ofaccess710 may be enabled for bothgames1 and2, while the point access injurisdiction2 might only be enabled forgame2, and accordingly the assets forgame1, A, B, and C, have not been made available to the point of access injurisdiction2.
• A game may be implemented using many types of assets: user interface components, ticket formats, business logic, security components, etc. Each asset may be deployed in a particular software component that is responsible for the asset's use. The asset manager (AM)701 may host the various assets that compose an individual game. TheAM701 serves as the warehouse for the assets of all the games of the gaming framework. Theasset manager701 may also be configured to deploy the game assets to the appropriate software components when a game is activated.
• The use of game frameworks may facilitate new games being added to the shared system without changing the implementation of a particular component. For example, game frameworks may be provided for reporting and back office applications, to allow the back office applications to integrate with the shared game server. They are particularly suitable for use in example systems A and B, discussed previously, where legacy systems run in parallel with a shared host system. In such cases, components of existing legacy systems may provide some game elements for new games.
• The content framework in the channel devices may communicate with the shared central service via the shared central server service interface. A description of the detail of this interaction is provided in the more detailed example discussed below. The aspects of developing and publishing the shared game and content are also illustrated in more detail below.
• FIG. 8 illustrates an example System F which includes content frameworks, according to an example embodiment of the present invention. Example System F enables the use of shared content through a content framework, which may be integrated into player/retailer channel devices. A content framework may exist for each type of channel and device to support the type of content and user interaction model (e.g., legacy). The content framework may operate alongside existing non-shared games and functions. The content framework may also operate as the sole interface through which a channel device accesses shared games. System F may be provided using any of the previously described shared content systems. Generally, a content framework may include software code supporting any required content and user interaction. For example, a player device may require a game play input interface, a game results reveal code module or other content output modules. A content framework of each device may be tailored to support that particular device's specific output requirements (e.g., a display format). The content framework may also include any device-specific interfaces necessary for communication with other channel devices (e.g., printers, scanners, etc.).
• As shown inFIG. 8, a sharedhost800 may include acontent server801 which may interact with the content framework of a channel device (e.g., achannel device840 and a content display device830) to deliver channel and other device-specific content in addition to channel configuration information (e.g., game parameters, message formats, etc.). A game interface of any shared game will generally include the content framework, the game content, and the channel configuration information. The interaction between thecontent server801 and the channel devices may occur through theservice interface211 of the sharedhost800.
• Thechannel device840 may operate on its own platform andOS841 on whichgame content831 may be built. Thegame content831 delivered may co-exist alongside existinggame content843 and along with non-game functions844 (e.g., device utilities, player registration code, user interface code, etc.).
• Content may be delivered to the channel devices in any number of ways depending on particular implementation, including through aPassthru engine821 of alottery host820, or a local acquirer and an acquirer service engine located on the shared host800 (not shown).
• FIG. 9 illustrates another example of a gaming system including an example subsystem facilitating the interaction ofcontent developers950 with a sharedhost system900, according to an example embodiment of the present invention. Example System G may include a content developer model consistent with the shared content systems previously discussed. Shared content may be developed byindividual developers950, software publishing companies or retailers (e.g., alottery930 or other game operator). Generally, the process of developing new content takes place in a controlled development environment where the developer can test and debug the content or demonstrate game concepts to potential customers or focus groups before deploying it to a sharedhost900. In order to comply with the specifications of the sharedhost900, thedevelopers950 may be provided with a Game Development Kit (GDK)942. TheGDK942 may include software tools to aid the developer in writing, testing and debugging the new content. The new content may be published to alocal content repository941. Once published, the content may be assembled in a test or demo environment, which may include other related content such as, for example, software libraries, input files and other data required for testing purposes. After the new content is deployed, game operators or individual retailers may then subscribe to access the content based on a licensing agreement. Access may be configured to the needs of the subscriber and the content may be activated and ready for delivery to authorized channel devices.
• It should be noted that in example System G, content does not have to be developed from scratch. For example, a lottery may only be interested in customizing an existing shared game rather than creating a new one. Thus, a lottery branding andlocalization department931 of alottery930 may modify the existing game by adding custom graphics, logics, messages, etc. After the new content is finalized, the content may be deployed by uploading to aContent Server901, which may then distribute the content to a requesting channel device (e.g., a Channel Device920).
Gaming Software as a Service
• Software as a service (SaaS) is a software application delivery model whereby a software vendor develops a web-native software application and hosts and operates (either independently or through a third-party) the application for use by its customers over the Internet. Customers access the software via a web-based API such as Web Services or REST (representational state transfer). SaaS provides a low-cost alternative for businesses to obtain the same benefits of commercially licensed, internally operated, on-premise software. SaaS is attractive to users because it may provide a quicker deployment model, minimize up-front investment, and lower risk for exploration of new business markets.
• Some example embodiments of the present invention extend SaaS concepts to use in wagering game deployment and operation, e.g., providing wagering games as a service, providing interactive events on demand, providing a universal player service across multiple game operators, providing a universal retailer management service across multiple game operators, providing a central randomization service over multiple game operators, providing a winning number validation and result information service across multiple game operators, and providing a standard security service across multiple game operators.
Wagering Games Service
• Some example embodiments of the present invention may provide secure network-based wagering game applications, e.g., lottery games deployed and accessed by one or more game operators, e.g., governmental lotteries, as shared hosted (off-premise) services. Games implemented and deployed on a shared hosted service architecture and associated shared content frameworks may be accessed by one or more game operators, e.g., lottery jurisdictions, that subscribe to the service. Subscriptions may be fixed price, per game, or based on amount or dollar volume of usage, or a blend of these or other pricing approaches. Game operators may access the shared services via shared service-enabled components within existing infrastructure or via dedicated shared service components deployed both directly in point-of-sale and in interactive environments.
• The shared service architecture and associated content frameworks described in the present application may also support the authoring of shared service games and content by third party developers and content producers. These developers may use a game development kit (GDK) which may include shared game and content frameworks, APIs, and game developer tools to author shared content for traditional retail point-of-sale and interactive channels such as iPC, iMobile, and iTV.
• In the shared game service, game logic may be separated from the entertainment experience presented directly to player customers. This separation may enable developers to author appropriate entertainment presentation content for target access devices while leveraging the same game and business logic code across different channels. Games may be implemented as single jurisdictional, multi-jurisdictional (e.g., where players in multiple jurisdictions compete for the same prize), with shared services and content, and with shared or separate data storage.
• The example architectures described herein may allow game operators to share content, services, and gaming infrastructure. The example architectures may support running multiple versions of the same service for backwards compatibility and version update purposes. The example architectures may also provide the ability to logically and physically separate code and data in the context of multi-tenancy architecture.
• In addition to traditional retail point-of-sale device access channels, multi-channel access to shared content and services supporting interactive channels such as iPC, iMobile, and iTV may be provided. The example architectures may also include a development and delivery platform supporting third party game and content developers.
• The example architectures may also include a new subscription-based business model for the lottery and gaming industry whereby wagering game operators may subscribe on a per seat periodic basis or pay-as-you-go metered usage model basis for the use of the shared game content.
Interactive Events on Demand Service
• The example architectures described herein may also provide interactive events as a service available to the game operators. The example architectures may enable interactive wagering (e.g., lottery and sports betting) at live sporting events in locations where such wagers are permitted. The example systems may enable retailer access devices to be deployed at live events for the purpose of taking player lottery and/or event-based bets processed by the example shared architectures and associated service. Enabled player access devices may also be used at live events allowing players to place lottery and/or event-based bets directly.
• It will be appreciated that interactive events on demand may require fast, timely deployment of mobile retailer access devices for processing player lottery and/or event-based bets at prominent sporting events in real time. Players with enabled devices can also place lottery wagers and event-based bets directly. The example architecture illustrated inFIG. 5 may be particularly well-suited for providing wagering services when special events occur, e.g., major sports events like sports championships, the World Cup, or events which change locations. New pilot interactive lottery or other wagering programs may be activated quickly and at minimal upfront cost.
Universal Player Service
• The example architectures described herein may also provide a Universal Player Service that allows wagering and lottery players to access their player account (registered and/or anonymously registered) information from a variety of player access devices such as lottery point-of-sale terminals, self-service terminals, Internet PCs, Internet Mobile Phones, and interactive television set top boxes. Players may establish a lottery play account and utilize this account during game play across multiple interactive game play access channels. The player account may be independent of any particular game operator or specific lottery jurisdiction and may be used by the player when participating in wagering or lottery game play or other wagering offerings (where and in a manner that such use is consistent with regulatory requirements). The universal player service may aggregate a player's game play activity across multiple interactive channels and across multiple game operators and lottery jurisdictions, so players may see a single report, and receiving a warning if they are wagering more than they desire, or if they have a low balance.
• Upon registration, player customers may be assigned a globally unique player identifier as part of their universal player service account.
Universal Retailer Service
• The example architectures described herein may also provide a universal retailer service which may be configured to allow lottery retailers and other wagering game retailers to access their retailer account information from a variety of retailer access devices such as lottery terminal point-of-sale environment terminals, Internet PCs, Internet Mobile Phones, and Interactive television set top boxes. Retailers can establish a lottery agent account and utilize this account during game sales activities across multiple interactive game sales channels. The retailer account may be independent of any specific game operator or lottery jurisdiction and can be used by the retailer when participating in lottery game sales offerings.
• The universal retailer service may aggregate retailer game sales activity across multiple interactive channels and across multiple game operators and/or lotteries.
• Upon registration a retailer may be assigned a globally unique retailer identifier as part of their shared server account. The universal retailer service provided from the shared server may enable a technology provider to establish direct (independent of the game operators) or indirect relationships with game retailers. Retailers can manage their lottery inventory and financial account details using the universal retailer service and large retail chains can manage their inter-state (or global) retailer base using the universal retailer services, aggregating sales activity and rolling up summary data, including aggregates across multiple game operators.
• The retailers may also use the shared player CRM information, described elsewhere in the present application, for market research and management.
Randomization Service
• Many gaming operations, e.g., lotteries, may require the use of secure, auditable random or pseudo-random numbers. The example architectures described in the present application may provide randomization services (e.g., generation/distribution) to participating subscribers across access channels (i.e. iPC, iMobile, and iTV). Many kinds of randomization services can be provided, e.g., a random set of numbers like the drawing numbers in a numbers lottery or keno, a random number chosen between a minimum and a maximum value, a shuffled card deck, or the first n values from a shuffled card deck, a prize multiplier in a certain range simulating a wheel spin, an order of finish for a simulated race with a certain number of participants and either uniform or non-uniform predetermined odds. These random numbers may be used both for determination of outcomes (like a lottery draw) and for automated wagers (e.g., a lottery Quick Pick). Winning number draws demand a much higher level of unpredictability and security (so that no unscrupulous person can forge winning numbers to illegally claim a game's jackpot).
• While pseudo-random numbers are acceptable for Quick Picks to appear random, winning numbers may need to be both highly unpredictable and auditable. For this reason, software-based, pseudo-random number generators are typically used for quick picks, while typically winning numbers, if generated using an automated draw machine, require some very sophisticated algorithm and dedicated hardware to constantly produce unpredictable results. In a sense, Quick Picks may just need one seed for a long time, e.g., a day or a month, but winning numbers may require many seeds in a short time, e.g., every selection of a winning number.
• From a player's point of view, Quick Picks may be generated on a retailer's lottery terminal locally (although typically, winning numbers are generated on a remote machine in a game operator's data center), but in some cases, wagers have to be generated on a remote host, e.g., for wagers to be generated for cell phones or PDAs, where computing power may not be adequate to run random number generation software. Even if wagers can be generated on a local machine, e.g., a lottery terminal, interactive TV or cash registers, the implementation may require different approaches to obtaining an operating system level entropy source in different systems, e.g., a Linux machine versus a Microsoft Windows operating system platform.
• Today lottery systems are deployed jurisdiction by jurisdiction. Typically, each jurisdiction has one or two separate lottery systems in its own geographical boundary. The randomization service provided by the example architectures described in the present application may eliminate the need for lotteries and other game operators to deal with the problem of generating acceptable random numbers on different platforms by providing a centralized randomization service accessible to various applications.
• FIG. 10 illustrates an example randomization service, according to the present invention. In the example systems described above, channel devices and retailers may require access to randomized numbers in support of game operations. As shown inFIG. 10, a number of channel devices may be provided for different channels and points of access. These devices may include anInternet terminal1021, apersonal computer1022,cell phone1023, a personaldigital assistant1024, anInteractive television1025 and aretailer terminal device1026. Random numbers may be generated uniformly on a remote centralized server (or cluster)1000 so that different game operators do not need to run different random number generation software. Rather, all of the game operators may share the same commoncentralized randomization service1000, to randomly generate both Quick Picks and winning numbers. The use of thecentral randomization service1000 may eliminate the issues of platform disparity, local and remote generation, resolution of inconsistencies between different algorithms, and the need to audit multiple implementations. Thecentralized randomization service1000 may be provided using modern server technologies such as server clustering, load balancing, shared storage, server redundancy, grid computing, or even traditional client-server approaches. A highly-reliable, high-performance randomization service may be provided to lottery systems and other game operators and their applications. For example, each different game operator subscribing to the service may be provided its own random seeds and internal states for the generation of Quick Picks, or for the case of winning numbers, its own hardware entropy source and jurisdiction specific information (an identifier or “token”). Optionally, each game operator may have a separate dedicated instance of the randomization service program. In this example approach, each game operator may maintain their own data about random number generation, but they all use the same software in the same environment.
• Optionally, if a game operator has some regulatory requirements that data must reside within its own geographical boundary, data related to the multi-tenant randomization service may be stored in one or more game operatorRegional Hosts1011,1012 and1013 or data centers, e.g., by pre-downloading random numbers and later providing a decryption code. Data and code may be separated with a regional data center really serving as a data storage facility, since the software and computing power may be provided by a remote centralized randomization service.
Security Services
• Security services such as encryption, authentication, digital signature, and validation of winning numbers may also be centralized in the shared host of the example architectures described in the present application. Existing two-layer centralized security schemes may be used, with the host security provided at either the regional or central host system. Alternatively, three layer schemes may be employed, e.g., with data storage at one service and the code for authentication at a different level. For example, public key service might be provided at the central shared host, while the encrypted data is authenticated at the regional host. This may reduce the risk from insiders and collusion attacks.
Shared CRM System
• Some example embodiments of the present invention may include a player customer registration or other similar customer relationship management (CRM) system that may be shared by the various game operators who use the system.
• A shared CRM service may be provided to the different game operators, e.g., as part of the shared hosts shown inFIGS. 2-6 and8-9. Player customers of various games may be identified to the system, and their identification may, but need not necessarily be tied to their personal identity. Players may be identified with various forms of personal information such as a name, address, bank account or credit card information, social security, passport, or other governmental identification number, or a special number assigned by the system. Alternatively, player's could be anonymous at the point of purchase, e.g., accessing the system only with a unique identification number or other pseudonym, even though their personal information is not associated with their identity in the system, e.g., not associated in the database with personal information. As a further alternative, a player's identification number might be unique but still anonymous, e.g., an identification code on a bearer card account or bearer instrument like a scratch-off instant lottery ticket.
• The player's identification number may be employed to identify players to the various game operators or jurisdictions, and also across various different channels. The CRM may be configured to store records of player activity across the game operators and jurisdictions and across the different channels of play. This information may be shared between game operators, or optionally, game operators may choose to keep their own data segregated from other game operators. Services and convenience programs, e.g., frequent player reward programs, targeted promotions, and other player customer services may be offered based on total play across all channels and jurisdictions.
• The player identification, which may include a unique player credential would be entered into the system or held within a device (e.g., player card, electronic identifier such as a dongle or secure cookie, or some other artifact that contains data) that the channel can read. In both instances the player may present these same player credentials for every instance they play a game regardless of channel and jurisdiction. These credentials verify their eligibility to participate in the games offered, and dependent upon the level of registration, may provide the means to electronically pay for game participation as well as collect any winnings that result from that participation.
• The CRM may be configured to make players known to any of the other components of the system, e.g., the service engine and OLTP. For example, once a player card is presented to a client device (regardless of what channel or jurisdiction), the overall CRM system may interact with the service interface to detect who the player is (even if they are anonymous) and the services that are available to them.
• The CRM may be configured to serve all channels and all game operators in the example system, and may provide services to the player customer related to their play. These services provided to customers may include:
• A Responsible Gaming Service—configured to enable the player (or Lottery) to set playing thresholds to alert the player when they are nearing their maximum and disallowing play once they have reached the threshold. This threshold logic may apply across all channels and game operators or jurisdictions.
• A Rewards Service—configured to enable the player to receive rewards (points, prizes, etc.) for their play accumulative across all channels and game operators or jurisdictions.
• A Favorite Game Service—configured to enable the player upon presenting their card or other identifier to be provided the player's favorite game (according to the channel) or, in the case of traditional games, the player's favorite wager numbers.
• A History Service—configured to enable a registered player to view (via a player portal into the CRM service, e.g., a secure web page) their wager history (across all channels and jurisdictions) and prize history (across all channels and jurisdictions).
• A Player Data Habits Service—the operator of the shared CRM could also provide analysis of player habits to the various game operators including all channel and jurisdiction data. This may be done via the CRM recording every game played, channel used, jurisdiction played from, bet amount, prize amounts, length of play, and responsible gaming activity. This analysis may be used to do market research on changes to game content, loyalty programs, advertising campaigns, and promotional activity.
• For players that have provided personal data (e.g., social security number or other governmental identifier, name, address, bank account) additional services may be offered across channels and jurisdictions. These services may include a secure eWallet that allows them to keep an electronic store of value on the system, automatic prize payout, and coupons/prizes sent to players' physical or electronic address. Player customers could opt to allow the central system to have access to their personal data without giving access to the individual game operators.
Back Office Normalization Engine
• Traditionally, online gaming systems, e.g., the lottery host systems operated by different lottery jurisdictions, have been provided to individual jurisdictions and each jurisdiction built or bought their back-office support systems to comply with the data formats, reports, and connectivity of the supplied online system. However, a problem arises whenever the online lottery system is replaced, because the new system generally has different data formats, reports, and connectivity.
• Additionally, it has not been customary for jurisdictions or different game operators to share a single online lottery system among themselves. However, some example embodiments of the present invention provide such a shared system, where multiple jurisdictions are connected to, and receive data and reports from, a single instance of an online gaming system.
• To minimize the changes needed to be made to back office systems when new online systems are installed or when connecting to a shared online system, there is a need for a new component, e.g., a software controlled dedicated computer system, or software modules located in some portion of the larger system, that will, on one hand, appear to have the existing back-office interface, but yet, on the other hand, accommodate the requirements of the new system.
• FIG. 11 illustrates an example architecture of a conversion system which may translate between existing back office systems and a new online system. InFIG. 11, anormalization component1101, is placed between existingback office systems1102 and a newonline lottery system1103. Thenormalization component1101 may facilitate communication between the existingback office system1102 and the newonline lottery system1103, translating data and reports between formats used in the existing legacy lottery system and formats used in the new online lottery system. The normalization component may include modules for the performing normalization functions and also for expanding the capability of the normalization component. For example, the normalization component may include modules for each of the proprietary formats in which it is able to communicate, and an expansion modules for installing or updating the normalization component with new or altered formats.
• Some example embodiments of the present invention provide a normalization engine and associated hardware and/or software systems and methods which may be responsible for transforming data, reports, and connections as necessary for the back office systems, e.g., the back office systems described above inFIGS. 2-6 and8-9, where the normalization engine may be included as a component of, or adjunct to, theservice interface211.
• FIG. 12 illustrates an example normalization engine which may operate between an existing back office system and a new online lottery system. ANormalization Engine1201 may be provided between the existing back office systems at multiple game operators and the share system. The engine may be configured to perform all necessary data transformations in order to allow existing Back Office Systems (1221,1222 and1223) to work with a new orShared Lottery System1230, with no or minimal modification of the existing back office systems. This may include transforming data as it is being sent to or from a back office system from a sharedonline system1230, transforming reports sent from the sharedonline system1230 to back office systems so that they are similar to pre-existing reports, and providing communications connectivity between the back office systems and the sharedonline system1230.
• A plurality of normalization engines (1301,1302 and1303) may also be individually configured to respectively accommodate multiple legacy host systems (1311,1312 and1313), as shown inFIG. 13, and a variety of back office data formats.
• Exemplary procedures according to example embodiments the present invention will now be described. The example procedures may be implemented in any of the example systems A-G previously described. Various parts of the example procedures will be described with reference to particular components of the example systems. However, those skilled in the art would understand that the elements of the example procedures may also be performed in other components or systems. Thus, the exemplary procedures are not limited to the example systems described above, but may also be successfully implemented in other systems in accordance with the present invention.
• FIG. 14 illustrates an example procedure for making a new game available, according to an example embodiment of the present invention. An example procedure, such as that shown inFIG. 14, may be implemented in any of the shared hosts previously described. In1401, a content developer develops and tests a new game within a development environment (e.g., the development environment ofFIG. 9). The content developer may be, e.g., an individual programmer, a lottery or other wagering game operator, or a software publishing company. Individual software code may be written, debugged and tested before being assembled (e.g., as an executable or binary file) to form a final product. The game may then be deployed as channel content to a database (e.g., the channel content server) within a sharedhost1402. The game may be transmitted over a communications network (e.g., uploading over the Internet) or physically (e.g., via a CD-ROM or DVD).
• In1403, the shared host may receive an access request for the game from one or more channel devices. The access request may originate from a lottery or wagering game operator wishing to subscribe to the game, thereby enabling users within the operator's jurisdiction to access the game.
• In1404, the channel content may be configured according to the subscriber's parameters, which may be pre-set defaults, or which alternatively may be input, e.g., through a customization interface. This may include establishing usage limitations, customizing game content, establishing delivery format and other parameters requested by the subscriber. The game may then be ready to be distributed to authorized users of channel devices in the operator's jurisdiction via the shared host'sservice interface1405.
• FIG. 15 illustrates an example procedure for activating a game, according to an example embodiment of the present invention.
• In1501, a game activation request may be received, for example at a shared host, from a lottery or wagering game operator. The request may be produced using a channel device such as the lottery operator's personal computer or terminal, or from a management terminal or server. This may occur via a software interface provided by the shared host. To facilitate activation a shared host may include an activation or adoption module. Such a game activation module may provide services for the activation of games for jurisdictions or game operators. For example, an activation module might provide an interface for game operators to select games to activate. The game activation module may also include modules for verification of access rights, reporting of activation activity, and interfacing with accounting and billing systems.
• In1502, he operator's authorization information may be received, for example at the shared host. This may, for example, include a username and a password, which serve to identify the operator as a person authorized to perform the request. The authorization information may be authenticated, e.g., at the shared host.
• In1503, the shared host may receive and confirm licensing information from the operator. The interface may provide an option to select one or more licensing agreements. The terms of the agreement(s) may be selected or modified by the operator. Once this information is received, the shared host may confirm that the terms are acceptable and may issue a confirmation notice to the operator.
• In1504, the game may be configured on the shared host according to game operator specifications. This may involve selecting usage restrictions (e.g., who can access the game and under what circumstances) and game features (e.g., wager limits, disabling or enabling certain in-game options). The operator may also be given an opportunity to perform customization of the game itself (e.g., branding). This may be performed by the operator himself (e.g, using a game development kit) or by another person on behalf of the operator. Game configuration may be facilitated by a game customization engine, which may be included in a shared host. Such a game customization engine may provide an interface to permit game customization. The game customization engine may also include a storage module for storing the configuration choices made, and may also contain a module for controlling the features of a game which may be subject to customization.
• In1505, the game may be ready to be distributed to channel users in accordance with the operator's specifications. Accordingly, the shared host distributes and activates the game by enabling authorized channel devices to access the game, and may distribute and automatically install required software components or other assets in the various devices.
• FIG. 16 illustrates an example procedure for revenue sharing, according to an example embodiment of the present invention. In1601 accounting information may be received, for example at an accounting system, possibly contained in a shared system, related to a game operator, e.g., information about what games are activated, and the amount of use of those games, such as number of players, number of plays, dollar volume wagered, etc.
• In1602, whether the game operator has a usage-based license may be considered, for example by the accounting system. Assuming the game operator has a usage-based license, the amount due from the game operator may be determined in1603, based at least in part on the accounting data received. In1604, revenues may be received related to the game operators game plays, e.g., either as a share of customer revenue received at a shared host (if customers pay the shared host directly) or a payment or share of revenues received by the game operator which is shared with the game host operator and content developer.
• In1605, a share of the revenue for a particular game received from the game operator is paid to the operator of the shared host, for example as a payment generated on the accounting system, and another share to the developer or provider of the game.
• Alternatively, in1606, non-usage based payments may be received from game operators, and may be reflected in the accounting system. For example, the shared host operator may receive a prearranged fixed fee, or a fixed fee for providing a certain number of games. In1607, fees may be shared with the game developer or provider, for example as a payment generated on the accounting system. These fees may be predetermined, if there is no usage based pricing for game operators, although it is possible that the game developer could still be paid based on usage, even if the game operator did not, e.g., if the shared host operator agreed in advance to pay the game developer based on total usage, and then elected for business reasons to contract with game operators for fixed fees.
• The above activities may be facilitated by an accounting system, which may be part of a shared host. Such an accounting system may include a module for tracking game usage statistics. The system could also have module for the configuration and storage of billing parameters. For example, the system could provide a module allowing for the identification of parties involved in revenue sharing and an identification of how the shares are calculated. The accounting system may also include a charging and payment engine, capable of issuing bills, printing checks, updating accounts, etc. The accounting system may also include a storage system for storing accounting data, billing and payment information, etc.
• FIG. 17 illustrates an example procedure for playing a game on a player client, according to an example embodiment of the present invention. In1701, a player, using the player client, may request access to a game. In1702, the player may be authenticated, e.g., based on their registration information. The authentication may be distributed, or may be done, e.g., by a shared host providing a multi-tenant security service for multiple game operators, as was described above. In1703, assuming the player has been authenticated, content assets may be delivered to the channel device that the player is accessing, e.g., from a content repository on the shared host. This game content may be installed on the channel device and activated. In1704, wager information and other game parameters may be received from the player. In1705, game services, e.g., outcome determination may be provided, e.g., on the shared host. In1706, game functions, e.g., presentations which depend on the outcome determinations made by the shared host, may be provided on the channel device. In1707, game results may be displayed to the player. In1708, game results may be recorded at the shared host.
• It will be appreciated that all of the disclosed methods, games, and procedures described herein can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer-readable medium, including RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be configured to be executed by a processor, which when executing the series of computer instructions performs or facilitates the performance of all or part of the disclosed methods, games, and procedures.
• It will be appreciated that, in the above descriptions, reference has been made to “random numbers” and “random number generation.” It will be appreciated that this recitation includes both random sampling of physical events, the use of a computer software pseudo random number generator, a firmware or hardware random or pseudo random number generator, or the reference to external real world events that are effectively random for the purposes of the game, e.g., the least significant digit in the total trading volume on a stock exchange. Access may also be provided to a secure random number generator outside the system itself, e.g., a utility or service that provides the results of random external events, such as ball drawings used in conventional Lotto type games or pseudo-random numbers generated on another computer system, or access to other information that while not perhaps not technically random in a purely theoretical mathematical sense, is unknowable in advance and effectively random for the purpose of the game, e.g., reference to particular sports or financial information, such as the last (least significant) digit in the total stock sales on the New York stock exchange, or the last (least significant) digit of the total number of pitches thrown in all the major league baseball games on a particular day. Where “random numbers” are referred to in the present application, it should be understood, unless expressly indicated otherwise, that any of the above approaches to random number generation are intended to be included. It is also appreciated that, the random numbers can be used to determine game outcomes; however, the determination, unless specifically required by the language of the claims need not be done in any particular location, it may be on a dedicated machine, a server, accessed over a network, etc.
• The foregoing descriptions of the example embodiments of the present invention reference the terms “communications” and “in communication with”. As used throughout the specification of the present application, these terms refer to device or system components which are in electrical or optical communication with each other. This may include both digitial and analog communication, both synchronous and asynchronous communication, and may be wired as well as wireless communication, using both direct (e.g., device-to-device) and indirect (e.g., networked through an intermediate device) communication.
• In the preceding specification, the present invention has been described with reference to specific example embodiments thereof. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the present invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

Claims (36)

1. A system for providing services to a plurality of lottery operators each associated with one of a plurality of jurisdictions, comprising:

a shared lottery host accessible to a plurality of lottery game terminals in each of the plurality of jurisdictions;

a game archive accessible to the shared lottery host storing software code configured to operate a plurality of wagering games selectively activatable by the plurality of lottery operators, the shared lottery host configured to communicate with the plurality of terminals to enable the terminals in a particular jurisdiction to allow the sale of tickets for the games which have been selectively activated by the lottery operator for that jurisdiction; and

an activation engine in communication with the shared lottery host, the activation engine configured to receive instructions from a lottery operator from the plurality of lottery operators to activate one of wagering games stored in the game archive.

2. The system ofclaim 1, further comprising:

a game operator host in one of the plurality of jurisdictions;

a plurality of point of access devices in the one of the plurality of jurisdictions.

3. The system ofclaim 2, further comprising:

a local game provided by the game operator host; and

a router configured to route communications from the plurality of point of access devices concerning the local game to the game operator host and configured to route communications from the plurality of point of access devices concerning the games provided by the shared host to the shared host.

4. The system ofclaim 2, wherein:

communications between the shared host and the point of access devices are routed through the game operator host.

5. The system ofclaim 1, further comprising:

a normalization engine in communication with the shared lottery host and a back office system of a lottery operator in the plurality of lottery operators, the normalization engine configured to convert data communicated between the back office system and the shared lottery host from a legacy format specific to the lottery operator to a shared standard format used by the shared lottery host.

6. A system for providing services to a plurality of lottery operators, comprising:

a shared lottery host including at least one computer system, the shared lottery host accessible to a plurality of lottery agent terminals and lottery customer clients in a plurality of jurisdictions;

a game archive accessible to the shared lottery host, the game archive storing software code for operating a plurality of wagering games selectively activatable by the plurality of lottery operators;

an activation engine accessible to the plurality of lottery operators, the engine configured to allow the plurality of lottery operators to selectively activate the wagering games;

a customization engine accessible to the plurality of lottery operators, the customization engine configured to allow the plurality of lottery operators to alter attributes of the wagering games;

a network providing connectivity between the plurality of lottery agent terminals and lottery customer clients and the shared lottery host, the lottery customer clients including at least one of a mobile phone, a personal computer, and an interactive television device;

a database accessible to the shared lottery host storing wagers placed at the plurality of lottery agent terminals and lottery customer clients;

a charging engine configured to receive information regarding wagering game usage by the plurality of lottery operators and to determine charging fees for the lottery operators based at least in part on the received information;

a lottery level financials reporting system configured to report sales information to the plurality of lottery operators for their respective activated games;

an agent-level financials reporting system, configured to report sales, invoices, and commissions to lottery agents for the games activated in a particular jurisdiction; and

a lottery game results reporting system configured to report the outcomes of wagering games to the game operators.

7. A method for providing services to wagering game operators, comprising:

providing a shared host in communication with a plurality of game operators;

providing a shared library of wagering games accessible to the shared host, and available for selective activation by the plurality of game operators;

receiving a request from a game operator from the plurality of game operators to activate a game;

responsive to the request, activating the game for the game operator on the shared host; and

charging the game operator based at least in part on the amount of usage that is made of the game by customers of the game operator.

8. The method ofclaim 7, further comprising:

receiving software modules for a new game from a content developer;

storing the software modules in the shared library;

receiving a request, at the shared host, from the game operator to activate the new game;

responsive to the request, activating the new game, on the shared host, for the game operator; and

paying a portion of the revenue received from the game operator for the new game to the content developer.

9. The method ofclaim 8, wherein the content developer is one of the plurality of game operators.

10. The method ofclaim 7, further comprising:

distributing software modules from the shared library which are associated with the game to point of access devices operated by the game operator.

11. The method ofclaim 7, wherein the game operator has a game operator host, the method further comprising:

passing communications relating to operation of the game between the shared host and a plurality of point of access devices through a game operator host.

12. The method ofclaim 7, wherein the game operator has a game operator host providing a second game not provided by the shared host, further comprising:

routing communications, related to the game, from a plurality of point of access devices to the shared host; and

routing communications, related to the second game, from the plurality of point of access devices to the game operator host.

13. A system comprising:

a game repository storing software code for a plurality of wagering games accessible to a plurality of game operators, the wagering games being selectively activatable by the plurality of game operators and having a plurality of tunable parameters; and

a game customization engine configured to allow a game operator from the plurality of game operators to select values for the tunable game parameters when a wagering game from the plurality of wagering games is activated by the game operator.

14. The system ofclaim 13, further comprising:

a content server configured to distribute the software code for an activated wagering game which has been customized by the game operator to the game operator's point of access devices.

15. The system ofclaim 13, wherein the tunable parameters include at least one of a wagering game payout percentage, a wagering game name, a wagering game operator name, and a legal notice.

16. The system ofclaim 13, wherein the game customization engine is further configured with default parameter settings for each game operator from the plurality of game operators which are automatically applied to wagering games activated by that game operator.

17. A system, comprising:

a game repository accessible to a plurality of wagering game operators, the game repository configured to allow the wagering game operators to select games from the game repository to offer to their respective customers;

a game repository deposit system configured to allow the entry of new games in the game repository;

a game adoption system configured to allow the wagering game operators to adopt the games in the game repository; and

an accounting system configured to determine the amount charged to the game operators based at least in part on adoption of the games in the game repository by the game operators.

18. The system of17, wherein:

the accounting system is further configured to determine an amount due to content developers for games deposited in the game repository based at least in part on adoption of the game by the game operators.

19. The system of17, wherein the amount charged to the game operators for a particular game is based at least in part on an amount of usage made by the game operator's player customers of the particular game.

20. A system, comprising:

a game repository accessible to a plurality of lottery game operators, the game repository configured to allow the lottery game operators to select lottery games from the game repository to offer to their respective customers;

a game repository deposit system configured to allow the entry of new games in the game repository by content developers;

a game adoption system configured to allow the lottery game operators to adopt the games in the game repository; and

an accounting system configured to determine an amount due to game depositors, for games deposited in the game repository, based at least in part on an amount of use made of the games by the lottery game operators' player customers for games the lottery game operators have adopted from the games in the game repository, the accounting system further configured to determine an amount due to content developers, for the games deposited in the game repository, based at least in part on adoption, by the lottery game operators, of the games deposited in the game repository, and further configured to determine an amount charged to the lottery game operators for a particular game, based at least in part on an amount of usage made by the lottery game operators' player customers of the particular game.

21. A method for providing wagering games to wagering game operators, comprising:

receiving deposits in a game repository from game depositors of game software modules for a plurality of games;

providing the wagering game operators access to the game software modules in the game repository;

collecting fees from the game operators based on their player customers' use of the games in the game repository and recording the fees in an accounting system; and

issuing a payment to the game depositors, using the accounting system, based on a pre-arranged portion of the fees from the game operators for the use of games deposited by the game depositors.

22. The method ofclaim 21, wherein the fees collected from the game operators are based on at least one of a number of times a game is played, the number of players who play the game, an amount of revenue received by a game operator, and an amount of profit earned by the game operator for the game.

23. A player customer relationship management system for a plurality of wagering game operators, comprising:

a customer relationship management server, configured to communicated with a plurality of wagering game operator servers, each associated with a wagering game operator from the plurality of wagering game operators; wherein

the customer relationship management server is configured to receive from each of the wagering game operator servers information regarding player customers collected by the wagering game operator servers; and

the customer relationship management server is configured to aggregate the information into a common wageror database containing information received from each of the wagering game operator servers.

24. The system ofclaim 23, further comprising:

a plurality of games from third party content providers selectively accessible by the plurality of wagering game operators; and

an interface configured to provide information to a third party content provider associated with a game from the plurality of games regarding player customers associated with at least two of the wagering game operators who have played the game.

25. The system ofclaim 24, wherein the interface is configured to provide aggregated information to the third party content provider while preventing access to information related to individual player customers.

26. The system ofclaim 23, wherein the information regarding player customers in the common wageror database does not identify individual player customers.

27. The system ofclaim 23, where the wagering game operators are governmental lotteries in different respective jurisdictions operating independently of each other.

28. The system ofclaim 23, wherein the player customers are permitted to access information related to themselves in the common wageror database.

29. The system ofclaim 28, wherein the information related to a player customer includes a player account with a monetary balance that can be accessed to play games provided by the plurality of wagering game operators.

30. A retailer management system for wagering games, comprising:

a plurality of wagering games offered by a plurality of wagering game operators through a plurality of retailers which are associated with a retailer organization; and

a host in communication with the plurality of wagering game operators and the plurality of retailers, the host configured to receive information regarding wager sales made by the plurality of retailers for the plurality of wagering games and to report aggregated sales data for the plurality of wagering games made at the plurality of retailers to the retailer organization.

31. The system of30, wherein the wagering games are provided from the host to the plurality of wagering game operators, at least a subset of the wagering games are operated by more than one of the wagering game operators, and the host is configured to aggregate the sales data for the retailers of the retailer organization from multiple wagering game operators.

32. The system ofclaim 31, wherein a plurality of pluralities of retailers are operated by a respective plurality of retailer organizations, and wherein the host is configured to report aggregated sales data for the plurality of wagering games to each retailer organization for their respective retailers.

33. The system ofclaim 30, wherein the wagering games used by multiple wagering game operators are customized by each wagering game operator.

34. The system ofclaim 30, wherein software code for operating the wagering games by the plurality of wagering game operators is provided on the host.

35. The system ofclaim 30, wherein the host is a single centralized computer system.

36. An article of manufacture comprising a computer-readable medium having stored thereon a series of instructions executable by a processor, the instructions configured to cause the performance of the method of7.

Images