Methods and apparatus for negotiating communications within a gaming network

A gaming system may include a gaming security arbiter, and first and second network gaming devices, each including a processor and a memory operatively coupled to the processor. The arbiter controller may be programmed to receive a request from the first network gaming device for a communication session between the first network gaming device and the second network gaming device, to provide a first encryption key to the first network gaming device and to provide a second encryption key to a second network gaming device. The first controller may transmit the request to the gaming security arbiter, receive the first encryption key, encrypt a message using the first encryption key and transmit the encrypted message to the second network gaming device. The second controller may be programmed to receive the second encryption key, receive the encrypted message and decrypt the encrypted message using the second encryption key.

BACKGROUND

This patent is directed to a casino gaming apparatus, which could be either an individual gaming unit or a casino gaming system having a plurality of gaming units, each gaming unit capable of secure communication within the casino gaming system.

A gaming apparatus of the type used in casinos has included a display unit such as a video display unit or a set of mechanical slot machine reels, a value input device such as a coin slot or paper currency reader, and a controller operatively coupled to the display unit and the value input device and having a processor and a memory operatively coupled to the processor. The controller was programmed to control the overall functions of the gaming machine, including generating game displays representing one or more of a number of casino games, such as poker, blackjack, slots, keno or bingo.

U.S. Pat. No. 6,149,522 to Alcorn, et al. discloses a gaming apparatus of the type described above. The Alcorn, et al. patent also discloses the preparation of gaming data which includes subjecting the gaming data to a hash function to generate a message digest and the subsequently encrypting of the message digest using an encryption key to form an encrypted message digest. Gaming data is authenticated by the gaming apparatus by decrypting the encrypted message digest and then comparing that unencrypted message digest with a hash of the original gaming data. U.S. Pat. No. 5,759,102 to Pease, et al. discloses a method and apparatus for downloading information to a plurality of gaming terminals from a central computer.

SUMMARY OF THE INVENTION

In one aspect, the invention is directed to a gaming system that may include a gaming security arbiter, a first network gaming device and a second network gaming device. The gaming security arbiter may include an arbiter controller that may include a processor and a memory operatively coupled to the processor of the arbiter controller. The arbiter controller may be programmed to receive a request from a first network gaming device, to provide a first encryption key to the first network gaming device and to provide a second encryption key to the second network gaming device. The request may include a request for a communication session between the first network gaming device and the second network gaming device. The first network gaming device may be operatively coupled to the gaming security arbiter and may include a first controller which may include a processor and a memory operatively coupled to the processor of the first controller. The first controller may be programmed to transmit a request to the gaming security arbiter for a communication session with the second network gaming device, to receive the first encryption key from the gaming security arbiter, to encrypt a message with the first encryption key and to transmit the message to the second network gaming device. The second network gaming device may be operatively coupled to the first network gaming device and the gaming security arbiter. The second network gaming device may include a second controller, which may include a processor and a memory operatively coupled to the processor of the second controller. The second controller may be programmed to receive the second encryption key from the gaming security arbiter, to receive the encrypted message from the first network gaming device and to decrypt the encrypted message using the second encryption key.

In another aspect, the invention is directed to a gaming apparatus which may include a display unit, a value input device and a controller operatively coupled to the display unit and the value input device, the controller comprising a processor and a memory operatively coupled to the processor. The controller may be programmed to cause the display unit to generate a game display, to receive a first encryption key from a gaming security arbiter, to encrypt a first message with the first encryption key, to transmit the first encrypted message to a first network gaming device and to determine a value payout associated with an outcome of the game. The game display may relate to one of the following games: poker, blackjack, slots, keno or bingo.

In a further aspect, the invention is directed to a gaming security arbiter operatively coupled to a first network gaming device and a second network gaming device. The gaming security arbiter may include a controller which may include a processor and a memory operatively coupled to the processor. The controller may be programmed to receive a request from the first network gaming device, to provide a first encryption key to the first network gaming device, to provide verification of the authenticity of the first network gaming device to the second network gaming device, and to provide a second encryption key to the second network gaming device. The request may include a request for a communication session between the first network gaming device and the second network gaming device.

In yet another aspect, the invention is directed to a gaming security method performed by a gaming security arbiter. The gaming security method may include receiving a request at the gaming security arbiter from a first network gaming device for a communication session between the first network gaming device and a second network gaming device, providing a first encryption key from the gaming security arbiter to the first network gaming device, providing verification of the authenticity of the first network gaming device to the second network gaming device, and providing a second encryption key from the gaming security arbiter to the second network gaming device.

Additional aspects of the invention are defined by the claims of this patent.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

FIG. 1illustrates one possible embodiment of a casino gaming system10in accordance with the invention. Referring toFIG. 1, the casino gaming system10may include a first group or network12of casino gaming units20operatively coupled to a network computer22via a network data link or bus24. The casino gaming system10may include a second group or network26of casino gaming units30operatively coupled to a network computer32via a network data link or bus34. The first and second gaming networks12,26may be operatively coupled to each other via a network40, which may comprise, for example, the Internet, a wide area network (WAN), or a local area network (LAN) via a first network link42and a second network link44. The gaming units20and network computer26of the first gaming network12may be operatively coupled to an authentication agent or gaming security arbiter46via a network data link or bus47for secure communications among the gaming units20and the network computer22. Likewise, the gaming units30and network computer32of the second gaming network26may be operatively coupled to a second authentication agent or gaming security arbiter48via a network data link or bus49for secure communications among the gaming units30and the network computer32. Each network computer22,32and gaming unit20,30may also use the gaming security arbiters46,48for secure communications across the network40.

The first network12of gaming units20may be provided in a first casino, and the second network26of gaming units30may be provided in a second casino located in a separate geographic location than the first casino. For example, the two casinos may be located in different areas of the same city, or they may be located in different states. The network40may include a plurality of network computers or server computers (not shown), each of which may be operatively interconnected. Where the network40comprises the Internet, data communication may take place over the communication links42,44via an Internet communication protocol.

The network computer22may be a server computer and may be used to accumulate and analyze data relating to the operation of the gaming units20. For example, the network computer22may continuously receive data from each of the gaming units20indicative of the dollar amount and number of wagers being made on each of the gaming units20, data indicative of how much each of the gaming units20is paying out in winnings, data regarding the identity and gaming habits of players playing each of the gaming units20, etc. The network computer32may be a server computer and may be used to perform the same or different functions in relation to the gaming units30as the network computer22described above.

Although each network12,26is shown to include one network computer22,32, four gaming units20,30and one gaming security arbiter46,48, it should be understood that different numbers of computers, gaming security arbiters and gaming units may be utilized. For example, the network12may include a plurality of network computers22, gaming security arbiters46and tens or hundreds of gaming units20, all of which may be interconnected via the data links24,47. The data links24,47may be provided as dedicated hardwired links or wireless links. Although the data links24,47are shown as single data links24,47, the data links24,47may comprise multiple data links.

FIG. 2is a perspective view of one possible embodiment of one or more of the gaming units20. Although the following description addresses the design of the gaming units20, it should be understood that the gaming units30may have the same design as the gaming units20described below. It should be understood that the design of one or more of the gaming units20may be different than the design of other gaming units20, and that the design of one or more of the gaming units30may be different than the design of other gaming units30. Each gaming unit20may be any type of casino gaming unit and may have various different structures and methods of operation. For exemplary purposes, various designs of the gaming units20are described below, but it should be understood that numerous other designs may be utilized.

Referring toFIG. 2, the casino gaming unit20may include a housing or cabinet50and one or more input devices, which may include a coin slot or acceptor52, a paper currency acceptor54, a ticket reader/printer56and a card reader58, which may be used to input value to the gaming unit20. A value input device may include any device that can accept value from a customer. As used herein, the term “value” may encompass gaming tokens, coins, paper currency, ticket vouchers, credit or debit cards, smart cards, and any other object representative of value.

