US20070021195A1

US20070021195A1 - Gaming system file authentication

Info

Publication number: US20070021195A1
Application number: US11/425,831
Authority: US
Inventors: Steven Campbell; Chad Ryan
Original assignee: Individual
Current assignee: LNW Gaming Inc
Priority date: 2005-06-24
Filing date: 2006-06-22
Publication date: 2007-01-25

Abstract

A gaming system utilizes watermarks in files to provide file authentication. In one embodiment, the files contain images or video clips. Selected frames of such images or video clips contain a watermark, which is compared to a key stored in the gaming system. The key may be stored in a non-volatile random access memory in the gaming system. In one embodiment, the memory is not modifiable by a customer.

Description

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. 119(e) from U.S. Provisional Application Ser. No. 60/694,056 filed Jun. 24, 2005, and from U.S. Provisional Application Ser. No. 60/711,510 filed Aug. 26, 2005, both of which applications are incorporated herein by reference.

COPYRIGHT

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 2006, WMS Gaming, Inc.

FIELD

The present invention related to gaming systems, and in particular to file authentication in a gaming system.

BACKGROUND

Gaming devices are highly regulated to ensure that they are operating properly, and within regulation. Many jurisdictions required that all gaming devices which have control programs residing in one or more conventional read only memory (ROM) devices must employ a mechanism to verify control programs and data. The mechanism used must detect at least 99.99 percent of all possible media failures. If these programs and data are to operate out of volatile random access memory (RAM), the program that loads the RAM must reside on and operate from a Conventional ROM Device.
Gaming devices having control programs or data stored on memory devices other than conventional ROM devices may need to employ a mechanism that verifies that all control program components, including data and graphic information, are authentic copies of the approved components. Tests may be required to verify that components are approved components. The verification mechanism must have an error rate of less than 1 in 10 to the 38th power and must prevent the execution of any control program component if any component is determined to be invalid. Any program component of the verification or initialization mechanism must be stored on a conventional ROM device that must be capable of being authenticated.
A method used for authentication should employ a mechanism which tests unused or unallocated areas of any alterable media for unintended programs or data and tests the structure of the storage media for integrity. The mechanism must prevent further play of the gaming device if unexpected data or structural inconsistencies are found.
Any gaming device executing control programs from electrically erasable or volatile memory must employ a mechanism that ensures the integrity of all control program components residing therein, including fixed data and graphic information and ensures that they are authentic copies of the approved components. Additionally, control program components, excluding graphics and sound components, must be fully verified at the time of loading into the electrically erasable or volatile memory and upon any significant event, including but not limited to door closings, game resets, and power up. The mechanism must prevent further play of the gaming device if an invalid component is detected.
These types of mechanisms can make it difficult to quickly modify gaming content in gaming machines. They can require the presence of a technician each time a game is updated or changed on a gaming device, which can lead to delays in updating games, introducing new games, and add to down time for gaming machines.

SUMMARY

A gaming system utilizes watermarks in files to provide file authentication. In one embodiment, the files may contain images, video clips, audio clips, executable code and other information. Selected portions of the files, such as frames of images or video clips contain a watermark, which is compared to a key stored in the gaming system. The key may be stored in a non-volatile random access memory in the gaming system or remotely. In one embodiment, the memory is not modifiable by a customer.
In further embodiments, a watermark may be spread across multiple frames, or may occur in one frame in 30 to 50 frames, corresponding to about one second or more of video. The watermark may change from frame to frame. In one embodiment, a selected number of different watermarks are used, and rotated. The location of the watermark within a portion of a file may be changed randomly from file to file, and may also cover only a portion of the file.
In one embodiment, the watermark is encrypted, and is decrypted as it is read by the gaming system during normal operation or boot. The decrypted watermark is then compared to the key. In a further embodiment, the file is authenticated in real time, as the frames are read, as opposed to authenticating the entire file prior to beginning to display the frames.

DESCRIPTION OF THE DRAWING

