2.

In general, the gaming machine 2 does not advance from a first state to a second state until critical information that allows the first state to be reconstructed is stored. This feature allows the game to recover operation to the current state of play in the event of a malfunction, loss of power, etc. that occurred just prior to the malfunction. After the state of the gaming machine 2 is restored during the play of a game of chance and/or a game of skill, game play may resume and the game may be completed in a manner that is no different than if the malfunction had not occurred. Typically, battery backed RAM devices can be used to preserve this critical data although other types of non-volatile memory devices may be employed.

As described in the preceding paragraph, when a malfunction occurs during a game of chance and/or a game of skill, the gaming machine 2 may be restored to a state in the game of chance just prior to when the malfunction occurred. The restored state may include metering information and graphical information that, was displayed on the gaming machine 2 in the state prior to the malfunction. When a malfunction has occurred after the player has made one or more selections, the gaming machine 2 may be restored to a state that shows the graphical presentation at just prior to the malfunction, including an indication of selections that have already been made by the player. In general, the gaming machine 2 may be restored to any state in a plurality of states that occur in the game of chance and/or game of skill that occurs while the game of chance and/or game of skill is played or to states that occur between the play of a game of chance and/or game of skill.

Game history information regarding previous games played such as an amount wagered, the outcome of the game and so forth may also be stored in a non-volatile memory device. The information stored in the non-volatile memory may be detailed enough to reconstruct a portion of the graphical presentation that was previously presented on the gaming machine and the state of the gaming machine 2 (e.g., credits) at the time the game of chance and/or game of skill was played. The game history information may be utilized in the event of a dispute. For example, a player may decide that in a previous game of chance and/or game of skill that they did not receive credit for an award that they believed they won. The game history information may be used to reconstruct the state of the gaming machine prior, during and/or after the disputed game to demonstrate whether the player was correct or not in their assertion.

The gaming device 2 can further comprise one or more interfaces, including serial interfaces to connect to serial devices, to connect to specific subsystems internal and external to the gaming device 2. The serial devices may have electrical interface requirements that differ from the “standard” Electronic Industries Association (EIA) 232 serial interfaces. These interfaces may include EIA 485. EIA 422. Fiber Optic Serial, optically coupled serial interfaces, current loop style serial interfaces, etc. In addition, to conserve serial interfaces internally in the gaming device 2, serial devices may be connected in a shared, daisy-chain fashion where multiple peripheral devices are connected to a single serial channel.

The serial interfaces can be used to transmit information using communication protocols that are unique to the gaming industry. For example, the Netplex™ system of International Game Technology (IGT) is a proprietary communication protocol used for serial communication between gaming devices. As another example, Serial Attached Small Computer System Interface (SCSI) (SAS) is a communication protocol used to transmit information, such as metering information, from a gaming machine to a remote device. Often SAS is used in conjunction with a player tracking system.

The gaming device 2 can alternatively be treated as a peripheral device to a casino communication controller and connected in a shared daisy chain fashion to a single serial interface. In both cases, the peripheral devices can be assigned device addresses. If so, the serial controller circuitry can implement a method to generate or detect unique device addresses.

The gaming device 2 can comprise security monitoring circuits to detect intrusion into the gaming machine 2 by monitoring security switches attached to access doors in the cabinet 4. Access violations can result in suspension of game play and can trigger additional security operations to preserve the current state of game play. These circuits also function when power is off by use of a battery backup. In power-off operation, these circuits continue to monitor the access doors of the gaming machine 2. When power is restored, the gaming machine 2 can determine whether any security violations occurred while power was off, e.g., via software for reading status registers. This can trigger event log entries and further data authentication operations by software.

The gaming device 2 can comprise trusted memory devices to ensure the authenticity of the software that may be stored on less secure memory subsystems, such as mass storage devices. Trusted memory devices and controlling circuitry are typically designed to not allow modification of the code and data stored in the memory device while the memory device is installed in the gaming device 2. The code and data stored in these devices may include authentication algorithms, random number generators, authentication keys, operating system kernels, etc. The purpose of these trusted memory devices is to provide gaming regulatory authorities a root trusted authority within the computing environment of the gaming device 2 that can be tracked and verified as original. This may be accomplished via removal of the trusted memory device from the gaming device 2 and verification of the secure memory device contents is a separate third party verification device. Once the trusted memory device is verified as authentic, and based on the approval of the verification algorithms contained in the trusted device, the gaming machine 2 is allowed to verify the authenticity of additional code and data that may be located in the gaming device 2, such as code and data stored on hard disk drives,