If provided on the gaming unit20, the ticket reader/printer56may be used to read and/or print or otherwise encode ticket vouchers60. The ticket vouchers60may be composed of paper or another printable or encodable material and may have one or more of the following informational items printed or encoded thereon: the casino name, the type of ticket voucher, a validation number, a bar code with control and/or security data, the date and time of issuance of the ticket voucher, redemption instructions and restrictions, a description of an award, and any other information that may be necessary or desirable. Different types of ticket vouchers60could be used, such as bonus ticket vouchers, cash-redemption ticket vouchers, casino chip ticket vouchers, extra game play ticket vouchers, merchandise ticket vouchers, restaurant ticket vouchers, show ticket vouchers, etc. The ticket vouchers60could be printed with an optically readable material such as ink, or data on the ticket vouchers60could be magnetically encoded. The ticket reader/printer56may be provided with the ability to both read and print ticket vouchers60, or it may be provided with the ability to only read or only print or encode ticket vouchers60. In the latter case, for example, some of the gaming units20may have ticket printers56that may be used to print ticket vouchers60, which could then be used by a player in other gaming units20that have ticket readers56.

If provided, the card reader58may include any type of card reading device, such as a magnetic card reader or an optical card reader, and may be used to read data from a card offered by a player, such as a credit card or a player tracking card. If provided for player tracking purposes, the card reader58may be used to read data from, and/or write data to, player tracking cards that are capable of storing data representing the identity of a player, the identity of a casino, the player's gaming habits, etc.

The gaming unit20may include one or more audio speakers62, a coin payout tray64, an input control panel66, and a display unit70. Where the gaming unit20is designed to facilitate play of a video casino game, such as video poker or video slots, the display unit70may be a color video display unit that displays images relating to the particular game or games. Where the gaming unit20is designed to facilitate play of a reel-type slot machine, the display unit70may comprise a plurality of mechanical reels that are rotatable, with each of the reels having a plurality of reel images disposed thereon. The audio speakers62may generate audio representing sounds such as the noise of spinning slot machine reels, a dealer's voice, music, announcements or any other audio related to a casino game. The input control panel66may be provided with a plurality of pushbuttons or touch-sensitive areas that may be pressed by a player to select games, make wagers, make gaming decisions, etc.

FIG. 2Aillustrates one possible embodiment of the control panel66, which may be used where the gaming unit20is a slot machine having a plurality of mechanical or “virtual” reels. Referring toFIG. 2A, if the display unit70is provided in the form of a video display unit, the control panel66may include a “See Pays” button72that, when activated, causes the display unit70to generate one or more display screens showing the odds or payout information for the game or games provided by the gaming unit20. As used herein, the term “button” is intended to encompass any device that allows a player to make an input, such as an input device that must be depressed to make an input selection or a display area that a player may simply touch. The control panel66may include a “Cash Out” button74that may be activated when a player decides to terminate play on the gaming unit20, in which case the gaming unit20may return value to the player, such as by returning a number of coins to the player via the payout tray64.

If the gaming unit20provides a slots game having a plurality of reels and a plurality of paylines which define winning combinations of reel symbols, the control panel66may be provided with a plurality of selection buttons76, each of which allows the player to select a different number of paylines prior to spinning the reels. For example, five buttons76may be provided, each of which may allow a player to select one, three, five, seven or nine paylines.

If the gaming unit20provides a slots game having a plurality of reels, the control panel66may be provided with a plurality of selection buttons78each of which allows a player to specify a wager amount for each payline selected. For example, if the smallest wager accepted by the gaming unit20is a quarter ($0.25), the gaming unit20may be provided with five selection buttons78, each of which may allow a player to select one, two, three, four or five quarters to wager for each payline selected. In that case, if a player were to activate the “5” button76(meaning that five paylines were to be played on the next spin of the reels) and then activate the “3” button78(meaning that three coins per payline were to be wagered), the total wager would be $3.75 (assuming the minimum bet was $0.25).

The control panel66may include a “Max Bet” button80to allow a player to make the maximum wager allowable for a game. In the above example, where up to nine paylines were provided and up to five quarters could be wagered for each payline selected, the maximum wager would be 45 quarters, or $11.25. The control panel66may include a spin button82to allow the player to initiate spinning of the reels of a slots game after a wager has been made.

InFIG. 2A, a rectangle is shown around the buttons72,74,76,78,80,82. It should be understood that that rectangle simply designates, for ease of reference, an area in which the buttons72,74,76,78,80,82may be located. Consequently, the term “control panel” should not be construed to imply that a panel or plate separate from the housing50of the gaming unit20is required, and the term “control panel” may encompass a plurality or grouping of player activatable buttons.

Although one possible control panel66is described above, it should be understood that different buttons could be utilized in the control panel66, and that the particular buttons used may depend on the game or games that could be played on the gaming unit20. If the display unit70is provided as a video display unit, the control panel66could be generated by the display unit70. In that case, each of the buttons of the control panel66could be a colored area generated by the display unit70, and some type of mechanism may be associated with the display unit70to detect when each of the buttons was touched, such as a touch-sensitive screen.

Gaming Unit Electronics

FIG. 3is a block diagram of a number of components that may be incorporated in the gaming unit20. Referring toFIG. 3, the gaming unit20may include a controller100that may comprise a program memory102, a microcontroller or microprocessor (MP)104, a random-access memory (RAM)106and an input/output (I/O) circuit108, all of which may be interconnected via an address/data bus110. It should be appreciated that although only one microprocessor104is shown, the controller100may include multiple microprocessors104. Similarly, the memory of the controller100may include multiple RAMs106and multiple program memories102. Although the I/O circuit108is shown as a single block, it should be appreciated that the I/O circuit108may include a number of different types of I/O circuits. The RAM(s)104and program memories102may be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example.

Although the program memory102is shown inFIG. 3as a read-only memory (ROM)102, the program memory of the controller100may be a read/write or alterable memory, such as a hard disk. In the event a hard disk is used as a program memory, the address/data bus110shown schematically inFIG. 3may comprise multiple address/data buses, which may be of different types, and there may be an I/O circuit disposed between the address/data buses.

FIG. 3illustrates that the control panel66, the coin acceptor52, the bill acceptor54, the card reader58and the ticket reader/printer56may be operatively coupled to the I/O circuit108, each of those components being so coupled by either a unidirectional or bidirectional, single-line or multiple-line data link, which may depend on the design of the component that is used. The speaker(s)62may be operatively coupled to a sound circuit112, that may comprise a voice- and sound-synthesis circuit or that may comprise a driver circuit. The sound-generating circuit112may be coupled to the I/O circuit108.

As shown inFIG. 3, the components52,54,56,58,66,112may be connected to the I/O circuit108via a respective direct line or conductor. Different connection schemes could be used. For example, one or more of the components shown inFIG. 3may be connected to the I/O circuit108via a common bus or other data link that is shared by a number of components. Furthermore, some of the components may be directly connected to the microprocessor104without passing through the I/O circuit108.

Gaming System Security

FIG. 4is a block diagram of a communication topology between a gaming unit20, the network computer22and the gaming security arbiter46. Although only one gaming unit20, one network computer22and one gaming security arbiter46are shown inFIG. 4, it should be understood that the following examples may be applicable to different types of network gaming devices within the gaming network12beyond the gaming unit20and the network computer22, and may include different numbers of network computers, gaming security arbiters and gaming units. For example, a single gaming security arbiter46may be used for secure communications among a plurality of network computers22and tens, hundreds or thousands of gaming units20. Likewise, multiple gaming security arbiters46may be utilized for improved performance and other scalability factors.

Referring toFIG. 4, the gaming security arbiter46may include an arbiter controller120that may comprise a program memory122, a microcontroller or microprocessor (MP)124, a random-access memory (RAM)126and an input/output (I/O) circuit128, all of which may be interconnected via an address/data bus129. The network computer22may also include a controller130that may comprise a program memory132, a microcontroller or microprocessor (MP)134, a random-access memory (RAM)136and an input/output (I/O) circuit138, all of which may be interconnected via an address/data bus139. It should be appreciated that although the gaming security arbiter46and the network computer22are each shown with only one microprocessor124,134, the controllers120,130may each include multiple microprocessors124,134. Similarly, the memory of the controllers120,130may include multiple RAMs126,136and multiple program memories122,132. Although the I/O circuits128,138are each shown as a single block, it should be appreciated that the I/O circuits128,138may include a number of different types of I/O circuits. The RAMs124,134and program memories122,132may be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example.

