Legacy Game Download and Configuration

FIELD OF THE INVENTION

The present invention relates to creating and downloading game packages, and in particular for creating and downloading game packages for legacy games.

BACKGROUND OF THE INVENTION

Advances in the design and implementation of gaming machines sometimes prevent older games from operating in newer gaming machines. New hardware and/or software is developed for gaming machines to provide new and/or improved game play experiences for players, and capabilities for owners and operators. For example, operating systems controlling the operation of the processor or processors in gaming machines are updated to provide new such capabilities. New games may then be designed and implemented to take advantage of these new capabilities. However, in some cases, older games, termed legacy games in the present application, which were not designed to use the new capabilities, are unable to take advantage of them. In such a situation, a legacy game may need to be reprogrammed to take advantage of the new operating system.

More specifically, an improved operating system, and cooperating new slot machine game program, may permit configuration options of the game to be dynamically and/or remotely changed without requiring a reinstallation of the game. However, in a legacy slot machine game, configuration data, such as maximum lines, maximum wager per line, and so forth, is set during installation of the game and is unchangeable without uninstalling (deleting) and then reinstalling the game in the gaming machine. Thus, legacy games are currently not able to cooperate with the new operating system to provide dynamic configuration option change.

Often, however, the legacy games are still popular and viable, and require no changes in game play operation. In addition, in most jurisdictions, game software must be submitted to and approved by regulatory bodies, which then require that the approved software be cryptographically signed to prevent modification. If a new game program is implemented, recreating the legacy game, which operates with the new operating system, it must be submitted to the regulatory bodies, which must analyze and approve it. This typically takes time and money. For a game not requiring any changes to the game play this is a waste of time and money.

It is, therefore, desirable to permit a legacy game to be able to be installed and operated in a gaming machine including new and/or improved features for which that game was not designed; more specifically a new operating system including features with which the legacy game was not designed to cooperate. Such a system will permit the use of already existing and approved games on gaming machines using new hardware and/or software. This will permit continued use of popular and viable legacy games without requiring redesign, reimplementation and resubmission to regulatory bodies of reprogrammed legacy games.

BRIEF DESCRIPTION OF THE INVENTION

In accordance with principles of the present invention, a system includes a download configuration host server coupled to an electronic gaming machine which, in turn, comprises an operating system. A method for configuring a legacy game application on the electronic gaming machine comprises the following steps. A downloadable package comprising a game image of the legacy game and a game descriptor file is generated. The downloadable package is communicated from the download configuration host server to the electronic gaming machine. The legacy game image is installed on the electronic gaming machine. The installed legacy game is configured by the operating system. The operating system simulates configuration of the installed legacy game by an operator in response to data in the game descriptor file. The installed legacy game is then enabled for game play.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a screen display illustrating a game setup menu for a legacy game;

FIG. 2 is a flow diagram illustrating the process for creating a download package for legacy games according to principles of the present invention;

FIG. 3 is a content diagram illustrating the contents of a downloadable package for a legacy game according to principles of the present invention;

FIG. 4 is a sequence diagram illustrating the process of downloading a downloadable package as illustrated in FIG. 3 to a gaming machine according to principles of the present invention;

FIG. 5 is a sequence diagram illustrating the process of installing a legacy game contained in a downloadable package as illustrated in FIG. 3 in a gaming machine according to principles of the present invention;

FIG. 6 is a sequence diagram illustrating the process of performing initial configuration of a legacy game previously installed in a gaming machine from a downloadable package as illustrated in FIG. 3 according to principles of the present invention;

FIG. 7 is a sequence diagram illustrating the process of reconfiguring a legacy game previously installed in a gaming machine from a downloadable package as illustrated in FIG. 3 according to principles of the present invention;

FIG. 8
a and b are screen displays illustrating a button panel displayed by a legacy game previously installed in a gaming machine from a downloadable package as illustrated in FIG. 3 in a first and second configuration, respectively, as reconfigured according to principles of the present invention

