Gaming machine having reduced-read software authentication

[0001] This application is related to U.S. patent application Ser. No. 10/119,663 filed Apr. 10, 2002, entitled “Gaming Software Authentication,” and incorporated herein by reference in its entirety.

[0002] The present invention relates generally to gaming machines, and more particularly, to software authentication in a gaming machine.

[0003] As a regulatory requirement in virtually all jurisdictions that allow gaming, it is necessary to have a technique to authenticate that the software installed in a gaming machine is tested and approved. In the past, gaming manufacturers have generally used EPROM-based hardware platforms to store program code. As a result, a number of software authentication techniques have been accepted as standards throughout the gaming industry. Depending upon the preferences of the local regulatory agency, these techniques generally include either a Kobetron signature or a hash function based on the data stored in the EPROM device.

[0004] Authentication of software programs basically occurs using two different methods in the field, again determined by the local regulatory agency. In one method, each EPROM is authenticated by a gaming agent prior to being installed in a gaming machine that is to be brought up for play. The EPROMs may be shipped directly to the gaming agency for authentication prior to the install date of the machine, or may be authenticated on the casino floor as the software is being installed in the machine. In another method, authentication is conducted on a spot-check basis. A gaming agent periodically visits a casino and picks machines selectively or at random to remove the software components for authentication.

[0005] Jurisdictional requirements require that storage media containing code or data be authenticated at power-up, continuously or at a periodic rate, or upon occurrence of predetermined events, such as the opening any doors or panels of the gaming device that allows access to internal circuitry. The storage media may be comprised of erasable programmable read-only memory devices (EPROMs), electrically erasable programmable read-only memory devices (EEPROMs), PROMs, CompactFlash storage cards, hard disk drives, CD drives, or substantially any non-volatile memory and in some cases volatile memory (e.g., NVRAM, specialty mask semiconductors, battery backed RAM, SRAM, DRAM, etc.). The storage media comprises a memory device and the data stored thereon. Authentication of storage media is controlled by the gaming device's central processing unit (CPU). However, authentication by the CPU may take more than several minutes due to increasing complexity of the gaming device's software and thus the storage size of the media.

[0006] For example, in some gaming machines, the authentication and boot process may require up to or more than three (3) complete (or close to complete) read cycles of the storage media. The three read cycles are required to complete software authentication of the gaming program as a whole (the bits of data), the gaming program files individually, and to load the software in an executable memory. Consider a game machine that takes advantage of and uses a media device that is potentially alterable or rewritable throughout execution of the program. Such an alterable media device could be, for example, a CompactFlash storage card, EEPROM, ROM, hard drive, CD ROM, DRAM, SRAM, or other non-volatile memory device (or volatile memory device) that can store an executable software program, or parts thereof, required for the gaming operation. Referring to FIG. 2, a typical software authentication algorithm would involve first reading all the bits of information from the alterable media device in order to validate the entire software media image 20. If the software media image (all the bits of information in the storage media) is successfully validated 22, then the executable software program stored in the alterable media device is read in order to validate each file of the gaming software program at the file level 24. If time file level authentication is successful 26, the gaming software program is read a third time in order to load the gaming software program into an executable memory device 28 such as a DRAM or any other applicable volatile or non-volatile memory. Thus, in order to authenticate and load the gaming program, the gaming program is read, for example, three times. If the time it takes to read the gaming program is T, then, at a minimum, the time required to authenticate the gaming program and load the appropriate executable memory devices or storage media of a gaming machine is 3T. In practicality, regulators and gaming operators have expressed a desire to see the time required to authenticate the gaming program in certain commercial products with large storage media components reduced. Thus, there is a need for a system and/or method for speeding up the authentication process.

[0007] In an embodiment of the present invention a gaming machine includes a CPU. The processor in the CPU requires substantially only a single read of a storage device in order to authenticate the bits of data in the device, to authenticate the files in the device and to move, if necessary, the files in the device to an executable memory device thereby decreasing the amount of time required to authenticate the gaming machine's software at boot-up and after a reset.

[0008] An embodiment of the present invention comprises a gaming machine that authenticates the gaming software at boot-up or after a reset. A processor in conjunction with the boot memory reads the bits of data and the files from a non-volatile memory device via a single read of each bit. The files are each validated while at substantially the same time the bits of non-volatile memory data are simultaneously validated. After all the files and the data are validated then the gaming software is authenticated.