Although the program memories122,132are shown inFIG. 4as read-only memories (ROM)122,132, the program memories of the controllers120,130may be a read/write or alterable memory, such as a hard disk. In the event a hard disk is used as a program memory, the address/data buses129,139shown schematically inFIG. 4may each comprise multiple address/data buses, which may be of different types, and there may be an I/O circuit disposed between the address/data buses.

As shown inFIG. 4, the gaming unit20may be operatively coupled to the network computer22via the data link24. The gaming unit20may also be operatively coupled to the gaming security arbiter46via the data link47, and the network computer22may likewise be operatively coupled to the gaming security arbiter46via the data link47. Communications between the gaming unit20and the network computer22may involve different information types of varying levels of sensitivity resulting in varying levels of encryption techniques depending on the sensitivity of the information. For example, communications such as drink orders and statistical information may be considered less sensitive. A drink order or statistical information may remain encrypted, although with moderately secure encryption techniques, such as RC4, resulting in less processing power and less time for encryption. On the other hand, financial information (e.g., account information, winnings, etc.) and personal information (e.g., social security number, personal preferences, etc.) may be encrypted with stronger encryption techniques such as DES or 3DES to provide increased security.

As will be disclosed in further detail below, the gaming security arbiter46may verify the authenticity of each network gaming device. The gaming security arbiter46may receive a request for a communication session from a network device. For ease of explanation, the requesting network device may be referred to as the client, and the requested network device may be referred to as the host. The client may be any device on the network12and the request may be for a communication session with any other network device. The client may specify the host, or the gaming security arbiter may select the host based on the request and based on information about the client and potential hosts. The gaming security arbiter46may provide encryption keys (session keys) for the communication session to the client via the secure communication channel. Either the host and/or the session key may be provided in response to the request, or may have been previously provided. The client may contact the host to initiate the communication session. The host may then contact the gaming security arbiter46to determine the authenticity of the client. The gaming security arbiter46may provide affirmation (or lack thereof) of the authenticity of the client to the host and provide a corresponding session key, in response to which the network devices may initiate the communication session directly with each other using the session keys to encrypt and decrypt messages.

Alternatively, as will be disclosed in further detail below, upon receiving a request for a communication session, the gaming security arbiter46may contact the host regarding the request and provide corresponding session keys to both the client and the host. The gaming security arbiter46may then initiate either the client or the host to begin their communication session. In turn, the client and host may begin the communication session directly with each other using the session keys to encrypt and decrypt messages. An additional explanation of the communication request, communication response and key distribution is provided below.

FIG. 5is a flowchart of a key distribution routine140that may be stored in the memory of the arbiter controller120. Referring toFIG. 5, the key distribution routine140may begin operation at block142during which the gaming security arbiter46establishes secure communication channel connections with each of the gaming units20, network computers22, or other devices connected to the network12via the data links47. The secure communication channel may include a secure socket layer (SSL) connection or an Internet Protocol Security (IPSec) connection, for example. As part of establishing the secure communication channels, the gaming security arbiter46may receive a user datagram protocol (UDP) message from a network device requesting the network location of the gaming security arbiter46. The gaming security arbiter46may respond to the network device with a UDP message that includes the Internet Protocol (IP) address of the gaming security arbiter46.

The gaming security arbiter46may further verify the authenticity of the network device by exchanging certificates at block142. The authentication process may be used to verify the identity of the network device and verify that the network device is authorized to communicate over the network12with other network devices. The certificates may be predetermined by the network administrator or other authorized personnel, and may be provided to each network device when configuring the network device to be connected to the network12. The certificate exchange may include an exchange of encryption keys, which may be asymmetric public encryption keys from public-private key pairs such as pretty good privacy (PGP) encryption keys, for subsequent communications between the network device and the gaming security arbiter46. In another example, the asymmetric encryption key pairs may be used to share symmetric encryption keys that may be used for subsequent communications.

In some cases, an authentic network device may nonetheless be denied communications with other network devices. Such decisions may be an override function made by an operator, such as a network administrator, casino operator or other authorized personnel, and may be for a variety of reasons, including, but not limited to, legal and regulatory reasons. The gaming security arbiter46may therefore communicatively disconnect the network device from the network in response to an operator input to prevent the device from communicating with other devices on the network. In addition, restrictions may be established regarding how the network device may communicate. For example, a network device may only be allowed to communicate with a particular group of network devices and/or may be prohibited from communicating with other network devices. The gaming security arbiter46may establish a list of approved network devices and/or a list of unapproved network devices. The list(s) may be associated with a network device to prevent the network device from communicating with other network devices that are either not on the approved list and/or network devices that are on the unapproved list.

In addition to authentication, the network device may inform the gaming security arbiter46of the services, resources and capabilities of the network device. For example, the network device may inform the gaming security arbiter46of capabilities, such as supported encryption methods (e.g., RC4, DES, 3DES), supported compression methods (e.g., zlib, bzip2) and supported data formats (e.g., XML, HTTP, raw binary). Additional services or resources that may be offered may include gaming routines, financial information, player tracking information, etc. The network device may further inform the gaming security arbiter46of what gaming functions may be supported by the network device based on its resources, services and capabilities. Alternatively, the gaming security arbiter46may determine what gaming functions may be supported by the network device based on its resources, services and capabilities. That is, the gaming security arbiter46may maintain data that associates a gaming function with particular resources, services and/or capabilities relating to that gaming function, such that the gaming security arbiter46may receive data regarding a gaming function and determine the resources, services and/or capabilities used to support that gaming function, or vice versa. Gaming functions may include, but are not limited to, accounting, configuring a gaming unit20for a particular player, auditing, and maintenance, for example.

Although encryption keys for communication sessions may be distributed to the communicating network devices in response to a request, as disclosed in further detail below, encryption keys may also be provided to a network device in response to verifying its authenticity. For example, an authenticated network device may be provided with a plurality of encryption keys for subsequent communication sessions. The network device selects an appropriate encryption key based on the communication (e.g., communication type, security level, encryption capabilities, etc.).

Common keys may also be distributed once the secure communication channel has been established for broadcast or multicast communications. A common session key may be designed for broadcast or multicast communications, such as when the network computer22may transmit information, such as a gaming routine update, to all gaming units20, or other instances where information is shared among multiple devices. The common session keys may also be used by the gaming security arbiter46to communicate with two or more network devices. In yet another example, the common session keys may be used for UDP communications. The common session keys may therefore be distributed to all gaming units20, network computers22, etc. that have been authenticated by the gaming security arbiter46. This may occur either upon request of the transmitting device (e.g., the network computer22) or automatically when a network device connects to the network12and completes the authentication process with the gaming security arbiter46.

The secure communication channel and authentication may provide mutual authentication between the gaming security arbiter46and each network gaming device, such as between the gaming security arbiter46and the gaming unit20, and between the gaming security arbiter46and the network computer22. For example, when a network computer22connects to the network12, the network computer22may establish a secure connection with the gaming security arbiter46and inform the gaming security arbiter46of its resources, services and capabilities. The network computer22and the gaming security arbiter46may exchange certificates to verify each other's identity and establish mutual authentication. As a result, each network computer22may establish a secure connection and mutual trust with the gaming security arbiter46. Subsequent communications between the gaming security arbiter46and the network computer22may be encrypted using the encryption keys. The gaming security arbiter46and the gaming unit20may also perform the authentication process and encryption key exchange such that every gaming unit20may establish a secure connection and mutual trust with the gaming security arbiter46. As a result, the gaming unit20may establish an indirect, mutual trust with the network computer22because both the gaming unit20and the network computer22established a mutual trust with the gaming security arbiter46. A similar indirect, mutual trust may be established with any other gaming unit20, network computer22, or other devices that have established a direct mutual trust with the gaming security arbiter46.

Having established a secure communication channel with each device on the network, and having authenticated each network device to verify its identity and authority to communicate over the network12, the gaming security arbiter46may wait until it receives a request for a communication session from a network device at block144. In response to the request, the gaming security arbiter46may provide the client with one or more available hosts and/or one or more encryption keys for the communication session, as disclosed in further detail below. In some cases, the request may accompany or immediately follow the connection of a network device at block142. It is also noted that, in some cases, a request for a communication session may result in an adequate host not being immediately available. This may be for a variety of reasons, including incompatible services, resources or capabilities of existing hosts. However, if an adequate host becomes available and establishes a secure connection with the gaming security arbiter46, as at block142, the gaming security arbiter46may provide the newly connected host with a list of one or more clients for the host to connect to following block142.