FIG. 9 is a diagram illustrating the format of a file name for archiving game play history for a legacy game according to principles of the present invention;

FIG. 10 is a screen display illustrating the location of icons on a game play history selection screen on a legacy game according to principles of the present invention;

FIG. 11 is a screen display illustrating images representing the contents of a game play history file according to principles of the present invention;

FIG. 12 is a screen display illustrating images representing the features active in main screen in a game play history file according to principles of the present invention;

FIG. 13 is a screen display illustrating images representing the features active in an upper screen in a game play history file according to principles of the present invention;

FIG. 14 is a screen display illustrating the location of icons on an operating system status screen according to principles of the present invention;

FIG. 15 is a screen display illustrating the location of buttons on an operating system archive selection screen according to principles of the present invention;

FIG. 16 is a screen display illustrating security accounting information according to principles of the present invention; and

FIG. 17 and FIG. 18 combined is a listing of a game descriptor file which is part of a downloadable package according to principles of the present invention.

DETAILED DESCRIPTION

It is desirable to create downloadable packages for legacy games which permit those legacy games to operate with a later, more advanced, operating systems and/or game download and configuration systems. Such download and configuration systems permit configuration changes to be made to electronic gaming machines (EGMs) on a casino floor in real time. Previously approved legacy game image files are used to create downloadable packages.

In general, a game play system, e.g. in a casino, includes a download configuration host server coupled to an electronic gaming machine which, in turn, comprises an operating system. A method for configuring a legacy game application on the electronic gaming machine comprises the following steps. A downloadable package comprising a game image of the legacy game and a game descriptor file is generated. The downloadable package is communicated from the download configuration host server to the electronic gaming machine. The legacy game image is installed on the electronic gaming machine. The installed legacy game is configured by the operating system. The operating system simulates configuration of the installed legacy game by an operator in response to data in the game descriptor file. The installed legacy game is then enabled for game play.

In the present application, the term ‘game image file’ refers to a file which includes information defining a game which has been approved by regulatory agencies and has been cryptographically signed to prevent alteration. A game image file for a legacy game is combined with a game option xml file called “Game Descriptor File” (GDF) to create a file called a “Download Package”.

Data in the GDF permits the operating system to interact with the legacy game. Repacking the legacy game image into a downloadable package file with a GDF gives the ability to release legacy popular game titles with a new and/or improved download and configuration host to provide game content that is downloadable and remotely configurable from a backend system. The present application describes creating a downloadable package from a previously approved game image, installing a game package in an EGM, and remotely configuring game options.

As is well known, electronic gaming machines include one or more computers, each including a processor, memory, and input/output devices, coupled together via a computer bus, and operating under control of one or more executable programs. The memory is a combination of read-write memory (RAM), read-only memory (ROM), and mass storage devices, such as disk drives; optical drives such as CDs or DVDs; semiconductor mass storage; tape drives; and so forth. Output devices include display screens on which images are displayed representing game play. Other output devices include lights and sound producing devices such as speakers, buzzers, bells, etc. Input devices include buttons for receiving instruction from a player related to game play. Other input devices include coin receivers, bill receivers, and/or ticket receivers for receiving wagers from players. Another input device is one or more touch screens, which may be placed atop one or more of the output devices, or atop a player panel, for receiving instruction from a player related to game play. The computer may also include communication input/output devices such as network interfaces which can receive data from a network and transmit data to the network, or wireless communication devices.

An executable program, when executed by the processor, receives input instructions from the player through the input devices, performs calculations in the processor according to the approved game executable program, and generates output displays and sounds representing the results of game play on the output devices. A control executable program, generally termed an operating system, controls access to the computer hardware from other executable programs, such as game programs, and other generally available functions. Other systems in a gaming system, such as download configuration host servers, progressive servers, administration servers, accounting servers, and so forth, also include one or more computers which are constructed and operated as described just above.

Typically, a legacy game requires its options to be configured during initial installation on an EGM before the game to become enabled and playable. The value of these options are typically displayed by the legacy game on an operator menu screen. FIG. 1 is a screen display 100 illustrating an example of such a menu screen entitled “Game Setup”. As illustrated in FIG. 1, typical options which may be configured include “Number of Paylines” 102, “Max Bet per Line” 104, “Line Button Layout” 106, and so forth.” Other options, not shown to simplify the figure, may include “Max Lines”, “Double up” and “Video Output”, etc. The game specific menu screen 100 is displayed and controlled by the legacy game software directly. In legacy game machines, these options are accessed by an operator by touching the screen at the location of the button desired to operate.

For the new operating system (OS) to support download and configuration of legacy games from e.g. a remote host, the OS needs information related to the display of the option selectors on the game setup display screens such as screen 100. This permits access to those game setup display screens to change of these options as desired. The Game Descriptor File (GDF) is an xml file that is created for the legacy game and contains information related to the display of game options on the Game Setup menu. FIG. 17 and FIG. 18 display a listing of a sample Game Descriptor File, and will be described in more detail below.

The Game Descriptor File contains co-ordinates (x, y) of the buttons and/or other widgets shown in the Game Setup Menu 100. The co-ordinates of a button relate to the location of that button on the game setup display. Typically, this is measured from the left edge for the x co-ordinate, and from the top edge for the y co-ordinate. The measurements are also typically in pixels, though other measurement units may be used instead. The Game Descriptor File may also contain other data related to the buttons and/or widgets such as name, identifiers, etc.

If, for example, the download and configuration system desires to change the “Max Bet Per Line” 104 option value from 10 (108) to 20 (110), the OS retrieves the location of “Max Bet Per Line” 20 button 110 from the GDF file. The OS then simulates a touch on the game setup display screen 100 at that location. This activates the “Max Bet Per Line” 20 button 110, as if it were being manually touched by an operator at the EGM. This configuration activity is hidden from players by displaying a splash screen over the Game Setup screen 100 which includes a status message indicating that option changes are being applied.

Legacy games were developed, approved, and released prior to the development of new OSs and/or new download and configuration systems coupled between the OS and the slot machine game application. The new OS and/or new download and configuration system allow dynamic access to, and remote configuration of, game options. The download and configuration system provides the capability for the game to register its configuration options to the OS at runtime. The OS compiles a list of options for the legacy game and sends them to the download and configuration system through a communication link. In one embodiment, this communication link may use the game-to-system (G2S) protocol. The G2S communication standard protocol is promulgated by the Gaming Standards Association (GSA). More specifically, in such an embodiment, the option configuration device (OptionConfig), which is part of the G2S protocol, may be used to configure, or reconfigure options in a gaming machine.

Because a legacy game is not designed or implemented to cooperate with a download and configuration system, or to communicate using the G2S communication protocol, the legacy game, by itself, cannot be used with such a system. To bridge this gap between the legacy game and the OS, Game Descriptor File (GDF), with the appropriate options for each legacy game, is generated and included within a download package. The legacy game image (i.e. the data approved by regulatory bodies and cryptographically signed) is combined with the GDF file to create a downloadable package. There are no changes made to the legacy game image in the downloadable package. The legacy game image is reproduced exactly and compressed to reduce the size of download package file. Because no changes are made to the legacy game image, that game image may legitimately be used to control the EGM.

Referring to FIG. 2, a build package tool 202 receives an approved legacy game image 204 and the game descriptor file 206 as input data. The build package tool 202 generates an unsigned downloadable package file 208 as output data. This download package is then cryptographically signed to prevent undetected modification to produce a signed downloadable package file 210. The signed downloadable package file 210 is downloaded to, and installed on, an EGM to permit the legacy game represented by the approved game image 204 to be played on the EGM.

