U.S. patent application number 11/530875 was filed with the patent office on 2008-09-04 for method for configuration.
Invention is credited to Christopher P. Arbogast, Thomas E. Buckeyne, Ronald A. Cadima, Robert W. Crowder, Anthony E. Green, Travis William Green, William K. Jones, Joshua D. Larsen, Pravinkumar Patel, Dale M. Shepherd.
Application Number | 20080214307 11/530875 |
Document ID | / |
Family ID | 39733510 |
Filed Date | 2008-09-04 |
United States Patent
Application |
20080214307 |
Kind Code |
A1 |
Arbogast; Christopher P. ;
et al. |
September 4, 2008 |
Method for configuration
Abstract
A method 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.
Inventors: |
Arbogast; Christopher P.;
(Reno, NV) ; Green; Travis William; (Washoe
Valley, NV) ; Jones; William K.; (Incline Village,
NV) ; Shepherd; Dale M.; (Reno, NV) ; Cadima;
Ronald A.; (Las Vegas, NV) ; Buckeyne; Thomas E.;
(North Las Vegas, NV) ; Green; Anthony E.;
(Henderson, NV) ; Patel; Pravinkumar; (Las Vegas,
NV) ; Crowder; Robert W.; (Las Vegas, NV) ;
Larsen; Joshua D.; (Las Vegas, NV) |
Correspondence
Address: |
STEPTOE & JOHNSON LLP
2121 AVENUE OF THE STARS, SUITE 2800
LOS ANGELES
CA
90067
US
|
Family ID: |
39733510 |
Appl. No.: |
11/530875 |
Filed: |
September 11, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60716713 |
Sep 12, 2005 |
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
G07F 17/3223 20130101;
G07F 17/323 20130101; G07F 17/32 20130101; G07F 17/3227 20130101;
G07F 17/3225 20130101 |
Class at
Publication: |
463/42 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method for configuring a gaming machine comprising:
establishing communication between a host server and the gaming
machine; sending a configuration change from the host server to the
gaming machine; testing the configuration change for validity;
making the configuration change at the gaming machine when the
configuration change is valid.
2. The method of claim 1 wherein the gaming machine communicates
with the host sever via a host interpreter.
3. The method of claim 2 wherein the gaming machine includes a
configuration server communicating with the host interpreter and
with a game client.
4. The method of claim 3 wherein the gaming machine returns an
error when the configuration change is not valid.
5. The method of claim 4 wherein the configuration change is stored
in a storage means.
6. The method of claim 5 wherein the storage means is NVRAM.
7. A method for configuring a gaming machine comprising: defining a
configuration template at a host server having one or more
configuration options; establishing communication between the host
server and the gaming machine; sending the configuration template
to the gaming machine; testing the configuration template for
validity; configuring options on the gaming machine in accordance
with the configuration template when the configuration template is
valid.
8. The method of claim 7 wherein the configuration template
comprises an XML file.
9. The method of claim 8 wherein the gaming machine may provide the
configuration template to other gaming machines for use.
10. The method of claim 8 wherein the configuration template is
valid only if all options of the configuration template are
valid.
11. The method of claim 7 wherein the gaming machine stores a
current configuration status in memory on the gaming machine.
12. The method of claim 11 wherein the gaming machine communicates
the current configuration status to the host server.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] 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.
[0004] 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.TM.
touch-screen display). Accordingly, there are a large number of
EGMs and related components that need to be monitored, maintained,
and serviced.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] Accordingly, there remains a need to provide a system for
updating and configuring EGMS and other networked components.
SUMMARY
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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
[0016] FIG. 1 illustrates an embodiment of a gaming network that
may be used with the system.
[0017] FIG. 2 is a block diagram of an alternate embodiment of a
gaming network that may be used with the system.
[0018] FIG. 3 is a block diagram of an embodiment of the
system.
[0019] FIG. 4 is a sequence diagram illustrating one embodiment of
the operation of the system.
[0020] FIG. 5 is a flow diagram of an embodiment of the system.
DETAILED DESCRIPTION
[0021] 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.
[0022] 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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] The network may be shared among other casino network
systems, or an exclusive network dedicated to configuration
activities.
[0027] 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.
[0028] 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.
[0029] 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:
[0030] Inspect the option and their respective settings without
making any changes.
[0031] Modify a single option setting.
[0032] Modify many options settings.
[0033] Modify all option settings.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] Furthermore, there are many combinations of selecting
subsets of options. Option subsets such as, but not limited to, the
following are typical:
[0038] Cabinet & peripheral options
[0039] Communication options
[0040] Money handling options
[0041] Game options (there may be game options that affect all
games on the EGM. There can be options that are defined 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.)
[0042] Progressive options
[0043] Bonus options
[0044] Player tracking options
[0045] There are several combinations of specifying the applied
conditions.
[0046] The network topology may be altered to accommodate the
following communication schemes:
[0047] `Home-run` network where a dedicated communication line is
routed from each EGM to the CSP, including but not limited to
Ethernet network schemes.
[0048] Multi-drop asynchronous serial network where a common
communication line is routed from the CSP to an EGM, then from EGM
to EGM.
[0049] Multi-drop synchronous serial network where a common
communication line is routed from the CSP to an EGM, then from EGM
to EGM.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] Configuration Options
[0055] The options that can be configured by the system includes,
but is not limited to, the following examples.
[0056] Configuration Category Game Sounds
[0057] User Feedback
[0058] Game Play
[0059] Attract Mode
[0060] Configuration Category User Feedback Definitions
[0061] Play Buttons
[0062] Operator Buttons
[0063] Bill in Sounds
[0064] Bill in Sounds
[0065] Coin in sounds
[0066] Coin in sounds
[0067] Jackpot Sounds
[0068] Jackpot Sounds
[0069] Instructional Vocals
[0070] Instructional Vocals
[0071] Configuration Category Game Play Definitions
[0072] Reel Spin duration
[0073] Win Roll Up speed
[0074] Bonus Features
[0075] Configuration Group Attract Definitions
[0076] Attract Music
[0077] Configuration Category Operator Menu
[0078] Configuration Category Limits
[0079] Credit Limit
[0080] IRS Limit
[0081] Jackpot Limit
[0082] Bill Limit
[0083] Bill Reject Limit
[0084] Configuration Category Voucher Data
[0085] Voucher Location
[0086] Voucher Address
[0087] Configuration Category Identification
[0088] Asset Number
[0089] Serial Number
[0090] Configuration Category Denomination
[0091] Denomination
[0092] Example Networks
[0093] 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 and 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.
[0094] 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.
[0095] 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.
[0096] 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.
[0097] 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.
[0098] 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.
[0099] 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.
[0100] 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.
[0101] 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.
[0102] Implementation Embodiment
[0103] 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.
[0104] An object may be created from a file:
[0105] CreateFromFile( vector<ConfigurationOption>&
Options, char*filename);
[0106] 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.
[0107] 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 "game 1/theme/volume", keeping them
separate and accurate.
[0108] 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.
[0109] 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.
[0110] Category--The Name of the Category that this object will
reside in.
[0111] Name--The Name of the Option.
[0112] Value--The Value of the Option. The creator of the Option is
responsible for filling this with the "default" value.
[0113] Type--The type of the option Value. The supported types are:
double, signed long, string, and Boolean.
[0114] Minimum--Optional, the minimum value of Value. (e.g. minimum
volume)
[0115] Maximum--Optional, the maximum value of Value. (e.g. maximum
volume)
[0116] Allowed Values--Optional, if provided, Value must be equal
to a value supplied in the allowed value list.
[0117] Allowed Value Rules--Optional, for each allowed value, this
rule will check if the allowed value will be present.
[0118] Control Type--Type of control object to display in GUI to
the operator.
[0119] Rules--Expressions that must resolve to true or non-zero
length string for Value to be considered valid.
[0120] 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.
[0121] OneTimeSettable--Boolean signifying if this option can only
be set once per rain clear.
[0122] IsSet--Boolean signifying if this option has been set at
least once since ram clear.
[0123] ReadOnlyWithCredits--Read Only With Credits signifies that
this Option can only be modified while there are no credits on the
machine.
[0124] Visible--Boolean signifies if this option can/will be
displayed to the operator.
[0125] 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.
[0126] 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.
[0127] 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)"
[0128] 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.
[0129] Some of the control types include:
[0130] 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.
[0131] Single Line Edit Box--Simplest of Control Type. This is a
text box that will accept a single line of text.
[0132] Multi-Line Edit Box--This is a text box that will allow for
new lines.
[0133] Slider--This is a drag-able slider bar. To use, provide a
min and max. Also supports allowed value list.
[0134] CheckBox--Used for Boolean options. May be checked or
un-checked by operator.
[0135] CheckBoxArray--Used for comma delimited lists with allowed
value sets. Each selected checkbox will add a comma delimited
string to the Value.
[0136] ListBox--Displays Allowed Values to be chosen from by
Operator
[0137] ComboBox--Displays Allowed Values list but allows Operator
to enter a custom single line of text
[0138] RadioButton--Will list Allowed Values as Radio Button
options, and the Operator will be allowed to select one.
[0139] Storing Configuration in NVRAM
[0140] 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.
[0141] 00105] 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.
[0142] 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.
[0143] 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.
[0144] Configuration Rules
[0145] 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.
[0146] Operation of an Embodiment
[0147] 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 registers 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.
[0148] 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.
[0149] Flow Diagram
[0150] 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 is 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.
[0151] 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.
[0152] 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.
[0153] 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.
[0154] Tournament Mode
[0155] 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.
[0156] Diagnostic Mode
[0157] 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.
[0158] Jurisdictional Configuration Options
[0159] 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.
[0160] Yield Management
[0161] 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.
[0162] 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 explicitly set forth, are contemplated to be
a part of this disclosure.
* * * * *