The request may relate to a communication session between a gaming unit20and one or more network computers22, between gaming units22for peer-to-peer communications, between network computers22, etc. Although the request may specify a particular host, the request relate to request for a host having a particular service, resource or capability. In one example, the request may inform the gaming security arbiter of a gaming function to be performed by the client. In order to complete the gaming function, the client may require the resources, services and/or capabilities of one or more hosts. By informing the gaming security arbiter46of the gaming function, the gaming security arbiter46may select one or more hosts that provide the resources, services and/or capabilities required by the gaming function.

The request may also include a request for one or more particular pairs of session keys, a request for a particular security level, information regarding the communication type and information regarding the client's capabilities (e.g., supported encryption, compression, data formats), for example. The gaming security arbiter46may use this information to specify a compatible host. In yet another example, the request may inform the network security arbiter46of services or resources that the client may provide along with a request to connect the client to any host that requires those services.

The gaming security arbiter46may verify that the client has been authenticated at block146. If authenticated, as determined at block146, the gaming security arbiter46may search among a list of authenticated network devices for a host to fulfill the request at block148. The gaming security arbiter46may select a host that is most suitable for the client based on the request. For example, if the request includes a request for a communication session with a particular host, and the gaming security arbiter46may determine if the host is connected to the network12and determine if the host is an authenticated network device. If the request includes a request for a particular service, resource and/or capability, the gaming security arbiter46may select a host that fulfills the requested service, resource and/or capability based on information provided by a host when it informs the gaming security arbiter46of resources, services and capabilities that the host provides. A request regarding a client gaming function may also result in the gaming security arbiter46selecting a host that may provide a service, resource or capability to fulfill the gaming function.

In yet another example, if the client provides particular services, resources or capabilities and requests a host in need of those services, resources or capabilities, the network security arbiter46may select a host that may require the provided service, resource or capability. The gaming security arbiter46may further select a host based on the capabilities of the client based on information previously received from the client, such as at block142. For example, if the client only supports an XML data format, the gaming security arbiter46may search for a host capable of the XML data format at block148, as opposed to a host capable of only HTTP and/or raw data formats. The gaming security arbiter46may thereby negotiate a communication session between a host and a client based on the capabilities of each, in addition to taking into account the services and resources offered and/or requested by the client and host. The network security arbiter46may also select a host that may require the services, resources or capabilities offered by the client for to fulfill a gaming function to be performed by the host. The gaming security arbiter46may search for hosts that may require such resources, services and/or capabilities upon establishing a secure communication channel at block142and based on previous requests for services, resources or capabilities, as noted above.

It should be understood that more than one host may fulfill the request and the gaming security arbiter46may provide a list of multiple hosts to the client. The client may subsequently select a host(s) from the list and connect to one or more of the provided hosts. Alternatively, if more than one host is available to fulfill a request, the gaming security arbiter46may choose a host at block148based on load balancing considerations, to ensure that the load is as balanced as practicable across the network12. If existing hosts are incompatible with the request (e.g., incompatible services, resources or capabilities), the gaming security arbiter46may refuse to permit the client to communication with the host, even if the host is specifically requested by the client. Instead, the gaming security arbiter46may select an alternative host, or wait for a suitable host to connect to the network12at block142and provide the client with the identity of the newly connected host. On the other hand, even if an existing host is compatible, the network security arbiter46may prevent the client and host from communicating if the host is not on a list of approved network devices for the client or if the host is on a list of unapproved network devices for the client. Likewise, the network security arbiter46may prevent the communication session if the client is not included in a list of approved network devices for the host or if the client is included in a list of unapproved network devices for the host.

The gaming security arbiter46may create a set of session keys at block150in response to the request, either based on a client request for a specific encryption key or based on additional information provided in the request. Alternatively, the session keys may have been previously created, and the gaming security arbiter46may retrieve session keys in response to the request at block150. The session keys may be either symmetric or asymmetric encryption keys. Although the gaming security arbiter46may create or select a session key based on the client request, in other instances the host may determine the particular session key to use. For example, the client may request a communication session with the host to download a new game. The host may determine (or have predetermined) that gaming code information is very sensitive. The host may therefore request a session key having a high encryption level.

The particulars of the session keys may depend on the security level for the communication, the communication type and/or the capabilities of the client and host. For example, if the request related to less sensitive information, such as a drink order or statistical information, or if the request specified a low security level, the gaming security arbiter46may create/select a session key having a moderately secure encryption technique, such as RC4. For more sensitive information, such as financial information, or if the request specified a high security level, a session key pair relating to a highly secure encryption technique, such as 3DES, may be created/selected. The session keys may be further determined according to the type of communication involved in transmitting the message. For example, a broadcast, multicast or UDP communication session may result in a common session key being created/selected. On the other hand, the session keys may be specific session keys which are only distributed to a particular client and host. The specific session keys may further be valid only for particular communication sessions, and discarded by the gaming unit20and network computer22when the communication session is ended. The session keys may further depend on the encryption capabilities of the client and/or the host, and the gaming security arbiter46may create/select a session key pair compatible with the client and host.

Generally, the session key may be associated with a serial number or other identification, to inform the decrypting device which encryption algorithm was used to encrypt the information. For example, a host may simultaneously communicate with multiple clients using both common and specific session keys, or a communication session may involve multiple messages. In either case, the information may include varying levels of sensitivity, resulting in varying encryption schemes. The gaming security arbiter46may create/select multiple pairs of session keys to accommodate multiple levels of security, and each session key may be associated with a serial number or other identification. The client or host may determine sensitivity of the information in a message and thus determine the appropriate key on a message-by-message basis depending on the level of security required, as disclosed in further detail below. The gaming security arbiter46may further include a timestamp on the session key indicating the date/time of creation, distribution and/or expiration. In addition or alternatively, the gaming security arbiter46may maintain data on when the session keys were created and/or distributed, and when the session key may expire.

In addition to creating or selecting the appropriate session keys at block150, the gaming security arbiter46may also determine appropriate communication parameters, such as encryption methods, authentication, compression methods, communication channels and data formats, to be used by the client and host. The determination of compression and data formats may be based on compatible capabilities between the client and the potential host. For example, the gaming security arbiter46may determine that the client and host will communicate using an XML data format because that is a compatible data format for each. The gaming security arbiter46may further may establish communication parameters that specify the compression technique to use based on the size of a message. For instance, the communication parameters may dictate that messages under 100 bytes are to be left uncompressed, messages between 100-500 bytes are to be compressed using zlib and messages over 500 bytes are to be compressed using bzip2. Encryption methods may be specified by the gaming security arbiter46based on sensitivity or network security, for example. Communication channels may be specified by the gaming security arbiter46based on load balancing considerations, channel security or information sensitivity. Likewise, authentication techniques may be specified by the gaming security arbiter46based on sensitivity and security. While any of these communication parameters (e.g., encryption, authentication, compression, communication channel, data format, etc.) may be determined by the client and/or host, it is therefore also possible for the gaming security arbiter46to dictate the parameters of the communication session between the client and the host.

At block152, in response to the request, the gaming security arbiter46may distribute one or more session keys and/or host identification (e.g., IP address) of one or more hosts to the client, along with the communication parameters, if applicable. In one example, the gaming security arbiter46may distribute a session key to the client and confirm receipt of the session key(s). If the gaming security arbiter46provides multiple session keys and/or multiple hosts, the client may select a session key(s) or host(s) from the lists and proceed with the communication session accordingly. The session keys and/or host identification may be encrypted using the encryption keys previously exchanged between the gaming security arbiter46and the client during authentication. In addition to host identification, the gaming security arbiter46may also provide information about the host, including, but not limited to, services, resources and capabilities provided by the host, and gaming functions supported by the host.

Although the gaming security arbiter46may distribute the session keys and/or host identification in response to a specific request, it should be understood that the session keys may have also been previously provided to the client and host in response to the authentication verification at block142, in which case the gaming security arbiter46may provide the selected host to the client, and the client and host may communicate using existing session keys.

