US20140228110A1 - Authenticating files in wagering game machines - Google Patents

Abstract

Methods and apparatus for authenticating content in wagering game machines are described herein. In one embodiment, the computer-implemented method includes authenticating a first set of wagering game files stored on a storage device of a wagering game machine. The method can also include starting a wagering game on the wagering game machine if the authentication of the first set of wagering game files is successful. The method can also include authenticating, during the wagering game, a second set of wagering game files stored on the storage device of the wagering game machine, wherein the first set of wagering game files and the second set of wagering game files are mutually exclusive. The method can also include stopping the wagering game if the authentication of the second set of wagering game files is not successful.

Description

RELATED APPLICATIONS
• This patent application claims the priority benefit of U.S. Provisional Patent Application Ser. No. 60/735,509, filed Nov. 10, 2005 and entitled “AUTHENTICATING FILES IN WAGERING GAME MACHINES” (Attorney Reference No. 1842.220PRV) by inventors Steven M. Campbell et al., and of U.S. Provisional Patent Application Ser. No. 60/744,421, filed Apr. 7, 2006 and entitled “AUTHENTICATING FILES IN WAGERING GAME MACHINES” (Attorney Reference No. 1842.220PV2) by inventors Srinivyasa M. Adiraju et al.
LIMITED COPYRIGHT WAIVER
• A portion of the disclosure of this patent document contains material to which the claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by any person of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office file or records, but reserves all other rights whatsoever. Copyright 2005, 2006, WMS Gaming, Inc.
FIELD
• This invention relates generally to the field of wagering game machines and more particularly to the field of file authentication in wagering game machines.
BACKGROUND
• A wide variety of computerized wagering game machines are now available to casino operators and players. Computerized wagering game machines range from slot machines to games that are traditionally played live, such as poker, blackjack, roulette, etc. These computerized wagering game machines provide many benefits to game owners and players, including increased reliability over mechanical machines, greater game variety, improved sound and animation, and lower overall management cost.
• Typically, when wagering game machines boot-up, they take measures for ensuring that their hardware and software components have not been modified or tampered-with. For example, wagering game machines often include software for verifying digital signatures for all machine components, including both hardware and software components. In some regulatory jurisdictions, gaming regulators prohibit wagering game machines from presenting wagering games until they have authenticated all machine components and software.
SUMMARY
• Methods and apparatus for authenticating content in wagering game machines are described herein. In one embodiment, the computer-implemented method includes authenticating a first set of wagering game files stored on a storage device of a wagering game machine. The method can also include starting a wagering game on the wagering game machine if the authentication of the first set of wagering game files is successful. The method can also include authenticating, during the wagering game, a second set of wagering game files stored on the storage device of the wagering game machine, wherein the first set of wagering game files and the second set of wagering game files are mutually exclusive. The method can also include stopping the wagering game if the authentication of the second set of wagering game files is not successful.
BRIEF DESCRIPTION OF THE FIGURES
• The present invention is illustrated by way of example and not limitation in the Figures of the accompanying drawings in which:
• FIG. 1 is graphical representation of simultaneous operations for authenticating files and presenting wagering games, according to example embodiments of the invention;
• FIG. 2 is a block diagram illustrating a wagering game device, according to example embodiments of the invention;
• FIG. 3 is a block diagram illustrating a storage unit, according to embodiments of the invention;
• FIG. 4 is a flow diagram illustrating operations for simultaneously (or virtually simultaneously) presenting wagering game while authenticating wagering game files and components, according to example embodiments of the invention;
• FIG. 5 is a flow diagram illustrating operations for granting access to wagering game files, according to example embodiments of the invention;
• FIG. 6 is a flow diagram illustrating operations for requesting access to wagering in files, according to example embodiments of the invention;
• FIG. 7 is a graph illustrating file dependencies associated with wagering game files, according to exemplary embodiments of the invention;
• FIG. 8 is a flow diagram illustrating operations for predictively loading/removing wagering game files into/from a wagering game device's main memory, according to example embodiments of the invention;
• FIG. 9 is a flow diagram illustrating operations for servicing file access requests, according to example embodiments of the invention;
• FIG. 10 is a flow diagram illustrating operations for predictively authenticating wagering game files on a persistent storage device and predictively loading wagering game files into main memory, according to example embodiments of the invention;
• FIG. 11 is a flow diagram illustrating operations for granting access to wagering game files when some of the wagering game files have been predictively loaded and authenticated, according to example embodiments of the invention;
• FIG. 12 is a flow diagram illustrating operations for predictively authenticating and predictively transmitting wagering game files, according to example embodiments of the invention;
• FIG. 13 is a block diagram illustrating a wagering game network, according to example embodiments of the invention; and
• FIG. 14 is a perspective view of a wagering game machine, according to example embodiments of the invention.
DESCRIPTION OF THE EMBODIMENTS
• Methods and apparatus for authenticating content in wagering game machines are described herein. This description of the embodiments is divided into five sections. The first section provides an introduction to embodiments of the invention. The second section describes example gaming device architectures, while the third section describes example operations performed by some embodiments of the gaming device architectures. The fourth section describes wagering game machines and wagering game networks and the fifth section provides some general comments.
Introduction
• This segment introduces embodiments of a wagering game machine that can simultaneously (or virtually simultaneously) present wagering games while authenticating wagering game files, such as audio and video files. By performing these operations simultaneously, embodiments of the invention enable wagering game machines to begin presenting wagering games without delays associated with file authentication. Thus, embodiments can increase wagering game machine availability, which may result in higher player satisfaction and higher profits. This section will continue with a discussion ofFIG. 1, which shows how embodiments of a wagering game machine can simultaneously authenticate wagering game files while presenting wagering games.
• FIG. 1 is graphical representation of simultaneous operations for authenticating files and presenting wagering games in a wagering game machine, according to example embodiments of the invention.FIG. 1 shows a wagering game machine performing operations over time.
• Attime 1, thewagering game machine100 authenticates a minimum set wagering game files needed for presenting wagering games. In one embodiment, the minimum set of files needed for presenting wagering games is mutually exclusive of other files that will be authenticated later. The wagering game files can include just enough audio, video, and other software for presenting a basic version of a wagering game, such as slots or video poker.
• After thewagering game machine100 has authenticated enough files for presenting wagering games, it can begin simultaneous operations. Attime 2, thewagering game machine100 simultaneously presents a wagering game (e.g., slots, video poker, etc.) and authenticates other files. As thewagering game machine100 authenticates more files, those files become available for use in the wagering games. As a result, the wagering game can evolve from its basic version to a more advanced version, having better audio and video effects.
• Atime 3, thewagering game machine100 continues presenting wagering games, while file authentication completes. After file authentication has completed, thewagering game machine100 has all its files available for use in wagering games.
• Attime 4, thewagering game machine100 continues presenting wagering games. Later, attime100, the wagering game machine shuts down.
• In some embodiments, thewagering game machine100 includes multiple processors or other hardware for simultaneously performing operations (i.e., parallel processing), as shown inFIG. 1. However, in other embodiments, thewagering game machine100 performs tasks at virtually the same time (i.e., virtually simultaneously). That is, thewagering game machine100 switches between tasks so rapidly that the switching is substantially imperceptible. For example, attime 2, if themachine100 is switching between operations for the wagering game and file authentication, such switching is imperceptible to players of the wagering game.
Example Wagering Game Devices
• This segment describes an example wagering game device with which embodiments of the invention can be practiced. This segment first presents an example wagering game device architecture and then an example persistent storage device architecture.
• FIG. 2 is a block diagram illustrating a wagering game device architecture, according to example embodiments of the invention. According to embodiments, thewagering game device206 can operate as a wagering game machine, mobile wagering game device, wagering game server, and/or other suitable device in a wagering game network (see discussion ofFIG. 13).
• As shown inFIG. 2, thewagering game device206 includes a central processing unit (CPU)226 connected to amain memory unit228, which includes an authentication unit234,wagering game unit232, andoperating system236. Theoperating system236 includes afile unit238. In one embodiment, thewagering game unit232 can present any suitable casino-style wagering game, such as video poker, video black jack, video slots, video lottery, etc. In one embodiment the authentication unit234 can authenticate files and verify other components (e.g., the storage unit230), as described herein. In one embodiment, theoperating system236 andfile unit238 predictively load files into themain memory228 and facilitate access to data (e.g., files) stored in components, such as themain memory unit228 and thestorage unit230.
• TheCPU226 is also connected to an input/output (I/O)bus222, which facilitates communication between the wagering game device's components. The I/O bus222 is connected to apayout mechanism208,secondary display210,primary display212, money/credit detector214,touchscreen216, push-buttons218,information reader220, andstorage unit230. The I/O bus222 is also connected to anetwork interface unit224, which is connected to awagering game network204.
• In one embodiment, thewagering game device206 can include additional peripheral devices and/or more than one of each component shown inFIG. 2. For example, in one embodiment, thewagering game device206 can include multiplenetwork interface units224 andmultiple CPUs226. In one embodiment, any of the components can be integrated or subdivided (e.g., theoperating system236 can include the authentication unit234). Additionally, in one embodiment, the components of thewagering game machine206 can be interconnected according to any suitable interconnection architecture (e.g., directly connected, hypercube, etc.).
• In one embodiment, any of the components of thewagering game device206 can include machine-readable media including instructions for performing operations described herein. Machine-readable media includes any mechanism that provides (i.e., stores and/or transmits) information in a form readable by a machine (e.g., a computer). For example, tangible machine-readable media includes read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc. Furthermore, components of thewagering game device206 can include other types of logic (e.g., firmware) for executing the operations described herein. In one embodiment, any component of the wagering game device206 (e.g., the wagering game unit232) can be made of software, hardware, or a combination of software and hardware.
• While the discussion ofFIG. 2 describes the various components of a wagering game device,FIG. 3 describes storage devices in greater detail. This description continues withFIG. 3.
• FIG. 3 is a block diagram illustrating a storage unit, according to embodiments of the invention. According to embodiments, thestorage unit302 can include a hard disk drive, flash memory device, read only memory device, or any high-capacity storage device. As shown inFIG. 3, thestorage unit302 includes a load order file table312, wagering game executable files310, audio/video files308,storage log306, andunused space304. In one embodiment, a wagering game device can use the components of thestorage unit302 for simultaneously presenting wagering games and authenticating files.
• In one embodiment, the load order file table312 includes a table indicating an order in which files are loaded when preparing a wagering game device for operation. In one embodiment, a wagering game device uses both the wagering game executable files310 and the audio/video files308 for presenting wagering games. The wagering game executable files310 the audio/video files308 can include software modules and data used for determining and presenting wagering game results. Embodiments of the invention can employ any suitable file structure, such as a directory file structure.
• Operations performed by embodiments of the invention are described in the next section.
Operations
• This segment describes operations performed by embodiments of the invention. In the discussion below, the flow diagrams will be described with reference to the block diagrams presented above. In certain embodiments, the operations are performed by instructions residing on machine-readable media (e.g., software), while in other embodiments, the operations are performed by hardware and/or other logic (e.g., firmware).
Authentication
• FIGS. 4-6, which are discussed below, describe operations for simultaneously (or virtually simultaneously) authenticating files/components and presenting wagering games. These Figures will be described with reference to the embodiments described above. This description continues with a discussion ofFIG. 4.
• FIG. 4 is a flow diagram illustrating operations for simultaneously (or virtually simultaneously) presenting wagering games while authenticating wagering game files and components, according to example embodiments of the invention. Theflow400 begins atblock402.
• Atblock402, basic wagering game files are authenticated. For example, a wagering game machine's authentication unit234 authenticates a basic set of files necessary for presenting a basic version of a wagering game. In one embodiment, the set of files includes only those wagering game executable files310 and audio/video files308 needed for presenting a basic version of a wagering game. In one embodiment, the basic set of files is mutually exclusive of another set of files that will be authenticated later, atblock408. In one embodiment, the authentication unit234 can authenticate the files using any suitable authentication technique, such as verifying digital signatures associated with the files. The flow continues atblock404.
• Atblock404, a determination is made about whether the basic wagering game files have been authenticated. For example, the authentication unit234 determines whether the basic wagering game files have been authenticated. If the files have been authenticated, the flow continues atblock406. Otherwise, the flow continues atblock418.
• Atblock406, wagering games begin. For example, thewagering game unit232 begins presenting a wagering game using the basic wagering game files, which were authenticated atblock402. In one embodiment, only authenticated files can be used in presenting wagering games. In one embodiment, instead of presenting wagering games, thewagering game unit232 presents audio and video for attracting players to thewagering game machine206, while being capable of presenting wagering games if activated by a player. The flow continues atblock408.
• Atblock408, during the wagering game, additional wagering game files are authenticated. For example, while thewagering game unit232 presents a wagering game, the authentication unit234 authenticates more of the audio/video files308 and wagering game executable files310. The flow continues atblock410.
• Atblock410, a determination is made about whether the additional wagering game files have been authenticated. For example, the authentication unit234 determines whether the additional audio/video files308 and wagering game executable files310 have been authenticated. If the files have been authenticated, the flow continues atblock412. Otherwise, the flow continues atblock416.
• Atblock412, during the wagering game, the storage unit's unused space is verified. For example, while thewagering game unit232 presents a wagering game, the authentication unit234 verifies the storage unit'sunused space304. In one embodiment, the authentication unit scans the unused space to make sure it does not contain rogue code or impermissible data. The flow continues atblock414.
• Atblock414, a determination is made about whether the unused space has been verified. For example, the authentication unit234 determines whether the empty space has been verified. If the unused space has not been verified, the flow continues atblock416. Otherwise, the flow ends.
• Atblock416, the wagering game is stopped. For example, the authentication unit234 informs thewagering game unit232 that a file/component could not be authenticated. As a result, thewagering game unit232 stops the wagering game. In one embodiment, the authentication unit234 informs attendants of the error. Fromblock416, the flow ends.
• As discussed above, thewagering game device206 can present a basic version of a wagering game while contemporaneously authenticating files. As more files are authenticated, thewagering game device206 can use those files to enhance the wagering game.FIG. 5 describes operations for determining which files can be accessed and used for augmenting basic wagering games.
• FIG. 5 is a flow diagram illustrating operations for determining access to wagering game files, according to example embodiments of the invention. Theflow500 commences atblock502.
• Atblock502, during a wagering game, a request is received for a wagering game file. For example, while thewagering game unit232 is presenting a wagering game, theoperating system236 receives a file request from thewagering game unit232. The request can be for a file including audio and video data, bonus event executables, or any other suitable wagering game content. The flow continues atblock504.
• Atblock504, a determination is made about whether the requested wagering game file has been authenticated. For example, theoperating system236 determines whether the wagering game file has been authenticated. In one embodiment, theoperating system236 compares a number associated with the requested file with an index corresponding to the most recently authenticated file. If the number is less than the index, the file has been authenticated. In another embodiment, theoperating system236 makes the determination by inspecting a table associated with the files of thestorage unit302. If the requested file has been authenticated, the flow continues atblock506. Otherwise, the flow continues atblock508.
• Atblock506, access to the wagering game file is allowed. For example, theoperating system236 loads the requested file into thememory unit228 and allows thewagering game unit232 to access it. Fromblock506, the flow ends.
• Atblock508, access to the requested file is denied. For example, theoperating system236 denies access to the requested file and returns an error message. Fromblock508, the flow ends.
• WhileFIG. 5 describes operations for granting/denying access to wagering game files,FIG. 6 describes operations for requesting access to wagering game files.
• FIG. 6 is a flow diagram illustrating operations for requesting access to wagering in files, according to example embodiments of the invention. Theflow600 commences atblock602.
• Atblock602, a wagering game is begun. For example, thewagering game unit232 begins presenting a wagering game. The flow continues atblock604.
• Atblock604, access for a wagering game file is requested, where the wagering game file is not one of the basic wagering game files. For example, thewagering game unit232 requests an audio file other than those required for presenting a basic version of the wagering game. The flow continues atblock606.
• Atblock606, a determination is made about whether access to the file is granted. For example, thewagering game unit232 determines whether theoperating system236 granted access to the requested file. In one embodiment, thewagering game unit232 determines whether theoperating system236 delivered a file handle for the requested file. If access is not granted, the flow continues atblock610. Otherwise, the flow continues atblock608.
• Atblock608, the wagering game file is accessed. For example, thewagering game unit232 accesses the requested wagering game file for use in presenting the wagering game. The flow continues atblock614.
• Atblock610, a determination is made about whether there is a default replacement. For example, thewagering game unit232 determines whether there is a default replacement file for the inaccessible file. If there is a default replacement file, the flow continues atblock612. Otherwise, the flow continues atblock616.
• Atblock612, the default replacement file is accessed. For example, thewagering game unit232 requests and receives access to the default replacement file. In one embodiment, the default replacement file has been authenticated by the authentication unit234. The flow continues atblock614.
• Atblock614, the wagering game continues. For example, thewagering game unit232 continues presenting the wagering game. As shown inFIG. 6, embodiments can continue presenting the wagering game with either the requested file or a default replacement. Fromblock614, the flow ends.
• Atblock616, a determination is made about whether access to the file is necessary for continuing the wagering game. For example, thewagering game unit232 determines whether it needs the requested file in order to continue the wagering game. If the requested file is needed, the flow continues atblock618. Otherwise, the flow continues atblock614.
• Atblock618, the wagering game is stopped. For example, thewagering game unit232 stops presenting the wagering game. Fromblock618, the flow ends.
File Dependencies
• This section describes how wagering game files may be related and how relationships between wagering game files can be used for reducing latencies in a wagering game device.
• FIG. 7 is a graph illustrating file dependencies associated with wagering game files, according to exemplary embodiments of the invention. In one embodiment, several files will be needed over the course of a wagering game. For example, as shown inFIG. 7, a wagering game may first need file A (702) and then other files. After using file A (702), the wagering game may need either file E (710), file B, (704) or file C (706), depending on variables such as user input, game outcome, etc. As the wagering game progresses, other files may be needed. As shown inFIG. 7, after a wagering game uses file C (706), it will need file D (708) or file F (712). A wagering game may continue using different files until an end state is encountered (i.e., there is no directed edge progressing to another file; see file E (710)).
• In addition to file-to-file dependencies, there may be dependencies between game states and files. Game states can include information about slot reel positions, wager amounts, bonus event status, wagering game results, progress and location within a wagering game, and any other information suitable for tracking progress and results of a wagering game. Game states can include all information necessary for restarting wagering games from a point where a wagering game terminated. When certain game states are encountered, specific files will be needed. For example, in a situation where a player is eligible for a game option (e.g., bonus event, extra spin, etc.), when the player chooses/activates a game option,wagering game unit232 will need files associated with the game option.
• Because dependencies between files, game states, and/or player states are often known, wagering game devices can include logic for loading and authenticating files before they are needed.
• In the following sections, this description will present methods for predictively loading, authenticating, and transmitting wagering game files.
Predictive Main Memory Loading
• This section describes operations for predictively loading files into a wagering game device's main memory and operations for servicing file access requests in a wagering game machine. This description continues withFIG. 8.
• FIG. 8 is a flow diagram illustrating operations for predictively loading/removing wagering game files into/from a wagering game device's main memory, according to example embodiments of the invention. Theflow800 begins atblock802.
• Atblock802, a wagering game device'sfile unit238 selects a wagering game file to load intomain memory228. In one embodiment, thefile unit238 selects the file based on file dependencies and file usage. For example, thefile unit238 may maintain data (e.g., graph700) indicating dependencies between wagering game files or dependencies between game states and wagering game files needed for presenting a wagering game. Thefile unit238 can use file dependencies and file usage information to determine other files that may be needed soon. As a result, thefile unit238 can select files for loading intomain memory228 before the files are needed for use in wagering games. The flow continues atblock804.
• Atblock804, the authentication unit234 authenticates the file, if necessary. In one embodiment, only certain wagering game files require authentication just before being loaded into main memory. The flow continues atblock806.
• Atblock806, thefile unit238 loads the wagering game file into themain memory228. In one embodiment, after the file has been loaded intomain memory228, it is available for use by thewagering game unit232 or other components of thewagering game device206. In one embodiment, themain memory228 can store a plurality of wagering game files. The flow continues atblock808.
• Atblock808, thefile unit238 determines whether it should remove a wagering game file frommain memory228. If thefile unit238 should remove a file frommain memory228, the flow continues atblock810. Otherwise, the flow continues atblock812.
• Atblock810, thefile unit238 selects and removes a wagering game file frommain memory228. In one embodiment, thefile unit238 selects and removes wagering game files to make room for other files that may be needed soon. In one embodiment, thefile unit238 evicts wagering game files frommain memory228 based on file dependencies and file usages (e.g., files currently in-use, recently used files, etc.). For example, referring toFIG. 7, thefile unit238 may evict file A (702) from main memory after file B (704) is in-use. Other embodiments can use other criteria for evicting files from main memory. The flow continues atblock812.
• Atblock812, thefile unit238 determines whether it should stop predictively loading wagering game files. If thefile unit238 should stop predictively loading wagering game files, the flow ends. Otherwise, the flow continues atblock802.
• WhileFIG. 8 describes operations for predictively loading files into a wagering game device's main memory,FIG. 9 describes operations for providing access to wagering game files. This description continues with a discussion ofFIG. 9.
• FIG. 9 is a flow diagram illustrating operations for servicing file access requests, according to example embodiments of the invention. The flow900 begins at block902.
• At block902, thefile unit238 receives a request to access a wagering game file. File access requests can originate from thewagering game unit232 or any other component of thewagering game device206. The flow continues at block904.
• At block904, thefile unit238 records the file access request. In one embodiment, a record of the file request can be used for predictively loading wagering game files (e.g., see discussion ofFIG. 8). The flow continues atblock906.
• Atblock906, thefile unit238 determines whether the requested wagering game file has been loaded intomain memory228 and (if needed) authenticated. As noted above, in one embodiment, certain files must be authenticated before they are loaded intomain memory228. If the file has not been loaded into main memory and (if needed) authenticated, the flow continues atblock908. Otherwise, the flow continues atblock914.
• Atblock908, thefile unit238 determines whether there is a default replacement for the requested file. If there is no default replacement for the requested wagering game file, the flow continues atblock910. Otherwise, the flow continues atblock920.
• Atblock910, in a situation where the requested wagering game file is not inmain memory228 and there is no default replacement, thefile unit238 determines whether there will be a file access delay that exceeds a given threshold. If there will not be a file access delay longer than a given threshold, the flow continues atblock914. Otherwise, the flow continues atblock912.
• Atblock912, thefile unit238 provides a transition file, while it loads and/or authenticates the requested wagering game file. In one embodiment, the transition file can include content (e.g., text, graphics, audio, etc.) for presentation during the file access delay. The flow continues atblock914.
• Atblock914, thefile unit238 provides access to the requested wagering game file in themain memory228. In one embodiment, before thefile unit238 loads an entire wagering game file into themain memory228, it can provide access to a portion of the file that has been loaded. In such an embodiment, the flow900 would proceed fromblock906 to block914 when a portion of the file is loaded into themain memory228 and authenticated (if needed). The flow continues atblock916.
• Atblock916, thefile unit238 records the access grant and tracks usage of the wagering game file. In one embodiment, information about access grant and file usage can be used for predictively loading wagering game files intomain memory228. The flow continues atblock918.
• Atblock918, thefile unit238 determines whether there are more file requests that need service. If there are more file requests that need service, the flow continues at block902. Otherwise, the flow ends.
• Atblock920, in a situation where the requested file was not present in main memory and/or authenticated, but where there is a default replacement for the requested file, thefile unit238 grants access to the default replacement file. In one embodiment, the default replacement file includes data that can be used in place of data in the requested file. In one embodiment, the default replacement file includes enough data to continue presenting a basic version of a wagering game, whereas the requested file may include data useful in presenting enhanced features of the wagering game. The flow continues atblock918.
Predictive Memory Loading with Predictive Authentication
• This section describes operations for predictively loading files into a wagering game device's main memory, while contemporaneously authenticating files stored in the wagering game device's persistent data store. This section also describes operations for servicing file access requests in an environment in which wagering game files are predictively loaded and predictively authenticated. This description continues withFIG. 10.
• FIG. 10 is a flow diagram illustrating operations for predictively authenticating wagering game files on a persistent storage device and predictively loading wagering game files into main memory, according to example embodiments of the invention. Theflow1000 begins atblock1002.
• Atblock1002, the authentication unit234 authenticates a set of pre-start wagering game files residing on thestorage unit230. In one embodiment, the pre-start wagering game files include a basic set of files necessary for presenting a basic version of a wagering game. That is, the basic set of files includes only those wagering game executable files310 and audio/video/data files308 needed for presenting a basic version of a wagering game. The flow continues in parallel atblocks1004 and1010.
• Atblock1004, the authentication unit234 authenticates, based on an authentication priority list, additional files stored on thestorage unit230. In one embodiment, the authentication priority list can include any data structure suitable for indicating an order in which the additional wagering game files will be authenticated. The additional files can include wagering game executable files and data useful in presenting an enhanced version of the wagering game.
• In one embodiment, file priorities are assigned based on file dependencies and file usage. For example, files may be assigned a high priority when file dependencies and file usage indicate that the files will be needed soon. In contrast, files may be assigned low priority when file dependencies and file usage indicate that the files will not be needed soon. In another embodiment, priority can be based on dependencies between files and game states. For example, when game states indicate that certain files may be needed soon, those files are assigned high priorities. In contrast, when game states indicate that certain files will not be needed soon, those files are assigned low priorities. In other embodiments, priority can be based on other suitable criteria.
• The flow continues atblock1006.
• Atblock1006, the authentication unit234 modifies the authentication priority list based on a loading priority list (see discussion of block1010). For example, in one embodiment, the authentication unit234 can assign files a higher priority when related files have been loaded into main memory. When files are removed frommain memory228, the authentication unit234 can assign related files a lower priority. In one embodiment, the relative priority of files in the authentication list is automatically adjusted to correspond to their relative priority in the memory loading list. For example, if a file is moves up in priority for loading, the file also moves up in priority for authentication. Although authentication and loading can be separate processes operating in parallel, they can remain correlated. The authentication unit234 can also base its priority assignments on other criteria. The flow continues atblock1008.
• Atblock1008, the authentication unit234 determines whether there are more files to authenticate. If there are no more files to authenticate, the flow ends. Otherwise, the flow continues atblock1004.
• Atblock1010, based on a loading priority list, thefile unit238 loads and/or removes wagering game files into and/or out of themain memory228. In one embodiment, thefile unit238 determines the loading priority list based on file dependencies and file usage. For example, thefile unit238 may assign high priorities when file dependencies and file usage indicate that files will be needed soon. In contrast, thefile unit238 may assign low priorities when files will probably not be needed soon. In one embodiment, priority can be based on other suitable criteria. The authentication unit234 can authenticate those files that must be authenticated before they are loaded intomain memory228. The flow continues atblock1012.
• Atblock1012, thefile unit238 allows access to the wagering game files that have been loaded into memory. The flow continues atblock1014.
• Atblock1014, based on game state and/or records of file access and usage, thefile unit238 modifies the loading priority list. For example, referring toFIG. 7, thefile unit238 may assign a higher priority to files D (708) and F (712) after file C (706) has been accessed. In contrast, thefile unit238 may assign a lower priority to file A (702) after file D (708) has been accessed. As another example, thefile unit238 may modify loading priorities after detecting particular game states. For instance, in response to detecting a game state, thefile unit238 can load a low resolution image file intomain memory228. Thefile unit238 can increase the priority of a related high resolution image file, accelerating authentication and loading of the high resolution image in anticipation that the player will want to see the high resolution image. The flow continues atblock1016.
• Atblock1016, thefile unit238 determines whether there are more files to load and/or remove. If there are more files to load/remove, the flow continues atblock1010. Otherwise, the flow ends.
• WhileFIG. 10 describes operations for predictively loading and predictively authenticating wagering game files,FIG. 11 describes operations for providing access to wagering game files. This description continues with a discussion ofFIG. 11.
• FIG. 11 is a flow diagram illustrating operations for granting access to wagering game files when some of the wagering game files have been predictively loaded and authenticated, according to example embodiments of the invention. The flow of1100 begins atblock1102.
• Atblock1102, thefile unit238 receives a request to access a wagering game file. The request can originate from thewagering game unit232 or any other component of thewagering game device206. The flow continues atblock1104.
• Atblock1104, thefile unit238 determines whether the requested wagering game file resides in themain memory228. If the file resides inmain memory228, the flow continues atblock1114. Otherwise, the flow continues atblock1105.
• Atblock1105, thefile unit238 determines whether the wagering game file requires authentication each time it is loaded intomain memory228. If the wagering game file requires authentication each time it is loaded, the flow continues atblock1108. Otherwise, the flow continues atblock1106.
• Atblock1106, thefile unit238 determines whether the requested wagering game file has been authenticated on thestorage unit230. In one embodiment, every wagering game file must be authenticated while it resides on thestorage unit230. If the wagering game file has been authenticated on thestorage unit230, the flow continues atblock1110. Otherwise, the flow continues atblock1108.
• Atblock1108, the authentication unit234 authenticates the requested wagering game file. The flow continues atblock1110.
• Atblock1110, thefile unit238 loads the wagering game file intomain memory228. The flow continues atblock1112.
• Atblock1112, thefile unit238 allows access to the requested wagering game file. The flow continues atblock1114.
• Atblock1114, thefile unit238 records the access grant and tracks usage of the wagering game file. In one embodiment, information about access grant and file usage can be used to assign priorities when predictively loading and predictively authenticating wagering game files (see discussion ofFIG. 10). Fromblock1114, the flow ends.
Predictive Authentication with Predictive Transmission
• This section describes operations for predictively authenticating and transmitting wagering game files over a wagering game network.
• In a distributed gaming environment, wagering game devices may not store all wagering game files needed for presenting a wagering game. If a wagering game device is lacking files, it can request the files from other network devices. However, authentication latencies and network transmission latencies may cause delays in presenting a wagering game. In one embodiment, wagering game network devices can use predictive authentication and predictive transmission to avoid these latencies. The operations described below are applicable in peer-to-peer, client/server, and other environments.
• FIG. 12 is a flow diagram illustrating operations for predictively authenticating and predictively transmitting wagering game files, according to example embodiments of the invention. Theflow1200 begins in parallel atblocks1202 and1210.
• Atblock1202, a wagering game device receives a request for a wagering game file. In one embodiment, the request is received from another wagering game device on a wagering game network. The flow continues atblock1204.
• Atblock1204, the wagering game device determines whether the file has been authenticated while residing in thestorage unit230. If the file has not been authenticated, the flow continues atblock1206. Otherwise, the flow continues atblock1208.
• Atblock1206, the wagering game device'sauthentication unit232 authenticates the file. The flow continues atblock1208.
• Atblock1208, the wagering game device'snetwork interface unit224 transmits the wagering game file over a wagering game network to anotherwagering game device206. Fromblock1208, the flow continues atblock1209.
• Atblock1209, the wagering game device determines whether it will receive more file requests. If it will not receive more file requests, the flow ends. Otherwise, the flow continues atblock1202.
• Atblock1210, theauthentication unit232 authenticates files on thestorage unit230 in order of priority rankings. As described above, files may be assigned a priority based on file dependencies and file usage. The flow continues atblock1212.
• Atblock1212, the wagering game device'sfile unit238 transmits, to another wagering game device, files that may soon be needed by other network devices. In one embodiment, thefile unit238 transmits some of the highest priority files that have been authenticated. In one embodiment, the wagering game device does not transmit files until they are explicitly requested. The flow continues atblock1214.
• Atblock1214, thefile unit238 updates priority rankings. For example, thefile unit238 updates priorities based on which files have been authenticated and/or transmitted. In one embodiment, files dependent on those that have been authenticated or transmitted are assigned higher priorities. The flow continues atblock1216.
• Atblock1216, the wagering game device determines whether there are more files to authenticate and/or transmit. If there are more files to authenticate and/or transmit, the flow continues atblock1210. Otherwise, the flow ends.
Example Wagering Game Devices and Wagering Game Networks
• This segment describes example wagering game devices and wagering game networks with which embodiments of the invention can be practiced.
Example Wagering Game Network
• FIG. 13 is a block diagram illustrating a wagering game network, according to example embodiments of the invention. As shown inFIG. 13 thewagering game network1300 includes a plurality ofcasinos1312 connected to a communications network1314. Each of the plurality ofcasinos1312 includes alocal area network1316, which includeswagering game machines1302, mobilewagering game devices1304, and awagering game server1306. Thewagering game machines1302, mobilewagering game device1304, and/or andwagering game server1306 can include hardware and machine-readable media including instructions for loading and authenticating wagering game files, as described herein. In one embodiment, thewagering game server1306 can facilitate switching between networks in concert with serving wagering games over thelocal area network1316.
• The wagering game machines described herein can be of any suitable form factor, such as floor standing models, mobile units, bartop models, workstation-type console models, etc. In one embodiment, thewagering game network1300 can include other network devices, such as accounting servers, wide area progressive servers, and/or other devices suitable for use in connection with embodiments of the invention.
• The components of eachcasino1312 can communicate over wired1308 and/orwireless connections1310. Furthermore, they can employ any suitable connection technology, such as Bluetooth, IEEE 802.11, Ethernet, public switched telephone networks, SONET, etc.
Example Wagering Game Machine
• FIG. 14 is a perspective view of a wagering game machine, according to example embodiments of the invention. As shown inFIG. 14, thewagering game machine1400 can be a computerized slot machine having the controls, displays, and features of a conventional slot machine.
• Thewagering game machine1400 can be mounted on astand1442 or it can be constructed as a pub-style tabletop game (not shown). As a result, thewagering game machine1400 can be operated while players are standing or seated. Furthermore, thewagering game machine1400 can be constructed with varying cabinet and display designs. Thewagering game machine1400 can incorporate any primary game upon which monetary value can be wagered, such as slots, poker, or keno, and additional bonus round games. The symbols and indicia used on and in thewagering game machine1400 can take mechanical, electrical, or video form.
• As illustrated inFIG. 14, thewagering game machine1400 includes acoin slot1402 andbill acceptor1424. Players can place coins in thecoin slot1402 and paper money or ticket vouchers in thebill acceptor1424. Other devices can be used for accepting payment. For example, credit/debit card readers/validators can be used for accepting payment. Additionally, thewagering game machine1400 can perform electronic funds transfers and financial transfers to procure monies from financial accounts. When a player inserts money in thewagering game machine1400, a number of credits corresponding to the amount deposited are shown in acredit display1406. After depositing the appropriate amount of money, a player can begin playing the game by pushingplay button1408. Theplay button1408 can be any play activator used for starting a wagering game or sequence of events in thewagering game machine1400.
• As shown inFIG. 14, thewagering game machine1400 also includes abet display1412 and one or more “bet” buttons on thepanel1416. The player can place a bet by pushing one or more of the bet buttons on thepanel1416. The player can increase the bet by one or more credits each time the player pushes a bet button. When the player pushes a “bet one”button1416, the number of credits shown in thecredit display1406 decreases by one credit, while the number of credits shown in thebet display1412 increases by one credit.
• A player may end the gaming session or “cash-out” by pressing a cash-out button1418. When a player cashes-out, thewagering game machine1400 dispenses a voucher or currency corresponding to the number of remaining credits. Thewagering game machine1400 may employ other payout mechanisms such as credit slips (which are redeemable by a cashier) or electronically recordable cards (which track player credits), or electronic funds transfer.
• The wagering game machine also includes aprimary display unit1404 and a secondary display unit1410 (also known as a “top box”). The wagering game machine may also include anauxiliary video display1440. In one embodiment, theprimary display unit1404 displays a plurality ofvideo reels1420. According to embodiments of the invention, thedisplay units1404 and1410 can include any visual representation or exhibition, including moving physical objects (e.g., mechanical reels and wheels), dynamic lighting, and video images. In one embodiment, eachreel1420 includes a plurality of symbols such as bells, hearts, fruits, numbers, letters, bars or other images, which correspond to a theme associated with thewagering game machine1400. Additionally, thewagering game machine1400 also includes anaudio presentation unit1428. Theaudio presentation unit1428 can include audio speakers or other suitable sound projection devices.
• In one embodiment, thewagering game machine1400 can simultaneously (or virtually simultaneously) authenticate wagering game files and/or components while presenting wagering games, as described herein.
General
• In this description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Note that in this description, references to “one embodiment” or “an embodiment” mean that the feature being referred to is included in at least one embodiment of the invention. Further, separate references to “one embodiment” in this description do not necessarily refer to the same embodiment; however, neither are such embodiments mutually exclusive, unless so stated and except as will be readily apparent to those of ordinary skill in the art. Thus, the present invention can include any variety of combinations and/or integrations of the embodiments described herein. Each claim, as may be amended, constitutes an embodiment of the invention, incorporated by reference into the detailed description.
• Herein, block diagrams illustrate example embodiments of the invention. Also herein, flow diagrams illustrate operations of the example embodiments of the invention. The operations of the flow diagrams are described with reference to the example embodiments shown in the block diagrams. However, it should be understood that the operations of the flow diagrams could be performed by embodiments of the invention other than those discussed with reference to the block diagrams, and embodiments discussed with references to the block diagrams could perform operations different than those discussed with reference to the flow diagrams. Additionally, some embodiments may not perform all the operations shown in a flow diagram. Moreover, although the flow diagrams depict serial operations, certain embodiments could perform certain of those operations in parallel.