Returning to the example of FIG. A, when a user wishes to play the gaming machine 2, he or she can insert cash through the coin acceptor 28 or bill validator 30. Additionally, the bill validator 30 can accept a printed ticket voucher which can be accepted by the bill validator 30 as indicia of credit when a cashless ticketing system is used. At the start of the game, the player can enter playing tracking information using the card reader 24, the keypad 22, and/or the florescent display 16. Further, other game preferences of the player playing the game can be read from a card inserted into the card reader 24. During the game, the player can view game information using the video display 34. Other game and prize information can also be displayed in the video display screen 42 located in the top box 6.

During the course of a game, a player can be required to make a number of decisions, which affect the outcome of the game. For example, a player can vary his or her wager on a particular game, select a prize for a particular game selected from a prize server, or make game decisions which affect the outcome of a particular game, including the selection of one or more entities from a listing of entities. The player can make these choices using the player-input switches 32, the video display screen 34 and/or using some other device which enables a player to input information into the gaming machine. For example, the player can use the play-input switches 32 or the video display screen 34 to select entities during a round of the game using the user interfaces shown in FIGS. 2A and 2B. In some embodiments, the player can be able to access various game services, such as concierge services and entertainment content services, using the video display screen 34 and one or more input devices.

During certain game events, the gaming machine 2 can display visual and auditory effects that can be perceived by the player. These effects can add to the excitement of a game, which can make a player more likely to continue playing. Auditory effects can comprise various sounds that are projected by the speakers 10, 12, 14. Visual effects can comprise flashing lights, strobing lights, and/or other patterns displayed from lights on the gaming machine 2 and/or from lights within the separate mechanical (or electronic) gaming system 40. After the player has completed a game, the player can receive game tokens from the coin tray 38 or the ticket 20 from the printer 18, which can be used to engage games or to redeem a prize. For example, the player can receive the prize from the coin tray 38 or the ticket 20 from the printer 18 after completing the game using the user interfaces shown in FIGS. 2A and 2B. Further, the player can receive a ticket 20 for food, merchandise, or games from the printer 18.

A gaming network that can be used to implement some aspects of the systems and methods described herein is depicted in FIG. 1B. Gaming establishment 1001 can be any sort of gaming establishment, such as a casino, a card room, an airport, a store, etc. Gaming network 1077 can comprise more than one gaming establishment, all of which are networked to game server 1022. Gaming machine 1002, and the other gaming machines 1030, 1032, 1034, and 1036, can comprise a main cabinet 1006 and a top box 1004. The main cabinet 1006 can house the main gaming elements and can also house peripheral systems, such as those that utilize dedicated gaming networks. The top box 1004 can also be used to house these peripheral systems.

The master gaming controller 1008 can control the game play on the gaming machine 1002 according to instructions and/or game data from game server 1022 and/or stored within gaming machine 1002 and/or can receive or send data to various input/output devices 1011 on the gaming machine 1002. For example, the master gaming controller 1008 can be used to control the game play for the game using the user interface shown in FIG. 1D. In one embodiment, master gaming controller 1008 can comprise processor(s) and other apparatuses of the gaming machines described above. The master gaming controller 1008 can also communicate with a display 1010. The display 1010 can be used to display the user interfaces shown in FIGS. 2A and 2B.

A particular gaming entity can provide network gaming services. Thus, dedicated networks can connect gaming machines to host servers that track the performance of gaming machines under the control of the entity, such as for accounting management, electronic fund transfers (EFTs), cashless ticketing, such as EZPay™, marketing management, and data tracking, such as player tracking. Therefore, master gaming controller 1008 can also communicate with EFT system 1012, EZPay™ system, and player tracking system 1020. The systems of the gaming machine 1002 can communicate the data onto the network 1022 via a communication board 1018.