Referring to FIG. 3, a downloadable package file 302 includes data 304 representing a package header. The package header 304 includes data representing a package description, hash codes for the downloadable package and other portions of the downloadable package. These hash codes are used to perform package verification of the package in a known manner. The downloadable package file also includes data representing the approved legacy game image 306 and the game descriptor file 308 associated with the legacy game image 306.

After the downloadable package file 302 is created and signed, it is communicated to a Software Download and Distribution Point (SDDP) server where it is available to be downloaded to gaming machines. Creating and scheduling the download and install tasks are done through a user interface to a download management host.

Referring to FIG. 4, various request, reply, transfer, command, status, and acknowledgement messages are exchanged among the download host system 402, the SDDP server 406 and the EGM 404 to implement the legacy game package download, verification and operation, as described in detail below. When a download task is scheduled in the download host system 402, it initiates the download 412 by sending a request 414 to add a download package (i.e. a legacy game) to the EGM 404, i.e. to transfer a specific game package from the SDDP server 406 to the EGM 404. The EGM 404 starts downloading the file 416 from the SDDP server 406. In one embodiment, this download may be performed through secure http (https) connection. Other protocols and connections may also be used. One skilled in the art understands how to select and implement a transfer protocol.

After the game package is downloaded 424, the EGM 404 performs a validation 418 of the package received from the SDDP server 406 to ensure that the download package is downloaded to the EGM 404 completely and without errors. In the illustrated embodiment, this is done using the known technique of calculating a result of a one-way function, e.g. a cryptographic hash function, applied to the downloaded file and comparing it to the expected value of the one-way function found in the package header 304 (of FIG. 3). If they are the same, then the file was downloaded in full and accurately.

The download host system 402 then performs an independent verification 420 of the download package on the SDDP server 406. In the illustrated embodiment, this verification uses the known technique of generating a salt value (consisting of a predetermined number of random bits), combining the salt with the contents of the download package, then calculating a result of applying a one-way function, e.g. a cryptographic hash function, to the combination. The value of the resulting one-way function of the combination is kept.

The download host system 402 then directs the EGM 404 to perform a similar verification 422 of the file downloaded to the EGM 404. The download host system 402 transmits the salt to the EGM 404 so the same salt is used by the EGM 404 to verify the contents of the download package at the EGM 404 as was used by the download host system 402 to verify the contents of the download package at the SDDP server 406. When the EGM 404 has calculated the result of the hash function on the combination of the salt received from the download host system 402 and the download package received from the SDDP server, that result is transmitted back to the download host system. The download host system compares the result received from the EGM 404 with the result previously calculated at the download host system 402. If the two results are equal, then the contents of the download package at the EGM are considered verified 428.

In a legacy game package download process, the EGM stores the legacy game image, i.e. the approved signed part, 306 (of FIG. 3) in the game partition of the hard-disk drive (not shown) in the EGM. The game descriptor file, i.e. the xml file that describes game options 308 is stored in the critical-data partition, e.g. /critical_data/descriptors of the hard-disk in the EGM 504. The installation process involves retrieving the legacy game image from the hard-disk drive and loading it into the memory of the EGM in anticipation of being executed.

Referring to FIG. 5, after the game package is downloaded, the download host server 502 will send an install command 510 to the EGM 504 to install the package. Based on jurisdictional requirements of game idle time and zero credit conditions and so forth, EGM 504 will start installation of the package when those requirements are satisfied. When the conditions are met, the download host server 502 places the EGM 504 into the disabled mode 512, 513.

Before installation of the downloaded package, EGM 504 provides a snapshot 514, 515 of meter data related to game play history, as described below in FIG. 9, FIG. 10, FIG. 11, FIG. 12, and FIG. 13 and the associated written description below. The EGM 504 also requests 516, 517 a package of data related to accounting and/or transaction history, as described in FIG. 14, FIG. 15, and FIG. 16 and the associated written description below. The data is uploaded to the SDDP server 506, and archived in relatively long term storage. It may be used to resolve player disputes after the legacy game is installed in the EGM 504. The files associated with the downloaded legacy game are then retrieved from the hard disk drive and installed 518 into the memory of the EGM 504.

