U.S. patent application number 11/329715 was filed with the patent office on 2008-12-25 for controlled access layer system and method.
Invention is credited to James W. Morrow, Steven R. Oak, Harold K. Robb.
Application Number | 20080318685 11/329715 |
Document ID | / |
Family ID | 38256851 |
Filed Date | 2008-12-25 |
United States Patent
Application |
20080318685 |
Kind Code |
A9 |
Oak; Steven R. ; et
al. |
December 25, 2008 |
Controlled access layer system and method
Abstract
A controlled access device produces a controlled access layer in
a packet switching environment. The device includes a game
monitoring system, a plurality of Ethernet ports, an internal
switch, and an encoding mechanism. The game monitoring system
monitors and manages game accounting data. The plurality of
Ethernet ports facilitate data ingress and egress, and are
connectable to a distribution switch. The internal switch forwards
transmitted data packets from one or more ingress ports to an
egress port. The encoding mechanism encodes a first type of data
packets with a QoS high packet delivery priority, and encodes a
second type of data packets with a QoS lower packet delivery
priority.
Inventors: |
Oak; Steven R.; (Reno,
NV) ; Robb; Harold K.; (Reno, NV) ; Morrow;
James W.; (Sparks, NV) |
Correspondence
Address: |
STEPTOE & JOHNSON, LLP
2121 AVENUE OF THE STARS
SUITE 2800
LOS ANGELES
CA
90067
US
|
Prior
Publication: |
|
Document Identifier |
Publication Date |
|
US 20070077995 A1 |
April 5, 2007 |
|
|
Family ID: |
38256851 |
Appl. No.: |
11/329715 |
Filed: |
January 10, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11225770 |
Sep 12, 2005 |
|
|
|
11329715 |
Jan 10, 2006 |
|
|
|
Current U.S.
Class: |
463/42 |
Current CPC
Class: |
G07F 17/3232 20130101;
G07F 17/3209 20130101; G07F 17/323 20130101; G07F 17/32 20130101;
G07F 17/3237 20130101; G07F 17/3239 20130101; G07F 17/3234
20130101 |
Class at
Publication: |
463/042 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A controlled access device for producing a controlled access
layer in a packet switching environment, the device comprising: a
game monitoring device; a plurality of Ethernet ports for
transmitting data packets, wherein the plurality of Ethernet ports
are connectable to a distribution switch; an internal switch,
wherein the internal switch forwards transmitted data packets from
one or more ingress ports to an egress port; and an encoding
mechanism, wherein the encoding mechanism encodes a first type of
data packets with a QoS high packet delivery priority, and wherein
the encoding mechanism encodes a second type of data packets with a
QoS lower packet delivery priority.
2. The system of claim 1, wherein the first type of data packets
comprise casino game accounting data packets.
3. The device of claim 1, wherein the first type of data packets
comprise Slot Data Systems data packets.
4. The device of claim 1, wherein the second type of data packets
comprise non-casino game accounting data packets.
5. The device of claim 1, wherein the second type of data packets
comprise non-Slot Data Systems data packets.
6. The device of claim 1, wherein the packet delivery priority is
controlled at an ingress level.
7. The device of claim 1, wherein the data packets are encoded with
packet delivery priority information at the inception of the
packets on the network.
8. The device of claim 1, wherein the encoded packet delivery
priority information enables guaranteed latency levels.
9. The device of claim 1, wherein the system utilizes asynchronous
transfer mode.
10. The device of claim 1, wherein internal switch is not
controlled by port location.
11. The device of claim 1, wherein all of the first type of data
packets are forwarded before any of the second type of data packets
are forwarded.
12. The device of claim 1, wherein the first type of data packets
are generated by the controlled access device.
13. The device of claim 1, wherein the second type of data packets
are received through the ingress ports.
14. The device of claim 1, wherein the internal switch enables QoS
packet delivery priority information to be filtered and changed,
thereby preventing the second type of data packets which arrive
through the ingress ports from having an unacceptable QoS high
packet delivery priority encoding after passing through the
switch.
15. The device of claim 1, wherein the device utilizes an 802.1x
secure authentication procedure.
16. The device of claim 1, wherein the device enables real time
adjustment from a remote location of the packet delivery priority
encoded onto different data types by the device.
17. A controlled access system for producing a controlled access
layer in a packet switching environment, the system comprising: a
game monitoring system; a plurality of Ethernet ports for
transmitting data packets, wherein the plurality of Ethernet ports
include at least one ingress port and at least one egress port; an
internal switch, wherein the internal switch forwards transmitted
data packets from at least one ingress port to at least one egress
port; and an encoding system, wherein the encoding mechanism
encodes a first type of data packets with a high packet delivery
priority, and wherein the encoding mechanism encodes a second type
of data packets with a lower packet delivery priority.
18. The system of claim 17, wherein the first type of data packets
comprise casino game accounting data packets.
19. The system of claim 17, wherein the first type of data packets
comprise Slot Data Systems data packets.
20. The system of claim 17, wherein the second type of data packets
comprise non-casino game accounting data packets.
21. The system of claim 17, wherein the second type of data packets
comprise non-Slot Data Systems data packets.
22. The system of claim 17, wherein the packet delivery priority is
controlled at an ingress level.
23. The system of claim 17, wherein the data packets are encoded
with packet delivery priority information at the inception of the
packets on the network.
24. The system of claim 17, wherein the encoded packet delivery
priority information enables guaranteed latency levels.
25. The system of claim 17, wherein the system utilizes
asynchronous transfer mode.
26. The system of claim 17, wherein internal switch is not
controlled by port location.
27. The system of claim 17, wherein all of the first type of data
packets are forwarded before any of the second type of data packets
are forwarded.
28. The system of claim 17, wherein the first type of data packets
are generated by the controlled access system.
29. The system of claim 17, wherein the second type of data packets
are received through the ingress ports.
30. The system of claim 17, wherein the internal switch enables
packet delivery priority information to be filtered and changed,
thereby preventing the second type of data packets which arrive
through the ingress ports from having an unacceptable high packet
delivery priority encoding after passing through the switch.
31. The system of claim 17, wherein the system utilizes an 802.1x
secure authentication procedure.
32. The system of claim 17, wherein the system enables real time
adjustment from a remote location of the packet delivery priority
encoded onto different data types by the system.
33. A method for producing a controlled access layer in a casino
gaming environment using a controlled access device that includes a
game monitoring device, a plurality of Ethernet ports, and an
internal switch, the method comprising: receiving data packets
through at least one ingress port; identifying game accounting data
packets, if present, and identifying non-game accounting data
packets, if present; encoding the game accounting data packets with
a high packet delivery priority, and the encoding the non-game
accounting data packets with a lower packet delivery priority; and
forwarding the encoded data packets through an egress port.
34. The method of claim 33, wherein the game accounting data
packets comprise casino game accounting data packets.
35. The method of claim 33, wherein the game accounting data
packets comprise Slot Data Systems data packets.
36. The method of claim 33, wherein the non-game accounting data
packets comprise non-casino game accounting data packets.
37. The method of claim 33, wherein the non-game accounting data
packets comprise non-Slot Data Systems data packets.
38. The method of claim 33, wherein the packet delivery priority is
controlled at an ingress level.
39. The method of claim 33, wherein the data packets are encoded
with packet delivery priority information at the inception of the
packets on the network.
40. The method of claim 33, wherein the encoded packet delivery
priority information enables guaranteed latency levels.
41. The method of claim 33, wherein the method utilizes
asynchronous transfer mode.
42. The method of claim 33, wherein internal switch is not
controlled by port location.
43. The method of claim 33, wherein all of the game accounting data
packets are forwarded before any of the non-game accounting data
packets are forwarded.
44. The method of claim 33, wherein game accounting data packets
are generated by the controlled access device.
45. The method of claim 33, wherein non-game accounting data
packets are received through the ingress ports.
46. The method of claim 33, wherein the internal switch enables
packet delivery priority information to be filtered and changed,
thereby preventing the non-game accounting data packets which
arrive through the ingress ports from having a high packet delivery
priority encoding after passing through the switch.
47. The method of claim 33, further comprising: utilizing an 802.1x
secure authentication procedure.
48. The method of claim 33, further comprising: enabling real time
adjustment from a remote location of the packet delivery priority
encoded onto different data types.
49. A method for producing a controlled access layer in a packet
switching environment using a controlled access device that
includes a game monitoring device, a plurality of Ethernet ports,
and an internal switch, the method comprising: implementing an
802.1x secure authentication procedure in the controlled access
device; receiving data packets through at least one ingress port;
identifying a first type of data packets, if present, and
identifying a second type of data packets, if present; encoding the
first type of data packets with a high packet delivery priority,
and the encoding the second type of data packets with a lower
packet delivery priority; and forwarding the encoded data packets
through an egress port.
50. The method of claim 49, wherein the first type of data packets
comprise casino game accounting data packets.
51. The method of claim 49, wherein the first type of data packets
comprise Slot Data Systems data packets.
52. The method of claim 49, wherein the second type of data packets
comprise non-casino game accounting data packets.
53. The method of claim 49, wherein the second type of data packets
comprise non-Slot Data Systems data packets.
54. The method of claim 49, wherein the packet delivery priority is
controlled at an ingress level.
55. The method of claim 49, wherein the data packets are encoded
with packet delivery priority information at the inception of the
packets on the network.
56. The method of claim 49, wherein the encoded packet delivery
priority information enables guaranteed latency levels.
57. The method of claim 49, wherein the method utilizes
asynchronous transfer mode.
58. The method of claim 49, wherein internal switch is not
controlled by port location.
59. The method of claim 49, wherein all of the game accounting data
packets are forwarded before any of the non-game accounting data
packets are forwarded.
60. The method of claim 49, wherein game accounting data packets
are generated by the controlled access device.
61. The method of claim 49, wherein non-game accounting data
packets are received through the ingress ports.
62. The method of claim 49, wherein the internal switch enables
packet delivery priority information to be filtered and changed,
thereby preventing the non-game accounting data packets which
arrive through the ingress ports from having a high packet delivery
priority encoding after passing through the switch.
63. The method of claim 49, further comprising: enabling real time
adjustment from a remote location of the packet delivery priority
encoded onto different data types.
64. A controlled access system for producing a controlled access
layer in a packet switching environment over a casino gaming
network, the system comprising: a game monitoring system, wherein
the game monitoring system monitors and manages casino game
accounting data, and wherein the game monitoring system connects
internal components of a casino game to the casino gaming network
via the controlled access system; a plurality of Ethernet ports,
wherein the plurality of Ethernet ports transmits casino game
accounting data, and wherein the plurality of Ethernet ports
include at least one ingress port and at least one egress port; an
internal switch, wherein the internal switch forwards transmitted
data packets from at least one ingress port to at least one egress
port; and an encoding mechanism that generates casino game
accounting data packets, encodes a casino game accounting data
packets with a high packet delivery priority, and encodes a
non-casino game accounting data packets with a lower packet
delivery priority.
65. A controlled access system for producing a controlled access
layer in a packet switching environment, the system comprising: a
plurality of Ethernet ports for transmitting data packets, wherein
the plurality of Ethernet ports include at least one ingress port
and at least one egress port, and wherein the system utilizes an
802.1x secure authentication procedure; an internal switch, wherein
the internal switch forwards transmitted data packets from at least
one ingress port to at least one egress port; and an encoding
system, wherein the encoding mechanism encodes a first type of data
packets with a high packet delivery priority, and wherein the
encoding mechanism encodes a second type of data packets with a
lower packet delivery priority.
Description
RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent
application Ser. No. 10/943,771 filed Sep. 16, 2004, entitled
System And Method For Gaming-Content Configuration And Management
System, now pending, which is hereby incorporated herein by
reference.
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.
FIELD OF THE INVENTION
[0003] This invention relates generally to a system and method for
utilizing a controlled access device to produce a controlled access
layer in a packet switching environment, and more particularly, to
a system and method for utilizing a controlled access device that
encodes specific types of data for high priority packet delivery in
a controlled access layer of a packet switching environment.
BACKGROUND OF THE INVENTION
[0004] Today's slot machines have parameters programmed into their
code such as theme, percentage, denomination, lines bet, minimum
bet, maximum bet, game run time, and the like. Changing any of
these parameters requires new game code, regulatory approval for
the code changes, physical movement of machines weighing hundreds
of pounds and regulatory approval for the move and oversight.
[0005] Past methods of changing games on the floor have been manual
in nature. As stated above, games and their associated gaming
parameters are typically programmed into EPROMs (Erasable
Programmable Read-Only Memory) contained within the gaming
machines. Accordingly, the changing of games (or modifying gaming
parameters) requires the EPROMs to be changed. Such a procedure
involves physically opening the gaming machines, erasing and
reprogramming the code (EPROM), and re-sealing the EPROM if
required by the regulatory jurisdiction. This also requires the
entire game to be `re-optioned` which is a long, error-prone manual
process.
[0006] Furthermore, gaming machines have operated for the most part
as stand-alone devices, at least with respect to non-progressive
gaming. In this regard, while there may have existed some limited
forms of communication or networking, fully-networked data and
communication systems have not been traditionally implemented. One
reason for this lack of fully-networked infrastructure is the
difficulty in upgrading system infrastructure, due to the constant
utilization of a gaming system, 24 hours a day, 7 days a week, 365
days a year. For this reason and others, gaming machines have
typically been utilized as separate machines, which are swapped out
or upgraded, but which generally operate autonomously. It would be
desirable for gaming machines instead, to be utilized as components
of a larger interactive and symphonious organizational arrangement.
However, many obstacles have made such an arrangement difficult and
unwieldy to visualize, let alone implement.
[0007] However, the lack of such a system deprives casino owners of
both apparent and actual control over their gaming floors. Further,
casino patrons are limited in the variety and selection of both
games, and the gaming parameters within such games, that are
available to them. These limitations are commonly due to the
particularized nature and general lack of customization typically
associated with individual gaming machines. In this regard, casino
owners have become aware that by adding additional features to
gaming machines, they may be able to maintain a player's attention
to the gaming machines for longer periods of time. This, in turn,
leads to the player wagering at the gaming machine for longer
periods of time, thereby increasing casino profits.
[0008] One technique that has been employed to maintain a player's
attention at the gaming machine has been to provide players with
access to gambling-related information. Moreover, it would be
desirable to provide the player with interactive access to the
above information. This type of interactivity would allow players
significantly more flexibility to make use of the above-described
information. The gambling-related information could also be
utilized by the player in a much more efficient manner. In this
regard, greater levels of flexibility and access are likely to make
a player remain and gamble at the gaming machine for significantly
longer periods of time. Unfortunately, the system components that
are currently utilized for displaying and accessing this type of
information, such as external keypads and display modules, are
extremely limited in the functionality and capabilities that they
provide, thus limiting the success of their ability to maintain a
player's attention.
[0009] As technology advances in the casino gaming environments,
the network architecture is moving towards high-speed Ethernet
networks (or other standard broadband protocol) that replace the
previous serial networks and proprietary data acquisition systems.
Often, the network architecture in these Ethernet gaming networks
has a very controlled access layer environment. In this regard,
sometimes the network architecture utilizes a layered network
topology.
[0010] The first or top layer is typically referred to as the core
layer, which is the backbone of the system. In this layer there are
usually very robust and high-speed switches in a data center
environment. These switches can process packets very rapidly.
Preferably, only decisions relating to packet destination and
packet transmission are made in the core layer.
[0011] The next layer, which connects to the core layer, is
typically referred to as the distribution layer. The primary job of
the distribution layer is aggregation and routing. Often this layer
raises the network frames at OSI (Open System Interconnect) layer 2
to routable packets at OSI layer 3.
[0012] The base layer is typically referred to as the access layer.
The access layer is the starting point for most traffic on the
network. The access or workgroup layer connects users and devices.
Important functions of the access layer include shared bandwidth,
switched bandwidth, MAC-layer (Media Access Control layer)
filtering, and micro segmentation. A MAC address refers to a
hardware address that uniquely identifies a node of a network. The
access layer is designed to pass traffic to the network for valid
network users and to filter traffic that is passed along through
the network. Typically, the access layer is the point at which end
users are connected to the network. Additionally, the access layer
provides the means to connect to the devices located in the
distribution layer, as well as providing connections to both local
and remote devices. Security and policy decisions are also made at
the access layer since the access layer is the entry point to the
network.
[0013] The prior data acquisition systems have typically been based
on a proprietary network that utilized a serial protocol standard.
While the data rates of such prior systems were relatively slow
((7.2 kbs) in comparison to even the slowest Ethernet speeds (10
Mbs)), these prior networks were single-use networks with the sole
purpose of communicating the SDS (Slot Data Systems) information
(or other similar game accounting information) to and from the
floor.
[0014] An Ethernet network, having significantly more bandwidth,
would typically be utilized as a shared network where the SDS (or
other similar game accounting protocol) is only an application that
runs on the network along with other applications and servers.
Instead of controlling a proprietary network, a prior casino
network might even be integrated into an existing casino Ethernet
network.
[0015] Typically, the prior serial networks did not support many
new technologies such as iView devices (i.e., player tracking user
interface devices), System Gaming, and game downloads. Additional
technologies are also likely to follow once more bandwidth is made
available. With these new technologies, many of which are
bandwidth-intensive, there is a growing need to ensure that SDS
data (or other similar game accounting data) maintains precedence
and consistently arrives at the SDS server without loosing
data.
[0016] One relevant LAN (local-area network) technology is known as
Quality of Service (QoS). This technology allows the network to
place certain packets at a higher priority than other packets to
ensure timely delivery. Normally, networks are "best effort"
delivery. QoS adds in the ability to prioritize certain packets for
a better and more controlled delivery. Typically, QoS is used is to
ensure timely delivery of data in applications such as a Voice over
IP network (VoIP). Instead of the "first-in-first-out," best effort
delivery of many shared networks, QoS ensures-timely delivery of
data with virtually no packet loss. Similarly, in the casino
environment, game accounting data also requires that data packets
are delivered in a timely fashion with no packet loss.
[0017] Referring again to VoIP, since VoIP data (and now streaming
video, video conferencing, and the like) is very sensitive to
network delay, under QoS the VoIP packets are given a priority that
places the VoIP packets into a high priority queue. The high
priority queue is serviced until empty while other less sensitive
data waits in another lower priority queue or queues. Since
technologies like VoIP are industry standards, most switches
recognize them and supply a QoS designation to ensure that VoIP
packets take precedence in any communication stream.
[0018] Referring again to an access layer of a layered network, it
is beneficial to make policy decisions at the access layer because
this is usually the "ingress level." The ingress level is the point
in the system where packets enter the network. Accordingly, this is
a timely point at which to examine the packets and make policy
decisions based on the packet information.
[0019] Typically, there are two ways to prioritize data packets
using QoS. Using one technique, a QoS aware access switch uses the
port location on the switch to indicate in which port the high
priority is located. However, in this scenario, there is nothing to
stop personnel from either accidentally or intentionally moving the
plug to a different port location, thus giving whatever is plugged
into the high priority port the highest priority, and giving the
intended high priority data the lower priority. This could possibly
lead to packet loss of the intended high priority data.
[0020] Another technique to supply the QoS information uses a
non-controlled device but encodes the QoS code into the IP packets
of the intended high priority data. This technique provides the
right encoding, but is required to be performed in a Controlled
Access environment. The problem with using a non-controlled device
stems from the potential for a third party to program their game
(or other device) to download packets with a high priority QoS
code, thus making this game compete for bandwidth with the intended
high priority data. Even if the access switch has the capabilities
to filter and change the QoS information, this functionality is
typically related to the port location, and thus, involves the same
problems noted above. While some high-end switches offer a QoS
filter for MAC addresses (the internal address of the Ethernet
port), this type of filtering presents significant problems and is
difficult to administer.
[0021] Accordingly, there exists a continuing need for a system or
method for non-industry standard IP communication to be labeled for
high quality delivery. The preferred embodiments of the system and
method described herein clearly address these and other needs.
SUMMARY OF THE INVENTION
[0022] Briefly, and in general terms, the claimed invention
resolves the above and other problems by providing a configuration
and management system for monitoring and controlling one or more
gaming devices in a gaming system on at least one gaming floor. The
system includes: one or more gaming devices in a gaming system; a
processing and control system; and a server-side, graphical user
interface including an interactive map of the gaming floor.
Preferably, the one or more gaming devices in the gaming system, as
well as the processing and control system, are interconnected via a
network. The processing and control system acquires gaming
performance data from the gaming devices in the gaming system. The
server-side, graphical user interface includes an interactive map
of the gaming floor. Additionally, the graphical user interface
enables monitoring of the gaming performance data from the gaming
devices in the gaming system. Further, the graphical user interface
enables configuration of multiple gaming platform capabilities,
multiple game titles, and multiple gaming parameters for each
gaming devices on the gaming floor. Preferably, the graphical user
interface is interconnected to the processing and control
system.
[0023] In another preferred embodiment, the network is a
packet-based communication network. In one such embodiment, the
packet-based communication network comprises an IP-based message
set that utilizes an interface layer between command-driven devices
and logical communication channels. Continuing, in such an
embodiment, the packet-based communication network implements the
BOB (best of breed) protocol, SuperSAS protocol, or other similar
packet-based protocol (e.g., G2S (Gaming 2 System)).
[0024] In another aspect of a preferred embodiment, the gaming
devices include, by way of example only, and not by way of
limitation: electronic gaming machines; embedded components,
including game monitoring units, and player tracking user
interfaces; gaming-related signage; and kiosks. Preferably, the
gaming systems that are controllable by the configuration and
management system include casino venues, class II venues, and
lottery venues. In one aspect of a preferred embodiment, the gaming
performance data includes, by way of example only, and not by way
of limitation: coin-in activity, coin-out activity, meters,
accounting information, security information, and player rating
information. In still another aspect of a preferred embodiment, the
gaming platform capabilities include platform-specific control over
functions including, by way of example only, and not by way of
limitation: volume settings, speed of play, hopper limits, log
access, platform-specific reports, and asset information, including
software and hardware bills of material. Preferably, the gaming
platforms include, by way of example only, and not by way of
limitation: Alpha, S6000, and Game Maker 2.
[0025] Other features and advantages of the claimed invention will
become apparent from the following detailed description when taken
in conjunction with the accompanying drawings, which illustrate by
way of example, the features of the claimed invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0026] FIG. 1 illustrates a relational diagram of a gaming-content
configuration and management system for controlling and managing a
gaming system that includes gaming devices on a casino floor
connected through networking equipment to multiple tiers of servers
on the casino backend, wherein the operators manage the gaming
floor from a computer via a graphical user interface;
[0027] FIG. 2 illustrates a map of the casino gaming floor via the
graphical user interface of the gaming-content configuration and
management system;
[0028] FIG. 3 illustrates another view of a map of the casino
gaming floor via the graphical user interface of the gaming-content
configuration and management system;
[0029] FIG. 4 illustrates a relational diagram of protocols
implemented by a gaming-content configuration and management system
for controlling and managing a gaming system that includes gaming
devices on a casino floor connected through networking equipment to
multiple tiers of servers on the casino backend;
[0030] FIG. 5 illustrates a front view of an IP gaming hub,
constructed in accordance with the invention; and
[0031] FIG. 6 illustrates an system diagram of IP gaming hubs in an
access layer connecting to a Distribution Layer and a Core
Layer.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0032] Briefly stated, a preferred embodiment of the gaming-content
configuration and management system is directed towards configuring
and managing a scalable number of gaming devices using a
centrally-connected user interface. The system configures and
manages components that are multi-platform, multi-theme,
multi-percentage, and multi-denomination. These gaming devices
include, by way of example only, and not by way of limitation,
electronic gaming machines (EGMs); embedded components, such as
GMUs (Game Monitoring Units); and/or player tracking user
interfaces (referred to sometimes herein as iView devices or Alpha
devices). Such gaming devices further include any uniquely
identifiable entity on the gaming floor, including by way of
example only, and not by way of limitation, gaming-related signage
and kiosks.
[0033] Referring now to the drawings, wherein like reference
numerals denote like or corresponding parts throughout the
drawings, and more particularly to FIGS. 1-4, there is shown a
preferred embodiment of gaming-content configuration and management
system 10. Specifically, FIGS. 1 and 2 show a gaming-content
configuration and management system 10 that enables configuration,
management, and delivery of content on a game floor 40 from a
computer 50 via a graphical user interface 70.
[0034] In a preferred embodiment, the system 10 is responsible for
the configuration, management, and download of code 20 (i.e.,
content) to gaming devices 30 (e.g., gaming machines, gaming
machine component, system components, network components, kiosks,
signage, gaming-related devices, and the like) on the gaming floors
40 of incorporated gaming venues. Preferably, such gaming venues
include casinos, Class II venues, and lottery venues. In one
preferred embodiment of the gaming-content configuration and
management system 10, gaming machines 30 and system components are
incorporated into a broadband-networked gaming floor 40, instead of
operating independently (or quasi-independently) as stand-alone
platforms and basic monitoring systems.
[0035] As briefly mentioned above, in one preferred embodiment, the
gaming-content configuration and management system 10 enables
operators to manage the gaming floor 40 from a desktop computer 50
(or other portable computer or hand-held device) via a graphical
user interface 70 on the computer. Preferably, the gaming-content
configuration and management system 10 is capable of administrating
gaming floors 40 ranging in size from a single slot floor to a
worldwide gaming enterprise. In a preferred embodiment, the system
10 administrates gaming devices 30 on floors 40 that are
multi-platform 60, multi-theme, multi-percentage, and
multi-denomination. Otherwise stated, in such an embodiment, each
of the gaming devices 30 (or at least some gaming devices 30)
incorporates multiple game platforms 60, incorporates multiple game
titles (stored locally or remotely), is capable of being configured
to generate multiple different payout percentages, and is capable
of offering multiple different monetary denominations for game
play. Central management of all these gaming options is enabled
from the graphical user interface 70.
[0036] Accordingly, in a preferred embodiment of the gaming-content
configuration and management system 10, a graphical user interface
70 is accessible via a gaming floor operator's computer 50. In such
an embodiment, as shown in FIGS. 2 and 3, a graphical user
interface 70 displays a map 74 of the slot floor 40. Preferably,
this map 74 of slot floor 40 includes multiple selectable layers
80. Gaming-related information is organized by layer 80; with each
layer displaying a different category of gaming-related
information. In one specific, non-limiting embodiment, a first
layer 80 displayed on the graphical user interface 70 shows game
themes (i.e., game titles) that are currently populating the slot
floor 40. Preferably, each game theme is emphasized with a distinct
color in order to differentiate one game theme from another game
theme. Continuing, in this specific, non-limiting embodiment, a
second layer 80 of the map 74 displays information that relates to
device volume settings. In this manner, each layer 80 displayed on
the graphical user interface 70 presents different gaming-related
information including, by way of example only, and not by way of
limitation, coin-in activity, coin-out activity, meters, other
accounting information, security information, and player rating
information.
[0037] A preferred embodiment of the gaming-content configuration
and management system 10 presents customers with a consistent,
intuitive, front-end interface 70 to all incorporated gaming
devices 30. Preferably, tabs at the bottom of the graphical user
interface 70 direct the operator from the configuration manager
screen to other screens that control backside servers and/or
services including, by way of example only, and not by way of
limitation: MCC server 90, SDG server 92, CMP server 94, MindPlay
server 96, SDS server 98, ACSC server 100, and the like. In a
preferred embodiment, the graphical user interface 70 for the
gaming-content configuration and management system 10 is an "entry
point" (i.e., front-end interface) for all incorporated gaming
devices 30. As such, the graphical user interface 70 of the
gaming-content configuration and management system 10 provides a
consistent "look and feel" for the operator as they use associated
products. This same look and feel of the graphical user interface
70 is expandable over time to include various methods of user
access to other categories of information, such as accounting,
cage, and security across all back office servers (e.g., MCC server
90, SDG server 92, CMP server 94, MindPlay server 96, SDS server
98, ACSC server 100, and the like).
[0038] Within each gaming platform 60 (e.g., Alpha, S6000, Game
Maker 2, EVO3, and the like) the gaming-content configuration and
management system 10 enables control of game theme (i.e., game
title), game percentage payout, and game denomination. Thus, the
configuration and management system 10 is able to control and
manage a multi-platform 60, multi-theme, multi-percentage, and
multi-denomination gaming floor 40. Additionally, a preferred
embodiment of the gaming-content configuration and management
system 10 also includes platform-specific control over functions
such as the volume setting of the device, speed of play, hopper
limits, and the like. Moreover, in a preferred embodiment, these
functions further include, by way of example only, and not by way
of limitation: access to logs, platform-specific reports, and asset
information (e.g., software and hardware bills of material).
[0039] Thus, the configuration and management system 10 is capable
of controlling game selection and gaming-related parameters, as
well as controlling platform-specific functions. In a preferred
embodiment of the configuration and management system 10, each
gaming platform 60 has uniquely-controllable configurations, and
the system 10 is capable of providing configuration and management
control specific to each gaming platform 60. For example, the S6000
platform 60 sets and controls options in a different manner than
the Alpha platform 60. In this regard, an Alpha platform 60 may
have multiple methods for option setting (e.g., the platform may
have a method for setting options for Class II gaming that is
different from the method for setting options for Class III
gaming). However, the configuration and management system 10 is
capable of providing configuration and management control specific
to each gaming platform 60.
[0040] In a preferred embodiment, the gaming-content configuration
and management system 10 merges the capabilities of commercial
system management products with the capabilities of commercial
operating systems (e.g., Linux.RTM., Windows.RTM., or the like).
Further, in one preferred embodiment, the gaming-content
configuration and management system 10 is utilized in combination
with the current SAS protocol, serial-based communication
infrastructure. In one such embodiment, the gaming-content
configuration and management system 10 employs several previously
un-implemented poll codes contained in the SAS6.01 protocol. A
preferred embodiment of the gaming-content configuration and
management system 10, which utilizes this SAS protocol,
serial-based communication network, (or similar non-SAS protocol,
serial-based communication network) is referred to as Phase 1 of
the configuration and management system 10.
[0041] In another preferred embodiment of the gaming-content
configuration and management system 10, an IP-based (or other
packet-based) communication network is implemented, which connects
the gaming devices 30 in the system. An IP-based message set
utilizes an interface layer between command-driven devices and
logical communication channels. This embodiment of the
gaming-content configuration and management system 10, which
utilizes an IP-based (or other packet-based) network format, is
referred to as Phase 2 of the configuration and management system
10. In one specific, non-limiting embodiment of a Phase 2 system
10, the SuperSAS protocol is implemented as the communication
protocol. In another specific, non-limiting embodiment of a Phase 2
system 10, a different packet-based protocol (or other event-driven
communication) is implemented as the communication protocol
(TCP/IP, Frame Relay, and the like).
[0042] Referring again to Phase I of the gaming-content
configuration and management system 10, in one preferred
embodiment, the system modifies various platforms 60 (Alpha, S6000,
GameMaker2) to enable selection of game theme (i.e., game title),
game payout percentage, and game play denominations through the use
of SAS6.01 commands. This configuration process enables
platform-specific control over specific platform capabilities
including, by way of example only, and not by way of limitation:
volume setting of the device, speed of play, hopper limits, and the
like.
[0043] In a preferred embodiment of Phase 1 of the gaming-content
configuration and management system 10, the system identifies the
configuration and control capabilities available in each gaming
device 30, and targets those controllable capabilities remotely
using the SAS6 protocol (or other non-SAS serial-based protocol).
After identifying and targeting the available configuration and
control capabilities, this protocol enables an administrator to
configure and manage the existing systems, networks, gaming devices
30, and platforms 60 (e.g., NT+, Gearbox, MC250,GameNet, Alpha,
Game Maker II, S6000, Mcc-Axiomtek, and SDG game controller).
[0044] Preferably, in the Phase 1 version of the gaming-content
configuration and management system 10, the SAS6 configuration
control "long polls" are implemented on all platforms 60.
Additionally, any integrated networks and systems are modified to
send these poll codes. Further, the graphic user interface 70 in
the system 10 is configured to control these poll codes.
[0045] Specifically, targeted SAS6 poll codes include, by way of
example only, and not by way of limitation: (A) Shutdown (lock out
play); (B) Startup (enable play); (C) Sound off (all sounds
disabled); (D) Sound on (all sounds enabled); (E) Reel spin sound
disabled; (F) Enable bill acceptor; (G) Disable bill acceptor; (H)
Configure bill denomination; (I) Enable/disable game n; (J) Set
sound volume; (K) Play sound; (L) Enable/disable real time
reporting; (M) Send gaming machine ID# and information; (N) ROM
signature verification; (O) Send EFT log; (P) Send current hopper
status; (Q) Send total number of games implemented; (R) Send game n
configuration; (S) Send SAS version ID, gaming serial no.; (T) Send
selected game number; (U) Send enabled game numbers; (V) Send
authentication info; (W) Send current date and time; (X) Receive
general ASCII message; (Y) Simulate user input; (Z) Send enabled
features; (AA) Send cash out limit; (BB) Enable/disable game auto
rebet; (CC) Send extended game n info; (DD) Send enabled player
denominations; and (EE) Send extended game n info. Additionally,
there are SAS general poll exception commands, such as: (A)
Operator changed options (configuration options); (B) System
validation request; and (C) Game locked.
[0046] Referring now to Phase 2 of the gaming-content configuration
and management system 10, the Phase 2 system transitions from using
SAS6 protocols (or other serial-based network format) to instead
utilizing broadband communications (e.g., Ethernet, TCP/IP, or
other packet-based network format). The Phase 2 of the
gaming-content configuration and management system 10 also enables:
(1) Web-based communications (e.g., BOB, SuperSAS, G2S, and the
like), (2) access to logs and reports specific to the platform, and
(3) downloading of new code and advertising content. Preferably, a
SMS (Systems Management Server) client agent is also added to the
platforms 60 in Phase 2 of the gaming-content configuration and
management system 10.
[0047] In another aspect of a preferred embodiment, Phase 2 of the
gaming-content configuration and management system 10 also includes
the control and auditing of system configurations. For example, the
reporting and settings options in a SDS server 98 are typically
different than settings options in an MCC server 90, SDG server 92,
or ACSC server 100. However, a preferred embodiment of the
gaming-content configuration and management system 10 is able to
control and audit each of these system configurations. In another
aspect of a preferred embodiment, an iView device 30 is controlled
by the gaming-content configuration and management system 10, which
has setup and control options that are unique in each of the NT,
Kontron board, and Mcc implementation.
[0048] In a preferred embodiment of the gaming-content
configuration and management system 10, platforms 60 include
Ethernet hardware, TCP/IP stacks, http stacks, SOAP (or the
proprietary layer SuperSAS), and XML handling capability.
Preferably, system management client agents for each platform and
each system are employed. In one preferred embodiment, these
elements are added to each platform and are "hooked" into the
platform code in order to tie XML messages to game logic. In
another aspect of one preferred embodiment that utilizes on Alpha
platform 60, a SMS client for Linux is implemented in order to
support the Alpha platform.
[0049] Referring again more specifically to FIGS. 2 and 3, in a
preferred embodiment of the gaming-content configuration and
management system 10, the graphical user interface 70 displays the
slot floor (or multiple slot floors) to the gaming floor
administrators on their computers 50. Specifically, the graphical
user interface 70 preferably presents a map 74 of the gaming floor
and incorporates the use of selectable layers 80 (for organizing
information) and colors (for emphasizing information). The layers
80 are selectable in order to present various types of information
by layer, including by way of example only, and not by way of
information: occupancy, level of handle, sound level, heat,
accounting, and performance measurements.
[0050] In one preferred embodiment, the graphical user interface 70
is extended to incorporate all user input screens. In this manner,
users have a consistent "front-end" experience when working with
any of the included user input screens, such as for the cage,
accounting, security, and the like.
[0051] In one preferred embodiment of the Phase 1 system 10,
information obtained from gaming devices 30 on the floor by the
SAS6 protocol (or other suitable protocol) is translated by the
graphical user interface 70 into a multi-dimensional graphic form
that includes geographic location (e.g., country, state facility,
slot floor position, and the like) and value (e.g., hi, lo, medium,
empty, full, and the like) which are preferably represented by
different colors. As mentioned above, in a preferred embodiment,
the graphical user interface 70 includes information on available
game themes, game payout percentages, and available game play
denominations. Further, the graphical user interface 70 not only
displays this information, but also enables an operator to
configure the gaming devices 30 on the gaming floor remotely from a
computer 50 via the graphical user interface. In this manner, the
graphical user interface 70 enables an operator to select a single
gaming device 30, or a group of gaming devices 30, and change their
configuration (theme, percentage, denomination, and the like).
Additionally, the graphical user interface 70 preferably enables
the scheduling of changes. Other configuration setting provided by
SAS6 (or other suitable protocol) and the platforms 60 are also
presentable and configurable, via the graphical user interface
70.
[0052] In a preferred embodiment, the graphical user interface 70
of the Phase 1 system 10 is an analysis program that provides
front-end, user interface functionality including, by way of
example only, and not by way of limitation: data analysis tools,
scheduling capabilities, and messaging resources for sending
messages back to the slot system. In comparison, the graphical user
interface 70 of the Phase 2 system 10 adds links into each of the
expanded back office server offerings (e.g., MCC server 90, SDG
server 92, CMP server 94, MindPlay server 96, SDS server 98, ACSC
server 100, and the like), as well as network management
capabilities. This graphical user interface 70 also enables
expansion to other applications. Otherwise stated, the graphical
user interface 70 of the Phase 2 system 10 becomes a "portal"
through which casino executives have access to all properties
services. In one specific, non-limiting preferred embodiment, a
first tab is associated with slot floor analysis; a second tab is
associated with network management (linking the user to a network
management software application such as HP OpenView); a third tab
is associated with whichever expanded system offerings (i.e., back
office servers) the customer has implemented on the slot floor
system (e.g., MCC server 90, SDG server 92, CMP server 94, MindPlay
server 96, SDS server 98, ACSC server 100, and the like); and a
fourth tab is associated with CMP (or SMS) for player marketing. In
one preferred embodiment, the graphical user interface 70 is
further expandable to include hospitality and POS links.
[0053] In a preferred embodiment, the gaming-content configuration
and management system 10 performs content management of game code,
data, and configuration. A preferred embodiment of a gaming-content
configuration and management system 10 accommodates slot floor (or
entire corporate organization) having from hundreds to tens of
thousands of gaming devices 30. Further, a preferred system 10 is
capable of controlling and managing multiple platforms 60 from
multiple platform manufacturers. Additionally, a preferred system
10 is capable of controlling and managing multiple themes (i.e.,
game titles) on each platform 60. Moreover, a preferred system 10
is capable of controlling and managing multiple percentages and
multiple denominations for each theme. In a preferred embodiment,
each combination of
"company/location/cabinet/theme/percentage/denomination" is defined
herein as a gaming combination. In a preferred embodiment of a
gaming-content configuration and management system 10, each gaming
combination has a configuration that needs to be stored, monitored,
and managed. Additionally, each gaming combination that is
controlled and managed by the system 10 has associated
configurations, assets, and logs. All of this data is stored and
organized by the system 10 to provide users, regulators, and
company personnel with access, management, and control
capabilities.
[0054] In a preferred embodiment of the gaming-content
configuration and management system 10, the process for signing
content 20 is supported through the use of the SAS6 protocol (or
other similar protocol). Preferably, the process for signing
content 20 leverages the capabilities of the iView content signing
procedures. Additionally, in a preferred embodiment of the
gaming-content configuration and management system 10, a directory
structure and filing system is implemented for game theme tables,
platform options settings (configuration), and access logs that are
enabled in SAS6. In one preferred embodiment, Microsoft Sharepoint
Server is utilized as the directory structure and filing system.
Preferably, Microsoft Server 2003 (or higher) is the server
operating system (OS) for the gaming-content configuration and
management system 10.
[0055] In a preferred embodiment of the Phase 2 system 10, all
content 20 (e.g., platform OS code, game theme code, platform
options-configuration, logs by cabinet, advertising content-skins,
and the like) is securely stored at a level sufficient to satisfy
gaming regulators. These security measures include, by way of
example only, and not by way of limitation, physical security
requirements, access requirements, logging requirements, and update
requirements. In a preferred embodiment of the Phase 2 system 10,
the procedure for authenticating code 20 with gaming regulations is
to require a server to meet the same compliance requirement as a
gaming device 30. In this manner, the server (and contained code)
is subject to corresponding gaming device regulations. For content
20 such as options-configurations and advertising content (e.g.,
skins), an authentication procedure is implemented that links the
production of new content into storage and subsequent
authentication signing.
[0056] In another aspect of a preferred embodiment, the
gaming-content configuration and management system 10 further
includes a distribution management component. Briefly stated, the
distribution management component transmits bulk data from a
backend server to the gaming floor. Movement of large files to
particular platforms 60 on the floor must be performed without
disrupting the primary use of the gaming floor (i.e., making money
through the support of gaming-related transactions). Thus, large
files of bulk data are moved "in the background" over otherwise
unused network bandwidth so as not to adversely affect
gaming-related transactions.
[0057] Accordingly, in a preferred embodiment of the gaming-content
configuration and management system 10, platforms 60 (i.e.,
clients) and systems (i.e., servers) are capable of downloading
large files of bulk data while game play is in progress.
Preferably, this download process is schedule-able and monitor-able
using the distribution management component. Typically, downloading
of large files (or upload of large files such as logs) takes a
large amount of time (on the order of hours, days, or long periods
of time). In a preferred embodiment, the download is performed at
the request of the client (i.e., the platform 60). As such, the
client and network load combine to determine the proper time and
speed for a download (or upload) to take place. In a preferred
embodiment of the gaming-content configuration and management
system 10, the server accommodates download scheduling, ensures
minimal bandwidth impact, enables progress reporting, and
guarantees delivery, as well as setup and management of the
download (or upload) process.
[0058] In a preferred embodiment of the Phase 1 system 10, floor
control is limited to the configuration changes that are possible
through SAS (or other equivalent protocol). As such there is no
additional distribution management functionality in the Phase I
system 10. However, the broadband networking utilized in a
preferred embodiment of the Phase 2 system 10 does implement
distribution management features. In one preferred embodiment, when
the content 20 is stored on alterable media (e.g., a local hard
drive, FLASH memory, and the like) in the platform 60 (Alpha,
iView, Game Maker II, G2S, and the like), command protocols such as
GSA BOB v1.01 can be used for enabling and disabling gaming
combination. In one preferred embodiment of the Phase 2 system 10,
operators are able to modify these configuration elements (i.e.,
gaming combinations) in real time. In one specific, non-limiting
embodiment, the server communicates in the GSA BOB v1.01 command
protocol to the slot floor.
[0059] Continuing, in a preferred embodiment of the gaming-content
configuration and management system 10, distribution management
includes, by way of example only, and not by way of limitation: (1)
the act of downloading new advertising content 20 to an iView
device 30 or gaming platform 60 (2) sending down code 20 or
operating system updates, and (3) sending down a new game theme
(i.e., game title). New game themes are typically large files that
can range from around 400 Kilo-bytes to over 4 Giga-bytes in size.
Code updates are typically smaller files that range from around 20
Kilo-bytes to 400 Mega-bytes in size.
[0060] In one specific, non-limiting embodiment, a slot director
uses the gaming-content configuration and management system 10 to
schedule a download (or upload) and check on the progress of the
download. For example, in one scenario, the system 10 rolls out a
large new game theme across a casino floor to several hundred
cabinets 30 over several days. Downloading such a game theme "in
the background" to a gaming machine fulfills Class III regulations,
provided that (1) the content 20 is downloaded into an "escrow"
area where the content cannot affect game play, and (2) an
authentication process is performed on the newly-downloaded
content. In some situations, installation and use of the downloaded
theme/content 20 may require physical intervention, an initiating
event, and/or approval to fulfill Class III regulations (e.g.,
using a key switch, BKEY, or the like), depending upon the
jurisdiction.
[0061] In one preferred embodiment, an initiating event includes,
by way of example only, and not by way of limitation: (1) no
credits on the game meters, (2) no activity at the game, game play,
button pushes, card-ins, printing, and the like, (3) a period of
time with no activity at the game, (e.g., 5 minutes, 10 minutes, or
the like), (4) a key insertion or card insertion by an employee,
(5) accessing of a special setup screen on the game by an
authorized person, (6) touching a button or activation point on the
screen in response to a message saying the new code is ready to
load, (7) a button push or activation by an operator on the casino
backend, (8) a tie-in to a video system to confirm there is no
player at the game and the initiation can take place, (9) a
biometric entry at the game or at the system that authorizes
initiation of the code, and (10) a key opening and BKEY (electronic
key) entry to authorize installation or reconfiguration of the
software.
[0062] In one preferred embodiment of the gaming-content
configuration and management system 10, the distribution management
is performed using Microsoft SMS on the server, iView device 30,
and Game Maker II. In another preferred embodiment, WBEM (Web Based
Enterprise Management) is implemented, which provides an
open-source option for LINUX, AIX, UNIX, AS400, and homegrown
clients. The distribution management abilities of the configuration
and management system 10 enable other game manufacturers or system
manufacturers to be monitored and controlled by the management
server of the system 10, which is typically required for lottery
and casino monitoring systems. Additionally, the distribution
management client software utilized in the system 10 is adaptable
and/or accessible to other manufacturers.
[0063] As mentioned above, in a preferred embodiment of the system
10, a key feature of distribution management is to ensure
availability of the network for gaming transactions (i.e., device
management may not dominate the bandwidth of the network). Another
important aspect of a preferred embodiment is flexibility in the
deployment of distribution management system and scalability of the
system. Otherwise stated, the ability to use the same distribution
management system in multiple situations. Such situations include,
by way of example only, and not by way of limitation: (1) a
point-to-point distribution management situation in which a laptop
(or other portable computing device) connects to a single device 30
or a small number of devices; (2) a property-based distribution
management situation in which the management server controls a
single property (with anywhere from 100 to 30,000 devices 30 in a
local installation), and (3) a wide area network distribution
management situation in which hundreds to thousands of devices 30
are connected over a combination broadband network and/or dial-up
facilities.
[0064] In one preferred embodiment of the gaming-content
configuration and management system 10, the data transport is a
switched, managed IP network of at least 100 Mbps. Preferably, each
endpoint in the network is monitor-able and controllable. With
respect to another preferred embodiment, the distribution
management system operates over a data transport based upon POTS
(plain old telephone system).
[0065] Referring now to another aspect of the gaming-content
configuration and management system 10, the device management
component is the client companion component to the distribution
management component discussed above. One preferred embodiment, the
system 10 utilizes a common server-based distribution engine that
communicates with a wide range of "clients" including, by way of
example only, and not by way of limitation: the LINUX-based Alpha
platform; the CE-based iView platform; the XPe based Game Maker II
platform; and other proprietary platform operating systems (e.g.,
QNX, home grown, and the like). The device management component of
gaming-content configuration and management system 10, also
includes systems products, including by way of example only, and
not by way of limitation: Windows server, AIX, UNIX and AS400.
[0066] In one preferred embodiment, since the Phase 1 system 10
enables floor control through configuration changes in SAS protocol
(or other equivalent protocol), all current platforms 60 are
configured to respond to these SAS poll codes. As such, in the
Phase 1 system 10 poll codes are implemented and/or modified in
their response as needed.
[0067] Referring now to the Phase 2 system 10, in one preferred
embodiment Microsoft SMS provides all of the necessary client
components. In another preferred embodiment, WBEM (Web Based
Enterprise Management) is implemented, which provides an
open-source option for LINUX, AIX, UNIX, and AS400 clients.
[0068] In preferred embodiments of the gaming-content configuration
and management system 10, the network infrastructure differs
depending on whether Phase 1 or Phase 2 of the system is being
implemented. In a preferred embodiment of the Phase 1 system 10,
the system is implemented over existing networks using SAS poll
codes (or another equivalent protocol). In a preferred embodiment
of the Phase 2 system 10, the system is implemented over a
broadband network and employs new message protocols (e.g., BOB,
SuperSAS, G2S, or the like). In one preferred embodiment, the
network is constructed using copper or fiber optics. Additionally,
the network may include wireless, VPN, and/or long-haul components.
In a preferred embodiment, the system 10 uses a fully-switched
network in which each port (down to the individual terminal 30,
game, platform 60, and/or iView device 30) is monitored and
controlled.
[0069] Due to increasing threats from hacking and other security
issues, gaming regulations in Class 3 jurisdictions dictate the use
of strong cryptographic authentication of code running on gaming
platforms. As such, a preferred embodiment of the gaming-content
configuration and management system 10 has adopted cryptography and
security standards in order to help ensure operational efficiency
and inter-operability with other products. In this regard, PKI
(public key infrastructure) is the root of a common, systematic
approach to security and authentication for the configuration and
management system 10. In a preferred embodiment, code 20 is signed
and authenticated on platforms 60 using a root authority with
subsidiaries that meet the highest cryptographic standards and
employ industry standards.
[0070] Referring now to FIGS. 1 and 4, the iView device 30 of a
preferred embodiment of the gaming-content configuration and
management system 10 is shown. Prior to the advent of the iView
device (described above), gaming regulators would have been
unwilling to allow casino operators to design their own content.
However, due to the cryptographic technology implemented by the
embedded processor in the iView device 30, a certification process
is provided by the system 10 with sufficient security for gaming
regulators to allow casino operators to design their own content.
Specifically, in one preferred embodiment, the certification
process offered ensures authentication and non-repudiation of the
casino operator designed web content. Preferably, in the
configuration and management system 10, the certification process
provided further ensures auditability and traceability. Various
cryptographic technologies, such as authentication and
non-repudiation (described herein below), are utilized in preferred
embodiments of the claimed invention, to provide sufficient
security for gaming regulators to allow casino operators to design
their own content.
[0071] In one preferred embodiment, this certification process is
used to certify "signed content" (created by the casino owners) in
the same manner that a "signed program" is certified. Preferably,
PKI (Public Key Infrastructure) is utilized in the certification
process. PKI is a system of digital certificates, Certificate
Authorities, and other registration authorities that verify
authenticity and validity. In one preferred embodiment, a "new
tier" or derivative PKI is created that is rooted in the primary
PKI and that leverages the capabilities of the certificate (e.g., a
x509 certificate) that allow for limited access. Thus, this
preferred embodiment allows the attributes within the certificate
to be used to provide "levels" of code access and acceptance in the
gaming industry.
[0072] In one embodiment, the content is protected by digital
signature verification using DSA (Digital Signature Algorithm) or
RSA (Rivest-Shamir-Adleman) technology. In this regard, the content
is preferably protected using digital signature verification so
that any unauthorized changes are easily identifiable. A digital
signature is the digital equivalent of a handwritten signature in
that it binds a trusted authority's identity to a piece of
information. A digital signature scheme typically consists of a
signature creation algorithm and an associated verification
algorithm. The digital signature creation algorithm is used to
produce a digital signature. The digital signature verification
algorithm is used to verify that a digital signature is authentic
(i.e., that it was indeed created by the specified entity). In
another embodiment, the content is protected using other suitable
technology.
[0073] In one preferred embodiment, a Secure Hash Function-1
(SHA-1), or better, is used to compute a 160-bit hash value from
the data content or firmware contents. This 160-bit hash value,
which is also called an abbreviated bit string, is then processed
to create a signature of the game data using a one-way, private
signature key technique, called Digital Signature Algorithm (DSA).
The DSA uses a private key of a private key/public key pair, and
randomly or pseudo-randomly generated integers, to produce a
320-bit signature of the 160-bit hash value of the data content or
firmware contents. This signature is stored in the database in
addition to the identification number.
[0074] In another preferred embodiment, the claimed invention
utilizes a Message Authentication Code (MAC). A Message
Authentication Code is a specific type of message digest in which a
secret key is included, as part of the fingerprint. Whereas a
normal digest consists of a hash (data), the MAC consists of a hash
(key+data). Thus, a MAC is a bit string that is a function of both
data (either plaintext or ciphertext) and a secret key. A Message
Authentication Code is attached to data in order to allow data
authentication. Further, a MAC may be used to simultaneously verify
both the data integrity and the authenticity of a message.
Typically, a Message Authentication Code (MAC) is a one-way hash
function that takes as input both a symmetric key and some data. A
symmetric-key algorithm is an algorithm for cryptography that uses
the same cryptographic key to encrypt and decrypt the message.
[0075] A Message Authentication Code can be generated faster than
using digital signature verification technology; however, a Message
Authentication Code is not as robust as digital signature
verification technology. Thus, when speed of processing is
critical, the use of a Message Authentication Code provides an
advantage, because it can be created and stored more rapidly than
digital signature verification technology.
[0076] In one preferred embodiment, the authentication technique
utilized is a BKEY (electronic key) device. A BKEY is an electronic
identifier that is tied to a particular trusted authority. In this
manner, any adding, accessing, or modification of content that is
made using a BKEY for authentication is linked to the specific
trusted authority to which that BKEY is associated. Accordingly, an
audit trail is thereby established for regulators and/or other
entities that require this kind of data or system
authentication.
[0077] Another preferred embodiment of the verification system
utilizes "component bindings" for verification using cryptographic
security. In component binding, some components come equipped with
unalterable serial numbers. Additionally, components such as web
content or the game cabinet may also be given another random
identification number by the owner. Other components in the system,
such as the CMOS memory in the motherboard, the hard drive, and the
non-volatile RAM, are also issued random identification numbers.
When all or some of these numbers are secured together collectively
in a grouping, this protected grouping is referred to as a
"binding." Each component of the machine contains its portion of
the binding.
[0078] In one such preferred embodiment, every critical log entry
made to the content is signed with a Hashed Message Authorization
Code (HMAC) that is based on the entry itself, and on the
individual binding codes. In this manner, the security produced by
the bindings ensures that log entries that are made cannot be
falsified or repudiated.
[0079] After the critical gaming and/or system components are
selected, given individual identifiers, and combined into a
protected grouping that is secured using the component "bindings,"
any changes to those components will then be detected, authorized,
and logged. For example, content within the binding is digitally
signed (SHA-1) using the key derived from the bindings. This
signature is verified whenever an entry is made to a component
within the binding. If the signature is wrong, this security
violation and the violator are noted, but typically the entry is
not prohibited. In other embodiments, the entry may be prohibited
as well. Thus, the component binding produces a cryptographic audit
trail of the trusted authority making changes to any of the
components within the binding.
[0080] Moreover, bindings ensure that the critical components of a
gaming machine system, or the content utilized therein, that have
been selected to be components within the binding have not been
swapped or altered in an unauthorized manner. Preferably, bindings
use unique identification numbers that are assigned to vital parts
of the gaming platform including, by way of example only, and not
by way of limitation: the cabinet, motherboard, specific software,
non-volatile RAM card, content (data), and hard drive. These
identification numbers combined in a cryptographic manner to form a
"binding" that protects and virtually encloses the included
components, such that no component within the binding can be
modified, removed, or replaced without creating an audit trail and
requiring authentication. Thus, for one of these components within
the binding to be changed, appropriate authentication is required
and a log file entry is made documenting the activity and the
identity of the trusted authority making the change. In one
preferred embodiment, a specific level of BKEY clearance or
classification is required to make specific changes.
[0081] As briefly described above, gaming devices 30 also includes
signage and kiosks, in addition to gaming machines, GMUs, and iView
devices. In this regard, gaming-related signage relates to
advertising signage that is typically in a reconfigurable
electronic format. In this context, gaming-related kiosks are
machines that provide gaming-related service but do not provide
actual game play itself. Gaming-related kiosks may include both
patron-oriented services and maintenance-oriented features. In one
embodiment, patron-oriented services include the ability to sign on
to rewards services, view account status and history, redeem payout
tickets and promotional "comps," request help from an attendant,
order drinks, make dinner reservations, reserve taxis, purchase
show tickets, conduct banking transactions, and the like.
Maintenance-oriented features include providing information such as
coin-in, coin-out, malfunctions, jackpots, tilt conditions, game
software version, and the like.
[0082] As described below, an iView device is an embedded
additional user interface, which is preferably integrated into a
gaming machine and acts to increase user excitement by providing a
richer gaming experience. An embedded additional user interface
provides enhanced player satisfaction and excitement, as well as
improved gaming device reliability, interactivity, flexibility,
security, and accountability. The user interface is sometimes
referred to herein as "additional" in that the user interface is
separate from the gaming screen (or other gaming presentation).
Further, the user interface is sometimes referred to herein as
"embedded" in that the user interface includes its own processor in
some preferred embodiments.
[0083] In one preferred embodiment, the gaming-content
configuration and management system 10 contains a datastore that
includes, by way of example only, and not by way of limitation: a
relational database, object database, a flat file, an ASCII list,
registry entries, an XML file, a "collection" (i.e., in a SQL
(structured query language) environment, a collection of parameter
defined data in an object database), or any other type of commonly
known data listing. In such a preferred embodiment, the computer
datastore enables the system 10 to sort gaming devices 30 by
feature, whether the gaming devices are electronic gaming machines
(EGMs), GMUs, iViews (embedded additional user interfaces), or any
other uniquely identifiable entity on the gaming floor. In one
aspect of a preferred embodiment, the gaming devices 30 being
tracked and/or sorted include a download feature that is sortable
according to: (a) the make/model of the gaming device that the
download feature is associated therewith, (b) the device's hardware
revision, (c) the device's firmware revision, (d) the physical
location of the gaming device on the property, (e) zoning of the
gaming device (e.g., high roller zone), (f) game type (e.g.,
mechanical, electrical, dual screen, and the like), (g) dynamic
gaming state or state change (e.g., payout, malfunction, "game in
use," offline, tilt, jackpot mode, turned off, authentication
failure, security breach, downloading content, installing content,
and the like), (h) IP (Internet Protocol) address or (i) other
suitable sorting feature, such as MAC addresses.
[0084] In one exemplary embodiment, all gaming devices 30 in a
particular group can then be targeted for a specific code download.
Accordingly, in one specific embodiment, all GMUs with a particular
code revision can be identified and upgraded while those GMUs
outside of the group are ignored. In another example, all iView
devices installed into gaming machines that are located in a
particular physical location on the property (i.e., a particular
bank of games) are identified, and receive downloaded content which
is then authenticated, after which they are reconfigured.
Meanwhile, all of the iView devices outside of that grouping are
ignored.
[0085] As mentioned above, the computer datastore of the
gaming-content configuration and management system 10 is capable of
utilizing these sorting and grouping capabilities for the purpose
of inventory management. In this regard, a property (e.g. casino)
is able to maintain up-to-date information on gaming floor
inventory for a multitude of inventory parameters. These inventory
parameters include, by way of example only, and not by way of
limitation, the name of the iView device, the hardware revision of
the iView device, the firmware revision of the iView device, the
content of the iView device, the make/model of the GMU, the
hardware revision of the GMU, the firmware revision of the GMU, the
make/model of the gaming machine, the hardware revision of the
gaming machine, the firmware revision of the gaming machine, and
the physical location of the gaming machine.
[0086] In one preferred embodiment, the gaming-content
configuration and management system 10 either queries the datastore
containing all of the gaming device inventory data. The
gaming-content configuration and management system 10 then sorts
the data according to one or more user-input parameters. After the
sorting has occurred, the user can, for example, download new
content 20 to the iView devices, once the devices have been
identified and targeted.
[0087] In a preferred embodiment of the gaming-content
configuration and management system 10, since the device data
resides on a central computer datastore, standard binary datastore
searches can be performed to produce specifically desired reports.
However, in one preferred embodiment, a distributed datastore is
used instead of a centralized datastore. In one particular example,
an analyst may be interested in the effectiveness of one piece of
content (content X) compared to another piece of content (content
Y) in a particular brand of gaming machine. Using the configuration
and management system 10, the analyst can perform a datastore query
on various parameters of the gaming devices, for example, the
"coin-in" count on all Blazing 7's style gaming machines with iView
gaming devices running content version X and content version Y. In
this manner, the configuration and management system 10 enables
specialty reporting, efficiency analysis, and gaming device
management with a level of organization and simplicity that was
never before possible.
[0088] In another preferred embodiment, the standard binary
datastore searches are performed to produce other specifically
desired reports, such as predictive analysis and yield management.
In one embodiment, the yield management data includes projection
data calculated based on one or more factors related to use of one
or more gaming machines. For example, in one preferred embodiment,
the yield management data includes game play projection data,
machine usage projection data, and/or income projection data
calculated based historical game play data for the one or more
gaming machines. In one preferred embodiment, the calculations are
performed using linear regression analysis. In another preferred
embodiment, the calculations are performed using a neural network.
In one embodiment, yield management data is used to determine one
or more bonuses.
[0089] A preferred embodiment of the gaming-content configuration
and management system 10 incorporates a yield management feature
for the purpose of optimizing floor drop using configuration
control over slot machines. The yield management feature of the
configuration and management system 10 implements configuration
control by setting optionable parameters including, by way of
example only, and not by way of limitation: wager, theme,
percentage and time in play. The analysis and predictive results
are displayed using the graphical user interface 70 presents a map
74 of the gaming floor, preferably, with click and grab ease of
planning and scheduling new gaming configurations.
[0090] A preferred embodiment of the gaming-content configuration
and management system 10 provides automation and future-looking
guidance to slot directors in configuring parameters for slot
machines in order to optimize floor drop over some period of time:
hour, day, week, month, year using inputs, including by way of
example only, and not by way of limitation: accounting, time of
day, civic, news and entertainment events, and player status.
[0091] As mentioned above, a preferred embodiment of the
gaming-content configuration and management system 10 includes a
graphical user interface 70 to simplify the use of these complex
tools. The graphical user interface 70 presents a map 74 of the
gaming floor that makes the yield management results clear and
comprehensible to those not highly skilled in the art of yield
management. Further, the graphical user interface 70 of the
gaming-content configuration and management system 10 accepts input
to the yield management feature, thereby allowing a casino operator
the personalized control to manage the yield management process in
the most logical/understandable/comprehensive manner. The input
parameters and requirement for the graphical user interface 70 are
also configured to be allowable subject to the gaming regulations
for the relevant jurisdiction.
[0092] A preferred embodiment of the gaming-content configuration
and management system 10 is able to analyze, automate, schedule,
and control the options, operation, and configuration for thousands
of machines. The configuration and management system 10 is capable
of providing this control from a single property to many properties
that may span states, countries, and even throughout the world.
Preferably, a map 74 is presented via the graphical use interface
70 of the system 10, which is used to present information to a
casino administrator in an easily understandable format. In this
manner, a casino administrator is able to see historical results
and then schedule changes in the slot floor using the map 74,
presented via the graphical use interface 70.
[0093] In one preferred embodiment, the configuration and
management system 10 is capable of applying the yield management
feature to an individual player. In another aspect of a preferred
embodiment, the configuration and management system 10 utilizes two
forms of yield management in combination (i.e., physical groupings
combined with individual player performance and monitoring).
[0094] In one preferred embodiment, yield management feature of the
configuration and management system 10 is configured to optimize
casino profitability. In one specific, non-limiting preferred
embodiment, casino profitability is represented by the formula: CP
= time .times. ( OP - OE ) ##EQU1## Where: [0095] CP=Casino Profit
[0096] OP=Operations Profit [0097] OE=Operations Expenses
[0098] Additionally, in one preferred embodiment of the
configuration and management system 10, time is a variable in yield
management calculations. Further, it should be noted that
operational expenses are included in the above casino profitability
formula. In a preferred embodiment, many aspects of operations
performance are captured in the systems and messages. An additional
aspect of the configuration and management system 10 involves
applying yield management principles to operational efficiency
issues, thereby further increasing casino profitability.
[0099] In a preferred embodiment, each element of the operations
profit formula (shown below) can be broken down and the principles
of yield management applied. For the casino slot floor the
operations profit, OP, can be broken into: OP = time .times. ( POSP
+ SFD ) ##EQU2## Where: [0100] POSP=Point Of Sale Profit (includes
hotel, retail, food and beverage and entertainment) [0101] SFD=Slot
Floor Drop [0102] Continuing: SFD = time .times. ( PL - promotions
) .times. ( RETURNVISIT ) ##EQU3## Where: [0103]
RETURNVISIT=probability that the player will return to the casino.
[0104] PL=Player Loss [0105] Promotions=marketing money the casino
contributes to player kickbacks, comps, and system games. [0106]
Still continuing: [0107] PL=ST*GCT*HPC*WAGER Where: [0108] ST=time
the player spends at the slot machine, i.e., seat time [0109]
GCT=Game Cycle Time [0110] HPC=Hold Percentage for the game [0111]
Further continuing: [0112] WAGER=LINESBET*CREDITS*DENOM Where:
[0113] LINESBET is the number of lines on which the player is
betting. [0114] CREDITS is the number of credits the player chooses
to bet. [0115] DENOM is denomination, i.e., the worth of an
individual credit.
[0116] It should be noted that LINESBET, CREDITS, and DENOM can
each be set to a minimum and are option-able parameters. As such,
LINESBET, CREDITS, and DENOM are each under yield management
control. Interestingly, changes in parameters within the PL (Player
Loss) formula above can have a significant effect. Even if PL
(Player Loss) is held constant, other element can still be modified
within the formula. For example, GCT (Game Cycle Time) could be
reduced by half while ST (Seat Time) is doubled. In this scenario,
the player spends much more time at the game. Accordingly, such a
players' chances of winning a progressive or system game are
increased. Continuing this example, during slow times for the
casino the above-described configuration change provides a method
for the casino operator to enhance the attractiveness of the games
to players without adversely compromising player loss or modifying
progressive rules or systems games. The capability of the
configuration and management system 10 provides a distinct
advantage over prior gaming systems, in that no regulatory review
of "new game rules" (i.e., new game configuration) is required.
[0117] A preferred embodiment of the configuration and management
system 10 includes the capability to link the above-described
changes to marketing programs such as mailings, advertisements,
phone calls, other marketing methods, and the like. In addition,
configuration and management system 10 includes a linkage to system
game operation and individual yield management, as described
above.
[0118] In one preferred embodiment of the configuration and
management system 10, the yield management feature of the system 10
includes the ability to advertise, annunciate, and/or otherwise
alert the player that yield management configuration change has
occurred. Otherwise stated, in one specific, non-limiting
embodiment, when the player sits at a gaming machine and is
identified, the configuration and management system 10 annunciates
to the player, "you are at 98% payback." In one preferred
embodiment, such an announcement is made and maintained for the
player to observe through at least one game cycle.
[0119] In another aspect of a preferred embodiment of the
configuration and management system 10, the yield management
parameter modifications are applied interactively as the casino
operates. For example, in one specific, non-limiting embodiment,
every fifteen minutes, the "forward looking" algorithms for yield
management operation note that a particular carousel is being
heavily played. In such an embodiment, yield management parameters
(e.g., minimum bet and the like) are then immediately modified on
those gaming cabinets (in the carousel) that are not currently in
play. Thus, any new players joining the "hot" carousel are joining
into game play that has had "tighter" yield management parameters
applied. Accordingly, in such an example, those gaming patrons
already on the "hot" carousel who have been a part of creating the
"hot" feeling are at an advantage to those players joining
later.
[0120] Likewise, in another specific, non-limiting embodiment, if
the "forward-looking" algorithms for yield management operation
detect that a carousel is "cooling," then yield management
parameters (e.g., denomination and the like) can be immediately
lowered or modified for ALL players. In this manner, those loyal
players receive the same reward as new players joining the
"action." Moreover, from a regulatory standpoint, relaxing yield
management parameters on players during a gaming session is viewed
far less restrictively than tightening yield management parameters
on players during a gaming session. In this regard, in one
preferred embodiment, tightening yield management parameters on
players requires at least an announcement (and possibly active
acceptance of the modifications by the player), and more commonly
instituting the above configuration changes between player
sessions.
[0121] In a preferred embodiment of the configuration and
management system 10, the yield management feature necessitates an
audio and/or visual announcement to the players that yield
management parameters have been changed. In this regard, parameter
changes in the players' favor may be displayed on the game screen,
presented in the systems interface (iView-type device), announced
by sound and/or the like. As explained above, parameter changes
that are not in the players' favor (i.e., changes that tighten
yield management parameters on the players) typically require
higher levels of announcement to the players and possibly active
acceptance of the modifications by the players.
[0122] Referring again to the formula above, slot floor drop, the
parameter RETURNVISIT (probability that the player will return to
the casino) is a significant term. In a preferred embodiment of the
configuration and management system 10, yield management accounts
for the importance of maximizing the RETURNVISIT probability, while
at the same time maximizing SFD (Slot Floor Drop, i.e., the money
collected). In a preferred embodiment of the system 10, a balance
between these two elements is significant, and advantageously, is
customizable by a casino administrator through the use of the yield
management feature of the configuration and management system
10.
[0123] In a preferred embodiment of the system 10, the yield
management feature enables cyclic patterns to be identified in
order to both increase operator profitability and optimize player
satisfaction, and thus return visits. Such factors, which are
examined by the yield management feature in determining such cycles
include, by way of example only, and not by way of limitation:
demographics, weather, and entertainment events. In a preferred
embodiment of the system 10, use of the yield management feature
enables casinos that have implemented the system 10 to provide a
much more personalized and individualized gaming experience.
[0124] In another aspect of a preferred embodiment of the system
10, the yield management feature combines individual player
performance over time with gross property-wide yield management
information. This combination gives each player their own unique
play characteristics. In this regard, individualized
characterization, control, and promotion are prominent features of
such an embodiment. By combining yield management with player
information, the system 10 enables customization of the game
offerings specific to that customer.
[0125] Thus, in one specific, non-limiting embodiment, if a game
cabinet holds fifteen game themes (i.e., game titles), only those
game themes that the yield management predicts are most attractive
to the player will be presented. Preferably, this extends to new
game offerings as well, so that when new game themes are
introduced, the yield management feature predicts if a particular
player might like this new game theme, provides that game theme to
the player, and announces to the player the existence of the new
game theme. Additionally, as described above, parameters such as
wager, game cycle time, and percentage can be set by the system 10,
based upon player characteristics and overall yield management
parameters.
[0126] In another specific, non-limiting embodiment of the
configuration and management system 10, if the "forward-looking"
yield management algorithms predict over 80% occupancy then GCT
(game cycle time) is reduced, thereby increasing profitability.
Moreover, if indications are that occupancy will remain over 80%,
then yield management can move to adjusting WAGER to higher
minimums. In one preferred embodiment, this adjustment might take
the form of changing minimum lines, minimum credits, or
denomination. As described above, the yield management feature of
the configuration and management system 10 has a wide area of
variables for affecting and adjusting slot floor profit.
[0127] In a preferred embodiment, the yield management aspect of
the configuration and management system 10, coordinates game
performance data from multiple input sources into an analytic
engine. The sources include, by way of example only, and not by way
of limitation: (1) slot data accounting, (2) multi-game cabinet
accounting, (3) player tracking data, comps, (4) hotel, (5) point
of sale system data, (6) location, (7) game mix nearby, (8)
entertainment data, (9) weather, (10) off site user group
demographic data, and (11) grouping of players, including the
monitoring of those groups and presentation of bonusing specific to
that group.
[0128] In accordance with a preferred embodiment of the system 10,
the regulatory rules that allow control over gaming devices by
electronic means are (1) GLI-21, and (2) NVGCB Proposed System
Based and System Supported gaming regulations. Gaming devices with
one or more modifiable parameters affecting yield management
calculations include, by way of example only, and not by way of
limitation: (1) theme, (2) wager (a) minimum bet, (b) maximum bet,
(c) minimum lines bet, and (d) denomination, (3) percentage, and
(4) play time, (a) spin cycle time, and (b) bonus round time.
[0129] In a preferred embodiment of the system 10, the uses of the
yield analysis feature, include by way of example only, and not by
way of limitation: system-games, gaming user groups, casino gaming
areas, casinos and multi-property gaming, base game play of
relating system-games, and modification of system-game operation
for optimization of overall property profitability. In another
aspect of a preferred embodiment of the system 10, the yield
analysis feature includes predictive analysis engine for optimizing
any desirable parameter (e.g., drop or occupancy during some future
time). In one preferred embodiment of the system 10, the yield
analysis feature includes an automation system for aiding and
advising slot floor managers in the optimal configuration of a
casino floor, including individual parameterization of slot
machines.
[0130] A preferred embodiment of the yield management aspect of the
system 10 is directed towards manipulation of gaming device
parameters including, by way of example only, and not by way of
limitation: wager, theme, percentage, and time in play to provide
optimal casino profitability based upon predictive modeling.
Additionally, in another aspect of a preferred embodiment,
predictive modeling includes parameters related to player, property
occupancy, time of day, week, month, year, events, weather,
demographics, and other similar parameters.
[0131] Another preferred embodiment of the yield management aspect
of the system 10 is directed towards linkage of yield management
manipulation of gaming devices 30 with player-targeted marketing,
including advertisements and inducements from casino to patrons.
Still another preferred embodiment the yield management aspect of
the system 10 is directed towards notifying a player for at least
one game cycle that a yield management parameter has been modified
on the gaming device being used by the player. Moreover, yet
another preferred embodiment the yield management aspect of the
system 10 is directed towards a system 10 configured to combine
message set capability with game design, wherein the game design
enables capturing, analyzing, and reporting on individual machine,
machine grouping, as well as individual player and player grouping
performance over time.
[0132] Referring now to FIG. 5, a preferred embodiment of an IP
gaming hub 200 is utilized as a controlled access device that
includes a game monitoring system 210, an internal Ethernet switch
220, and a plurality of ports 230. A game monitoring system 210 has
the functionality of a GMU, as described above. Typically, a GMU is
an in-cabinet device that connects the internal components of
gaming devices to the network. In one preferred embodiment, the IP
gaming hub 200 can be embodied as an advanced Mastercom type of the
device (but incorporating many additional types of functionality
beyond that of prior Mastercom devices), as sold by Bally Gaming of
Las Vegas Nev.
[0133] Preferably, the internal Ethernet switch 220 is not
controlled by port location. In one preferred embodiment, the IP
gaming hub 200 includes a 6-port Ethernet switch 220. Preferably,
one of the ports 230 is the uplink port (in QoS vernacular, the
"egress port"). Continuing, in such a preferred embodiment, four of
the ports 230 are used to connect to any Ethernet device within the
game cabinet. These ports 230 are connectable to the game
motherboard, iView-type devices, Alpha-type devices, and the like.
Typically, the last of the ports 230 is used internally for SNMP
(Simple Network Management Protocol) and formation of the GMU/SDS
data packets. Simple Network Management Protocol is a method for a
network device to communicate management and error information to a
remote server. SNMP can also be used to query a device for
information about the device. The SNMP protocol can support
monitoring of network-attached devices for any conditions that
warrant administrative attention. One of ordinary skill in the art
will appreciate that other standard broadband protocols, networks,
switches, and ports, may be substituted for Ethernet in other
embodiments of the invention.
[0134] As shown in FIG. 6, the network includes a core layer 301
over a distribution layer 302 above an access layer 303. The core
layer 301 serves as a gateway between the servers and the gaming
devices. The core layer 301 is contemplated to be a so-called "back
end" layer that resides in an administrative location, separate
from the gaming floor, for example, and protected physically and
electronically.
[0135] The distribution layer 302 serves to collect traffic between
the core layer 301 and the access layer 303. The distribution layer
may comprise trunks and switches that route message and signal
traffic through the network. The access layer 303 provides a
physical interface between the gaming machines (and any of their
associated devices) and the rest of the network. In one preferred
embodiment, this is done via managed switches.
[0136] In another aspect of a preferred embodiment, the core layer
301 includes one or more servers that are coupled via a
communication path to one or more switches. In one embodiment, the
servers and switches of the core layer 301 are located within the
gaming establishment premises in a secure administrative area. The
servers may, but are not required to be, game servers. The
communication path may be hardwire (e.g., copper), fiber, wireless,
microwave, or any other suitable communication path that may be
protected from attack.
[0137] The distribution layer 302 communicates with the core layer
301 via high bandwidth communications links. These links may be
copper, fiber, or any other suitable link. If desired, redundant
links may be built into the system to provide more failsafe
operation. The communications links couple the core layer switches
to the distribution layer switches.
[0138] In another aspect of a preferred embodiment, the
distribution layer 302 communicates with the access layer 303 via a
high capacity communication link. The link may be wire, fiber,
wireless, or any other suitable communication link. In the
embodiment, the communication link is coupled to a gaming carousel
that comprises a plurality of gaming machines. A managed switch is
coupled to the link to provide an interface switch to a plurality
of other managed switches.
[0139] In one embodiment of the gaming network, the network uses
TCP/IP sessions between the gaming machines and the servers. The
TCP/IP sessions are used to exchange private information concerning
game operations, game performance, network management, patron
information, revised game code, accounting information, 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, and the like.
[0140] Moreover, the gaming network may use a number of network
services for administration and operation. Dynamic Host
Configuration Protocol (DHCP) allows central management and
assignment of IP addresses within the gaming network. The dynamic
assignment of IP addresses is used in one embodiment instead of
statically assigned IP addresses for each network component. A DNS
(domain name service) is used to translate between the domain names
and the IP addresses of network components and services. DNS
servers are well known in the art and are used to resolve the
domain names to IP addresses on the Internet.
[0141] Similarly, Network Time Protocol (NTP) is used to
synchronize time references within the network components for
security and audit activities. It is important to have a consistent
and synchronized clock so that the order and the timing of
transactions within the gaming network can be known with
reliability and certainty. Network information can be gathered
centrally at a single workstation by using the Remote Monitoring
(RMON) protocol. SNMP (simple network management protocol) allows
network management components to remotely manage hosts on the
network, thus providing scalability. Still further, TFTP (trivial
file transfer protocol) is used by servers to boot or download code
to network components.
[0142] In one embodiment, the network may be implemented using the
IPv6 protocol designed by the IETF (Internet Engineering Task
Force). When using IPv6, the network may take advantage of the
Quality of Service (QoS) features available with IPv6. QoS refers
to the ability of a network to provide a guaranteed level of
service (e.g., transmission rate, loss rate, minimum bandwidth,
packet delay, and the like). QoS may be used as an additional
security feature in that certain transactions may request a certain
QoS as a rule or pursuant to some schedule.
[0143] Referring again to FIG. 5, in a preferred embodiment, all of
the ports 230 are internal to the IP gaming hub 200, which enables
total control of the ports and a QoS (or other packet delivery
prioritizing technology) encoding mechanism 240. As identified
above, the SDS data packets are programmatically encoded with a
specific QoS high priority level (or other packet delivery
prioritizing technology), while all the other data packets are
programmatically encoded with a lower priority level (e.g., zero)
as the data passes into the downlink port (ingress) and moves to
the uplink port (egress). This procedure ensures that the SDS data
(or other specifically designated game accounting data) is encoded
with a QoS high priority level (or other packet delivery
prioritizing technology) at the inception of the packets on the
network. Preferably, all of the other ports 230 are set to
zero.
[0144] In another embodiment the QoS priority level of packets from
the ingress ports may be programmatically encoded with a lower
priority by hardware located at the egress port rather than by the
switch hardware directly at the ingress ports. This allows the use
of any available switching circuit whether or not it has the
built-in capability of re-marking the priority of ingress
packets.
[0145] In one preferred embodiment the configuration of the packet
QoS encoding methodology in IP gaming hub 200 is administered
through the use of an SNMP server located at the core layer of the
network. This server allows on-the-fly adjustment of the encoding
scheme to which the devices that attach to the ports 230 receive
high-priority switching. This server may also be used as an access
manager for devices attached to the ports 230 to make requests to
be treated as high-priority traffic. In this implementation, a
device that is authorized to transmit high-priority traffic but
that is currently being treated as a low-priority device, may
dynamically request that its data transmissions be re-prioritized
to a different priority level.
[0146] In a preferred embodiment, as a result of the SDS data (or
other specifically designated game accounting data) being encoded
within the IP gaming hub 200, there is no possibility of personnel
either intentionally or accidentally plugging cables into the
incorrect ports 230, since all the cables plugging into the IP
gaming hub 200 have the same priority (e.g. zero or other low
priority). In one preferred embodiment of the IP gaming hub 200,
the SDS data packets always go out first before any data from the
ingress ports due to the QoS high packet delivery priority encoding
that is implemented on the internal switch 220.
[0147] In a preferred embodiment, the uplink (or egress) port 230
of the IP gaming hub 200 connects to a QoS-enabled switch in a
carousel. This internal switch 220 has the ability to take the data
from its ingress ports 230 and move them to the egress port 230
(i.e., the uplink to the Distribution Layer devices), using QoS
prioritizing techniques, thus ensuring that the high priority
QoS-encoded packets are passed first. Having the controlled switch
220 located within the IP gaming hub 200 also provides the ability
to extract other information from the controlled layer environment.
For example, in some embodiments, the IP gaming hub 200 is capable
of supplying information about the motherboard and other elements
within the cabinet, as well as their relationship with the GMU.
[0148] In a preferred embodiment, the controlled ingress system
built into the IP gaming hub 200 ensures that the SDS data packets
on a shared Ethernet network have correct (i.e. high delivery
priority) QoS encoding and ensures that the other ports in the
cabinet are set to a standard best delivery encoding (e.g. zero or
other low priority). This configuration also presents a suitable
cabling configuration since multiple Ethernet ports 230 are
accommodated within a cabinet. Accordingly, the multiple Ethernet
ports 230 are all accommodated by the IP gaming hub 200 while
having only a single wire leave the cabinet. In a preferred
embodiment, the Ethernet switches that are utilized are QoS
aware.
[0149] In one preferred embodiment, these Ethernet switches 220 are
connected to a distribution switch in a nearby closet (or other
suitable location) and use a QoS encoder 240 to ensure the high
priority delivery of the SDS data. In one preferred embodiment, the
distribution switch is set to "trust" and uses the QoS encoding
that is conveyed by the uplink switch in the carousel. Using the
QoS delivery prioritizing information supplied in the IP packets,
the packets are moved from the ingress ports (all the carousel
switches) to the egress port, which is preferably a gigabit
Ethernet connection to the core switch, as shown in FIG. 6.
[0150] Referring now to the data flowing from the SDS servers 260
back to the game units, as shown in FIG. 6, the Core Layer switch
preferably knows where the SDS servers are attached. Preferably,
the switch is in a controlled IT area. In another aspect of one
preferred embodiment, the QoS encoding is applied to any packets
sent out from the SDS servers 260 and entering the core switch on
their assigned port, thereby ensuring that the same delivery
priority that is used on the incoming data from the SDS servers is
replicated on any outgoing data.
[0151] In one preferred embodiment, the IP gaming hub 200 is an
802.1x enabled smart device (using extensible authentication
protocol) that is intelligent enough to perform an 802.1x secure
authentication procedure. 802.1x is a methodology typically used
for securing a carousel switch (i.e., locking down the switch), so
that only allow approved devices can access a port on the switch.
Specifically, 802.1x is an IEEE standard for network access
control. 802.1x keeps a network port disconnected until
authentication is completed. Depending on the results, the port is
either made available to the user, or the user is denied access to
the network.
[0152] 802.1x provides an authentication framework, allowing a user
to be authenticated by a central authority. 802.1x uses an existing
protocol, the Extensible Authentication Protocol (EAP, RFC 2284),
that works on Ethernet, Token Ring, or wireless LANs, for message
exchange during the authentication process. The device that
contains usernames and passwords and authorizes the
access-requesting device is the "authentication server." The
authentication server may use the Remote Authentication Dial-In
User Service (RADIUS), although 802.1x does not require it.
[0153] Although the invention has been described in language
specific to computer structural features, methodological acts, and
by computer-readable media, it is to be understood that the
invention defined in the appended claims is not necessarily limited
to the specific structures, acts, or media described. Therefore,
the specific structural features, acts and mediums are disclosed as
exemplary embodiments implementing the claimed invention.
[0154] Furthermore, the various embodiments described above are
provided by way of illustration only and should not be construed to
limit the invention. Those skilled in the art will readily
recognize various modifications and changes that may be made to the
claimed invention without following the example embodiments and
applications illustrated and described herein, and without
departing from the true spirit and scope of the claimed invention,
which is set forth in the following claims.
* * * * *