(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2005/0009599 A1
`Ryan
`(43) Pub. Date:
`Jan. 13, 2005
`
`US 2005OOO9599A1
`
`(54) GAMING MACHINE HAVING TARGETED
`RUN-TIME SOFTWARE AUTHENTICATION
`
`(57)
`
`ABSTRACT
`
`(76) Inventor: Chad A. Ryan, Lisle, IL (US)
`Correspondence Address:
`ENSN SEER P.C.
`SUTE 2600
`CHICAGO, IL 60606 (US)
`9
`(21) Appl. No.:
`10/616,459
`
`(22) Filed:
`
`Jul. 9, 2003
`Publication Classification
`
`(51) Int. Cl." ..................................................... A63F 13/00
`(52) U.S. Cl. ................................................................ 463/29
`
`
`
`A gaming machine that authenticates its gaming Software
`Substantially continuously and repetitiously while the gam
`Ing machine ls powered on. A processor, while running the
`gaming machine's gaming program, determines whether the
`data in each of a plurality of memories is authentic. The
`processor may read multiple memories in a parallel fashion
`while making memory contents authenticity determinations.
`The processor may also read multiple memories in a Serial
`fashion while making memory contents authenticity deter
`minations. The processor may also read Same memories in
`a parallel fashion and read other memories in a Serial fashion
`while determining the authenticity of each memory's con
`tents. Furthermore, the contents of a memory may be
`analyzed to decipher between executable data and graphics
`data Such that the executable data's authenticity is deter
`mined more often than the graphics data's authenticity
`
`IPR2020-01218
`Sony EX1009 Page 1
`
`

`

`Patent Application Publication Jan. 13, 2005 Sheet 1 of 3
`
`US 2005/0009599 A1
`
`
`
`IPR2020-01218
`Sony EX1009 Page 2
`
`

`

`Patent Application Publication Jan. 13, 2005 Sheet 2 of 3
`
`US 2005/0009599 A1
`
`30
`
`MICRO
`PROCESSOR N52
`
`MAN
`MEMORY
`
`
`
`BATTERY
`BACKED
`MEMORY
`
`36
`
`3B
`
`VIDEO
`CIRCUITRY
`
`40
`VIDEO OUT
`59
`
`c.A.R.
`
`AUDIO OUT
`42
`
`I/O
`CONTROL
`
`I/O
`44
`
`
`
`
`
`
`
`
`
`
`
`OTTERY TERMINAL
`
`80
`
`BOOT MEMORY
`HICH CAPACY STORACE MEMORYY (SERIAL READ-WRTE NEMOR
`52
`BOOT CODE
`GAME AND OPERATING
`54 N. SYSTEM EXECUTABLE
`in
`SYSTEM
`
`||
`E.
`
`
`
`JURISDICTION BIT CODE--88
`OPTIONS
`JURISDICTION MAX BET --90
`
`92
`
`94 .
`
`
`
`JURSOCTION MAX. WN
`UNUSED SPACE
`ZERO FILLED
`56N DIGITAL SIGNATURE
`WH
`CE
`(WHOLE DEVICE)
`50
`
`62
`
`
`
`
`
`
`
`||
`CE.
`
`56
`
`
`
`
`
`58
`
`DECOMPRESSION
`UTILITY
`UNUSED SPACE-
`ZERO FILLED
`DIGITAL SIGNATURE
`(WHOLE DEVICE)
`
`UNUSED SPACE-
`ZERO FILLED
`WAN
`FEST YES
`(GIASCNAIRES
`DCTAL SIGNATURE
`(WHOLE DEVICE)
`
`46
`
`78
`
`48
`FIG. 2
`
`IPR2020-01218
`Sony EX1009 Page 3
`
`

`

`Patent Application Publication Jan. 13, 2005 Sheet 3 of 3
`
`US 2005/0009599 A1
`
`100
`
`102
`Reod
`Foils Read High Capacity
`Storage Memory and
`Codculote SHA-1
`
`Moin Application Launched
`from System SDRAM
`B
`Authenticote SP EEPROM
`Poss
`107
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`n Won
`Memory
`File Type=
`
`Timer
`Count Down
`= 0
`
`Executable file
`In Systern SDRAM
`
`Authenticote
`Non-Executoble Fie
`
`Continuous
`Run-Time
`Authenticqtion
`Process
`
`The Cycle above handles
`both the Compqct Flush
`Autheritication qnd it
`verifies that the Compact
`Flosh card is present. The
`CF Cord is Occessed
`opproximately every 15ms.
`Any unsuccessful read
`hotts the mochine,
`
`Verify NVRAM CRC's
`Areas and Main/Aux
`Copies
`
`Display Critical
`
`O
`
`IPR2020-01218
`Sony EX1009 Page 4
`
`

`

`US 2005/0009599 A1
`
`Jan. 13, 2005
`
`GAMING MACHINE HAVING TARGETED
`RUN-TIME SOFTWARE AUTHENTICATION
`
`REFERENCE TO RELATED APPLICATIONS
`0001. This application is related to U.S. patent applica
`tion Ser. No. 10/119,663 filed on Apr. 10, 2002, entitled
`"Gaming Software Authentication', and incorporated herein
`by reference in its entirety.
`
`FIELD OF THE INVENTION
`0002 The present invention relates generally to gaming
`machines, and more particularly, to Software authentication
`of programs running in a gaming machine.
`
`BACKGROUND OF THE INVENTION
`0003. As a regulatory requirement in virtually all juris
`dictions that allow gaming, it is necessary to have a tech
`nique to authenticate that the Software installed in a gaming
`machine is tested and approved. In the past, gaming manu
`facturers have generally used EPROM-based hardware plat
`forms 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 tech
`niques 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
`wherein a gaming agent periodically visits a casino and
`pickS machines for the removal of 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), elec
`trically 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.). Storage media comprises a memory
`device and the data Stored thereon. Authentication of Storage
`media is controlled by the gaming device's central proceSS
`ing 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, the authenticity of numerous storage
`devices associated with the CPU may need to be determined
`
`every So often while a gaming machine is running. In Some
`cases, gaming authorities require that a gaming program be
`authenticated about every ten minutes while the gaming
`machine is running. To determine the authenticity of a
`memory device's contents the CPU must read the memory
`device and perform various calculations and comparisons to
`determine if the memory device's contents are authentic.
`Reading many memory devices or large memory devices
`can use Significant CPU time and therefore may negatively
`affect the responsiveness of the gaming program that a user
`interacts with. What is needed is a technique for authenti
`cating memory devices associated with a gaming machine
`that does not affect the gaming program that the user
`interacts with.
`
`SUMMARY OF THE INVENTION
`0007 Embodiments of the present invention authenticate
`a gaming machine program, Software, firmware, or data
`(data) Stored in memory devices within the gaming machine
`while the gaming machine is running and interacting with a
`user. The authentication proceSS does not slow or interfere
`with the gaming program that interacts with the user. The
`authentication processes are ongoing and are Substantially
`continuously repetitive. The authentication processes may
`substantially repeat every 2 minutes to 24 hours. Further
`more, in order to increase the Speed of authenticating Some
`of the data, graphics data may be differentiated from execut
`able data So that the authenticity of the executable data can
`be determined more often than the graphics data.
`0008. It should be understood that for the purposes of this
`description of exemplary embodiments of the present inven
`tion that the gaming machine program may be either com
`piled or uncompiled. Furthermore the gaming machine
`program comprises code, files, instructions or programs that
`are executable in that they direct the gaming machine to do
`Something (hereinafter “executable code”). The gaming
`machine program further comprises graphics code, files,
`data, instructions or programs (herein after "graphics data')
`that have to do with graphics or multimedia applications.
`Such graphics or multimedia may include, but are not
`limited to, data or information used to control graphics,
`animation, or other special effects that move air, move fluids,
`create Smells, create bubbles, create flashing lights, control
`laser lights, control air preSSure, control temperature, control
`mechanical devices, or control Sound devices.
`0009. In an embodiment of the present invention a gam
`ing machine comprises a user interface and a central pro
`cessing unit (CPU) coupled to the user interface. The CPU
`comprises a processor. A first memory is coupled to the
`processor. The first memory is adapted to contain executable
`program code. The executable program code has both
`executable instructions and graphics data. A Second memory
`is also coupled to the processor. The Second memory Stores
`data. The executable instructions found in the first memory
`include a plurality of instructions configured to cause the
`processor to determine the authenticity of the executable
`program code and the data. The processor, with the aid of the
`executable instructions, determines the authenticity of the
`executable program and the data on a Substantially continu
`ous, repetitious basis. Furthermore, the authenticity deter
`mination of the executable program code might be per
`formed Substantially in a parallel proceSS with the
`authenticity determination of the data.
`
`IPR2020-01218
`Sony EX1009 Page 5
`
`

`

`US 2005/0009599 A1
`
`Jan. 13, 2005
`
`0010. Other executable instructions cause the processor
`to determine, when reading Said executable program code,
`whether executable code or graphics data are being read. If
`the processor is reading graphics data, then the plurality of
`executable code cause Said processor to not determine the
`authenticity of the graphics data unless more than a prede
`termined number of events have passed since the last time
`the graphics data was authenticated. The events may be
`Seconds, clock count-ups, countdowns, a number of repeti
`tions through a program loop, etc. If the processor reads
`executable instructions, then the plurality of instructions
`cause the processor to determine the authenticity of Said
`executable instructions.
`0011. In another embodiment of the present invention, a
`gaming machine comprises a CPU and a plurality of
`memory devices. The CPU is adapted to determine the
`authenticity of data in at least two of the plurality of memory
`devices in a parallel, repeating manner. The CPU is also
`adapted to read the data Stored in at least one of the plurality
`of memory devices and determine whether the data is
`executable data or graphics data. If the data Stored in a
`memory is determined to be graphics data, then the CPU is
`adapted to determine the authenticity of the graphics data if
`a predetermined number of events have passed. The events
`may be clock cycles, Seconds, count-ups, count-downs,
`passes through a program routine or loop, uses by a user,
`number of games played, etc. If the data Stored in a memory
`is determined to be executable data, then said CPU is
`adapted to determine the authenticity of said executable
`data.
`0012. In another embodiment of the present invention a
`method is provided for authenticating various memory
`devices data within a gaming machine while the gaming
`machine is operating. The authentication process of the
`memory devices data can be performed in Substantially a
`parallel fashion, Such that two or more memory device's
`data is being authenticated at about the same time. The
`method of authenticating also compriseS reading data from
`a first memory device and determining or using other
`techniques to determine whether the data is graphic data or
`executable code. If the data is determined to be graphic data,
`then more data is read from the first memory device. If the
`data is determined to be executable data, then it is deter
`mined whether the executable code is authentic after which
`more data is read from the first memory device.
`0013 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.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0.014. The foregoing and other advantages of the inven
`tion will become apparent upon reading the following
`detailed description and upon reference to the drawings.
`0.015
`FIG. 1 is an isometric view of a gaming machine
`operable to conduct a Wagering game;
`0016 FIG. 2 is an exemplary block diagram of a CPU in
`a gaming machine according to the present invention; and
`0017 FIG. 3 is a flow chart for an exemplary run-time
`authentication process for a gaming machine.
`
`0018 While the invention is susceptible to various modi
`fications 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.
`0019 Description of Illustrative Embodiments
`0020 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 embodi
`ment, 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.
`0021. The gaming machine 10 includes a plurality of
`possible credit receiving mechanisms 14 for receiving cred
`its 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 (chips) cards coded with money or
`designating an account containing money.
`0022. 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 pro
`Vided 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.
`0023 Referring now to FIG. 2, 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, mechani
`cal 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.
`
`IPR2020-01218
`Sony EX1009 Page 6
`
`

`

`US 2005/0009599 A1
`
`Jan. 13, 2005
`
`0024. The CPU 30 includes a microprocessor 32 and
`various memory devices is (media devices). The micropro
`ceSSor 32 interfaces with many other components of the
`gaming machine 10 via an interface bus 34. A main memory
`36 Stores the compiled gaming machine program for oper
`ating the gaming machine 10.
`0025. The main memory 36 may be DRAM or SRAM or
`Substantially any other volatile memory device or repro
`grammable 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 or rewritable non-volatile memory
`device. The video circuitry 39 Supplies display information
`to a video display 12 that 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, multimedia devices, etc.
`0026. 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 or
`appropriately sized programmable read-only memory. The
`boot memory 46 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, DVD drive, magnetic RAM, battery
`backed RAM 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.
`0027. The boot memory 46 stores, at least some of the
`following, 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 verification algorithm 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 a 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 (although this is very
`unlikely). The non-uniqueness of the hash value for each
`item in the message digest is acceptable because each hash
`value is used to evaluate a different file or data Set within a
`memory device. The message digest is a Small representa
`tion of a large amount of data. A message digest is a
`relatively unique representation of data, from a crypto
`graphic Standpoint, and is an irreversible representation of
`the data. In other words, one cannot recreate the original data
`from the message digest.
`0028. The digital signature 58 is generated, in effect,
`from the boot memory's contents as a whole. In an exem
`plary 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 Verifi
`cation 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 are used to create an original
`Signature associated with the original message digest. The
`public key, the original Signature, and a calculated message
`digest are used to check a signature associated with a
`message digest in order to determine the origin and authen
`ticity of the data Set. 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 of the boot memory con
`tents. Again, the Signature may be used to determine the
`Source or manufacturer of the message digest, via a public
`key, but cannot be used to recreate the message digest or the
`original data. Furthermore, the DSA is not being used here
`as an encryption process under FIPS 186-2, but rather a
`technique for validating the Signature associated with the
`data Set, and the public key.
`0029. 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 file list of file types 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.
`0030 The serial read-write memory 50 stores informa
`tion/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.
`0031) The boot memory 46, serial read-write memory 50
`and high capacity Storage memory 48 may each be remov
`able devices and/or contain alterable Software. Each of these
`memory devices may be able to be reprogrammed or be able
`to receive downloaded 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 network
`ing 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.
`0032. In order to better understand the advantages of an
`exemplary run-time authentication algorithm, it is important
`
`IPR2020-01218
`Sony EX1009 Page 7
`
`