FIG. 1 is a block diagram of a gaming machine according to an example embodiment.
FIG. 2A is a block diagram illustrating embedding of watermarks in frames of audio/video files according to an example embodiment.
FIG. 2B is a block diagram illustrating authentication of frames containing watermarks according to an example embodiment.
FIG. 3 is a block diagram illustration of partitions of a disk drive containing files according to an example embodiment.
FIG. 4 is a block diagram illustration of compact flash game card according to an example embodiment.
FIG. 5 is a flow chart illustration of post boot authentication of a watermark database according to an example embodiment.
FIG. 6 is a flow chart illustrating continuous authentication of file frames as frames are displayed according to an example embodiment.
FIG. 7 is a block diagram illustration of a compact flash game card according to a further example embodiment.
FIG. 8 is a flow chart illustrating installation on a hard disk drive according to an example embodiment.
FIG. 9 is a block diagram illustration of partitions of a disk drive containing files according to a further example embodiment.
FIG. 10 is a block diagram illustration of compact flash game card according to a further example embodiment.
FIG. 11 is a flowchart illustration of verification of a hard disk drive authorization table according to an example embodiment.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific embodiments which may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that structural, logical and electrical changes may be made without departing from the scope of the present invention. The following description is, therefore, not to be taken in a limited sense, and the scope of the present invention is defined by the appended claims.
The functions or algorithms described herein are implemented in software or a combination of software and human implemented procedures in one embodiment. The software comprises computer executable instructions stored on computer readable media such as memory or other types of storage devices. The term “computer readable media” is also used to represent carrier waves on which the software is transmitted. Further, such functions correspond to modules, which are software, hardware, firmware or any combination thereof. Multiple functions are performed in one or more modules as desired, and the embodiments described are merely examples. The software is executed on a digital signal processor, ASIC, microprocessor, or other type of processor operating on a computer system, such as a personal computer, server or other computer system.
As used herein, the term casino game or gaming device encompasses, without limitation, slot machines, video poker machines, roulette tables, poker tables, craps tables and any other game of chance offered by a gaming establishment wherein for example the game qualifies as regulated and/or licensed gaming equipment.
A typical gaming system is first described, followed by a description of the use of watermarks in frames of audio, video and/or still images contained in a file. The watermarks may be used to authenticate the frames in real time by comparing them to a key stored on the gaming system, allowing faster initial display of the frames. Watermarks may also be used in other types of files, such as executable files and data files.
As illustrated in FIG. 1, the gaming device 100 includes a coin slot 102 and bill acceptor 124. Players can place coins in the coin slot 102 and paper money or ticket vouchers in the bill acceptor 124. Other devices can be used for accepting payment. For example, credit/debit card readers/validators can be used for accepting payment. Additionally, the gaming device 100 can perform electronic funds transfers and financial transfers to procure monies from house financial accounts. When a player inserts money in the gaming device 100, a number of credits corresponding to the amount deposited is shown in a credit display 106. After depositing the appropriate amount of money, a player can begin playing the game by pulling an arm or by pushing a play button. The play button can be any play activator used by the player to start a game or sequence of events in the gaming device 100.
As shown in FIG. 1, the gaming device 100 also includes a bet display 112 and a “bet one” button. The player places a bet by pushing the bet one button. The player can increase the bet by one credit each time the player pushes the bet one button. When the player pushes the bet one button, the number of credits shown in the credit display 106 decreases by one, and the number of credits shown in the bet display 112 increases by one.
A player may “cash out” by pressing a cash out button 116. When a player cashes out, the gaming device 100 dispenses a number of coins, corresponding to the number of remaining credits, into the coin tray 118. The gaming device 100 may employ other payout mechanisms such as credit slips, which are redeemable by a cashier, or electronically recordable cards, which track player credits.
The gaming device 100 also includes one or more display devices. The embodiment shown in FIG. 1 includes a primary display unit 104 and a secondary display unit 126. In one embodiment, the primary display unit 104 displays a plurality of reels 120. In one embodiment, the gaming device displays three reels, while an alternative embodiment displays five reels. In one embodiment, the reels are in video form. According to embodiments of the invention, the display units can display any visual representation or exhibition, including moving physical objects (e.g., mechanical reels and wheels), dynamic lighting, and video images. In one embodiment, each reel 120 includes a plurality of symbols such as bells, hearts, fruits, numbers, letters, bars or other images, which correspond to a theme associated with the gaming device 100. Furthermore, as shown in FIG. 1, the gaming device 100 includes a primary sound unit 128 and a secondary sound unit 130. In one embodiment, the primary and secondary sound units include speakers or other suitable sound projection devices.
FIG. 2A is a block flow diagram 200 of a digital watermarking technique that introduces changes to video, image and audio data that are imperceptible to the human eye or ear but easily recoverable by a computer program. Generally, the watermark is a number. The locations in the data where the watermark is embedded are determined by a key, which may also contain a number matching the watermark to verify that the data contains the correct watermark. An original audio/video file is indicated at 210, and is provided to a watermark embedding program 220. A key 230 is also provided for each watermark. The embedding algorithm uses the key to determine which bits of a frame of the audio/video file to modify, resulting in a marked audio/video file 240.
FIG. 2B is a block diagram of a gaming system 250 that utilizes watermarks on audio/video frames in a file. Marked audio/video files 240 are provided to a decoding algorithm 255, which also provides a key 230 for each marked frame in the file. The decoding algorithm 255 extracts the watermarks from the frames and uses the key to verify that frames in the files contain the correct watermarks. Frames that pass the verification are shown at 260, and are available for display by the gaming system 250. If the end of the file, such as a movie, has not been reached at 265, the next frame is extracted and verified at 255. If a frame is found not to contain the proper watermark, the gaming system, such as a gaming machine halts execution at 270.
In one embodiment, a commercial software product is used to insert watermarks into selected frames of files, such as audio/video files. One watermark may be inserted into each frame, or selected frames, such as every 30^thto 50^thframe, corresponding to one or more seconds of audio video when viewed by a user. The watermark may be the same or different for each frame, or may comprise a sequence of watermarks that may be repeated, or randomized. Keys are stored on the gaming system, such as in a compact flash read only card that is inserted into the gaming system. The keys should match up with the watermarks. The keys may identify locations in the frames where watermark numbers are placed, and also contains an identifier of the watermark, such as a sequence of matching numbers. In some embodiments, the watermark is encrypted, and when read, is decrypted prior to matching it to the number sequence in the corresponding key. The watermark may alternatively be digitally signed, with the signature verified prior to matching it.
During operation of a game, as audio/video frames are read, they are checked to ensure they contain the proper watermark. In one embodiment, an incorrect watermark may place the game in a halt state, showing a call attendant message on the screen. Normal operation is not possible without intervention by an attendant. In further embodiments, two consecutive incorrect watermarks may be detected prior to the game being placed in the halt state. In still further embodiments, a selected number of incorrect watermarks in a sequence of a predetermined number of watermarks. One example would be two out of three watermarks being incorrect, or two out of four or five watermarks being incorrect. This would allow for software and disk drive errors without prematurely halting a game. Many other examples of a percentage of incorrect watermarks may be envisioned to allow for an acceptable error rate without unnecessarily disrupting the user of a game. In further embodiments, a small percentage of files on boot or continuously during operation of the gaming system are checked for proper watermarking. Portions of files containing watermarks may be randomized from file to file.
FIG. 3 is a block diagram of a storage device 300 for the gaming system. In one embodiment, the storage device comprises a hard disk drive that has been formatted into three partitions. A first partition contains graphics files 310, and may be a read only partition, meaning that a user is not allowed to write to the partition. In other words, the user may not modify information contained on the partition. A second partition contains sound files 320 and may also read only. A third partition is filled with zeros at 330, or other predetermined information to indicate that it is not used. Such information allows the gaming system to determine that the partition has not been modified, as it is also a read only partition. Read/write drives may also be used in further embodiments.
A compact flash memory card is shown at 400 in FIG. 4. The compact flash, or CF, contains game executables at 410, a sound operating system 420, common sound banks 430, watermark database 440, manifest file containing a file signature table (FST) 450, and a digital signature 460 for the whole device. Watermark database 440 contains a key pattern used for comparison on each unique audio/video file contained in the hard drive 300, as well as each file size in one embodiment.
When the gaming system is booted up, a post boot authentication process shown at 500 in FIG. 5 is executed by the gaming system. At 505, the game compact flash, CF, is initialized and verified at 510. If verification fails, the process is stopped at 515. If successfully verified, the watermark database represented at 520 is verified at 525. The hard drive status is checked at 530. For systems not requiring a hard drive, the system will verify that the hard drive is not installed by trying a read/write. An error will indicate that the hard drive is not present, while no error will indicate the presence of the hard drive. This will place the system in a fault state showing a call attendant message on the display screen, and normal operation is not possible without intervention by an attendant. This state is represented at 515.
If the hard drive is present, a read only check is performed at 535 to ensure that the drive is in the proper read only state. Following successful checking of the CF, watermark database and hard drive read only status, each file is opened in succession on the hard drive at 540. If a file is found at 545, it is verified at 550 using the watermarks stored in the watermark database. In one embodiment, approximately 15% of the files are verified at 555 to save time. Other percentages of file verification may be used in further embodiments, either higher or lower depending on the level of assurance of verification desired. If the last file is found at 560, the post boot authentication process is exited and the gaming system continues with other processes at 565.
During normal operation of the game, such as when the game is selected by a user or casino customer, watermark authentication of each audio/video file is performed in real time as illustrated at 600 in FIG. 6. The hard drive 605 is verified as read only at 610. If not read only, the process is stopped at 615, and the game is placed in a halt state, showing a call attendant message on the screen. Normal operation is not possible without intervention by an attendant. Files are then opened at 620 and verified at 625 as being of proper size. Frames in a file are then verified at 630, using the watermark in the frame, and the key from the watermark database. If verified or authenticated at 630, the frame is used during playing of the game at 635. If the end of the file has not been reached at 640, the next frame is verified at 630. The authentication process continues while the game is being played.
In further embodiments, gaming system is coupled to a network. A remote network component may be used to store a watermark database. Results may be retrieved from this database when checking watermarks on files stored on gaming system. The remote network component may generate on demand requests to the gaming system for authentication of the watermarks of the entire gaming system, or a selected portion of the gaming system, such as a single file, portion of a file, disk drive or other portion of the gaming system.
An installation to hard drive method utilizes a game CF as shown in FIG. 7. The game CF comprises multiple sections, including compressed files to be installed to hard drive section 710, game executables 720, sound operating system 730, watermark database 740, manifest file containing FST 750 and digital signature for the whole device 760.
The method for installation to hard drive is shown at 800 in FIG. 8. Installation in one embodiment occurs when a RAM CLEAR is performed. After the RAM CLEAR, the system starts by initializing the BOOT CF at 802. It is verified at 804, and if not verified, the process stops at 806 and places the game in a halt state, showing a call attendant message on the screen. Normal operation is not possible without intervention by an attendant.
Following verification of the BOOT CF, the game CF is initialized at 808 and verified at 810. The system then asks for a write protect jumper to be installed at 812. Alternatively, a write enable jumper may be used, such that when added, writing is enabled, and when removed, writing is disabled. Installation is verified as having been done at 814, and the hard drive is formatted and partitioned at 816. This will be done in three partitions as shown in FIG. 3. A full installation is performed onto the hard drive. In one embodiment, it is formatted with full sector checking during installation at a factory, such that checking for bad sectors may not be required during the current installation. This allows for a faster formatting process.
Following formatting and partitioning, the compressed file from the game CF is obtained at 818 and verified at 820. The watermark database is then retrieved at 822 and verified at 824. Then the compressed file is decompressed at 826, and files are verified at 828. Again, in one embodiment, since the files may be very large, a partial authentication of approximately 15% of the files is performed. If the last file has not been processed at 830, the next file is obtained, decompressed and verified until all have been processed. The authentication is performed using the watermark database, which has been verified using a hashing algorithm on the game CF card. The watermark database also contains a size of each file to be tested in one embodiment. In a further embodiment, a file may contain a watermark corresponding to only a portion, such as a small percentage of the file as opposed to the entire file. The location of the portion in each file may be randomized to make the verification process less predictable. More than one watermark may be used on any particular frame or file if desired.
At 832, the system prompts for removal of the write protect jumper, and verifies such removal at 834. A game configure is then started at 836, by performing a power-restart. At this time initial settings of the game machine will be configured. Once this is done, the game is ready to play.
In a further embodiment, the contents of the hard disk drive and CF are indicated at 900 and 1000 in FIGS. 9 and 10 respectively. The drive 900 or other type of storage device is read only in one embodiment, and has four partitions. Graphics files are in a first partition at 910. Sound files are in partition 920. A read/write area in partition 930 contains a hard disk drive authorization table, and a fourth partition 940 is used for the remaining portion of the drive that is not needed, and is filled with zeros.
CF 1000 contains game executables 1010, a sound operating system 1020, common sound banks 1030, a watermark database containing a hard disk drive encryption key 1040, a manifest file containing a FST 1050, and a digital signature for the entire device at 1060. The watermark database contains the key pattern used for comparison on each unique audio/video file contained on the hard drive, as well as each file size.
The hard disk drive authorization table may contain the file name, date/time created, file information such as type and validation technique, and an indication of whether the file is closed or not closed. Once a file is written to the hard drive, it becomes closed. If anything happens to the machine while writing to the hard drive, the file is considered not closed. Any not closed file will have a time/date stamp written to the hard disk drive authorization error log table. The authorization table may be encrypted to the hard drive encryption key. The file may be displayable through an operator menu of a game.
The hard drive encryption key will verify that the hard disk drive authorization table exists and may be used to verify that all files are contained in the authorization table. In the event of a failed authentication, the device will enter an error condition.
If a file is found in the hard disk drive authorization error log table that is not critical, such as files that do not affect game play, operation, or outcome, the file in question is deleted from the hard drive and a time/date stamp is written into the authorization error log table. Once the authorization error log table is cleared, verification of the authorization table is performed before returning to the game. Critical files, such as those that affect game play, operation, or outcome require operator intervention.
If further authentication of the authorization table is required, the table may be made redundant. In one embodiment, it may be set up with two equal sized partitions, keeping identical copies of the data. At regular intervals in each partition are special numbers, called checksums. When power is re-supplied to a game terminal, the checksums are recomputed and compared to the values stored. A hash algorithm may also be used to produce a message digest, or some other algorithm that produces a result which can be compared to verify the data is what is expected. If one partition is found to have errors, a recover attempt may be made by copying the good partition to the partition with an error. After copying, another result may be calculated and if successful, the game is allowed to continue.
A random check of partition four at 940 may be performed to ensure that zeros are found in different locations. If there is any authentication failure, the system starts up in a fault state showing a call attendant message on the screen, and normal operation is not possible without intervention by an attendant.
FIG. 11 illustrates the above summarized use of the authorization table. At 1102, the game CF is initialized and verified at 1104. If verification is not successful, the game is stopped at 1106. The same is true for further verification steps shown in FIG. 11. The hard drive status is checked at 1108. Read write status is verified at 1110 and if not proper for each partition, the game is stopped at 1106. Otherwise, the hard disk drive encryption key is read at 1112 and verified at 1114. If properly verified, the authorization file is read at 1116 and verified at 1118. If properly verified, each file is checked to see that it exists at 1120 and then the files in the authorization table are opened at 1122. If the last file has been read, as indicated at 1124, files in the authorization error log table are opened at 1126. If a file was not correctly deleted, it is automatically deleted at 1130, and the authorization error log table file is updated. Processing then proceeds back to 1120, where each file in the authorization table is opened.
If the error file was correctly deleted at 1128, a check is made to see if it was the last error file at 1132. Each file is checked in a loop including 1128 and 1132 until the last file has been checked as indicated at 1132. The game is then allowed to continue at 1134.
In this embodiment, continuous run time authentication occurs in a manner similar to that illustrated in FIG. 6.

