US20070105628A1 - Download and configuration system for gaming machines - Google Patents

Download and configuration system for gaming machines Download PDF

Info

Publication number
US20070105628A1
US20070105628A1 US11/530,452 US53045206A US2007105628A1 US 20070105628 A1 US20070105628 A1 US 20070105628A1 US 53045206 A US53045206 A US 53045206A US 2007105628 A1 US2007105628 A1 US 2007105628A1
Authority
US
United States
Prior art keywords
package
download
egm
software
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/530,452
Inventor
Christopher Arbogast
Travis Green
William Jones
Dale Shepherd
Ronald Cadima
Thomas Buckeyne
Anthony Green
Pravinkumar Patel
Robert Crowder
Joshua Larsen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LNW Gaming Inc
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to US11/530,452 priority Critical patent/US20070105628A1/en
Priority to EP06814544A priority patent/EP1934869A4/en
Priority to PCT/US2006/035556 priority patent/WO2007033207A2/en
Priority to AU2006290982A priority patent/AU2006290982A1/en
Priority to CA002622577A priority patent/CA2622577A1/en
Assigned to BALLY GAMING, INC. reassignment BALLY GAMING, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: JONES, WILLIAM K., GREEN, TRAVIS, SHEPHERD, DALE M., ARBOGAST, CHRISTOPHER P., BUCKEYNE, THOMAS E., CADIMA, RONALD A., CROWDER, ROBERT W., GREEN, ANTHONY E., LARSEN, JOSHUA D., PATEL, PRAVINKUMAR
Publication of US20070105628A1 publication Critical patent/US20070105628A1/en
Priority to US13/033,833 priority patent/US20120220374A1/en
Assigned to SG GAMING, INC. reassignment SG GAMING, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: BALLY GAMING, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3202Hardware aspects of a gaming system, e.g. components, construction, architecture thereof
    • G07F17/3223Architectural aspects of a gaming system, e.g. internal configuration, master/slave, wireless communication
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3225Data transfer within a gaming system, e.g. data sent between gaming machines and users
    • G07F17/323Data transfer within a gaming system, e.g. data sent between gaming machines and users wherein the player is informed, e.g. advertisements, odds, instructions
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3225Data transfer within a gaming system, e.g. data sent between gaming machines and users
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F17/00Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3225Data transfer within a gaming system, e.g. data sent between gaming machines and users
    • G07F17/3227Configuring a gaming machine, e.g. downloading personal settings, selecting working parameters