[0009] The above summary of the present invention is not intended to represent each embodiment, or every aspect, of the present invention. This is the purpose of the figures and the detailed description which follow.

[0015] While the invention is susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the invention is not intended to be limited to the particular forms disclosed. Rather, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

[0016] Turning now to the drawings and referring initially to FIG. 1, a gaming machine 10 is operable to conduct a wagering game such as mechanical or video slots, poker, keno, bingo, or blackjack. If based in video, the gaming machine 10 includes a video display 12 such as a cathode ray tube (CRT), liquid crystal display (LCD), plasma, or other type of visual display known in the art. A touch screen preferably overlies the display 12. In the illustrated embodiment, the gaming machine 10 is an “upright” version in which the display 12 is oriented vertically relative to a player. Alternatively, the gaming machine may be a “slant-top” version in which the display 12 is slanted at about a thirty-degree angle toward the player.

[0017] The gaming machine 10 includes a plurality of possible credit receiving mechanisms 14 for receiving credits to be used for placing wagers in the game. The credit receiving mechanisms 14 may, for example, include a coin acceptor, a bill acceptor, a ticket reader, and a card reader. The bill acceptor and the ticket reader may be combined into a single unit. The card reader may, for example, accept magnetic cards and smart (chip) cards coded with money or designating an account containing money.

[0018] The gaming machine 10 includes a user interface comprising a plurality of push-buttons 16, the above-noted touch screen, and other possible devices. The plurality of push-buttons 16 may, for example, include one or more “bet” buttons for wagering, a “play” button for commencing play, a “collect” button for cashing out, a “help” button for viewing a help screen, a “pay table” button for viewing the pay table(s), and a “call attendant” button for calling an attendant. Additional game-specific buttons may be provided to facilitate play of the specific game executed on the machine. The touch screen may define touch keys for implementing many of the same functions as the push-buttons. Other possible user interface devices include a keyboard and a pointing device such as a mouse or trackball.

[0019] Referring now to FIG. 3, a central processing unit (CPU) 30 controls operation of the gaming machine 10. In response to receiving a wager and a command to initiate play, the CPU 30 randomly selects a game outcome from a plurality of possible outcomes and causes the display 12, via the video circuitry 39 and video out 40, to depict indicia representative of the selected game outcome. Alternatively, the game outcome may be centrally determined at a remote computer using either a random number generator (RNG) or pooling schema. In the case of slots, for example, mechanical or simulated slot reels are rotated and stopped to place symbols on the reels in visual association with one or more pay lines. If the selected outcome is one of the winning outcomes defined by a pay table, the CPU 30 awards the player with a number of credits associated with the winning outcome.

[0020] The CPU 30 includes a microprocessor 32 and various memory devices (media devices). The microprocessor 32 interfaces with many other components of the gaming machine 10 via an interface bus 34. A main memory 36 stores the executable gaming machine software program variables and files for operating the gaming machine 10. The main memory may be DRAM or SRAM or substantially any other volatile memory device or reprogrammable non-volatile memory device. The battery backed memory 38 stores machine critical data that cannot be lost when power is removed from machine 10. The battery backed memory 38 may be battery backed volatile memory or a reprogrammable non-volatile memory device. The video circuitry 40 supplies display information to a video display 12 which may comprise a CRT, LCD, plasma, or other display device. Audio circuitry 42 generates sounds for game play on the gaming machine 10. The I/O control 44 controls input/output interfaces with the user interfaces such as game buttons 16, coin validators 14, touch screen bill validators, etc.

[0021] In an exemplary embodiment, the various memory devices may also include a boot memory 46, a high capacity storage memory 48, and a serial read-write memory 50. The boot memory 46 is preferably a read-only memory such as a one megabit EPROM, EEPROM, PROM or other type of programmable read-only memory. The boot memory may also be substantially any type of non-volatile memory. The high capacity storage memory 48 is preferably a CompactFlash card, but may also be a hard disk drive, CD drive, or other type of non-volatile memory. The serial memory 50 is preferably an EEPROM such as a 512 byte SPI EEPROM, but could be any type of programmable read-only or read/write non-volatile memory. Depending upon the preferences of the local gaming regulatory agency, all three memories may be adapted to be authenticated outside of the CPU as well as when installed in the CPU at power up or prior to being utilized in the gaming machine.

[0022] The boot memory 46 stores, at least, boot code 52, an authentication program 54, a RAM loader, a decompression utility 56, and a digital signature 58. The authentication program includes a hash function 60, a digital signature verify operation 62, and a public key 64. The hash function 60 may, for example, be an SHA-1 hash algorithm that reduces a data set to a unique 160 bit message digest. A hash algorithm or function is used to calculate an index or message digest corresponding to the files in, for example, a memory device. The message digest does not have to be unique, i.e., the function may return the same hash value for two or more items. The non-uniqueness of the hash value for each item in the message digest is acceptable because each hash value is positioned in different locations in the index. The message digest is a small representation of a large amount of data. A message digest is a relatively unique representation of data, from a cryptographic standpoint, and is an irreversible representation of the data. In other words, one cannot recreate the original data from the message digest.

[0023] The digital signature 58 is generated, in effect, from the boot memory's contents as a whole. In an exemplary embodiment, after hashing is performed to produce a message digest, then a digital signature is created to enable the origin and authenticity of the digest to be determined. When there is data that requires a means for determining the origin of the data, one generally uses a digital signature mechanism. There exists a federal standard called FIPS 186-2 that defines a digital signature generation and verification mechanism called the Digital Signature Algorithm (DSA). In an exemplary embodiment a digital signature is created from the message digest. In essence the DSA uses a private key, a public key, and the message digest. A private key and the message digest is used to create an original signature associated with the original message digest. The public key, the original signature, and the message digest are used to check a signature associated with a message digest in order to determine the origin and authenticity of the digest. It is understood that neither the message digest nor the data or files used to create the message digest can be recreated using the DSA. The digital signature 58 is used to sign the message digest containing the hash(es) of the boot memory contents. Again, the signature may be used to determine the source or manufacturer of the hash or message digest, via a public key, but cannot be used to recreate the hash or the original data. Furthermore, the DSA is not being used here as an encryption process, but rather a technique for validating the signature associated with the bash, and the public key.

[0024] The high capacity storage memory 48 stores game and operating system executable program files 66, sound operating system files 68, sound bank files 70, graphics files 72, a manifest file 74, and digital signatures 76, 78. The files in the high capacity storage memory 48, taken together, constitute a “gaming program” as that term is used herein, and the various files constitute “data files” as that term is used herein. Thus, the gaming program includes a plurality of data files. For each data file on the high capacity storage memory 48, the manifest file contains a file name, a file type, a load address, and a file digital signature 76. The whole device digital signature 78 is generated from the gaming program as a whole, while each digital signature 76 is generated from the associated data file listed in the manifest file.

[0025] The serial read-write memory 50 stores information/data specific to the jurisdiction where the CPU is to be installed. This information may, for example, include a lottery terminal identification (ID) 80, a part number 82, a jurisdiction ID 84, a jurisdiction name 86, jurisdiction bit code options 88, jurisdiction max bet 90, jurisdiction max win 92, and a digital signature 94. The digital signature 94 is generated from the serial memory's contents as a whole.

[0026] The boot memory 46, serial read-write memory 50 and high capacity storage memory 48 may each be removable devices and/or contain alterable software that may be able to be reprogrammed or to download updates from an outside source via a programming device, a network such as the Internet, an intranet, an Ethernet, a fibre loop, or other type of networking system. The boot memory, 46, serial read-write memory 50, and high capacity memory 48 each may be required to be authenticated by the gaming machine 10 at various points during operation of the gaming machine.

[0027] In accordance with an embodiment of the present invention, during boot-up of the gaming machine, the CPU 30 is powered up. The microprocessor 32 within the CPU 30 addresses the boot memory 46 and utilizes the boot code 52 to begin operations. The authentication program 54, within the boot memory 46, is initialized so that a predetermined amount of the gaming software stored in a non-volatile memory device (media device) can be authenticated and correctly loaded into or initialized in an executable memory such as the main storage memory 36. In essence, one or more of the software components (the contents of the boot memory 46, the high capacity storage memory 48 or serial read-write memory 50) may be properly authenticated prior to use of the gaming machine. It should be noted that the items in the high capacity storage memory 48 are only representative of the vast variety of files that could be stored as part of an executable program or gaming program in a gaming machine. In some exemplary embodiments only the flash memory or high capacity storage memory 48 is required to be authenticated at boot-up.