`

`US 2005/0009599 A1
`
`Jan. 13, 2005
`
`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
`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 during run-time operations
`has increased because the methods required to authenticate
`the Software content became more complex. An increase in
`the time required to authenticate the Software during
`machine run-time operations may affect the responsiveness
`and Speed of the run-time Software as well as the SmoothneSS
`of operation to the extent that it is noticeable to the user. A
`CPU may become unable to effectively operate the gaming
`machine main program while multiplexing authentication
`processes are taking place due to the sheer Size of the main
`program that must be authenticated within a predefined
`period of time. Thus, it is necessary to provide a technique
`to authenticate the gaming programs and media within
`various media devices without slowing or disturbing the
`operation of the gaming machine.
`0033. An exemplary run-time authentication comprises
`two main cycles of events during the operation of a gaming
`machine. The first cycle of events checks whether the high
`capacity storage memory 48 is connected to the bus 34. This
`check is performed at predetermined intervals that may
`range from about every 5 ms to about every minute. The first
`cycle also checks whether the high capacity Storage memo
`ry's 48 SHA-1 message digest calculation is continuously
`being recalculated.
`0034. The second cycle of events performs a constant or
`continuous authentication of the boot memory 46, the Serial
`read-write memory 50, the files that are being executed from
`the main memory 36, and the integrity of the data Stored in
`the battery backed memory 38. Utilizing a SHA-1 hash
`message digest of a media device's contents the authenti
`cation of each media device is performed. The authentica
`tion of the media device during a run-time authentication
`may be limited to the data in the whole media device rather
`than the individual files stored in the media device. The
`authentication of a media device may also be performed file
`by file when the CPU has stored the memory locations and
`the type of data in the memory locations prior to an
`authentication process.
`0035). During a boot-up process of the CPU 30 the media
`devices and Software thereon are normally authenticated.
`The boot-up authentication process includes performing a
`SHA-1 hash over the media Software that is loaded into the
`main memory 36, authenticating the digital signature 58,78,
`94, and Storing the calculated hash message digest in battery
`backed memory. Thus, during run-time authentication there
`is no requirement to perform Signature verification Since the
`files and components were proven to be authentic during the
`boot process. One main purpose of run-time authentication
`is so the CPU 30 can check to make Sure that the files and
`data loaded into the main memory 36 during the boot
`proceSS have not been altered. Another purpose of the
`run-time authentication is to verify that certain Software or
`hardware components, Such as the boot memory 46, the high
`capacity Storage memory 48, or the Serial read-write
`
`memory 50 have not been changed or undergone a change
`in any of their software/firmware. In order to check the
`executable code in main memory 36, the boot memory 46,
`the high capacity Storage memory 48, or the Serial read-write
`memory 50 for authenticity, only a SHA-1 hash, or its
`equivalent is necessary Since all had been Verified at boot-up
`to have come from a trusted Source via a digital Signature
`Verification process. It is understood that there are various
`other techniques other than a SHA-1 hash function that
`could be used to verify the authenticity of the various media
`devices during run time. Such other techniques may include,
`but are not limited to, CRC-16, CRC-32, MD5 and check
`Sum techniques.
`0036) As an additional run-time authentication and veri
`fication check, a digital Signature verify operation is per
`formed on the media devices (e.g., main memory 36, boot
`memory 46, high capacity Storage memory 48, and Serial
`read-write memory 50) when the gaming software returns
`from certain gaming events. These events are mainly Secu
`rity events wherein people have had access to the inside of
`the gaming machine or the gaming machine has made a large
`payout. The Security events that may require an additional
`run-time verification and authentication check along with a
`digital signature Verify operation include, but are not limited
`to:
`0037) 1. Any “door closure event'. On a gaming
`machine there may be various doors or hatches for
`providing access to the interior of the gaming machine.
`Anytime one of the doors or hatches is closed, the
`gaming program and other various media devices are
`checked for authenticity because Someone may have
`had access to the interior of the gaming machine.
`0038 2. Any return to game play when exiting the
`“administration Screen'. Various gaming machines
`have an administration mode. There may be one or
`more levels for the administration mode. For example,
`one mode may include critical configuration Settings
`affecting the payouts made by the gaming device and
`may require machine doors or hatches to be accessed to
`gain entry. Another mode may allow an administrator to
`View and Verify meters, event logs, game playtime,
`machine Statistics and other items benign to the func
`tionality of the gaming device without unlocking any
`machine access doors or hatches.
`0039) 3. Any return to game play from a “game dis
`able' State. An attendant, a command from a host
`System, or other internal mechanisms can place the
`gaming machine in a game disable State in order to
`reserve the gaming machine for a certain player or for
`numerous other reasons. ESSentially the gaming
`machine is on, but will not operate until it is taken out
`of the disabled State.
`0040 4. Any cashout handpay state. A cashout hand
`pay is typical when a player would like to cash out of
`gaming machine and the amount of credit or winnings
`on the gaming machine is higher than the amount of
`coins or payout units in the gaming machine's hopper
`or higher than an operator configured machine payout
`limit. If this occurs, the gaming machine may go into a
`cashout handpay State wherein an attendant will have to
`come to the gaming machine and assist the player So
`that the player can get manually paid or handpaid. Once
`
`IPR2020-01218
`Sony EX1009 Page 8
`
`