Claims (22)

1. (canceled)

2-40. (canceled)

41. A computer-implemented method comprising:

authenticating a first set of wagering game files stored on a storage device;

if the authentication of the first set of wagering game files is successful, presenting a wagering game on the wagering game machine; and

during the presenting, authenticating a second set of wagering game files stored on the storage device, wherein the first set of wagering game files and the second set of wagering game files are mutually exclusive.

42. The computer-implemented method ofclaim 41, wherein the presenting a wagering game includes executing an audio file or a video file on the wagering game machine.

43. A computer-implemented method comprising:

authenticating a first set of wagering game files stored on a storage device;

if the authentication of at least one of the first set of wagering game files is successful, executing the at least one of the first set of wagering game files on the wagering game machine; and

during the executing, authenticating a second set of wagering game files stored on the storage device, wherein the first set of wagering game files and the second set of wagering game files are mutually exclusive.

44. The computer-implemented method ofclaim 43, wherein the at least one of the first set of wagering game files is an audio file.

45. The computer-implemented method ofclaim 43, wherein the at least one of the first set of wagering game files is a video file.

46. The computer-implemented method ofclaim 43, wherein the first set of wagering game files includes files for executing a basic wagering game.

47. The computer-implemented method ofclaim 43, wherein the first set of wagering game files and the second set of wagering game files are defined in a load order file table.

