U.S. patent application number 11/425831 was filed with the patent office on 2007-01-25 for gaming system file authentication.
Invention is credited to Steven Mark Campbell, Chad A. Ryan.
Application Number | 20070021195 11/425831 |
Document ID | / |
Family ID | 37679757 |
Filed Date | 2007-01-25 |
United States Patent
Application |
20070021195 |
Kind Code |
A1 |
Campbell; Steven Mark ; et
al. |
January 25, 2007 |
GAMING SYSTEM FILE AUTHENTICATION
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.
Inventors: |
Campbell; Steven Mark; (Las
Vegas, NV) ; Ryan; Chad A.; (Henderson, NV) |
Correspondence
Address: |
SCHWEGMAN, LUNDBERG, WOESSNER & KLUTH, P.A.
P.O. BOX 2938
MINNEAPOLIS
MN
55402
US
|
Family ID: |
37679757 |
Appl. No.: |
11/425831 |
Filed: |
June 22, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60694056 |
Jun 24, 2005 |
|
|
|
60711510 |
Aug 26, 2005 |
|
|
|
Current U.S.
Class: |
463/29 |
Current CPC
Class: |
G07F 17/32 20130101;
G07F 17/3241 20130101; G07F 17/323 20130101 |
Class at
Publication: |
463/029 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
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.
Description
RELATED APPLICATIONS
[0001] 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
[0002] 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
[0003] The present invention related to gaming systems, and in
particular to file authentication in a gaming system.
BACKGROUND
[0004] 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.
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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
[0009] 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.
[0010] 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.
[0011] 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
[0012] FIG. 1 is a block diagram of a gaming machine according to
an example embodiment.
[0013] FIG. 2A is a block diagram illustrating embedding of
watermarks in frames of audio/video files according to an example
embodiment.
[0014] FIG. 2B is a block diagram illustrating authentication of
frames containing watermarks according to an example
embodiment.
[0015] FIG. 3 is a block diagram illustration of partitions of a
disk drive containing files according to an example embodiment.
[0016] FIG. 4 is a block diagram illustration of compact flash game
card according to an example embodiment.
[0017] FIG. 5 is a flow chart illustration of post boot
authentication of a watermark database according to an example
embodiment.
[0018] FIG. 6 is a flow chart illustrating continuous
authentication of file frames as frames are displayed according to
an example embodiment.
[0019] FIG. 7 is a block diagram illustration of a compact flash
game card according to a further example embodiment.
[0020] FIG. 8 is a flow chart illustrating installation on a hard
disk drive according to an example embodiment.
[0021] FIG. 9 is a block diagram illustration of partitions of a
disk drive containing files according to a further example
embodiment.
[0022] FIG. 10 is a block diagram illustration of compact flash
game card according to a further example embodiment.
[0023] FIG. 11 is a flowchart illustration of verification of a
hard disk drive authorization table according to an example
embodiment.
DETAILED DESCRIPTION
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.sup.th to 50.sup.th frame,
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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] In this embodiment, continuous run time authentication
occurs in a manner similar to that illustrated in FIG. 6.
* * * * *