`

`US 2005/0009599 A1
`
`Jan. 13, 2005
`
`the cashout handpay is completed the attendant will use
`a key, card or other code or device to access the gaming
`machine and exit from the cashout handpay State.
`0041 5. Any Jackpot handpay state. A Jackpot hand
`pay State is similar to the cashout handpay State, except
`the gaming machine is Set to go into a Jackpot handpay
`State when a jackpot hit by the player is above a
`predetermined amount Such as a monetary amount that
`must be reported to Internal Revenue Service (IRS).
`When a jackpot of the predetermined amount or greater
`is hit then the machine locks up and an attendant is
`called to hand pay the player and further to have the
`player fill out the appropriate IRS (W-2G) form(s). The
`attendant can then use a key, card, pass code, or other
`appropriate means to reset the gaming machine into a
`play mode again.
`0042. After a successful verification of all files in main
`memory 36, the battery backed memory 38 is verified using,
`for example, a CRC check. The battery backed memory 38
`can be set to Store two copies of critical data-a first copy
`that is Stored as a master copy and a Second copy that is
`Stored as an auxiliary copy. The master copy program and
`auxiliary copy of the critical data can also be compared to
`each other to help ensure the integrity of the critical data
`being stored in the battery backed memory 38.
`0.043
`FIG. 3 depicts a flow chart of an exemplary
`authentication proceSS for continuous run-time authentica
`tion in accordance with an embodiment of the present
`invention. After boot-up of the