Definitions

  • a casino floor may include thousands of electronic gaming machines (EGMs) that are in communication with and monitored by the casino's gaming network.
  • EGMs provide an enhanced gaming experience with computer graphics, stereo sound, animation, and other features that have been developed to maintain player interest in the game.
  • EGMs may include secondary networked devices such as player tracking devices or enhanced player interfaces (e.g., Bally Gaming's iViewTM touch-screen display). Accordingly, there are a large number of EGMs and related components that need to be monitored, maintained, and serviced.
  • 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.
  • gaming machines have become customizable via electronic communications and remotely controllable.
  • Manufacturers of gaming equipment have taken advantage of the increased functionality of gaming machines by adding additional features to gaming machines, thereby maintaining a player's attention to the gaming machines for longer periods of time increasing minimum bet and bet frequency and speed of play. This, in turn, leads to the player wagering at the gaming machine for longer periods of time, with more money at a faster pace, thereby increasing owner profits.
  • the amount of interactivity and data presentation/collection possible with current processor based gaming machines has led to a desire to connect gaming machines in a gaming network.
  • 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.
  • a technician typically needs to travel to the gaming machine in order to replace existing software package media (e.g., EPROMs, CD-ROM's, Compact Flash, etc.) with new software package media.
  • existing software package media e.g., EPROMs, CD-ROM's, Compact Flash, etc.
  • the software package update process may require that the EGM be disabled hours in advance to prevent any players from using the EGM when the technician is ready to perform software package changes.
  • EGMs may be disabled prior to software package updates, but the technician must periodically check to ensure that the EGM(s) are not being used by a player.
  • technicians may need to be supervised during the process of software package installation as the technician has access to critical areas of the EGM required for configuration or of those areas of containing cash.
  • Typical transfer mechanisms provide point-to-point transfer where a Software Distribution Point (SDP) will transfer to a single EGM until the transfer is complete, and then the SDP may transfer to another EGM.
  • SDP Software Distribution Point
  • installing packages on an EGM can require verification that dependent software packages and hardware components are available within the EGM. This is typically a manual process that prone to human interpretation and human error.
  • various embodiments are directed to management of gaming devices over a network.
  • the system allows a casino operator to manage groups of electronic gaming machines (EGMs).
  • EGMs electronic gaming machines
  • Managing new or existing collections (i.e., groups) of gaming devices reduces the effort required to download or configure large numbers of EGMs.
  • new software may be downloaded to groups of EGMs from a central location, and the EGMs may be configured from the central location. Accordingly, this operational efficiency reduces maintenance costs and minimizes EGM downtime due to maintenance or EGM set-up.
  • EGMs can be updated over the network via a multicast over TCP/IP or some other suitable mechanism.
  • a package containing game information and/or configuration information is created at a server.
  • the package is delivered to an EGM over the network.
  • the packages can be downloaded via a background thread and may take place while the EGM is enabled or disabled or even when a player is actively playing the EGM.
  • the system includes a scheme for EGM's to report corrupted or missing packets from the transfer, which the SDP will use to resend the packets.
  • the SDP will use the multicast protocol to resend the packets, potentially reducing the network bandwidth used during error recovery.
  • the system includes a package validation method that uses digital signatures.
  • a digital signature is provided with each package, which an EGM can use to validate the package and authenticate the origin of the package.
  • the EGM will not install or use a package that does not pass validation.
  • the system includes technology necessary for the System Management Point (SMP) to manage package dependencies (dependencies such as a new package-A that requires package-B and package-C to operate). This technology can be used to confirm that new package-A dependencies are addressed before requesting the EGM to transfer a new package. Additionally, the SMP can determine the dependencies and request that those packages also be transferred to the EGM.
  • SMP System Management Point
  • the system includes technology necessary for the SMP to determine if a package's dependent hardware components are available on the EGM.
  • the concept is similar to the package dependencies; however the SMP can not automatically transfer hardware components to an EGM to satisfy package dependencies. If a package's required hardware dependencies are available on the EGM, then the package transfer to the EGM will be permitted; otherwise, the package transfer will not be permitted.
  • the system may designate that a collection of gaming machines should have a particular status at a given time. Changes or status may be applied to different collections of gaming machines.
  • the network system allows a casino operator to define changes to software inventory (i.e., via download) and to schedule configuration changes. For example, a casino operator can define default payouts and denominations, schedule recurring overrides for weekends, and schedule a one-time override for a holiday or casino promotion. Accordingly, these changes can occur without further operator interaction. As a result, casino management does not need to be in attendance every time the slot floor assumes a new configuration.
  • the configuration changes are communicated during the background operation of the EGM without affecting gameplay, and the changes are applied at a designated convenient time (e.g., a predetermined period of time after the credit meter reaches zero credits). Accordingly, the EGM does not need to be placed in an inactive state prior to downloading configuration changes.
  • conflicts will only occur for assignments of the same type (e.g., download and configuration).
  • download/configuration conflicts are avoided by running the download process before the configuration process with the exception that data related to host and owner information will supersede other assignments.
  • conflicts may arise as a result of an EGM being a member of different collections where membership may vary depending on the moment in time. For example, switching an EGM from a 5 cent denomination to a 25 cent denomination may switch the membership of the EGM to another collection (e.g., all 25 cent EGMs).
  • the network system includes various methods to resolve situations where EGMs are given improper settings (e.g., the system will filter out settings that the EGM does not support). As a result, these methods provide consistent procedures as to how the network host configures EGMs when more than one assignment applies.
  • the network system uses option templates to support pre-configuration because a particular EGM or game theme within an EGM may support a large number and wide variety of options.
  • option definition templates such as Combo Option templates or Option Group templates may be used to define the configuration of new content before it is downloaded to an EGM.
  • a casino operator may schedule the download of a new game theme during off-hours and have the network host configure the new game theme as soon as installation is completes without requiring operator intervention.
  • the network system provides a method of recognizing when an EGM needs data downloads or configuration, and the network coordinates these activities to avoid conflicts. For example, in one method, attempts to configure an EGM will be prevented until downloads for the EGM are completed. In another method, the network host automatically restores data modules and configures an EGM if it has been RAM-cleared or has been offline. Accordingly, an operator can monitor and manage a group of EGMs from a single terminal, thereby eliminating the need for slot technicians to collect configuration data and to manually reconfigure each EGM.
  • the network system distributes (i.e., downloads) data packages through the use multicast sessions, where the EGMs request all or part of a data package (as directed by the download server).
  • This method may also include a lossless transport mechanism and an IP multicast as the distribution mechanism.
  • the multicast distribution mechanism conserves network bandwidth, can be throttled at the host, and prevents low priority activities (e.g., download) from interfering with critical communications (e.g., vouchers or events).
  • Another method is directed to minimizing memory storage consumption associated with package downloads to EGMs.
  • the host downloads a package (e.g., BLOB (Binary List of Bytes)) to the EGM.
  • the package is then authenticated and may then be installed immediately or at a later scheduled time.
  • the package may optionally be removed from the EGM. For example, portions of package may be removed by overwriting the package with new packages.
  • the package's contents are tracked by the resulting versioned modules that have been installed on the EGM.
  • FIG. 1 illustrates an embodiment of a gaming network that may be used with the system.
  • FIG. 2 illustrates an overview of download interaction
  • FIG. 3 illustrates an overview of EGM Startup message flow.
  • FIG. 4 depicts the logic flow of /dev/download driver initialization.
  • FIG. 5 is a flow diagram illustrating a routine to validate download requests and pass control to the proper handler function.
  • FIG. 6 is a flow diagram illustrating the add package logic of the download driver.
  • FIG. 7 is a flow diagram illustrating the download control process addPackage logic.
  • FIG. 8 illustrates the message flow for the download receiver addPackage process.
  • FIG. 9 illustrates the logic flow for the DR.
  • FIG. 10 is a flow diagram illustrating the pre-requisite process.
  • FIG. 11 illustrates the logic flow for this process.
  • FIG. 12 is an overview of how the package is installed on the EGM.
  • the system supports data downloads and configuration of gaming machines such as, but not limited to, electronic gaming machines (EGMs).
  • EGMs electronic gaming machines
  • a casino operator may define a collection of EGMs, assign modules to one or more collections of EGMs, assign configuration changes to one or more collections of EGMs, and schedule all assignments.
  • the system permits some or all of the software that is to be run on an EGM to be centrally stored in a software distribution library located on one or more servers.
  • the software can be sent over a network (such as an Ethernet network) as desired for initial set up of an EGM, as updating of an EGM, game replacement, configuration, or any other desired purpose.
  • the system utilizes multicasting to download software packages to the EGMs in the background, even while full game play is ongoing.
  • the server does a single multicast transfer of one or more packages to all target machines.
  • Each EGM tracks the packages and notes missing, corrupted, or dropped packets.
  • the server receives requests from all EGMs for packets to resend and again multicasts them to all EGMs, regardless of which EGM requested which packet.
  • the individual EGMs accept needed missing packets and ignore other re-broadcast packets.
  • the system is not limited to multicast transmissions but may use HTTP, HTTPS, FTP, SFTP, and other transmission protocols.
  • EGM is intended to encompass any type of gaming machine, including hand-held devices used as gaming machines such as cellular based devices (e.g. phones), PDAs, or the like.
  • the EGM can be represented by any network node that can implement a game and is not limited to cabinet based machines.
  • the system has equal applicability to gaming machines implemented as part of video gaming consoles or handheld or other portable devices.
  • a geo-location device in the handheld or portable gaming device may be used to locate a specific player for regulatory and other purposes.
  • Geo-location techniques that can be used include by way of example, and not by way of limitation, IP address lookup, GPS, cell phone tower location, cell ID, known Wireless Access Point location, Wi-Fi connection used, phone number, physical wire or port on client device, or by middle tier or backend server accessed.
  • GPS and biometric devices are built within a player's client device, which in one embodiment, comprises a player's own personal computing device, or provided by the casino as an add-on device using USB, Bluetooth, IRDA, serial or other interface to the hardware to enable jurisdictionally compliant gaming, ensuring the location of play and the identity of the player.
  • the casino provides an entire personal computing device with these devices built in, such as a tablet type computing device, PDA, cell phone or other type of computing device capable of playing system games.
  • the software distribution network consists of a top level vender distribution point 101 that contains all packages for all jurisdictions, one or more Jurisdiction distribution points 102 A and 102 B that contain regulator approved production signed packages used within that jurisdiction or sub-jurisdiction, one or more Software Management Points 103 A and 103 B to schedule and control the downloading of packages to the EGM and a one or more Software Distribution Points 104 A and 104 B that contain regulator approved production signed packages only used in the gaming establishment that it supports.
  • the Software Distribution Points (SDPs) 104 A and 104 B can communicate with Systems Management Points (SMPs) 105 A and 105 B, respectively as well as directly to one or more EGMs 106 A and 106 B.
  • SDP and SMP Systems Management Points
  • the communication between SDP and SMP is optional.
  • a benefit is to permit the SMP and the user access to the catalogue of software packages available on the SDP).
  • the system allows for rapid and secure distribution of new games and OS's from a centralized point. It makes it possible to update and modify existing gaming machines with fixes and updates to programs as well as providing modifications to such files as screen images, video, sound, pay tables and other EGM control and support files. It provides complete control of gaming machines from a centralized control and distribution point and can minimize the need and delay of human intervention at the EGM.
  • a 1 GB compact flash card will initially be used as the storage media in the EGMs for OS and download package storage.
  • a second compact flash will be used for the storage of the production game as it exists today.
  • the OS compact flash will be partitioned into production, backup, and download areas.
  • the production area contains the active OS and game management software used to allow the playing of games on the EGM. This part of storage will have all the file integrity checking and validation performed on it.
  • the other areas will be used to store backup software and data, new download packages, installation of the new packages and saving of NVRAM, counters, random number data and other secure information in an encrypted data format.
  • Software downloads will be scheduled by gaming personnel via the SMPs.
  • the SMP notifies the individual gaming machines they have been scheduled to receive a download package from a specific vendor Software Distribution Point (SDP).
  • SDP Software Distribution Point
  • the system solves the network bandwidth usage problem by using a multicast network protocol, which the SDP uses to broadcast the transfer to multiple EGM's simultaneously.
  • the SDP will send a single transfer to a defined set of EGM's, thereby using a fraction of the network bandwidth when compared to the point-to-point strategy. If there are X groups of EGM's, with each group consisting of Y EGM's, then the following calculations provide a general sense of reduced network bandwidth usage: Multicast: X * transferSize Point-to-point: (X * Y) * transferSize Gross Improvement: 1/Y network usage with multicast.
  • the system includes a recovery scheme to accommodate transmission error or reception error of the package.
  • This recovery scheme allows each EGM to report missing pieces (packets) where either not received or received with errors (data corruption).
  • the SDP logic can accumulate a list of missing packets and the corresponding EGM's, and use the multicast protocol to resend the missing packets.
  • the specific packages that are transferred are specified by the EGM.
  • the EGM makes requests to the SDP using a point-to-point protocol.
  • the SDP may not service these requests immediately, so the EGM is permitted to operate while waiting for the transfer and during the transfer.
  • the EGM is responsible for logging transfers and checking the validity of the completed transfer. This log can be used to reconcile the package content of the EGM at any given time. Additionally, the SDP will log transfer activity and provide a means to cross check the package content of an EGM.
  • An EGM validates transferred packages using a digital signature. This digital signature provides authentication of the package itself regardless of the specific SDP server that provided it, and is used to determine if the package incurred any transmissions errors. If an EGM is unable to validate a package, then the package will not be installed or otherwise used.
  • the system includes technology necessary to determine if an EGM contains packages necessary to use a new package (package dependencies). If a given package-A requires additional packages, package-B and package-C, to operate on the EGM, the dependencies can be determined from a package header contained within package-A. The SMP can then determine if the EGM already contains the dependent packages, package-B and package-C, before requesting that package-A be transferred to the EGM. Similarly, the SMP can automatically select the dependent packages to be transferred in addition to the original package-A, thus fulfilling the dependencies of package-A. This aspect of the system provides a level of assurance that the packages transferred can actually be used by the EGM.
  • the system includes technology necessary to determine if a package's dependent hardware components (components) are available on the EGM. If package-X requires component-Y and component-Z, the SMP can read the components of the EGM and use this information for component dependency checking. If a package's required component dependencies are available on the EGM, then the package transfer to the EGM will be permitted; otherwise, the package transfer will not be permitted. This aspect of the system provides a level of assurance that the packages transferred can actually be used by the EGM.
  • the ability to transfer software directly to the EGM provides additional alternatives when installing a new EGM on the casino floor.
  • An EGM that is manufactured and placed directly on the casino floor can be initially loaded with a boot-strap media (EPROM, CD-ROM, Compact Flash, etc.) that can boot the EGM and prepare communications before requesting new packages to install.
  • boot-strap media EPROM, CD-ROM, Compact Flash, etc.
  • Two boot-strap methods may be used to transfer software to an EGM. Both methods require minimal configuration of an EGM before the boot-strap process can be completed.
  • Minimal configuration consists of the following:
  • a unique network IP Address for the EGM This can be provided by a DHCP system, or assigned to the EGM via operator configuration.
  • a unique EGM identifier that is derived from the EGM hardware (such as network card MAC address) or assigned to the EGM via operator configuration.
  • the simple boot-strap mode requires that EGM is also configured with the necessary options to locate the SMP network server. This can be a hard-coded default address that may be overridden via operator configuration. This address is used by the EGM to locate the SMP server, which can then assign new packages to the EGM for transfer.
  • the EGM and its associated peripherals can be identified using a scheme such as is described in U.S. patent application Ser. No. 11/319,034 entitled “Device Identification” and incorporated in its entirety herein by reference.
  • a device sends its MAC address out on the network.
  • a local switch collects MAC and IP addresses for the devices connected to it.
  • the switch Periodically, transmits raw Ethernet frames, USB packets, or TCP packets containing tables of devices and associated MAC/IP addresses.
  • the device may attempt communication with that device. First, a verification procedure is used to validate the devices. Subsequently, communication is possible between the devices.
  • the advanced boot-strap mode involves the EGM requesting a default boot-strap package from the SDP.
  • the package name for this boot-strap package is predefined and known to both the EGM and the SDP.
  • This boot-strap package contains configuration files that identify the default software packages and configuration data.
  • the boot-strap package can be customized for the specific installation (casino) and stored on the SDP. This way all EGM's will request the predefined boot-strap package, the SDP will transfer the boot-strap package to the EGM, and the EGM will process the boot-strap package.
  • the EGM can read the SMP address, default EGM OS package, and other packages such as default peripheral firmware packages. At this point the EGM can request these packages from the SDP, and the SDP will begin transferring the default packages to the EGM, ultimately ending with an EGM ready for configuration.
  • FIG. 2 illustrates an overview of download interaction between the System Management Point 105 , EGM 106 , and Software Distribution Point 104 .
  • the design consists of a download device driver which provides the central control logic and logic. It interfaces with the Download Class (which may be G2S or any other protocol) and a download control thread. The download control thread controls requesting and downloading packages from the download distribution point server.
  • the Download Class which may be G2S or any other protocol
  • the System Management Point 105 sends package commands and requests to the Download Control 206 of EGM 106 to tell it to add and delete packages, install packages and request information about packages and installed modules.
  • the Download Control 206 will filter these requests and pass then to the Download Driver 207 for processing. Requests to add packages are then given to the Download Receiver Process 208 which then opens communications with the Software Distribution Point 104 .
  • the Download Receiver Process 208 receives the package data from the Software Distribution Point 104 via a multicast (or any other defined transmission protocol) link 204 in multiple packets and assembles the package in compact flash. Once all packets of the package have been received, the package data is verified using a SHA-1 verification string passed in the package header. The appropriate status and package state information shall be passed back to the Download Driver 207 which passes it to the Download Control 206 for logging and passing back to the System Management Point.
  • the download driver is installed when the EGM system is started. It's primary functions are to:
  • the Download Control Process 206 is either a thread running within the game manager context or a standalone process when there is no game manager running on the system. It's primary tasks are:
  • the Download Receiver Process 208 is responsible for communications between the EGM 106 and the Software Distribution Point 104 . It's primary functions are:
  • the Download Package Installer Process 209 is responsible for installing the packages that are downloaded from the Software Distribution Point 104 . It is notified of when to start installing a downloaded package when a set install rule command is sent from the Systems Management Point 105 . It receives this command via a read to the Download Driver 207 .
  • the basic functions of the Download Package Installer Process 109 are:
  • FIG. 3 illustrates an overview of EGM startup message flow.
  • EGM 106 sends a message 302 to SDP 104 requesting a package.
  • SDP 104 replies with a message 303 indicating package size and the multicast IP/Socket that will be used for transmission.
  • Message 304 from SDP 104 to EGM 106 is the package data itself. If necessary, EGM 106 can request missed packets by sending a message 305 .
  • the system uses multicasting to send packages to multiple EGMs.
  • SDP 104 collects a number of requests and sends out multicasts of all missed packets to all of the EGMs. If a particular EGM does not need one of these re-broadcast packets, it is ignored. Otherwise, the EGM accepts the re-broadcast packet and uses it to complete the package transmission.
  • all set status, set error information and command information is passed to the driver 207 via an IOCTL call.
  • the processes use the read interface to get processing instructions from the driver 207 .
  • the Download Receiver 208 uses the read interface to get add package requests
  • the Download Installer Process 209 uses the read to obtain set install rule requests
  • the Download Control Process 206 uses the read interface to receive the status and error information from the Receiver and Install processes.
  • DI_Init_module( ) is the first routine to gain control when the module is loaded. It will:
  • the ioctl entry point DL_ioctl( ) will process all the System Management Point 105 requests passed through the Download Control Process received from the download class.
  • the DL_read( ) entry point services all the read requests from:
  • the Download Control Process 206 for packages status and error
  • the Download Receiver process 208 to pass add package requests.
  • the Download Installer 209 to receive set install rule request.
  • FIG. 4 depicts the logic flow of /dev/download driver initialization.
  • the Read Queue areas and semaphores are initialized.
  • the package is initialized and the Install Rule Data Structures are set.
  • the driver is registered with the system and at step 404 the system returns.
  • the dl_ioctl( ) driver 207 serves as the interface to the Download Control Process 206 , and the Receiver 208 and Install 209 processes. All requests from System Management Point 105 are passed through Download Control Process 206 and either passed onto the driver 207 to be processed, or in the case of module and log requests, processed within the Download Control Process 206 itself.
  • the dl_ioctl( ) is a command ID to determine what to do with the specific request.
  • FIG. 5 is a flow diagram illustrating a routine to validate download requests and pass control to the proper handler function.
  • step 501 the particular switch that is set on the Command ID is examined so that the request from the SMP 105 can be routed to the correct handler.
  • Add and delete Package commands are provide to DL_Packages 502 .
  • Set and Delete Install rules are passed to DL_Install 503 .
  • Set Status, Retrieve Status, retrieve List commands are sent to DL_Status 504 .
  • Register processes are sent to block 505 where the Pid of the Process being registered is saved. Unknown commands return an error event at 506 .
  • the addPackage command from the Download class is processed by the Download Control Process 206 , the download driver 207 and the download receiver process 208 . Breaking up the processing into these three areas helps to maintain isolation between specific function for easily adapting the code to support operation both with any protocols as well as providing the capability to integrate different package download protocols and requirements that may arise in the future.
  • FIG. 6 illustrates the download driver 207 addPackage logic. The addPackage logic checks to see if the package already exists on the EGM and if there is enough room to store the package information. If so, it will send the package information to the Download receiver's driver read queue and the Download control driver's read queue and post the read semaphores if a read is outstanding.
  • step 601 there is an addPackage request.
  • step 602 it is determined if the requested package exists. If no, the system returns a package exists error at step 603 . Otherwise the system proceeds to step 604 to determine if the maximum number of packages is already queued. If yes, a return queue full error is returned at step 605 . Otherwise the system proceeds to step 606 and adds addPackage information into the package table.
  • step 607 addPackage is placed in the receiver read queue.
  • step 608 it is determined if there is a receiver read outstanding. If not, the system returns normal status at step 609 . Otherwise, the system posts a receiver read sleep semaphore at step 610 .
  • step 611 the addPackage status is placed in the control read queue.
  • step 612 it is determined if there is a control read outstanding. If no, the system returns normal status at steps 609 . If yes, the system posts a control read sleep semaphore at step 613 and returns normal status at step 609 .
  • the download control process 206 has a thread that performs reads from the download driver 207 .
  • the operation of FIG. 7 is followed.
  • the package information is written to the /Packages/Packages directory using the package ID as the file name.
  • a log entry is also created and written to the package log in the /Packages/Logs directory.
  • a package status message is created and sent back for delivery to the System Management Point.
  • the addPackage is read from the driver.
  • the addPackage information is written to disk.
  • a read is issued to the download driver.
  • the Download receiver is responsible for downloading the package identified in the addPackage message from the Software Distribution Point 104 .
  • FIG. 8 illustrates the message flow for accomplishing this task. The message flow is between the SMP 105 and EGM 106 , and between EGM 106 and SDP 104 .
  • the Download Receiver (DR) process 208 is the one that communicates with the Software Distribution Server.
  • the addPackage command 801 contains the IP and socket address of the Distribution Server to be contacted.
  • the DR 208 opens the link to the SDP 104 and requests 806 the package identified within the addPackage command be sent to it.
  • the SDP 104 responds 807 with a message containing packet size, timeout values, the size of the package, and the multicast port to receive the data on.
  • the DR 208 sends download initiate status 802 and download progress messages 803 to SMP 105 .
  • the DR 208 keeps track of the packets sent and will request a resend 809 for any packets not received. Those packets are resent 810 as part of a multicast. After all packets have been received 804 , a SHA-1 value will be calculated for the data portion of the package and compared 805 against the validation string sent as part of the package.
  • FIG. 9 illustrates the logic flow for the DR 208 .
  • the DR read is initiated.
  • a link is opened to the SDP 104 .
  • the response from the SDP is read at step 907 .
  • a multicast socket is opened.
  • the status is sent to the DR via ioctl.
  • the DR reads from the multicast socket.
  • step 915 the downloaded package is validated (e.g. using SHA-1).
  • step 916 it is determined if the data is validated. If not, a package error status message is sent to the download driver at step 917 . Otherwise a package validated status is sent to the download driver at step 918 and the system returns to step 905 .
  • the deletePackage command is processed by the Download Control 206 and Receiver 208 processes and by the Download Driver 207 .
  • the download driver 207 receives a deletePackage request, if the status of the package is not validated or there is an error, the status is reset to delete pending and the delete package command is sent to the download receiver 208 .
  • the download receiver process 208 should then delete any files it has created and terminate any download activity for the file. When the cleanup is complete, it will send a deleted status back to the download driver 207 and resume its read from the download driver 207 .
  • the download driver 207 When the download driver 207 receives a package deleted status, or if the original status of the package was validated or error, the download driver 207 frees the package data save area and sends a deletePackage complete status to the Download controller process 206 .
  • the download controller process 206 logs the new status in the package log and deletes the package status file from the /Packages/Packages directory. It then sends the delete complete status back to the SMP 105 .
  • the setInstallRule Download Class command is processed by the Download Control process 206 , the Download Installer Process 209 and the Download Driver 207 .
  • the Download Control process 206 maintains the updated status of the setInstallRule on disk and in the install rules log file, as well as sending the status back to the SMP 105 via messages.
  • the download driver 207 acts as the interface between the Download Control Process 206 and the Download install process 209 . It will also validate the package does not already exist and that there is enough room to process the install rules.
  • Parsing of the setInstallRule command and the pre-requisite conditions contained in the package header is the first step in installing a download package.
  • the package header is examined to extract the information as to what hardware requirements the package to be installed needs as well as any software that needs to be on the EGM in order to support the package.
  • software prerequisites these can refer to already installed software, or software contained in other packages that have been downloaded and are ready to install.
  • FIG. 10 is a flow diagram illustrating the pre-requisite process.
  • step 1001 the validation process begins.
  • step 1002 it is determined if the requisite hardware is present for the download package. If so, a table of installed hardware data is build at step 1003 .
  • step 1004 the loop of hardware prerequisites is read from the package header.
  • step 1005 it is determined if the prerequisites are in fact in installed in the hardware table. If so it is determined at step 1006 if all the prerequisites are met. If so, return success at step 1008 . If not, return to step 1004 .
  • step 1005 If the prerequisites are not installed in the table at step 1005 , an install error is logged at step 1009 .
  • step 1010 the install status is sent to the SMP 105 and an error is returned at step 1011 .
  • step 1007 If the hardware prerequisites are not present at step 1002 , it is determined at step 1007 if the software prerequisites are present. If no prerequisites are specified, return success at step 1008 If yes at step 1007 , build a table of required software at step 1012 . At step 1013 build a table of available modules from the installed module inventory. At step 1014 build a table of modules from available packages. At step 1015 loop through the prerequisite table.
  • step 1016 determine if the prerequisites are found in the installed modules. If the prerequisite isn't satisfied by the installed modules, step 1019 determines if the prerequisite may be satisfied by packages that have not yet been installed If the prerequisite can't be satisfied, log install error at step 1009 . Otherwise remove the prerequisite from the table at step 1017 . At step 1018 determine if all prerequisites are satisfied. If yes return success at step 1008 . If not, return to step 1014 .
  • step 1016 determines if the prerequisite is in the package table at step 1019 . If not, log install error at step 1009 . If so, determine at step 1020 if the package prerequisites are in the prerequisite table. If yes, return to step 1015 . If not, add package modules to the prerequisite table at step 1021 and return to step 1015 .
  • the install rules contain information on when to disable the machine to prevent game playing and if a time delay is required after disabling the game, what trigger to use to start the installation process, and whether the host needs to authorize the install once all other conditions have been met.
  • FIG. 11 illustrates the logic flow for this process.
  • the DL_Installer( ) routine is initiated.
  • step 1102 it is determined if the time window for the install is met. If not, the system waits for the install period at step 1103 . Otherwise at step 1104 it is determined if the disable conditions are met. If so, disable the coin and bill collectors at step 1105 . Oherwise determine if disable should be immediate at step 1106 . if not determine if there should be disable none at step 1107 . If no, determine if disable zero credit is true at step 1108 . If note return error and exit at step 1109 .
  • step 1108 determine if the disable wait time has expired at step 1110 . If not wait for the disable time at step 1111 . For true at 1106 , 1108 , 1110 , or after step 1111 , disable the coin and bill acceptors at step 1105 . After step 1105 or if true at step 1107 , determine if automatic inititation is true at step 1112 . If not, determine if initiate none is true at step 1113 . If not determine if initiate operator is strue at step 1114 . If not, error exit at step 1116 . Otherwise display waiting for initiate install at 1115 .
  • step 1117 determines if host authorization is required at step 1117 . If no, start installing package at step 1118 . Otherwise determine if host authorization is received at step 1119 . If not, wait for host authorization at 1120 . Otherwise start installing the package at step 1118 .
  • the package is ready to be installed. Once the installation process starts, it should not be cancelled or interrupted.
  • the package downloaded is made up of at least three distinct parts.
  • This data partition may be in a compressed or uncompressed format.
  • compressed formats that are supported are gzip and bzip2.
  • Other compression techniques can be accommodated with the actual package data itself and may be processed by the installation command file sent in the package data.
  • FIG. 12 is an overview of how the package is installed on the EGM.
  • the package install process is initiated.
  • data is copied from the package to a file.
  • At step 1206 create an individual file from the file portion of the package file. Determine if all files have been created at step 1207 . If not, return to 1205 .
  • step 1209 determine if a reboot is specified in InstallRule. If not, then remove setInstallRule and log and send status at step 1210 and return success at step 1211 . Otherwise determine if the prerequisite packages are installed at step 1212 . If not, log error and send status to SMP at step 1213 and return error at step 1214 . Othewise set NVRAM clear conditions and delete install rules at step 1215 , and reboot the EGM at step 1216 .
  • the current Download interface can be modified to present the Download Installer code with G2S like commands. That is, the SetInstallRule commands may be changed changed into setScript commands for processing by the Download Installed. Also, the getScriptList and GetScriptStatus commands will map the getInstallRuleStatus and getInstallRuleList commands.
  • CURL will be used to provide the support for downloading packages via HTTPS, SFTP, FTP, HTTP, etc.
  • HTTPS HyperText Transfer Protocol
  • SFTP Simple Stream Transfer Protocol
  • FTP HyperText Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • a locally developed protocol may be used.
  • a separate thread is used to issue reads to the download driver to receive setScript, deleteScript, authorizeScript commands.
  • a table of scripts is maintained. Each entry in the script table will point to the next entry in the script table. A global pointer will be used to point to the first script in the table.
  • the table will be arranged in a FIFO queue and the scripts are processed in the order in which the setScript commands install time frames are specified. If an authorizeScript command is received before it's setScript command, it is rejected and an error event sent back to the server sending the authorization command.
  • the script table may be maintained in both memory and on disk. The status of the script entry will be update on disk before the in memory copy.
  • script waiting for start install time frame and has a start install time frame that is after the script just received place the already active script back into the process queue and set the new script to waiting for start time frame
  • script record in process queue remove from process queue and send script deleted event.
  • script is processing and not in installing state, send event script canceled, delete script record and reset states. If script waiting in script queue, start processing next script.
  • Multiple hosts may be required to authorize a script to proceed with installation. Must maintain a list of authorizing hosts and set their authorization state when received. Installation can not proceed until all hosts authorize it.
  • Process authorizations There can be multiple authorizations required. This includes a local operator authorization as well as multiple host authorizations.
  • Scripts may or may not contain command lists. If not command lists are included, then the package is installed based on the contents of the package. Command lists will only exist for removing modules or executing specific commands on the EGM that is not related to installing or removing packages.
  • the package When processing the package, the package will either contain a tar file for updates to the system or an image of a partition or entire storage media. If there is an image file, a check is performed to insure that the image is the correct size for the media.
  • Installation dependencies and pre-requisites are used interchangeably. Each may have a set of module, hardware and storage dependencies that must exist before the module can be installed.
  • the dependency checking is performed as follows:
  • Module Dependency A module dependency is defined by it Module ID and Release Information.
  • Hardware Dependency The module dependency is defined by the Hardware ID and version number
  • Storage Dependency Defined by the storage type and the amount of free space required.
  • a test flag will define how to identify if a dependency is met.
  • the dependency check flag will have the following values:
  • release number or version number must be equal to the one of the installed hardware or module.
  • startTime/endTime This is a date and time stamp that defines the start of the time and end of a time window within which a setScript command can start processing. None of the packages within the package list starts processing before this date and time are reached. The endTime is the date and time stamp after which the setScript command cannot start. The start of processing depends upon the initiateType being satisfied and all the authorizations being met. If these are not met, then the processing of the setScript command is suspended until the time window is entered again. Once the first package has started processing, all other packages will be processed regardless of the time window.
  • disableType This specifies how the EGM should be disabled. The EGM cannot be disabled until the time processing time window is entered. As soon as the disable conditions are met, the EGM will be disabled and wait for the authorizations to occur. If the authorizations do not occur within the processing time window, the setScript command will be discontinued and the EGM re-enabled. The setScript command is then placed back into the waiting to process queue.
  • initiateType Specificifies what actions need to take place in order to start the installation. This includes host authorizations, local operator authorization, etc. These events can occur before the EGM is disabled in the case of host authorizations. All initiation requirements must be satisfied during the process time window.
  • authorizeList This is a list of host IDs who must authorize the setScript command to start processing. If the host specifies authorization not granted, then the processing of the setScript command will be terminated.
  • PackageList This is a list of packages to be processed. The packages will be processed in the order that they are specified within the setScript command. Module dependencies within one package may be satisfied by module in another package within the package list.
  • Each download package is made of various sections. Each section starts with a section ID, the size of the section, and the contents of the section. The contents of the section is dependent upon the type of package section defined.
  • Package Header This describes the overall package.
  • Module Entry A package may contain one or module entries.
  • File Entry Various types of file entries are defined. Each type has its own unique ID
  • a SHA 1 hash value is calculated over the entire package data. This hash value does not include the header in its calculation.
  • Each package section contains an integer header.
  • the first integer is the section ID, and the second is the size of the section itself.
  • the following sections describe the information that is contained within each package section.
  • the contents of the package header can be seen in the following table: Field Description mcnt integer Number of modules contained within the package ccnt integer Number of command defined in the package compression integer Compression applied to the package data psize integer Size of the package Data hsize integer Size of the header data type integer Type of Package Time_stamp Time_t Time stamp of when the package was built vString char Package Data Validation String (SHA1 or HMAC) pkgId char Unique identifier of the package release char Release information of package, (Version, build No, etc) description Char Description of package contents builderID char Identity of vender that created package
  • the package header is the first thing contained with a package and is a fixed length in size.
  • the package data compression types are: Compression Description 1 Uncompressed data 2 Compressed data using gzip protocol 3 Compressed data using bzip2 protocol
  • the module section is identified by the package section ID number 2 and the size is the size of the module information as described in the table below.
  • Field Type Description Type integer Type of Module Action Integer Action to take on Module (Add, update, delete) Mod Depend cnt. Integer No. of module dependencies for this module Hard Depend cnt. Integer No. of hardware dependencies for this module Strg Depend cnt Integer No. of defined storage dependencies Time Stamp integer Time stamp associated with when module built. Release Number sring Specific Release Major, Minor, Build and Version Nos.
  • Name string Null terminate string containing the name of the module. Description string An optional null terminated string used to describe the module.
  • Each module is assigned a unique module name.
  • the first three characters of the name are manufacturer unique and used to identify the manufacturer of the module.
  • the size of the name does not exceed 32 characters in length in one embodiment, but that is by way of example only.
  • the hardware, module, and storage dependency counts specify how many of each type of dependency is included in the package.
  • Module Type ID Description os EGM OS module. Linux and Game kernels, libraries and utilities gm EGM Game module. fw Firmware module dt Data module. Contains EGM unique data. jr Jurisdiction module df Definition Module - Used to define new modules within the EGM cf Configuration Module - Used to specify configur- ation information for the OS, EGM and Game.
  • Files entries within the package are associated with the preceding module identified in the package. That is, all files entries after a module definition is encountered until the next module or command definition are associated with the module they follow.
  • module 1 has file 1 and 2 associated with it and module 2 has files 3 and 4 associated with it.
  • Field Type Description Type Integer Type file that follows File size integer Size of the file File name string File name including fully qualified path. Destination string Fully qualified path where file is to be stored. Used for image files.
  • the manifest file section data area comprises the following 3 fields: Field type Description Type integer Type of manifest, OS (1), Game (2) Manifest Name string Manifest file name (32 Characters Max) File data binary
  • the type field is used to determine which manifest sub-directory to copy the manifest file into. Manifests will be copied into a directory called manifests and either into the OSI or games subdirectory.
  • Updates to installed modules as well as game installations will be in the form of a tar file.
  • the partition image section contains a complete image of a particular partition on the EGM. Following the Section header data are the identification of the partition to be replaced by the image, followed by the image itself. The EGM will assign a name to the image file for processing at the EGM. The partition identification is a null terminated string. The partition that contains the manifest validation files will always be partition one on any device. This partition can not be updated with the use of a partition image.
  • the device image file section contains the complete image of a device on the EGM such as an entire compact flash.
  • the manifest files are include within the image file itself and are therefore not included in a package manifest section.
  • a null terminated string that contains the device the image is meant for, such as /dev/had, followed by the image itself.
  • the EGM will assign a name to the image file locally.
  • the hardware dependency section identifies what hardware must exist on the system before the previously defined module can be installed. There can be any number of these associated with each module in the package.
  • the hardware dependency section is comprised of the hardware ID as known on the EGM, a version number and the comparison type to be performed (equal, greater than, or greater than or equal).
  • the module dependency specifies which modules must exist on the EGM before the previously defined module can be installed. There can be any number of these associated with each module in the package.
  • the module dependency consist of the module id, the version number for the module and the comparison identifier that specifies the type of comparison to be performed against the version number (equal to, greater then, or greater than or equal to).
  • the storage dependency defines how much storage must exist on the EGM.
  • the fields in the storage record specify the type of storage, RAM, ROM, disk, etc and how mush must be there or how much free space must exist depending on the type of storage specified.
  • Module Definition 2 Defines modules included in package Manifest File 3 Manifest File Associated with previous module definition.
  • Tar File 4 Tar file associated with previous Module definition Partition Image 5 Partition Image file associated with previous Module definition.
  • Device Image file 6 Device Image file associated with previous Module definition.
  • Hardware 7 Hardware prerequisite/dependency associated Pre-requisite with previous module definition.
  • Module 8 Module Prerequisite/dependency associated Pre-requisite with previous module definition.
  • Storage Dependency 9 Storage Prerequisite dependency associated with previous module definition.

Abstract

The system allows a casino operator to manage groups of electronic gaming machines (EGMs). Managing new or existing collections (i.e., groups) of gaming devices reduces the effort required to download or configure large numbers of EGMs. For example, new software may be downloaded to groups of EGMs from a central location, and the EGMs may be configured from the central location. Accordingly, this operational efficiency reduces maintenance costs and minimizes EGM downtime due to maintenance or EGM set-up.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This patent application claims priority to U.S. Provisional Patent Application No. 60/716,713 filed Sep. 12, 2005 and incorporated by reference herein in its entirety.
  • COPYRIGHT NOTICE
  • A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
  • BACKGROUND
  • Over the years, casinos have grown in size, grandeur, and amenities in order to attract gambling patrons. Additionally, casinos have attempted to provide gambling patrons with a wide variety of the new and exciting games. Given this demand, gaming machines have grown in sophistication and features in order to captivate and maintain player interest. As a result, casinos are able to provide a wide range and large number of games of chance.
  • For example, a casino floor may include thousands of electronic gaming machines (EGMs) that are in communication with and monitored by the casino's gaming network. EGMs provide an enhanced gaming experience with computer graphics, stereo sound, animation, and other features that have been developed to maintain player interest in the game. Furthermore, EGMs may include secondary networked devices such as player tracking devices or enhanced player interfaces (e.g., Bally Gaming's iView™ touch-screen display). Accordingly, there are a large number of EGMs and related components that need to be monitored, maintained, and serviced.
  • In early gaming environments, gaming machines were stand-alone devices. Security of the gaming machines was accomplished via physical locks, security protocols, security personnel, physical and video monitoring, and the need to be physically present at a machine to attempt to breach the security of the gaming machine. By the same token, management of the gaming machines required a great deal of personal physical interaction with each gaming machine. The ability to change parameters of the gaming machine also required physical interaction.
  • In view of the increased processing power and availability of computing devices, gaming machines have become customizable via electronic communications and remotely controllable. Manufacturers of gaming equipment have taken advantage of the increased functionality of gaming machines by adding additional features to gaming machines, thereby maintaining a player's attention to the gaming machines for longer periods of time increasing minimum bet and bet frequency and speed of play. This, in turn, leads to the player wagering at the gaming machine for longer periods of time, with more money at a faster pace, thereby increasing owner profits.
  • The amount of interactivity and data presentation/collection possible with current processor based gaming machines has led to a desire to connect gaming machines in a gaming network. In addition to the gaming machines themselves, a number of devices associated with a gaming machine or with a group of gaming machines may be part of the network. It has become important for the devices within a gaming machine or cabinet to be aware of each other and to be able to communicate to a control server. Not only is the presence or absence of a network device important, but also the physical location of the device and the ability to associate devices within a particular gaming machine has become a necessary component of a gaming network.
  • Currently, casino operators use manual methods to alter content or to reconfigure EGMs and/or other secondary networked devices. For example, a casino employee would need to physically swap out an EPROM to change game content or the employee would need to access an attendant menu on the EGM to alter game configurations. Given the large number of machines and networked devices, this process is a time-consuming and costly process not only in terms of operating and/or maintenance costs, but also in terms of lost profits due to extended downtime for the EGMs. Similarly, existing approaches for software updates or downloads for EGMs are labor-intensive and costly as the EGMs. For example, a technician typically needs to travel to the gaming machine in order to replace existing software package media (e.g., EPROMs, CD-ROM's, Compact Flash, etc.) with new software package media. Furthermore, the software package update process may require that the EGM be disabled hours in advance to prevent any players from using the EGM when the technician is ready to perform software package changes. Alternatively, EGMs may be disabled prior to software package updates, but the technician must periodically check to ensure that the EGM(s) are not being used by a player. Additionally, technicians may need to be supervised during the process of software package installation as the technician has access to critical areas of the EGM required for configuration or of those areas of containing cash.
  • The process of transferring packages to an EGM over a network may require a significant amount of network bandwidth during the transfer period. Typical transfer mechanisms provide point-to-point transfer where a Software Distribution Point (SDP) will transfer to a single EGM until the transfer is complete, and then the SDP may transfer to another EGM. When hundreds or thousands of EGM's require packages to be transferred there may be an unacceptable extended period of high bandwidth usage, since the transfers must occur sequentially.
  • Additionally, installing packages on an EGM can require verification that dependent software packages and hardware components are available within the EGM. This is typically a manual process that prone to human interpretation and human error.
  • Accordingly, there remains a need to provide a system for updating and configuring EGMS and other networked components.
  • SUMMARY
  • Briefly, and in general terms, various embodiments are directed to management of gaming devices over a network. The system allows a casino operator to manage groups of electronic gaming machines (EGMs). Managing new or existing collections (i.e., groups) of gaming devices reduces the effort required to download or configure large numbers of EGMs. For example, new software may be downloaded to groups of EGMs from a central location, and the EGMs may be configured from the central location. Accordingly, this operational efficiency reduces maintenance costs and minimizes EGM downtime due to maintenance or EGM set-up.
  • In one embodiment, EGMs can be updated over the network via a multicast over TCP/IP or some other suitable mechanism. A package containing game information and/or configuration information is created at a server. The package is delivered to an EGM over the network. The packages can be downloaded via a background thread and may take place while the EGM is enabled or disabled or even when a player is actively playing the EGM.
  • The system includes a scheme for EGM's to report corrupted or missing packets from the transfer, which the SDP will use to resend the packets. The SDP will use the multicast protocol to resend the packets, potentially reducing the network bandwidth used during error recovery.
  • The system includes a package validation method that uses digital signatures. A digital signature is provided with each package, which an EGM can use to validate the package and authenticate the origin of the package. The EGM will not install or use a package that does not pass validation.
  • The system includes technology necessary for the System Management Point (SMP) to manage package dependencies (dependencies such as a new package-A that requires package-B and package-C to operate). This technology can be used to confirm that new package-A dependencies are addressed before requesting the EGM to transfer a new package. Additionally, the SMP can determine the dependencies and request that those packages also be transferred to the EGM.
  • The system includes technology necessary for the SMP to determine if a package's dependent hardware components are available on the EGM. The concept is similar to the package dependencies; however the SMP can not automatically transfer hardware components to an EGM to satisfy package dependencies. If a package's required hardware dependencies are available on the EGM, then the package transfer to the EGM will be permitted; otherwise, the package transfer will not be permitted.
  • According to one method, the system may designate that a collection of gaming machines should have a particular status at a given time. Changes or status may be applied to different collections of gaming machines. The network system allows a casino operator to define changes to software inventory (i.e., via download) and to schedule configuration changes. For example, a casino operator can define default payouts and denominations, schedule recurring overrides for weekends, and schedule a one-time override for a holiday or casino promotion. Accordingly, these changes can occur without further operator interaction. As a result, casino management does not need to be in attendance every time the slot floor assumes a new configuration.
  • Moreover, the configuration changes are communicated during the background operation of the EGM without affecting gameplay, and the changes are applied at a designated convenient time (e.g., a predetermined period of time after the credit meter reaches zero credits). Accordingly, the EGM does not need to be placed in an inactive state prior to downloading configuration changes.
  • Furthermore, various methods of assignment conflict analysis and resolution are disclosed herein. Typically, conflicts will only occur for assignments of the same type (e.g., download and configuration). Generally, download/configuration conflicts are avoided by running the download process before the configuration process with the exception that data related to host and owner information will supersede other assignments. Alternatively, conflicts may arise as a result of an EGM being a member of different collections where membership may vary depending on the moment in time. For example, switching an EGM from a 5 cent denomination to a 25 cent denomination may switch the membership of the EGM to another collection (e.g., all 25 cent EGMs). Accordingly, the network system includes various methods to resolve situations where EGMs are given improper settings (e.g., the system will filter out settings that the EGM does not support). As a result, these methods provide consistent procedures as to how the network host configures EGMs when more than one assignment applies.
  • In another method, methods of pre-configuring EGMs are disclosed herein. In one method, the network system uses option templates to support pre-configuration because a particular EGM or game theme within an EGM may support a large number and wide variety of options. For example, option definition templates such as Combo Option templates or Option Group templates may be used to define the configuration of new content before it is downloaded to an EGM. Additionally, a casino operator may schedule the download of a new game theme during off-hours and have the network host configure the new game theme as soon as installation is completes without requiring operator intervention.
  • Methods of automatic downloading and configuration of EGMs are also disclosed. In one method, the network system provides a method of recognizing when an EGM needs data downloads or configuration, and the network coordinates these activities to avoid conflicts. For example, in one method, attempts to configure an EGM will be prevented until downloads for the EGM are completed. In another method, the network host automatically restores data modules and configures an EGM if it has been RAM-cleared or has been offline. Accordingly, an operator can monitor and manage a group of EGMs from a single terminal, thereby eliminating the need for slot technicians to collect configuration data and to manually reconfigure each EGM.
  • In yet another method, methods of simultaneous download to multiple EGMs are disclosed herein. The network system distributes (i.e., downloads) data packages through the use multicast sessions, where the EGMs request all or part of a data package (as directed by the download server). This method may also include a lossless transport mechanism and an IP multicast as the distribution mechanism. The multicast distribution mechanism conserves network bandwidth, can be throttled at the host, and prevents low priority activities (e.g., download) from interfering with critical communications (e.g., vouchers or events).
  • Another method is directed to minimizing memory storage consumption associated with package downloads to EGMs. In this method, the host downloads a package (e.g., BLOB (Binary List of Bytes)) to the EGM. The package is then authenticated and may then be installed immediately or at a later scheduled time. Once the contents of the package are installed on the EGM, the package may optionally be removed from the EGM. For example, portions of package may be removed by overwriting the package with new packages. The package's contents are tracked by the resulting versioned modules that have been installed on the EGM.
  • Other features and advantages will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate by way of example, the features of the various embodiments.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates an embodiment of a gaming network that may be used with the system.
  • FIG. 2 illustrates an overview of download interaction
  • FIG. 3 illustrates an overview of EGM Startup message flow.
  • FIG. 4 depicts the logic flow of /dev/download driver initialization.
  • FIG. 5 is a flow diagram illustrating a routine to validate download requests and pass control to the proper handler function.
  • FIG. 6 is a flow diagram illustrating the add package logic of the download driver.
  • FIG. 7 is a flow diagram illustrating the download control process addPackage logic.
  • FIG. 8 illustrates the message flow for the download receiver addPackage process.
  • FIG. 9 illustrates the logic flow for the DR.
  • FIG. 10 is a flow diagram illustrating the pre-requisite process.
  • FIG. 11 illustrates the logic flow for this process.
  • FIG. 12 is an overview of how the package is installed on the EGM.
  • DESCRIPTION OF EMBODIMENTS
  • Various network systems and methods for managing networked gaming machines are disclosed herein. The system supports data downloads and configuration of gaming machines such as, but not limited to, electronic gaming machines (EGMs). With the network system, a casino operator may define a collection of EGMs, assign modules to one or more collections of EGMs, assign configuration changes to one or more collections of EGMs, and schedule all assignments.
  • The system permits some or all of the software that is to be run on an EGM to be centrally stored in a software distribution library located on one or more servers. The software can be sent over a network (such as an Ethernet network) as desired for initial set up of an EGM, as updating of an EGM, game replacement, configuration, or any other desired purpose.
  • The system utilizes multicasting to download software packages to the EGMs in the background, even while full game play is ongoing. The server does a single multicast transfer of one or more packages to all target machines. Each EGM tracks the packages and notes missing, corrupted, or dropped packets. In one embodiment, the server receives requests from all EGMs for packets to resend and again multicasts them to all EGMs, regardless of which EGM requested which packet. The individual EGMs accept needed missing packets and ignore other re-broadcast packets. It should be noted that the system is not limited to multicast transmissions but may use HTTP, HTTPS, FTP, SFTP, and other transmission protocols.
  • It should be noted that the term EGM is intended to encompass any type of gaming machine, including hand-held devices used as gaming machines such as cellular based devices (e.g. phones), PDAs, or the like. The EGM can be represented by any network node that can implement a game and is not limited to cabinet based machines. The system has equal applicability to gaming machines implemented as part of video gaming consoles or handheld or other portable devices. In one embodiment, a geo-location device in the handheld or portable gaming device may be used to locate a specific player for regulatory and other purposes. Geo-location techniques that can be used include by way of example, and not by way of limitation, IP address lookup, GPS, cell phone tower location, cell ID, known Wireless Access Point location, Wi-Fi connection used, phone number, physical wire or port on client device, or by middle tier or backend server accessed. In one embodiment, GPS and biometric devices are built within a player's client device, which in one embodiment, comprises a player's own personal computing device, or provided by the casino as an add-on device using USB, Bluetooth, IRDA, serial or other interface to the hardware to enable jurisdictionally compliant gaming, ensuring the location of play and the identity of the player. In another embodiment, the casino provides an entire personal computing device with these devices built in, such as a tablet type computing device, PDA, cell phone or other type of computing device capable of playing system games.
  • An embodiment of a network that may be used with the system is illustrated in FIG. 1. The software distribution network consists of a top level vender distribution point 101 that contains all packages for all jurisdictions, one or more Jurisdiction distribution points 102A and 102B that contain regulator approved production signed packages used within that jurisdiction or sub-jurisdiction, one or more Software Management Points 103A and 103B to schedule and control the downloading of packages to the EGM and a one or more Software Distribution Points 104A and 104B that contain regulator approved production signed packages only used in the gaming establishment that it supports. The Software Distribution Points (SDPs) 104A and 104B can communicate with Systems Management Points (SMPs) 105A and 105B, respectively as well as directly to one or more EGMs 106A and 106B. (The communication between SDP and SMP is optional. A benefit is to permit the SMP and the user access to the catalogue of software packages available on the SDP). The system allows for rapid and secure distribution of new games and OS's from a centralized point. It makes it possible to update and modify existing gaming machines with fixes and updates to programs as well as providing modifications to such files as screen images, video, sound, pay tables and other EGM control and support files. It provides complete control of gaming machines from a centralized control and distribution point and can minimize the need and delay of human intervention at the EGM.
  • In one embodiment, a 1 GB compact flash card will initially be used as the storage media in the EGMs for OS and download package storage. A second compact flash will be used for the storage of the production game as it exists today. The OS compact flash will be partitioned into production, backup, and download areas. The production area contains the active OS and game management software used to allow the playing of games on the EGM. This part of storage will have all the file integrity checking and validation performed on it. The other areas will be used to store backup software and data, new download packages, installation of the new packages and saving of NVRAM, counters, random number data and other secure information in an encrypted data format. Software downloads will be scheduled by gaming personnel via the SMPs. The SMP notifies the individual gaming machines they have been scheduled to receive a download package from a specific vendor Software Distribution Point (SDP). The EGM shall then request the SDP to start sending the download package to it.
  • The system solves the network bandwidth usage problem by using a multicast network protocol, which the SDP uses to broadcast the transfer to multiple EGM's simultaneously. The SDP will send a single transfer to a defined set of EGM's, thereby using a fraction of the network bandwidth when compared to the point-to-point strategy. If there are X groups of EGM's, with each group consisting of Y EGM's, then the following calculations provide a general sense of reduced network bandwidth usage:
    Multicast: X * transferSize
    Point-to-point: (X * Y) * transferSize
    Gross Improvement: 1/Y network usage with multicast.
  • The system includes a recovery scheme to accommodate transmission error or reception error of the package. This recovery scheme allows each EGM to report missing pieces (packets) where either not received or received with errors (data corruption). The SDP logic can accumulate a list of missing packets and the corresponding EGM's, and use the multicast protocol to resend the missing packets.
  • The specific packages that are transferred are specified by the EGM. The EGM makes requests to the SDP using a point-to-point protocol. The SDP may not service these requests immediately, so the EGM is permitted to operate while waiting for the transfer and during the transfer. The EGM is responsible for logging transfers and checking the validity of the completed transfer. This log can be used to reconcile the package content of the EGM at any given time. Additionally, the SDP will log transfer activity and provide a means to cross check the package content of an EGM.
  • An EGM validates transferred packages using a digital signature. This digital signature provides authentication of the package itself regardless of the specific SDP server that provided it, and is used to determine if the package incurred any transmissions errors. If an EGM is unable to validate a package, then the package will not be installed or otherwise used.
  • The system includes technology necessary to determine if an EGM contains packages necessary to use a new package (package dependencies). If a given package-A requires additional packages, package-B and package-C, to operate on the EGM, the dependencies can be determined from a package header contained within package-A. The SMP can then determine if the EGM already contains the dependent packages, package-B and package-C, before requesting that package-A be transferred to the EGM. Similarly, the SMP can automatically select the dependent packages to be transferred in addition to the original package-A, thus fulfilling the dependencies of package-A. This aspect of the system provides a level of assurance that the packages transferred can actually be used by the EGM.
  • The system includes technology necessary to determine if a package's dependent hardware components (components) are available on the EGM. If package-X requires component-Y and component-Z, the SMP can read the components of the EGM and use this information for component dependency checking. If a package's required component dependencies are available on the EGM, then the package transfer to the EGM will be permitted; otherwise, the package transfer will not be permitted. This aspect of the system provides a level of assurance that the packages transferred can actually be used by the EGM.
  • The ability to transfer software directly to the EGM provides additional alternatives when installing a new EGM on the casino floor. An EGM that is manufactured and placed directly on the casino floor can be initially loaded with a boot-strap media (EPROM, CD-ROM, Compact Flash, etc.) that can boot the EGM and prepare communications before requesting new packages to install. Two boot-strap methods may be used to transfer software to an EGM. Both methods require minimal configuration of an EGM before the boot-strap process can be completed. Minimal configuration consists of the following:
  • 1) A unique network IP Address for the EGM. This can be provided by a DHCP system, or assigned to the EGM via operator configuration.
  • 2) A unique EGM identifier that is derived from the EGM hardware (such as network card MAC address) or assigned to the EGM via operator configuration.
  • 3) An address of the SDP network server to make transfer requests of. This can be a hard-coded default address that may be overridden via operator configuration.
  • The simple boot-strap mode requires that EGM is also configured with the necessary options to locate the SMP network server. This can be a hard-coded default address that may be overridden via operator configuration. This address is used by the EGM to locate the SMP server, which can then assign new packages to the EGM for transfer. In one embodiment, the EGM and its associated peripherals can be identified using a scheme such as is described in U.S. patent application Ser. No. 11/319,034 entitled “Device Identification” and incorporated in its entirety herein by reference. In this embodiment, during start-up, a device sends its MAC address out on the network. A local switch collects MAC and IP addresses for the devices connected to it. Periodically, the switch transmits raw Ethernet frames, USB packets, or TCP packets containing tables of devices and associated MAC/IP addresses. When a device receives information about another device, the device may attempt communication with that device. First, a verification procedure is used to validate the devices. Subsequently, communication is possible between the devices.
  • The advanced boot-strap mode involves the EGM requesting a default boot-strap package from the SDP. The package name for this boot-strap package is predefined and known to both the EGM and the SDP. This boot-strap package contains configuration files that identify the default software packages and configuration data. The boot-strap package can be customized for the specific installation (casino) and stored on the SDP. This way all EGM's will request the predefined boot-strap package, the SDP will transfer the boot-strap package to the EGM, and the EGM will process the boot-strap package. When the EGM processes the boot-strap package, the EGM can read the SMP address, default EGM OS package, and other packages such as default peripheral firmware packages. At this point the EGM can request these packages from the SDP, and the SDP will begin transferring the default packages to the EGM, ultimately ending with an EGM ready for configuration.
  • FIG. 2 illustrates an overview of download interaction between the System Management Point 105, EGM 106, and Software Distribution Point 104. The design consists of a download device driver which provides the central control logic and logic. It interfaces with the Download Class (which may be G2S or any other protocol) and a download control thread. The download control thread controls requesting and downloading packages from the download distribution point server.
  • In operation, the System Management Point 105 sends package commands and requests to the Download Control 206 of EGM 106 to tell it to add and delete packages, install packages and request information about packages and installed modules. The Download Control 206 will filter these requests and pass then to the Download Driver 207 for processing. Requests to add packages are then given to the Download Receiver Process 208 which then opens communications with the Software Distribution Point 104. The Download Receiver Process 208 receives the package data from the Software Distribution Point 104 via a multicast (or any other defined transmission protocol) link 204 in multiple packets and assembles the package in compact flash. Once all packets of the package have been received, the package data is verified using a SHA-1 verification string passed in the package header. The appropriate status and package state information shall be passed back to the Download Driver 207 which passes it to the Download Control 206 for logging and passing back to the System Management Point.
  • Download Driver 207
  • The download driver is installed when the EGM system is started. It's primary functions are to:
  • 1—Initialize package and control information as stored on the compact flash.
  • 2—Process commands to add packages and install rules from the Download Control 206.
  • 3—Supply the Download Control 206 with list and status information and download and install events.
  • 4—Queue add package requests for the Download Receiver process 208 and pass them to the Download Receiver 208 via a read 211 to the driver.
  • 5—Update package the status and error conditions of packages and install rules and pass them back to the Download Control Process 206.
  • Download Control Thread 206
  • The Download Control Process 206 is either a thread running within the game manager context or a standalone process when there is no game manager running on the system. It's primary tasks are:
  • 1—Receives download commands
  • 2—Passes the commands that it will not process on to the download driver 207 for delivery to the Download Receiver process 208 and the Download Installer process 209.
  • 3—Receive download and install status from the driver and log in the appropriate log files on the EGM 106.
  • 4—Supply the log information and package, install rule and module lists to the System Management Point 105 when requested.
  • Download Receiver Process 208
  • The Download Receiver Process 208 is responsible for communications between the EGM 106 and the Software Distribution Point 104. It's primary functions are:
  • 1—Receive add package requests from the Download Driver 207.
  • 2—Open a TCPIP link to the Software Distribution Point 104 and request the package defined within the add package request be sent to the EGM 106.
  • 3—Open a multicast communications port specified by the Software Distribution Point 104 and receive the requested package in multiple packet format.
  • 4—Assemble the packets of the package into a single file.
  • 5—Request any missed or missing packets be resent.
  • 6—Verify the package data by calculating a SHA-1 value and matching that against the SHA-1 validation string passed in the package header.
  • 7—Send back status and error information of the package receive process to the Download Control Process 206 via the Download Driver 207.
  • Download Package Installer Process 209
  • The Download Package Installer Process 209 is responsible for installing the packages that are downloaded from the Software Distribution Point 104. It is notified of when to start installing a downloaded package when a set install rule command is sent from the Systems Management Point 105. It receives this command via a read to the Download Driver 207. The basic functions of the Download Package Installer Process 109 are:
  • 1—Parse the set install rules to determine how to process the package.
  • 2—Disable the EGM 106 based on the instructions in the set install rule command.
  • 3—Install the package using the command file sent as part of the download package.
  • 4—Clear NVRAM as instructed by the install rules.
  • 5—Reboot the EGM 106 as instructed by the set install rules.
  • 6—Pass back status and error information via the Download Driver 207.
  • EGM Initialization
  • FIG. 3 illustrates an overview of EGM startup message flow. EGM 106 sends a message 302 to SDP 104 requesting a package. SDP 104 replies with a message 303 indicating package size and the multicast IP/Socket that will be used for transmission. Message 304 from SDP 104 to EGM 106 is the package data itself. If necessary, EGM 106 can request missed packets by sending a message 305.
  • As noted above, the system uses multicasting to send packages to multiple EGMs. When packets are missed and requested by an EGM, SDP 104 collects a number of requests and sends out multicasts of all missed packets to all of the EGMs. If a particular EGM does not need one of these re-broadcast packets, it is ignored. Otherwise, the EGM accepts the re-broadcast packet and uses it to complete the package transmission.
  • Download Driver
  • In the interface between the download driver 207 and the download processes, all set status, set error information and command information is passed to the driver 207 via an IOCTL call. The processes use the read interface to get processing instructions from the driver 207. The Download Receiver 208 uses the read interface to get add package requests, the Download Installer Process 209 uses the read to obtain set install rule requests, and the Download Control Process 206 uses the read interface to receive the status and error information from the Receiver and Install processes.
  • /dev/download is a loadable module, “device driver”, that is loaded as the system comes up. (It is a Linux loadable module in one embodiment). DI_Init_module( ) is the first routine to gain control when the module is loaded. It will:
  • 1—Allocate the download buffer used to store Download Class messages. (e.g. the G2S or other protocol)
  • 2—Register the download support as a Linux kernel device.
  • 3—Initialize the read queues fro the processes that communicate with the driver.
  • 4—Initialize the storage area for package and set install rules that may be received.
  • Once the driver has been installed and initialized, all further actions will controlled by the ioctl and read function entry points into the driver. The ioctl entry point, DL_ioctl( ), will process all the System Management Point 105 requests passed through the Download Control Process received from the download class. The DL_read( ) entry point services all the read requests from:
  • The Download Control Process 206 for packages status and error,
  • The Download Receiver process 208 to pass add package requests.
  • The Download Installer 209 to receive set install rule request.
  • FIG. 4 depicts the logic flow of /dev/download driver initialization. At step 401 the Read Queue areas and semaphores are initialized. At step 402 the package is initialized and the Install Rule Data Structures are set. At step 403 the driver is registered with the system and at step 404 the system returns.
  • Once the /dev/download driver is installed and initialized, the dl_ioctl( ) driver 207 serves as the interface to the Download Control Process 206, and the Receiver 208 and Install 209 processes. All requests from System Management Point 105 are passed through Download Control Process 206 and either passed onto the driver 207 to be processed, or in the case of module and log requests, processed within the Download Control Process 206 itself. The dl_ioctl( ) is a command ID to determine what to do with the specific request. FIG. 5 is a flow diagram illustrating a routine to validate download requests and pass control to the proper handler function.
  • At step 501 the particular switch that is set on the Command ID is examined so that the request from the SMP 105 can be routed to the correct handler. Add and delete Package commands are provide to DL_Packages 502. Set and Delete Install rules are passed to DL_Install 503. Set Status, Retrieve Status, Retrieve List commands are sent to DL_Status 504. Register processes are sent to block 505 where the Pid of the Process being registered is saved. Unknown commands return an error event at 506.
  • addPackage Processing Logic
  • The addPackage command from the Download class is processed by the Download Control Process 206, the download driver 207 and the download receiver process 208. Breaking up the processing into these three areas helps to maintain isolation between specific function for easily adapting the code to support operation both with any protocols as well as providing the capability to integrate different package download protocols and requirements that may arise in the future. FIG. 6 illustrates the download driver 207 addPackage logic. The addPackage logic checks to see if the package already exists on the EGM and if there is enough room to store the package information. If so, it will send the package information to the Download receiver's driver read queue and the Download control driver's read queue and post the read semaphores if a read is outstanding.
  • At step 601 there is an addPackage request. At step 602 it is determined if the requested package exists. If no, the system returns a package exists error at step 603. Otherwise the system proceeds to step 604 to determine if the maximum number of packages is already queued. If yes, a return queue full error is returned at step 605. Otherwise the system proceeds to step 606 and adds addPackage information into the package table.
  • At step 607 addPackage is placed in the receiver read queue. At step 608 it is determined if there is a receiver read outstanding. If not, the system returns normal status at step 609. Otherwise, the system posts a receiver read sleep semaphore at step 610. At step 611 the addPackage status is placed in the control read queue. At step 612 it is determined if there is a control read outstanding. If no, the system returns normal status at steps 609. If yes, the system posts a control read sleep semaphore at step 613 and returns normal status at step 609.
  • Download Control Process addPackage Logic
  • The download control process 206 has a thread that performs reads from the download driver 207. When the read is satisfied for an addPackage or package status, the operation of FIG. 7 is followed. The package information is written to the /Packages/Packages directory using the package ID as the file name. A log entry is also created and written to the package log in the /Packages/Logs directory. Finally a package status message is created and sent back for delivery to the System Management Point.
  • At step 701 the addPackage is read from the driver. At step 702 the addPackage information is written to disk. At step 703 it is determined if the write operation was successful. If not, an error event is created and sent at step 704. Otherwise, a package log entry is created and written at step 705. At step 706 it is determined if the log write was successful. If not, an error event is sent at step 707. If the log write is successful, or after step 707, a package status message is created and sent at step 708. At step 709 a read is issued to the download driver.
  • Download Receiver addPackage
  • The Download receiver is responsible for downloading the package identified in the addPackage message from the Software Distribution Point 104. FIG. 8 illustrates the message flow for accomplishing this task. The message flow is between the SMP 105 and EGM 106, and between EGM 106 and SDP 104.
  • Within the EGM 106, the Download Receiver (DR) process 208 is the one that communicates with the Software Distribution Server. The addPackage command 801 contains the IP and socket address of the Distribution Server to be contacted. The DR 208 opens the link to the SDP 104 and requests 806 the package identified within the addPackage command be sent to it. The SDP 104 responds 807 with a message containing packet size, timeout values, the size of the package, and the multicast port to receive the data on. The DR 208 sends download initiate status 802 and download progress messages 803 to SMP 105.
  • As data packets are downloaded 808, the DR 208 keeps track of the packets sent and will request a resend 809 for any packets not received. Those packets are resent 810 as part of a multicast. After all packets have been received 804, a SHA-1 value will be calculated for the data portion of the package and compared 805 against the validation string sent as part of the package.
  • FIG. 9 illustrates the logic flow for the DR 208. At step 901 the DR read is initiated. At step 902 a link is opened to the SDP 104. At step 903 it is determined if a link is established. If not, a package error is sent to the driver at step 904 and a read is issued to the driver at step 905. Otherwise a request package is sent to the SDP at step 906.
  • The response from the SDP is read at step 907. At step 908 a multicast socket is opened. Ata step 909 the status is sent to the DR via ioctl. At step 910 the DR reads from the multicast socket. At step 911 it is determined if there is a read timeout condition. If not, at step 912 the packet data is saved at a specified offset and save sequence. Otherwise it is determined at step 913 if there are any missed packets. If yes, then at step 914 a resend packet request is sent to the SDP and the system returns to step 909.
  • Otherwise at step 915 the downloaded package is validated (e.g. using SHA-1). At step 916 it is determined if the data is validated. If not, a package error status message is sent to the download driver at step 917. Otherwise a package validated status is sent to the download driver at step 918 and the system returns to step 905.
  • deletePackage
  • The deletePackage command is processed by the Download Control 206 and Receiver 208 processes and by the Download Driver 207. When the download driver 207 receives a deletePackage request, if the status of the package is not validated or there is an error, the status is reset to delete pending and the delete package command is sent to the download receiver 208. The download receiver process 208 should then delete any files it has created and terminate any download activity for the file. When the cleanup is complete, it will send a deleted status back to the download driver 207 and resume its read from the download driver 207.
  • When the download driver 207 receives a package deleted status, or if the original status of the package was validated or error, the download driver 207 frees the package data save area and sends a deletePackage complete status to the Download controller process 206. The download controller process 206 logs the new status in the package log and deletes the package status file from the /Packages/Packages directory. It then sends the delete complete status back to the SMP 105.
  • setInstallRule
  • The setInstallRule Download Class command is processed by the Download Control process 206, the Download Installer Process 209 and the Download Driver 207. The Download Control process 206 maintains the updated status of the setInstallRule on disk and in the install rules log file, as well as sending the status back to the SMP 105 via messages. The download driver 207 acts as the interface between the Download Control Process 206 and the Download install process 209. It will also validate the package does not already exist and that there is enough room to process the install rules.
  • Download Installer Process—setInstallRule
  • Parsing of the setInstallRule command and the pre-requisite conditions contained in the package header is the first step in installing a download package. The package header is examined to extract the information as to what hardware requirements the package to be installed needs as well as any software that needs to be on the EGM in order to support the package. With respect to software prerequisites, these can refer to already installed software, or software contained in other packages that have been downloaded and are ready to install. FIG. 10 is a flow diagram illustrating the pre-requisite process.
  • At step 1001 the validation process begins. At step 1002 it is determined if the requisite hardware is present for the download package. If so, a table of installed hardware data is build at step 1003. At step 1004 the loop of hardware prerequisites is read from the package header. At step 1005 it is determined if the prerequisites are in fact in installed in the hardware table. If so it is determined at step 1006 if all the prerequisites are met. If so, return success at step 1008. If not, return to step 1004.
  • If the prerequisites are not installed in the table at step 1005, an install error is logged at step 1009. At step 1010 the install status is sent to the SMP 105 and an error is returned at step 1011.
  • If the hardware prerequisites are not present at step 1002, it is determined at step 1007 if the software prerequisites are present. If no prerequisites are specified, return success at step 1008 If yes at step 1007, build a table of required software at step 1012. At step 1013 build a table of available modules from the installed module inventory. At step 1014 build a table of modules from available packages. At step 1015 loop through the prerequisite table.
  • At step 1016 determine if the prerequisites are found in the installed modules. If the prerequisite isn't satisfied by the installed modules, step 1019 determines if the prerequisite may be satisfied by packages that have not yet been installed If the prerequisite can't be satisfied, log install error at step 1009. Otherwise remove the prerequisite from the table at step 1017. At step 1018 determine if all prerequisites are satisfied. If yes return success at step 1008. If not, return to step 1014.
  • If 1016 is no, determine if the prerequisite is in the package table at step 1019. If not, log install error at step 1009. If so, determine at step 1020 if the package prerequisites are in the prerequisite table. If yes, return to step 1015. If not, add package modules to the prerequisite table at step 1021 and return to step 1015.
  • Once all the prerequisites have been met for the all the required packages, the package install rules will be processed. The install rules contain information on when to disable the machine to prevent game playing and if a time delay is required after disabling the game, what trigger to use to start the installation process, and whether the host needs to authorize the install once all other conditions have been met. FIG. 11 illustrates the logic flow for this process.
  • At step 1101 the DL_Installer( ) routine is initiated. At step 1102 it is determined if the time window for the install is met. If not, the system waits for the install period at step 1103. Otherwise at step 1104 it is determined if the disable conditions are met. If so, disable the coin and bill collectors at step 1105. Oherwise determine if disable should be immediate at step 1106. if not determine if there should be disable none at step 1107. If no, determine if disable zero credit is true at step 1108. If note return error and exit at step 1109.
  • If true at step 1108 determine if the disable wait time has expired at step 1110. If not wait for the disable time at step 1111. For true at 1106, 1108, 1110, or after step 1111, disable the coin and bill acceptors at step 1105. After step 1105 or if true at step 1107, determine if automatic inititation is true at step 1112. If not, determine if initiate none is true at step 1113. If not determine if initiate operator is strue at step 1114. If not, error exit at step 1116. Otherwise display waiting for initiate install at 1115.
  • For true at 1112 and 1113, or after 1115, determine if host authorization is required at step 1117. If no, start installing package at step 1118. Otherwise determine if host authorization is received at step 1119. If not, wait for host authorization at 1120. Otherwise start installing the package at step 1118.
  • Package Installation—Installing the Package Contents
  • Once all of the install requirements and prerequisites have been satisfied, the package is ready to be installed. Once the installation process starts, it should not be cancelled or interrupted.
  • The package downloaded is made up of at least three distinct parts.
  • 1—A header which contains the following information:
  • i. The module names, descriptions and release version number.
  • ii. The files and their offsets into the data package.
  • iii. The name of the command procedure used to install the package and its offset into the data package.
  • 2—A SHA-1 validation string used to validate the data portion of the package.
  • 3—A data portion of the package containing the installation procedure file and all the files to be installed for this package. This data partition may be in a compressed or uncompressed format. Currently compressed formats that are supported are gzip and bzip2. Other compression techniques can be accommodated with the actual package data itself and may be processed by the installation command file sent in the package data.
  • FIG. 12 is an overview of how the package is installed on the EGM. At step 1201 the package install process is initiated. At step 1202 data is copied from the package to a file. At step 1203 it is determined if the package data is compressed. If yes, the system uncompresses the file at step 1204. Otherwise at step 1205 loop through the file definition in the package header. At step 1206 create an individual file from the file portion of the package file. Determine if all files have been created at step 1207. If not, return to 1205.
  • Otherwise execute the install file command at step 1208. At step 1209 determine if a reboot is specified in InstallRule. If not, then remove setInstallRule and log and send status at step 1210 and return success at step 1211. Otherwise determine if the prerequisite packages are installed at step 1212. If not, log error and send status to SMP at step 1213 and return error at step 1214. Othewise set NVRAM clear conditions and delete install rules at step 1215, and reboot the EGM at step 1216.
  • Alternate Package Install Handling
  • With the introduction of new file validation methodologies and the transition to G2S, the system contemplates an alternate embodiment for download package install handling. The current Download interface can be modified to present the Download Installer code with G2S like commands. That is, the SetInstallRule commands may be changed changed into setScript commands for processing by the Download Installed. Also, the getScriptList and GetScriptStatus commands will map the getInstallRuleStatus and getInstallRuleList commands.
  • It is assumed that all the commands dealing with download logs will be handled in the G2S support code and will not be a part of the Download support.
  • CURL will be used to provide the support for downloading packages via HTTPS, SFTP, FTP, HTTP, etc. For any multicast protocol, a locally developed protocol may be used.
  • This alternate embodiment is based on the following commands:
  • 1. A separate thread is used to issue reads to the download driver to receive setScript, deleteScript, authorizeScript commands.
  • 2. A table of scripts is maintained. Each entry in the script table will point to the next entry in the script table. A global pointer will be used to point to the first script in the table. The table will be arranged in a FIFO queue and the scripts are processed in the order in which the setScript commands install time frames are specified. If an authorizeScript command is received before it's setScript command, it is rejected and an error event sent back to the server sending the authorization command.
  • The script table may be maintained in both memory and on disk. The status of the script entry will be update on disk before the in memory copy.
  • 3. When any of the script commands are received the following will happen:
  • setScript
  • If no setScript record exists for this script, create and initialize script record with a state of waiting to process.
  • If other script records exist, place this into the process queue according to its installation start time frame value.
  • If no other scripts in the process queue, place it at the beginning of the process queue.
  • If script waiting for start install time frame and has a start install time frame that is after the script just received, place the already active script back into the process queue and set the new script to waiting for start time frame
  • If machine is in disable state and currently processing another script, just place the script into the script queue on disk.
  • deleteScript
  • If no script record for the specified script, return error, no script present
  • If script record in process queue, remove from process queue and send script deleted event.
  • If script is processing, and process state is installing, send event script installing, not deleted.
  • If script is processing and not in installing state, send event script canceled, delete script record and reset states. If script waiting in script queue, start processing next script.
  • authorizeScript
  • Multiple hosts may be required to authorize a script to proceed with installation. Must maintain a list of authorizing hosts and set their authorization state when received. Installation can not proceed until all hosts authorize it.
  • If no script record exists for specified script, reject authorize command and send back an error event.
  • If processing script, set script state to what is specified in the command for the particular host specified in the authorize command.
  • If not processing script, set authorization state to what is specified in command for the specified host.
  • Processing setScript Command
  • When a setScript command enters the processing state, the order in which things occur are:
  • 1) Check dependencies: hardware and modules. Module dependencies can be satisfied by either already installed modules or modules that exist within the packages being installed by the setScript. Insure to take into consideration that another package in the setScript could be removing a module that may be required.
  • 2) Check storage dependencies taking into account that a package within the setScript command could be removing a module and therefore freeing up storage.
  • 3) Wait for install time frame.
  • 4) Disable EGM according to disableType attribute.
  • 5) Initiate processing of packages according to the initiateType command.
  • 6) Process authorizations. There can be multiple authorizations required. This includes a local operator authorization as well as multiple host authorizations.
  • 7) Scripts may or may not contain command lists. If not command lists are included, then the package is installed based on the contents of the package. Command lists will only exist for removing modules or executing specific commands on the EGM that is not related to installing or removing packages.
  • 8) Whenever a package is removed, its related file validation manifest must also be removed from the system
  • 9) Whenever a module is installed or removed from the EGM that cause a manifest to be modified, deleted or added, the system must be rebooted after the installation completes.
  • 10) Based on jurisdiction requirements and state specified in the setScript command, delete the downloaded package.
  • Installing and Updating Module Requirements
  • Whenever a module is installed or updated on a system that has sufficient storage to maintain a backup copy of the operating environment, the following steps are performed.
  • 1) Reset the partition access permissions to allow writing to the partitions.
  • 2) Copy the production environment into the backup environment. This may be done via a background task when an environment is activated and while the game is running.
  • 3) Apply the changes to the production environment.
  • 4) Insure that the boot.id file is set to boot the production environment and that a backup environment exists.
  • 5) Reboot the system according to jurisdictional requirements.
  • When processing the package, the package will either contain a tar file for updates to the system or an image of a partition or entire storage media. If there is an image file, a check is performed to insure that the image is the correct size for the media.
  • When installing new games, this is performed via a tar file. A check is made to insure that there is enough space to hold the new or updated game's files and manifest file. No backup will be made of an existing game on the system. If the game fails to run, we expect that it will have to be downloaded again from the server.
  • Installation Dependencies
  • Installation dependencies and pre-requisites are used interchangeably. Each may have a set of module, hardware and storage dependencies that must exist before the module can be installed. The dependency checking is performed as follows:
  • Module Dependency—A module dependency is defined by it Module ID and Release Information.
  • Hardware Dependency—The module dependency is defined by the Hardware ID and version number
  • Storage Dependency—Defined by the storage type and the amount of free space required.
  • For Release Information and hardware version number, a test flag will define how to identify if a dependency is met. The dependency check flag will have the following values:
  • 0—No check is performed.
  • 1—The release number or version number must be equal to the one of the installed hardware or module.
  • 2—The release number version number must be greater than the installed one.
  • 3—The release or version must be greater than or equal to the installed one.
  • setScript Command Structure
  • This section describes the setScript command structure that will be passed into the download install logic.
    Field Entry Field Type Description
    setScript ID string Unique identifier for the setScript
    command
    startTime time_t Specifies the start time frame of
    when the attached command can start
    processing
    endTime time_t Specifies the end of the time window
    when the attached scripts can start
    processing
    disableType integer Indicates the conditions under which
    the EGM is to be disabled to start
    processing the attached scripts
    initiateType integer Indicates the events that need to
    happen in order to start processing
    the attached command list.
    authorizeList string array A list of hosts that need to
    authorize the installation of the
    package.
    packageList string array A list of package IDs to be
    processed by this script command.
  • startTime/endTime—This is a date and time stamp that defines the start of the time and end of a time window within which a setScript command can start processing. None of the packages within the package list starts processing before this date and time are reached. The endTime is the date and time stamp after which the setScript command cannot start. The start of processing depends upon the initiateType being satisfied and all the authorizations being met. If these are not met, then the processing of the setScript command is suspended until the time window is entered again. Once the first package has started processing, all other packages will be processed regardless of the time window.
  • disableType—This specifies how the EGM should be disabled. The EGM cannot be disabled until the time processing time window is entered. As soon as the disable conditions are met, the EGM will be disabled and wait for the authorizations to occur. If the authorizations do not occur within the processing time window, the setScript command will be discontinued and the EGM re-enabled. The setScript command is then placed back into the waiting to process queue.
  • initiateType—Specifies what actions need to take place in order to start the installation. This includes host authorizations, local operator authorization, etc. These events can occur before the EGM is disabled in the case of host authorizations. All initiation requirements must be satisfied during the process time window.
  • authorizeList—This is a list of host IDs who must authorize the setScript command to start processing. If the host specifies authorization not granted, then the processing of the setScript command will be terminated.
  • PackageList—This is a list of packages to be processed. The packages will be processed in the order that they are specified within the setScript command. Module dependencies within one package may be satisfied by module in another package within the package list.
  • When a package specifies that a module is to be deleted, then all the files within the Module manifest file will be deleted from the system along with the manifest file itself.
  • Download Package Description
  • This document is used to specify the detail design of download packages. Each download package is made of various sections. Each section starts with a section ID, the size of the section, and the contents of the section. The contents of the section is dependent upon the type of package section defined.
  • The specific package sections are:
  • Package Header—This describes the overall package.
  • Module Entry—A package may contain one or module entries.
  • Dependency Entry—After each module. The hardware and software dependencies are defined for the module. There may none or multiple dependencies for each module.
  • File Entry—Various types of file entries are defined. Each type has its own unique ID
  • All the sections after the package header are considered to be part of the package data. A SHA 1 hash value is calculated over the entire package data. This hash value does not include the header in its calculation.
  • Each package section contains an integer header. The first integer is the section ID, and the second is the size of the section itself. The following sections describe the information that is contained within each package section.
  • The contents of the package header can be seen in the following table:
    Field Description
    mcnt integer Number of modules contained within
    the package
    ccnt integer Number of command defined in the
    package
    compression integer Compression applied to the package
    data
    psize integer Size of the package Data
    hsize integer Size of the header data
    type integer Type of Package
    Time_stamp Time_t Time stamp of when the package was
    built
    vString char Package Data Validation String
    (SHA1 or HMAC)
    pkgId char Unique identifier of the package
    release char Release information of package,
    (Version, build No, etc)
    description Char Description of package contents
    builderID char Identity of vender that created
    package
  • The package header is the first thing contained with a package and is a fixed length in size.
  • The package data compression types are:
    Compression Description
    1 Uncompressed data
    2 Compressed data using gzip protocol
    3 Compressed data using bzip2 protocol
  • The following package type are been identified:
    Package Type ID Description
    1 Download Package is download from a package
    server distribution
    2 Upload Package is created at the EGM and uploaded to
    a server.
    3 Command Package is downloaded from a server and
    only contains commands to be run at the EGM.
  • Module Sections
  • There can be multiple module sections within a package. The module section is identified by the package section ID number 2 and the size is the size of the module information as described in the table below.
    Field Type Description
    Type integer Type of Module
    Action Integer Action to take on Module (Add,
    update, delete)
    Mod Depend cnt. Integer No. of module dependencies for
    this module
    Hard Depend cnt. Integer No. of hardware dependencies
    for this module
    Strg Depend cnt Integer No. of defined storage
    dependencies
    Time Stamp integer Time stamp associated with when
    module built.
    Release Number sring Specific Release Major, Minor,
    Build and Version Nos.
    Name string Null terminate string containing
    the name of the module.
    Description string An optional null terminated
    string used to describe the module.
  • Each module is assigned a unique module name. The first three characters of the name are manufacturer unique and used to identify the manufacturer of the module. The size of the name does not exceed 32 characters in length in one embodiment, but that is by way of example only.
  • The hardware, module, and storage dependency counts specify how many of each type of dependency is included in the package.
  • The type is used to identify the type of module. The following table identifiers the module type that are used:
    Module Type ID Description
    os EGM OS module. Linux and Game kernels, libraries
    and utilities
    gm EGM Game module.
    fw Firmware module
    dt Data module. Contains EGM unique data.
    jr Jurisdiction module
    df Definition Module - Used to define new modules
    within the EGM
    cf Configuration Module - Used to specify configur-
    ation information for the OS, EGM and Game.
  • Package File Definitions
  • Files entries within the package are associated with the preceding module identified in the package. That is, all files entries after a module definition is encountered until the next module or command definition are associated with the module they follow. In the following example, module 1 has file 1 and 2 associated with it and module 2 has files 3 and 4 associated with it.
    Package Header
    Module
    1
    File 1
    File 2
    Module 2
    File 3
    File 4
  • All file definitions use the same control structure.
    Field Type Description
    Type Integer Type file that follows
    File size integer Size of the file
    File name string File name including fully qualified
    path.
    Destination string Fully qualified path where file is
    to be stored. Used for image files.
  • The following describes the type of files that can be included:
  • The manifest file section data area comprises the following 3 fields:
    Field type Description
    Type integer Type of manifest, OS (1), Game (2)
    Manifest Name string Manifest file name (32 Characters Max)
    File data binary The manifest file contents
  • The type field is used to determine which manifest sub-directory to copy the manifest file into. Manifests will be copied into a directory called manifests and either into the OSI or games subdirectory.
  • Tar File—(Package ID Type: 4)
  • Updates to installed modules as well as game installations will be in the form of a tar file.
  • Partition Image File—(Package ID Type: 5)
  • The partition image section contains a complete image of a particular partition on the EGM. Following the Section header data are the identification of the partition to be replaced by the image, followed by the image itself. The EGM will assign a name to the image file for processing at the EGM. The partition identification is a null terminated string. The partition that contains the manifest validation files will always be partition one on any device. This partition can not be updated with the use of a partition image.
  • Device Image File—(Package ID Type: 6)
  • The device image file section contains the complete image of a device on the EGM such as an entire compact flash. When the device image is specified, it is assumed that the manifest files are include within the image file itself and are therefore not included in a package manifest section. Following the section header, is a null terminated string that contains the device the image is meant for, such as /dev/had, followed by the image itself. The EGM will assign a name to the image file locally.
  • Dependency Sections
  • Hardware Dependencies (Package ID Type: 7)
  • The hardware dependency section identifies what hardware must exist on the system before the previously defined module can be installed. There can be any number of these associated with each module in the package. The hardware dependency section is comprised of the hardware ID as known on the EGM, a version number and the comparison type to be performed (equal, greater than, or greater than or equal).
  • Module Dependencies (Package ID Type: 8)
  • The module dependency specifies which modules must exist on the EGM before the previously defined module can be installed. There can be any number of these associated with each module in the package. The module dependency consist of the module id, the version number for the module and the comparison identifier that specifies the type of comparison to be performed against the version number (equal to, greater then, or greater than or equal to).
  • Storage Dependence (Package ID Type: 9)
  • The storage dependency defines how much storage must exist on the EGM. The fields in the storage record specify the type of storage, RAM, ROM, disk, etc and how mush must be there or how much free space must exist depending on the type of storage specified.
  • Package Record Identifiers
  • This describes the currently assigned id values for download package sections.
    Package
    Section Type ID Description
    Package Header
    1 Information unique to the package.
    Module Definition 2 Defines modules included in package
    Manifest File 3 Manifest File
    Associated with previous module definition.
    Tar File 4 Tar file associated with previous Module
    definition
    Partition Image 5 Partition Image file associated with previous
    Module definition.
    Device Image file 6 Device Image file associated with previous
    Module definition.
    Hardware 7 Hardware prerequisite/dependency associated
    Pre-requisite with previous module definition.
    Module 8 Module Prerequisite/dependency associated
    Pre-requisite with previous module definition.
    Storage Dependency 9 Storage Prerequisite dependency associated
    with previous module definition.