Having distributed the session key(s) and host(s) identification to the client, the gaming security arbiter46may wait for a communication from the host at block154. The communication from the host may inform the gaming security arbiter46that the client is attempting to initiate a communication session with the host. The host communication may therefore include request for confirmation from the gaming security arbiter46that the client is an authenticated network device and that the gaming security arbiter46authorized the client to communicate with the host. The arbiter may provide such confirmation at block156and further provide a session key(s) to the host corresponding to the session key(s) provided to the client at block152. The session keys may be encrypted using the encryption keys exchanged with the host during authentication verification. Alternatively, the session key(s) may have been previously provided to the host during the authentication verification. Additionally, the gaming security arbiter46may inform the host of the client's capabilities, services and/or resources, and/or inform the host of the communication parameters of the communication session between the client and the host. The client and host may then commence the communication session using the session keys to encrypt/decrypt messages, and based on the communication parameters and capabilities, if provided by the gaming security arbiter46.

As mentioned above, the session keys may include a timestamp indicating the time/date of creation, distribution and/or expiration, or the gaming security arbiter46may otherwise note the same. At block158, the gaming security arbiter46may determine whether a predetermined amount of time has elapsed since the session keys were created or distributed. In other words, the gaming security arbiter46may determine whether the session keys have expired or are about to expire. If not, the gaming security arbiter46may continue to wait. Otherwise, control may pass to block150and the gaming security arbiter46may renegotiate new session keys for the client and host, either automatically or upon request from the client or host. Alternatively, the client or host may determine if the session keys have expired, or are about to expire, and request the gaming security arbiter46to negotiate new session keys. The client and host may further utilize different keys upon expiration, if multiple session keys were initially provided. If new session keys are not negotiated, the existing session keys may expire, and the communication session may be terminated.

FIG. 5Ais a flowchart of an alternative key distribution routine160that may be stored in the memory of the arbiter controller120. Referring toFIG. 5A, the key distribution routine160may begin operation at block162during which the gaming security arbiter46establishes secure communication channel connections, such as SSL or IPSec, with each of the gaming units20, network computers22, or other devices connected to the network12. The connecting network device may transmit a UDP message, and the gaming security arbiter46may respond to the message with its IP address. The gaming security arbiter46may verify the authenticity of the network device by exchanging certificates and encryption keys for further communications between the gaming security arbiter46and the network device. The gaming security arbiter46may thereby authenticate each device on the network to verify its identity and authority to communicate over the network12. Override functions may also be initiated by an operator to communicative disconnect the network device from the from the network. Approved and unapproved network device lists may be established for the network device, and the gaming security arbiter46may determine if the network device is to be listed on any approved or unapproved network device lists. The network device may further inform the gaming security arbiter46of the services, resources, capabilities and supported gaming functions of the network device, or the gaming security arbiter46may determine what gaming functions the network device may support. Common and/or specific session keys may also be distributed, or the session keys may be distributed in response to a request.

The gaming security arbiter46may wait until it receives a request from a client at block164, which may be any one of the network devices. Alternatively, the gaming security arbiter46may automatically proceed to negotiate a communication session based on a previously existing request or a request from a newly authenticated network device. The request may include a request for a particular host or for a host offering particular services, resources or capabilities (e.g., encryption, compression, data format), or inform the gaming security arbiter46of a gaming function to be performed by the client. The request may also include a request for a host that requires the services, resources or capabilities of the client. The request may further specify a request for particular session keys, a particular security level, the communication type or information about the client's capabilities, for example.

The gaming security arbiter46may verify that the client has been authenticated at block166. At block168, the gaming security arbiter46may search among a list of authenticated network devices to determine if a requested host is connected to the network12and authenticated. If a request does not specify a particular host, the gaming security arbiter46may one or more host that may fulfill the details of the request and/or is compatible with the client. The gaming security arbiter46may therefore select a host based on services, resources, capabilities offered by the host that are compatible with the services, resources and capabilities required by the client or a gaming function to be performed by the client. Alternatively, if the client provides particular services, resources or capabilities and requests a host in need of those services, resources or capabilities, the network security arbiter46may search for compatible hosts. If more than one host fulfills the request, the gaming security arbiter46may create a list of multiple hosts for the client to choose from or select a host based on load balancing considerations. The gaming security arbiter46may also restrict a client from communicating with a host (e.g., based on approved and unapproved lists) and provide the client with an alternative host.

The gaming security arbiter46may create or select a set of session keys at block170in response to, and appropriate for, the request. As mentioned, the session keys may be specified in the request by the client, or the gaming security arbiter46may create or select the appropriate session keys based on the request (e.g., capabilities, security level, communication type, etc.) or by having the requested device specify the session keys. Multiple sets of session keys of varying types of encryption may be created or selected, such that the client or host may determine the appropriate session key for a message, which may be based on communication parameters established by the gaming security arbiter46. If the request relates to a multicast communication, a broadcast communication, a UDP communication, etc., a common session key may result, whereas if the request relates to a direct communication between two devices, the gaming security arbiter46may create/select specific session keys.

Each session key pair may include an identification to allow the client and host to encrypt and decrypt messages using the appropriate session key. The gaming security arbiter46may further include a timestamp on the session key indicating the date/time of creation, distribution and/or expiration, or otherwise note when the session keys were created and/or distributed, and when the session key may expire. The gaming security arbiter46may further determine appropriate the encryption methods, authentication, compression methods, communication channels and/or data formats to be used by the client and host, which may be based on compatible capabilities between the client and the potential host. The gaming security arbiter46may specify the encryption methods, authentication, compression methods, communication channels and data formats in the communication parameters.

At block172, the gaming security arbiter46may inform the client of the host(s) it may communicate with along with information about the host (e.g., services, resources, capabilities, supported gaming functions, etc.), and inform the host that an authorized client wishes to communicate with the host. The gaming security arbiter46may further distribute the session keys to the client and to the host, along with the communication parameters and/or capabilities, if applicable. As above, although the gaming security arbiter46may distribute the session keys and/or host identification in response to a specific request, it should be understood that the session keys may have also been previously provided to the client and host in response to the authentication verification, in which case the gaming security arbiter46may provide the selected host to the client, and the client and host may communicate using existing session keys. The session keys may be encrypted using the encryption keys exchanged during the authentication verification. In one example, the gaming security arbiter46may first distribute a session key to the host and confirm receipt before distributing a session key to the client and confirming receipt of the session key to the client. If the session keys are successfully received, the gaming security arbiter46may inform the client that the session keys were successfully received, and at block174the gaming security arbiter46may prompt the client to initiate the communication session with the host, or prompt the host to communicate with the client. If the session keys are not delivered successfully, the gaming security arbiter46may resend the session keys. The client and host may then commence the communication session using the session keys to encrypt/decrypt messages, and based on the communication parameters and capabilities, if provided by the gaming security arbiter46. New session keys may be renegotiated automatically or upon a request from the client or host.

FIG. 6is a flowchart of a communication request routine180that may be stored in the memory of the controller of a network device requesting a communication session (client), such as the controller100of the gaming unit20, the controller130of the network computer22, etc. Referring toFIG. 6, the communication request routine180may begin at block181during which the client may with establish a secure communication channel connection, such as an SSL or IPSec connection, with the gaming security arbiter46. Upon connecting to the network12, the client may determine its IP address (e.g., through dynamic host configuration protocol) and broadcast a UDP message, to which the gaming security arbiter46may respond with its own IP address. As part of establishing a secure communication channel connection, the client may authenticate itself for the gaming security arbiter46, and may further authenticate the gaming security arbiter46, by exchanging certificates and encryption keys for further communications. The client may receive a common encryption key for multicast or broadcast communications, and specific session keys may also be received. The client may further inform the arbiter of services, resources, capabilities and gaming functions provided by the client.

Having established a secure communication channel and authentication with the gaming security arbiter46, the client may request a communication session with one or more devices on the network12(host) at block182. Alternatively, the client may request a particular service or resource, or specify a gaming function, in response to which the gaming security arbiter46may decide which host will provide the service or resource. The request may relate to resources, service and capabilities offered by the client, and request a host(s) that may require such resources, services and capabilities. The request may also include a request for a particular security level, a request for one or more particular pairs of session keys, communication type, or any other information that may be used by the gaming security arbiter46to provide the appropriate session keys. In yet another example, the gaming security arbiter46may automatically provide the client with a host(s) to communication with upon authentication at block181.