Claims

1. A gaming machine implemented method comprising:

reading a frame from a file;

extracting a watermark from the frame; and

comparing the extracted watermark to a key to authenticate the frame.

2. The method of claim 1 wherein the file comprises audio/video information stored on the gaming machine.

3. The method of claim 1 wherein a frame or file contains more than one watermark.

4. The method of claim 1 wherein the file comprises multiple audio/video frames, and wherein every nth frame contains a watermark, wherein n ranges between approximately 30 to 50.

5. The method of claim 1 wherein authentication is performed continuously while reading frames from a file.

6. The method of claim 5 and further comprising outputting frames from the files to users of the gaming machine as selected frames are authenticated.

7. The method of claim 1 and further comprising stopping execution of a game when an extracted watermark does not successfully compare to a corresponding key.

8. The method of claim 1 wherein a small percentage of files are authenticated during a boot of the gaming machine.

9. The method of claim 1 wherein at least one frame from each file is authenticated on boot or continuous running of the gaming machine.

10. The method of claim 9 wherein the location of a watermark in a file is randomized from file to file.

11. A method of authenticating a file in a gaming system, the method comprising:

reading multiple frames from the file;

extracting a watermark from one of the frames;

comparing the extracted watermark to a key stored on the gaming system to authenticate the frame.