Claims (16)

1. A system for providing software to one or more gaming machines comprising:
a software distribution point for generating a download package and sending the package as a plurality of packets to the one or more gaming machines as part of a multicast;
at each gaming machine receiving the packets and determining if all packets have been received;
requesting dropped packets from the software distribution point: resending all dropped packets in a multicast.
2. The system of claim 1 wherein the multicast is done as a background process.
3. The system of claim 1 wherein a download control process on a gaming machine communicates with a system management point to control the download of the package.
4. The system of claim 3 further including a download receiver, download driver, and package installer on the gaming machine.
5. The system of claim 4 further including validating the package before installation.
6. The system of claim 5 further including checking for software prerequisites before installing the package.
7. The system of claim 6 further including downloading software prerequisites when needed before installing the package.
8. The system of claim 7 further including checking for hardware prerequisites before installing the package.
9. The system of claim 1 further including dividing memory on a gaming machine into partitions.
10. The system of claim 9 wherein the partitions comprise a manifest partition, a games partition and a download partition.
11. The system of claim 8 further including disabling the game machine when installation conditions have been met.
12. A system of initializing a gaming machine comprising:
a storage media having boot-strap instruction on the gaming machine;
communications means using the boot-strap instructions to initialize communications with a server upon initial start-up of the gaming machine and requesting a software package from the server;
the gaming machine receiving the software package and installing the software package on the gaming machine using the boot-strap instructions.
13. The system of claim 12 wherein the boot-strap instructions include a default address of a server for communication.
14. The system of claim 13 wherein the server is an SMP network server.
15. The system of claim 12 wherein the boot-strap instructions request a default boot-strap package from the server.
16. The system of claim 15 wherein the server is an SDP.
US11/530,452 2005-09-12 2006-09-08 Download and configuration system for gaming machines Abandoned US20070105628A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US11/530,452 US20070105628A1 (en) 2005-09-12 2006-09-08 Download and configuration system for gaming machines
EP06814544A EP1934869A4 (en) 2005-09-12 2006-09-11 Download and configuration system and method for gaming machines
PCT/US2006/035556 WO2007033207A2 (en) 2005-09-12 2006-09-11 Download and configuration system and method for gaming machines
AU2006290982A AU2006290982A1 (en) 2005-09-12 2006-09-11 Download and configuration system and method for gaming machines
CA002622577A CA2622577A1 (en) 2005-09-12 2006-09-11 Download and configuration system and method for gaming machines
US13/033,833 US20120220374A1 (en) 2005-09-12 2011-02-24 Download and configuration system and method for gaming machines

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US71671305P 2005-09-12 2005-09-12
US11/530,452 US20070105628A1 (en) 2005-09-12 2006-09-08 Download and configuration system for gaming machines

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/033,833 Continuation US20120220374A1 (en) 2005-09-12 2011-02-24 Download and configuration system and method for gaming machines

