US20070111791A1

US20070111791A1 - System for configuration

Info

Publication number: US20070111791A1
Application number: US11/530,880
Authority: US
Inventors: Christopher Arbogast; Travis Green; William Jones; Dale Shepherd; Ronald Cadima; Thomas Buckeyne; Anthony Green; Pravinkumar Patel; Robert Crowder; Joshua Larsen
Original assignee: Bally Gaming Inc
Current assignee: LNW Gaming Inc
Priority date: 2005-09-12
Filing date: 2006-09-11
Publication date: 2007-05-17
Also published as: CN101346723A; CN102592366A; CN102592366B; US20070105628A1; US20080200260A1; US20120220374A1; US9305424B2; CN101360541B; US20070218998A1; CN101360541A; US20080214307A1

Abstract

A system for configuring an EGM from a remote terminal thereby providing improvements in operational efficiency when configuring EGMs. For example, operational efficiencies are possible by providing direct access to configure an EGM without the technician traveling to the physical machine, which may be miles away. For local EGM's, there will be efficiencies obtained by the number of EGM's configured per hour/per technician. For extremely remote EGM's, there are additional efficiencies by the reduction of travel and lodging expenses for the technician. Additionally, remote configuration of an EGM reduces security overhead.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to U.S. Provisional Patent Application No. 60/716,713 filed Sep. 12, 2005 and incorporated by reference herein in its entirety.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