After the download of the legacy game and the retrieval and storage of history, meter and transaction data, and in preparation for the initiation of operation of the downloaded legacy game, the EGM 504 automatically clears 518 the contents of a non-volatile memory device (not shown) in the EGM 504 erasing previously stored critical information such as accounting meters, game history, and logs of vouchers, events, progressive contributions and wins, bills-in, etc. This critical information is stored 522 locally in the EGM 504 in a critical-data partition of the hard disk drive and retained to meet jurisdictional requirements.

To activate the newly downloaded legacy game, the EGM 504 performs an automatic processor reset. During the reboot process, the OS locates the game descriptor file (FIG. 3, 308) associated with the legacy game to be installed on the hard disk drive, and reads all the options from the xml file. Because data representing the screens presenting the configuration data, and the locations of buttons and/or other widgets on those screens is specified in the game descriptor file 308, the EGM 504 gets access to the game options. In one embodiment, this may be done through use of the G2S OptionConfig device, as is known. Other methods for performing this function exist, and one skilled in the art understands how to select, and to design and implement such methods, as appropriate.

FIG. 6 illustrates initially configuring an EGM 604. Referring to FIG. 6, the download host server 602 communicates with the EGM 604 to remotely configure the EGM 604 options. In one embodiment, the download host server 602 may use the G2S optionConfig device to configure the EGM 604. However, any protocol capable of remotely configuring the EGM 604 options may be used. One skilled in the art knows how to select, and to design and implement such a configuration protocol, as appropriate.

Some of the options that are expected to be configured initially from the download host server 602 include: device setup, credit setup, game combos, etc. Other options that are expected to be configured include game options such as: number of lines and bet per line, minimum bet, double up and any other game specific options. The minimum bet option is expected to change more frequently than other options in order to perform yield management. After configuration of the legacy game options, the EGM 604 is enabled and the legacy game, or game combos, are made available to a player.

When the EGM 604 performs a reset, or reboot, it clears 610 the non-volatile RAM (NVRAM), as described above. The EGM 604 then connects 612 to the download configuration host server 602. Operation of the EGM 604 is suspended 614 giving the operator the opportunity to configure the EGM 604. Once connected, the download configuration host server 602 sends an option change message 616 to the EGM 604. This option change message 616 contains desired values for all the required options. The EGM updates the specified options, and informs the download configuration host server 602 when the configuration changes are applied 618. When the options received from the download configuration host server 602 have been applied and the EGM is ready to be playable 620, the EGM 604 sends a message 622, informing the download configuration host server 602.

As described above, it is desirable to support configuration and reconfiguration of legacy game options remotely and/or in real-time. The legacy game 708, itself, is not designed or implemented in a manner to allow such reconfiguration. However, the new OS 706 in the new EGM 704 is designed and implemented to handle configuration changes in legacy games 708.

FIG. 7 illustrates reconfiguring an operative EGM 704; that is, reconfiguring the EGM 704 after it had been configured and enabled 710 to allow play of a legacy game. Referring to FIG. 7, after initial configuration (FIG. 6), the download configuration server 702 may be controlled to change one or more game options. In the embodiment illustrated in FIG. 7, the download configuration host server 702 is controlled to change one option: the bet-per-line option from 5 to 10 credits 720 for the legacy game 708 in the EGM 704. As described above, the legacy game 708 is designed to set options only on installation, and not during operation. Consequently, to change options, the legacy game must be uninstalled and reinstalled, and the new options set at reinstallation time.

The download and configuration host 702 sends a bet-per-line change request 722 to the EGM 704. The OS 706 in the EGM 704 receives the request and detects that this option is meant for a legacy game 708 and, thus, is settable only at installation. In order to apply this option change request, the legacy game 708 is uninstalled and reinstalled. During this process, the legacy game 708 persistent data, e.g. NVRAM, is cleared, then the previous options are set again, along with the new value for the minimum bet option. Changes to configuration options are made during “Idle” conditions which meet jurisdictional and operational requirements. To verify this condition, the OS checks if the EGM 704 is in the “Game_Idle” state and if so, proceeds doing the following steps:

