Patent Application
20070105628
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.
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.
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.
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
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:
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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:
The package header is the first thing contained with a package and is a fixed length in size.
The package data compression types are:
The following package type are been identified:
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.
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:
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.
All file definitions use the same control structure.
The following describes the type of files that can be included:
The manifest file section data area comprises the following 3 fields:
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 60716713 | Sep 2005 | US |