Publications (1)

Publication Number Publication Date
US20070105628A1 true US20070105628A1 (en) 2007-05-10

Family

ID=39733510

Family Applications (6)

Application Number Title Priority Date Filing Date
US11/530,452 Abandoned US20070105628A1 (en) 2005-09-12 2006-09-08 Download and configuration system for gaming machines
US11/530,450 Abandoned US20070218998A1 (en) 2005-09-12 2006-09-08 Download and configuration method for gaming machines
US11/530,875 Abandoned US20080214307A1 (en) 2005-09-12 2006-09-11 Method for configuration
US11/530,880 Abandoned US20070111791A1 (en) 2005-09-12 2006-09-11 System for configuration
US12/111,956 Active 2030-06-01 US9305424B2 (en) 2005-09-12 2008-04-29 System for managing an electronic gaming machine group
US13/033,833 Abandoned US20120220374A1 (en) 2005-09-12 2011-02-24 Download and configuration system and method for gaming machines

Family Applications After (5)

Application Number Title Priority Date Filing Date
US11/530,450 Abandoned US20070218998A1 (en) 2005-09-12 2006-09-08 Download and configuration method for gaming machines
US11/530,875 Abandoned US20080214307A1 (en) 2005-09-12 2006-09-11 Method for configuration
US11/530,880 Abandoned US20070111791A1 (en) 2005-09-12 2006-09-11 System for configuration
US12/111,956 Active 2030-06-01 US9305424B2 (en) 2005-09-12 2008-04-29 System for managing an electronic gaming machine group
US13/033,833 Abandoned US20120220374A1 (en) 2005-09-12 2011-02-24 Download and configuration system and method for gaming machines