- 1. Before terminating the current installation of the legacy game 708, the OS 706 in the EGM 704 stores 725 current values of game play history logs, and accounting information in archive storage to preserve the current critical information needed to resolve any player disputes. This is described in more detail in FIG. 9, FIG. 10, FIG. 11, FIG. 12, FIG. 13, FIG. 14, FIG. 15, FIG. 16 and the associated written description, below.
- 2. Terminates 724 the current legacy game 708.
- 3. Removes 726 all the persistent data storage generated and used by the legacy game 708.
- 4. Restarts 727 the same legacy game 708.
- 5. After the game boots completely 728, the OS 706 in the EGM 704 apply 729 all the game options for the legacy game 708, including the new bet-per-line option value, as described below.
- 6. The OS 706 in the EGM 704 reports 730 the proper option change status and event to the download and configuration host 702
- 7. Enables 731, 732 the legacy game 708 after the post configuration idle period set by jurisdiction or operational requirements.

Entries in the game descriptor file (FIG. 3, 308) allow configuration of the options of the legacy game, as described below. More specifically, an entry in the game descriptor file 308 related to the minimum bet option allows the download and configuration host server 702 to specify this option and the OS 706 to change this option in the legacy game 708. The minimum bet option is an integer type option with a maximum range defined in credits. Changing the value of this option in the EGM 704 may require that certain “Number of Lines” or “Bet per Lines” buttons on the button deck panel be disabled and force the player to bet a different minimum wager per game cycle.

For example, referring to FIG. 8a, if the initial configuration sets the minimum bet to $0.01, all the number-of-lines and bet-per-line buttons are enabled. Referring now to FIG. 8b, if an operator at the download and configuration host changes the value of the minimum bet option from $0.01 to $0.05, the OS 706 disables the four lowest bet-per-line buttons, based on an algorithm in the OS 706, so that the bet-per-line buttons displayed and enabled are the only choices players can select. In the algorithm in the OS 706, the game display defaults to maximum number of lines in this case. As illustrated in FIG. 8b, the 1-4 line buttons 802 are disabled and blank icons 804 are displayed instead.

During the course of game play (i.e. after the legacy game 708 starts and before it ends) the icon buttons 804 may be enabled and displayed e.g. based on a need for a game feature or bonus round. For example, if the legacy game 708 has a feature where the player needs to make a selection of 5 cards, then the number of lines buttons 802 (e.g. the four number of lines buttons 802) become enabled again for the player to make a selection. After the end of the game feature or bonus round state, the number of lines buttons 802 return to the disabled state 804.

As described above, before installation of a downloaded game or a game configuration change, the game play history for the current game is captured to one or more video files. One frame of the file history is stored in a portion of the video file corresponding to a video frame. In one embodiment, the history files are stored as delta compressed .f32 format video in the /critical_data/gamehistory partition in the hard disk drive (not shown) on the EGM. However, other video file formats may also be used to store the game history. One skilled in the art understands how to select a video file format and to store the game history frames as corresponding video frames in the format of the selected video file.

These files are named as illustrated in FIG. 9. The display ID is 0 for a primary display, and 1 for a secondary display, and so forth; i.e. further digits may be assigned to represent other displays. The data/time stamp represents the date and time of creation of the file. The file extension, “f32” indicates that the file is an .f32 movie so appropriate programs may be invoked to properly read and process it.

The process of capturing the game history screens is similar to that of setting game options of a legacy game by the OS. That is, touch coordinates for the screen buttons and/or other widgets operative to display screens containing game history are stored in the game descriptor file (FIG. 3, 308). These coordinates are used by the OS to simulate navigating to the game history screens displayed by the legacy game. When a history item is displayed, frame-by-frame screen captures are performed and written to the named .f32 file. The “History” section of the Game Descriptor File describes the information necessary for performing the history navigation and recoding process.