In response to the request, and assuming the gaming security arbiter46approves the request, the client may receive the session key(s) at block183and confirm receipt of the session key(s) with the gaming security arbiter46at block184. The client may receive an identification of the host(s) and communication parameters as determined by the gaming security arbiter46. In one example, the session key(s) was received after authentication verification, which the client may use when provided with the host identification. Multiple session keys and/or multiple hosts may result in the client selecting an appropriate session key or host for the communication session. The client then initiate the communication session directly with the host, and wait for the host to respond at block185. As mentioned above, the host will contact the gaming security arbiter46to confirm the client's authenticity. If authenticated, the client may receive a message from the host and commence the communication session in accordance with the communication parameters, if applicable. Otherwise, the client may continue to wait for contact from the host, and/or after a predetermined amount of time, attempt to renegotiate the communication session with the gaming security arbiter46. Alternatively, the gaming security arbiter46may provide the client and host with authorization to initiate the communication session, rather than have the client and the host contact the gaming security arbiter46for confirmation.

All messages may be communicated directly between the client and the host, without routing the message through the gaming security arbiter46. If one of the network devices engaged in a communication session is transmitting a message, the transmitting device may encrypt the information with a session key appropriate for the sensitivity of the information, as determined by the gaming security arbiter46, the client or the host. The transmitting device may also include routing information and session key identification, so the receiving device may verify it is the correct recipient and use the appropriate session key to decrypt the message. Additional information, such as compression and data format, for example, may be included in the message header to permit appropriate (de)compression and formatting/reading. The message header may be encrypted using a predetermined encryption key or may remain unencrypted. The receiving device may read the message header, including routing information, session key identification, etc., and decrypt the message using the appropriate session key. The message header information may remain unencrypted. The session keys may include an expiration and may automatically expire, causing the client and host to renegotiate further session keys with the gaming security arbiter46, or otherwise receive further session keys from the gaming security arbiter46, if the communication session is to continue. Alternatively, the client and host may utilize a new session key already provided by the gaming security arbiter46, if multiple session keys were provided.

FIG. 7is a flowchart of a communication request response routine190that may be stored in the memory of the controller of a host being contacted by a client for a communication session, such as the controller100of the gaming unit20, the controller130of the network computer22, etc. Referring toFIG. 7, the communication request response routine190may begin at block192during which the host may establish contract with the gaming security arbiter46and establish a secure communication channel connection, such as an SSL or IPSec connection, with the gaming security arbiter46. Upon connecting to the network12, the host may determine its IP address (e.g., through dynamic host configuration protocol) and broadcast a UDP message, to which the gaming security arbiter46may respond with its own IP address. As part of establishing a secure communication channel connection, the host may exchange certificates and encryption keys with the gaming security arbiter46. The host may further inform the gaming security arbiter46of resources, service, capabilities and gaming functions supported by the host, or required by the host. The host may receive a common encryption key for multicast or broadcast communications, and/or specific session keys for subsequent communication sessions.

Having established a secure communication channel and authentication with the gaming security arbiter46, the host may receive a request for a communication session from a client at block192. The request may inform the host of the details of the request (e.g., the service, resource, capabilities, communication parameters, security level, communication type, etc.). In yet another example, the gaming security arbiter46may automatically provide the host with a client(s) to communicate with upon authentication at block191

The host may request confirmation of the client's authenticity from the gaming security arbiter46at block193. At block194, the host may wait for the gaming security arbiter46to provide confirmation of the client's authenticity. If provided, the host may receive the session keys from the gaming security arbiter46at block195, along with communication parameters, client services, resources, capabilities, etc., if applicable. If confirmation is not provided, the host may refuse to communicate with the client. Alternatively, the gaming security arbiter46may provide the client and host with authorization to initiate the communication session, rather than have the client and the host contact the gaming security arbiter46for confirmation.

The host may receive the session key(s), communication parameters, etc. from the gaming security arbiter46at block195and confirm receipt of the session keys at block196. The host may then initiate the communication session directly with the client. The host may encrypt the information with the appropriate session key if transmitting information, and decrypt information with the appropriate session key if receiving information. Routing information and session key identification may also be included in the message headers, to verify the correct recipient received the message and to use the appropriate session key to encrypt or decrypt the message. Additional information, such as compression and data format, for example, may be included in the message header, which may be encrypted or may remain unencrypted. The session keys may automatically expire, causing the client and host to receive further session keys from the gaming security arbiter46or utilize a new session key already provided by the gaming security arbiter46.

Overall Operation of Gaming Unit

One manner in which one or more of the gaming units20(and one or more of the gaming units30) may operate is described below in connection with a number of flowcharts which represent a number of portions or routines of one or more computer programs, which may be stored in one or more of the memories of the controller100. The computer program(s) or portions thereof may be stored remotely, outside of the gaming unit20, and may control the operation of the gaming unit20from a remote location. Such remote control may be facilitated with the use of a wireless connection, or by an Internet interface that connects the gaming unit20with a remote computer (such as one of the network computers22,32) having a memory in which the computer program portions are stored. The computer program portions may be written in any high level language such as C, C++, C#, Java or the like or any low-level assembly or machine language. By storing the computer program portions therein, various portions of the memories102,106are physically and/or structurally configured in accordance with computer program instructions.

FIG. 8is a flowchart of a main operating routine200that may be stored in the memory of the controller100. Referring toFIG. 8, the main routine200may begin operation at block202during which an attraction sequence may be performed in an attempt to induce a potential player in a casino to play the gaming unit20. The attraction sequence may be performed by displaying one or more video images on the display unit70(if provided as a video display unit) and/or causing one or more sound segments, such as voice or music, to be generated via the speakers62. The attraction sequence may include a scrolling list of games that may be played on the gaming unit20and/or video images of various games being played, such as video poker, video blackjack, video slots, video keno, video bingo, etc.

During performance of the attraction sequence, if a potential player makes any input to the gaming unit20as determined at block204, the attraction sequence may be terminated and a game-selection display may be generated on the display unit70(if provided as a video display unit) at block206to allow the player to select a game available on the gaming unit20. The gaming unit20may detect an input at block204in various ways. For example, the gaming unit20could detect if the player presses any button on the gaming unit20; the gaming unit20could determine if the player deposited one or more coins into the gaming unit20; the gaming unit20could determine if player deposited paper currency into the gaming unit; etc.

The game-selection display generated at block206may include, for example, a list of video games that may be played on the gaming unit20and/or a visual message to prompt the player to deposit value into the gaming unit20. While the game-selection display is generated, the gaming unit20may wait for the player to make a game selection. Upon selection of one of the games by the player as determined at block208, the controller100may cause one of a number of game routines to be performed to allow the selected game to be played. For example, the game routines could include a video poker routine210, a video blackjack routine220, a slots routine230, a video keno routine240, and a video bingo routine250. At block208, if no game selection is made within a given period of time, the operation may branch back to block202.

After one of the routines210,220,230,240,250has been performed to allow the player to play one of the games, block260may be utilized to determine whether the player wishes to terminate play on the gaming unit20or to select another game. If the player wishes to stop playing the gaming unit20, which wish may be expressed, for example, by selecting a “Cash Out” button, the controller100may dispense value to the player at block262based on the outcome of the game(s) played by the player. The operation may then return to block202. If the player did not wish to quit as determined at block260, the routine may return to block208where the game-selection display may again be generated to allow the player to select another game.

It should be noted that although five gaming routines are shown inFIG. 8, a different number of routines could be included to allow play of a different number of games. The gaming unit20may also be programmed to allow play of different games.

FIG. 9is a flowchart of an alternative main operating routine300that may be stored in the memory of the controller100. The main routine300may be utilized for gaming units20that are designed to allow play of only a single game or single type of game. Referring toFIG. 9, the main routine300may begin operation at block302during which an attraction sequence may be performed in an attempt to induce a potential player in a casino to play the gaming unit20. The attraction sequence may be performed by displaying one or more video images on the display unit70(if provided as a video display unit) and/or causing one or more sound segments, such as voice or music, to be generated via the speakers62.