Country Status (2)

Country Link
US (6) US20070105628A1 (en)
CN (3) CN101346723A (en)

Cited By (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070266174A1 (en) * 2006-05-12 2007-11-15 Caitlin Bestler Method and system for reliable multicast datagrams and barriers
US20080064497A1 (en) * 2004-01-12 2008-03-13 Igt Method and apparatus for using a light valve to reduce the visibility of an object within a gaming apparatus
US20080071885A1 (en) * 2006-09-20 2008-03-20 Michael Hardy Methods, systems and computer program products for determining installation status of SMS packages
US20080090652A1 (en) * 2006-10-16 2008-04-17 Kuehling Brian L Progressive controller
US20080108435A1 (en) * 2006-11-03 2008-05-08 Igt Monitoring and controlling gaming-environments
US20080113775A1 (en) * 2006-11-13 2008-05-15 Igt Three-dimensional paylines for gaming machines
US20080113749A1 (en) * 2006-11-13 2008-05-15 Igt Multimedia emulation of physical reel hardware in processor-based gaming machines
US20080113756A1 (en) * 2006-11-13 2008-05-15 Igt Presentation of wheels on gaming machines having multi-layer displays
US20080132323A1 (en) * 2006-11-03 2008-06-05 O'hara Matt Paul System for arranging gaming machines in a restricted space
US20080136741A1 (en) * 2006-11-13 2008-06-12 Igt Single plane spanning mode across independently driven displays
US20080162729A1 (en) * 2006-11-10 2008-07-03 Bally Gaming, Inc. Gaming system download network architecture
WO2009001075A1 (en) * 2007-06-27 2008-12-31 Inspired Gaming (Uk) Limited Entertainment device
US20090036208A1 (en) * 2002-08-06 2009-02-05 Igt Reel and video combination machine
US20090082109A1 (en) * 2007-09-20 2009-03-26 Konami Gaming, Inc. Multipurpose egm/player tracking device and system
US20090124372A1 (en) * 2005-04-29 2009-05-14 Gagner Mark B Asset management of downloadable gaming components in a gaming system
US20090131144A1 (en) * 2007-11-12 2009-05-21 Bally Gaming, Inc. Meta-option
US20090137302A1 (en) * 2005-07-05 2009-05-28 Ralston Samuel D Client-server network configurations for gaming systems
US20100022299A1 (en) * 2006-10-18 2010-01-28 Wms Gaming Inc. Control of reconfigurable gaming machines
US20100093441A1 (en) * 2008-07-11 2010-04-15 Bally Gaming, Inc. Integration gateway
US20100203954A1 (en) * 2007-03-01 2010-08-12 Wms Gaming Inc. Flex-time scheduling of electronic gaming machines
US7951001B2 (en) 2002-08-06 2011-05-31 Igt Gaming device having a three dimensional display device
US8052519B2 (en) 2006-06-08 2011-11-08 Bally Gaming, Inc. Systems, methods and articles to facilitate lockout of selectable odds/advantage in playing card games
US8192281B2 (en) 2006-11-13 2012-06-05 Igt Simulated reel imperfections
US8201229B2 (en) 2007-11-12 2012-06-12 Bally Gaming, Inc. User authorization system and methods
US8210922B2 (en) 2006-11-13 2012-07-03 Igt Separable game graphics on a gaming machine
US8266213B2 (en) 2008-11-14 2012-09-11 Bally Gaming, Inc. Apparatus, method, and system to provide a multiple processor architecture for server-based gaming
US8272945B2 (en) 2007-11-02 2012-09-25 Bally Gaming, Inc. Game related systems, methods, and articles that combine virtual and physical elements
US20120302324A1 (en) * 2011-05-24 2012-11-29 Wms Gaming, Inc. Player incentives for wagering game transfers
US8347303B2 (en) 2008-11-14 2013-01-01 Bally Gaming, Inc. Apparatus, method, and system to provide a multi-core processor for an electronic gaming machine (EGM)
US8357033B2 (en) 2006-11-13 2013-01-22 Igt Realistic video reels
US8366542B2 (en) 2008-05-24 2013-02-05 Bally Gaming, Inc. Networked gaming system with enterprise accounting methods and apparatus
US8423790B2 (en) 2008-11-18 2013-04-16 Bally Gaming, Inc. Module validation
US8425316B2 (en) 2010-08-03 2013-04-23 Igt Methods and systems for improving play of a bonus game on a gaming machine and improving security within a gaming establishment
US8631501B2 (en) 2006-11-10 2014-01-14 Bally Gaming, Inc. Reporting function in gaming system environment
US8667457B2 (en) 2006-11-13 2014-03-04 Bally Gaming, Inc. System and method for validating download or configuration assignment for an EGM or EGM collection
US8721431B2 (en) 2008-04-30 2014-05-13 Bally Gaming, Inc. Systems, methods, and devices for providing instances of a secondary game
US8784212B2 (en) 2006-11-10 2014-07-22 Bally Gaming, Inc. Networked gaming environment employing different classes of gaming machines
US20140289049A1 (en) * 2011-10-20 2014-09-25 Proxistore S.A. Communication system for the display of advertisements
US8856657B2 (en) 2008-04-30 2014-10-07 Bally Gaming, Inc. User interface for managing network download and configuration tasks
US8870647B2 (en) 2006-04-12 2014-10-28 Bally Gaming, Inc. Wireless gaming environment
US20140329604A1 (en) * 2013-05-02 2014-11-06 Bally Gaming, Inc. Transport agnostic ipc mechanism
US8920233B2 (en) 2006-11-10 2014-12-30 Bally Gaming, Inc. Assignment template and assignment bundle in a gaming configuration and download system
US9005034B2 (en) 2008-04-30 2015-04-14 Bally Gaming, Inc. Systems and methods for out-of-band gaming machine management
US9058716B2 (en) 2011-06-06 2015-06-16 Bally Gaming, Inc. Remote game play in a wireless gaming environment
US9082258B2 (en) 2006-11-13 2015-07-14 Bally Gaming, Inc. Method and system for providing download and configuration job progress tracking and display via host user interface
US9101820B2 (en) 2006-11-09 2015-08-11 Bally Gaming, Inc. System, method and apparatus to produce decks for and operate games played with playing cards
US9111078B2 (en) 2006-11-10 2015-08-18 Bally Gaming, Inc. Package manager service in gaming system
US9120007B2 (en) 2012-01-18 2015-09-01 Bally Gaming, Inc. Network gaming architecture, gaming systems, and related methods
US9443377B2 (en) 2008-05-30 2016-09-13 Bally Gaming, Inc. Web pages for gaming devices
US9466172B2 (en) 2006-11-13 2016-10-11 Bally Gaming, Inc. Download and configuration management engine for gaming system
US9483911B2 (en) 2008-04-30 2016-11-01 Bally Gaming, Inc. Information distribution in gaming networks
US9792770B2 (en) 2012-01-18 2017-10-17 Bally Gaming, Inc. Play for fun network gaming system and method
US10957153B2 (en) * 2019-03-15 2021-03-23 Ags Llc Technician input-free reconfiguration of secured gaming system
US10970968B2 (en) 2018-04-18 2021-04-06 Igt System and method for incentivizing the maintenance of funds in a gaming establishment account
US20220368764A1 (en) * 2021-05-13 2022-11-17 Agora Lab, Inc. Universal Transport Framework For Heterogeneous Data Streams

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8100753B2 (en) 2006-05-23 2012-01-24 Bally Gaming, Inc. Systems, methods and articles to facilitate playing card games with selectable odds
US8191121B2 (en) 2006-11-10 2012-05-29 Bally Gaming, Inc. Methods and systems for controlling access to resources in a gaming network
US8195825B2 (en) 2006-11-10 2012-06-05 Bally Gaming, Inc. UDP broadcast for user interface in a download and configuration gaming method
US8478833B2 (en) 2006-11-10 2013-07-02 Bally Gaming, Inc. UDP broadcast for user interface in a download and configuration gaming system
US20090104994A1 (en) * 2006-11-13 2009-04-23 Ihor Bohdan Rybak Dynamic game management of video lottery terminals and a method and system for providing thereof
US8131829B2 (en) 2006-11-13 2012-03-06 Bally Gaming, Inc. Gaming machine collection and management
IL180230A0 (en) * 2006-12-21 2007-05-15 Eci Telecom Ltd Method for downloading data files to a group of clients via a proxy with a limited storage
ITMI20071449A1 (en) * 2007-07-19 2009-01-20 Technit Compagnia Tecnica Inte METHOD OF CLASSIFICATION OF DEFECTS AND MANAGEMENT OF GRINDING OF LAMINATION CYLINDERS
US8353758B2 (en) * 2007-09-17 2013-01-15 Ami Entertainment Network, Inc. Amusement device having electronic game and jukebox functionalities
AU2008221552A1 (en) * 2007-09-27 2009-04-23 Aristocrat Technologies Australia Pty Limited A gaming system and a method of gaming
JP2009230422A (en) * 2008-03-21 2009-10-08 Canon Inc License file issuing device, image processing apparatus, license file issuing method, and application installation method
US20090327303A1 (en) * 2008-06-27 2009-12-31 Microsoft Corporation Intelligent allocation of file server resources
US8274980B2 (en) * 2009-02-26 2012-09-25 International Business Machines Corporation Ethernet link aggregation
US8192283B2 (en) 2009-03-10 2012-06-05 Bally Gaming, Inc. Networked gaming system including a live floor view module
US8429464B2 (en) * 2009-11-12 2013-04-23 Bally Gaming, Inc. Background memory validation for gaming devices
US8371934B2 (en) 2010-06-30 2013-02-12 Bally Gaming, Inc. Self configuring progressive jackpot award systems
US20120115608A1 (en) * 2010-11-05 2012-05-10 Howard Pfeifer Method and apparatus for controlling an audio parameter of a plurality of wagering game machines
US8278779B2 (en) 2011-02-07 2012-10-02 General Electric Company System and method for providing redundant power to a device
US8662998B2 (en) * 2011-08-30 2014-03-04 Multimedia Games, Inc. Systems and methods for dynamically altering wagering game assets
JP5984043B2 (en) * 2012-03-30 2016-09-06 ブラザー工業株式会社 Template processing program and template processing method
US9005021B2 (en) 2012-08-23 2015-04-14 Wms Gaming Inc. System and method for flexible banking of wagering game machines
US8790185B1 (en) 2012-12-04 2014-07-29 Kabam, Inc. Incentivized task completion using chance-based awards
US8831758B1 (en) 2013-03-20 2014-09-09 Kabam, Inc. Interface-based game-space contest generation
US9007189B1 (en) 2013-04-11 2015-04-14 Kabam, Inc. Providing leaderboard based upon in-game events
US9613179B1 (en) 2013-04-18 2017-04-04 Kabam, Inc. Method and system for providing an event space associated with a primary virtual space
US9626475B1 (en) 2013-04-18 2017-04-18 Kabam, Inc. Event-based currency
US8961319B1 (en) 2013-05-16 2015-02-24 Kabam, Inc. System and method for providing dynamic and static contest prize allocation based on in-game achievement of a user
US9463376B1 (en) 2013-06-14 2016-10-11 Kabam, Inc. Method and system for temporarily incentivizing user participation in a game space
US10110594B2 (en) 2013-09-04 2018-10-23 Hewlett-Packard Development Company, L.P. Header section download of package
US9799163B1 (en) 2013-09-16 2017-10-24 Aftershock Services, Inc. System and method for providing a currency multiplier item in an online game with a value based on a user's assets
WO2015046447A1 (en) * 2013-09-27 2015-04-02 グリー株式会社 Computer control method, control program and computer
US11058954B1 (en) 2013-10-01 2021-07-13 Electronic Arts Inc. System and method for implementing a secondary game within an online game
US10282739B1 (en) 2013-10-28 2019-05-07 Kabam, Inc. Comparative item price testing
US10482713B1 (en) 2013-12-31 2019-11-19 Kabam, Inc. System and method for facilitating a secondary game
US9508222B1 (en) 2014-01-24 2016-11-29 Kabam, Inc. Customized chance-based items
US10226691B1 (en) 2014-01-30 2019-03-12 Electronic Arts Inc. Automation of in-game purchases
US9873040B1 (en) 2014-01-31 2018-01-23 Aftershock Services, Inc. Facilitating an event across multiple online games
US9795885B1 (en) 2014-03-11 2017-10-24 Aftershock Services, Inc. Providing virtual containers across online games
US9517405B1 (en) 2014-03-12 2016-12-13 Kabam, Inc. Facilitating content access across online games
US9610503B2 (en) 2014-03-31 2017-04-04 Kabam, Inc. Placeholder items that can be exchanged for an item of value based on user performance
US9744445B1 (en) 2014-05-15 2017-08-29 Kabam, Inc. System and method for providing awards to players of a game
US10307666B2 (en) 2014-06-05 2019-06-04 Kabam, Inc. System and method for rotating drop rates in a mystery box
US9744446B2 (en) 2014-05-20 2017-08-29 Kabam, Inc. Mystery boxes that adjust due to past spending behavior
US9717986B1 (en) 2014-06-19 2017-08-01 Kabam, Inc. System and method for providing a quest from a probability item bundle in an online game
US9579564B1 (en) 2014-06-30 2017-02-28 Kabam, Inc. Double or nothing virtual containers
US9452356B1 (en) 2014-06-30 2016-09-27 Kabam, Inc. System and method for providing virtual items to users of a virtual space
US9539502B1 (en) 2014-06-30 2017-01-10 Kabam, Inc. Method and system for facilitating chance-based payment for items in a game
US10463968B1 (en) 2014-09-24 2019-11-05 Kabam, Inc. Systems and methods for incentivizing participation in gameplay events in an online game
US9656174B1 (en) 2014-11-20 2017-05-23 Afterschock Services, Inc. Purchasable tournament multipliers
US9827499B2 (en) 2015-02-12 2017-11-28 Kabam, Inc. System and method for providing limited-time events to users in an online game
CN109814887A (en) * 2019-01-23 2019-05-28 广州奇艺果信息科技有限公司 It is a kind of can the compatible Android game of Remote Expansion arcade system
TWI726485B (en) * 2019-11-14 2021-05-01 名豐電子股份有限公司 Gambling games management system
WO2021174232A2 (en) * 2020-06-04 2021-09-02 Futurewei Technologies, Inc. Constraint set merge and subtraction
CN111983949B (en) * 2020-07-16 2022-04-15 徐州晶睿半导体装备科技有限公司 Device control method and system based on Dotnet upper computer and lower computer
CN111973991A (en) * 2020-08-21 2020-11-24 上海二三四五网络科技有限公司 Control method and device for accelerating game loading through distributed loading resource files

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US6009274A (en) * 1996-12-13 1999-12-28 3Com Corporation Method and apparatus for automatically updating software components on end systems over a network
US6319125B1 (en) * 1994-10-12 2001-11-20 Acres Gaming Incorporated Method apparatus for promoting play on a network of gaming devices
US20030200290A1 (en) * 2002-04-18 2003-10-23 Myron Zimmerman System for and method of streaming data to a computer in a network
US6805634B1 (en) * 1998-10-14 2004-10-19 Igt Method for downloading data to gaming devices

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5526506A (en) * 1970-12-28 1996-06-11 Hyatt; Gilbert P. Computer system having an improved memory architecture
US6222856B1 (en) * 1996-07-02 2001-04-24 Murali R. Krishnan Adaptive bandwidth throttling for individual virtual services supported on a network server
GB2354613B (en) * 1996-10-16 2001-05-30 Ibm Data processing network
US6202207B1 (en) * 1998-01-28 2001-03-13 International Business Machines Corporation Method and a mechanism for synchronized updating of interoperating software
US6219836B1 (en) * 1998-10-14 2001-04-17 International Game Technology Program management method and apparatus for gaming device components
US6891955B1 (en) * 1999-07-29 2005-05-10 Micron Technology, Inc. Audio volume control for computer systems
US6508710B1 (en) * 1999-12-27 2003-01-21 Virtgame Corp. Gaming system with location verification
US7043641B1 (en) * 2000-03-08 2006-05-09 Igt Encryption in a secure computerized gaming system
US6988141B1 (en) * 2000-05-17 2006-01-17 Ricoh Company, Ltd. Method and system of remote diagnostic, control and information collection using a dynamic linked library of multiple formats and multiple protocols with restriction on protocol
AU2002223184A1 (en) * 2000-10-18 2002-04-29 Gaming Systems International System and method for casino management
WO2002055163A2 (en) * 2000-11-01 2002-07-18 Station Casinos Inc Method and system for remote gaming
US7515718B2 (en) * 2000-12-07 2009-04-07 Igt Secured virtual network in a gaming environment
US7168089B2 (en) * 2000-12-07 2007-01-23 Igt Secured virtual network in a gaming environment
US7186181B2 (en) * 2001-02-02 2007-03-06 Igt Wide area program distribution and game information communication system
WO2002089935A1 (en) * 2001-04-11 2002-11-14 Walker Digital, Llc Method and apparatus for remotely customizing a gaming device
US20030003997A1 (en) * 2001-06-29 2003-01-02 Vt Tech Corp. Intelligent casino management system and method for managing real-time networked interactive gaming systems
US20030006931A1 (en) * 2001-07-03 2003-01-09 Ken Mages System and method for providing accurate location information for wireless or wired remote gaming activities
US20030130040A1 (en) * 2001-07-17 2003-07-10 Jeffrey Thomas Dripps Distributed video game system and method
US20060287098A1 (en) * 2001-09-28 2006-12-21 Morrow James W System and method for gaming-content configuration and management system
US8147334B2 (en) * 2003-09-04 2012-04-03 Jean-Marie Gatto Universal game server
US6935958B2 (en) * 2002-02-06 2005-08-30 Igt Method and apparatus for machine location
US6843725B2 (en) * 2002-02-06 2005-01-18 Igt Method and apparatus for monitoring or controlling a gaming machine based on gaming machine location
US20030206549A1 (en) * 2002-05-03 2003-11-06 Mody Sachin Satish Method and apparatus for multicast delivery of information
US6884173B2 (en) * 2002-05-14 2005-04-26 Atronic International Gmbh Configuration technique for a gaming machine
US6939234B2 (en) * 2002-06-10 2005-09-06 Wms Gaming, Inc. Dynamic configuration of gaming system
JP3495032B1 (en) * 2002-07-24 2004-02-09 コナミ株式会社 Game progress management device, game server device, terminal device, game progress management method, and game progress management program
US20040166940A1 (en) * 2003-02-26 2004-08-26 Rothschild Wayne H. Configuration of gaming machines
CA2518466C (en) * 2003-03-10 2011-06-21 Cyberscan Technology, Inc. Dynamic configuration of a gaming system
US7383271B2 (en) * 2004-04-06 2008-06-03 Microsoft Corporation Centralized configuration data management for distributed clients
US7844964B2 (en) * 2004-09-23 2010-11-30 Hewlett Packard Development Company, L.P. Network for mass distribution of configuration, firmware and software updates

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4558413A (en) * 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US6319125B1 (en) * 1994-10-12 2001-11-20 Acres Gaming Incorporated Method apparatus for promoting play on a network of gaming devices
US6009274A (en) * 1996-12-13 1999-12-28 3Com Corporation Method and apparatus for automatically updating software components on end systems over a network
US6805634B1 (en) * 1998-10-14 2004-10-19 Igt Method for downloading data to gaming devices
US20030200290A1 (en) * 2002-04-18 2003-10-23 Myron Zimmerman System for and method of streaming data to a computer in a network

Cited By (84)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7951001B2 (en) 2002-08-06 2011-05-31 Igt Gaming device having a three dimensional display device
US8715058B2 (en) 2002-08-06 2014-05-06 Igt Reel and video combination machine
US20090036208A1 (en) * 2002-08-06 2009-02-05 Igt Reel and video combination machine
US20080064497A1 (en) * 2004-01-12 2008-03-13 Igt Method and apparatus for using a light valve to reduce the visibility of an object within a gaming apparatus
US8118670B2 (en) 2004-01-12 2012-02-21 Igt Method and apparatus for using a light valve to reduce the visibility of an object within a gaming apparatus
US20090124372A1 (en) * 2005-04-29 2009-05-14 Gagner Mark B Asset management of downloadable gaming components in a gaming system
US20090137302A1 (en) * 2005-07-05 2009-05-28 Ralston Samuel D Client-server network configurations for gaming systems
US8870647B2 (en) 2006-04-12 2014-10-28 Bally Gaming, Inc. Wireless gaming environment
US9786123B2 (en) 2006-04-12 2017-10-10 Bally Gaming, Inc. Wireless gaming environment
US20070266174A1 (en) * 2006-05-12 2007-11-15 Caitlin Bestler Method and system for reliable multicast datagrams and barriers
US7849211B2 (en) * 2006-05-12 2010-12-07 Broadcom Corporation Method and system for reliable multicast datagrams and barriers
US8052519B2 (en) 2006-06-08 2011-11-08 Bally Gaming, Inc. Systems, methods and articles to facilitate lockout of selectable odds/advantage in playing card games
US9544196B2 (en) * 2006-09-20 2017-01-10 At&T Intellectual Property I, L.P. Methods, systems and computer program products for determining installation status of SMS packages
US20080071885A1 (en) * 2006-09-20 2008-03-20 Michael Hardy Methods, systems and computer program products for determining installation status of SMS packages
US20080090652A1 (en) * 2006-10-16 2008-04-17 Kuehling Brian L Progressive controller
US7896741B2 (en) * 2006-10-16 2011-03-01 Igt Progressive controller
US8142291B2 (en) * 2006-10-18 2012-03-27 Wms Gaming, Inc. Control of reconfigurable gaming machines
US20100022299A1 (en) * 2006-10-18 2010-01-28 Wms Gaming Inc. Control of reconfigurable gaming machines
US20080132323A1 (en) * 2006-11-03 2008-06-05 O'hara Matt Paul System for arranging gaming machines in a restricted space
US20080108435A1 (en) * 2006-11-03 2008-05-08 Igt Monitoring and controlling gaming-environments
US9101820B2 (en) 2006-11-09 2015-08-11 Bally Gaming, Inc. System, method and apparatus to produce decks for and operate games played with playing cards
US9275512B2 (en) 2006-11-10 2016-03-01 Bally Gaming, Inc. Secure communications in gaming system
US20080162729A1 (en) * 2006-11-10 2008-07-03 Bally Gaming, Inc. Gaming system download network architecture
US8920233B2 (en) 2006-11-10 2014-12-30 Bally Gaming, Inc. Assignment template and assignment bundle in a gaming configuration and download system
US8784212B2 (en) 2006-11-10 2014-07-22 Bally Gaming, Inc. Networked gaming environment employing different classes of gaming machines
US8631501B2 (en) 2006-11-10 2014-01-14 Bally Gaming, Inc. Reporting function in gaming system environment
US20080171598A1 (en) * 2006-11-10 2008-07-17 Bally Gaming, Inc. Secure communications in gaming system
US9111078B2 (en) 2006-11-10 2015-08-18 Bally Gaming, Inc. Package manager service in gaming system
US9508218B2 (en) 2006-11-10 2016-11-29 Bally Gaming, Inc. Gaming system download network architecture
US8360847B2 (en) 2006-11-13 2013-01-29 Igt Multimedia emulation of physical reel hardware in processor-based gaming machines
US8142273B2 (en) * 2006-11-13 2012-03-27 Igt Presentation of wheels on gaming machines having multi-layer displays
US8210922B2 (en) 2006-11-13 2012-07-03 Igt Separable game graphics on a gaming machine
US8727855B2 (en) * 2006-11-13 2014-05-20 Igt Three-dimensional paylines for gaming machines
US20080113775A1 (en) * 2006-11-13 2008-05-15 Igt Three-dimensional paylines for gaming machines
US20080113749A1 (en) * 2006-11-13 2008-05-15 Igt Multimedia emulation of physical reel hardware in processor-based gaming machines
US8667457B2 (en) 2006-11-13 2014-03-04 Bally Gaming, Inc. System and method for validating download or configuration assignment for an EGM or EGM collection
US8192281B2 (en) 2006-11-13 2012-06-05 Igt Simulated reel imperfections
US8357033B2 (en) 2006-11-13 2013-01-22 Igt Realistic video reels
US9082258B2 (en) 2006-11-13 2015-07-14 Bally Gaming, Inc. Method and system for providing download and configuration job progress tracking and display via host user interface
US9466172B2 (en) 2006-11-13 2016-10-11 Bally Gaming, Inc. Download and configuration management engine for gaming system
US20080113756A1 (en) * 2006-11-13 2008-05-15 Igt Presentation of wheels on gaming machines having multi-layer displays
US20080136741A1 (en) * 2006-11-13 2008-06-12 Igt Single plane spanning mode across independently driven displays
US8199068B2 (en) 2006-11-13 2012-06-12 Igt Single plane spanning mode across independently driven displays
US8303418B2 (en) * 2007-03-01 2012-11-06 Wms Gaming Inc. Flex-time scheduling of electronic gaming machines
US20100203954A1 (en) * 2007-03-01 2010-08-12 Wms Gaming Inc. Flex-time scheduling of electronic gaming machines
WO2009001075A1 (en) * 2007-06-27 2008-12-31 Inspired Gaming (Uk) Limited Entertainment device
US8429229B2 (en) * 2007-09-20 2013-04-23 Konami Gaming, Inc. Multipurpose EGM/player tracking device and system
US20090082109A1 (en) * 2007-09-20 2009-03-26 Konami Gaming, Inc. Multipurpose egm/player tracking device and system
US9452359B2 (en) 2007-09-20 2016-09-27 Konami Gaming, Inc. Multipurpose EGM/player tracking device and system
US8734245B2 (en) 2007-11-02 2014-05-27 Bally Gaming, Inc. Game related systems, methods, and articles that combine virtual and physical elements
US8272945B2 (en) 2007-11-02 2012-09-25 Bally Gaming, Inc. Game related systems, methods, and articles that combine virtual and physical elements
US9613487B2 (en) 2007-11-02 2017-04-04 Bally Gaming, Inc. Game related systems, methods, and articles that combine virtual and physical elements
US8920236B2 (en) 2007-11-02 2014-12-30 Bally Gaming, Inc. Game related systems, methods, and articles that combine virtual and physical elements
US8201229B2 (en) 2007-11-12 2012-06-12 Bally Gaming, Inc. User authorization system and methods
US8616958B2 (en) 2007-11-12 2013-12-31 Bally Gaming, Inc. Discovery method and system for dynamically locating networked gaming components and resources
US8819124B2 (en) 2007-11-12 2014-08-26 Bally Gaming, Inc. System and method for one-way delivery of notifications from server-to-clients using modified multicasts
US20090131144A1 (en) * 2007-11-12 2009-05-21 Bally Gaming, Inc. Meta-option
US9005034B2 (en) 2008-04-30 2015-04-14 Bally Gaming, Inc. Systems and methods for out-of-band gaming machine management
US8856657B2 (en) 2008-04-30 2014-10-07 Bally Gaming, Inc. User interface for managing network download and configuration tasks
US9483911B2 (en) 2008-04-30 2016-11-01 Bally Gaming, Inc. Information distribution in gaming networks
US8721431B2 (en) 2008-04-30 2014-05-13 Bally Gaming, Inc. Systems, methods, and devices for providing instances of a secondary game
US8366542B2 (en) 2008-05-24 2013-02-05 Bally Gaming, Inc. Networked gaming system with enterprise accounting methods and apparatus
US8382584B2 (en) 2008-05-24 2013-02-26 Bally Gaming, Inc. Networked gaming system with enterprise accounting methods and apparatus
US9443377B2 (en) 2008-05-30 2016-09-13 Bally Gaming, Inc. Web pages for gaming devices
US20100093441A1 (en) * 2008-07-11 2010-04-15 Bally Gaming, Inc. Integration gateway
US8412768B2 (en) 2008-07-11 2013-04-02 Ball Gaming, Inc. Integration gateway
US8851988B2 (en) 2008-11-14 2014-10-07 Bally Gaming, Inc. Apparatus, method, and system to provide a multiple processor architecture for server-based gaming
US8266213B2 (en) 2008-11-14 2012-09-11 Bally Gaming, Inc. Apparatus, method, and system to provide a multiple processor architecture for server-based gaming
US8347303B2 (en) 2008-11-14 2013-01-01 Bally Gaming, Inc. Apparatus, method, and system to provide a multi-core processor for an electronic gaming machine (EGM)
US8423790B2 (en) 2008-11-18 2013-04-16 Bally Gaming, Inc. Module validation
US8425316B2 (en) 2010-08-03 2013-04-23 Igt Methods and systems for improving play of a bonus game on a gaming machine and improving security within a gaming establishment
US8475283B2 (en) * 2011-05-24 2013-07-02 Wms Gaming, Inc Player incentives for wagering game transfers
US20120302324A1 (en) * 2011-05-24 2012-11-29 Wms Gaming, Inc. Player incentives for wagering game transfers
US9058716B2 (en) 2011-06-06 2015-06-16 Bally Gaming, Inc. Remote game play in a wireless gaming environment
US9898889B2 (en) 2011-06-06 2018-02-20 Bally Gaming, Inc. Remote game play in a wireless gaming environment
US20140289049A1 (en) * 2011-10-20 2014-09-25 Proxistore S.A. Communication system for the display of advertisements
US9120007B2 (en) 2012-01-18 2015-09-01 Bally Gaming, Inc. Network gaming architecture, gaming systems, and related methods
US9792770B2 (en) 2012-01-18 2017-10-17 Bally Gaming, Inc. Play for fun network gaming system and method
US10403091B2 (en) 2012-01-18 2019-09-03 Bally Gaming, Inc. Play for fun network gaming system and method
US20140329604A1 (en) * 2013-05-02 2014-11-06 Bally Gaming, Inc. Transport agnostic ipc mechanism
US10970968B2 (en) 2018-04-18 2021-04-06 Igt System and method for incentivizing the maintenance of funds in a gaming establishment account
US10957153B2 (en) * 2019-03-15 2021-03-23 Ags Llc Technician input-free reconfiguration of secured gaming system
US20220368764A1 (en) * 2021-05-13 2022-11-17 Agora Lab, Inc. Universal Transport Framework For Heterogeneous Data Streams
US11811877B2 (en) * 2021-05-13 2023-11-07 Agora Lab, Inc. Universal transport framework for heterogeneous data streams

Also Published As

Publication number Publication date
CN102592366B (en) 2015-07-29
CN102592366A (en) 2012-07-18
CN101360541A (en) 2009-02-04
US20120220374A1 (en) 2012-08-30
CN101360541B (en) 2012-04-04
US20070111791A1 (en) 2007-05-17
US20080214307A1 (en) 2008-09-04
US9305424B2 (en) 2016-04-05
US20070218998A1 (en) 2007-09-20
US20080200260A1 (en) 2008-08-21
CN101346723A (en) 2009-01-14

Similar Documents

Publication Publication Date Title
US20070105628A1 (en) Download and configuration system for gaming machines
AU2006290982A1 (en) Download and configuration system and method for gaming machines
US9990800B2 (en) Casino game download system and method of use
US20050054448A1 (en) N-tier architecture for a casino management system and method
US20090235245A1 (en) Software Management System and Method
US20080200258A1 (en) System for configuration validation
AU2020233716B2 (en) Casino game download system and method of use
US20130252739A1 (en) Systems and methods for configuring a gaming machine
US20080207334A1 (en) Method for configuration validation
AU2014218394B2 (en) Method and system for configuration
AU2006291020B2 (en) Method and system for configuration
US20090181773A1 (en) Gaming system and a method of gaming
AU2015202266B2 (en) Casino game download system and method of use
AU2018202275A1 (en) N-tier architecture for a casino management system and method
AU2009243039A1 (en) User interface for managing network download and configuration tasks
AU2013216594A1 (en) N-tier architecture for a casino management system and method
AU2011253945A1 (en) Casino game download system and method of use

Legal Events

Date Code Title Description
AS Assignment

Owner name: BALLY GAMING, INC., NEVADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ARBOGAST, CHRISTOPHER P.;GREEN, TRAVIS;JONES, WILLIAM K.;AND OTHERS;REEL/FRAME:018781/0831;SIGNING DATES FROM 20070103 TO 20070111

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION

AS Assignment

Owner name: SG GAMING, INC., NEVADA

Free format text: CHANGE OF NAME;ASSIGNOR:BALLY GAMING, INC.;REEL/FRAME:051641/0653

Effective date: 20200103