48. The computer-implemented method ofclaim 43, wherein the first set of wagering game files includes files selected from the group consisting of boot files, operating system files, default audio files, default video files, required audio files, required video files, and wagering game executable files.

49. The computer-implemented method ofclaim 43, wherein if the authentication of the first set of wagering game files and the authentication of the second set of wagering game files is not completed within a specific amount of time, the executing is stopped.

50. The computer-implemented method ofclaim 43, further comprising:

determining that one of the second set of wagering game files is inaccessible; and

accessing one of the first set of wagering game files instead of the one of the second set.

51. A wagering game comprising:

a storage device including a first set of wagering game files and a second set of wagering game files;

an authentication unit configured to authenticate the first set of wagering game files;

a controller executing at least one of the first set of wagering game files if the authentication of at least one of the first set of wagering game files is successful; and

wherein the authentication unit is configured to authenticate the second set of wagering game files after executing the at least one of the first set of wagering game files, wherein the first set of wagering game files and the second set of wagering game files are mutually exclusive.

52. The wagering game ofclaim 51, wherein the authentication unit is further configured to, during the executing, determine whether a wagering game file of the first or second set of wagering game file has been authenticated, and if the wagering game file has been authenticated, the authentication unit is further configured to allow access to the wagering game file, and if the wagering game file has not been authenticated, the authentication unit is further configured to prevent access to the wagering game file.