[0028] Elements, whether a software element or firmware elements that are required to be authenticated at boot-up, are denoted in the boot memory 46. Denotation in the boot memory 46 is done because the boot memory 46 may be externally authenticated to the satisfaction of a regulatory agency. Thus, at boot-up the boot memory may have already been authenticated by an external device.

[0029] In order to better understand the advantages of the exemplary reduced read algorithm, it is important to realize that as gaming machines evolved they began to use alterable media, such as flash memories, EEPROMs, EPROMs, CD drives, disk drives, etc. in their electronics and programming structure to store all or portions of the executable programs and files. Newer gaming machines are designed to allow the gaming software to be updated, to grow in size, and to grow in complexity. Because of these advances and changes in gaming machine design, electronics, software and memory storage size the time necessary to authenticate the software in the storage media at boot-up increased because the methods required to authenticate the software content became more complex. An increase in the time required to authenticate the software during boot-up of each gaming machine impacts customer operations by lengthening the set up time or down time of a gaming machine due to the system reboot time.

[0030] Exemplary embodiments of the present system and methods for reduced read software authentication effectively reduce the amount of time required to authenticate the raw data and/or the gaming program software contents of the non-volatile memory devices containing executable programs and/or data. In a nutshell, the exemplary algorithm or technique reads a reprogrammable, non-volatile storage media (e.g., high capacity storage memory 48 and/or serial read-write memory 50) at boot-up and then maps the executable software into the appropriate volatile memory. The reading and mapping is performed by the processor emulating what an operating system's file system does when reading files from non-volatile memory and mapping the files into executable volatile memory. Authenticating the gaming program (the bits) and individual data files, using one read of a storage media device, allows the file level authentication to be performed in parallel (in a multiplexed fashion, or at substantially the same time) with a total raw media verification of the high capacity storage memory 48, eliminating a need for additional reads of the non-volatile memory 48 thereby saving time. In addition, once the data bytes are read from the non-volatile memory, they are mapped into the appropriate file and the boot loading software can load the file data into the main memory 30, thus avoiding an additional media read/write cycle for loading the gaming program software into executable non-volatile memory. The number of media reads is limited to about one total read thereby decreasing the number read cycles from three to one or by about 66%.

[0031] A raw media read is a reading of each byte in a memory device—for example, a read of each byte of the gaming program (data) in the high capacity storage memory 48. A raw media read is not performed using the CPU's standard operating system's file system read utilities. The raw media read is done at a lower level than an operating system's file read. The CPU reads each bit, byte, word, or other predetermined amount of data in a predetermined order from, for example, the first memory location to the last memory location of, for example, the high capacity storage memory 48. When a raw media read is performed, there is no determination of where each file starts and ends. The CPU at this time is reading bits or data without regard to file structure or oranization. The data bits must be read at this low level in order to verify and authenticate the raw media. At the same time, in parallel with or multiplexed with the raw media read, the CPU emulates what the operating system normally does when files are read. As each bit, byte, word, etc. is read, the CPU, via emulation, determines what, if any, file the bits, bytes or words belong to. The hash for each file is then calculated so that each file can be properly authenticated.

[0032] As each file is extracted, mapped, and authenticated, each file is loaded into the main memory 30 by the boot-up software in the boot memory 46.

[0033] An exemplary process for booting, performing a raw media read, performing a file read, performing an authentication of the gaming program, and loading the software files into an executable main memory is shown in FIG. 4. The exemplary processor requires a single read of the high capacity storage memory 48 or any other non-volatile memory device.

[0034] At step 100 the gaming device is either turned on or being reset. When a gaming device is booted or reset a software verification and authentication is required. At step 102 the microprocessor 32 reads a predetermined amount of data from the high capacity storage memory 48. In this exemplary embodiment the high capacity storage memory is a compact flash memory, but could be substantially any non-volatile type of memory device or devices. The microprocessor will probably read a byte of data from the high capacity storage memory 48 at a time, but may also read a word of data or more depending on what is appropriate for the architecture.

[0035] At step 104, after the byte is read, the byte is used as part of the SHA-1 hash calculation (or whatever type of hash or other calculation is being performed to authenticate the raw media). At step 106 the process checks to determine whether a file verification is in progress because the byte read may or may not be part of a file (as opposed to being part of a pointer or other non-file or related data found in the high capacity storage memory 48). If file verification is not in progress, then the process goes to step 116 and it is determined whether the byte was the last byte of the raw media. If it is not the last byte of the raw media, then the process returns to step 102.

