Abstract:
The system and method allows a casino operator to re-configure one or more electronic gaming machines as part of a multicast. Where any reconfiguration requires a software package A and any dependent package B, a server is configured to combine as part of the multicast both packages A and B. The system and method also provides for scheduling reconfiguration though multi-casting. In the event any data packages are lost, corrupted or not received, those packages are repackaged and the data packets are re-sent as a multicast.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This patent application is a continuation application U.S. patent application Ser. No. 11/530,452 filed Sep. 8, 2006 and titled “DOWNLOAD AND CONFIGURATION SYSTEM FOR GAMING MACHINES” which claims priority to U.S. Provisional Patent Application No. 60/716,713 filed Sep. 12, 2005 and which applications are incorporated by reference herein in their entirety. This application is related to U.S. patent application Ser. No. 11/530,450 filed Sep. 8, 2006 and titled “DOWNLOAD AND CONFIGURATION SYSTEM FOR GAMING MACHINES”. 
     
    
     COPYRIGHT NOTICE 
       [0002]    A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. 
       BACKGROUND 
       [0003]    Over the years, casinos have grown in size, grandeur, and amenities in order to attract gambling patrons. Additionally, casinos have attempted to provide gambling patrons with a wide variety of the new and exciting games. Given this demand, gaming machines have grown in sophistication and features in order to captivate and maintain player interest. As a result, casinos are able to provide a wide range and large number of games of chance. 
         [0004]    For example, a casino floor may include thousands of electronic gaming machines (EGMs) that are in communication with and monitored by the casino&#39;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&#39;s iView™ touch-screen display). Accordingly, there are a large number of EGMs and related components that need to be monitored, maintained, and serviced. 
         [0005]    In early gaming environments, gaming machines were stand-alone devices. Security of the gaming machines was accomplished via physical locks, security protocols, security personnel, physical and video monitoring, and the need to be physically present at a machine to attempt to breach the security of the gaming machine. By the same token, management of the gaming machines required a great deal of personal physical interaction with each gaming machine. The ability to change parameters of the gaming machine also required physical interaction. 
         [0006]    In view of the increased processing power and availability of computing devices, gaming machines have become customizable via electronic communications and remotely controllable. Manufacturers of gaming equipment have taken advantage of the increased functionality of gaming machines by adding additional features to gaming machines, thereby maintaining a player&#39;s attention to the gaming machines for longer periods of time increasing minimum bet and bet frequency and speed of play. This, in turn, leads to the player wagering at the gaming machine for longer periods of time, with more money at a faster pace, thereby increasing owner profits. 
         [0007]    The amount of interactivity and data presentation/collection possible with current processor based gaming machines has led to a desire to connect gaming machines in a gaming network. In addition to the gaming machines themselves, a number of devices associated with a gaming machine or with a group of gaming machines may be part of the network. It has become important for the devices within a gaming machine or cabinet to be aware of each other and to be able to communicate to a control server. Not only is the presence or absence of a network device important, but also the physical location of the device and the ability to associate devices within a particular gaming machine has become a necessary component of a gaming network. 
         [0008]    Currently, casino operators use manual methods to alter content or to reconfigure EGMs and/or other secondary networked devices. For example, a casino employee would need to physically swap out an EPROM to change game content or the employee would need to access an attendant menu on the EGM to alter game configurations. Given the large number of machines and networked devices, this process is a time-consuming and costly process not only in terms of operating and/or maintenance costs, but also in terms of lost profits due to extended downtime for the EGMs. Similarly, existing approaches for software updates or downloads for EGMs are labor-intensive and costly as the EGMs. For example, a technician typically needs to travel to the gaming machine in order to replace existing software package media (e.g., EPROMs, CD-ROM&#39;s, Compact Flash, etc.) with new software package media. Furthermore, the software package update process may require that the EGM be disabled hours in advance to prevent any players from using the EGM when the technician is ready to perform software package changes. Alternatively, EGMs may be disabled prior to software package updates, but the technician must periodically check to ensure that the EGM(s) are not being used by a player. Additionally, technicians may need to be supervised during the process of software package installation as the technician has access to critical areas of the EGM required for configuration or of those areas of containing cash. 
         [0009]    The process of transferring packages to an EGM over a network may require a significant amount of network bandwidth during the transfer period. Typical transfer mechanisms provide point-to-point transfer where a 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&#39;s require packages to be transferred there may be an unacceptable extended period of high bandwidth usage, since the transfers must occur sequentially. 
         [0010]    Additionally, installing packages on an EGM can require verification that dependent software packages and hardware components are available within the EGM. This is typically a manual process that prone to human interpretation and human error. 
         [0011]    Accordingly, there remains a need to provide a system for updating and configuring EGMS and other networked components. 
       SUMMARY 
       [0012]    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. 
         [0013]    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. 
         [0014]    The system includes a scheme for EGM&#39;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. 
         [0015]    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. 
         [0016]    The system includes technology necessary for the System Management Point (SMP) to manage package dependencies (dependencies such as a new package-A which 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. 
         [0017]    The system includes technology necessary for the SMP to determine if a package&#39;s dependent hardware components are available on the EGM. The concept is similar to the package dependencies; however the SMP cannot automatically transfer hardware components to an EGM to satisfy package dependencies. If a package&#39;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. 
         [0018]    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. 
         [0019]    Moreover, the configuration changes are communicated during the background operation of the EGM without affecting game play, 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. 
         [0020]    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. 
         [0021]    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. 
         [0022]    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. 
         [0023]    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). 
         [0024]    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&#39;s contents are tracked by the resulting versioned modules that have been installed on the EGM. 
         [0025]    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 
         [0026]      FIG. 1  illustrates an embodiment of a gaming network that may be used with the system. 
           [0027]      FIG. 2  illustrates an overview of download interaction 
           [0028]      FIG. 3  illustrates an overview of EGM Start-up message flow. 
           [0029]      FIG. 4  depicts the logic flow of /dev/download driver initialization. 
           [0030]      FIG. 5  is a flow diagram illustrating a routine to validate download requests and pass control to the proper handler function. 
           [0031]      FIG. 6  is a flow diagram illustrating the add package logic of the download driver. 
           [0032]      FIG. 7  is a flow diagram illustrating the download control process addPackage logic. 
           [0033]      FIG. 8  illustrates the message flow for the download receiver addPackage process. 
           [0034]      FIG. 9  illustrates the logic flow for the DR. 
           [0035]      FIG. 10  is a flow diagram illustrating the pre-requisite process. 
           [0036]      FIG. 11  illustrates the logic flow for this process. 
           [0037]      FIG. 12  is an overview of how the package is installed on the EGM. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0038]    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. 
         [0039]    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. 
         [0040]    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. 
         [0041]    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&#39;s client device, which in one embodiment, comprises a player&#39;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. 
         [0042]    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  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. (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&#39;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. 
         [0043]    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. 
         [0044]    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&#39;s simultaneously. The SDP will send a single transfer to a defined set of EGM&#39;s, thereby using a fraction of the network bandwidth when compared to the point-to-point strategy. If there are X groups of EGM&#39;s, with each group consisting of Y EGM&#39;s, then the following calculations provide a general sense of reduced network bandwidth usage: 
         [0000]    
       
         
           
             Multicast 
              
             
               : 
             
              
             
                 
             
              
             X 
             * 
             transferSize 
           
         
       
       
         
           
             
               
                 Point 
                  
                 
                   - 
                 
                  
                 to 
                  
                 
                   - 
                 
                  
                 point 
                  
                 
                   : 
                 
               
               
                 Gross 
                  
                 
                     
                 
                  
                 Improvement 
                  
                 
                   : 
                 
               
             
              
             
               
                 
                   
                     ( 
                     
                       X 
                       * 
                       Y 
                     
                     ) 
                   
                   * 
                   transferSize 
                 
                 
                   
                     1 
                     / 
                     Y 
                   
                    
                   
                       
                   
                    
                   network 
                    
                   
                       
                   
                    
                   usage 
                    
                   
                       
                   
                    
                   with 
                    
                   
                       
                   
                    
                   multicast 
                 
               
               . 
             
           
         
       
     
         [0045]    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&#39;s, and use the multicast protocol to resend the missing packets. 
         [0046]    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. 
         [0047]    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. 
         [0048]    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. 
         [0049]    The system includes technology necessary to determine if a package&#39;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&#39;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. 
         [0050]    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: 
         [0051]    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. 
         [0052]    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. 
         [0053]    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. 
         [0054]    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. 
         [0055]    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&#39;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. 
         [0056]      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. 
         [0057]    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. 
         [0058]    Download Driver  207   
         [0059]    The download driver is installed when the EGM system is started. It&#39;s primary functions are to: 
         [0060]    1—Initialize package and control information as stored on the compact flash. 
         [0061]    2—Process commands to add packages and install rules from the Download Control  206 . 
         [0062]    3—Supply the Download Control  206  with list and status information and download and install events. 
         [0063]    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. 
         [0064]    5—Update package the status and error conditions of packages and install rules and pass them back to the Download Control Process  206 . 
         [0065]    Download Control Thread  206   
         [0066]    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&#39;s primary tasks are: 
         [0067]    1—Receives download commands 
         [0068]    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 . 
         [0069]    3—Receive download and install status from the driver and log in the appropriate log files on the EGM  106 . 
         [0070]    4—Supply the log information and package, install rule and module lists to the System Management Point  105  when requested. 
         [0071]    Download Receiver Process  208   
         [0072]    The Download Receiver Process  208  is responsible for communications between the EGM  106  and the Software Distribution Point  104 . It&#39;s primary functions are: 
         [0073]    1—Receive add package requests from the Download Driver  207 . 
         [0074]    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 . 
         [0075]    3—Open a multicast communications port specified by the Software Distribution Point  104  and receive the requested package in multiple packet format. 
         [0076]    4—Assemble the packets of the package into a single file. 
         [0077]    5—Request any missed or missing packets be resent. 
         [0078]    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. 
         [0079]    7—Send back status and error information of the package receive process to the Download Control Process  206  via the Download Driver  207 . 
         [0080]    Download Package Installer Process  209   
         [0081]    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: 
         [0082]    1—Parse the set install rules to determine how to process the package. 
         [0083]    2—Disable the EGM  106  based on the instructions in the set install rule command. 
         [0084]    3—Install the package using the command file sent as part of the download package. 
         [0085]    4—Clear NVRAM as instructed by the install rules. 
         [0086]    5—Reboot the EGM  106  as instructed by the set install rules. 
         [0087]    6—Pass back status and error information via the Download Driver  207 . 
         [0088]    EGM Initialization 
         [0089]      FIG. 3  illustrates an overview of EGM start-up 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 . 
         [0090]    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. 
         [0091]    Download Driver 
         [0092]    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. 
         [0093]    /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: 
         [0094]    1—Allocate the download buffer used to store Download Class messages. (e.g. the G2S or other protocol) 
         [0095]    2—Register the download support as a Linux kernel device. 
         [0096]    3—Initialize the read queues for the processes that communicate with the driver. 
         [0097]    4—Initialize the storage area for package and set install rules that may be received. 
         [0098]    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: 
         [0099]    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.       
 
         [0102]      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. 
         [0103]    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. 
         [0104]    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 . 
         [0105]    addPackage Processing Logic 
         [0106]    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&#39;s driver read queue and the Download control driver&#39;s read queue and post the read semaphores if a read is outstanding. 
         [0107]    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. 
         [0108]    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 . 
         [0109]    Download Control Process addPackage Logic 
         [0110]    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. 
         [0111]    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. 
         [0112]    Download Receiver addPackage 
         [0113]    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 . 
         [0114]    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 . 
         [0115]    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. 
         [0116]      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 . 
         [0117]    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 . 
         [0118]    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 . 
         [0119]    deletePackage 
         [0120]    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 . 
         [0121]    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 . 
         [0122]    setInstallRule 
         [0123]    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. 
         [0124]    Download Installer Process—setInstallRule 
         [0125]    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. 
         [0126]    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 . 
         [0127]    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 . 
         [0128]    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. 
         [0129]    At step  1016  determine if the prerequisites are found in the installed modules. If the prerequisite isn&#39;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&#39;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 . 
         [0130]    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 . 
         [0131]    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. 
         [0132]    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 . Otherwise 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 . 
         [0133]    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 initiation is true at step  1112 . If not, determine if initiate none is true at step  1113 . If not determine if initiate operator is true at step  1114 . If not, error exit at step  1116 . Otherwise display waiting for initiate install at  1115 . 
         [0134]    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 . 
         [0135]    Package Installation—Installing the package contents 
         [0136]    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. 
         [0137]    The package downloaded is made up of at least three distinct parts. 
         [0138]    1—A header which contains the following information: 
         [0139]    i. The module names, descriptions and release version number. 
         [0140]    ii. The files and their offsets into the data package. 
         [0141]    iii. The name of the command procedure used to install the package and its offset into the data package. 
         [0142]    2—A SHA-1 validation string used to validate the data portion of the package. 
         [0143]    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. 
         [0144]      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 . 
         [0145]    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 . Otherwise set NVRAM clear conditions and delete install rules at step  1215 , and reboot the EGM at step  1216 . 
         [0146]    Alternate Package Install Handling 
         [0147]    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 into setScript commands for processing by the Download Installed. Also, the getScriptList and GetScriptStatus commands will map the getInstallRuleStatus and getInstallRuleList commands. 
         [0148]    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.       
 
         [0150]    This alternate embodiment is based on the following commands: 
         [0151]    1. A separate thread is used to issue reads to the download driver to receive setScript, deleteScript, authorizeScript commands. 
         [0152]    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&#39;s setScript command, it is rejected and an error event sent back to the server sending the authorization command. 
         [0153]    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. 
         [0154]    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       
 
         [0167]    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.       
 
         [0171]    Processing setScript Command 
         [0172]    When a setScript command enters the processing state, the order in which things occur are: 
         [0173]    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. 
         [0174]    2) Check storage dependencies taking into account that a package within the setScript command could be removing a module and therefore freeing up storage. 
         [0175]    3) Wait for install time frame. 
         [0176]    4) Disable EGM according to disableType attribute. 
         [0177]    5) Initiate processing of packages according to the initiateType command. 
         [0178]    6) Process authorizations. There can be multiple authorizations required. This includes a local operator authorization as well as multiple host authorizations. 
         [0179]    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. 
         [0180]    8) Whenever a package is removed, its related file validation manifest must also be removed from the system 
         [0181]    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. 
         [0182]    10) Based on jurisdiction requirements and state specified in the setScript command, delete the downloaded package. 
         [0183]    Installing and Updating Module Requirements 
         [0184]    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. 
         [0185]    1) Reset the partition access permissions to allow writing to the partitions. 
         [0186]    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. 
         [0187]    3) Apply the changes to the production environment. 
         [0188]    4) Insure that the boot.id file is set to boot the production environment and that a backup environment exists. 
         [0189]    5) Reboot the system according to jurisdictional requirements. 
         [0190]    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. 
         [0191]    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&#39;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. 
         [0192]    Installation Dependencies 
         [0193]    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.       
 
         [0197]    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.       
 
         [0202]    setScript Command Structure 
         [0203]    This section describes the setScript command structure that will be passed into the download install logic. 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 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. 
               
               
                   
               
             
          
         
       
     
         [0204]    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. 
         [0205]    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. 
         [0206]    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. 
         [0207]    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. 
         [0208]    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. 
         [0209]    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. 
         [0210]    Download Package Description 
         [0211]    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. 
         [0212]    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       
 
         [0217]    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. 
         [0218]    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. 
         [0219]    The contents of the package header can be seen in the following table: 
         [0000]    
       
         
               
               
               
             
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 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 
               
               
                   
                   
               
             
          
         
       
     
         [0220]    The package header is the first thing contained with a package and is a fixed length in size. 
         [0221]    The package data compression types are: 
         [0000]    
       
         
               
               
             
           
               
                   
               
               
                 Compression 
                 Description 
               
               
                   
               
             
             
               
                 1 
                 Uncompressed data 
               
               
                 2 
                 Compressed data using gzip protocol 
               
               
                 3 
                 Compressed data using bzip2 protocol 
               
               
                   
               
             
          
         
       
     
         [0222]    The following package type are been identified: 
         [0000]    
       
         
               
               
             
           
               
                   
               
               
                 Package Type ID 
                 Description 
               
               
                   
               
             
             
               
                 1 
                 Download Package is download from a package 
               
               
                   
                 distribution server 
               
               
                 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. 
               
               
                   
               
             
          
         
       
     
         [0223]    Module Sections 
         [0224]    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. 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 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. 
               
               
                   
               
             
          
         
       
     
         [0225]    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. 
         [0226]    The hardware, module, and storage dependency counts specify how many of each type of dependency is included in the package. 
         [0227]    The type is used to identify the type of module. The following table identifiers the module type that are used: 
         [0000]    
       
         
               
               
             
           
               
                   
               
               
                 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. 
               
               
                   
               
             
          
         
       
     
         [0228]    Package File Definitions 
         [0229]    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. 
         [0000]    
       
         
               
               
             
           
               
                   
                   
               
               
                   
                 Package Header 
               
               
                   
                   
               
             
             
               
                   
                 Module 1 
               
               
                   
                 File 1 
               
               
                   
                 File 2 
               
               
                   
                 Module 2 
               
               
                   
                 File 3 
               
               
                   
                 File 4 
               
               
                   
                   
               
             
          
         
       
     
         [0230]    All file definitions use the same control structure. 
         [0000]    
       
         
               
               
               
               
             
           
               
                   
                   
               
               
                   
                 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. 
               
               
                   
                   
               
             
          
         
       
     
         [0231]    The following describes the type of files that can be included: 
         [0232]    The manifest file section data area comprises the following 3 fields: 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 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 
               
               
                   
               
             
          
         
       
     
         [0233]    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 OS1 or games subdirectory. 
         [0234]    Tar File—(Package ID Type: 4) 
         [0235]    Updates to installed modules as well as game installations will be in the form of a tar file. 
         [0236]    Partition Image File—(Package ID Type: 5) 
         [0237]    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. 
         [0238]    Device Image File—(Package ID Type: 6) 
         [0239]    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. 
         [0240]    Dependency Sections 
         [0241]    Hardware Dependencies (Package ID Type: 7) 
         [0242]    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). 
         [0243]    Module Dependencies (Package ID Type: 8) 
         [0244]    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). 
         [0245]    Storage Dependency (Package ID Type: 9) 
         [0246]    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. 
         [0247]    Package Record Identifiers 
         [0248]    This describes the currently assigned id values for download package sections. 
         [0000]    
       
         
               
               
               
             
           
               
                   
               
               
                 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 
               
               
                 Prerequisite 
                   
                 with previous module definition. 
               
               
                 Module 
                 8 
                 Module Prerequisite/dependency associated 
               
               
                 Prerequisite 
                   
                 with previous module definition. 
               
               
                 Storage Dependency 
                 9 
                 Storage Prerequisite dependency associated 
               
               
                   
                   
                 with previous module definition.