53. The wagering game ofclaim 51, wherein the at least one of the first set of wagering game files is an audio file.

54. The wagering game ofclaim 51, wherein the at least one of the first set of wagering game files is a video file.

55. The wagering game ofclaim 51, wherein the first set of wagering game files includes files for executing a basic wagering game.

56. The wagering game ofclaim 51, wherein the first set of wagering game files and the second set of wagering game files are defined in a load order file table in the storage device.

57. The wagering game ofclaim 51, wherein the first set of wagering game files includes files selected from the group consisting of boot files, operating system files, default audio files, default video files, required audio files, required video files, and wagering game executable files.

58. The wagering game ofclaim 51, wherein if the authentication of the first set of wagering game files and the authentication of the second set of wagering game files is not completed within a specific amount of time by the authentication unit, the executing is stopped.

59. The wagering game ofclaim 51, wherein the authentication unit determines that one of the second set of wagering game files is inaccessible and allows accessing one of the first set of wagering game files instead of the one of the second set.

60. A machine-readable medium including instructions which when executed by a machine cause the machine to perform operations comprising:

authenticating a first set of wagering game files stored on a storage device;

if the authentication of at least one of the first set of wagering game files is successful, executing the at least one of the first set of wagering game files on the wagering game machine;

during the executing, authenticating a second set of wagering game files stored on the storage device, wherein the first set of wagering game files and the second set of wagering game files are mutually exclusive.

Images