[0036] Back at step 106, if a file verification is in process, meaning that if the byte is part of a file, then the yes path is taken. At step 108, the operating system's file system is emulated by the microprocessor 32, with the help of the boot memory 46, and it is determined what file the byte belongs to.

[0037] At step 110, the SHA-1 hash for the determined file is calculated or recalculated and updated using the additional file byte. In this manner, the hash calculations for the raw media and the files contained in the raw media are being performed substantially simultaneously, in parallel and/or in a time shared manner. The hash calculation for the raw media and the files contained within the raw media are being performed as a result of a single read of the raw media. Multiple reads of the raw media or data contained in the high capacity storage memory are not required in order to update and calculate respective hash calculations for both the total raw media and the files within the raw media.

[0038] At step 112, the byte is mapped to the main memory 36 (executable memory) and associated with its correct program file. Once mapped the bytes are copied to their mapped location in the main memory By mapping and copying the file bytes to executable memory here an additional read of the high capacity storage memory 48 is avoided. Since the file system was emulated in step 108, the microprocessor can determine and map where in executable memory the byte belongs in order for the byte to be associated with its appropriate software/firmware file. In other exemplary embodiments of the invention the bytes may be cached until after their associated file is verified and then copied to the main memory. This copying of the file(s) may be done at the end of the file signature valid step 120 or the end of file verification step 124 or possible other places in the exemplary flow diagram. Furthermore, the memory in which the bytes are being read from may also be an executable non-volatile memory. If the storage memory 48 is the executable memory, then the mapping and copying of the bytes may not be necessary.

[0039] At step 114, the process determines whether the byte is the last byte of the file. If it is not the last byte, then at step 116 the process determines whether the end of the raw media has been reached. If the end has not been reached then the process returns to step 102 and reads the next byte of data.

[0040] Back at step 114, if the process determines that the byte is the last byte of a file, then the hash calculation performed at step 110 should be the complete hash for the file. At step 118 the hash calculation result is used, along with a public key in a DSA, to verify the signature for the file. In an exemplary embodiment a digital signal algorithm (DSA) is used to verify the signature of the file. It is understood that it is possible to verify a file using various types of verification processes from a simple checksum calculation of all the bytes in the file to a hash calculation and on to a public key/private key DSA technique. At step 120, if the signature is not valid then the authentication process for the high capacity storage memory fails at step 130. On the other hand, if the file signature is determined to be valid then at step 122, the process determines if the file is the last file to be validated. If the file is not the last file to be validated, then the process determines if the last byte of media has been read at step 116 and returns to step 102 to read the next byte of raw media.

[0041] At step 122 the process determines whether or not the file is the last file that needs to have its signature verified. Then, at step 124 the file verification process is completed and if the software files have not been loaded in 112 or 120, then the files are loaded into the main memory 36. In effect any additional raw media reads will not be a byte that belongs to a file. Therefore, since all the files have been verified, the files can be loaded into main memory 36 and/or the battery backed memory 38.

[0042] With file verification completed, the process again checks if all the bytes of raw media have been verified. If there are additional bytes then the process goes back to perform another raw media byte read at step 102. If there are no more bytes of media to read, then the process has completed calculating the hash for the raw media (step 110) and is ready to perform the digital signature algorithm (DSA) in order to verify the media signature at step 126. At step 128 if the raw media signature is not valid then the authentication process fails at step 130 and the gaming machine's software does not boot up. On the other hand, if the raw media signature is valid, then both the files and the raw media are deemed valid. The validation and authentication process for booting or resetting the exemplary gaming machine is complete and the system can boot-up at step 132.

[0043] In yet another embodiment of the present gaming machine validation and authentication process, the files stored in the high capacity storage memory 48 are stored contiguously rather than using the more usual non-contiguous file storage technique that utilizes file pointers for files that are divided into portions throughout the memory media. By storing the files contiguously in the memory media 48, then each file can be copied to main memory 36 immediately after each file is verified. Furthermore, the file system emulation step may be simplified or eliminated based on the microprocessor being able to look up exactly where each file starts and ends without the need for a file emulation functionality. A look-up table may be all that is necessary. As such, each entire file could be checked for its hash and signature easily while the hash for the entire raw media is being calculated.

[0044] While the present invention has been described with reference to one or more particular embodiments, those skilled in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present invention. Each of these embodiments and obvious variations thereof is contemplated as falling within the spirit and scope of the claimed invention, which is set forth in the following claims.