It will be appreciated by those of skill in the art that embodiments of the systems and methods described herein could be implemented on a network with more or fewer elements than are depicted in FIG. 1B. For example, player tracking system 1020 is not a necessary feature of some implementations of the systems and methods described herein. However, player tracking programs can help to sustain a game player's interest in additional game play during a visit to a gaming establishment and can entice a player to visit a gaming establishment to partake in various gaming activities. Player tracking programs provide rewards to players that typically correspond to the player's level of patronage (e.g., to the player's playing frequency and/or total amount of game plays at a given casino). Player tracking rewards may be free meals, free lodging and/or free entertainment. Player tracking information may be combined with other information that is now readily obtainable by a server-based gaming (SBG) system.

Moreover, data collection unit (DCU) 1024 and translator 1025 are not required for all gaming establishments 1001. However, due to the sensitive nature of much of the information on a gaming network (e.g., electronic fund transfers and player tracking data), the manufacturer of a host system usually employs a particular networking language having proprietary protocols. For instance, 10-20 different companies produce player tracking host systems where each host system may use different protocols. These proprietary protocols are usually considered highly confidential and not released publicly.

Further, gaming machines are made by many different manufacturers. The communication protocols on the gaming machine can be hard-wired into the gaming machine and each gaming machine manufacturer can utilize a different proprietary communication protocol. A gaming machine manufacturer can also produce host systems, in which case their gaming machines are compatible with their own host systems. However, in a heterogeneous gaming environment, gaming machines from different manufacturers, each with its own communication protocol, can be connected to host systems from other manufacturers, each with another communication protocol.

A network device that links a gaming establishment with another gaming establishment and/or a central system will sometimes be referred to herein as a “site controller.” Here, site controller 1042 can provide this function for gaming establishment 1001. The site controller 1042 can be connected to a central system and/or other gaming establishments via one or more networks, which can be public or private networks. Among other things, the site controller 1042 can communicate with game server 1022 to obtain game data, such as ball drop data, bingo card data, etc. For example, the site controller 1042 can communicate with the game server 1022 to obtain the game using the user interface shown in FIG. 1D.

Gaming machines 1002, 1030, 1032, 1034 and 1036 can be connected to a dedicated gaming network 1022. In general, the DCU 1024 can function as an intermediary between the different gaming machines on the network 1022 and the site controller 1042. In general, the DCU 1024 can receive data transmitted from the gaming machines and send the data to the site controller 1042 over a transmission path 1026. In some instances, when the hardware interface used by the gaming machine is not compatible with site controller 1042, a translator 1025 can be used to convert serial data from the DCU 1024 to a format accepted by site controller 1042. The translator 1025 can provide this conversion service to a plurality of DCUs.

Further, in some dedicated gaming networks, the DCU 1024 can receive data transmitted from site controller 1042 for communication to the gaming machines on the gaming network. The received data can be, for example, communicated synchronously to the gaming machines on the gaming network.

Here, clerk validation terminal (CVT) 1052 can provide cashless and cashout gaming services to the gaming machines in gaming establishment 1001. For example, CVT 1052 can provide cashless and cashout gaming services to gaming machines executing the game using the user interface shown in FIG. 1D. Broadly speaking, CVT 1052 can authorize and validate cashless gaming machine instruments (also referred to herein as “tickets” or “vouchers”), including but not limited to tickets for causing a gaming machine to display a game result and cash-out tickets. Moreover, CVT 1052 can authorize the exchange of a cashout ticket for cash. These processes will be described in detail below. In one example, when a player attempts to redeem a cash-out ticket for cash at cash-out kiosk 1044, cash-out kiosk 1044 can read validation data from the cash-out ticket and transmit the validation data to CVT 1052 for validation. The tickets can be printed by gaming machines, by the cash-out kiosk 1044, by a stand-alone printer, by the CVT 1052, etc. Some gaming establishments may not have a cash-out kiosk 1044. Instead, a cash-out ticket can be redeemed for cash by a cashier (e.g. of a convenience store), by a gaming machine and/or by a specially configured CVT.

FIG. 1C illustrates an example of a network device that can be configured for implementing the systems and methods described herein. Network device 1160 can comprise a master central processing unit (CPU) 1162, interfaces 1168, and a bus 1167 (e.g., a PCI bus). Interfaces 1168 can comprise ports 1169 appropriate for communication with the appropriate media. In some embodiments, one or more of interfaces 1168 can comprise at least one independent processor and, in some instances, volatile RAM. The independent processors can be, for example, application specific integrated circuits (ASICs) or any other appropriate processors. According to some such embodiments, these independent processors can perform at least some of the functions of the logic described herein. In some embodiments, one or more of interfaces 1168 can control such communications-intensive tasks as encryption, decryption, compression, decompression, packetization, media control, and management. By providing separate processors for the communications-intensive tasks, interfaces 1168 can allow the master microprocessor 1162 efficiently to perform other functions such as routing computations, network diagnostics, security functions, etc.

The interfaces 1168 can be provided as interface cards (sometimes referred to as “linecards”). The interfaces 1168 can control the sending and receiving of data packets over the network and can support other peripherals used with the network device 1160. Among the interfaces 1168 that can be provided are Fibre Channel (FC) interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, digital subscriber line (DSL) interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces can be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, Asynchronous Transfer Mode (ATM) interfaces, High-Speed Serial Interface (ISSI) interfaces, Packet-over-Synchronous Optical Networking (SONET) (POS) interfaces, Fiber Distributed Data Interface (FDDI) interfaces, Actuator Sensor Interface (ASI) interfaces, DigiCable Headend Expansion Interface (DHEI) interfaces and the like.

The CPU 1162 can be responsible for implementing specific functions associated with the functions of a desired network device. According to some embodiments, the CPU 1162 can accomplish the systems and methods described herein under the control of instructions, including an operating system and any appropriate applications. The CPU 1162 can be used to execute the game using the user interface shown in FIG. 1D.

The CPU 1162 can comprise one or more processors 1163 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, the processor 1163 can be specially designed hardware for controlling the operations of network device 1160. In a specific embodiment, a memory 1161 (such as non-volatile RAM and/or ROM) also can form part of the CPU 1162. However, there are many different ways in which memory could be coupled to the system. The memory 1161 can be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc. The memory 1161 can be used to store instructions for performing the game using the user interface shown in FIG. 1D.

Regardless of network device's 1160 configuration, it can employ one or more memories or memory modules (such as, for example, memory block 1165) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein. The program instructions can control the operation of an operating system and/or one or more applications, for example.

A device enabling practice of the systems and methods described herein can comprise: a display device: a player position input device; a memory for storing a plurality of instructions; and a processor for accessing and executing the plurality of instructions. These instructions, when executed by the processor, can cause the processor to operate in cooperation with the display device and the input device to perform activities that are physically and visually determinable, for a performance of a wagering event and/or game of skill.

Turning now to FIG. 2A, shown is an example user interface 200a for a round of gaming using historical performance data. The user interface 200a presents a listing of entities. In this example, the listing of entities is a listing of football players. As was described above, the listing of players can be selected randomly from a larger pool of players. Each of the players is grouped into one of three performance tiers 202a, 202b, and 202c, or a separate group 204 for quarterbacks. The user interface 200a solicits a selection of three players from each of the performance tiers 202a, 202b, and 202c, and a selection of one player from the quarterback group 204. Each of the selectable players is denoted by a user interface element 206. The user interface element 206 can correspond to a selectable button, a selectable touch-screen input, or other user interface element 206 facilitating the selection of a corresponding entity. In this example, each user interface element 206 lists a player name, a two-digit representation of a year, and a two- or three-letter abbreviation of a team of which the player was a member. Other information can also be presented to inform a user of the entities available for selection.

Moving on to FIG. 2B, shown is an example user interface 200b. Here, highlighted user interface elements 208 indicate which players have been selected by a user for inclusion in the given round of the game. Also shown is an input 210 for confirming the selection of players. On a “yes” selection from the input 210, the gaming machine presenting the user interface accesses the historical performance data for each of the selected players for a given performance period. In an aspect, performance period can be selected from multiple performance periods available for a selected player. In an aspect, the performance period can be selected according to a temporal constraint corresponding to the selected player. In this example, each player is listed with a corresponding two-digit year abbreviation. The performance period can comprise a game selected from a year or season denoted by the two-digit year abbreviation.

Using the historical performance data for each of the selected players, a payout is determined based on how many of the players meet or exceed a performance benchmark. In an aspect, the performance benchmark may be indicated to a user through a user interface 200a or 200b. The performance benchmark may also be hidden or otherwise unknown to a user. An example table of payouts is set forth in FIG. 3. Column 302 includes entries for a number of players who meet their respective performance benchmarks, with corresponding payouts in column 304. In this example, a user selecting five or fewer players whose performance benchmarks were met would receive no payout, and would receive increasingly greater payouts for each player above five who met their benchmark. In an aspect, the payout can also be based on a bet or number of credits used to initiate a round of a game.

In an aspect, the historical performance data for each of the selected players may be updated prior to determining how many of the players met or exceeded the performance benchmark. For example, the historical performance data for a group of quarterbacks may have changed in the intervening time period between the start of the game and the selection of the one or more of the entities. Updating the historical performance data would allow the game to be more accurate when determining whether the performance benchmark was met.

FIG. 4 is a flow chart 400 of an exemplary method. At step 402, a credit can be received from a user to initiate a round of a game. A credit can be a coin, a ticket, money, a token, credit card information, debit card information, and/or the like. At step 404, a listing of entities is provided to a user. In an aspect, this can include selecting the listing of entities from a larger pool of entities. In an aspect, this selection can be performed randomly. In an aspect, the entities may be organized into one or more groups, including performance tiers, player positions, or other groups. In such an aspect, providing the listing of entities can include selecting a number of entities from each of the groups for presentation to the user. In an aspect, each of the entities may be associated with a temporal constraint, such as a year, season, or other period. For example, an entity listing can include a player and a corresponding year from which a performance period will be selected, as will be described below. In such an embodiment, an entity can appear more than once in the listing of entities provided that it is associated with a different temporal constraint. For example, a given player can appear multiple times in the listing of entities provided that each entry in the listing corresponds to a different season or year.

Next, at step 406, a selection of entities is received from the user. The entities are selected by the user from the listing of entities provided in step 404. In an aspect, the entities can be selected according to the groups into which the entities arc classified. For example, a predefined number of entities can be selected from each of the groups. At step 408, a performance period is selected for each of the selected entities. The performance period can include, for example, an individual game, a series of games, a season, or a time period. In aspects in which the entities are associated with a temporal constraint, the performance period can be selected from within a time defined by the temporal constraint. For example, if a player is associated with a year in the listing of entities, the performance period can be selected as a game or series from within the associated year. As another example, if a stock is associated with a year, the performance period can be selected as a day, week, month, quarter, or other period within the year. The performance period can be selected randomly, or according to one or more rules. For example, the performance period can be selected as a predefined game number in the respective temporal constraint of a given entity. As an example, the performance period can be selected as the first game in the respective season corresponding to each selected entity.

At step 410, historical performance data is selected for each of the selected entities reflecting their performance during their corresponding selected performance period. In an aspect, the historical performance data for each of the selected entities may be updated prior to proceeding to the next step, which would improve the accuracy of the method. For example, for a given player having a given game as its selected performance period, the historical performance data would indicate that player's performance during that game. Next, at step 412, a number of entities meeting a performance benchmark in their respective performance period is determined using the historical performance data. This can include, for each entity, determining if a particular benchmark is met according to their selected historical performance data. The performance benchmark can include, for example, points scored, distance covered, percentage of attempts that were successful, money earned, growth percentage, or other benchmark as can be appreciated. In an aspect, the performance benchmark can be the same across all entities, or differ between entities.

At step 414, a payout is provided based on the number of selected entities that met their corresponding performance benchmark. For example, in an aspect, no payout can be provided if the number of entities meeting their performance benchmark falls below a threshold. In an aspect, the payout can increase as the number of entities meeting their performance benchmark increases above the threshold. In an aspect the payout can be based on a bet, number of credits, or previous payout used to initiate the round of the game.

In an exemplary aspect, the methods and systems can be implemented on a computer 501 as illustrated in FIG. 5 and described below. By way of example, video gaming machine 2 of FIG. 1A can be a computer as illustrated in FIG. 5. Similarly, the methods and systems disclosed can utilize one or more computers to perform one or more functions in one or more locations. FIG. 5 is a block diagram illustrating an exemplary operating environment for performing the disclosed methods. This exemplary operating environment is only an example of an operating environment and is not intended to suggest any limitation as to the scope of use or functionality of operating environment architecture. Neither should the operating environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment.