Patent Application
20090143128
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.
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.
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.
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 to
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 in
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 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.
The shared host 200 may include a configuration and control system 201. This system 201 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 shared host 200 may include an online transaction processing system 202. The OLTP system 202 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.
The OLTP system 202 may include a basic OLTP Platform 203 which the games are based around. Although the implementations of the OLTP Platform 203 may vary among different shared hosts, each OLTP platform 203 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.
The OLTP platform 203 may interface with a game services component 204. The game services component 204 may provide a uniform set of services which may be accessed by games 206, 206 and 207 located in the OLTP system 202. 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, the OLTP platform 203 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 or repository 1800, such as that illustrated in
An additional game service that may be provided by the game services component 204 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 shared host 200. 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.
The OLTP system 202 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 shared host 200 may be a content server 208 which may deliver channel content between the shared host 200 and the operators. The content server 208 may include a channel configuration engine 209, 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). The content server 208 may also include a channel content engine 210, 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 in Jurisdiction A 220. 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 in
The passthru engine 223 is configured to operate as a transaction acquirer which serves as an intermediary between the shared host 200 and the channel users. Transaction requests are received at the passthru engine 223, 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's host 221, whereas requests for shared games are forwarded to the shared host 200.
The game operator's host 221 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's host 221 may also be connected via a network, e.g., the Internet, directly to a game player's client device such as a personal computer 225, a mobile phone 226, and an interactive television terminal 227.
In addition to the game operator host 221, 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 and control system 201 in the shared host 200. The back office system may include various applications 228 and 229, 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, the OLTP system 202 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 in
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.
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, an Acquirer Service engine 301 may be provided as part of a shared host 300, between the service interface engine 211′ and a legacy lottery host 322. The Acquirer Service engine 301 may be configured to communicate with a plurality of Jurisdictions A 320, B 330 and C 340, each of which may include a legacy host.
Also, separate from the legacy host 322, a router 321 may be provided specifically for handling transactions from customers and agent terminals that involve games provided on the shared host 300. These transactions may be handled without passing directly through the legacy lottery host 322 on the way to the shared host 300. The router 321 may receive transaction requests and forward the requests to either the shared host 300 or the legacy host 322 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 existing games 222′. 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 shared host 300 and the legacy host 322. The shared host 300 may keep records relating to usage of shared games while an accounting engine 323 in the legacy host 322 may track usage of legacy games. Channel management may be performed by local applications and sent to the Acquirer Service engine 301 for reconciliation.
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.
In the example System C, a local acquirer engine 421 may be provided within each of several Jurisdictions A 420, B 430 and C 440. The local acquirer 421 may be configured to manage all of the channels (both player and retailer) and to forward gaming transactions to a shared host 400. The local acquirer service may also include a local service interface 422 which may be configured to request gaming services from the shared host 400. When a transaction request is received, the local acquirer 421 may automatically forward the request to the shared host 400, which may then fulfill the request by, for example, distributing a requested game along with any associated services back to the local acquirer 421.
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 more back office applications 228″ and 229″. In addition, accounting may be performed substantially remotely at the shared host 400. Management users 423 at each jurisdiction may receive accounting information by communicating with the shared host 400 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 shared host 400, allowing the management users to choose between the local applications and the hosted applications.
The shared host 400 may also include a hosted services engine 401 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 hosted services engine 401. Other hosted services may, for example, include player registration services, game activation services and management services.
In example System D, player and retailer transaction requests are received at a communications service engine 501 located at the shared host 500. The communications service engine 501 may provide a set of communication protocols along with a corresponding communications arrangement for interfacing with the channel devices. The communications service engine 501 may extract the requests from the communications and pass the requests to an acquirer service engine 502.
In System D, the acquirer service engine 502 directs the transactions to an appropriate component of the shared host 500 for processing. For example, a gaming transaction may be directed to the OLTP 202 while a back office transaction may be directed to a hosted services engine 503. 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 shared host 500. However, once this software is developed, retailers may access it without any perceived difference between the features of the new and legacy software.
The hosted services engine 503 may provide all of the retailer, player and back office applications required by each of the jurisdictions. Initially, the hosted services engine 503 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.
The shared host 600 may include components similar to those of the shared host 500, including a communication service engine 501 which may facilitate communications with lottery operators located in different jurisdictions 620, and an acquirer service engine 502, 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 shared host 600 allows multiple access paths depending on the particular channel being accessed.
A service interface 602 may provide direct access to games located in the OLTP 202 by communicating with a video host 631 or a casino server 641. Games and game services may be delivered from the video host 631 and the casino server 641 to a channel device such as a video lottery terminal 632 or a slot machine 642. Additionally, the service 602 interface may be configured to deliver channel content directly to the channel devices.
The shared host may also include a direct retailer and player services engine 601 which may be configured to provide direct service to players/retailers 650. 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 shared host 600 may be coupled to the hosted services engine 503, enabling direct access to such services as accounting, player registration and game subscription.
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.
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. The AM 701 serves as the warehouse for the assets of all the games of the gaming framework. The asset manager 701 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.
As shown in
The channel device 840 may operate on its own platform and OS 841 on which game content 831 may be built. The game content 831 delivered may co-exist alongside existing game content 843 and along with non-game functions 844 (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 a Passthru engine 821 of a lottery host 820, or a local acquirer and an acquirer service engine located on the shared host 800 (not shown).
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 and localization department 931 of a lottery 930 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 a Content Server 901, which may then distribute the content to a requesting channel device (e.g., a Channel Device 920).
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.
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.
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 in
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.
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.
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.
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 operator Regional Hosts 1011, 1012 and 1013 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 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.
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 in
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.
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.
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 in
A plurality of normalization engines (1301, 1302 and 1303) may also be individually configured to respectively accommodate multiple legacy host systems (1311, 1312 and 1313), as shown in
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.
In 1403, 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.
In 1404, 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's service interface 1405.
In 1501, 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.
In 1502, 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.
In 1503, 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.
In 1504, 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.
In 1505, 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.
In 1602, 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 in 1603, based at least in part on the accounting data received. In 1604, 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.
In 1605, 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, in 1606, 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. In 1607, 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.
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 61005386 | Dec 2007 | US |
