Source: http://www.google.fr/patents/US8636596
Timestamp: 2017-09-22 17:18:58
Document Index: 118150929

Matched Legal Cases: ['Application No. 60', 'Application No. 2', 'Application No. 06785708', 'Application No. 07843492', 'application No. 01983154', 'application No. 01983154']

Brevet US8636596 - Dynamic player notices for operational changes in gaming machines - Google Brevets
A gaming terminal data repository (GTDR) for storing game software components and transaction information for gaming machine and gaming terminals is disclosed. A system database is partitioned according to different gaming entities allowing game software component configurations of particular gaming...http://www.google.fr/patents/US8636596?utm_source=gb-gplus-shareBrevet US8636596 - Dynamic player notices for operational changes in gaming machines
Numéro de publication US8636596 B2
Numéro de demande US 11/176,833
Date de priorité 4 nov. 2000
Autre référence de publication CA2613629A1, CA2613629C, EP1902430A1, US20050282638, US20140141872, WO2007008413A1
Numéro de publication 11176833, 176833, US 8636596 B2, US 8636596B2, US-B2-8636596, US8636596 B2, US8636596B2
Inventeurs Richard E. Rowe
Citations de brevets (144), Citations hors brevets (64), Classifications (15), Événements juridiques (2)
US 8636596 B2
1. A gaming terminal data repository, comprising:
a network interface adapted to communicate with a first gaming terminal located separate from said gaming terminal data repository, said first gaming terminal being adapted to accept wagers, play games based on said wagers, and provide monetary awards based on the outcomes of said games;
a memory arranged to store gaming terminal transaction information received from said first gaming terminal and game software components for use by said first gaming terminal, wherein at least one of said game software components stored at said gaming terminal data repository memory is not also stored at said first gaming terminal; and
a processor configured: i) to update game software components on said first gaming terminal using one or more update triggers, ii) to receive game software component information from said first gaming terminal, wherein the game software component information describes game software components stored on said first gaming terminal, and iii) to download game software components adapted to present a game of chance to said first gaming terminal,
wherein the gaming terminal data repository is configured to: determine a first gaming jurisdiction where said first gaming terminal is located, generate instructions for configuring game software components that comply with rules of said first gaming jurisdiction, and send the instructions for configuring the game software components to said first gaming terminal such that game software components stored on said first gaming terminal can be combined with game software components downloaded from the gaming terminal data repository to create a different combination of game software components to provide different game play features to enable a new version of a current game or a different game to be played if the current game is performing poorly.
a player compliance module adapted to facilitate the provision of information regarding one or more operational changes of said first gaming terminal, said one or more operational changes resulting at least in part from communications from said gaming terminal data repository.
The present application is a continuation-in-part of and claims priority from U.S. patent application Ser. No. 10/659,827 by Rowe, filed Sep. 10, 2003 now abandoned, which is a divisional of and claims priority from U.S. patent application Ser. No. 09/746,944 by Rowe, filed Dec. 21, 2000 now U.S. Pat. No. 6,645,077, which claims further priority from U.S. Provisional Patent Application No. 60/242,046 by Rowe, filed Oct. 19, 2000, each of which is entitled “Gaming Terminal Data Repository and Information Distribution System,” each of which is commonly assigned, and each of which is incorporated by reference herein in its entirety and for all purposes.
The present invention relates generally to casino gaming, and more specifically to systems and methods for data and configuration management for game services provided to gaming machines distributed across a gaming entity.
There are a wide variety of associated devices that can be connected to a gaming machine such as a slot machine or video poker machine. Some examples of these devices are lights, ticket printers, card readers, speakers, bill validators, ticket readers, coin acceptors, display panels, key pads, coin hoppers and button pads. Many of these devices are built into the gaming machine or components associated with the gaming machine such as a top box, which usually sits on top of the gaming machine.
Typically, utilizing a master gaming controller (MGC), the gaming machine controls various combinations of devices that allow a player to play a game on the gaming machine and also encourage game play on the gaming machine. For example, a game played on a gaming machine usually requires a player to input money or indicia of credit into the gaming machine, indicate a wager amount, and initiate a game play. These steps require the gaming machine to control input devices, such as bill validators and coin acceptors, to accept money into the gaming machine and recognize user inputs from devices, including key pads and button pads, to determine the wager amount and initiate game play. After game play has been initiated, the gaming machine determines a game outcome, presents the game outcome to the player and may dispense an award of some type depending on the outcome of the game.
FIG. 1 is a block diagram depicting gaming machines distributed in different establishments partially connected by a dedicated communication network for typical gaming entities currently operating in the gaming industry. In FIG. 1, a first gaming entity 101 utilizes a central office 142. Gaming machines, 102, 104, 106, 136 and 138 operated by the gaming entity 101 are located in casino 110 and a store 140. The store 140 may be part of route comprising gaming machines distributed in such venue sites as stores, bars and other retail establishments. The gaming machines, 114, 116 and 118 for the gaming entity 150 are located in casinos 122. A gaming entity may operate hundreds, thousands or ten of thousands of gaming machines. Since gaming is allowed in many locations throughout the world, the two casinos, 110 and 122, the central office 142 and the store may be distributed over a wide geographic area. For instance, the casino 110 may be located in Atlantic City, N.J., the casino 122 may be located in Australia, the central office may be located in Las Vegas, Nev. and the store may be located in Reno, Nev.
In some cases, the gaming entities, 101 and 150, may exchange information in some manner. For instance, a player may be issued a cashless instrument at casino 122, such as an award ticket valid for game play, and the player may then utilize the award ticket at casino 110. In this example, gaming entity 150 may transfer resources to gaming entity 101, in some manner, to cover a value of the cashless instrument used by the player. The server 124 may be used to generate reports summarizing the performance of all the gaming machines within the gaming entity (e.g. casino 110, casino 122 and store 140). The reports may be accessed locally using the local access points 126 and 128 via the local network. In addition, reports may be remotely accessed using a dial in number for a limited number of users. For instance, an executive traveling on the road might view gaming machine performance data from a remote access point 134, where the remote access point 134 may be a hotel room.
Within the gaming industry, there is some desire to provide centralized network gaming services, centralized data access, centralized data analysis, centralized configuration management and centralized data acquisition to all of the gaming machines or a larger proportion of gaming machines within a gaming entity. The centralization may be provided at both the casino level and the corporate level as a means of lowering information management costs and optimizing gaming performance. A current barrier to providing the centralized services, described above, is the complexity and costs of obtaining and managing large amounts of information from a large variety of gaming machines some of which may be dynamically configurable. Further, within the gaming industry, game performance information has traditionally been closely guarded and has not been widely shared even within a gaming entity. Thus, mechanisms for data sharing on a large scale have not been generally implemented in the gaming industry. In addition, once the data is obtained, another barrier is analyzing the information and applying it in a manner that is both useful and convenient to users within the gaming entity.
In view of the above, it would be desirable to provide hardware and methods for data sharing, data analysis and configuration management for gaming machines that reduce the complexity of the information management environment. Also, it is desirable for the hardware and methods to be scaleable to a large number of gaming machines and machine operators where the gaming machines and machine operators are widely distributed within a gaming entity.
Successful solutions to the foregoing problems, however, can result in further issues related to such solutions. For example, the foregoing related parent and sibling applications provide for a central gaming terminal data repository and support system adapted for a number of useful purposes, such as the remote configuration and downloading of games and other software components to gaming machines. Such remote downloading and control of gaming machines can result in changes that may affect a number of significant items, including game play related elements, such as, for example, paytables, game denominations, presentation speeds, machine return or cash throughput, and the like.
Many gaming jurisdictions, however, require notices to the public and/or actual gaming machine players with respect to various gaming machine elements, such as paytables. Thus, changes to a number of gaming machine items, such as paytables, for example, may result in a violation of one or more gaming laws or regulations where an appropriate notice regarding any new information is not provided to a player of the gaming machine. Such changes might be particularly problematic where they occur during a single gaming session by a single player. Even where the player is the one who is responsible for such changes, such as by requesting and downloading a new game during a single gaming session, there may be problems presented by changes to various gaming machine parameters or components for which there are laws or regulations regarding the posting of information.
Accordingly, it would be desirable to provide additional hardware, software and/or methods for meeting the various notice requirements to players and the public with respect to gaming machine parameters and items that change. In particular, such provisions should be capable of ensuring that appropriate notices are provided with respect to any significant gaming machine changes that occur during a single gaming session by a single player.
It is an advantage of the present invention to provide systems and methods for ensuring that appropriate player and public notices are given whenever conditions in a gaming machine are significantly changed. This can be accomplished by providing a player compliance module, which operates to identify when a significant aspect of gaming machine operations has changed, to provide appropriate player or public notice of such a change, and to attend to the recording or logging that such an appropriate notice has been made. The resulting systems then permit casinos or other gaming operators to provide dynamic notices at their gaming machines to players with respect to any significant changes that take place in the gaming machines.
According to various embodiments of the present invention, the provided system can include a gaming terminal data repository that may be used to store game software components, game software component information and gaming transaction information for a plurality of gaming terminals owned by a plurality of gaming entities. The repository may store the game software component information and the gaming transaction information in a database partitioned according to the different gaming entities in a manner allowing a game software component configuration of a particular gaming machine to be easily analyzed and modified. Using various update triggers, game software components for gaming machines connected to the gaming terminal data repository may be automatically updated. The gaming terminals, configured or designed to receive game software components from the repository, may present game play using a combination of game software components residing on the gaming machine and the game software components received from the repository.
In particular embodiments, the method may also include one or more of the following: a) prior to sending the game software components, contacting a local ISP and sending the game software components via the local ISP, b) looking up an IP address of the one or more gaming machines, c) encapsulating the game software components in multiple information packets, d) encrypting the game software components, e) generating instructions for configuring the game software components and sending the instructions with the game software components, f) requesting game software component version information from the gaming machines, g) receiving game software component version information from the gaming machine, h) receiving game transaction information from the gaming machines and storing the game transaction information according to one or more game data categories where the game data categories are selected from the group consisting of game version data, game data, gaming terminal data, player data, route data and venue data, i) prior to storing said game transaction information, determining access privileges for said game transaction information; j) prior to storing said game transaction information, performing one or more operations on said game transaction information, k) determining a data storage partition from among a plurality of data storage partitions for storing said game transaction information where the plurality of data storage partitions correspond to a plurality of gaming entities, and l) checking a list of update triggers where the update triggers are selected from the group consisting of an update time, an update day, an update week, a game event, a game performance event and a player input.
Still further embodiments can include gaming systems, gaming machines and methods involving a player compliance module (PCM). Such a PCM can be in the form of software located either within the gaming machine, gaming terminal, GTDR or elsewhere within the system. The PCM can be unalterable, and can comprise software adapted to facilitate both the detection of changed operational conditions and the provision of information to players regarding such changed operational conditions. Such changed operational conditions can be related to games or other items presented at a respective gaming machine or terminal, and can include new or modified games, downloads, paytables, game denominations, presentation speeds, payback percentages, game holds, harm minimization factors or items, among other conditions.
Player notices or other information provided can include: a) full displays disclosing all details of all changed operational conditions, b) informational notices having a limited level of detail regarding any least changed operational conditions, and/or c) minimalist alerts that one or more changes have taken place, with such alerts having little to no detail regarding the changes. The notices or information provided to can comprise content sufficient to satisfy a player notice requirement or regulation of a gaming jurisdiction where the gaming terminal is located. Notices or other information can be in the form of fully or partially pre-rendered message frames, with such frames being more readily traceable with respect to tracking and record or log creation.
The PCM can also be adapted to facilitate the creation of a record or audit trail containing details regarding any changed operational conditions and any provision of notices to players regarding the changes. Such records can be kept in a log, record base or other storage location, such as at a GTDR. Further provisions can also be used to prevent any game of chance from being played at a respective gaming terminal while information or a notice regarding an operational change remains displayed at the gaming terminal. An affirmative player input might also be required to remove such a notice or information, such that a better record is created of the player having been presented with such notice and accepting such a change.
General methods of providing dynamic player notices at a gaming terminal can include the steps of accepting a communication from a remotely located and independent network device, such as a GTDR, detecting a significant operational change at the gaming terminal resulting from the communication, associating the significant operational change with a dynamic player notice having an adequate amount of information regarding the operational change, and displaying the dynamic player notice at a display located at the gaming terminal. Further steps can include recording details regarding the operational change and display of the dynamic player notice to a saved record or log, as well as providing a PCM adapted to perform or facilitate the performance of one or more of the method steps, such as those for detecting, associating and displaying. Still further steps can include prompting a player to provide an affirmative player input to remove the dynamic player notice, and preventing the play of any wager based game at the gaming terminal until such affirmative player input is provided.
The included drawings are for illustrative purposes and serve only to provide examples of possible structures and elements for the disclosed gaming terminal data repository and information distribution systems and methods. These drawings in no way limit any changes in form and detail that may be made to the invention by one skilled in the art without departing from the spirit and scope of the invention.
FIG. 7 is a flowchart depicting a method of updating game software components on a gaming machine using a remote server.
FIG. 8 is a flowchart depicting a method, in a remote server, of modifying game play on a plurality of gaming machines.
FIG. 9 is a flowchart depicting a method of accessing game transaction information on a partitioned database storing data from multiple different game entities.
FIGS. 10A and 10B are exemplary paytables that can be associated with a given gaming machine or terminal.
FIGS. 11A through 11C are screen shots of exemplary pre-rendered frames for providing displays, notices and alerts to players regarding operational changes of gaming machines or terminals.
FIG. 12 is a flowchart depicting one method of providing players with dynamic notices regarding operational changes to gaming machines or terminals.
In general, the present invention relates to systems and methods for providing adequate notices to players when significant gaming machine or gaming terminal conditions change, such as through the download or changing of games on the gaming machine or terminal. Such systems and methods are desirable for a wide variety of reasons, including the ability to meet legal requirements related to providing notice to players, as well as to protect the gaming operator from claims of fraud or unfair gaming practices by players who experience such changes at a gaming machine or terminal. To this end, the provided systems and methods can include a variety of items designed to detect changes, provide informational displays, notices and alerts to players regarding the changes, and to create an audit trail verifying that such dynamic player notices were provided and the details thereof.
Gaming Terminal Data Repositories
The gaming terminals 218, 220 and 222 may send game transaction information, such as coin-in and coin-out, game software component information, such as the versions of software residing on each gaming terminal and the version of a game being played, and player tracking information, such as the identity of a player playing a game on the gaming machine. The gaming terminals 218, 220 and 222 may send and may receive information directly from the GTDR 200 or the gaming terminals may communicate with the GTDR 200 via an intermediate device such as a cashless system server. Information received from the gaming terminals may be archived in the gaming terminal database 210 on the GTDR. In addition, the GTDR 200 may poll various servers such as bonus game servers, cashless system servers, progressive game servers for gaming information that may stored in the gaming terminal database 210.
The GTDR 200 may communicate with the gaming terminals, 218, 220 and 222 and other remote gaming devices, such as portable computers, printers, personal digital assistants and computers located at various gaming venues, using the network interface 208. The network interface 208 may be a wireless network interface or wired network interface. The GTDR 200 may utilize a firewall 209 to prevent unauthorized access to data stored in the GTDR 200. Access firewalls may be those provided by Cisco Systems of San Jose, Calif.
The large amount data and variety of game programs on each gaming terminal may be managed using the data and program management tools of the GTDR 200. Each game program may comprise of plurality of game software components. In FIG. 2, each of the items may be associated with a particular gaming terminal or associated with a type of gaming terminal. The items may be organized in a database structure of some type that may be extended to a large number of gaming terminals. Many different types of database structures are possible. Some examples of database structures that may be utilized are described in the text: “Database Management Systems,” by R. Ramakrishnan, Mcgraw-Hill, which is incorporated herein by reference in its entirety and for all purposes.
The associations between gaming terminal database elements and the gaming terminals may be managed and leveraged with specific GTDR 200 tools that utilize information that may be stored in the data repository such as within a database structure of some type. For instance, the system may be used to establish relationships between users, terminal information, site information, and gaming terminals. With a given set of relationships established using the system, the casino operator may then identify the configuration desired of a particular gaming terminal or groups of gaming terminals. An example of the structure, relationships and types of information that may be stored in a data partition 216 for a particular gaming entity is shown in FIG. 2. The example is used for illustrative purposes as many different structures are possible and additional gaming information may be stored in the database 210.
The data categories 260 may be used to store commonly accessed data combinations to minimize analysis times. Many different combinations of game transaction information and other game information for various groups of gaming terminals may be stored in the gaming terminal database 210 as a queryable database. Other examples of game data categories may include: 1) gaming terminal data 250, which may be a history of game performance on a particular gaming terminal for all of its past configuration, 2) player data 252, which may be a composite of a player's game play on many different gaming terminals, 3) route data 254 which may be a composite of gaming terminal information for a group of gaming terminals on a route comprising a number of gaming venues such as stores, and 4) venue data 255 which may be a composite of terminal information for a groups of gaming terminals at a particular venue such as a casino, a subset of gaming terminals within a casino, a store or a restaurant. Again many types of data categories may be possible. The number of potential data categories may depend on the number of fields associated with each data record obtained from a gaming terminal and a processing power of the GTDR 200, because too many data categories may result in a degradation of search performance on the GTDR 200.
The processor and memory 206 on the GTDR 200 may be used to execute a number of analysis tools 270 (e.g., gaming repository applications) residing in each data partition, including 212, 214 and 216 in the gaming terminal database 210. The gaming repository applications 270 as well as the game transaction information and game software components stored in the gaming terminal database 210, may be proprietary and in some cases may not be shared by different gaming entities. The analysis tools 270 may utilize a number of user interfaces such as graphics tools for presenting data generated in each application. For instance, an interface may display the current game software components on a gaming terminal as highlighted in a list of game software components available on the gaming terminal. These interfaces may be viewed on displays, including 202, or remote computers which are connected to the GTDR 200.
The gaming repository applications 270 may include: 1) data analysis applications 272, which may be used to establish data categories and various relationships between data categories, 2) version management tools 273, which may be used to identify the game software components on a particular gaming terminal and then update one or more game software components by downloading game software components from the GTDR 200, 3) configuration and scheduling tools 274, which may be used to automatically configure one or more gaming terminals according to one or more scheduled update triggers, 4) query configuration application, which may be used to design query relationships in the database that are suited to a particular users needs, and 5) report generation applications for formatting game transaction information. The gaming repository applications 270 are not limited to these applications, and many types of gaming repository applications are possible.
Data from the various applications executed on the GTDR 200 may be shared and utilized by other applications. For instance, the data analysis tools 272 may be used to establish relationships between game versions, game transaction information, site information and gaming terminal information. The relationships may be utilized by the configuration application 274 to establish configurations for one or more gaming terminals. The configuration application may identify the current set of game software components used for game play on a particular gaming terminal and then compare the identified software components with game software components required for a new game configuration (e.g., a plurality of game software components are used to present a game presentation on each game presentation). The result of the comparison may be a list of game software components that need to be updated on the gaming terminal to enable the new game configuration. Configuration management tool 274, which is executed by the processor 206, may then download the game software components required for the new game configuration to the gaming terminal via the network interface 208. A similar process may be used by the software version management to update versions of software residing on one or more gaming terminals.
The scheduling tools may be used to automatically update the configurations of one or more gaming terminals according to a number of update triggers. Updates might be triggered at certain times, such as hourly, daily or weekly, according to player input, or according to game performance. For instance, when a game is performing poorly on a gaming terminal, game software components to enable a new version of the game being played or a different game may be downloaded to the gaming terminals connected to the GTDR 200. The gaming performance of the gaming terminals may be monitored by the GTDR 200 so that the download may be performed automatically. As another example, different paytables may be downloaded to different gaming terminals at specific times of the day to encourage game play during off-peak hours or increase profits during peak hours. In yet another example, the GTDR may download new game software components to a particular gaming terminal being utilized by a particular player. The download may occur as a result of a data analysis indicating personal game playing preferences of a particular player such as liking particular sounds or graphics. The download may occur automatically without being initiated by the player or may be initiated by the player.
In the past, new games have been installed in gaming machines by exchanging an EPROM in the gaming machine containing all of the gaming software, or by downloading an entire game software package. In these examples, all the gaming software on the gaming machine is exchanged whether or not it is different from the new gaming software. An advantage of only downloading specific game software components is that it allows for faster downloads when only a small fraction of the gaming software is being updated. Also, in many cases, the gaming machine may continue to operate while the download is implemented. When all of the gaming machine software is downloaded, the gaming machine may have to brought down for the installation. Further, for a game with many different versions where the variation from version to version may be small, it is more efficient to manage and store the individual game software components rather than many different game software versions with each version comprising all of the game software components.
The game system components 224 may comprise software modules used to provide various system functions on the gaming terminal. For instance, the event manager 312 may be used to monitor and distribute events occurring on the gaming machine such as card-in, card-out, power hit and tilt. The bank manager 315 may be used to perform accounting functions on the gaming terminal. The communication manager 316 may be used to provide communication protocols allowing different gaming devices to communicate with the gaming terminal such as player tracking devices. Another example of gaming system components might include device drivers allowing the gaming system software to communicate with various devices connected to the gaming terminal such as displays, bill validators, ticket readers, coin acceptors, card readers and printers. Details of game system components that may be used in the present invention are described in co-pending and commonly owned U.S. patent application Ser. No. 09/642,192 by LeMay, et al., filed Aug. 18, 2000, and entitled “Gaming Machine Virtual Player Tracking and Related Services,” which is incorporated herein by reference in its entirety and for all purposes.
The game bonusing 228, which may be downloaded to a gaming terminal, includes bonus game peak 332, bonus game off-peak 334, bonus game promotion 336 and bonus game test 338. A large variety of bonus games are possible. The bonus game peak and bonus game off-peak may have been selected based upon game performance data stored on the GTDR. The bonus game test 338 may be downloaded to gather gaming performance data on a particular bonus game, such as, for example, to try out a new bonus game that has been developed.
Specific update triggers may be determined based upon a demographic analysis of game performance data (e.g., game transaction information) and user data (e.g., player tracking information) stored in the GTDR. The demographic analysis may be performed using software executed on the GTDR. The software may indicate that certain groups of individuals are more likely to play certain types of games at certain times of day. Thus, update triggers may be developed and implemented on the GTDR that configure gaming terminals with certain games at certain times corresponding to the preferences of a particular demographic group.
The game software components 300 listed in FIG. 3 may appear to the operator as a menu on a display screen where the current game software configuration of the gaming terminal is highlighted in some manner. For instance, a current game software configuration may comprise: 1) a first versions of the event manager 312, bank manager 314, and communication manager 316, 2) a bonus peak game 332, 3) a red dynamic background 344, 4) easy music 354, 5) a game only progressive 362, and 6) a Nevada gaming jurisdiction configuration. The current game software configuration may be highlighted on the screen as a particular color. By pointing to the screen using a mouse or some other device, an operator may highlight particular boxes to adjust the configuration of a particular gaming terminal or a group of gaming terminals. In addition, the menu may include configuration templates corresponding to a number of gaming terminal configuration options that may be selected by the operator. These templates may be proprietary and based upon an analysis of game performance data available to a particular gaming entity.
GTDR Networks
FIG. 4 is a block diagram of venues and route sites with gaming terminals connected to a gaming terminal data repository. In FIG. 4, gaming machines, 465, 466, 467, 468, 469, 475, 476, 477, 478, and 479, reside in the casino 405, gaming terminals, 419 and 420, in the bingo parlor 418, gaming machines, 437 and 438, in the store 436, a remote user 402, and gaming terminals, 443 and 444, in the restaurant are connected to a GTDR 410 located in the casino 405. The gaming machines and gaming terminals are connected to the GTDR 410 via local area networks, via the Internet 490 and via a secure private intranet 446. In FIG. 4, the communication connection configuration represents one of many potential connection schemes possible with the present invention. Also, the GTDR 410 may be located other locations besides the casino 405. For instance, the GTDR could be located in a separate location containing the GTDR and its support infrastructure or the GTDR might be located in a corporate headquarters for a particular gaming entity.
There are many ways in which IP VPN services may be implemented, such as, for example, virtual leased lines, virtual private routed networks, virtual private dial networks, virtual private LAN segments, and so forth. Additionally, VPNs may be implemented using a variety of protocols, such as, for example, IP Security (IPSec) Protocol, Layer 2 Tunneling Protocol, Multiprotocol Label Switching (MPLS) Protocol, and the like. Details of these protocols including RFC reports may be found from the VPN Consortium, an industry trade group (http://www.vpnc.com, VPNC, Santa Cruz, Calif.). Details of VPNs and related communication methods that may be used in the present invention are described in co-pending and commonly owned U.S. patent application Ser. No. 09/732,650 by Nguyen, filed Dec. 7, 2000, and entitled “Secured Virtual Network In a Gaming Environment,” which is incorporated herein by reference in its entirety and for all purposes.
In some embodiments, the GTDR 410 may be combined with an existing remote server and may use an existing intranet utilized by the remote server for communicating with a number of gaming terminals. For instance, in one embodiment, the GTDR 410 may be combined with a cashless system server, such as an EZ Pay® system server by IGT of Reno, Nev., to provide both cashless system functions and GTDR functions as previously described. In the following paragraphs, the cashless system functions and connection scheme, which may be incorporated into a combined GTDR and cashless system, are described.
Components of a cashless system may include: 1) data acquisition hardware, 2) data storage hardware, 3) cashless instrument generation and validation hardware (e.g., printers, card readers, ticket acceptors, validation terminals, and so forth), 3) auditing software, 4) cashless instrument validation software, and 5) database software. Many types of cashless systems are possible and are not limited to the components listed above or embodiments such as the EZ Pay® ticket voucher system. Typically, a cashless system is installed at each property utilizing cashless instruments. To allow multi-site validations of cashless instruments, the cashless systems at each property may be linked to a cashless instrument transaction clearinghouse. Using the cashless instrument clearinghouse, the GTDR 410 may obtain gaming transaction information from multiple gaming entities.
Returning to FIG. 4, a first group of gaming machines, 465, 466, 467, 468, and 469 is shown connected to a first clerk validation terminal (CVT) 460 and a second group of gaming machines, 475, 476, 477, 478 and 479 is shown connected to a second CVT 470. All of the gaming machines print ticket vouchers, which may be exchanged for cash or accepted as credit of indicia in other gaming machine located within the property 405. In this example, the ticket voucher serves as a cashless instrument. In addition, the gaming machines may contain smart card readers for reading voucher information stored on smart cards.
The CVTs, 460 and 470, store cashless instrument transaction information corresponding to the outstanding cashless instruments, including ticket vouchers, smart cards and debit cards, that are waiting for redemption. In addition, cashless instrument transaction information may be stored in a cashless server and GTDR including the GTDR 410. The cashless instrument transaction information may be used when the vouchers are validated and cashed out or redeemed in some manner. The CVTs 460 and 470 may store the information for the ticket vouchers printed by the gaming machines connected to the CVT. In addition, the CVTs 460 and 470 may store the information for vouchers stored on a smart card or other types of cashless instruments that were generated on each gaming machine. For example, CVT 460 stores voucher information for vouchers issued by gaming machines 465, 466, 467, 468, and 469.
In this embodiment, when a player wishes to cash out a voucher, the player may redeem vouchers issued from a particular gaming machine at the CVT associated with the gaming machine or any other CVT which is part of the cashless system associated with the CVT. For example, since CVT 460 and CVT 470 are connected as part of a single cashless system to the GTDR 410, a player may redeem vouchers or utilize vouchers at the gaming machines, the CVTs (460 or 470), the cashiers (425, 430, 435, and 440) or the wireless cashiers 458. The CVTs, cashiers, wireless cashiers and gaming machines may be referred to as “cashless validation sites.”
Using the cashless system network, multiple groups of gaming machines connected to CVTs are connected together in a cross validation network 445. The cross validation network is typically comprised of one or more concentrators 455, which accepts inputs from two or more CVTs and enables communications to and from the two or more CVTs using one communication line. The concentrator is connected to a front end controller 450, which may poll the CVTs for voucher information. The front end controller is connected to GTDR 410, which may provide a variety of information services for the cashless system, including accounting 420, administration 415, as well as GTDR functions such as downloading game software components to the various gaming machines connected to the system.
As cashless instruments are validated, the information may be sent to audit services computer 440 providing audit services, the accounting computer 420 providing accounting services, or the administration computer 415 providing administration services. In another embodiment, all of these services may be provided by the GTDR 410. Examples of auditing services, which may be provided by the GTDR 410 include: 1) session reconciliation reports, 2) soft count reports, 3) soft count verification reports, 4) soft count exception reports, 5) machine voucher status reports, and 5) security access report. Examples of accounting services, which may be provided by the GTDR 410, include: 1) voucher issuance reports, 2) voucher liability reports, expired voucher reports, 3) expired voucher paid reports, and 4) voucher redemption reports. Examples of administration services, which may be provided by GTDR 410, include: 1) manual voucher receipt, 2) manual voucher report, 3) voucher validation report, 4) interim validation report, 5) validation window closer report, 6) voided voucher receipt, and 7) voided voucher report.
In FIG. 5, all of the information and applications available on the GTDR may be accessible to a site supervisor 500. Members of the systems users group 502, which may include the site supervisor 500, may have site supervisor privileges for the entire GTDR or may have site supervisor privileges for one or more data partitions within the GTDR. The members of the systems users group typically manage the GTDR system functions and applications. For instance, members of the system user group 502 may allocate the size of partition, may perform backups and may provide application troubleshooting. Under the site supervisor group 500, a number groups relating to gaming entities, including an entertainment corporation group 505 and an entertainment corporation group 510, may reside. Gaming transaction information and repository applications, which may be proprietary to each gaming entity, may be stored in a separate data partition on the GTDR. For instance, a first data partition may be allocated to the gaming entity corresponding to the entertainment corporation group 505 and a second data partition may be allocated to the gaming entity corresponding to the entertainment corporation group 510. The number of groups and access privileges may vary from gaming entity to entity. The number of groups and the hierarchical group relationships may depend on the number of venues in the gaming entity, such as the number of casinos, information access policies formulated by each gaming entity and the types of group access privileges available on the GTDR. Many examples of group hierarchies are possible and are not limited to the example in FIG. 5.
FIG. 6A is a perspective drawing of a gaming machine 600 having a top box 606 and other devices. Gaming machine 600 includes a main cabinet 604, which generally surrounds the machine interior (not shown) and is viewable by users. The main cabinet includes a main door 608 on the front of the machine, which opens to provide access to the interior of the machine. Attached to the main door are player-input switches or buttons 632, a coin acceptor 628, and a bill validator 630, a coin tray 638, and a belly glass 640. Viewable through the main door is a video display monitor 634 and an information panel 636. The display monitor 634 will typically be a cathode ray tube, high resolution flat-panel LCD, or other conventional electronically controlled video monitor. The information panel 636 may be a back-lit, silk screened glass panel with lettering to indicate general game information including, for example, a game denomination (e.g. $0.25 or $1). The bill validator 630, player-input switches 632, video display monitor 634, and information panel are devices used to play a game on the game machine 602. The devices are controlled by circuitry (e.g., the MGC and associated devices) housed inside the main cabinet 604 of the machine 602. Many possible games, including mechanical slot games and video games of chance including video slot games, video poker, video black jack, video pachinko, video card games, video bingo, video keno, video checkers and video lottery, may be provided with gaming machines of this invention.
The gaming machine 602 includes a top box 606, which sits on top of the main cabinet 604. The top box 606 houses a number of devices, which may be used to add features to a game being played on the gaming machine 602, including speakers 610, 612, 614, a ticket printer 618 which prints bar-coded tickets 620, a key pad 622 for entering player tracking information, a florescent display 616 for displaying player tracking information and a card reader 624 for entering a magnetic striped card containing player tracking information. The ticket printer 618 may be used to print tickets for a cashless ticketing system. Further, the top box 606 may house different or additional devices than shown in FIG. 6A. For example, the top box may contain a bonus wheel or a back-lit silk screened panel which may be used to add bonus features to the game being played on the gaming machine. As another example, the top box may contain a display for a progressive jackpot offered on the gaming machine. During a game, these devices are controlled and powered, in part, by circuitry (e.g., the MGC) housed within the main cabinet 604 of the machine 602.
Returning to the example of FIG. 6A, when a user wishes to play the gaming machine 602, he or she might insert cash through the coin acceptor 628 or bill validator 630. Additionally, the bill validator may accept a printed ticket voucher, which may be accepted by the bill validator 630 as indicia of credit when a cashless ticketing system is used. At the start of the game, the player may enter playing tracking information using the card reader 624, the keypad 622, and the florescent display 616. Further, other game preferences of the player playing the game may be read from a card inserted into the card reader. During the game, the player views game information using the video display 634. Records of these transactions may be transmitted from the gaming machine 600 to a GTDR.
During the course of a game, a player may be required to make a number of decisions, which affect the outcome of the game. For example, a player may vary his or her wager on a particular game, select a prize for a particular game selected from a prize server, or make game decisions that affect the outcome of a particular game. The player may make these choices using the player-input switches 632, the video display screen 634 or using some other device which enables a player to input information into the gaming machine. In some embodiments, the player may be able to access various game services such as concierge services and entertainment content services using the video display screen 634 and one or more input devices.
During certain game events, the gaming machine 602 may display visual and auditory effects that can be perceived by the player. These effects add to the excitement of a game, which makes a player more likely to continue playing. Auditory effects can include various sounds that are projected by the speakers 610, 612, 614. Visual effects can include flashing lights, strobing lights or other patterns displayed from lights on the gaming machine 602 or from lights behind the belly glass 640. After the player has completed a game, the player may receive game tokens from the coin tray 638 or the ticket 620 from the printer 618, which may be used for further games or to redeem a prize. Further, the player may receive a ticket 620 for food, merchandise, or games from the printer 618.
FIG. 6B is a block diagram of components within a gaming machine 600 that may be used with the present invention. The game software components may be game system components (e.g., communication protocols, device drivers, event managers, and the like), game paytables, game bonusing, game graphics, game sounds, game progressives, game jurisdiction information and game networking. For example, the device drivers may allow communication between the MGC 650 and a number of devices controlled by the MGC, including the bill validator 630, the coin acceptor 628, the card reader 624 and the speaker 614. The game software components may be stored on a CD accessed using a CD-drive 674, a hard drive 655, a hard drive with a game software component partition 672 or other types of memory (not shown), including an EPROM, a flash memory, a ROM, a RAM, a DVD, a tape drive or non-volatile memory. In addition, game software version information corresponding to game software components stored on the gaming machine may also be stored in a memory of some type on the gaming machine.
The MGC 650 may utilize processor logic to combine various game software components, as previously described, to present a game on the gaming machine. To alter the game play on a gaming machine, the MGC 650 may receive game software components from a remote server such as a GTDR. For instance, using a first combination of game software components on the gaming machine, the MGC may present a game presentation with a particular set of graphics and sounds. As described with reference to FIGS. 3 and 4, game software components with new graphics and new sounds may be downloaded to the gaming machine from the GTDR. The MGC 650 may combine game software components from the first combination with the new graphical game software components and the new audio game software components to create a second combination of game software components. The second combination of game software components may be used to present a game on the gaming machine with the new graphics and sounds. Thus, as different game software components are downloaded from the GTDR, different combinations of game software components allowing different game play features may be generated by the MGC 650.
The MGC may communicate with a remote server, such as a GTDR, via a network interface on the main communication board 660 and the LAN 615. The LAN 615 may be an intranet, such as a casino area network, a cashless system network, a progressive game network, an accounting network and a bonus game network, or a wide area network, such as the Internet. To establish communications between the gaming machine 600 and the remote server, a wireless communication interface 670 such as a wireless modem connected to an antenna, or a wired communication interface, such as wired modem 676 connected to a phone line or Ethernet connection, may be used. To enable communications between the remote server and the gaming machine, a communication protocol such as TCP/IP may be used.
Illegal access to the gaming machine 600 may be prevented using the internal firewall 665. The internal firewall 665 is designed to prevent someone such as a hacker from gaining illegal access to the gaming machine and tampering with it in some manner. For instance, an illegal access may be an attempt to plant a program in the gaming machine that alters the operation of the gaming machine or allows someone to steal data. Firewalls used in the gaming machine may be provided by Cisco Systems of San Jose, Calif.
General GTDR Methods
FIG. 7 is a flowchart depicting a method of updating game software components on a gaming machine using a remote server 700. In 705, communications are established with the remote server, which may be a GTDR. The communications may be initiated by the gaming machine or by the remote server using an appropriate communication protocol such as TCP/IP. The gaming machine may establish communications with the remote server by contacting an ISP to establish an Internet connection. In 710, the gaming machine may send game software component information, such as a list of game software components currently being used on the gaming machine, a list of game software components stored on the gaming machine or game software component version information, to the remote server. In 715, the gaming machine may receive one or more game software components from the remote server where a plurality of game software components are used to present a game on the gaming machine. The game software components may include game system components, game paytables, game bonusing, game progressives, game graphics, game sounds, game jurisdiction information and game networking components.
FIG. 8 is a flowchart depicting a method, in a remote server, of modifying game play on a plurality of gaming terminals 800. In 805, the remote server may check a list of update triggers that have been set for a particular gaming terminal. Many possible update triggers may be set for each gaming terminal. For instance, the update triggers may be an update time, an update day, an update week, a game event, game terminal performance criterion or a player input. A particular update may be also triggered by a combination of update triggers. For example, a game event during a certain period of time during the day may trigger an update of a game software component containing a paytable for a gaming machine.
FIG. 9 is a flowchart depicting a method 900 of accessing game transaction information on a partitioned database storing data from multiple different gaming entities. In 905, the remote server may receive a request for gaming transaction information from a gaming device such as a gaming machine or a remote computer. The gaming transaction information request may be generated from an application executed by the user on the remote server or on the gaming device. For example, the information request may be from a remote user operating from a remote computer. In 910, the remote server may verify the identity of the gaming machine and/or a user requesting the information. Thus, verification process may be based upon a password, biometric information such as fingerprint or combinations of both password and biometric information.
In 915, when the identity of a user has been verified, the remote server may determine the access privileges of the user, such as the access privileges of a user group assigned to the user. The access privileges may be delegated according to hierarchical groups, as described with reference to FIG. 5. In 920, the remote server may compare access privileges assigned to the user with an access privilege needed for the information request. In 922, when the user does not have sufficient access privileges, access to the gaming transaction information is denied. In 925, when the user has sufficient access privileges, the remote server generates the requested data. To generate the requested data, the remote server may have to retrieve the gaming information from one or more memory locations and perform one or more operations on the gaming information. The retrieval process may require searching a queryable database.
Dynamic Player Notices
While it may be possible to download new games or other software and/or otherwise modify a gaming machine or terminal from a remote location, such as by using a GTDR, such changes can affect the various public notices that must or should be made to a player, or at least be made available to a player, at the gaming machine or terminal. As noted above, various gaming machine or terminal changes, such as those in paytables, game denominations, presentation speeds, and the like, may affect the return or cash throughput on a gaming machine, and thus the gaming experience of a player. As such, it may be preferable, or even required by law, to provide appropriate notice to a player of any such significant change, particularly where the subject matter of the change concerns items for which notice is already required. Such dynamic player notices can be made in a variety of ways, such as by full disclosure displays, limited informational notices, and simple alerts notifying the player that one or more changes have taken place. Although the terms “displays,” “notices” and “alerts” are used herein in the context of informational items to players having, respectively, full, limited and no details, such terms can be used interchangeably to reflect any form of dynamic player notice regarding changed conditions in a gaming machine or terminal.
As one example of a significant gaming machine item or parameter for which changes should be noticed, many gaming jurisdictions currently require that a paytable covering the various payouts and/or other game outcomes for the game being played on the gaming machine or terminal be displayed or at least be made player accessible. Any change in a paytable may thus result in a requirement or at least a desire to fairly alert the player to such a paytable change. FIGS. 10A and 10B provide exemplary paytables that can be associated with a given gaming machine or terminal. For purposes of illustration, FIG. 10A depicts a paytable 1000 for a “Cherries Galore” game theme. Various reel symbols may be present for such a game, such as, for example, cherries, bars, coins and blanks, among others. As is generally known in the art, various winning paylines 1001 comprising combinations of one or more winning reel symbols can result in a game “win” and payout to the player. As shown in the “Cherries Galore” game of FIG. 10A, such winning paylines can include three cherries resulting in a win of 1000 coins, 2 cherries and a bar resulting in a win of 500 coins, and so forth, down to a single coin in the first reel position resulting in a win of 1 coin. As is also generally known in the art, such a paytable 1000 can be implemented on a per coin multiple basis, such that the paytable shown represents the payouts for 1 coin wagered, and the payouts for multiple coins wagered can simply be that which is shown in paytable 1000 multiplied by the number of coins wagered. For example, if a player were to wager 5 coins and then receive a game outcome including three cherries on a single payline, the win to that player could be 5000 coins.
Moving next to FIG. 10B, a paytable 1010 for an exemplary “Sevens Wild” game theme is shown. Such a game theme might also be made available on the same gaming machine or terminal that is adapted to provide the “Cherries Galore” themed game including the paytable in FIG. 10A. For example, a single gaming machine 602 might be adapted to play both a Cherries Galore game and a Sevens Wild game, among other possible games. As noted above, such a gaming machine or terminal might be adapted to store both games at the machine or terminal, or could be connected to an overall gaming network adapted to provide downloadable games to the gaming machine or terminal, such as via a GTDR. Similar to the “Cherries Galore” game of the foregoing example of FIG. 10A, the “Sevens Wild” game can include a variety of reel symbols, such as moons, barrels, blanks and at least four different styles of sevens, among others. Various winning combinations are depicted in paytable 1010, with a top prize being for three of the largest and boldest sevens. While the various reel symbols and the payout structures are all different between the two paytables 1000 and 1010, it will be readily appreciated that one or more similarities may exist. In fact, the game of FIG. 10A can be substantially different and independent of the game of FIG. 10B.
Whether stored together on the gaming machine or made available via downloads or other remote access devices, any switch at a given gaming machine or terminal from the “Cherries Galore” game to the “Sevens Wild” game will result in a switch from the paytable of FIG. 10A to the paytable shown in FIG. 10B. Regardless of the reason for such a game switch, a presentation and/or availability of the paytable for the new game should be made to a player. While such a presentation, a notice of paytable availability or simple change alert is preferable even where it is the player who elects to switch the game on the gaming machine or terminal, such a presentation, notice and/or alert is even more preferable where such a change is made automatically by the machine itself or some remote device, such as a GTDR. In some embodiments, a dedicated paytable button can be present on the gaming machine or terminal, such that a player can pull up an image of the applicable paytable for whatever game is being played at the simple touch of a button. In some embodiments, a dedicated secondary video screen or “virtual glass” can be used to display the applicable paytable for whatever game is being played. Examples of such a virtual glass are described in co-pending and commonly owned U.S. patent application Ser. No. 10/756,225 by LeMay, et al., filed Jan. 12, 2004, and entitled “Virtual Glass for a Gaming Machine,” which is incorporated herein by reference in its entirety and for all purposes. In still further embodiments, a temporary display of a changed paytable or notice to the player can be made at any display, such as a main display of the gaming machine or terminal. Of course, such displays, notices and alerts regarding changes can be made regarding any change, and are not limited to paytable changes.
For any of the disclosed embodiments either alone or in combination, a “player compliance module” (PCM) can be implemented to ensure that appropriate displays, notices or alerts are provided to a player or the public in general when gaming conditions change. Such a PCM can be a software module that is implemented on new gaming machines and/or added to existing gaming machines. Also, a PCM or one or more PCM components may be located at a remote network location, such as at a GTDR. In sum, a PCM can be programmed or otherwise adapted to detect when any of a number of significant operational changes occur in a gaming machine or terminal, such as, for example, a downloaded software program and/or software change, and then notify the player of such a change and/or any notable parameters that have changed as a result. While such significant operational changes may involve those made with respect to paytables, game denominations and presentation speeds, many other types of changes may also be included as those that are detected and then reported on to the player. Upon detection of a significant change or changes, the PCM would then ensure that an appropriate display, notice or alert is provided to the player. The PCM might also be adapted to log or transmit data regarding appropriate information being provided to players when such changes occur, such that an audit trail is created, as detailed below.
In some embodiments, such a PCM can be unalterable, such that it does not change when any new form of software or other programs are downloaded to a gaming machine or terminal. It may be possible in some cases to incorporate the PCM into a base operating system or other base component of the gaming machine or gaming network architecture. In any event, it may be preferable to structure the gaming machine or network architecture such that the PCM is treated as a secure module or software program, so as to protect the PCM from intrusions or alteration attempts, such as by causing a gaming machine tilt if such an attempt is detected. Because it may be desirable to implement a PCM as a stable and unalterable program module, such a PCM may reside on a ROM device, such as an EPROM, CD-ROM or other unalterable device installed within the gaming machine or system.
A display for a changed condition in a gaming machine or terminal could involve a full display of all changed conditions, such as, for example, a full paytable for a new game to be played on the gaming machine. Such a full display could be made in various ways at one or more display locations, as noted above. Alternatively, a notice might be made to the player, with such a notice possibly specifying that certain gaming conditions have just changed, a summary as to how they might have changed, and/or instructions as to how the player can access more details of such a change or changes. For example, a notice might be provided to the player that the game paytable has just changed, without providing the full paytable itself, along with instructions as to how the player can access the new full paytable. At a minimum, a simple alert can be provided to the player to let the player know that gaming machine conditions have changed. Such an alert may contain few details, and might not even have instructions in some cases. Such a minimal alert might be appropriate, for example, where the player has affirmatively elected a change, such as a player selection for a download of a new game. In such instances, a player is aware from his or her own actions that changes at the gaming machine or terminal are taking place, such that a minimal alert to the player may be a simple appropriate warning that game paytables, denominations, speed and/or other game factors may be changing due to the affirmative player decision to change games or other game conditions.
While one primary purpose of the PCM can be to make sure that proper displays and/or notices regarding changed conditions are provided to players, another function can include the creation of an audit trail to note any significant differences or changes in new or added software or game conditions, and to establish that the player or public was properly notified of such differences or changes. In the event that no player was at the gaming machine at the time of the significant change or difference, such an audit trail might include a submission noting that the gaming machine or terminal was not active at the time of the change or difference. Such a conclusion might involve, for example, a play log indicating that the last play of a game and/or input of any sort by a player to the gaming machine took place at a given amount of time before the change was made. A period of ten or fifteen minutes of idle time, for example, might be sufficient to establish that a gaming machine or terminal was not active at the time of the change, such that notice of the change was not necessary. Of course, other idle time cutoffs might also be used, such as five minutes, an hour, or otherwise, as desired. In the event that a gaming machine or terminal has indeed been idle for a set period, an established audit trail entry could simply show the amount of idle time prior to the download or other significant change, and possibly after the download or other change. When a gaming machine or terminal has been used within the designated recent time period, or an actual gaming session is active and in progress at the gaming machine, then information in the form of an appropriate display, notice, alert or the like can be provided to a player when a significant change takes place.
An audit trail entry can be created for such an informational display, notice or alert to a player. One method for establishing an audit trail can be to use pre-rendered message frames having content sufficient to satisfy any player display, notice or alert requirement or other desired informational effect. Examples involving the use of pre-rendered frames for a gaming machine can be found in commonly owned U.S. Pat. No. 6,863,608 by LeMay, et al., entitled “Frame Buffer Capture of Actual Game Play,” which is incorporated herein by reference in its entirety and for all purposes. In the context of providing appropriate player information in the form of full displays, notices, alerts and the like, such pre-rendered frames can be presented to players on one or more gaming machine or gaming terminal displays when significant changes take place, such as, for example, a paytable change. In using such pre-rendered frames for player displays, notifications and alerts, the PCM or other suitable gaming machine component could be adapted to hash each pre-rendered frame with a time stamp when it is presented. Of course, alternative ways of tagging each frame might be used, and any such hashing, tagging or recording can also involve providing various details of the frame presentation, such as the time, size, duration and location of the presentation.
Recorded data could then be sent to a central server, such as a GTDR, and the central server or other suitable network device could compare the sent hash value information with a stored hash value for each pre-rendered frame. When matched, an audit trail is established showing that a software download has occurred at a given time, place and manner, and that a particular frame or sequence of frames was shown to the player in a given manner at the affected gaming machine or terminal at or about the same time. Such information can be stored and made available later for a variety of reasons. For example, gaming auditors or internal personnel may want to verify that appropriate legal notices and alerts are being provided to players regarding changed conditions in gaming machines. As another example, proof that an appropriate notice was made to a player can be made available to rebut a player game that he or she was defrauded or cheated by changed conditions for which no notice was given.
Although a wide variety of pre-rendered frame types can be used, several exemplary frames are disclosed herein for purposes of illustration. FIGS. 11A through 11C are screen shots of exemplary pre-rendered frames for providing displays, notices and alerts to players regarding operational changes of gaming machines or terminals. Turning first to FIG. 11A, a screen shot 1100 depicts a main display of a gaming machine partitioned into various components. A main play area 1101 provides three simulated reels having reel symbols for a “Cherries Galore” themed slots games. As shown, a primary payline depicts a game result of coin-blank-coin, which would result in an even money payout according to the exemplary paytable for this game provided herein. A pre-rendered frame 1102 displaying the full paytable for the Cherries Galore game is prominently displayed in one section of main display screen shot 1100. The other partitioned portions of the main display include a player information area 1103 and a credit meter and/or other meter area 1104. While the main display of screen shot 1100 is shown as partitioned in the manner shown, it will be readily appreciated that a virtually infinite number of partition designs can be had, including other arrangements and other partition portions, and that not all partition portions shown need be present.
Further, although shown as part of the main display, it will be readily appreciated that full paytable pre-rendered frame 1102 could be shown at a secondary or tertiary screen, virtual glass, or other suitable gaming machine or terminal location, as may be desired. Also, full paytable pre-rendered frame 1102 might be displayed permanently, or might be shown for a set time period or number of game plays, after which the main screen 1100 might be reconfigured either automatically or by player option such that the paytable is either removed or diminished in prominence. Such options might also attach to any other location where full paytable pre-rendered frame 1102 might be located. In some embodiments, fully detailed display frame 1102 might be displayed prominently for a set time period at one location, such as that which is shown for main display 1100, after which it is relocated to a less prominent location on the main display or elsewhere on the gaming machine or terminal. Such a secondary location might also display the paytable in a similar manner, either permanently or for an extended period of time. For example, frame 1102 might be displayed as shown on the main display 1100 and also at a secondary screen for the first five minutes or the first ten plays of the new game on the gaming machine or terminal. After the set time period or set number of game plays, which can be any amount of time or number of game plays, frame 1102 might be removed from main display 1100 but remain at the secondary location. In any event, when frame 1102 is shown, a record of the frame showing can be created, with such a record including a specific frame ID, hash, time, duration, location(s) and other display details, as may be desired.
Moving next to FIG. 11B, a screen shot 1110 shows a main display of a gaming machine or terminal that is not partitioned into various components, but rather contains a full or substantially full image of a main game play area 1111. One or more small meter areas 1114 might also be present as well. A pre-rendered frame 1112 can be overlaid or superimposed over the main game play area 1111, with such a frame providing a player notice with limited details, and for a limited time. Limited details might include a notice that the game and/or paytable has changed, along with the name of the new game, the new jackpot combination, and instructions to the player as to how to find the full paytable, among other informational items. Such an implementation can be advantageous in that it is difficult for the player to ignore the notice frame 1112, since the game preferably cannot be played with the pre-rendered notice frame in place. Such a frame is thus likely in place for a short time, such as ten or twenty seconds.
Alternatively, a player input might be required before the notice frame 1112 is removed and game play can commence. Such a player input might include an affirmative opt-in and acceptance of the changes by the player, such as through an additional “I accept” line item and touch screen button in the notice frame itself, for example. Such a requirement might be further advantageous in protecting the gaming establishment against frivolous claims of fraud or unfair gaming practices relating to changed conditions on a gaming machine, since the player must acknowledge the changes before being allowed to play the new or modified game. Data regarding the time and manner of player acceptance of changes might also be captured and recorded along with other frame or notice related data. Such data might also include the identity of the player, if applicable, such as what might be known from an accepted player tracking card at the gaming machine or terminal.
In FIG. 11C, screen shot 1120 shows a main display of a gaming machine or terminal that also is not partitioned, into various components, and also contains a full or substantially full image of a main game play area 1121, as well as one or more small meter areas 1124. Rather than including a player notice having some details regarding changed operational conditions of the gaming machine or terminal, however, a simple alert frame 1122 is provided. Such an alert frame is can be deliberately minimalist in nature, such as where a player should know that changes have taken place, either through the actions of the player or some other obvious circumstances. In its brief and streamlined form, such an alert 1122 might suffice to provide a “warning” and thereby meet any rules or regulations regarding the provision of notice in gaming machines, particularly where changed conditions are due to player selections. As in the previous embodiment for a shortened player notice 1112, such a no frills or details player alert frame 1122 might also contain a “player accept” or other opt-in feature, such that a player acknowledgement of notice can be recorded.
Of course, other informational provisions beyond pre-rendered frames might also be used, and it is specifically contemplated that all forms and formats of dynamic player notices, displays and alerts can be used in conjunction with the present invention. For example, a series of frames might be provided, in what might even amount to a slide show or video clip. In the case of notice frame 1112, a series of pre-rendered frames might provide the entire paytable in ascending or descending order, for example. Further, one or more pre-rendered frames might have portions that are pre-rendered and portions that are filled in. For example, notice frame 1112 might be the same for any paytable change, except for the fill in of the actual game name and the actual jackpot combo and payout. Such fill in information could be stored as one or more added data items in a log record involving the display of the generic pre-rendered frame. As yet another example, one or more audio notices or alerts can be provided as another way of making the player aware that significant changes have been made to the gaming machine or terminal.
As noted above, such changes need not be limited to game and/or paytable information, as player notices or alerts might also be provided regarding changes to denomination, speed, throughput, payback percentage or hold, and/or other parameters. Another item for which the PCM could be adapted to provide player notices could be those related to harm minimization. Harm minimization principles, factors and features are generally well known in the gaming industry, with some examples being presented in an August 2002 white paper by the Australian Gaming Council entitled “Current Issues Related to Identifying the Problem Gambler in the Gaming Venue,” which paper is incorporated herein in its entirety and for all purposes. In general, harm minimization involves the restriction or termination of play for a given player based on concerns for the well being of that given player. Although acting to restrict or deny play for some individuals can likely result in some immediate loss of revenue for a gaming operator, many gaming operators understand that the long term effects of permitting problem gamblers to play unchecked can be severely detrimental to those gamblers, their friends and families, and society in general, in addition to creating a bad reputation for the gaming industry. Accordingly, many gaming operators prefer to implement some forms of harm minimization where possible.
In addition to acting to restrict or prevent play as an extreme measure in some cases where justified, other harm minimization measures or notices of varying levels of severity can include, for example, displaying cash amounts rather than credits, displaying the length of time played at a particular machine or remote gaming terminal, displaying reminders to take a break or slow down, reducing the level of enticing graphics or other sensory elements in game play, forcibly slowing the pace of the game, sending a message to the player or host of the remote gaming terminal to limit alcohol consumption, displaying phone numbers for help services, sending mailers to potentially problematic players, forcing a cash out at a given time, and/or forcing a break in play for a set period of time, among others. In some embodiments, such harm minimization measures can be implemented based not only on each player, but also based upon each location, as some jurisdictions may have differing laws, requirements, and/or recommended procedures with respect to the implementation of such measures. For example, the state of Missouri provides for a loss limit of $500 per day per player, at which point a player is no longer legally permitted to continue in gaming activities.
Some or all of these measures may be at least facilitated in part through use of the PCM, such as utilizing the PCM to provide appropriate harm minimization notices to players, and possibly to record the provisions of such notices as well. As shown in the player information partition 1103 of FIG. 11A, such harm minimization information can be provided to the player or others watching at the gaming machine or terminal on a constant or periodic basis. For example, a “current session” display item might show how long the player has been playing at the given gaming machine or terminal, such as the 22 minutes illustrated in FIG. 11A. Other harm minimization items might be similarly depicted and/or tracked, such as those relating to amounts wagered or amounts lost by the player during the playing session or over a series of recent playing sessions. Further details regarding harm minimization provisions and techniques can be found in, for example, co-pending and commonly owned U.S. patent application Ser. No. 11/064,207 by Nguyen, et al., filed Feb. 22, 2005, and entitled “Harm Minimization Interfaces and Services on a Gaming Machine,” which is incorporated herein by reference in its entirety and for all purposes.
The PCM can thus be generally adapted to detect a significant gaming machine or gaming terminal event, such as a paytable or other operational change, associate the event with one or more notices to be shown for such an event, such as pre-rendered frames or frame portions, provide instructions for such frames to be displayed at an appropriate location and for an appropriate time period, and also record the details of such an event and the frame presentation to a log or other auditable event trail. FIG. 12 is a flowchart depicting an exemplary method of using a PCM to provide players with dynamic notices regarding significant operational changes to gaming machines or terminals. While this flowchart may be comprehensive in some respects, it will be readily understood that not every step provided is necessary, that other steps can be included, and that the order of steps might be rearranged as desired. After start step 1200, a PCM is provided at a process step 1202. Such a PCM can be one or more software components located at any of a number of locations and adapted to perform or facilitate the performance of numerous functions, as detailed above.
At subsequent process step 1204, a communication is accepted at the gaming terminal from a remote device. Such a remote device can be a GTDR, other server, or other network device, and the communication can involve a download of one or more new games, other new software downloads, or a configuration command or instruction, among others. At process step 1206, a significant operational change is detected at the gaming terminal, with such an operational change resulting either directly or indirectly from the communication from the remote device, such as a download of new computer code. At process step 1208, the detected operational change is associated with one or more dynamic player notices, with such notices being in any of a number of forms, as detailed above. For example, such player notices can be in the form of fully or partially pre-rendered frames, and can comprise full displays, notices having limited details, and/or minimalist alerts.
The method then continues to process step 1210, where the associated dynamic player notice or notices are displayed at the gaming terminal, and preferably to a player at the gaming terminal. At a following process step 1212, the player is then prompted for input in order for the dynamic player notice or notices to be removed. Such a prompt might be a part of the notice itself, and might comprise a player acknowledgement and/or acceptance of the noticed gaming terminal changes, as noted above. At decision step 1214, in inquiry is made as to whether an appropriate player input has been received. If not, the method moves to process step 1216, where the play of any further games at the gaming terminal is prevented, with the method reverting back to process step 1211. When an appropriate player input is received at decision step 1214, then the method moves to process step 1218, where details on the significant operational change and provided dynamic player notice or notices are recorded to a log or other auditable storage device. The method then ends at end step 1220. Again, various details and additional steps may similarly be included, and it is specifically contemplated that many variations of these exemplary methods may also be practiced.
US5155837 2 mars 1989 13 oct. 1992 Bell Communications Research, Inc. Methods and apparatus for software retrofitting
US5359730 4 déc. 1992 25 oct. 1994 International Business Machines Corporation Method of operating a data processing system having a dynamic software update facility
US5555418 30 janv. 1995 10 sept. 1996 Nilsson; Rickard System for changing software during computer operation
US5605506 24 mai 1995 25 févr. 1997 International Game Technology Candle antenna
US5675754 * 9 août 1996 7 oct. 1997 Siemens Energy & Automation, Inc. Graphical display for an energy management device
US5682533 27 sept. 1994 28 oct. 1997 Telefonaktiebolaget Lm Ericsson (Publ) Updating software within a telecommunications switch without interrupting existing communication and neither moving nor converting data
US5715462 27 févr. 1995 3 févr. 1998 Ntt Data Communications Systems Corporation Updating and restoration method of system file
US5724425 10 juin 1994 3 mars 1998 Sun Microsystems, Inc. Method and apparatus for enhancing software security and distributing software
US5809251 9 oct. 1996 15 sept. 1998 Hewlett-Packard Company Remote installation of software by a management information system into a remote computer
US5812857 28 août 1996 22 sept. 1998 Extended Systems, Inc. Field configurable embedded computer system
US5845077 27 nov. 1995 1 déc. 1998 Microsoft Corporation Method and system for identifying and obtaining computer software from a remote computer
US5905523 28 juin 1996 18 mai 1999 Two Way Tv Limited Interactive system
US5923249 * 11 janv. 1996 13 juil. 1999 Aristocrat Leisure Industries Pty. Ltd. Door security system
US5923306 7 juin 1995 13 juil. 1999 Nintendo Co. Ltd. Hotel-based video game and communication system
US6047128 9 déc. 1997 4 avr. 2000 U.S. Philips Corporation System for downloading software
US6047129 3 mars 1998 4 avr. 2000 Frye; Russell Software updating and distribution
US6074435 30 oct. 1997 13 juin 2000 Telefonakiebolaget Lm Ericsson (Publ) Remote software download with automatic adjustment for data access compatibility
US6219836 14 oct. 1998 17 avr. 2001 International Game Technology Program management method and apparatus for gaming device components
US6263497 27 juil. 1998 17 juil. 2001 Matsushita Electric Industrial Co., Ltd. Remote maintenance method and remote maintenance apparatus
US6266810 17 avr. 1998 24 juil. 2001 Matsushita Electric Industrial Co., Ltd. Remote program downloading system and apparatus
US6317827 16 août 1996 13 nov. 2001 Intel Corporation Method and apparatus for fault tolerant flash upgrading
US6634946 * 12 sept. 1999 21 oct. 2003 James L. Bridgeman Pari-mutuel networks, devices and games
US6712693 28 août 2000 30 mars 2004 Igt Method and apparatus for player selection of an electronic game payout
US6716102 9 mars 2001 6 avr. 2004 Microsoft Corporation Method and apparatus for displaying information regarding stored data in a gaming system
US7379901 * 11 sept. 2000 27 mai 2008 Lv Partners, L.P. Accessing a vendor web site using personal account information retrieved from a credit card company web site
US20020188940 8 juin 2001 12 déc. 2002 Robert Breckner Method and apparatus for gaming device software configuration
US20040048671 10 sept. 2003 11 mars 2004 Igt Gaming terminal data repository and information distribution system
US20040180721 23 févr. 2004 16 sept. 2004 Igt Gaming terminal data repository and information distribution system
US20050176498 4 févr. 2005 11 août 2005 Igt Name your prize game playing methodology
US20070032288 5 oct. 2006 8 févr. 2007 Igt Remote configuration of gaming terminals
US20070197298 23 févr. 2007 23 août 2007 Igt Wide area program distribution and game information communication system
US20070270212 1 août 2007 22 nov. 2007 Igt Executing multiple applications and their variations in computing environments
US20080045346 27 juil. 2007 21 févr. 2008 Igt Remote configuration of gaming terminals
EP0491585A2 22 nov. 1991 24 juin 1992 International Business Machines Corporation Dynamic link libraries system and method
EP0689325A2 20 juin 1995 27 déc. 1995 NCR International, Inc. Method and apparatus for distributing software
EP0706275B1 22 août 1995 25 janv. 2006 International Business Machines Corporation System and method for secure storage and distribution of data using digital signatures
EP0841615A2 15 sept. 1997 13 mai 1998 International Computers Limited Updating mechanism for software
EP0905614B1 28 sept. 1998 8 déc. 2004 Noritsu Koki Co. Ltd. Processing apparatus and an operation control information update system employing the processing apparatus
EP0962900A2 18 févr. 1993 8 déc. 1999 Ricos Co., Ltd. Computer game device
EP1001391A2 29 sept. 1999 17 mai 2000 International Game Technology Gaming device identification method and apparatus
EP1004969A2 29 sept. 1999 31 mai 2000 International Game Technology Program management method and apparatus for gaming device components
EP1004970B1 29 sept. 1999 14 nov. 2007 Igt Method for downloading data to gaming devices
EP1363252A2 4 mars 2003 19 nov. 2003 Atronic International GmbH Configuration technique for a gaming machine
GB2151054A Titre non disponible
WO2005022453A1 * 27 août 2004 10 mars 2005 Flanagan John Thomas System and method for facilitating responsible behaviour
1 "Computer Networking," Wikipedia [online] [retrieved on Jul. 29, 2008] Retrieved from: http://en.wikipedia.org/wiki/Computer-networking, 14 pp.
2 "Computer Networking," Wikipedia [online] [retrieved on Jul. 29, 2008] Retrieved from: http://en.wikipedia.org/wiki/Computer—networking, 14 pp.
3 AU Office Action dated Jul. 19, 2011 issued in 2007307924.
4 AU Office Action dated Jun. 15, 2011 issued in 2006269597.
5 AU Office Action dated Nov. 8, 2010 issued in 2006269597.
6 AU Office Action dated Oct. 13, 2005 issued in 2002214603, 2 pages.
7 Australian Office Action dated Jun. 24, 2008 issued in No. 2002255490, 2 pgs.
8 Australian Office Action dated Nov. 8, 2010 issued in 2006269597.
9 Canadian Office Action dated Jul. 19, 2007 from related Canadian Application No. 2,435,750 3 pages.
10 Chinese Office Action dated Aug. 30, 2010 issued in 200780044186.9.
11 EP Communication pursuant to Article 94(3) EPC dated Apr. 9, 2009 issued in EP Application No. 06785708.6 6 pp.
12 EP Communication pursuant to Article 94(3) EPC dated Aug. 26, 2009 issued in EP Application No. 07843492.5 4 pp.
13 EP Search Report dated Aug. 26, 2005 for corresponding EP application No. 01983154.4 (4 pages).
14 European Office Action dated May 9, 2006 issued in No. 02724890.5.
15 Examination Report from Corresponding EP application No. 01983154.4, dated Dec. 20, 2006, 6 pages.
16 Final Office Action from U.S. Appl. No. 09/965,524, dated Feb. 13, 2006, 6 pages.
17 First Canadian Office Action dated Jan. 6, 2005 issued in No. 2,435,750.
18 Hiroaki Higaki, 7 page document entitled, "Group Communication Algorithm for Dynamically Updating in Distributed Systems", Copyright 1994 IEEE International Conference on Parallel and Distributed Systems (pp. 56-62) 0-8186-6555-6/94, higaki@sdesun.slab.ntt.jp.
19 Hiroaki Higaki, 9 page document entitled, "Extended Group Communication Algorithm for Updating Distributed Programs", Copyright 1996, IEEE, International Conference on Parallel and Distributed Systems, 0-8186-7267-6/96, hig@takilab.k.dendai.ac.ip.
20 International Preliminary Examination Report dated Apr. 17, 2003, 3 pages.
21 International Preliminary Examination Report dated Apr. 7, 2009 issued in PCT/US2007/079901, 6 pages.
22 International Preliminary Examination Report dated Dec. 2, 2002 issued in PCT/US01/32368 4 pages.
23 International Preliminary Report on Patentability dated Jan. 17, 2008 issued in PCT/US2006/025089.
24 International Search Report and Written Opinion dated Apr. 20, 2009 issued in PCT/US2008/071830 15 pp.
25 International Search Report and Written Opinion dated May 7, 2008 issued in PCT/US2007/079901 11 pp.
26 International Search Report and Written Opinion dated Nov. 2, 2006 issued in PCT/US2006/025089, 9 pages.
27 International Search Report and Written Opinion from International application No. PCT/US2006/025089, Nov. 11, 2006, 9 pages.
28 International Search Report or the Declaration dated Feb. 24, 2003 issued in PCT/US02/02431.
29 International Search Report or the Declaration dated Mar. 25, 2002 issued in PCT/US01/32368 7 pages.
30 Internet Basics: ‘How Information Travels Online’, ‘What Happens When You Go Online’, ‘Making the Online Connection’ and ‘How to Download Files’, copyright 1996, 12 pages.
31 Internet Basics: 'How Information Travels Online', 'What Happens When You Go Online', 'Making the Online Connection' and 'How to Download Files', copyright 1996, 12 pages.
32 Notice of Allowance and Allowed Claims dated Apr. 2, 2008 from related U.S. Appl. No. 10/659,827 16 pages.
33 Notice of Allowance dated Sep. 13, 2006 issued in U.S. Appl. No. 09/965,524, 10 pp.
34 Office Action dated Jun. 28, 2005 from related U.S. Appl. No. 09/965,524 (10 pages).
35 Oracle Corporation, www.oracle.corn/collateral/ent-partioning-fo.pdf, Feb. 1999.
36 Oracle Corporation, www.oracle.corn/collateral/ent—partioning—fo.pdf, Feb. 1999.
37 PCT International Preliminary Report on Patentability and Written Opinion dated Feb. 2, 2010 issued in PCT/US2008/071830.
38 PCT Partial Search Report and Invitation to Pay Additional Fees dated Nov. 6, 2008 issued in PCT/US2008/071830 6 pp.
39 Spielo Gaming International, www.spielo.com, Dec. 6, 2000.
40 Steffen Hauptmann, et al., 11 page document entitled, "On-Line Maintenance with On-the-fly Software Replacement", Copyright 1996 IEEE Proceedings, Third International Conference on Configurable Distributed Systems, (pp. 70-80) 0/8186-7395-8/96.
41 Supplemental US Office Action dated Mar. 12, 2002 issued in U.S. Appl. No. 09/746,944.
42 U.S. Appl. No. 09/642,192, filed Aug. 18, 2000.
43 U.S. Appl. No. 11/064,207, filed Feb. 22, 2005.
44 US Advisory Action dated May 10, 2010 issued in U.S. Appl. No. 10/659,827.
45 US Examiner's Interview Summary dated Mar. 26, 2010 issued in U.S. Appl. No. 10/659,827.
46 US Final Office Action dated Aug. 19, 2009 issued in U.S. Appl. No. 10/785,526, 15 pgs.
47 US Final Office Action dated Dec. 22, 2009 issued in U.S. Appl. No. 10/659,827.
48 US Final Office Action dated Feb. 4, 2010 issued in U.S. Appl. No. 10/785,526, 23 pp.
49 US Final Office Action dated Jun. 30, 2010 issued in U.S. Appl. No. 11/709,981.
50 US Final Office Action dated May 27, 2009 issued in U.S. Appl. No. 10/659,827.
51 US Final Office Action dated Sep. 16, 2002 issued in U.S. Appl. No. 09/746,944.
52 US Final Office Action Jan. 27, 2010 issued in U.S. Appl. No. 11/544,923, 22 pp.
53 US Final Office Action May 16, 2011 issued in U.S. Appl. No. 11/544,923.
54 US Notice of Allowance dated Jun. 13, 2003 issued in U.S. Appl. No. 09/746,944.
55 US Office Action dated Aug. 7, 2008 issued in U.S. Appl. No. 10/659,827.
56 US Office Action dated Feb. 28, 2002 issued in U.S. Appl No. 09/746,944.
57 US Office Action dated Jan. 31, 2003 issued in U.S. Appl. No. 09/746,944.
58 US Office Action dated Nov. 30, 2009 issued in U.S. Appl. No. 11/709,981, 21 pp.
59 US Office Action dated Sep. 11, 2009 issued in U.S. Appl. No. 11/544,923.
60 US Office Action dated Sep. 15, 2009 issued in U.S. Appl. No. 11/829,789.
61 US Office Action Dec. 17, 2010 issued in U.S. Appl. No. 11/544,923.
62 US Office Action-Notice NonCompliant Amendment, dated Jan. 15, 2009 issued in U.S. Appl. No. 10/659,827.
63 US Office Action—Notice NonCompliant Amendment, dated Jan. 15, 2009 issued in U.S. Appl. No. 10/659,827.
64 Written Opinion dated Aug. 12, 2002 issued in PCT/US01/32368 5 pages.
Classification aux États-Unis 463/42, 463/41, 463/43, 463/29, 463/40
Classification internationale A63F9/24, G07F17/32, G06F19/00, G06F17/00
Classification coopérative G07F17/3244, G07F17/3239, G07F17/3227, G07F17/3223, G07F17/32, G07F17/323
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROWE, RICHARD E.;REEL/FRAME:016683/0742