US20070054740A1 - Hybrid gaming network - Google Patents

Abstract

The invention provides a method and apparatus for linking a plurality of independent networks to a single central control system. In one embodiment, a casino accounting and reporting processing system provides a common back end to a plurality of networks. In one embodiment, the central server is coupled to at least one network using the same protocol so that no translation or interface is necessary. One or more other networks are coupled to the central server via an interface for translating communications and commands from the independent network to the host network protocol. In one embodiment, the interface is implemented using a standard interface referred to as “S2S”. An advantage of the invention is that it can be used to provide a common user interface, common accounting and security, and common player tracking management.

Description

RELATED APPLICATION
• This patent application is a continuation-in-part of pending U.S. patent applications Ser. No. 11/220,781 filed on Sep. 7, 2005 entitled “Gaming Network” and assigned to the assignee of the present application and U.S. patent application Ser. No. 11/319,034 filed on Dec. 23, 2005 entitled “Device Identification” and assigned to the assignee of the present application, both of which are incorporated herein in their entirety.
COPYRIGHT NOTICE
• A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• The claimed invention relates generally to a network, and more particularly, to a gaming network with an identification and communication system for network devices.
• 2. Background
• In early gaming environments, gaming machines were stand-alone devices. Security of the gaming machines was accomplished via physical locks, security protocols, security personnel, physical and video monitoring, and the need to be physically present at a machine to attempt to breach the security of the gaming machine. By the same token, management of the gaming machines required a great deal of personal physical interaction with each gaming machine. The ability to change parameters of the gaming machine also required physical interaction.
• In view of the increased processing power and availability of computing devices, gaming machines have become customizable via electronic communications and remotely controllable. Manufacturers of gaming equipment have taken advantage of the increased functionality of gaming machines by adding additional devices and features to gaming machines, thereby maintaining a player's attention to the gaming machines for longer periods of time increasing minimum bet and bet frequency and speed of play. This, in turn, leads to the player wagering at the gaming machine for longer periods of time, with more money at a faster pace, thereby increasing owner profits.
• 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. In this regard, attaching a small electronic display to the gaming device, gambling-related information, as well as news and advertisements can be sent to the player. The gambling-related information may include, for example, information on sports betting and betting options for those sporting events. Additionally, the gambling-related information may also include information such as horse racing and off-track betting. News and advertisements can also maintain a player's attention by providing the player with access to information ranging from show times, to restaurant and hotel specials, and to world events, thus reducing the need and/or desire of the player to leave the gaming machine.
• Moreover, it has been shown to be desirable to provide the player with interactive access to the above information. This type of interactivity allows players significantly more flexibility to make use of the above-described information. The gambling-related information can 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 the player remain and gamble at the gaming machine for significantly longer periods of time.
• In addition, the player may participate in a “premium” promotion where the player is registered with the gaming establishment as a club member when the player inserts an ID card into the gaming machines during play. The player may be rewarded for certain play patterns (e.g. wager amounts, wager totals, payouts, time of play, or the like) and earn redeemable benefits or upgrade of club member status.
• Attempts to distribute gambling-related information and advertisements to players and to allow the recognition of premium membership players have resulted in additional system components that may be attached to the gaming devices. These components for accessing and displaying information for gaming machines may include a keypad, card reader, and display equipment (including, for example, color touch-screens) It is also desired to have a common user interface for all gaming machines including having a common location for devices such as the card reader, keypad, and display.
• The amount of interactivity and data presentation/collection possible with current processor based gaming machines has led to a desire to connect gaming machines in a gaming network. In addition to the gaming machines themselves, a number of devices associated with a gaming machine or with a group of gaming machines may be part of the network. It has become important for the devices within a gaming machine or cabinet to be aware of each other and to be able to communicate to a control server. Not only is the presence or absence of a network device important, but also the physical location of the device and the ability to associate devices within a particular gaming machine has become a necessary component of a gaming network.
• Current networks for gaming machines have been primarily one-way in communication, have been slow, and have been proprietary (custom designed and incompatible with commercial networking equipment). Prior art networks provided accounting, security, and player related data reporting from the gaming machine to a backend server. Secondary auditing procedures allowed regulators and managers to double check network reporting, providing a method of detecting malfeasance and network attacks. However, such security is remote in time from when a network attack has occurred. Prior art networks lack many security features needed for more rapid detection of cheating from a variety of possible attackers.
• One disadvantage of prior art networks is the inability to integrate one or more proprietary or independent networks to a common central server. The inability of certain networks to communicate with each other makes management of the networks more complex and costly. Accounting, player tracking, and security are problematic when messages originate from multiple networks.
• Although prior art networks of gaming machines provide advantages to gaming establishment operators, they also engender new risks to security of the gaming establishment and to the gaming machines. Not only is traditional data associated with gaming machines now potentially at risk on the gaming network, but personal player information is now at risk, as well.
• In addition, the proprietary nature of prior art gaming machine networks limits the ability to use commercially available technology. This adds to the cost of gaming networks and limits their scalability and the ability to upgrade as technology improves. Further, as gaming machines are grouped in networks, the value of the pooled financial data traversing the network creates a great temptation to attack the network. The potential reward from attacking a network of gaming machines is greater than the reward from attacking a single machine.
• A gaming network may have a large number of dynamically changing and reconfigurable components. Because of the desire to keep down-time to a minimum, it is important that the population of devices on the network be determinable and verifiable. In the past, this has meant pre-programming knowledge of all other devices into each device, so that communication between devices could take place. Such a requirement of pre-programming or pre-knowledge is too time consuming to be practical in a gaming network environment.
• In addition, operators desire to be able to access individual devices inside of a gaming machine from a central server or from other machines. In addition, it may be desirable for multiple machines to be able to communicate with a peripheral so that peripherals may be shared. In other cases, it may be desired to temporarily use another machine's peripheral upon failure of one of its own peripherals.
• Another disadvantage of current gaming systems is the hybrid nature of networks that include a number of different protocols. Many legacy devices are unable to effectively communicate with other devices in the system. In addition, proprietary protocols add to the expense of device manufacture and replacement.
SUMMARY OF THE INVENTION
• The invention provides a method and apparatus for linking a plurality of independent networks to a single central control system. In one embodiment, a casino accounting and reporting processing system provides a common back end to a plurality of networks. In one embodiment, the central server is coupled to at least one network using the same protocol so that no translation or interface is necessary. One or more other networks are coupled to the central server via an interface for translating communications and commands from the independent network to the host network protocol. In one embodiment, the interface is implemented using a standard interface referred to as “S2S”. An advantage of the invention is that it can be used to provide a common user interface, common accounting and security, and common player tracking management.
• These and 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
• FIG. 1 is a block diagram of an embodiment of the invention.
• FIG. 2 is a block diagram illustrating an embodiment of a communication model using the interface of the invention.
• FIG. 3 is a flow diagram illustrating communication in an embodiment of the invention.
• FIGS. 4A, 4B, and4C are block diagrams of a gaming machine configuration in embodiments of the invention.
• FIG. 5 is a flow diagram illustrating one embodiment of game machine device management using the invention.
• FIG. 6 is a flow diagram illustrating the transmission step ofFIG. 5.
• FIG. 7 is a flow diagram illustrating the identification step ofFIG. 5.
• FIG. 8 is a flow diagram illustrating the communication step ofFIG. 5.
DETAILED DESCRIPTION
• The claimed invention is directed to a hybrid network where one or more independent networks may be managed by a single central server. The preferred embodiments of the system and method are illustrated and described herein, by way of example only, and not by way of limitation.
• Referring now to the drawings, wherein like reference numerals denote like or corresponding parts throughout the drawings, there are shown embodiments of the hybrid gaming network constructed in accordance with the claimed invention.FIG. 1 is a block diagram illustrating an embodiment of the invention. A central server orback end system101 is configured as the controller of the system. Although this back end system may be comprised of many parts, it may be referred to herein as acentral server101. The protocol upon which thecentral server101 operates is referred to as the native protocol. In the embodiment shown, anative network102 is directly coupled to thecentral server101. Thenative network102 is a group of game machines that operate using the same protocol as thecentral server101. It should be understood that the invention may be practiced with or without one or more native networks.
• Thecentral server101 includes adatabase103 for storing operational data, performance data, financial data, security data, and the like. Anapplication layer104 interfaces between thenative network102 and the command queues105 (inbound) and106 (outbound). In one embodiment,application layer104 communicates with a casinoback end server124.Command queues105 and106 communicate withprotocol layer107.Server108 communicates (receiving messages from independent networks) with theinterface110 and is a web server in one embodiment capable of XML parsing.Client109 is coupled tointerface110 and is used to send messages to independent networks.
• Interface110 is used to bridge between the native and the independent networks. As referred to herein, an independent network is a network using a different protocol than the native protocol of thecentral server101. These independent protocols may or may not include some mixture of proprietary and standard protocols. An example of a proprietary protocol is the Slot Data Transport (SDT) by Bally Gaming Systems, or RSM, a binary TCP messaging structure that is socket based, used for near real-time communication, also by Bally Gaming Systems. The interface provides the ability to translate commands and data from one network protocol to another. In this case, it provides a way to translate from one or more independent protocols to the native protocol and vice-versa. Communication is not limited to only between the central server and the independent networks. It should be realized that the native and independent networks may communicate with each other, using the interface to facilitate communication.
• In one embodiment of the invention, the interface is implemented using the S2S (System to System) protocol defined by the Gaming Standards Association (GSA)
• In the example ofFIG. 1, there are a number ofindependent networks111,112, and113 coupled to thecentral server101 via theinterface110.Independent network111 is shown by way of example as an IGT Class II system. Thenetwork111 comprises a plurality ofgaming machines150 coupled tosystem processor114.Network111 in one embodiment communicates using web services via SOAP (“Simple Object Access Protocol”) over HTTPS.Network112 comprises a network (e.g. an NRT network) with a plurality ofbill acceptors152 or other coin-indevices153,154 coupled tonetwork system processor115.Network112 communicates with direct posts using HTTP in one embodiment of the invention.Network113 is an anticipated future network that uses a protocol not currently in use and includes a plurality ofgaming machines156 andnetwork system processor116.Network113 in one embodiment communicates via socket or web services. The invention contemplates use with existing network protocols and future network protocols.
• In the example ofFIG. 1,protocol layer107 is capable of communicating with a number of independent networks using a variety of protocols.Protocol layer107 can use web services to communicate using SOAP, use direct posts using HTTP, or via sockets.
• FIG. 2 is a block diagram illustrating a communication model in an embodiment of theinterface110. The native network system is represented on the left side ofFIG. 2 and an independent network is represented on the right side.Application layer201 and business layer202 respond to commands in messages directed to the native network. In one embodiment,business layer104 communicates with a casinoback end server220.Application layer218 andBusiness layer217 respond to commands in messages directed to the independent network.
• Application layer201 receives messages (and commands) viainbound command queue203.Application layer201 sends messages to the network viaoutbound command queue204. Thequeues203 and204 are coupled to theprotocol layer207. At the protocol level, messages are transmitted between the network hosts.
• Application layer218 receives messages and commands viainbound command queue216 and sends messages to the network viaoutbound command queue215.Queues215 and216 are coupled toprotocol layer214.
• Protocol layer207 includes aweb server205 andclient connection206. Similarly,protocol layer214 includes aclient connection212 andweb server213. In the embodiment shown inFIG. 2, communication is accomplished via a request-response method. Therefore, there are separate channels for inbound and outbound communication of messages. The inbound channel for protocol layer207 (and correspondingly the outbound channel for protocol layer214) is represented by the connection betweenserver205 ofprotocol layer207 andclient connection212 ofprotocol layer214.Client connection212 sends amessage208 toserver205. An acknowledgement (ACK)209 is sent back byserver205 toclient connection212 when a message has been received.
• The outbound channel for protocol layer207 (and inbound channel for protocol layer214) is represented by the connection betweenclient connection206 ofprotocol layer207 andweb server213 ofprotocol layer214.Client connection206 sends amessage210 toweb server213. AnACK211 is sent back byserver213 toclient connection206 when a message has been received.
• In the embodiment illustrated, the ACK only indicates that a message and the commands have been received and does not represent an acknowledgement that the commands will be executed. The processing of commands in the system ofFIG. 2 is illustrated in the flow diagram ofFIG. 3. Atstep301 the native network A sends a message to independent network B. The message includes a command. Atstep302 network B sends an ACK to network A acknowledging the receipt of the message and command. At some later time atstep303 network B processes the command. (The embodiment illustrated contemplates asynchronous operation so that the commands do not have to be processed immediately upon receipt). Atstep304 network B may send a message to network A that confirms that the original command has been processed and perhaps including a command from network B to network A. Atstep305 network A sends an ACK to network B. Atstep306, network A processes the command.
• Message Format
• In one embodiment of the invention, a standard message format is used to enhance the ability to promote cross network and cross protocol communication. In one embodiment, a message element forms the outer wrapper of an original message and the acknowledgement. An acknowledgement is composed of a single element “Acknowledge”. A message comprises a header and a body. The header identifies the sender, the receiver and information about the message. The body of the message contains application level commands.
• The header includes attributes that identify the message, including a system identifier of the originator, the system identifier of the recipient, a unique message identifier, and a date stamp. The system identifier permits the appropriate translation to take place for ease of communication between native and non-native systems.
• The application command consists of a class-level element and a command-level element. A message element may contain multiple commands comprising the class-level/command-level pair.
• Gaming Machine
• The invention contemplates the ability to interact with gaming devices on different networks. The following figures give examples of embodiments of gaming machines that may be used with the invention.FIG. 4A is a block diagram of an example gaming machine configuration in an embodiment of the invention. Thegaming machine415 communicates with its associated native or non-native network viacommunications path414 which may be Ethernet, wireless Ethernet, wire, fiber, wireless, or any other suitable communication link. Thegaming machine415 may include acommunications interface401 that handles communication between the gaming machine and its associated devices and the remainder of the gaming network.Communication interface401 is coupled to anMPU402. The MPU serves as the processor of the gaming machine. An interface referred to as a “SMIB”403 (smart interface board or slot machine interface board) is coupled to the MPU and to thecommunication interface401.SMIB403 is coupled to one or more peripherals or other devices connected to thegaming machine415, such asdevices404A to404N ofFIG. 4A. In one embodiment of the invention,SMIB403 uses an Ethernet or other high-speed communications link to thecommunication interface401,MPU402, anddevices404A through404N. In one embodiment, the SMIB includes switching capabilities. In one embodiment, the SMIB is implemented with a Mastercom 300 manufactured by Bally Technologies.
• FIG. 4B illustrates an alternate embodiment of a gaming machine and peripherals. The gaming machine communicates with its associated network via communications path414 (which may be an Ethernet connection). Communication is handled bynetwork distribution device405. This device could be an Ethernet hub, for example, or any other suitable communications interface. The game machine includes anMPU402 that provides processing for the game. A number of peripherals are included in the gaming machine and are coupled directly to thenetwork distribution device405 or to theMPU402. In the embodiment ofFIG. 4B, such peripheral devices includelights406,keypad407,card reader408,primary display409,lights410,button deck411,printer412,hopper413,coin acceptor414,bill acceptor415, andsecondary display416. It is understood that not every gaming machine will have this exact configuration of peripherals. A gaming machine may have fewer or more peripherals, and different peripherals, without departing from the scope of the invention.
• An alternate embodiment of a gaming machine and peripherals is illustrated inFIG. 4C. Here the gaming machine remains coupled to its associated network viacommunication path414 andnetwork distribution device405. The gaming machine includes anMPU402 and a number of peripheral devices. In this embodiment, the devices are coupled to thenetwork distribution device405 and/or theMPU402 via a plurality of protocols. These protocols could include parallel connections (e.g. lights406), I²C connections (e.g. keypad407), USB (e.g. card reader408), LVDS (e.g. primary display409) and other protocols. In this embodiment, theMPU402 and/or thenetwork distribution device405 convert from the non-Ethernet protocol to Ethernet protocol for communication via the network.
• Each 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.
• Similarly, Network Time Protocol (NTP) may be 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. In one embodiment of the gaming network, SNMPv3 is used to take advantage of embedded security mechanisms to mitigate malicious attacks made against the configuration management function. Still further, TFTP (trivial file transfer protocol) is used by servers to boot or download code to network components.
• 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 (i.e. transmission rate, loss rate, minimum bandwidth, packet delay, etc). 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. Any fraudulent traffic of that nature that does not request the appropriate QoS is considered an attack and appropriate quarantine and counter measures are taken.
• Similarly, the Type of Service (ToS) capabilities of IPv4 may also be used in a similar manner to provide additional security cues for validation of transactions. Again, certain types of transactions may be associated with a particular specific ToS or a rotating schedule of ToS that is known by network monitors.
• Traffic Content
• In an embodiment of the gaming network, the traffic content varies in size and sensitivity. Messages may comprise transactional messages related to game play, such as coin-in. Other messages may be related to management, administration, or sensitive information, such as administrator passwords, new game code, pay tables, win rates, patron personal data, or the like.
• Device Addressing
• In one embodiment of the invention, each device, including each peripheral device in a game machine, could have its own MAC address. The central server could be responsible for assigning IP addresses to each device and gathering the devices into bindings that represent a physical location of a device. For example, all of the bindings of a gaming machine may be in a single binding. Alternatively, thenetwork distribution device405 may be responsible for assigning IP addresses to the devices within the game machine.
• In one embodiment, there is a common IP address (e.g. 10.5.5.32) for the gaming machine and that is owned bynetwork distribution device405. (In some cases, theMPU402 and/or other devices, such as the printer, may have their own IP addresses). The remaining devices in the gaming machine are addressable by a unique port assignment attached to the common IP address. For example, PORT5020 could be associated with thecard reader408, PORT5030 with thehopper413, and the like. Even though the physical connection with the peripheral may be, for example, an RS232 connection, theMPU402 andnetwork distribution device405 communicate using the IP and PORT address. In some cases the communication itself may use a proprietary protocol yet still use the IP and PORT address as a destination.
• In cases where multiple protocols are used in the system, the network distribution service can act as an Internet Protocol Exchange (IPX) to facilitate the translation of TCP/IP network traffic to the native protocol of a device and vice-versa. In one embodiment, the device enablement may take advantage of a USB sharing hub such as the USB Multi-switch manufactured by Standard Microsystems, Corp.
• Initialization of Gaming Machine Devices
• An embodiment of the invention provides a process for identifying devices coupled to a game machine. This process is described inFIG. 5. Atstep501, during initialization, each device (e.g. devices404A-404N) attempts to communicate with the network and transmits its MAC/IP address. The address is received by a switch in the game machine (e.g. theSMIB403,network distribution device405, or the like) and a table of addresses of associated devices is assembled. This table is made available to the devices in the game machine so that the IP addresses of other devices within the gaming machine become available to each device.
• At theidentification step502 each device identifies itself to other devices in the gaming machine. At step503 a verification process is initiated so that it can be determined if the devices are valid devices on the network. Atstep504 devices may begin to transmit data between themselves and to the core layer or other back-end server of the network.
• MAC/IP Transmission
• A description of one embodiment of the MAC/IP transmission ofstep501 is illustrated in the flow diagram ofFIG. 6. During a boot orinitialization sequence601, any network-connected device inside the gaming machine will attempt to communicate with the network atstep602 by sending its MAC/IP address via the SMIB or other switching device. The nature of this initial communication may be for a DHCP or BOOTP configuration, an ARP request, or any other attempt to identify itself to the back-end system. The MAC/IP addresses that are part of these communication attempts are added atstep603 to a table. This table is managed by theSMIB403 in one embodiment, or by theMPU402 in another embodiment. Eventually atstep604, a table will be generated that contains the MAC/IP addresses of all of the devices in the gaming machine.
• In one embodiment, the devices send only their MAC addresses but the switch or other management device associates an IP address with each MAC address to populate a table. This embodiment may be used when IP addresses are assigned dynamically as described above.
• Atstep605, the switch or MPU, or whichever device is managing the address table, periodically transmits raw Ethernet frames, USB packets, or TCP packets that include a list of the attached MAC/IP addresses associated with that game machine. In one embodiment, the frame is sent on a regular basis (e.g. every three to five seconds) so that other devices can expect that frame and react appropriately if it is not received. The transmitted frame is sent to switches and game machines on the network. In one embodiment, the transmission is via User Datagram Protocol (UDP) but any suitable protocol may be used without departing from the spirit and scope of the invention. In this manner, game machine devices need only be able to recognize the frame to take action. Eventually all of the MAC/IP addresses of game machine devices are published throughout the network. In this embodiment, there is no necessity of flooding the network with broadcasts frames with address information. This information is distributed organically throughout the network.
• The process in one embodiment is an ongoing process, shown by the return path fromstep605 to step602 inFIG. 6. The tables are rebroadcast periodically by the switch. This rebroadcast allows devices to learn about other new devices that have been added to the network. It also allows a device to know when another device has left the network.
• At this point in the process the information being collected is pre-authentication. It allows a list of possible devices to be known and addressable so that if the device is valid and authenticated, it can participate on the network.
• Identification
• Theidentification process502 is described in conjunction withFIG. 7. A device receives a MAC/IP transmission frame from the switch atstep701. This is an ongoing process during runtime as the switch periodically transmits Ethernet frames containing updated and new MAC/IP address information as described above. Atstep702 the device identifies other devices within the same game machine or cabinet from information in the Ethernet frame. Atstep703 the device initiates an identification communication with one or more other devices in the game machine. The form of this transmission atstep704 may be as simple as sending an “I'm here” message. In other embodiments, the identification message may include identification information about the device atstep704. This information may include information such as the port address, device ID, a preferred communication protocol, and the like. In other embodiments, such information is provided during communication negotiations.
• Verification
• Once two devices have identified themselves to each other, a verification procedure can take place. The verification procedure is intended to establish that the device with which another device is communicating is a valid gaming device. In one embodiment of the invention, verification may be accomplished by using the protocol described herein in connection withFIGS. 3 and 4. Any suitable verification protocol may be utilized without departing from the scope and spirit of the invention. In-cabinet devices have similar security concerns as other network devices described herein. For example a device may not only need to identify itself to a central server, but may also need to identify itself to another device within the same cabinet.
• In one embodiment, a verification method is used such as is described in pending U.S. patent application Ser. No. 10/243,912, filed on Sep. 13, 2002, and entitled “Device Verification System and Method”, assigned to the assignee of the invention, and incorporated by reference herein in its entirety. The invention provides a system and method for verifying a device by verifying the components of that device. The components may comprise, for example, software components, firmware components, hardware components, or structural components of an electronic device. These components include, without limitation, processors, persistent storage media, volatile storage media, random access memories, read-only memories (ROMs), erasable programmable ROMs, data files (which are any collections of data, including executable programs in binary or script form, and the information those programs operate upon), device cabinets (housings) or cathode ray tubes (CRTs). Identification numbers or strings of the components are read and then verified. The process of verifying may comprise matching each identification number in a database to determine whether each identification number is valid. In the case where a data file comprises one of a plurality of operating system files, verification of that file, in effect, comprises verifying part of an operating system. For data files, the file names may comprise the identification numbers.
• The database may comprise a relational database, object database, or may be stored in XML format, or in a number of other formats that are commonly known. The database may also comprise an independent system stack of bindings, which comprise numbers, identification strings or signatures in the database for matching or authenticating the components, from manufacturers of the components, each identification number being verified using the binding from the manufacturer of the respective component to verify the component. Especially in the context of smaller devices such as personal digital assistants (PDAs), such a system stack may comprise a subset of one or more global component databases containing bindings from manufacturers of the components, each binding of the subset being associated with at least one of the identification numbers of one of the components in the device.
• Structural components, such as cabinets, may contain an electronic identification chip embedded within them, such as a so-called Dallas chip or an IBUTTON device manufactured by Dallas Semiconductor of Dallas, Tex. These devices allow a unique identifier, placed within a semiconductor or chip, to be placed on a component that may or may not be electronic, such as a computer or gaming machine cabinet. The IBUTTON device is a computer chip enclosed in a16 mm stainless steel can. The steel button can be mounted, preferably permanently or semi-permanently, on or in the structural component. Two wires may be affixed to the IBUTTON device, one on the top, and one on the bottom, to exchange data between the IBUTTON device and a processor, serial port, universal serial bus (USB) port, or parallel port.
• The matching process may comprise matching each identification number based on the type of component that the identification number identifies. The identification number and the type of component are matched in the database in order to verify that the identification number is valid. Operation of the device may be stopped if any one of the identification numbers is not matched in the database. In the case of a game or gaming machine type of device, a tilt condition message is generated if any one of the identification numbers is not matched in the database.
• The database may consist of a set of signatures, also called bindings. At least with respect to the components that comprise data files or firmware, a well-known hash function, the Secure Hash Function-1, also known as SHA-1, may be used to compute a 160-bit hash value from the data file or firmware contents. This 160-bit hash value, also called an abbreviated bit string, is then processed to create a signature of the game data using an equally well-known, one-way, private signature key technique, the Digital Signature Algorithm (DSA). The DSA uses a private key of a private key/public key pair, and randomly or pseudorandomly generated integers, to produce a 320-bit signature of the 160-bit hash value of the data file or firmware contents. This signature is stored in the database in addition to the identification number.
• Either contained in the device, or in communication with the device, is a processor and a memory containing executable instructions or a software program file for verification of the components (verification software), which may itself be one of the components to verify. The verification software may be stored on a persistent storage media such as a hard disk device, read only memory (ROM), electrically erasable programmable read-only memory (EEPROM), in the aforementioned CMOS memory, battery-backed random access memory, flash memory or other type of persistent memory. Preferably, the verification software is stored in a basic input/output system (BIOS) on a solid-state persistent memory device or chip. BIOS chips have been used for storing verification software, such as the BIOS+ chip used by Bally Gaming Systems, Inc. of Las Vegas, Nev. in their EVO gaming system. Placing the verification software in the BIOS is advantageous because the code in the BIOS is usually the first code executed upon boot or start-up of the device, making it hard to bypass the verification process.
• Alternatively, the verification software may be stored in a firmware hub, which may comprise the part of an electronic device or computer that stores BIOS information. In personal computer hub technology, such as that manufactured by the Intel Corporation of Santa Clara, Calif., a hub is used in place of a peripheral component interconnect (PCI) bus to connect elements of chipsets.
• The persistent storage media may be a removable storage unit such as a CD-ROM reader, a WORM device, a CD-RW device, a floppy disk device, a removable hard disk device, a ZIP disk device, a JAZZ disk device, a DVD device, a removable flash memory device, or a hard card device. However, the database is preferably stored in a non-removable, secure device either within the device being verified, or remotely on a server, in order to enhance security.
• The verification software executes a DSA verification of the data files and firmware components. Also stored in the database is the public key of the private key/public key pair. For each data file and firmware component, as part of the DSA verification, the processor and verification software first computes the hash value of the digital contents of the component using the SHA-1 algorithm. The verification software then processes or authenticates this computed hash value, using the DSA signature verification algorithm, which also takes, as input, the aforementioned public key stored in the database. The verification part of the DSA produces a Boolean result (yes or no) as to whether the inputs solve the algorithm. If the algorithm is not solved by the inputs, then an unexpected result is produced, thereby failing to verify the particular component. This may cause a fault tilt to occur to prohibit the loading operation of the device. Otherwise, use of the device is permitted. A detailed description of the DSA can be found in the U.S. government's Federal Information Processing Standards Publication (FIPS) 186-2. That publication describes each step of the DSA signature generation and verification.
• Alternatively, the set of executable instructions may use the Rivest-Shamir-Adleman (RSA) algorithm to verify the components. Using the RSA algorithm, a first abbreviated bit string or hash value is computed from each component's digital contents and encrypted into a digital signature. The digital signature is stored in the database along with the identification number for the component. When the device is verified, the component is verified by computing a second abbreviated bit string computed from the component's digital contents. The signature is retrieved from the database by searching the database for the identification number. The signature is decrypted to recover the first abbreviated bit string. The component is then verified by comparing the second abbreviated bit string with the first abbreviated bit string. If the first and second abbreviated bit strings do not match, then the component is not verified. As discussed below, this may cause a fault tilt to occur to prohibit the loading operation of the device. Otherwise, use of the device is permitted.
• Instead of creating a digital signature for, or signing, each data file individually, collections of data files may be signed together in order speed up processing. The abbreviated bit strings, hash values, or signatures, also called digests, of the collection of data files are collected into a catalog file, and the catalog is signed as described above.
• Communication
• After verification between devices has been completed, they may begin communication. Atstep801 ofFIG. 8, a device initiates a communication with another device. The sending device may include a section of the first message to provide needed information to the intended recipient. This information may include atstep802 the type of device, the protocol the device is using, any restrictions related to QOS, and other communication related information. At step803 the recipient determines if it can communicate with the sender directly or if an interface is needed atdecision block804. If an interface is needed atstep806, the sender and receiver may need to communicate through the MPU orinterface110, for example, if the MPU includes software or firmware for translating appropriately for the devices. If the devices can communicate directly, then messages are sent back and forth using an accepted protocol atstep805.
• The invention allows devices to be aware of each other's presence through MAC/IP transmissions. This permits the use of a single network port for each device to use to communicate with each other and with a back-end system. The devices do not need pre-knowledge of the MAC/IP addresses of other devices but can learn them at start up and during run-time. The system also allows a new device to be added to a game cabinet and have it be integrated and identified to the system without extensive IT effort.
• Although the invention has been described in connection with in-cabinet devices identifying themselves to each other, it is not limited to such an application. The invention may be used to provide identification of any network devices by organically updating identification information periodically in Ethernet frames. In addition, the invention is not limited to the specific network configuration described herein. Rather, the system can work with any number of network configurations without departing from the scope and spirit of the invention.
• It will be apparent from the foregoing that, while particular forms of the claimed invention have been illustrated and described, various modifications can be made without departing from the spirit and scope of the claimed invention. Accordingly, it is not intended that the claimed invention be limited, except as by the appended claims.

Claims (8)

1. A gaming network comprising:

a first sub-network using a first network protocol;

a second sub-network using a second network protocol;

an interface coupled to the first and second sub-networks to translate messages between the first and second sub-networks.

2. The gaming network ofclaim 1 wherein the second network protocol is SOAP over HTTPS.

3. The gaming network ofclaim 1 wherein the first network protocol is a proprietary system.

4. The gaming network ofclaim 1 wherein the interface comprises an S2S transport protocol.

5. The gaming network ofclaim 1 further including a first inbound command queue in said first sub-network for receiving messages containing commands from the second sub-network.

6. The gaming network ofclaim 5 further including a first outbound command queue in said first sub-network for sending messages containing commands to the second sub-network.

7. The gaming network ofclaim 6 further including a second inbound command queue in said second sub-network for receiving messages containing commands from the first sub-network.

8. The gaming network ofclaim 7 further including a second outbound command queue in said second sub-network for sending messages containing commands to said first sub-network.

Images