12. The method of claim 11 wherein a watermark is stored in one of approximately thirty consecutive frames.

13. The method of claim 11 wherein frames have different watermarks.

14. The method of claim 13 wherein the different watermarks comprise a sequence of different watermarks that are repeated.

15. The method of claim 11 wherein the watermark is encrypted, and wherein extracting the watermark further comprises decrypting the watermark.

16. The method of claim 11 wherein the key is stored on a memory device that is not accessible to users of the gaming system.

17. A computer readable medium having instructions encoded thereon for execution by a gaming machine for implementing a method comprising:

reading a frame from a file;

extracting a watermark from the frame; and

comparing the extracted watermark to a key to authenticate the frame.

18. The method of claim 17 wherein a file contains multiple frames, and wherein a watermark is stored in one of approximately thirty consecutive frames.

19. The method of claim 17 wherein the watermark is encrypted, and wherein extracting the watermark further comprises decrypting the watermark.

20. The method of claim 17 wherein the key is stored on a memory device that is not accessible to users of the gaming system.

21. A computer readable medium having code for execution on a gaming system, the medium comprising:

a file having multiple frames containing images for display on the gaming system, selected frames having watermarks corresponding to keys stored on the gaming system, wherein the gaming system extracts the watermarks from the selected frames and compares them to the keys for authentication of the frames in real time.

22. A gaming machine comprising:

a storage device having a read only audio/video file containing multiple frames of audio/video information, selected frames having a watermark;

a read only memory device having keys corresponding to watermarks in the selected frames; and

an authentication module that when executed by the gaming machine, authenticates the selected frames by comparing the watermarks to the keys while outputting the frames to the user.

23. The gaming machine of claim 22 wherein the storage device comprises a hard disk drive and the memory device comprises a game compact flash card.

24. A gaming machine implemented method comprising:

reading data from a file;

extracting a watermark from the data; and

comparing the extracted watermark to a key to authenticate the file.

25. The gaming machine implemented method of claim 24 wherein the data read from the file is selected from the group consisting of audio, video, still image, executable code, and information stored on the gaming machine.

26. The gaming machine implemented method of claim 24 wherein a frame or file contains more than one watermark.

27. The gaming machine implemented method of claim 24 wherein a small percentage of files are authenticated during a boot of the gaming machine.

28. The gaming machine implemented method of claim 24 wherein multiple files in the gaming system are authenticated, and wherein the location of the watermarks in files is randomized from file to file.