During performance of the attraction sequence, if a potential player makes any input to the gaming unit20as determined at block304, the attraction sequence may be terminated and a game display may be generated on the display unit70(if provided as a video display unit) at block306. The game display generated at block306may include, for example, an image of the casino game that may be played on the gaming unit20and/or a visual message to prompt the player to deposit value into the gaming unit20. At block308, the gaming unit20may determine if the player requested information concerning the game, in which case the requested information may be displayed at block310. Block312may be used to determine if the player requested initiation of a game, in which case a game routine320may be performed. The game routine320could be any one of the game routines disclosed herein, such as one of the five game routines210,220,230,240,250, or another game routine.

After the routine320has been performed to allow the player to play the game, block322may be utilized to determine whether the player wishes to terminate play on the gaming unit20. If the player wishes to stop playing the gaming unit20, which wish may be expressed, for example, by selecting a “Cash Out” button, the controller100may dispense value to the player at block324based on the outcome of the game(s) played by the player. The operation may then return to block302. If the player did not wish to quit as determined at block322, the operation may return to block308.

Video Poker

Where the gaming unit20is designed to facilitate play of a video poker game, the display unit70may comprise a video display unit.FIG. 10is an exemplary display350that may be shown on the display unit70during performance of the video poker routine210shown schematically inFIG. 8. Referring toFIG. 10, the display350may include video images352of a plurality of playing cards representing the player's hand, such as five cards. To allow the player to control the play of the video poker game, a plurality of player-selectable buttons may be displayed. The buttons may include a “Hold” button354disposed directly below each of the playing card images352, a “Cash Out” button356, a “See Pays” button358, a “Bet One Credit” button360, a “Bet Max Credits” button362, and a “Deal/Draw” button364. The display350may also include an area366in which the number of remaining credits or value is displayed. If the display unit70is provided with a touch-sensitive screen, the buttons354,356,358,360,362,364may form part of the video display350. Alternatively, one or more of those buttons may be provided as part of a control panel that is provided separately from the display unit70.

FIG. 12is a flowchart of the video poker routine210shown schematically inFIG. 8. Referring toFIG. 12, at block370, the routine may determine whether the player has requested payout information, such as by activating the “See Pays” button358, in which case at block372the routine may cause one or more pay tables to be displayed on the display unit70. At block374, the routine may determine whether the player has made a bet, such as by pressing the “Bet One Credit” button360, in which case at block376bet data corresponding to the bet made by the player may be stored in the memory of the controller100. At block378, the routine may determine whether the player has pressed the “Bet Max Credits” button362, in which case at block380bet data corresponding to the maximum allowable bet may be stored in the memory of the controller100.

At block382, the routine may determine if the player desires a new hand to be dealt, which may be determined by detecting if the “Deal/Draw” button364was activated after a wager was made. In that case, at block384a video poker hand may be “dealt” by causing the display unit70to generate the playing card images352. After the hand is dealt, at block386the routine may determine if any of the “Hold” buttons354have been activated by the player, in which case data regarding which of the playing card images352are to be “held” may be stored in the controller100at block388. If the “Deal/Draw” button364is activated again as determined at block390, each of the playing card images352that was not “held” may be caused to disappear from the video display350and to be replaced by a new, randomly selected, playing card image352at block392.

At block394, the routine may determine whether the poker hand represented by the playing card images352currently displayed is a winner. That determination may be made by comparing data representing the currently displayed poker hand with data representing all possible winning hands, which may be stored in the memory of the controller100. If there is a winning hand, a payout value corresponding to the winning hand may be determined at block396. At block398, the player's cumulative value or number of credits may be updated by subtracting the bet made by the player and adding, if the hand was a winner, the payout value determined at block396. The cumulative value or number of credits may also be displayed in the display area366(FIG. 10).

Although the video poker routine210is described above in connection with a single poker hand of five cards, the routine210may be modified to allow other versions of poker to be played. For example, seven card poker may be played, or stud poker may be played. Alternatively, multiple poker hands may be simultaneously played. In that case, the game may begin by dealing a single poker hand, and the player may be allowed to hold certain cards. After deciding which cards to hold, the held cards may be duplicated in a plurality of different poker hands, with the remaining cards for each of those poker hands being randomly determined.

Video Blackjack

Where the gaming unit20is designed to facilitate play of a video blackjack game, the display unit70may comprise a video display unit.FIG. 11is an exemplary display400that may be shown on the display unit70during performance of the video blackjack routine220shown schematically inFIG. 8. Referring toFIG. 11, the display400may include video images402of a pair of playing cards representing a dealer's hand, with one of the cards shown face up and the other card being shown face down, and video images404of a pair of playing cards representing a player's hand, with both the cards shown face up. The “dealer” may be the gaming unit20.

To allow the player to control the play of the video blackjack game, a plurality of player-selectable buttons may be displayed. The buttons may include a “Cash Out” button406, a “See Pays” button408, a “Stay” button410, a “Hit” button412, a “Bet One Credit” button414, and a “Bet Max Credits” button416. The display400may also include an area418in which the number of remaining credits or value is displayed. If the display unit70is provided with a touch-sensitive screen, the buttons406,408,410,412,414,416may form part of the video display400. Alternatively, one or more of those buttons may be provided as part of a control panel that is provided separately from the display unit70.

FIG. 13is a flowchart of the video blackjack routine220shown schematically inFIG. 8. Referring toFIG. 13, the video blackjack routine220may begin at block420where it may determine whether a bet has been made by the player. That may be determined, for example, by detecting the activation of either the “Bet One Credit” button414or the “Bet Max Credits” button416. At block422, bet data corresponding to the bet made at block420may be stored in the memory of the controller100. At block424, a dealer's hand and a player's hand may be “dealt” by making the playing card images402,404appear on the display unit70.

At block426, the player may be allowed to be “hit,” in which case at block428another card will be dealt to the player's hand by making another playing card image404appear in the display400. If the player is hit, block430may determine if the player has “bust,” or exceeded 21. If the player has not bust, blocks426and428may be performed again to allow the player to be hit again.

If the player decides not to hit, at block432the routine may determine whether the dealer should be hit. Whether the dealer hits may be determined in accordance with predetermined rules, such as the dealer always hit if the dealer's hand totals 15 or less. If the dealer hits, at block434the dealer's hand may be dealt another card by making another playing card image402appear in the display400. At block436the routine may determine whether the dealer has bust. If the dealer has not bust, blocks432,434may be performed again to allow the dealer to be hit again.

If the dealer does not hit, at block436the outcome of the blackjack game and a corresponding payout may be determined based on, for example, whether the player or the dealer has the higher hand that does not exceed 21. If the player has a winning hand, a payout value corresponding to the winning hand may be determined at block440. At block442, the player's cumulative value or number of credits may be updated by subtracting the bet made by the player and adding, if the player won, the payout value determined at block440. The cumulative value or number of credits may also be displayed in the display area418(FIG. 11).

Slots

Where the gaming unit20is designed to facilitate play of a video slots game, the display unit70may comprise a video display unit.FIG. 14is an exemplary display450that may be shown on the display unit70during performance of the slots routine230shown schematically inFIG. 8. Referring toFIG. 14, the display450may include video images452of a plurality of slot machine reels, each of the reels having a plurality of reel symbols454associated therewith. Although the display450shows five reel images452, each of which may have three reel symbols454that are visible at a time, other reel configurations could be utilized.

To allow the player to control the play of the slots game, a plurality of player-selectable buttons may be displayed. The buttons may include a “Cash Out” button456, a “See Pays” button458, a plurality of payline-selection buttons460each of which allows the player to select a different number of paylines prior to “spinning” the reels, a plurality of bet-selection buttons462each of which allows a player to specify a wager amount for each payline selected, a “Spin” button464, and a “Max Bet” button466to allow a player to make the maximum wager allowable.