Over the years, casinos have grown in size, grandeur, and amenities in order to attract gambling patrons. Additionally, casinos have attempted to provide gambling patrons with a wide variety of the new and exciting games. Given this demand, gaming machines and have grown in sophistication and features in order to captivate and maintain player interest. As a result, casinos are able to provide a wide range and large number of games of chance.
For example, a casino floor may include thousands of electronic gaming machines (EGMs) that are in communication with and monitored by the casino's gaming network. EGMs provide an enhanced gaming experience with computer graphics, stereo sound, animation, and other features that have been developed to maintain player interest in the game. Furthermore, EGMs may include secondary networked devices such as player tracking devices or enhanced player interfaces (e.g., Bally Gaming's iView™ touch-screen display). Accordingly, there are a large number of EGMs and related components that need to be monitored, maintained, and serviced.
In early gaming environments, gaming machines were stand-alone devices. Security of the gaming machines was accomplished via physical locks, security protocols, security personnel, physical and video monitoring, and the need to be physically present at a machine to attempt to breach the security of the gaming machine. By the same token, management of the gaming machines required a great deal of personal physical interaction with each gaming machine. The ability to change parameters of the gaming machine also required physical interaction.
In view of the increased processing power and availability of computing devices, gaming machines have become customizable via electronic communications and remotely controllable. Manufacturers of gaming equipment have taken advantage of the increased functionality of gaming machines by adding additional features to gaming machines, thereby maintaining a player's attention to the gaming machines for longer periods of time increasing minimum bet and bet frequency and speed of play. This, in turn, leads to the player wagering at the gaming machine for longer periods of time, with more money at a faster pace, thereby increasing owner profits.
The amount of interactivity and data presentation/collection possible with current processor based gaming machines has led to a desire to connect gaming machines in a gaming network. In addition to the gaming machines themselves, a number of devices associated with a gaming machine or with a group of gaming machines may be part of the network. It has become important for the devices within a gaming machine or cabinet to be aware of each other and to be able to communicate to a control server. Not only is the presence or absence of a network device important, but also the physical location of the device and the ability to associate devices within a particular gaming machine has become a necessary component of a gaming network.
Currently, casino operators use manual methods to alter content or to reconfigure EGMs and/or other secondary networked devices. For example, a casino employee would need to physically swap out an EPROM to change game content or the employee would need to access an attendant menu on the EGM to alter game configurations. Given the large number of machines and networked devices, this process is a time-consuming and costly process not only in terms of operating and/or maintenance costs, but also in terms of lost profits due to extended downtime for the EGMs. Similarly, existing approaches for software updates or downloads for EGMs are labor-intensive and costly as the EGMs. For example, a technician typically needs to travel to the gaming machine in order to replace existing software package media (e.g., EPROMs, CD-ROM's, Compact Flash, etc.) with new software package media. Furthermore, the software package update process may require that the EGM be disabled hours in advance to prevent any players from using the EGM when the technician is ready to perform software package changes. Alternatively, EGMs may be disabled prior to software package updates, but the technician must periodically check to ensure that the EGM(s) are not being used by a player. Additionally, technicians may need to be supervised during the process of software package installation as the technician has access to critical areas of the EGM required for configuration or of those areas of containing cash.
The process of transferring packages to an EGM over a network may require a significant amount of network bandwidth during the transfer period. Typical transfer mechanisms provide point-to-point transfer where a SDP will transfer to a single EGM until the transfer is complete, and then the SDP may transfer to another EGM. When hundreds or thousands of EGM's require packages to be transferred there may be an unacceptable extended period of high bandwidth usage, since the transfers must occur sequentially.
Additionally, installing packages on an EGM can require verification that dependent software packages and hardware components are available within the EGM. This is typically a manual process that prone to human interpretation and human error.
Accordingly, there remains a need to provide a system for updating and configuring EGMS and other networked components.

SUMMARY

Generally, the system may configure an EGM from a remote terminal thereby providing improvements in operational efficiency when configuring EGMs. For example, operational efficiencies are possible by providing direct access to configure an EGM without the technician traveling to the physical machine, which may be miles away. For local EGM's, there will be efficiencies obtained by the number of EGM's configured per hour/per technician. For extremely remote EGM's, there are additional efficiencies by the reduction of travel and lodging expenses for the technician. Additionally, remote configuration of an EGM reduces security overhead. That is, some environments require authorized security or management personnel to witness a technician while the EGM is open during configuration. These witnesses are mostly required because critical areas of the EGM are accessible during the configuration process, including access to areas that contain cash. By remotely configuring the EGM, no critical areas are made accessible and thus no security or management personnel are needed.
Additionally, casino management may use remote configuration to optimize their machines in ways that would otherwise be impractical. This may provide the basis for a ‘Yield Management’ capability. For example, casino management may enable high denomination games and restrict low denomination games during peak demand periods. Alternatively, casino management may expand low denomination games configured during weekdays when the players are typically loyal locals.
In another method, methods of pre-configuring EGMs are disclosed herein. In one method, the network system uses option templates to support pre-configuration because a particular EGM or game theme within an EGM may support a large number and wide variety of options. For example, option definition templates such as Combo Option templates or Option Group templates may be used to define the configuration of new content before it is downloaded to an EGM. Additionally, a casino operator may schedule the download of a new game theme during off-hours and have the network host configure the new game theme as soon as installation is completes without requiring operator intervention.
Methods of automatic downloading and configuration of EGMs are also disclosed. In one method, the network system provides a method of recognizing when an EGM needs data downloads or configuration, and the network coordinates these activities to avoid conflicts. For example, in one method, attempts to configure an EGM will be prevented until downloads for the EGM are completed. In another method, the network host automatically restores data modules and configures an EGM if it has been RAM-cleared or has been offline. Accordingly, an operator can monitor and manage a group of EGMs from a single terminal, thereby eliminating the need for slot technicians to collect configuration data and to manually reconfigure each EGM.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of a gaming network that may be used with the system.
FIG. 2 is a block diagram of an alternate embodiment of a gaming network that may be used with the system.
FIG. 3 is a block diagram of an embodiment of the system.
FIG. 4 is a sequence diagram illustrating one embodiment of the operation of the system.
FIG. 5 is a flow diagram of an embodiment of the system.

DETAILED DESCRIPTION

In one embodiment, the system may configure an EGM from a remote terminal over network communications. The configuration of an EGM can vary upon the EGM's installed software, so the system includes a mechanism for the remote terminal to query the EGM for its specific set of configuration options. The system allows the remote configuration of EGMs, the validation of the configuration, and configuration reporting by the EGM.
Once the EGM has responded to the query, all of the EGM options are available at the remote terminal. This information is used by an operator at the remote terminal to change the option settings while keeping the settings within constraints provided with the EGM options. The operator has the ability to change any number of options from the set of EGM provided options. The operator may choose to inspect EGM option settings and/or change one or more EGM option settings.
The modified options, if any, may then be transferred from the Configuration Server Point (CSP) to the EGM with instructions of how to apply the modified options. The EGM is responsible for monitoring the EGM state and comparing it with the applied conditions. The EGM is the authority on when the option changes get applied; however, the EGM uses the applied conditions provided by the operator at the remote terminal.
It should be noted that the term EGM is intended to encompass any type of gaming machine, including hand-held devices used as gaming machines such as cellular based devices (e.g. phones), PDAs, or the like. The EGM can be represented by any network node that can implement a game and is not limited to cabinet based machines. The system has equal applicability to gaming machines implemented as part of video gaming consoles or handheld or other portable devices. In one embodiment, a geo-location device in the handheld or portable gaming device may be used to locate a specific player for regulatory and other purposes. Geo-location techniques that can be used include by way of example, and not by way of limitation, IP address lookup, GPS, cell phone tower location, cell ID, known Wireless Access Point location, Wi-Fi connection used, phone number, physical wire or port on client device, or by middle tier or backend server accessed. In one embodiment, GPS and biometric devices are built within a player's client device, which in one embodiment, comprises a player's own personal computing device, or provided by the casino as an add-on device using USB, Bluetooth, IRDA, serial or other interface to the hardware to enable jurisdictionally compliant gaming, ensuring the location of play and the identity of the player. In another embodiment, the casino provides an entire personal computing device with these devices built in, such as a tablet type computing device, PDA, cell phone or other type of computing device capable of playing system games.
In one embodiment, the system uses a network configuration where one or more EGM's are networked with a CSP network server and at least one CSP network access terminal. Supplemental remote terminals can be networked with the CSP to provide multiple workstations for EGM configuration verification/alteration.
The network may be shared among other casino network systems, or an exclusive network dedicated to configuration activities.
The system may also include secure network technology to assure that only authorized systems and users may inspect or alter an EGM's configuration options. The use of PKI and SHA1 are applied to authenticate and validate configuration network messages.
The system includes technology in the CSP network server and in the EGM to exchange an EGM's configurable options and constraints on possible settings for those options. The system uses a point-to-point protocol between the CSP and the EGM, where the CSP can request a full set or a subset of options from the EGM. The EGM uses the point-to-point protocol to respond to the request, providing either a full set or the appropriate subset of options and constraints. Each option is accompanied with constraints: either a range of valid settings or a list of valid settings—one of which can be active at any given time.
The system includes technology to present the options and constraints to an operator at a remote terminal of the CSP. The remote terminal will accept changes to the option settings from the operator. The changes to any of the options will be checked for consistency with the constraints. Invalid selections will be flagged by the technology and the changed option setting will not be permitted. This capability allows the operator to perform the following:
Inspect the option and their respective settings without making any changes.
Modify a single option setting.
Modify many options settings.
Modify all option settings.
The system includes technology to send the modified configuration options from the CSP to the EGM, where the EGM will validate the new option settings. If the option settings are within constraints and match the EGM's capabilities, then the EGM will accept the option settings. Otherwise, the EGM will reject the option settings and notify the CSP of the rejection.
The system includes technology to specify the application conditions that EGM will use to apply the new option settings. The application conditions include optional time windows with date and times for the start and end times. There are application conditions for disabling the game before the changes may be applied. Alternatively, the game does not need to be disabled before the changes are applied. There are also application conditions that include automatic application, manual operator interaction, or explicit authorization from the CSP. There is also a parameter for what action to take after the new option settings have been applied—whether to continue EGM operation or to restart the EGM.
Assuming the EGM accepts new option settings and apply conditions from the CSP, the EGM will monitor itself to determine when the correct conditions are available to apply the new option settings. The system includes this technology to monitor and apply the new options only when the proper conditions have been met, and then to take the appropriate action after the new option settings have been applied.
Furthermore, there are many combinations of selecting subsets of options. Option subsets such as, but not limited to, the following are typical:
Cabinet & peripheral options
Communication options
Money handling options
Game options (there may be game options that affect all games on the EGM. There can be options that are defmed by theme and affect all of the games of that given theme. there can also be options defined at the paytable level that can affect a specific instantiation of a theme/paytable,denomination.)
Progressive options
Bonus options
Player tracking options
There are several combinations of specifying the applied conditions.
The network topology may be altered to accommodate the following communication schemes:
‘Home-run’ network where a dedicated communication line is routed from each EGM to the CSP, including but not limited to Ethernet network schemes.
Multi-drop asynchronous serial network where a common communication line is routed from the CSP to an EGM, then from EGM to EGM.
Multi-drop synchronous serial network where a common communication line is routed from the CSP to an EGM, then from EGM to EGM.
The specific constraints for common options can be pre-defined with defaults. This would reduce the data sent from the EGM to the CSP when the EGM responds to a CSP request for options. If the EGM had option setting constraints outside of the default constraints, the EGM would then provide explicit constraints for the option, which would be used to override the default constraints.
The system also provides for the use of templates that represent a configuration state of an EGM. Instead of remotely setting or changing individual constraint or option, the operator can simply download the configuration template and change all options, constraints, and configurations at once. This can be used in connection with a plurality of EGMs that are either identical or are able to accept identical configuration templates. In one embodiment, the configuration template can be communicated to one or more EGMs as part of a background download. In another embodiment, the configuration template can be communicated to one or more EGMs as part of a multicast.
In another embodiment, a machine can be configured remotely either by selection of individual options or by use of a template. Once an EGM has been configured, a copy of the configuration of the EGM may then be used to configure other EGMs, such as in a bank of similar EGMs.
Once a machine has been configured, the host system may query the machine for its configuration. The machine then responds with its option configuration. This allows for changes to be detected and allow for current configuration information in the host system. In one embodiment, the gaming machine provides data about the option type as well as the configuration setting to the host system. This meta-data makes it easier for the host system to present the data in an appropriate manner to a user for making configuration changes. For example, if the machine returns a configuration option related to volume, the fact that the type is volume may trigger the host system to display that option with a slider bar instead of as a text box.
Configuration Options
The options that can be configured by the system includes, but is not limited to, the following examples.

- Configuration Category Game Sounds
- User Feedback
- Game Play
- Attract Mode
- Configuration Category User Feedback Definitions
- Play Buttons
- Operator Buttons
- Bill in Sounds
- Bill in Sounds
- Coin in sounds
- Coin in sounds
- Jackpot Sounds
- Jackpot Sounds
- Instructional Vocals
- Instructional Vocals
- Configuration Category Game Play Definitions
- Reel Spin duration
- Win Roll Up speed
- Bonus Features
- Configuration Group Attract Definitions
- Attract Music
- Configuration Category Operator Menu
- Configuration Category Limits
- Credit Limit
- IRS Limit
- Jackpot Limit
- Bill Limit
- Bill Reject Limit
- Configuration Category Voucher Data
- Voucher Location
- Voucher Address
- Configuration Category Identification
- Asset Number
- Serial Number
- Configuration Category Denomination
- Denomination

Example Networks
An embodiment of a network that may be used with the system is illustrated in FIG. 1. The example network consists of a top level vender distribution point 101 that contains all packages for all jurisdictions, one or more Jurisdiction distribution points 102A and 102B that contain regulator approved production signed packages used within that jurisdiction or sub-jurisdiction, one or more Software Management Points 103A and 103B to schedule and control the downloading of packages to the EGM and a one or more Software Distribution Points 104A and 104B that contain regulator approved production signed packages only used in the gaming establishment that it supports. The Software Distribution Points (SDPs) 104A and 104B can communicate with Systems Management Points (SMPs) 105A and 105B, respectively as well as directly to one or more EGMs 106A and 106B. The system allows for rapid and secure distribution of new games, configurations, and OS's from a centralized point. It makes it possible to update and modify existing gaming machines with fixes aiid updates to programs as well as providing modifications to such files as screen images, video, sound, pay tables and other EGM control and support files. It provides complete control of gaming machines from a centralized control and distribution point and can minimize the need and delay of human intervention at the EGM. In one embodiment, the configuration control may be from the SDPs 101 or 104 or from the gaming servers 103.
Another embodiment of a network that may be used in the system is illustrated in FIG. 2. A core layer 215 includes one or more servers 201 that are coupled via a communication path 202 to one or more switches 203. In one embodiment, the servers and switches of the core layer 215 are located within the gaming establishment premises in a secure administrative area. The servers 201 may, but are not required to be, game servers. The communication path 202 may be hardwire (e.g., copper), fiber, wireless, microwave, or any other suitable communication path that may be protected from attack. In one embodiment, the switches 203 are L2/L3 switches. However, one of ordinary skill in the art will appreciate that other types of switches may be used without departing from the scope or spirit of the claimed system.
A distribution layer 216 communicates with the core layer 215 via high bandwidth communications links 204. These links may be copper, fiber, or any other suitable link. If desired, redundant links 205 may be built into the system to provide more failsafe operation. The communications links couple the core layer switches 203 to the distribution layer switches 206. These may be one or more switches, such as L2 switches, for example.
The distribution layer 216 communicates with an access layer 217 via a high capacity communication link 207. The link 207 may be wire, fiber, wireless, or any other suitable communication link. In the embodiment of FIG. 2, the communication link 207 is coupled to a gaming carousel 208 that comprises a plurality of gaming machines (e.g., 16 gaming machines 215A-215P). A managed switch 209 is coupled to the link 207 to provide an interface switch to a plurality of other managed switches 210 through 213. In the embodiment illustrated, each of the managed switches 210-213 manages four game machines 215(x). It is understood that the types of switches may be changed without departing from the scope of the claimed system. Further, switches with more or fewer ports may be substituted and more or fewer tiers of switches in the access layer may be used, as well, without departing from the scope or spirit of the claimed system. In another embodiment, each game machine has its own managed switch.
In one embodiment of the gaming network, the network uses TCP/IP sessions between the gaming machines 215 and the servers 201. The TCP/IP sessions are used to exchange private information concerning game operations, game performance, network management, patron information, revised game code, accounting information, configuration and download, and other sensitive information. In one embodiment, sessions may be a single message and acknowledgement, or the sessions may be an extended interactive, multiple transaction session. Other instantiations may include UDP/IP, token ring, MQ, etc.
The example network is described in co-pending U.S. patent application Ser. No. 11/220,781 entitled Gaming Network and is incorporated herein by reference in its entirety. Any of the servers of FIGS. 1 and 2 could serve as the Configuration Server Point for use in the system.
FIG. 3 is a block diagram of an embodiment of a configuration management architecture that may be used in an EGM with the system. The architecture illustrates software functions within an EGM in one embodiment. A configuration server 303 is part of the game manager 304. An IPC connection 302 is made to a host interpreter 301. In one embodiment, the host interpreter interprets for the so-called Best of Breed (“BOB”) protocol or G2S protocol. One or more clients 306A-306C have an IPC connection 305 to the configuration server 303. The configuration server has access to local NVRAM 307 via the game manager 304.
In one embodiment, the configuration server 303 acts as a central point of configuration management. The server 303 does not necessarily have specific knowledge of any specific configuration options. Rather, the server handles each configuration option dynamically as it is registered and used. It is the responsibility of the configuration client to register for a configuration and respond to a configuration change.
The client object's function is to provide a useful interface to the configuration service. The methods given are not direct IPC calls, but instead tools that use IPC calls to communicate with the configuration service. The majority of these methods accept vectors of configuration objects to reduce calls and simplify the interface, as it is anticipated that most configuration clients will have multiple options to manage. Even though configuration objects may be created at any time, it is recommended that all configuration objects be registered before a “Game Complete” event. This will allow host interpreters to have a consistent point of completeness, and provide a more consistent interface with the given host system.
Implementation Embodiment
In order to allow easier operability for a user or administrator, the system contemplates a system for naming individual options so that they can be uniquely identified. There may be a number of volume options that can be configured using the system. Calling each of these options “volume” would limit the ability of a user to distinguish the particular volume option that is desired to configure. To solve this issue, the system proposes a naming convention for configuration options so that plain English names can be used to enable easy understanding of an operator when implementing a configuration or configuration template. The example given is for one embodiment of the system and is not intended to be limiting. In the embodiment, the components are part of a configuration option object that may be provided to an EGM. Within the development environment, an Option can be viewed at any time as a C++ Object, or as a XML text buffer. The configuration Object will usually be handled within the context of a standard template library vector. Configuration Hosts and the configuration manager will view configuration options in their whole form, while configuration clients will typically only deal with the configuration options by their name and value.
An object may be created from a file:
CreateFromFile(vector<ConfigurationOption>& Options, char*filename);
This fills the vector Options with all of the Options defined by filename. It also automatically appends the path information as necessary to ensure that each configuration option has a unique name. Alternatively, the Option can be constructed at run time, by declaring an Option and filling each parameter. The Caller will then be responsible for ensuring that configuration option names are guaranteed unique.
Multiple modules may have configuration options that have the same short name (e.g. volume). A Game may have several “Volumes” and the OS may have its own volume. To manage this problem, a simple name to value pair is not sufficient, because the management server needs to be able to distinguish between the different volumes. To do this, each configuration option name will include the path of the configuration file that it was created from. This reduces the restriction on option names to be unique per configuration file, but now allows multiple “volumes” across the system. This configuration path name may need to be overridden in some specific cases, in which case an IPC call will be supported to do so if and when it is needed. With the path as part of the name, the configuration options when presented to in a GUI can be displayed as “Volume” but in the background can now be managed as “cfg/OSSound/Volume” and “game1/theme/volume”, keeping them separate and accurate.
Every configuration object is responsible for defining rules that will prevent illegal configurations. This is important because the possibility of incomplete configurations needs to be avoided, as recovery from such situations may not always be possible due to one time configurations, interdependencies, and the like. Changes may occur singularly, or as a whole. Each configuration request will be treated as a single transaction regardless of the size or number of options that change. All rules will be re-evaluated before changes are implemented. Registered clients will receive their option changes at the same time to avoid chicken/egg situations. Configuration clients will have their handlers called in the order that the client registered with the configuration service.
The components of a configuration option object include category, name, value, type, minimum, maximum, allowed values, allowed value rules, control type, rules, ReadOnly, OneTimeSettable, IsSet, ReadOnlyWithCredits, Visible, RestrictToAllowedValues, UniquePerMachine, CommaDelimitedList, and Enabled. As can be seen from a review of these components, some may be optional depending on the configuration option.
Category—The Name of the Category that this object will reside in.
Name—The Name of the Option.
Value—The Value of the Option. The creator of the Option is responsible for filling this with the “default” value.
Type—The type of the option Value. The supported types are: double, signed long, string, and Boolean.
Minimum—Optional, the minimum value of Value. (e.g. minimum volume)
Maximum—Optional, the maximum value of Value. (e.g. maximum volume)
Allowed Values—Optional, if provided, Value must be equal to a value supplied in the allowed value list.
Allowed Value Rules—Optional, for each allowed value, this rule will check if the allowed value will be present.
Control Type—Type of control object to display in GUI to the operator.
Rules—Expressions that must resolve to true or non-zero length string for Value to be considered valid.
ReadOnly—Boolean signifying if this is a modifiable option. It is preferable if the ReadOnly flag be set once to prevent confusion or conflicts when copying one machines configuration to another.
OneTimeSettable—Boolean signifying if this option can only be set once per ram clear.
IsSet—Boolean signifying if this option has been set at least once since ram clear.
ReadOnlyWithCredits—Read Only With Credits signifies that this Option can only be modified while there are no credits on the machine.
Visible—Boolean signifies if this option can/will be displayed to the operator.
RestrictToAllowedValues—Boolean signifies that the Value MUST be on the allowed value list. When this flag is not set, Allowed Values are used more as “suggested” values. Do not use this option in combination with Control Type Combo Box.
UniquePerMachine—Flag that signifies the option is part of the identity of a gaming machine, and should not be copied to another machine. No 2 machines should have the same value.
CommaDelimitedList—Flag that signifies if this option is intended to be a list of values. Comma delimited lists are intended to have the format “(value)”,“(value2)”,“(value3)”
Enabled—This flag signifies if this option is “Enabled”. Enabled means that a change in the option can have an effect, while not Enabled, means that this option value is ignored. An example would be in Iowa, there is no printer limit. So the printer limit is “Disabled”. You can give the printer limit a value, but it will have no effect on the operation of the machine. If Enabled is not present in the definition of an option, it is assumed to be true. Enabled's primary purpose is for the use in Rules. A rule may check the enabled state of itself, and either require that the value is some fixed number, or allow any value, since it has no effect for example. Rules may also check the enabled state of other rules. For the Iowa example, the tax limit may normally check to ensure that it is greater than printer limit, if the printer limit is enabled, otherwise, ignore the rule. The same rule would then work for jurisdictions that have a printer limit, and for jurisdictions that do not.
Some of the control types include:
Category—New Category. This will use the Value as the name of the new category. The only other member variables that will effect this option on the GUI end is the Visible flag. Value and AllowedValues and Rules are still available when evaluating Rules.
Single Line Edit Box—Simplest of Control Type. This is a text box that will accept a single line of text.
Multi-Line Edit Box—This is a text box that will allow for new lines.
Slider—This is a drag-able slider bar. To use, provide a min and max. Also supports allowed value list.
CheckBox—Used for Boolean options. May be checked or un-checked by operator.
CheckBoxArray—Used for comma delimited lists with allowed value sets. Each selected checkbox will add a comma delimited string to the Value.
ListBox—Displays Allowed Values to be chosen from by Operator
ComboBox—Displays Allowed Values list but allows Operator to enter a custom single line of text
RadioButton—Will list Allowed Values as Radio Button options, and the Operator will be allowed to select one.
Storing configuration in NVRAM
Saved in NVRAM in a reserved block will be the category, name, and string value of every configuration object. The categories may be stored in a lookup table to save space, and the value may be stored separately with index references to their category and names.
Configuration data may be streamed to the block as configuration changes are made. The NVRAM structure should be managed. If the reserved block is not managed, then theoretically, a change at the beginning of the structure in the length of a string can cause the entire block to be re-streamed to NVRAM, causing unacceptable resource loads. Instead the data should be kept in an allocation table, so that the data can be dynamically rearranged to reduce NVRAM writes on configuration changes. A background timer or thread can then be used to defragment the data over time, to create large blocks of space for future configuration changes.
If a configuration change is made that does not fit into NVRAM, then the change will not occur, and the configuration change will be denied with an error for insufficient space.
If a change occurs for which there is sufficient NVRAM space, but due to defragmentation there are no continuous blocks large enough to contain the change, then the defragmentation process will be forcefully completed just enough to allow the change to take place. The forced defragmentation will only defragment the entire block of space if it is absolutely required. The goal is to complete the write with as little NVRAM access as possible.
Configuration Rules
Configuration rules are intended to allow the configuration manager and the host system to pre-check all configuration requests and make accurate predictions on if a configuration is possible and valid. The host system will be able to also use the rules system to provide immediate feedback to a GUI user if the configuration they are creating is valid. The Rules system is not the last stand against illegal or bad configurations, but it should cover the majority of cases. Additional coded checks within the gaming machine should be made to ensure that an error in a configuration rule does not allow illegal configuration. For every rule, the final result must be true, or the option will be considered invalid. Multiple rules can be applied to any Option. It may be advantageous to have multiple rules than a single large rule consisting of a series of ands. This allows error reporting to be more specific. Rules will be similar to c style expressions, and can reference other options by their name. To refer to another option by name, the [OptionName:defaultValue] operator may be used. The OptionName is the name of the option being referred to, the defaultValue is the value that is returned if OptionName is not found.
Operation of an Embodiment
FIG. 4 is a sequence diagram illustrating the operation of one embodiment of the system. The diagram shows the communication between the configuration client 401, configuration manager 402, host interpreter 403 and host system 404. The configuration client 401 regidters its handler 405 and option 406 with configuration manager 402. Configuration manager 402 sends the configuration change 407 and game ready event 408 to the host interpreter 403. The host interpreter 403 sends an option update 409 to the host system 404.
The host system 404 returns a configuration change 410 to the host interpreter 403, which sends a test set configuration 411 to the configuration manager 402. The configuration manager 402 tests the rules 412 and returns the test results 413 to the host interpreter 403. If the test fails, the host interpreter 403 reports errors 414 to the host system 404. Otherwise the host interpreter 403 sends set values 415 to the configuration manager 402 who sends a change handler to configuration client 416. Host interpreter 403 reports success 417 to the host system 404.
Flow Diagram
The system does not change the configuration at an EGM unless the new configuration has been tested and validated. Referring to FIG. 5, at step 501 a configuration change provided to an EGM. At step 502 the EGM tests the configuration change for validity. If not valid at step 503, the system returns an error at step 504. Otherwise the system checks whether there are more changes at step 505. If so, the system returns to step 502 to validate those changes. Otherwise the system applies all of the changes at once at step 506. In one embodiment this means writing the changes to a block in an NVRAM at the EGM and then applying the changes to the EGM by applying the configuration parameters to the appropriate controllers in the EGM. At step 507 the system reports success to the server.
Because the configuration of the EGM is stored in NVRAM, the EGMs can recover from power failures more easily than before. Upon repower, all the configuration parameters are still present in the NVRAM and available for configuring the machine. In addition, the EGM can periodically broadcast its configuration state to a server as necessary.
In one embodiment, the system permits configuration changes from a handheld device that may be used by authorized personnel near the EGM. This may be particularly useful for controlling the audio volume of EGMs on a casino floor. In some cases, a standard volume level may sound louder in a particular environment or in a particular machine. The system allows a user to be adjacent an EGM and control some of the environmental parameters on the spot without needing the open the machine or shut it down. Some environmental parameters may have the ability to be changed during game play so that a player need not interrupt play on the machine while such updates are taking place.
The system also supports the downloading and storing of multiple configuration templates that are each tested for validity. In this embodiment, the server need only communicate a command to the EGM to select a previously validated, but locally stored, configuration template. In some cases, it may be desirable to having an automatically timed switch from one configuration to another based on time of day or day of week.
Tournament Mode
In one embodiment of the system, a configuration template is established that represents a tournament mode of the EGM. If it is desired to initiate tournament play on one or more EGMs.
Diagnostic Mode
The system provides the ability to obtain configuration states of an EGM and recreate field issues at a similar EGM that is located off floor for example. The issues can then be corrected and the appropriate configuration options can be provided remotely to the EGM that was originally having issues and correct it without needing to manually open the EGM. This replaces the prior art technique of taking an EGM out of play while converting it to tournament mode.
Jurisdictional Configuraton Options
Certain configuration options have to do with regulatory requirements. The system provides for those options to be visible but not reconfigurable. This permits the administration and review of EGMs for jurisdictional compliance without requiring manual inspection of the EGM.
Yield Management
One of the configuration options that can be controlled by the system is the denomination of the EGM. When coordinated with yield management algorithms, the system allows the denomination of an EGM to be easily increased or decreased as appropriate to maximize or increase yield based on real-time conditions.
The various embodiments described above are provided by way of illustration only and should not be construed to be limiting. Those skilled in the art will readily recognize various modifications and changes may be made to the embodiments, and these embodiments, while not explicity set forth, are contemplated to be a part of this disclosure.

Claims

1. A system for configuring a gaming machine comprising:

a host server having a communication link to the gaming machine and for sending a configuration change from the host server to the gaming machine;

the gaming machine in communication with the host server, the gaming machine testing the configuration change for validity and making the configuration change at the gaming machine when the configuration change is valid.

2. The system of claim 1 wherein the gaming machine communicates with the host sever via a host interpreter.

3. The system of claim 2 wherein the gaming machine includes a configuration server communicating with the host interpreter and with a game client.

4. The system of claim 3 wherein the gaming machine returns an error when the configuration change is not valid.

5. The system of claim 4 wherein the configuration change is stored in a storage means.

6. The system of claim 5 wherein the storage means is NVRAM.

7. A system for configuring a gaming machine comprising:

a host server defining a configuration having one or more configuration options and establishing communication link between the host server and the gaming machine;

a gaming machine receiving the configuration template, testing the configuration template for validity, and configuring options on the gaming machine in accordance with the configuration template when the configuration template is valid.

8. The system of claim 7 wherein the configuration template comprises an XML file.

9. The system of claim 8 wherein the gaming machine may provide the configuration template to other gaming machines for use.

10. The system of claim 8 wherein the configuration template is valid only if all options of the configuration template are valid.

11. The system of claim 7 wherein the gaming machine stores a current configuration status in memory on the gaming machine.

12. The system of claim 11 wherein the gaming machine communicates the current configuration status to the host server.