In general, access to the display screens available for saving the game play history and accounting history of the EGM begin with screen 1000, illustrated in FIG. 10. On screen 1000, activating the “Archives” button 1006 displays a different screen, e.g. screen 1100 as illustrated in FIG. 11. Screen 1100 is typical of those screens containing history information. On screen 1100, a base game screen 1101 is shown in the foreground while a top screen 1003 is shown layered in the background. The buttons required to navigate and view the archived history are displayed on screen 1100 as follows. A Next button 1102 is activated to display to the next game history record. The Next button 1102 is grayed out, and inactivated, if no more game history records exist past the current one. A Previous button 1104 is activated to display the previous game history record. The Previous button 1104 is grayed out, and inactivated, if no more game history records exist prior to the current one. A Swap button 1006 is activated to swap between displaying the base game screen 1101 in the foreground and displaying the top screen 1103 in the foreground, if both are available. The Swap button 1106 is grayed out if no top screen history was captured for this game. A Features button 1108 is activated to show the current game's feature history if it exists. The Features button 1108 is grayed out if no features were played for this game history record. An Exit button 1110 is activated to close the Archived Game History screen 1100 and return to the screen 1000 of FIG. 10.

In automatic operation under control of the OS 706 (FIG. 7), the OS 706 simulates operation of the Archives button 1006 (FIG. 10), which controls the legacy game to display the archived game history screen 1100, illustrated in FIG. 11. The OS 706 captures data representing the image of the screen, then generates data representing a video frame containing the captured image, and appends the generated video frame to the video file designated as illustrated in FIG. 9. If a top screen 1103 exists, the OS 706 simulates activation of the swap button 1106, displaying the top screen in the foreground. Data representing the image of the displayed top frame is captured and appended to the video file in the same manner. The OS 706 then simulates activation of the Next button 1102, causing the next archived screen image, or images, to be displayed. These screen images are appended to the video file as just described. This continues until there are no further archived game play history screens to display, signified by the Next button 1102 being made inactive.

In order to save the features history of the legacy game, the OS 706 (of FIG. 7) then simulates activating the features button 1108 (of FIG. 11). This controls the EGM to display a features history screen 1200, illustrated in FIG. 12, including a main screen 1204 in the foreground and another screen 1206 layered behind the main screen 1204. The OS 706 captures the displayed screen 1204 and appends it to the video file. In some games the top screen 1206 is used to display additional game history information. In such cases, the OS 706 displays screen 1206 by simulating activation of the Swap button 1214. For example, FIG. 13 illustrates a display of the top screen 1306 of feature game history. The OS 706 captures screen 1306 and appends it to the video file. The OS 706 then advances to the next screen in the history by simulating activation of the Next button 1208. Subsequent feature history screens are captured and appended to the video file as just described. This continues until there are no more feature history screens. At this point the OS 706 simulates activation of the Exit button 1110, closing the Feature History screen 1100 and reopening the screen of FIG. 10.

The OS 706 then simulates activation of the current history button 1004 (of FIG. 10) which displays a current history screen similar to the archived history screen 1100 of FIG. 11 displaying the current game history. The same procedure of repeated screen capturing, appending to the video file, and swapping is performed to append frames representing the current game play history, and game feature history, to the video file. When there are no further current game play history screens to display, the Exit button is activated by the OS 706 closing the Current Game History screen and reopening the screen of FIG. 10.

After storing the game history information, and before installation of a downloaded legacy game, OS information is also captured to archive files, which in the illustrated embodiment are also video files. The following OS information is archived:

- Accounting data (i.e. machine, bill, game, protocol, security, and error Accounting);
- History data (i.e. event, transaction, card, and progressive history); and
- Version information.