FIG. 16is a flowchart of the slots routine230shown schematically inFIG. 8. Referring toFIG. 16, at block470, the routine may determine whether the player has requested payout information, such as by activating the “See Pays” button458, in which case at block472the routine may cause one or more pay tables to be displayed on the display unit70. At block474, the routine may determine whether the player has pressed one of the payline-selection buttons460, in which case at block476data corresponding to the number of paylines selected by the player may be stored in the memory of the controller100. At block478, the routine may determine whether the player has pressed one of the bet-selection buttons462, in which case at block480data corresponding to the amount bet per payline may be stored in the memory of the controller100. At block482, the routine may determine whether the player has pressed the “Max Bet” button466, in which case at block484bet data (which may include both payline data and bet-per-payline data) corresponding to the maximum allowable bet may be stored in the memory of the controller100.

If the “Spin” button464has been activated by the player as determined at block486, at block488the routine may cause the slot machine reel images452to begin “spinning” so as to simulate the appearance of a plurality of spinning mechanical slot machine reels. At block490, the routine may determine the positions at which the slot machine reel images will stop, or the particular symbol images454that will be displayed when the reel images452stop spinning. At block492, the routine may stop the reel images452from spinning by displaying stationary reel images452and images of three symbols454for each stopped reel image452. The virtual reels may be stopped from left to right, from the perspective of the player, or in any other manner or sequence.

The routine may provide for the possibility of a bonus game or round if certain conditions are met, such as the display in the stopped reel images452of a particular symbol454. If there is such a bonus condition as determined at block494, the routine may proceed to block496where a bonus round may be played. The bonus round may be a different game than slots, and many other types of bonus games could be provided. If the player wins the bonus round, or receives additional credits or points in the bonus round, a bonus value may be determined at block498. A payout value corresponding to outcome of the slots game and/or the bonus round may be determined at block500. At block502, the player's cumulative value or number of credits may be updated by subtracting the bet made by the player and adding, if the slot game and/or bonus round was a winner, the payout value determined at block500.

Although the above routine has been described as a virtual slot machine routine in which slot machine reels are represented as images on the display unit70, actual slot machine reels that are capable of being spun may be utilized instead, in which case the display unit70could be provided in the form of a plurality of mechanical reels that are rotatable, each of the reels having a plurality of reel images disposed thereon.

Video Keno

Where the gaming unit20is designed to facilitate play of a video keno game, the display unit70may comprise a video display unit.FIG. 15is an exemplary display520that may be shown on the display unit70during performance of the video keno routine240shown schematically inFIG. 8. Referring toFIG. 15, the display520may include a video image522of a plurality of numbers that were selected by the player prior to the start of a keno game and a video image524of a plurality of numbers randomly selected during the keno game. The randomly selected numbers may be displayed in a grid pattern.

To allow the player to control the play of the keno game, a plurality of player-selectable buttons may be displayed. The buttons may include a “Cash Out” button526, a “See Pays” button528, a “Bet One Credit” button530, a “Bet Max Credits” button532, a “Select Ticket” button534, a “Select Number” button536, and a “Play” button538. The display520may also include an area540in which the number of remaining credits or value is displayed. If the display unit70is provided with a touch-sensitive screen, the buttons may form part of the video display520. Alternatively, one or more of those buttons may be provided as part of a control panel that is provided separately from the display unit70.

FIG. 17is a flowchart of the video keno routine240shown schematically inFIG. 8. The keno routine240may be utilized in connection with a single gaming unit20where a single player is playing a keno game, or the keno routine240may be utilized in connection with multiple gaming units20where multiple players are playing a single keno game. In the latter case, one or more of the acts described below may be performed either by the controller100in each gaming unit or by one of the network computer22,32to which multiple gaming units20are operatively connected.

Referring toFIG. 17, at block550, the routine may determine whether the player has requested payout information, such as by activating the “See Pays” button528, in which case at block552the routine may cause one or more pay tables to be displayed on the display unit70. At block554, the routine may determine whether the player has made a bet, such as by having pressed the “Bet One Credit” button530or the “Bet Max Credits” button532, in which case at block556bet data corresponding to the bet made by the player may be stored in the memory of the controller100. After the player has made a wager, at block558the player may select a keno ticket, and at block560the ticket may be displayed on the display520. At block562, the player may select one or more game numbers, which may be within a range set by the casino. After being selected, the player's game numbers may be stored in the memory of the controller100at block564and may be included in the image522on the display520at block566. After a certain amount of time, the keno game may be closed to additional players (where a number of players are playing a single keno game using multiple gambling units20).

If play of the keno game is to begin as determined at block568, at block570a game number within a range set by the casino may be randomly selected either by the controller100or a central computer operatively connected to the controller, such as one of the network computers22,32. At block572, the randomly selected game number may be displayed on the display unit70and the display units70of other gaming units20(if any) which are involved in the same keno game. At block574, the controller100(or the central computer noted above) may increment a count which keeps track of how many game numbers have been selected at block570.

At block576, the controller100(or one of the network computers22,32) may determine whether a maximum number of game numbers within the range have been randomly selected. If not, another game number may be randomly selected at block570. If the maximum number of game numbers has been selected, at block578the controller100(or a central computer) may determine whether there are a sufficient number of matches between the game numbers selected by the player and the game numbers selected at block570to cause the player to win. The number of matches may depend on how many numbers the player selected and the particular keno rules being used.

If there are a sufficient number of matches, a payout may be determined at block580to compensate the player for winning the game. The payout may depend on the number of matches between the game numbers selected by the player and the game numbers randomly selected at block570. At block582, the player's cumulative value or number of credits may be updated by subtracting the bet made by the player and adding, if the keno game was won, the payout value determined at block580. The cumulative value or number of credits may also be displayed in the display area540(FIG. 15).

Video Bingo

Where the gaming unit20is designed to facilitate play of a video bingo game, the display unit70may comprise a video display unit.FIG. 18is an exemplary display600that may be shown on the display unit70during performance of the video bingo routine250shown schematically inFIG. 8. Referring toFIG. 18, the display600may include one or more video images602of a bingo card and images of the bingo numbers selected during the game. The bingo card images602may have a grid pattern.

To allow the player to control the play of the bingo game, a plurality of player-selectable buttons may be displayed. The buttons may include a “Cash Out” button604, a “See Pays” button606, a “Bet One Credit” button608, a “Bet Max Credits” button610, a “Select Card” button612, and a “Play” button614. The display600may also include an area616in which the number of remaining credits or value is displayed. If the display unit70is provided with a touch-sensitive screen, the buttons may form part of the video display600. Alternatively, one or more of those buttons may be provided as part of a control panel that is provided separately from the display unit70.

FIG. 19is a flowchart of the video bingo routine250shown schematically inFIG. 8. The bingo routine250may be utilized in connection with a single gaming unit20where a single player is playing a bingo game, or the bingo routine250may be utilized in connection with multiple gaming units20where multiple players are playing a single bingo game. In the latter case, one or more of the acts described below may be performed either by the controller100in each gaming unit20or by one of the network computers22,32to which multiple gaming units20are operatively connected.

Referring toFIG. 19, at block620, the routine may determine whether the player has requested payout information, such as by activating the “See Pays” button606, in which case at block622the routine may cause one or more pay tables to be displayed on the display unit70. At block624, the routine may determine whether the player has made a bet, such as by having pressed the “Bet One Credit” button608or the “Bet Max Credits” button610, in which case at block626bet data corresponding to the bet made by the player may be stored in the memory of the controller100.

After the player has made a wager, at block628the player may select a bingo card, which may be generated randomly. The player may select more than one bingo card, and there may be a maximum number of bingo cards that a player may select. After play is to commence as determined at block632, at block634a bingo number may be randomly generated by the controller100or a central computer such as one of the network computers22,32. At block636, the bingo number may be displayed on the display unit70and the display units70of any other gaming units20involved in the bingo game.

At block638, the controller100(or a central computer) may determine whether any player has won the bingo game. If no player has won, another bingo number may be randomly selected at block634. If any player has bingo as determined at block638, the routine may determine at block640whether the player playing that gaming unit20was the winner. If so, at block642a payout for the player may be determined. The payout may depend on the number of random numbers that were drawn before there was a winner, the total number of winners (if there was more than one player), and the amount of money that was wagered on the game. At block644, the player's cumulative value or number of credits may be updated by subtracting the bet made by the player and adding, if the bingo game was won, the payout value determined at block642. The cumulative value or number of credits may also be displayed in the display area616(FIG. 18).