Screens representing OS information are captured by the same technique described above: the OS 706 (FIG. 7) simulates activation of appropriate on-screen buttons and/or widgets, captures screen images and appends those screen images to a portion of a video file representing a frame. Referring again to FIG. 10, current OS information is accessed the OS 706 simulating activation of the “Accounting” button 1008 for the accounting data, and “History” button 1010 for the history data.

When the OS 706 (FIG. 7) simulates activation of the Accounting Button 1008 (FIG. 10), a screen 1400, illustrated in FIG. 14, is displayed. Archived OS information is then accessed by the OS 706 simulating activation of the “Archives” button 1402. In response to activating the “Archives” button 1402, a screen 1500, illustrated in FIG. 15, is displayed including a list box 1502. One of the items from the list box may be selected to view. For example, in order to display the accounting information, the OS 706 simulates activating the Security Accounting entry 1504. In response, a screen, as illustrated in FIG. 16, is displayed. This screen displays a portion of the accounting data. The OS 706 captures image data representing this screen and appends it to the video file, as described above. The OS 706 (FIG. 7) simulates activation of a Next button 1602. In response, the EGM is controlled to display the next screen of accounting information. This screen is captured and appended to the video format file. This is repeated until the next button 1602 is grayed out, indicating that no more accounting data exists past the current screen.

All information desired to be archived before installation of the legacy game is stored in this manner: simulating activation of appropriate on-screen buttons; capturing data representing desired screens; and appending the captured screens to a video format file.

Archived .f32 video files, containing game and OS data, are protected from unauthorized alteration. More specifically, a hash (e.g. SHA1) is calculated on the data in the .f32 file and is added to the game history log file(s) stored in /critical-data/Logs/partition of the hard disk drive (not shown) of the EGM. The game history log file(s) with the SHA1 hash is authenticated after power cycles or machine reboots. If any data changes in the f32 files or game history log itself, the EGM will fault and the RAM must be cleared to proceed.

FIG. 17 and FIG. 18, together, are a listing of an exemplary game descriptor file (308 of FIG. 3). Data in this file is used by the OS 706 (FIG. 7) to simulate activation of appropriate screen buttons, list entries, and/or other widgets. In general, when an operator activates an on-screen button, the operating system generates data representing the button activation. This data is stored in a construct sometimes called an event. The data in the event includes data representing the location touched, which button was activated, and so forth. The event data is supplied to different software routines which react to the received event by performing some processing. For example, pressing the Game Play History button 1002 (FIG. 10) generates an event which causes the legacy game software to display the game play history screen 1100 (FIG. 11) to be displayed. The OS 706 simulates activation of the Game Play History button 1002 by generating an event which contains the same data as an event which would have been generated by an operator activating the button. This event is then distributed to the rest of the system in the same manner as a normal, operator generated, event would be. The system then responds as if the Game Play History button 1002 had been activated by an operator.

The game descriptor file of FIG. 17 and FIG. 18, contains the information required by the OS 706 (FIG. 7) to generate the events which simulate activation of the required buttons, list entries, and/or other widgets. Referring specifically to FIG. 17, as may be seen, after identifying the descriptor type 1702 and part number 1704, the game descriptor file lists a series of features of the legacy game to be accessed by the OS. For example, “history” 1706 and “options” 1708. Within the history record 1706 are items 1710, 1712, 1714 and 1716, indicating button types and locations. More specifically, item 1710 describes a button having the type “enter”, text “feat1”, and screen location x=0.777187 and y=0.032564. When the OS 706 desires to activate this button, it assembles a button-press event using this data from the GDF, and passes that event to the legacy game, simulating activation of this button. Other items in the game descriptor file FIG. 17 and FIG. 18 provide required data to the OS 706 for it to simulate activation of the other buttons, list entries, etc. This data is used by the OS 706 to navigate through the legacy game menu screens as described above.

Legacy Game Download and Configuration

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

US Classifications

International Classifications

Abstract

Description

Claims

Provisional Applications (1)