Abstract:

A method and apparatus for operating a gaming device having a flat rate
play session costing a flat rate price. The flat rate play session spans
multiple plays on the gaming device over a pre-established duration. The
gaming device identifies price parameters and determines the flat rate
price of playing the gaming device based on those price parameters. In
one embodiment, identifying price parameters includes receiving player
selected price parameters. Once the player initiates play, the gaming
device tracks the duration remaining in the flat rate play session and
stops the play when the given period has elapsed. During the play,
payouts are made either directly to the player in the form of coins or
indirectly in the form of credits to the player's credit account.

Claims:

1. A gaming system comprising:at least one display device;at least one
input device;at least one processor; andat least one memory device which
stores a plurality of instructions, which when executed by the at least
one processor, cause the at least one processor to operate with the at
least one display device and the at least one input device to:(a) receive
a payment for a plurality of distinct plays of a blackjack wagering game
of a flat rate play session, the payment being received prior to any play
of any of the plurality of distinct plays of the blackjack wagering
game;(b) enable a player to place at least one wager on each of the
plurality of distinct plays of the blackjack wagering game, such that a
sum of the wagers placed on each of the plays of the blackjack wagering
game at least equals the payment received for the plurality of distinct
plays of the blackjack wagering game; and(c) for each of the plurality of
distinct plays of the blackjack wagering game:(i) randomly generate a
blackjack game outcome,(ii) display the generated blackjack game
outcome,(iii) determine any award associated with the generated blackjack
game outcome, and(iv) display any determined award.

2. The gaming system of claim 1, wherein the sum of the wagers placed on
each of the plays of the blackjack wagering game exceeds the payment
received for the plurality of distinct plays of the blackjack wagering
game.

3. The gaming system of claim 1, wherein the plurality of distinct plays
of the blackjack wagering game includes a predetermined quantity of
distinct plays of the blackjack wagering game.

4. The gaming system of claim 1, wherein the plurality of distinct plays
of the blackjack wagering game includes a predetermined quantity of
wagers placed on the plays of the blackjack wagering game.

5. The gaming system of claim 1, wherein the plurality of distinct plays
of the blackjack wagering game includes a predetermined quantity of
generated blackjack game outcomes that are each associated with an award
having a value greater than zero.

6. The gaming system of claim 1, wherein the flat rate play session
includes a predetermined duration of time to place wagers on the plays of
the blackjack wagering game.

7. A gaming system comprising:at least one display device;at least one
input device;at least one processor; andat least one memory device which
stores a plurality of instructions, which when executed by the at least
one processor, cause the at least one processor to operate with the at
least one display device and the at least one input device to:(a)
establish a blackjack session contract with a player, said blackjack
session contract including at least two distinct plays of a blackjack
game and said blackjack session contract being associated with a
price;(b) before any generation any blackjack game outcomes of the
blackjack session contract, determine that the player paid the price
associated with the blackjack session contract; and(c) after determining
that the player paid the price associated with the blackjack session
contract, enable the player to play each of said at least two plays of
the blackjack game, each of the plays of the blackjack game associated
with a generated and displayed blackjack game outcome and each of the
plays of the blackjack game associated with at least one wager placed by
the player, such that a total wager placed by the player in association
with the at least two plays of the blackjack game at least equals the
player paid price associated with the blackjack session contract.

8. The gaming system of claim 7, wherein the total wager placed by the
player in association with the at least two plays of the blackjack game
exceeds the player paid price associated with the session contract

9. The gaming system of claim 7, wherein the blackjack session contract is
associated with a predetermined quantity of distinct plays of the
blackjack game.

10. The gaming system of claim 7, wherein the blackjack session contract
is associated with a predetermined quantity of wagers placed on the plays
of the blackjack game.

11. The gaming system of claim 7, wherein the blackjack session contract
is associated with a predetermined quantity of generated and displayed
blackjack game outcomes that are each associated with an award having a
value greater than zero.

12. The gaming system of claim 7, wherein the blackjack session contract
is associated with a predetermined duration of time to places wagers on
the plays of the blackjack game.

13. A method of operating a gaming system, said method comprising:causing
at least one processor to execute a plurality of instructions stored in
at least one memory device to operate with at least one display device
and at least one input device to:(a) receive a payment for a plurality of
distinct plays of a blackjack wagering game of a flat rate play session,
the payment being received prior to any play of any of the plurality of
distinct plays of the blackjack wagering game;(b) enable a player to
place at least one wager on each of the plurality of distinct plays of
the blackjack wagering game, such that a sum of the wagers placed on each
of the plays of the blackjack wagering game at least equals the payment
received for the plurality of distinct plays of the blackjack wagering
game; and(c) for each of the plurality of distinct plays of the blackjack
wagering game:(i) generate a blackjack game outcome,(ii) display the
generated blackjack game outcome,(iii) determine any award associated
with the generated blackjack game outcome, and(iv) display any determined
award.

14. The method of claim 13, wherein the sum of the wagers placed on each
of the plays of the blackjack wagering game exceeds the payment received
for the plurality of distinct plays of the blackjack wagering game.

15. The method of claim 13, wherein the plurality of distinct plays of the
blackjack wagering game includes a predetermined quantity of distinct
plays of the blackjack wagering game.

16. The method of claim 13, wherein the plurality of distinct plays of the
blackjack wagering game includes a predetermined quantity of wagers
placed on the plays of the blackjack wagering game.

17. The method of claim 13, wherein the plurality of distinct plays of the
blackjack wagering game includes a predetermined quantity of generated
blackjack game outcomes that are each associated with an award having a
value greater than zero.

18. The method of claim 13, wherein the flat rate play session includes a
predetermined duration of time to place wagers on the plays of the
blackjack wagering game.

19. The method of claim 13, which is operated through a data network.

20. The method of claim 19, wherein the data network is an internet.

21. A method of operating a gaming system, said method comprising:causing
at least one processor to execute a plurality of instructions stored in
at least one memory device to operate with at least one display device
and at least one input device to:(a) establish a blackjack session
contract with a player, said blackjack session contract including at
least two distinct plays of a blackjack game and said blackjack session
contract being associated with a price;(b) before any generation any
blackjack game outcomes associated with the blackjack session contract,
determine that the player paid the price associated with the blackjack
session contract; and(c) after determining that the player paid the price
associated with the blackjack session contract, enable the player to play
each of said at least two plays of the blackjack game, each of the plays
of the blackjack game associated with a generated and displayed blackjack
game outcome and each of the plays of the blackjack game associated with
at least one wager placed by the player, such that a total wager placed
by the player in association with the at least two plays of the blackjack
game at least equals the player paid price associated with the blackjack
session contract.

22. The method of claim 21, wherein the total wager placed by the player
in association with the at least two plays of the blackjack game exceeds
the player paid price associated with the session contract

23. The method of claim 21, wherein the blackjack session contract is
associated with a predetermined quantity of distinct plays of the
blackjack game.

24. The method of claim 21, wherein the blackjack session contract is
associated with a predetermined quantity of wagers placed on the plays of
the blackjack game.

25. The method of claim 21, wherein the blackjack session contract is
associated with a predetermined quantity of generated and displayed
blackjack game outcomes that are each associated with an award having a
value greater than zero.

26. The method of claim 21, wherein the blackjack session contract is
associated with a predetermined duration of time to place wagers on the
plays of the blackjack game.

27. The method of claim 21, which is operated through a data network.

28. The method of claim 27, wherein the data network is an internet.

Description:

PRIORITY CLAIM

[0001]This application is a continuation of, claims priority to and the
benefit of U.S. patent application Ser. No. 11/425,037, filed on Jun. 19,
2006, which is a continuation of, claims priority to and the benefit of
U.S. patent application Ser. No. 11/293,016, filed on Dec. 2, 2005, which
is a continuation of, claims priority to and the benefit of U.S. patent
application Ser. No. 10/001,089, filed on Nov. 2, 2001, now U.S. Pat. No.
7,140,964, which claims priority to and the benefit of U.S. patent
application Ser. No. 60/282,792, filed on Apr. 10, 2001 and which also is
a continuation-in-part of, claims priority to and the benefit of U.S.
patent application Ser. No. 09/518,760, filed on Mar. 3, 2000, now U.S.
Pat. No. 6,319,127, which is a continuation of, claims priority to and
the benefit of U.S. patent application Ser. No. 08/880,838, filed on Jun.
23, 1997, now U.S. Pat. No. 6,077,163, the entire contents of which are
each incorporated by reference herein.

BACKGROUND OF THE INVENTION

[0002]1. Field of the Invention

[0003]The present invention relates generally to the structure and
operation of at least one gaming device, such as a slot machine, wherein
a flat rate price purchases a flat rate play session comprising multiple
plays.

[0004]2. Description of Related Art

[0005]There are numerous types of gaming devices in use today. Most of
these gaming devices, such as slot machines, video blackjack machines,
video poker machines, and the like, require the player of the device to
purchase individual plays at a set cost or wager per play. Because
players can only purchase individual plays, they may stop playing after
any individual play. Furthermore, having to purchase each individual play
is inconvenient. Thus, a need exists for a gaming device allowing more
convenient and efficient methods of play.

[0006]One scenario in which players seemingly purchase multiple plays on a
gaming device during a flat rate play session is entry fee slot machine
tournaments. Such tournaments typically involve players paying a fee for
a set period of play determined by the casino. During such tournaments,
each player plays a specific type and denomination of machine, also
determined by the casino, and accumulates points rather than money. Those
players accumulating the most points are awarded prizes.

[0007]Although slot machine tournaments are popular with some players, the
tournaments are inflexible and not accommodating to individual player's
preferences. The organizers set the time and duration of the tournament,
the cost to play, the amount wagered per play, and the type of machines
which are played. Furthermore, the organizers must designate machines for
the tournament. Because these machines are available only to tournament
players and not the general public, the machine owners lose revenue for
all machines designated but not played during a tournament. Thus, a need
still exists for a gaming device which allows tournament style play
without comprising the revenue stream of a casino, particularly where the
player selects the time and duration of the period, the amount wagered
per play, and the particular gaming device played.

SUMMARY OF THE INVENTION

[0008]In accordance with the present invention, there is provided a
method, apparatus and article of manufacture for providing a gaming
session using a gaming device. In one embodiment, the method includes
identifying at least one price parameter, determining a flat rate price
based upon the at least one identified price parameter, and initiating a
flat rate play session of the gaming device upon receiving an indication
of payment of the flat rate price. The flat rate play session spans a
pre-established duration. A duration may comprise a specified amount of
time and/or a specified number of game plays (e.g. handle pulls of a slot
machine).

[0009]In one embodiment, the price parameter is a player selected price
parameter, such as the amount wagered per play, jackpot structure, length
of the flat rate play session, the type of gaming device, time of day,
day of the week, and day of the year. In another embodiment, the price
parameter is an operator selected price parameter, such as player status
rating, availability of gaming devices, and anticipated availability of
gaming devices.

[0010]In accordance with one embodiment, the flat rate play session may be
purchased by means of purchasing a contract from a casino, wherein the
contract specifies terms such as, for example, a price to be paid by the
purchaser for the contract, a duration of play of a gaming device, and a
threshold of credits above which the player may collect winnings from a
gaming device. The terms of the contract may be determined based on
player selected price parameters and/or operator controlled price
parameters. Such a contract may involve a third party that acts as an
insurer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011]FIG. 1 is an overall schematic view of a system according to one
embodiment of the present invention, including a slot machine and a slot
network server;

[0032]FIG. 21 is a table illustrating an embodiment of the player database
stored in the casino server of FIG. 17.

[0033]FIG. 22 is a table illustrating an embodiment of the gaming device
database stored in the casino server of FIG. 17.

[0034]FIG. 23 is a table illustrating an embodiment of the contract
database stored in the casino server of FIG. 17.

[0035]FIG. 24 is a flowchart illustrating a process in accordance with one
embodiment of the present invention, the process corresponding to the
system illustrated in FIG. 16.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0036]Certain preferred embodiments of the present invention will now be
described in greater detail with reference to the drawings. Although the
embodiments discussed herein are directed to reel slot machines, it
should be understood that the present invention is equally applicable to
other gaming devices, such as video poker machines, video blackjack
machines, video roulette, video keno and the like.

[0037]The present invention is directed generally to a method and
apparatus for operating a gaming device having a flat rate play session.
As used herein, flat rate play session is defined as a period of play
wherein the player need not make funds available for any play during the
play session. The flat rate play session spans multiple plays of the
gaming device. These multiple plays are aggregated into intervals or
segments of play. It is to be understood that the term interval as used
herein could be time, handle pulls, and any other segment in which slot
machine play could be divided. For example, two hours, one hundred spins,
fifty winning spins, etc. A player enters player identifying information
and player selected price parameters at a gaming device. The price
parameters define the flat rate play session, describing the duration of
play, machine denomination, jackpots active, etc. The gaming device
stores the player selected price parameters and proceeds to retrieve the
flat rate price of playing the gaming device for the flat rate play
session. The player selected price parameters, in combination with
operator price parameters, determine the flat rate price. Should the
player decide to pay the flat rate price, the player simply deposits that
amount into the gaming device or makes a credit account available for the
gaming device to debit. For example, it might cost twenty-five dollars to
play for half an hour.

[0038]Once the player initiates play, the gaming device tracks the flat
rate play session and stops the play when the session is completed,
usually when a time limit has expired. During the play session, the
player is not required to deposit any coins. Payouts are made either
directly to the player in the form of coins or indirectly in the form of
credits to the credit balance stored in the machine. It should be
understood that the player balance could be stored in a number of
mediums, such as smart cards, credit card accounts, debit cards, and
hotel credit accounts.

[0039]With reference to FIG. 1, a system 100 according to one embodiment
of the present invention is shown. In general, the system 100 comprises
multiple slot machines 102 and a slot network server 106. In the present
embodiment, each slot machine 102, which is uniquely identified by a
machine identification (ID) number, communicates with the slot network
server 106 via a slot network 104. The slot network 104 is preferably a
conventional local area network controlled by the server 106. It is to be
understood, however, that other arrangements in which the slot machines
102 communicate with the server 106 are within the scope of the present
invention.

[0040]As will be described in greater detail below, in one embodiment, the
slot machine 102 communicates player identifying information to the slot
network server 106. The slot network server 106, in turn, verifies the
player identifying information. The slot machine 102 also calculates a
flat rate price based on both player selected and casino determined price
parameters and displays the flat rate price to the player. The player may
then accept the flat rate price and initiate play. In another embodiment,
the present invention may be practiced without server 106, in an
arrangement in which the slot machine 102 calculates the flat rate price.

[0041]With reference to FIG. 2A, the slot machine 102 will now be
described in greater detail. The slot machine 102 contains a Central
Processing Unit (CPU) 210, a clock 212, and an operating system 214
(typically stored in memory as software). The CPU 210 executes
instructions of a program stored in Read Only Memory (ROM) 216 for
playing the slot machine 102. The Random Access Memory (RAM) 218
temporarily stores information passed to it by the CPU 210 during play.
Also in communication with the CPU 210 is a Random Number Generator (RNG)
220.

[0042]With respect to gaming operations, the slot machine 102 operates in
a conventional manner. The player starts the machine 102 by inserting a
coin into coin acceptor 248, or using electronic credit, and pressing the
starting controller 222. Under control of a program stored, for example
in a data storage device 224 or ROM 216, the CPU 210 initiates the RNG
220 to generate a number. The CPU 210 looks up the generated random
number in a stored probability table 226, which contains a list which
matches random numbers to corresponding outcomes, and finds the
appropriate outcome. Based on the identified outcome, the CPU 210 locates
the appropriate payout in a stored payout table 228. The CPU 210 also
directs a reel controller 230 to spin reels 232, 234, 236 and to stop
them at a point when they display a combination of symbols corresponding
to the appropriate payout. When the player wins, the machine stores the
credits in RAM 218 and displays the current balance in video display area
238. In an alternate embodiment, the slot machine 102 dispenses the coins
to a payout tray (not shown), and in another embodiment, the slot network
server 106 stores the player credits.

[0043]A hopper controller 240 is connected to a hopper 242 for dispensing
coins. When the player requests to cash out by pushing a cashout button
(not shown) on the slot machine 102, the CPU 210 checks the RAM 218 to
see if the player has any credit and, if so, signals the hopper
controller 240 to release an appropriate number of coins into a payout
tray (not shown). A coin acceptor 248 is also coupled to the CPU 210.
Each coin received by the coin acceptor 248 is registered by the CPU 210.

[0044]In alternate embodiments, the slot machine 102 does not include the
reel controller 230 and reels 232, 234 and 236. Instead, a video display
area 238 graphically displays representations of objects contained in the
selected game, such as graphical reels or playing cards. These
representations are preferably animated to display playing of the
selected game.

[0045]Also in communication with the CPU 210 is a player tracking device
260. The tracking device 260 comprises a card reader 266 for reading
player identifying information stored on a player tracking card. As used
herein, the term player identifying information denotes any information
or compilation of information that uniquely identifies a player. In the
present embodiment, the identifying information is a player
identification (ID) number. Although not so limited, the player tracking
card of the present embodiment stores the player ID on a magnetic strip
located thereon. Such a magnetic strip and device to read the information
stored on the magnetic strip are well known.

[0046]The player tracking device 260 also includes a display 262 and a
player interface 264. The player interface 264 may include a keypad
and/or a touchscreen display. In operation, as discussed below, the slot
machine 102 displays a message prompting the player to enter player
selected price parameters. In the present embodiment, a player may enter
the player selected price parameters via the player interface 264.
Because the player interface 264 is part of the tracking device 260, it
is, therefore, in communication with the CPU 210. Alternatively, input of
selected price parameters may be accomplished through video display area
238 if it is configured with touch screen capabilities.

[0047]The slot machine 102 also includes a series of bet buttons 272, 274,
276. The bet buttons include "Bet 1 coin" 272, "Bet 2 coins" 274, and
"Bet 3 coins" 276. The bet buttons 272, 274, 276 are coupled to the CPU
210. Therefore, pressing one transmits a signal to the CPU 210 indicating
how much a player is wagering on a given play.

[0049]Also connected to the CPU 210 is a slot network interface 250. The
slot network interface 250 provides a communication path from the slot
machine 102 to slot network server 106 through the slot network 104.
Thus, as discussed in greater detail below, information is communicated
among the player tracking card, player tracking device 260, slot machine
102, and slot network server 106.

[0050]With reference to FIG. 2B, the plan view of slot machine 102, will
now be described below. FIG. 2B depicts slot machine 102 displaying
player selected price parameter options on video display area 238.
Included in the displayed parameters is amount wagered per play 712,
interval 714, duration of interval 722, and active pay combinations 720.
As will be described further below, after the player has selected the
desired price parameters, the slot machine 102 displays a flat rate price
724. Once the player has accepted the flat rate price and made the
appropriate funds available, play may commence.

[0051]The slot network server 106 will now be described in greater detail
with reference to FIG. 3. Like the slot machine 102 of FIG. 2, the slot
network server 106 has a Central Processing Unit (CPU) 310. The CPU 310,
which has a clock 312 associated therewith, executes instructions of a
program stored in Read Only Memory (ROM) 320. During execution of the
program instructions, the CPU 310 temporarily stores information in the
Random Access Memory (RAM) 330.

[0052]Additionally, the CPU 310 is coupled to a data storage device 340,
having a flat rate database 246, transaction processor 342 and a casino
player database 344. In general, the transaction processor 342 manages
the contents of the data storage devices 340. As discussed in detail
below, the casino player database 344 stores information specific to each
player, including player identifying information.

[0053]In order to communicate with the slot machines 102, the slot network
server 106 also includes a communication port 350. The communication port
350 is coupled to the CPU 310 and a slot machine interface 360. Thus, the
CPU 310 can control the communication port 350 to receive information
from the data storage device 340 and RAM 330 and transmit the information
to the slot machines 102 and vice versa.

[0054]It is to be understood that because the slot machines 102 are in
communication with the slot network server 106, information stored in a
slot machine 102 may be stored in the server 106 and vice versa. Thus,
for example, in an alternate embodiment, the server 106 rather than the
slot machine 102 includes the payout table 228, flat rate database 246,
and/or calculation table 227.

[0055]The casino player database 344 of the present embodiment, as shown
in FIG. 4, includes multiple records having multiple fields of
information. Specifically, the casino player database 344 comprises
multiple records, each record being associated with a particular player,
as identified by a player identification (ID) number. The fields within
each record include: player identification (ID) number 410, social
security number 412, name 414, address 416, telephone number 418, credit
card number 420, credit balance 422, complimentary information, such as
total accumulated complimentary points 424, whether the player is a hotel
guest 426, player status rating 428, and value of interval remaining 430.
Having information related to one field, such as player ID 410, allows
the slot network server 106 to retrieve all information stored in
corresponding fields of that player record.

[0056]It is to be understood that not all of these identifying fields are
necessary for operation of the present embodiment. For example, the name
414, social security number 412, address 416, telephone number 418,
credit card number 420, and hotel guest 426 fields are merely
representative of additional information that may be stored and used for
other purposes. In one embodiment, credit card number 420 and hotel guest
426 are used for billing purposes and social security number 412 is used
to generate tax forms when a player wins a jackpot over a given amount.

[0057]Complimentary points awarded 424 is further illustrative of
additional information a casino may store in a player's record. As
described below, a player's complimentary points are displayed to the
player when a player tracking card is inserted into the slot machine 102.
In an alternate embodiment, such points may be used in addition, or as an
alternative to the credit balance 422 stored in RAM 218 of slot machine
102.

[0058]The player status rating 428 contains information representative of
the particular player's relative importance to the casino, as based upon
the frequency and duration of the player's visits, the amount of money
wagered, and the like.

[0059]The value of interval remaining field 430 stores the value of
interval remaining in a flat rate play session when a player terminates
the play session prior to its expiration. This field will be described in
greater detail below.

[0060]The flat rate database 246 will now be described in greater detail
with reference to FIG. 5. The flat rate database 246 comprises multiple
records, each record pertaining to the flat rate play session of a
particular player, as identified by that player's ID number.
Consequently, one field in flat rate database 246 is the player ID number
field 510. Other fields include: player selected price parameters 512,
flat rate price 514, interval remaining 516, time audit data 518, and
machine identification (ID) number field 520. The machine ID number field
520 contains the machine ID number that uniquely identifies the slot
machine 102. It is to be understood that since both the casino player
database 244 and the flat rate database 246 include a player ID field,
410 and 510, respectively, the system 100 can correlate any player
information stored in the casino player database 344, with any player
information stored in the flat rate database 246.

[0061]The payout table 228 will now be described in greater detail with
reference to FIG. 6. As shown in FIG. 6, the payout table 228 of the
present embodiment can be logically represented by five fields of related
information. The first field, a pay combination field 610, identifies the
set of possible pay combinations for a given slot machine 102. Such
possible pay combinations include winning pay combinations, or those in
which a payout results, and non-winning pay combinations, in which the
player receives no payout and consequently loses the amount wagered.
Winning pay combinations include, for example, "DOUBLE JACKPOT-DOUBLE
JACKPOT-DOUBLE JACKPOT" and "BAR-BAR-BAR." The pay combinations field 610
also includes a "NON-WINNING OUTCOMES" record, an entry representing the
outcomes which result in no payout to the player, such as
"PLUM-BELL-ORANGE."

[0062]The payout table 228 also includes three payout fields 620, 630,
640. Such payout fields 620, 630, 640 contain the payout information for
each of the possible pay combinations identified in the pay combinations
field 610. Each of the payout fields 620, 630, 640 is identified by the
number of coins wagered on a particular play, as selected via the bet
buttons 272, 274, 276. In the present embodiment, payout table 228
contains a "1 coin" payout field 620, which is accessed when one coin is
wagered, a "2 coins" payout field 630, which is accessed when two coins
are wagered, and a "3 coins" payout field 640, which is accessed when
three coins are wagered. In other words, each field 620, 630, 640
corresponds to a bet button 272, 274, 276, respectively. The payout
information provides the number of coins won upon the occurrence of a
particular pay combination. Thus, "CHERRY-CHERRY-CHERRY" pays out ten
coins when one coin is wagered.

[0063]Finally, the payout table 228 of the present embodiment includes a
pay combination status field 650. The pay combination status field 650
includes an indication for each winning pay combination, identified in
the pay combination field 610, of whether the player is eligible to win
the payout for each outcome. As will be described below, the
determination of whether a player is eligible to win a payout for a given
outcome is made by the player as part of the player selected price
parameters.

[0064]The calculation table 227 will now be described in greater detail
with reference to FIG. 7. The calculation table 227 is used by the system
100 in determining the flat rate price 724 (field 514 in the flat rate
database 246) charged to the player. Specifically, the calculation table
227 contains multiple price parameters which are correlated to a flat
rate price 724. More specifically, these price parameters include player
selected price parameters and operator selected price parameters. In
general, player selected price parameters include any game related
variable that defines the flat rate play session. Furthermore, operator
selected price parameters are parameters which the operator of the slot
machines 102 selects as affecting the flat rate price 724. Thus, in the
present embodiment, the player selected price parameters in the
calculation table 227 include machine type 710, amount wagered per play
712, active pay combinations 720, and length of the flat rate play
session 722. The operator selected price parameters in the calculation
table 227 include player status rating 714, time of day 716, day of the
week 718, and machine usage 719. In the present embodiment the flat rate
price 724 is predetermined based upon the aforementioned price parameters
and stored in the calculation table 227, as will be described later in
FIGS. 14 and 15. In an alternate embodiment the flat rate price 724 is
calculated based upon these parameters as needed according to a price
algorithm stored in memory. For example, the price algorithm may operate
as follows:

Algorithm for Calculating a Flat Rate Price.

[0065]The are any number of algorithms that could be used to calculate a
flat rate price, and they can be generally described as calculating an
expected value to the customer and then adding in a margin for the casino
or adjusting the price to reflect the time of day, value of the customer,
etc.

[0066]The first step is to determine a "base" flat rate price. This would
be calculated as follows:

Base Price=[(amount wagered)×(interval)]×[(expected coins
awarded for all active pay combinations over a cycle/expected coin-in
over a cycle)].

[0067]For example, the following Base Price calculation represents a
player selecting three dollar coins per handle pull, an interval of 500
handle pulls, and the top three pay combinations active. For this example
we will assume that a complete cycle of the slot machine is 10,648 unique
outcomes and that the top three pay combinations would pay 2,160 coins
over that cycle. Note also that the expected coins awarded for all active
pay combinations over a cycle and the expected coin-in over the cycle
should both reflect the same number of coins wagered. Essentially, this
ratio reflects the expected monetary return to the payer on a per coin
wagered basis. When multiplied by the amount wagered and the number of
handle pulls the number reflects the amount of money that the player
would be expected to receive from the machine over the interval
specified. It should be notes that this amount of money is not
necessarily the number of coins entered by the player but rather is the
theoretical number of coins of play allowed by the flat rate session.
Continuing with the calculation:

[0068]Note that if the player were to pay this Base Price he would be
essentially getting a fair bet for his money. He would pay $304.28 for
the session and expect (over the long run) to get $304.28 back in prize
money from the top three active pay combinations. Of course in the short
run his results could range from receiving no payouts over the interval
to receiving thousands of dollars. Because this base price is a fair bet
for the player the casino may want to add in margin for the house,
perhaps by multiplying the base price by a predetermined margin factor
such as 50%. In this example the Profit Adjusted Price would thus be:

Profit Adjusted Price = $304 .28 × 150 %
= $456 .42 ##EQU00002##

[0069]Of course the casino might want to offer flat rate sessions to
players without a casino markup under some circumstances, such as part of
a promotional package or to reward a particularly loyal customer. In fact
the casino might even decrease the base price in some circumstances.

[0070]The Base Price or (Profit Adjusted Price) could be further modified
by various other operator price parameters such as the following:

[0071]1. Time of Day (TD).

[0072]Times of the day in which the casino traffic tends to be heavy
should result in the player paying a premium for the flat rate session,
while quiet times in the casino should offer the player a discount over
normal rates.

[0078]When the majority of slot machines in the casino are being used, a
premium is applied to the cost of the flat rate play session in order to
more evenly distribute play. For example:

TABLE-US-00004
Heavy 120%
Moderate 100%
Light 80%

[0079]Sample Calculation.

[0080]In addition to the above player selected price parameters, the
following operator selected parameters are incorporated into the price:
The player is in the casino at 2 am on a Wednesday, there is low slot
machine usage, and the player has an average rating. The calculations
below reflect these conditions:

[0081]The casino may round up this price to $137 to avoid the need for
small change. In the above calculations, the casino might also
incorporate floors which prevent the Base Price from going below a level
that would be profitable for the house, regardless of the number of
positive criterion that were applied to the base price.

[0082]Those of ordinary skill in the art will appreciate that
modifications could be made to the formula to reflect different kinds of
flat rate sessions. For a session with an interval of one hour (instead
of a fixed number of handle pulls) the formula might reflect an expected
number of handle pulls per hour for that particular game, perhaps even
adjusted to reflect the type of player purchasing the flat rate session.
For example, an experienced video poker player might be expected to reach
700 hands per hour while a beginner might only be expected to reach 300
hands per hour.

[0083]As will also be understood by those skilled in the art, the ultimate
goal of many slot machine players is to hit a jackpot payout. The
enjoyment of the play, as well as the ability to maximize the chance of
hitting a large jackpot, is increased by more play. Play can be increased
both by playing longer, and by playing faster. As will be appreciated
from a consideration of the process described below, the present
invention permits both increased duration, by providing for play at
discounted prices, and speed of play, by providing for minimal time
delays between plays.

[0084]The flat rate price package database 229 will now be described in
greater detail with reference to FIG. 14. The flat rate price package
database 229 is used by the system 100 in providing the player with
different price package options for flat rate play of the slot machine
100. Specifically, the flat rate price package database 229 contains
multiple combinations, or packages 1410, of price parameters which
correspond to pre-established flat rate prices. More specifically, these
price parameters include but are not limited to, interval 1412, duration
of flat rate play 1414, amount wagered per play 1416, and pay combination
status 1418. Each combination of price parameters has corresponding flat
rate play session prices 1420. As will be described later in FIG. 15, the
flat rate price package database 229 is accessed when the player
determines he wishes to initiate a flat rate play session. Rather than
let the player choose the price parameters, the slot machine 100 lists
the different packages stored in the flat rate price package database
229. The player then chooses the package he likes the most and play
commences.

[0085]Having thus described the components of the present embodiment, the
operation of the system 100 will now be described in greater detail with
reference to FIGS. 8-11, and continuing reference to FIGS. 1-7. It is to
be understood that the programs stored in ROM 320 of the slot network
server 106 and ROM 216 of the slot machine 102 provide the function
described below.

[0086]Turning first to FIGS. 8a and 8b, the general operation of the
system 100 will be described. As shown in step 810, the slot machine
player first inserts the player tracking card into the card reader 266.
The card reader 266 then proceeds to read player identifying information
from the tracking card. The player identifying information, namely the
player ID number, is communicated from the slot machine 102 to the slot
server 106 in step 812.

[0087]Upon receiving the player identifying information, the slot network
server 106 verifies the information in step 814. Such verification
includes the slot network server 106 searching the casino player database
344 for a record containing the received player ID number in the
appropriate field 410. Once the slot network server 106 verifies the
player identifying information, the server 106 transmits a signal to the
slot machine 102 acknowledging such verification in step 816. In
alternate embodiments, other information, such as the player's name 414,
complimentary point total 424, and player status rating 428 are
transmitted to the slot machine 102 for display.

[0088]In step 818, the player selects flat rate play via the player
interface 264. The CPU 210 of slot machine 102, in step 820, then
receives a signal from the player interface 264, indicating that the
player has selected flat rate play. For example, there could be a button
specifically for triggering a flat rate play session. The CPU 210, in
response, accesses memory to retrieve player selectable price parameters.
Player selectable price parameters are the choices available to a player
for entering the player selected price parameters. These player
selectable price parameters are controlled by a program stored in ROM
216. Such player selectable price parameters, in the present embodiment,
include the amount wagered per play, (e.g. one, two, or three coins), the
length of the flat rate play session, and possible jackpot structures,
such as having only the "DOUBLE JACKPOT" and "5 BAR" jackpots active (as
illustrated in the payout table 228 of FIG. 6). In an alternate
embodiment, the player selectable price parameters are stored as part of
the calculation table 227.

[0089]Then, as shown in step 822, the slot machine 102 displays the player
selectable price parameters to the player. For example, the parameters
could be listed on the video display area 238 for the player, as
described previously in FIG. 2B. Once the parameters appear, the player
simply selects his desired settings. Alternatively, the player may accept
one or more default settings. Once the player selectable price parameters
are displayed on the display 238, the player proceeds, in step 824, to
enter player selected price parameters via the player interface 264. The
player selected price parameters also include data which, although not
directly inputted by the player, is selected by the player and identified
by the slot machine 102. In the present embodiment, such additional
player selected price parameters include type of machine, time of day,
and day of the week.

[0090]It is to be understood that the casino operator of the slot machines
102 may define the scope of the player selectable price parameters, and
therefore limit the player selected price parameters in any manner. For
example, the length of flat rate play may be limited to periods above a
minimum time or to periods that are multiples of thirty minute intervals.
The jackpot structure may require that some jackpots remain active.

[0091]Referring now to FIG. 8B, the slot machine 102 CPU 210 receives the
player selected price parameters in step 826. Having received the player
selected parameters, the CPU 210 then stores the player selected price
parameters, the player identifying information, and the slot machine's
machine ID number in a record in the flat rate database 246.
Specifically, the player ID number is stored in field 510, the machine ID
number is stored in field 520, and the player selected price parameters
are stored in field 512. Although the player selected price parameters
are illustrated as being stored in a single field (512), it is to be
understood that each player selected price parameter may be stored in a
separate field. It is also to be understood that in alternate embodiments
the player selected price parameters need not be stored in a database,
but could be stored in RAM 218.

[0092]The slot machine 102 CPU 210 uses the player selected price
parameters to determine the flat rate prices. Specifically, in step 828,
the CPU 210 accesses the calculation table 227 and searches for the flat
rate price 724 corresponding to the received player selected price
parameters 512, which, in the present embodiment, include machine type
710, amount wagered per play 712, time of day 716, day of the week 718,
active jackpots 720, and the length of the flat rate play session 722.
The CPU 210 also incorporates operator selected price parameters for the
flat rate price 724 such as player status rating 714 and machine
availability 719. As will be appreciated by one skilled in the art, the
player status rating 714 is received from the casino player database 344
at any time prior to determination of the flat rate price 724. Thus, in a
preferred embodiment, the slot network server 106 transmits the player
status rating 428 to the slot machine 102 along with the verification
signal in step 816.

[0093]By including the player status rating 714 in the calculation table
277, a casino may reward frequent players who wager relatively large
amounts of money with a lower flat rate price 724. Thus, the system 100
rewards and encourages frequent play. By including active jackpots 720 in
the calculation table 348, the system 100 allows a casino to discount the
flat rate price 724 for those players who choose to enable relatively few
winning outcomes in the payout table 228. Furthermore, by including the
price parameters relating to time of day and day of the week in the
calculation table 227, a casino may charge a lower flat rate price 724
for sessions during weekday afternoons or between 2:00 a.m. and 8:00 a.m.
in the mornings, thereby encouraging play of the slot machines 102 when
they are typically idle.

[0094]It is to be understood that the aforementioned price parameters in
the calculation table 227 are merely representative of the type of
variables that may be considered in determining a flat rate price. Thus,
it is within the scope of the present invention to include only some of
the price parameters, all of the parameters, or additional parameters in
the calculation table 227.

[0095]As mentioned above, the flat rate price may be based partly upon the
availability of slot machines 102. In such an embodiment, the server 106
tracks whether each slot machine 102 is being used by noting whether
outcomes are currently being received from a given slot machine 102. In
another embodiment, the server 106 tracks slot machine availability by
tabulating the number of slot machines 102 for which flat rate play is
currently enabled. In yet another embodiment, the server 106 tracks slot
machine availability by identifying how many slot machines 102 have a
player tracking card inserted therein.

[0096]Another price parameter which may be used is predicted or forecasted
slot machine availability. Specifically, such a parameter accounts for
anticipated availability of slot machines 102 based upon events at the
casino. For example, the calculation table 227 correlates a lower flat
rate price 724 to the time of day 716 corresponding to an event, such as
a show which many casino players attend. On the other hand, the
calculation table 227 correlates a higher flat rate price to the time of
day 716 corresponding to the end of the event or heavier casino traffic.
This enables a casino to effectively revenue manage their slot machines
without resorting to a change in hold percentage which requires
regulatory approval.

[0097]It is to be understood that accounting for slot machine availability
need not be accomplished in the calculation table 227. Rather, in an
alternate embodiment, a schedule of events is stored in RAM 218 which is
accessed prior to transmitting the flat rate price 724 to the player. If
the event schedule indicates that an event is ending during the requested
flat rate play session, then the flat rate price 724 will be incremented
accordingly.

[0098]In another embodiment, the flat rate price is based only on operator
selected price parameters. A slot machine 102 according to such an
embodiment could, for example, provide discounted flat rate play sessions
based on player status rating, thereby offering 100 plays for the price
of 90 or discounted timed sessions. To encourage repeat, high stakes
play, higher player status ratings result in greater discounts.

[0099]Having determined the flat rate price 724, the slot machine 102, in
step 830, displays the duration of the flat rate play session 722 and the
flat rate price 724 and requests approval from the player. Once the
player accepts the terms of the flat rate play session, flat rate play
commences.

[0100]If the player does not approve the flat rate price 724, then the
player indicates so via the player interface 264. As indicated by path A
in FIGS. 8a and 8b, the slot machine 102 repeats its operation from step
822. On the other hand, if the player approves the flat rate price 724,
the player indicates such approval via the player interface 264 in step
832. Following such approval, the slot machine 102 prompts the player to
enter an appropriate amount of money in step 834. In the present
embodiment, the player deposits coins into the coin acceptor 248. In one
embodiment, the player deposits a casino token as payment for the flat
rate session. Such tokens may be denominated in dollars, or represent a
number of handle pulls. A casino could thus sell a fifty handle pull
token, usable on a particular denomination and/or type of machine. Such a
token may additionally serve to activate the flat rate session,
eliminating the need for the player to select flat rate play via player
interface 264. Alternatively, the player's credit balance 422 may be
debited to pay for the flat rate play session.

[0101]In some embodiments a casino token may be associated with a
particular set of pay combinations which are to be active during a flat
rate play session activated via the token. In yet other embodiments a
casino token may be associated with (i) a specified duration of time,
(ii) a specified number of handle pulls or outcomes, (iii) a specified
number of winning handle pulls or outcomes, and/or (iv) a flat rate price
package as, for example, described with reference to the flat rate price
package database 299 of FIG. 14. A gaming device may identify such a
token and enter the appropriate flat rate play session by, for example,
the size and/or weight of the token or by reading or receiving
information from the token (e.g. via a computer chip embedded in the
token or special markings on the token). Such a casino token may be, for
example, purchased by a person and given to another person as a gift. The
recipient may subsequently use the token by inserting it into an
appropriate gaming device and essentially playing for "free" (since the
person that gave the gift had prepaid for the token) for a specified
duration.

[0102]Once the CPU 210 registers the receipt of money, the CPU 210
reconfigures the slot machine 201 for the flat rate play session in step
836. Specifically, the CPU 210 generates a signal, or a flag in memory,
indicating that there is no need to accept the coins between plays. CPU
210 further sets the active field 650 in the payout table 228 according
to the jackpot structure entered by the player.

[0103]The operation of the slot machine 102 during the flat rate play
session will now be described with reference to FIG. 9 and continuing
reference to FIGS. 1-7. During the flat rate play session, a slot machine
102 operates generally as described above with reference to FIG. 2.
However, the slot machine 102 is reconfigured to operate according to the
player selected price parameters, if such parameters affect play, and to
operate continuously, without requiring payment between each play.
Specifically, the flat rate play session begins when the player presses
the starting controller 222 in step 910. The CPU 210 also initiates a
countdown of the length of the flat rate play session as stored in the
player selected parameters field 512 of the flat rate database 246. With
the start of the session, the CPU 210 stores the start time of the flat
rate play session in the flat rate database 246. Specifically, the start
time is stored in the time audit data field 520 in step 912. In step 914,
the CPU 210 begins to count down the duration of the flat rate play
session. Next, in step 916, the slot machine 102 generates an outcome and
accesses payout table 228 to determine the appropriate corresponding
number of coins to be paid out.

[0104]Furthermore, in step 918, after each outcome is generated, the slot
machine 102 determines whether the countdown of the interval remaining
516 has reached zero. It is to be understood that the countdown may be
implemented in either software or hardware. Additionally, it is
understood that the countdown process discussed herein may be replaced
with any suitable means for tracking the duration of the flat rate play
session. Interval remaining 516 may also represent the number of handle
pulls remaining.

[0105]In the event that the countdown has not reached zero, the player
presses the starting controller 222 in step 920, thereby initiating
another play of the slot machine 102. In the event that the countdown has
reached zero, the CPU 210 generates a signal indicating that the flat
rate play session has concluded. The slot machine 102 displays a message
indicating this to the player and, in step 922, stores the end time of
the session in the time audit data field 518 of the flat rate database.

[0106]In an alternate embodiment, the player selected price parameters
include the "time between plays." In this embodiment, the CPU 210 of slot
machine 102 controls the time between generating outcomes of successive
plays in the slot machine 102 to equal the received "time between plays"
player selected price parameter. In another alternate embodiment, the
slot machine 102 tracks the number of plays during the flat rate play
session. If the number of plays exceeds a predetermined limit, the slot
machine 102 automatically terminates the flat rate play session,
regardless of the duration of the flat rate play session.

[0107]Turning now to FIG. 10, the operation of the system 100 when the
player terminates the flat rate play session prior to the expiration of
the session will be described. In step 1010, the player indicates a
desire to terminate the flat rate play session via the player interface
264. Consequently, the slot machine 102 CPU 210 receives a termination
signal and, in step 1012, displays a message to the player, asking the
player to verify termination of the flat rate play session. If the player
does not verify termination, then the session continues as described
above with reference to FIG. 9. On the other hand, if the player verifies
termination, shown as step 1014, the CPU 210 proceeds to store the stop
time in the time audit data field 518 of the flat rate database 246 in
step 1016.

[0108]It is to be understood that having both the start time and the stop
time of the flat rate play sessions stored in the flat rate database 246
allows the casino to perform an audit of the session. Specifically,
should a player allege that the flat rate play session was shorter than
that which was paid for, the casino may access the flat rate database 246
and retrieve the actual start and stop time from the time audit data
field 520. In the present embodiment, this time includes an indication of
the day, hour, and minute of the play session.

[0109]Next, in step 1018, CPU 210 determines the value of the interval
remaining in the flat rate play session and transmits the value to the
server 106. In order to determine the value of the interval remaining,
the CPU 210 accesses the calculation table 227. The value of interval
remaining will equal the flat rate price 724 corresponding to the price
parameters (i.e., the machine type 710, amount wagered per play 712,
player status rating 714, time of day 716, etc.) used to determine the
original flat rate price charged to the player. When determining the
value of the interval remaining, however, the value in the length of flat
rate play session field 722 is not the original length of the session,
but rather is equal to the actual interval remaining in the flat rate
play session. Stated succinctly, the slot machine 102 identifies the flat
rate price 724 corresponding to the actual interval remaining in the flat
rate play session.

[0110]Once the value of interval remaining is determined, the slot machine
102 transmits the value to the slot network server 106. Upon receiving
the value of interval remaining, the server 106 stores the value in field
430 of the casino player database 344 in the player's record, as
identified by the player ID number 410. Storing the value is shown as
step 1020. Finally, in step 1022, the player removes the player tracking
card.

[0111]The process of resuming play at another slot machine 102 will now be
described with reference to FIGS. 11a and 11b. The initial operation of
the system 100, as indicated by steps 1110-1128, proceeds generally as
described above with reference to steps 810-828 of FIGS. 8a and 8b.

[0112]However, once the CPU 210 of slot machine 102 determines a new flat
rate price based on the relevant price parameters, the CPU 210 determines
whether the player must deposit additional funds.

[0113]Specifically, in step 1130, the CPU 210 compares the new flat rate
price 724 with the value of interval remaining 430. The server 106
transmits the value of interval remaining 430, as stored in the casino
player database 344, to the slot machine 102 in step 1116 so that the
comparison may be performed. As indicated by step 1132, the comparison
involves determining whether the new flat rate price 724 is higher than
the value of interval remaining 430.

[0114]If the new price 724 is not higher than the value of interval
remaining 430, then, in step 1134, the slot machine allows the player to
play the flat rate session at no cost. However, if the new flat rate
price 724 is higher than the value of interval remaining 430, then, in
step 1136, the CPU 210 assigns the difference in the two values as the
new flat rate price. Thus, in step 1138, the CPU 210 displays the new
flat rate price on the video display area 238 of the slot machine 102.
Thereafter, operation of the system continues as described above with
reference to steps 832-836 of FIG. 8B.

[0115]In an alternate embodiment, when a player terminates the flat rate
session early, the value of the interval remaining is added to the
player's credit balance, as stored in field 422 of the casino player
database 344.

[0116]It is to be understood that an embodiment of the present invention
need not include both a slot machine and slot network server. For
example, an embodiment employing only a slot machine 102 is within the
scope of the present invention. Such an embodiment will now be described
with reference to FIGS. 12a, 12b, and 13, and continuing reference to
FIGS. 2, 5, and 7. Such an embodiment utilizes the slot machine 102 of
FIG. 2.

[0117]Initially, the player selects flat rate play on the slot machine 102
in step 1210. Once the player selects flat rate play, the flat rate play
signal is transmitted from the player interface 264 to the CPU 210 in
step 1212. The CPU 210 then proceeds, in step 1214, to retrieve the
player options for selectable price parameters. Then, in step 1216, the
CPU 210 transmits the player selectable price parameter options to the
video display area 238 for viewing.

[0118]Once the player selectable price parameter options have been
displayed to the player, the player inputs the player selected price
parameters through the player interface 264. Then, in step 1220, the CPU
210 receives the player selected price parameters from the player
interface 264.

[0119]Once the CPU 210 receives the player selected price parameters, the
CPU 210 reconfigures the slot machine 102. Specifically, the CPU 210
generates a signal, or a flag in memory, indicating that there is no need
to accept the coins between plays. CPU 210 further sets the pay
combination status field 650 in the payout table 228 according to the
jackpot structure entered by the player. In an alternate embodiment in
which the player selectable price parameters include the time between the
handle pulls, the CPU 210 sets an internal timer.

[0120]Furthermore, once the slot machine 102 CPU 210 receives the player
selected price parameters, it proceeds to access the calculation table
227. By accessing the calculation table 227, the CPU 210 retrieves the
flat rate price for the flat rate play session. Retrieving the flat rate
price is shown as step 1224. Once the CPU 210 retrieves the flat rate
price, it proceeds to transmit the price, the length of the flat rate
play session, and payment instructions to the video display area 238 for
player viewing in step 1226.

[0121]In step 1228, the player reads the data and instructions on the
video display area 238 and inserts money into the coin acceptor 248 or a
bill acceptor (not shown) in order to initiate play of the slot machine
102. In an alternate embodiment, the player enters a stored value card
such as a "smart card" into the card reader 266. Such a smart card has
the players credit balance stored thereon. Payment using a smart card
further entails the CPU 210 debiting the player's balance on the smart
card by the amount of the flat rate price. Further, the player may enter
a credit card into the card reader 266.

[0122]In step 1230, the CPU 210 generates a confirmed payment message
indicating that the player has deposited sufficient funds to cover the
flat rate price. Consequently, the CPU 210, in step 1232, sends the
current time to both the video display area 238 and the time audit field
518 of flat rate database 246. Next, in step 1234, the CPU 210 initiates
the countdown of the interval remaining in the flat rate play session as
stored in field 516. The length of the flat rate play session received
from the player is initially stored in field 516. The slot machine 102
decrements, or counts down, this value as the flat rate play session
begins.

[0123]As shown in step 1236, the flat rate play session continues in
accordance with the player selected price parameters, if such parameters
affect play, in step 1236. During such play, the CPU 210 stores and
updates the player's accumulated credits in RAM 218. In an alternate
embodiment, the slot machine pays out jackpots as they occur. Finally, in
step 1238, the CPU 210 terminates the flat rate play session when the
countdown ends.

[0124]In an alternate embodiment, the interval of the flat rate play
session is not a time period, but rather is a maximum number of plays. In
such an embodiment, the slot machine 102 stores the number of plays in
the flat rate database 246, as described previously in FIG. 9, and, in
step 916, increments a counter for each outcome generated. The counter
may be implemented in either software or hardware. Furthermore, in step
918, the slot machine 102 compares the number of plays stored in the flat
rate database 246 to the value of the counter. If the value of the
counter equals the stored number of plays, then the flat rate play
session is terminated.

[0125]Turning now to FIG. 13, the process of receiving a payout from the
present embodiment will be described. As shown as step 1310, the flat
rate play session ends upon the termination of the countdown.
Specifically, as shown in step 1312, the slot machine 102 CPU 210
terminates the flat rate play session by reconfiguring the slot machine
102 to its default values. For example, the CPU 210 resets the pay
combination status field 650 in the payout table 228 to reflect the
original jackpot structure. The CPU 210 also generates a signal
indicating that coins must be received for each play. In short, the
player selected price parameters are no longer in effect.

[0126]In step 1314, the CPU 210 checks the total credits accumulated, as
stored in the RAM 218, and transmits a payout command to the hopper
controller 240. Consequently, in step 1316, the slot machine 102 pays out
the total number of credits to the player.

[0127]An alternate embodiment of the present invention will now be
described with reference to FIG. 15. The operation of slot machine 100,
as indicated by steps 1510-1524 below, proceeds generally as described
with reference to FIG. 14. In this embodiment, the player selects from a
list of casino determined price packages, rather than choosing individual
price parameters. Each price package, as stored in the flat rate price
package database 229 described above, is a combination of different price
parameters which correspond to a flat rate play session price.

[0128]In step 1510, the player presses a "flat rate play" button on the
slot machine 100. The slot machine 102 CPU 210 receives flat rate play
signal from the player interface 264 in step 1512. In this case, the
player interface is an actual "flat rate play" button located on the
outside of the slot machine 100. Next, in step 1514, the CPU 210 access
flat rate price package database 229 from data storage device 224. The
CPU 210 then displays the player selectable price packages on video
display area 238 in step 1516. It is to be understood that the CPU 210
need not display the packages on the video display area 238, as those
package options could be displayed elsewhere on the body of the slot
machine 100. Alternatively, player interface 264 could incorporate
several "flat rate play" buttons, each representing a different flat rate
price package.

[0129]Next, in step 1518, the player selects the desired price package via
the player interface 264. Having already seen what the price of the
selected package is, the player then deposits the appropriate amount of
money into coin acceptor 248 in step 1520. For example, the player may
have chosen price package four which costs fifty dollars. In return for
fifty dollars deposited into the slot machine, the player receives two
hundred and fifty handle pulls, with three coins wagered per pull, and
with the top three jackpots active in his flat rate play session. These
parameters are specified in the flat rate price package database 229.

[0130]In step 1522, the CPU 210 receives an indication of payment from the
coin acceptor 248 and reconfigures the parameters of slot machine 100 to
meet the specifications of the flat rate price package selected by the
player. Finally, in step 1524, flat rate play begins.

[0131]It is noted that the flat rate price package database 229 could be
located at the slot network server 106 and not at each individual slot
machine 100. When it is located at the server, certain casino or operator
selected parameters could be used to determine the price. For example,
there could be different flat rate price packages for different times
during the day which are based on projected or actual casino traffic
and/or slot machine usage.

[0132]As will be appreciated by one of ordinary skill in the art, the key
step in getting players to wager money on gaming devices, such as slot
machines, is to bring the players to the casino floor. One way in which
casinos can bring additional players to the casino floor, and thereby
increase total revenues, is by giving away free samples or rewards with a
minimum displacement of traditional pay-per-play players. The present
invention may be employed for such a purpose.

[0133]In one embodiment, for example, the casino could declare a free-play
period. During the free-play period, likely chosen by the casino to
correspond to down time, when most gaming devices are idle, players
insert their player tracking cards into the gaming devices and initiate
play without being charged. Specifically, the casino programs the
calculation table 227 so that the flat rate price 724 is zero for a given
time of day 716 and day of the week 718. It is anticipated that during
such a free-play period, the casino will alter the jackpot structure,
causing only a selected jackpot to be active. Thus, the lure of free
jackpots will bring additional players to the casino floor who will
likely continue playing after the free-play period ends. A further
benefit of this embodiment is that it would encourage players to become
slot club members. This would result in an increase of players who return
to the casino and the customer base which the casino markets to through
mailings.

[0134]It is also to be understood that play of the slot machines during
the free-play period need not occur as described above. Thus, in an
alternate embodiment, the reels 232, 234, 236 of the slot machines 102
continuously spin, regardless of whether a player has inserted a tracking
card, with the server 106 periodically signaling a jackpot on a random
machine. Only when a player has inserted a player tracking card is the
jackpot awarded. The server 106 randomly selects a machine ID number and,
if the machine 102 is not being played by a pay-per-play player, the
server 106 transmits a signal to that slot machine 102 directing it to
produce a winning outcome.

[0135]In an alternate embodiment that achieves substantially the same
result of attracting additional players to the floor during down times,
the casino issues guests a player tracking card or a smart card having a
predetermined free credit balance associated therewith. The casino could
then restrict the day and time in which the players could use the free
card in a flat rate play session. In another embodiment, the cards
provided to guests contain an indication of time, rather than money, for
use during a flat rate play session.

[0136]Although the foregoing embodiments employ static jackpot structure,
which stay the same throughout the flat rate play session, it is within
the scope of the present invention to employ dynamic jackpot structures,
which change during the flat rate play session. In one such embodiment,
the dynamic jackpot structure starts with a given number of active
jackpots, as indicated in the pay combination status field 650 of the
payout table 228. As the flat rate play session progresses, the number of
active jackpots changes. Specifically, as the interval remaining in the
flat rate play session decreases, fewer pay combinations are made active.
In other words, the slot machine 102 CPU 210 monitors the time and, every
fifteen minutes, for example, causes the pay combination status field 650
to change from "active" to "inactive" for a given pay combination 610.
Alternatively, the CPU 210 changes the pay combination status field 650
after a predetermined number of plays. In a further variation of this
embodiment, individual jackpots may be decreased instead of or in
addition to being eliminated (e.g. the jackpot for a particular outcome
may decrease from 10 coins to 8 coins as the play session progresses).

[0137]As will be appreciated by those skilled in the art, a dynamic
jackpot structure based on the time progression of the flat rate play
session can increase the revenue generated by the slot machines 102.
Specifically, such a dynamic jackpot structure could be used with a flat
rate play session whose duration is not a fixed time, but rather a given
number of plays. Because fewer jackpots will be active as time
progresses, players have an incentive to use their fixed number of plays
within a short time period. Stated succinctly, the present invention
increases speed of play.

[0138]In another embodiment, the jackpot structure is dynamic based not on
the progression of the flat rate play session, but rather on the outcomes
generated by the slot machine 102. One such embodiment involves changing
a particular jackpot from "active" to "inactive" upon a player hitting
the outcome corresponding to that pay combination. For example, a player
may begin the flat rate play session with all jackpots active. On one
play, the slot machine 102 generates a "CHERRY-CHERRY-CHERRY" outcome
610. Upon accessing the payout table 228, the CPU 210 determines that ten
coins are to be paid out, credits the player's accumulated credits
accordingly, and causes the pay combination status field 650
corresponding to the "CHERRY-CHERRY-CHERRY" outcome 610 to change from
"active" to "inactive". Thus, a player can only hit a given jackpot once.
As will be appreciated by those skilled in the art, such a dynamic
jackpot structure will allow slot machine operators to further discount
the flat rate price to attract additional players. Furthermore, it is
anticipated that players will be willing to forego hitting the same
jackpot multiple times because their focus is typically on hitting the
highest jackpot once.

[0139]These and other dynamic jackpot structures may be implemented as
either a player selected price parameter or an operator selected price
parameter. When implemented as a player selected price parameter, the
dynamic jackpot structure is displayed to the player as a player
selectable price parameter option. The player, in turn, selects it via
the player interface 264. When implemented as an operator selected price
parameter, the dynamic jackpot structure is displayed for player viewing
prior to player approval of the flat rate price. Whether the price
parameters are selected by the player or the casino operator, the dynamic
jackpot structure affects the flat rate price generally as described
above, namely, as a field in the calculation table 227 or as a variable
in the price algorithm.

[0140]In some embodiments of the present invention, an individual may
purchase a flat rate play session as a gift for another person. For
example, an individual may purchase one of the available flat rate price
packages of FIG. 14. In such an embodiment the individual purchasing a
flat rate play session may be provided with a flat rate play session
identifier, which the purchase in turn provides to the gift recipient.
The flat rate play session identifier may be stored by the casino in
association with the price parameters defining the flat rate play
session. Thus, when the gift recipient inserts the flat rate play session
identifier into a gaming device, the gaming device may communicate with
the casino server to determine the parameters of the flat rate play
session and set itself to such parameters. A flat rate play session
identifier may be provided on, for example, a gift card that is
magnetically or optically encoded with the flat rate play session
identifier such that it may be read by a gaming device.

Contract Embodiment

[0141]In accordance with some embodiments of the present invention a flat
rate play session may be purchased by means of a contract. According to
such embodiments a player at a casino may purchase a contract (e.g. from
an insurer, such as the casino or another entity) or similar agreement to
use a gaming device, such as a slot machine. Costing a fixed amount, the
contract insures the player against the possibility of potentially large
losses at the slot machine. In accordance with one such embodiment, upon
purchasing the contract, a player credit account is set up at the slot
machine. The account may begin with zero credits but may begin with
another balance in other embodiments. The player is then allowed a fixed
number of handle pulls at the slot machine without requiring the player
to insert any money. Each handle pull decreases the player account,
typically by decreasing the player account by a predetermined amount
(e.g. one credit) for each handle pull. This may cause the number of
credits to be negative, but play may still continue. If the player
achieves a winning outcome, credits can be added to the player account in
accordance with the payout for the winning outcome. If, after the fixed
number of handle pulls, there are a positive number of credits in the
player account, then these may be paid out to the player in the form of
cash. If, however, there are less than a predetermined amount of credits
(e.g. zero credits) in the player account, then the player receives
nothing. The insurer, however, could compensate the casino for, e.g., an
amount in the player's account that is less than a predetermined number.

[0142]In such an embodiment, the player enjoys the fixed number of pulls
without the risk of any loss. The only loss for the player comes from the
cost of the contract.

[0143]One aspect of this invention is a way to price a contract for a
block of pulls to be sold to a player. Pricing a contract may involve
calculating the expected amount that would have to be paid a player upon
the completion of the pulls. The price of the contract would then
typically be greater than this expected amount so as to result in an
expected profit possibly to be divided amongst the casino and, if it is a
separate entity, an insurer. For example, if a player could be expected
to receive $30 upon the completion of 1000 pulls, then the contract for
the block of 1000 pulls could by sold for $35.

[0144]The following definitions define the terms used to describe the
contract embodiments of the present invention:

[0145]Contract indicator--an object or information by which a gaming
device may recognize a contract in order to execute the contract. For
example, a player purchases a contract at casino desk and receives a
token that serves as a contract indicator. When the player deposits the
token in a gaming device, the gaming device recognizes the contract the
player has signed up for and executes the contract accordingly.

[0146]Execute a contract--to carry out the terms of a contract. A gaming
device executes a contract for 200 pulls by generating the 200 outcomes,
incrementing and decrementing player credits in accordance with the
outcomes, and paying the player, if necessary, at the end of the
contract.

[0147]Gambling contract--An agreement between a player, an insurer, and
sometimes a casino (e.g. if different than the insurer) with the
following exemplary provisions: [0148]The player pays the insurer a
fixed amount up front. [0149]The player must make a predetermined number
of handle pulls, no more and no less. [0150]The player need not pay any
additional money after purchasing the contract. [0151]The player keeps
any net winnings after all handle pulls have been completed. [0152]If the
player has a net loss after the handle pulls have been completed, then
the loss is paid to the casino by the insurer.

[0153]There are many variants of these provisions, and additional
provisions are possible. As can be seen, the contract insures a player
against excessive losses, and may give the player more handle pulls than
would otherwise be possible for the price of the contract. Also, since
there may be no additional player decisions required after the player has
purchased the contract, the player need not be present for the execution
of the contract and may therefore experience the feeling of remote
gambling.

[0154]Gaming Device--Any electrical, mechanical, or electro-mechanical
device that accepts wagers, steps through a process to determine an
outcome, and pays winnings based on the outcome. The outcome may be
randomly generated, as with a slot machine; may be generated through a
combination of randomness and player skill, as with video poker; or may
be generated entirely through player skill. Gaming devices may include
slot machines, video poker machines, video blackjack machines, video
roulette machines, video keno machines, video bingo machines, and the
like.

[0155]Gross winnings--the total of a player's winnings during the
execution of a contract without regard to wagers made by the player. For
example, if, after five pulls of a contract, a player has attained one
winning outcome with a payout of 4 coins, and one winning outcome with a
payout of 20 coins, then the player's gross winnings thus far are 24
coins. Since gross winnings does not account for wagers a player makes,
gross winnings will always be larger than or equal to net winnings.

[0156]Handle pull--a single play at a gaming device, including video
poker, video blackjack, video roulette, video keno, video bingo, and
other devices. The definition is intended to be flexible in that a single
play might constitute a single complete game, or a single wager. For
example, in video blackjack, a player might play a single game in which
he splits a pair of sevens, requiring an additional wager. This one game
might thereby constitute either one or two handle pulls.

[0157]Net winnings--the total of a player's winnings during the execution
of a contract minus the amount spent by the player on wagers. In the
example cited under the definition of "gross winnings," the net winnings
are 19 coins since the player has won 24 coins but used one coin as a
wager on each of the five pulls.

[0158]Turning now to a detailed description of the contract embodiments of
the present invention, various aspects of such embodiments are set forth
below.

Description of the Contract

[0159]A typical contract is an agreement between the insurer and a player.
The player agrees to pay a fixed amount of money up front. In return, the
player may (or must) gamble at a gaming device for a designated amount of
time or for a designated number of outcomes. After the player has gambled
the requisite amount, the player has the right to keep any winnings that
exceed a certain threshold. The player does not, however, pay any losses.
Thus, one function of the contract is to insure the player against losses
at a gaming device. There are many variations of the contract and a
portion of these are described below.

[0160]Another function of the contract is to allow a player to play a
large number of handle pulls without the need of a large bankroll. For
example, a player wishing to make 600 pulls at a quarter slot machine
would ordinarily require $150 (25 cents×600) in order to assure
himself the ability of completing the 600 pulls. However, a contract
might allow a player to make 600 pulls by paying only $20.

[0161]In some embodiments, the contract does not involve an insurer. The
function of the contract may be to allow outcomes to be generated for the
player while the player is not physically present at the gaming device.
In these embodiments, the contract may consist mainly of instructions
from the player as to how the slot machine should gamble on the player's
behalf. For example, the instructions will tell the machine how fast to
gamble, when to quit, and then where to send winnings.

Amount of Play

[0162]A contract may place one or more of the following exemplary
restrictions on play covered by the contract: [0163]The player must
make a minimum number of handle pulls. [0164]The player may not make more
than a maximum number of handle pulls. [0165]The player must play for a
certain minimum time period. [0166]The player must play for less than a
certain maximum time period. [0167]The player must maintain a minimum
rate of play. [0168]The player may not exceed a maximum rate of play.
[0169]The total coin in over the course of the contract must exceed a
certain minimum amount. [0170]The total coin in over the course of the
contract must not exceed a certain amount. [0171]The player must play
until obtaining a specified outcome.

Coin Denomination

[0172]A contract may specify the size of the wager for each pull. The
wager size may be the same as that typically used by the gaming device.
For example, if a player signs up for a contract at a quarter slot
machine, the wager for each pull of the contract might be a quarter. If
the slot machine offers multiple coin bets, the wager for each pull might
be a quarter, 50 cents, 75 cents etc. The contract may allow or may force
the player to vary the wager from pull to pull.

[0173]One aspect of a contract may allow all play to occur in "credit
mode." That is, the player need not physically insert money into the
gaming device prior to each pull, and money needn't come out of the
gaming device after a player win. Rather, a player's credit balance may
be stored in a player database either in the gaming device or at the
casino server. Every time the player then makes a handle pull, credits
are deducted from the player's balance. Every time the player wins,
credits are added to the player's balance. The player's credit balance
can be displayed on the device so that the player may track his progress.

[0174]Since play may occur in credit mode, each wager might consist of
coin denominations that are not standard for the gaming device. For
example, a device that typically handles quarters may accept wagers of a
nickel, of 40 cents, or even of 12% cents.

Winnings Threshold

[0175]A contract may describe some threshold of gross winnings, net
winnings, or accumulated player credits above which the player keeps any
excess. Gross winnings describes the accumulated player wins from each
pull of the contract. Thus, a player who makes 600 pulls on a $1 slot
machine as part of a contract and wins $3 on each of 100 pulls has gross
winnings of $300 ($3/pull×100 pulls). Net winnings are the gross
winnings less the accumulated costs of wagering. In the above example,
the accumulated costs of wagering are $600 ($1/pull×600 pulls).
Thus, in the above example, the player's net winnings would be negative
$300 ($300-$600). Accumulated player credits may mirror a running tally
of a player's net winnings. For example, a player may begin with zero
credits, with credits deducted in the amount of any wager, and added in
the amount of any winnings. Accumulated player credits may also mirror a
running tally of gross winnings, or any other statistic about a player's
performance.

[0176]At the end of a contract, a player's accumulated credits may be
compared to a threshold. The player may then receive a payout of any
excess accumulated credits above the threshold. For example, if the
threshold is zero, and the player has 44 credits, each credit
representing 25 cents, then the player receives a payout of $11 (44
credits×25 cents/credit). If the player had -12 credits, indicating
a net loss of 12 credits, then the player receives nothing. The player
does not owe $3 because the contract does not make the player responsible
for any losses.

[0177]The threshold might be at 10 credits, in which case a player with
accumulated credits of 30 would receive a payout equivalent to 20 credits
at the end of a contract, and a player with 6 credits would receive
nothing. A threshold might be at -10 credits, in which case a player with
accumulated credits of -6 would receive the equivalent of 4 credits,
while a player with -100 credits would receive nothing.

[0178]Rather than insuring against all of a player's losses, a contract
might insure all losses up to a point and not beyond. Therefore, a
contract may have multiple thresholds, each with different functions. A
player may, for example, be responsible for any losses beyond a threshold
loss of 100 credits. The same player might receive any winnings beyond a
threshold of 10 accumulated credits. Thus, if, at the end of the
contract, the player has accumulated -125 credits, then the player must
pay 25 credits. If the player has accumulated 33 credits, then the player
receives a 23 credit payout. If the player has accumulated -49 credits,
then the player neither owes nor receives anything.

[0179]In some embodiments, a threshold delineates a change in the
percentage of a player's winnings or losses between credit tallies above
and below the threshold. For example, a player might keep any credits won
beyond a threshold of 50. Below 50 credits, the player only keeps 80% of
his winnings. Therefore, if a player has 70 credits remaining at the end
of a contract, he keeps all 20 credits above 50, and he keeps an
additional 40 credits, representing 80% of the first 50 credits.
Therefore, the player keeps 60 credits in total.

[0180]A player may also be responsible for a percentage of losses above or
below a certain threshold. For example, a player may be responsible for
50% of losses over 10 credits. Thus, a player who finishes a contract
with minus 20 credits owes nothing for the first 10 credits of loss, but
owes 5 credits for the next 10 credits of loss. The player therefore owes
5 credits.

[0181]In the most general sense, a contract specifies a functional
relationship between what a player's accumulated credits are at the end
of the contracted number of pulls, and what the player either owes or is
due. The function may be piece-wise linear, or may be rather non-linear
and convoluted.

[0182]Where there is potential for a player to owe money at the end of a
contract, the player may be required to deposit money into the gaming
device in advance so as to prevent the player from walking away when he
owes money. The advance payment may later be returned if the player turns
out to owe nothing at the end of the contract.

[0183]In many embodiments, a contract is transparent to the casino. In
other words, if the player makes a certain number of pulls, the casino
makes the same amount of money whether or not the player happened to be
involved in a contract. In these embodiments, however, a casino may
collect money that it makes (and the player has lost) from the insurer,
rather than from the player. The casino may also act as an intermediary
in transactions between the player and the insurer. For example, the
casino may collect from the player money that is meant to pay for a
contract. The casino may then transfer an equivalent amount of money to
the insurer.

[0184]In other embodiments, a contract is not completely transparent to
the casino. That is, the amount of money a casino receives after a
certain number of the player's handle pulls may depend on whether or not
the player was in a contract. In one example, a casino agrees that if a
player's accumulated credits at the end of a contract are less than -200,
then the casino will only collect 200 credits for the contract's handle
pulls. This example may benefit the insurer, since the insurer doesn't
have to worry about covering player losses in excess of 200 credits. In
another example, the casino configures a gaming device to give different
odds to a player in contract play versus a player not in contract play.

Player Decisions

[0185]As mentioned previously, players may have some restrictions on the
play covered by the contract. For example, a contract may cover an hour's
play at a gaming device, but require the player to make between 600 and
800 pulls in that hour. In some embodiments, however, contracts may allow
players to quit early or to play more than is otherwise covered by the
contract. For example, a contract might cover an hour's worth of play.
After the first half-hour, the player may be ahead by $100 and wish to
quit without risking the loss of the $100 in the subsequent half-hour. He
may therefore opt to pay $20 in order to be released from the obligation
of continuing the contract. He may then collect his $100 in winnings.

[0186]A player at a gaming device may reach the end of a contract with
accumulated credits just short of an amount necessary to collect
winnings. However, the last 17 out of 20 pulls may have been wins for the
player. The player may feel as if he has some momentum going for him and
therefore may not wish that the contract be finished. In some
embodiments, the player may extend the contract. For example, the gaming
device might prompt the player, saying, "For only $5 more, we'll give you
another 200 spins added to your contract." If the player accepts, then
the casino or insurer has made a new sale with potential profitability.
In some embodiments, the player may be allowed to extend a contract for
free, or may even be paid to extend the contract. For example, the player
may have winnings of $100 at the end of a contract. The casino, or
insurer, may figure that if the player were to keep pulling, he would be
likely to lose some of that $100. So the casino may pay the player $5 to
take another 200 pulls.

[0187]In a related embodiment, a player may carry over the accumulated
credits from a first contract to a second contract. Thus, a player with
40 accumulated credits at the end of a first contract may begin a second
contract with 40 accumulated credits. The player may pay or be paid for
carrying over credits.

Price

[0188]In many embodiments, the player pays a fixed sum to buy the
contract. In exchange for that fixed sum, the player can then gamble a
significant amount with little or no risk of losses. In many embodiments,
the insurer takes the risk of the player's loss. The insurer must
therefore price the contract so as to be compensated for the risk it
takes. In other embodiments, the casino and the insurer share the profits
and losses associated with a contract. To ensure a profit to be divided
amongst the two, a contract may be priced in excess of a player's average
win. Note that a player's loss would count as zero in figuring out the
player's average win, since the player does not have to pay for losses.

[0189]One method of pricing the contract involves first figuring out what
the insurer might expect to pay, on average, to cover a player's losses.
Another method of pricing a contract involves first figuring out what the
casino/insurer combination might expect to pay, on average, to compensate
a player for his winnings. Both methods involve similar computations.
Therefore, computations will be described below with respect to only one
or the other method of pricing a contract.

Exemplary Price Computations

[0190]The insurer obtains the gaming device or a component of the gaming
device containing significant information about the operation of the
gaming device (e.g. the CPU). The insurer then operates the gaming device
as a player would when under contract. For example, if the insurer is to
sell contracts for 600 pulls, the insurer would make 600 handle pulls at
the gaming device and record the number of accumulated credits at the end
of the 600 pulls. The insurer may repeat this process of testing
contracts at the device for a large number of trials. The insurer may
then average what its payments would be over all the trials. Note that
while it might take a player days or years to complete, say, 100,000
contracts at a gaming device; the process may be sped up for the insurer
by giving the gaming device special instructions to generate outcomes
more rapidly. The performance of large number of trials in the manner
described above is often called a Monte-Carlo simulation.

[0191]The following is an example of pricing a contract. Using the method
of pricing described above, an insurer simulates the execution of a
600-pull contract. The insurer repeats the simulation four more times.
After the first simulation, the player has won $10. After the second, the
player has lost $5. After the third, the player has lost $17. After the
fourth, the player has lost $8. After the fifth, the player has won $3.
To figure out what the insurer must pay, on average, the insurer adds the
three losses to get: $5+$17+$8=$30. The insurer then divides by five, the
number of simulations, to get: $30/5=$6. The insurer doesn't care, for
the purposes of this calculation, how much the player won when he did
win, since the casino is the one paying the player his winnings. Now, in
order to obtain an average $4 profit, the insurer might charge $10 for
each contract. [0192]1) The insurer obtains or creates software that
mirrors or models the operation of the gaming device. For example, the
software is configured to generate the same outcomes as does the gaming
device with the same frequency as the gaming device. For each outcome
generated, the software tracks what a player's accumulated credits would
be. As before, the insurer may simulate many contracts and average what
its payments would be over all the trials. [0193]2) The insurer
mathematically models potential outcomes of one handle pull of the gaming
device using a random variable with a probability mass function (PMF) or
probability density function (PDF). With these functions, the x-axis may
represent potential winnings, such as -$1 or $3, which can occur from a
single handle pull. The example of -$1 indicates the player has paid $1
for the pull but has won nothing. The example of $3 indicates that the
player has paid $1 for the pull and won $4. The y-axis of these functions
represents the probability or probability density of each outcome
occurring. The probability of the player getting -$1 on a pull might be
0.8, while the probability of the player getting $3 might be 0.2. A PMF
for the number of accumulated credits at the end of a contract can then
be created by summing the random variables representing individual handle
pulls. If each pull is independent with an identical PMF, as is common
with slot machines, then the PMF for the results of the entire contract
can be created using repeated convolutions of the PMF's for individual
handle pulls. If, for example, 600 pulls are involved, then the PMF for
single a handle pull may be convolved with itself 599 times to generate a
PMF for the entire contract. Using this resultant PMF, the insurer can
easily calculate how much it would expect to pay to cover a player's
losses on each contract. If the resultant random variable is denoted by
w, and the insurer would by required to pay for any player losses, then
the insurer's expected payment is given by Σ-.sub.∞0
w*probability(w). [0194]3) In the method described above, Fourier
Transforms, Z transforms, Laplace Transforms, or other transforms can be
used to aid in the calculation of the repeated convolutions. Such a use
of transforms is well known in the art. [0195]4) As is well known in the
art, with many classes of random variables, repeated summation results in
a Gaussian probability distribution. This distribution has the shape of
the familiar bell curve. The Gaussian distribution has the advantage of
being fully described by only two parameters, a mean and a standard
deviation. If a Gaussian probability distribution is used to approximate
the sum of a large number of independent, identically distributed random
variables, such as those that often describe handle pulls, then the mean
and standard deviation of the Gaussian distribution is very easily
calculated based on the mean and standard deviation of a random variable
describing an individual pull. Such calculations are well known in the
art. Thus, a Gaussian distribution can easily be generated to approximate
the PMF of a player's accumulated credits at the end of a contract. Using
this distribution, the insurer can calculate the amount it would be
required to pay, on average, to cover a player's losses. The method of
calculation is similar to that described in 3). If a Gaussian PDF is used
as an approximation, then an integral sign replaces the summation sign,
and "probability" is replaced by "probability density."

[0196]The following is an example of using a Gaussian probability density
function to approximate the amount a casino would be required to pay, on
average to, to compensate a player for his winnings at the end of a
contract. The contract may then be priced in excess of this amount to
ensure an average profit for the casino/insurer combination. A Gaussian
function is given by the formula, f(x)=1/
(2πσ)exp(-(x-μ)2/(2σ2)). In this formula,
σ is the standard deviation, and μ is the mean. Now, let us
suppose that a single handle pull of a slot machine results in a required
payout to the player described by a probability mass function with mean
μ0 and standard deviation σ0. Then, assuming each
handle pull is independent, n handle pulls of the slot machine may be
described by a function with mean μ=μ0n and standard deviation
σ=σ0 n. Furthermore, if n is large, then the function
describing a casino's aggregate payout after n handle pulls may be
approximated by the Gaussian function f(x), whose formula is given above.

[0197]To calculate what a casino would have to pay to compensate a player
for his winnings, on average, we note that the casino pays when the
player wins, but receives nothing when a player loses. Therefore, the
expected payment of the casino is given by:

[0202]If we were to graph the above as a function of n, the number of
pulls, we would see that initially, as the number of pulls in a contract
gets larger, a casino could expect to pay more money to compensate a
player for his winnings. However, there would reach a point, beyond which
more pulls in a contract would actually decrease the amount a casino
could expect to pay to compensate a player for his winnings. This
illustrates an important feature of contracts. Having more pulls in a
contract is not necessarily an advantage for a player. [0203]5) A casino
or insurer may start with a first price for a contract, and then evolve
the price as more and more of the contracts are purchased and executed.
For example, if an insurer loses money on the first few contracts it
sells, then it may increase the price of the contract. If the insurer
makes large profits on its first few contracts, then it may reduce the
price.

[0204]Once the insurer has determined what it can expect to pay, on
average, to cover a player's losses, the insurer may price the contract
so as to give itself a desired profit margin. For example, if the insurer
can expect to pay, on average, $15 to cover a player's losses, then the
insurer might price the contract at $20 to insure itself a $5 average
profit.

Automatic Play

[0205]A contract may require certain behaviors of the player. As
mentioned, these behaviors may include maintaining a certain rate of
play, or performing a minimum number of handle pulls. The gaming device
on which a contract is executed may take various steps to ensure that the
behaviors are performed. To this end, the gaming device may initiate
handle pulls automatically or may fail to register handle pulls that the
player attempts to initiate. For example, if the player must make at
least one handle pull every 10 seconds, and the player has failed to make
any handle pulls in 9 seconds, then the gaming device may automatically
initiate a handle pull for the player on the tenth second. As another
example, a player may be restricted from making more than one pull every
10 seconds. If in the same 10-second interval, the player attempts to
make more than one handle pull, the second handle pull may not be
initiated, at least until the next 10-second interval.

[0206]As can be seen from the above two examples, the player may maintain
some control over his gambling behavior even while the gaming device
forces him to comply with the contract. So a player who must make a pull
every 10 seconds still has control over whether the pull occurs on the
first second of an interval or the eighth second of an interval. Such
control can be psychologically important, because many players feel that
the exact moment at which the handle pull is initiated has an important
effect on the ultimate outcome.

[0207]In some cases, a player may not desire to make any active decisions
once a contract has been initiated and may simply put a gaming device
into "automatic play." The player may later have the option of taking the
gaming device out of automatic play and of manually initiating handle
pulls.

Offering the Contract

[0208]A contract may be offered to a player in a number of ways. A gaming
device may use text or synthesized voice to ask a person whether or not
he would like to sign up for a contract. A casino attendant may offer a
contract to a player, or signs at a casino may point a player towards a
casino desk where he may then purchase a contract.

[0209]A number of circumstances may trigger the casino or an insurer to
offer a contract to the player. For example, the player may have lost
most of an initial stake deposited into a gaming device. A player may be
slowing his play, or may no longer be inserting coins into the machine.
The time of day may be a player's typical lunch time or departure time. A
player may have the opportunity to enter into a contract only if he also
agrees to do business with a particular merchant or group of merchants.
The player may have the opportunity to enter into a contract if the
casino or insurer deems him a good, valuable, or loyal customer.

Agreeing to the Contract

[0210]A player may specify a desired contract in a number of ways. At a
gaming device, a player may use a touch screen to indicate his desire to
enter into a specific contract. Using the touch screen, the player may
select from a menu of possible contracts. For example, the menu might
list several contracts with different time durations or different prices.
The player could then select a contract by touching an area of the screen
next to his desired contract.

[0211]The player might use menus to customize a contract for himself. The
player might use a first menu to select a duration of the contract (e.g.
600 pulls, or 1/2 hour). A second menu might be used to select a rate of
play. A third menu might be used for coin denomination. Many other menus
are possible for other contract features. Once the player has selected
several contract features, the gaming device may select the remaining
feature so as to make the contract profitable for the insurer. For
example, once the player has chosen a number of pulls and a coin
denomination, the gaming device might choose the price of the contract.

[0212]Rather than a touch screen, a player may use special buttons, keys,
or voice input to specify a desired contract or contract terms.

[0213]In some embodiments, a player chooses a contract prior to
approaching the gaming device or even the casino. A player might select a
contract on the Internet. On the Internet, the player might specify terms
of the contract, such as the number of pulls, the rate of play, the cost,
the payout tables, the winning symbol combinations, etc. The player may
then print out a code or a document describing the terms of the contract.
The player then brings the code or document to a gaming device that then
recognizes what contract the player has chosen. When the player signs up
for a contract, a description of the contract might be sent
electronically directly to the gaming device. The player might then only
identify himself at the gaming device in order to initiate contract play.

[0214]Other terms of a contract a player may agree to or specify include:
the font size of the machine, the noise level of the machine's sound
effects, the particular game (e.g. number of reels, number of pay lines),
the brightness of the display, etc.

Signature

[0215]To confirm entry into a contract, a player might sign a document
that may contain the terms of the contract. The document may be printed
from a gaming device or from the Internet, or may be obtained from a
counter at a casino. The signed document may then be deposited into an
opening in the gaming device, may be returned to a casino counter, or may
be kept by the player. The player might also sign an area on a touch
screen or other sensing device.

[0216]A player might also confirm entry into a contract simply by paying
for it. The player might pay be depositing tokens, coins or other
currency into the gaming device. The player might pay using a credit or
debit card. The player might also pay from a player credit account
established with the casino. The player might pay at a counter of the
casino and might receive a contract or a contract indicator to bring to a
gaming device. The gaming device might then recognize the contract
indicator by, for example, a bar code, and then execute the contract.

Instruction Sets

[0217]A typical contract may cover and/or require a large number of handle
pulls by the player. Now ordinarily, when a player is gambling at a
gaming device for a long period of time, the player makes a number of
decisions related to his gambling. Should the player play more quickly or
more slowly? Should the player double his bet after a loss? Should the
player quit after a sizable win? Should the player take a short break to
use the restroom?

[0218]Since the contract covers a large number of pulls, it is possible
for the some player decisions to be made beforehand and included in the
contract. A gaming device may then act on the decisions specified in the
contract without further input from the player. For example, while
negotiating a contract for an hour of play at 10 pulls per minute, a
player might decide he'd like a 15 minute break between the first 1/2
hour and the second 1/2 hour of pulls. The gaming device might then
execute the contract for the first half hour by automatically spinning
and generating outcomes for the first 1/2 hour. The gaming device might
then freeze for 15 minutes, preventing other players from stepping in and
allowing the contract holding player to take his 15 minute break. The
device can then unlock after 15 minutes, perhaps with the entry of a
password, and resume the generation of outcomes.

[0219]One important aspect of having a player's decisions spelled out
before hand in the contract is that the player need not even be present
at the gaming device. A player can sign up for a contract at a casino in
Las Vegas, and then have the contract executed automatically by a gaming
device. The player can then view a running tally of his accumulated
credits over the Internet while in Virginia, for example.

[0220]In general, player instructions built into a contract will include
some action to be performed as well as some triggering condition for the
action. As an example, a player instruction may be to increase the rate
of handle pulls provided accumulated player credits exceed 100. In this
example, the action is to increase the rate of handle pulls, and the
triggering condition is whether accumulated player credits exceed 100.
The following player actions may be part of a player's instructions:
[0221]Increase or decrease a wager amount on one or more handle pulls.
[0222]Increase or decrease a rate of wagering. [0223]Cease gambling.
[0224]Change the way outcomes are displayed.

[0225]The following conditions may trigger the above actions [0226]The
player has just won or lost on one or more handle pulls. [0227]The player
has just won a certain amount on one or more handle pulls. [0228]Any
player defined sequence of wins and losses has occurred on prior handle
pulls. [0229]The player has approached or left the vicinity of the gaming
device. [0230]The current time has reached a particular time of day.

[0231]One advantage of contracts executed by the gaming device is that a
gaming device can gamble at speeds a human is incapable of achieving. For
example a player is on a winning streak, but must soon join his family
for lunch. Rather than cash out and leave, he decides to accelerate his
play to 2 pulls per second. He therefore enters a into a contract which
is to be executed by the machine at 2 pulls per second for the next 8
minutes. In this contract, an insurer is not involved. The contract
simply serves as a means of increasing the rate of play. As it happens,
the player loses all his money in 6 minutes, and so the contract ends.

[0232]Player instructions may tell the slot machine to play faster when
the player is present or is observing in some way, and to play more
slowly while the player is asleep. For example, the rate of pulls may be
twice as fast during the day as at night. The rate of play may likewise
be faster when an infrared detector in the slot machine senses the heat
of the player's presence.

[0233]Player instructions may also tell a gaming device how to play
certain games involving player decisions. For example, a player may leave
instructions to use basic strategy in a game of video blackjack, or to
play according to published theory in a game of video poker. The player
may add instructions to always draw to a four card open-ended straight
flush.

Times of Execution

[0234]A contract may be executed over a range of different time periods.
The outcomes, the accumulated player credits, and the player winnings may
or may not be displayed to the player at the same time at which the
outcomes are being generated.

[0235]In one embodiment, all the outcomes needed for a contract are
generated very rapidly by a gaming device, perhaps all in less than a
second. The outcomes may then be displayed to the player over a much
longer time frame so as to give the player a more exciting gaming
experience.

[0236]In another embodiment, outcomes may be continuously generated at a
rate comparable to that with which a player might make handle pulls on
his own. This embodiment might be entertaining for a player if the player
is sitting at the gaming device or watching the outcomes being generated
from a home computer.

[0237]In another embodiment, outcomes are generated on a periodic basis at
fixed times every day, week, hour, etc. For example, outcomes for a
600-pull contract may be generated 100 outcomes at a time, each block
being generated from 8 pm-9 pm on Sunday. Thus, it would take just under
six weeks for the entire contract to be executed. This method of
execution may be ideal if a player has a schedule as to when he enjoys
watching outcomes being generated. For example, the player might enjoy
seeing outcomes generated while he watches his favorite show on Sundays
from 8 pm to 9 pm. This method of execution might also be ideal for the
casino if slow business periods occur on a periodic basis where the
entire contract cannot be executed in a single period.

[0238]In still another embodiment, outcomes are generated on a flexible
basis, either when it is convenient for the casino or for the player. In
this embodiment, the casino may wait for a gaming device to be free of
use before using it to generate the next couple of outcomes of a
contract. Alternatively, the player may signal the gaming device any time
he is ready to have the next few outcomes generated

Viewing the Contract's Execution

[0239]As discussed, a player may enjoy watching from a remote location as
the outcomes of his contracts are generated. Since the player is not
physically at the slot machine, the outcomes must be presented to the
player via some graphical representation. In one embodiment, a camera
simply films the gaming device generating the player's outcomes. The
image from the camera is transmitted to the player device via the
Internet, the cable system, satellite, etc. The player device might be,
for example, a TV or a personal computer. In another embodiment, the
generated outcomes are recorded either by the gaming device, by a camera
watching the device, or by a casino employee. The generation of the
outcomes is then graphically recreated for the player in a manner not
necessarily consistent with the physical appearance of the gaming device
that generated the outcomes. For example, a gaming device generates the
outcome: cherry-orange-lemon. The gaming device then transmits, via the
casino server and the Internet, a bit sequence indicating the outcomes
cherry-orange-lemon. Perhaps the bits "0000" represent cherry, "0011"
represent orange, and "1111" represent lemon. The bit sequence is
transmitted to a player's home computer, where a software program
displays a cartoon representation of a slot machine. The cartoon shows
the reels spinning and stopping with the outcome: cherry-orange-lemon.
The cartoon representation of the slot machine may not look anything like
the slot machine that originally generated the outcomes. In some
embodiments, a player views a combination of the actual image of his
gaming device, and a computer-rendered version of a gaming device. For
example, a cartoon of the reels spinning might be displayed within the
frame of an actual image of the slot machine, without the reels.

[0240]In some embodiments, the player does not view a graphical
representation of the outcomes, but sees the outcomes as text, such as
"seven-bar-bar," "s-b-b," "7-b-b," etc. The player may not even see the
outcomes, just how much he has won or lost on every pull. Thus, the
player may view a periodically updated tally of his accumulated credits.
He may only view his total accumulated credits, or his take home
winnings, after all outcomes have been generated.

[0241]Any graphical or textual representation of the player's outcomes,
accumulated credits, or other contract information may be displayed
either on an entire portion of a computer or TV screen, or on a smaller
portion of the screen. For example, a small cartoon slot machine may
reside in a box in the upper right hand corner of a TV screen that
simultaneously displays a regular TV show. A player watching television
need then only glance up at the corner of his screen to follow the
progress of his contract. Representation of outcomes may also be place in
an email message to the player.

[0242]Of course, the various representations of outcomes may be used just
as well with a player physically present at the gaming device or at the
casino.

[0243]In some embodiments, the player calls up a number to monitor the
progress of his contract. He may enter a code or password when prompted
by a voice response unit (VRU) and thereby access the outcomes from his
particular contract.

[0244]A player may be sent updates on his contract only when certain
triggering conditions are met. For example, a player may only wish for
updates when he wins more than 100 credits on a spin, or when the
contract terminates.

Revenue Management

[0245]As discussed previously, the pricing of a contract will often take
into account the expected amount an insurer must pay to a casino to cover
a player's losses, or the expected amount that a casino and insurer in
combination can expect to pay to compensate the player for his winnings.
Pricing of contracts may account for additional factors such as, for
example: [0246]Times or dates on which the contract is to be executed.
[0247]The gaming device on which the contract is to be executed
[0248]Flexibility in the contract's execution. [0249]A player's playing
history. [0250]The importance of the player as a customer of the casino.

[0251]For example, a contract which is to be executed during a period of
low customer activity at a casino may be priced at a discount. This is
because a casino would like to encourage the use of gaming devices that
are otherwise empty. Alternatively, a casino may want to discourage the
purchase of contracts during times of high customer traffic, and so
contracts may be higher priced at such times.

[0252]If a contract has flexibility as to when it may be executed, then
this allows the casino to execute contracts only during times when gaming
devices would not otherwise be in use. Therefore, such a contract might
be priced more favorably.

[0253]A contract that is executed at an unpopular gaming device, for
example, might be priced more favorably for the player so as to encourage
the use of that device.

[0254]If a player shows signs of nearing the end of his gambling session,
a contract might be priced at a discount for that player. For example, a
player might be slowing his rate of play, indicating boredom. A player
might be lowering his wager size, indicating a decreasing bankroll. A
player might simply have been at a gaming device for such a long time
that he would almost necessarily be hungry enough to leave at any moment.
Providing a discount on a contract to such players would encourage them
to remain gambling for at least the time it takes to execute the
contract.

Settlement

[0255]In some embodiments, the casino acts as the intermediary in
transactions between a player and the insurer. The casino is an
intermediary, for example, when its gaming devices collect a player's
payment for a contract, even though that payment is meant to go to the
insurer. The casino is also an intermediary when it does not collect
losses from a player, but from an insurer.

[0256]Since the casino may engage in many transactions with the insurer,
it would potentially be inefficient for the casino to transfer money to
the insurer, or vice versa, after every transaction. Therefore, the
casino or the insurer may maintain records of how much one owes the
other. The casino and the insurer may then settle their accounts
periodically. If the casino owes the insurer money, then the casino may
wire money to the insurer. If the insurer owes the casino, then the
insurer may wire money. Of course, many other methods of settlement are
possible.

[0257]In cases where a contract has resulted in a net win for the player,
the player must be paid. If the player is at the casino, he may enter
into a gaming device a password or other identifier of himself or of his
contract. The gaming device may then access a database in the casino
server containing the details of the contract, including the amount owed
to the player. The gaming device may then payout the amount owed in the
form of cash, tokens, paper receipts or vouchers, digital cash, digital
receipts, etc. The player may also collect his winnings at a casino desk,
perhaps after presenting identification.

[0258]If a player is remote from a casino when his contract has finished
executing, then the player may be sent his winnings either by the insurer
or the casino. If the insurer provides the winnings, then the casino may
later reimburse the insurer in the amount of the winnings. The winnings
may be sent in the form of cash, check, money order, etc. The winnings
may be sent by postal mail, by wire transfer, by direct deposit, by email
as digital cash, etc.

[0259]In some embodiments, the casino may simply keep the player's
winnings in a player account at a casino, to be accessed by the player
next time he visits the casino. The winnings may, in the mean time,
accumulate interest. The casino (or insurer) may also alert the player
that his contract has finished executing and that he has winnings. The
player may be instructed to come to the casino and pick them up.

[0260]In some embodiments, the player may have left instructions to take
any winnings from a first contract and purchase a second contract. This
allows for the notion of a meta-contract. Just as a contract may specify
how to allocate money for pulls, a meta-contract would describe how to
allocate money for contracts. There could then be meta-meta-contracts,
and so on.

[0261]Numerous variations on the above-described contract embodiments of
the present invention may be practiced without departing from the spirit
and scope of the present invention. For example, a player may be halfway
through a contract and have negative 200 accumulated credits. The player
might therefore lose all hope of winning enough to overcome the
200-credit deficit, and so lose interest in the contract. Therefore, in
one embodiment, a player who is well below a threshold number of
accumulated credits for winning may play for an altered pay table. Low
paying outcomes may be eliminated, while the likelihood of achieving high
paying outcomes may increase. This is because a player with a 200-credit
deficit probably doesn't care about a win of ten credits, but does care
about a win of 500 credits. The overall hold percentage of the machine
may remain constant. In some embodiments, the alteration of the pay
tables is an automatic function of the number of pulls remaining and the
credit deficit of the player. In other embodiments, the player must
request an alteration of the pay tables. As an example, a player may
select an option that says, "Let me play just for the jackpot. Eliminate
everything else and make the jackpot more likely." The player may or may
not have to pay for an alteration of the pay tables. In a more general
sense, the pay tables may change such that the standard deviation of the
payout for a particular handle pull changes even as hold percentage may
remain constant.

[0262]In another embodiment, a player might purchase a contract at a
casino desk and receive a token that indicates the type of contract. The
player might then deposit the token into a gaming device. The gaming
device would then recognize the token and be able to execute the
contract.

[0263]A player may have the privilege of entering into favorable contracts
after a fixed amount of initial betting. For example, if the player
wagers for an hour, he may be able to enter into a contract where each
pull is at true odds. That is each pull pays back, on average, the same
amount that was put in. Typically the pull pays back less. In yet another
embodiment, a player may receive better odds on contract play when he is
recommended to the casino by a friend.

[0264]In some embodiments, certain results of a pull may terminate a
contract early. For example, if a player hits the jackpot, the contract
may terminate. In other embodiments a player's accumulated credits can be
displayed to a player as a function of time in the form of a graph. The
graph may look much like graphs used to plot the price of a stock market
index as a function of time. In some embodiments, a player wins money or
some other prize if the graph takes on a certain shape. For example, if
the line of the graph is such that it slips between several sets of
markers (much like a skier on a slalom course), then the player may win a
large prize.

[0265]In some embodiments, a player's winnings on each pull of the
contract are reinvested into the contract, whereas in other embodiments
they are not. In one example, a player purchases a contract for $100. The
player instructs the gaming device to gamble the $100 until it is all
gone. However, any winnings are not to be used to gamble, they are to be
sent directly to the player. In a second example, the player purchases a
contract for $100 and instructs the gaming device to gamble the $100
until it is gone or until it has become $200. Here, the player elects to
reinvest winnings, using the winnings to pay for new handle pulls even
after $100 worth of handle pulls has been made already.

[0266]A contract may reward a player based on any second order data, or
meta-data about one or more outcomes. Examples include rewarding the
player if three like outcomes occur in a row, if 20 cherries come up in
10 sequential spins, if the players accumulated credits ever reach 100,
etc. An example previously mentioned is rewarding a player based on the
pattern of a graph of accumulated winnings as a function of time. A
player might choose the "meta-outcomes" on which he desires to be
rewarded, and the gaming device may figure the corresponding odds and the
size of the reward should the meta-outcome occur.

[0267]A player may be rewarded with the downside of a sequence of outcomes
much as buying insurance gives him the upside. For example, a player pays
a fixed sum of money, and collects winnings for every dollar in the
negative the contract finishes at. Thus, if a contract ends with the
player having minus 20 accumulated credits, then the player collects 20
credits.

[0268]A contract may apply to a "best 100" sequence of a larger sequence
of pulls. For example, the player pays $100 for a contract of 1000 pulls.
From those 1000 pulls, the player gets to choose any 100 consecutive
outcomes to determine his winnings, and can disregard the rest of the
outcomes. Thus the player can say he wants to use outcomes 506 through
605. Perhaps there was a hot streak during that sequence. The player's
winnings are then determined solely based on what happened between pulls
506 and 605. This might result in winnings of $200, whereas having
counted all 1000 pulls would have resulted in a net loss for the player.
Of course, the gaming device may automatically choose the most favorable
sequence for the player.

[0269]A player may choose his favorite outcome and receive higher payouts
for that outcome, special privileges for receiving that outcome (e.g. the
ability to terminate a contract), etc.

[0270]Returning now to the figures, FIG. 16 is a schematic representation
of an embodiment of a system configured to carry out the contract
embodiments described above. The system 1600 comprises a casino server
1605 in communication with insurer device 1610, a gaming device 1615, and
a player device 1620. As used herein, a device (including the casino
server 1605, the insurer device 1610, the gaming device 1615 and/or the
player device 1620) may communicate, for example, through a communication
network such as a Local Area Network (LAN), a Wide Area Network (WAN), a
Metropolitan Area Network (MAN), a Public Switched Telephone Network
(PSTN), a proprietary network, a Wireless Access Protocol (WAP) network,
or an Internet Protocol (IP) network such as the Internet, an intranet or
an extranet. Moreover, as used herein, a communication network includes
those enabled by wired or wireless technology.

[0271]It should be understood that any number of gaming devices and any
number of player devices can be used in system 1600. Although system 1600
includes both a casino server 1605 and an insurer device 1610 as
illustrated, one or the other of these elements may be omitted (for
example, the insurer device may be omitted in embodiments that do not
include an insurer or where the casino acts as the insurer). Similarly,
although system 1600 includes both a gaming device 1615 and a player
device 1620 as illustrated, one or more of these embodiments may be
omitted (for example, the player device may be omitted if the casino has
not implemented remote gaming). Further, some or all of the functionality
of a casino server 1605 may be carried out by insurer device 1610 and
vice versa. Similarly, some or all of the functionality of casino server
1605 and/or insurer device 1610 may be carried out by gaming device 1615
and vice versa. In one embodiment, the casino server 1605 comprises one
or more computers that are connected to a remote database server.

[0272]Turning now to FIG. 17, therein depicted is schematic illustration
of a casino server 1605. Casino server 1605 is an illustration of an
embodiment of the casino server of the same number in FIG. 16. Casino
server 1605 comprises a processor 1705 in communication with a
communications port 1710 and storage device 1715. Contained in storage
device 1715 is a program 1720, a player database 1725, a gaming device
database 1725, and a contracts database 1730. Each of these databases
will be described in detail below. The processor 1705 performs
instructions of the program 1720, and thereby operates in accordance with
the present invention. The program 1720 may be stored in a compressed,
uncompiled and/or encrypted format. The program 1720 furthermore includes
program elements that may be necessary, such as an operating system, a
database management system, and "device drivers" used by the processor
210 to interface with peripheral devices. Appropriate program elements
are known to those skilled in the art.

[0273]Note that the processor 1705 and the storage device 1715 may be, for
example, located entirely within a single computer or other computing
device or located in separate devices coupled through a communication
channel.

[0274]Turning now to FIG. 18, therein depicted is a schematic illustration
of an insurer device 1610. Insurer device 1610 is an illustration of an
embodiment of the insurer device 1610 of the same number in FIG. 16.
Insurer device comprises a processor 1805 in communication with a
communications port 1810 and a storage device 1815. Storage device 1815
stores a program 1820. The processor 1805 performs instructions of the
program 1820, and thereby operates in accordance with the present
invention. The program 1820 may be stored in a compressed, uncompiled
and/or encrypted format. The program 1820 furthermore includes program
elements that may be necessary, such as an operating system, a database
management system, and "device drivers" used by the processor 1805 to
interface with peripheral devices. Appropriate program elements are known
to those skilled in the art. Note that the processor 1805 and the storage
device 1815 may be, for example, located entirely within a single
computer or other computing device or located in separate devices coupled
through a communication channel.

[0275]Turning now to FIG. 19, therein depicted is a schematic illustration
of a gaming device 1615. Gaming device 1615 is an illustration of an
embodiment of the gaming device of the same number depicted in FIG. 16.
Gaming device 1615 comprises a processor 1905 in communication with a
communications port 1910, an input device 1915, an output device 1920,
and a storage device 1925. Storage device 1925 stores a program 1930. The
processor 1905 performs instructions of the program 1930, and thereby
operates in accordance with the present invention. The program 1930 may
be stored in a compressed, uncompiled and/or encrypted format. The
program 1930 furthermore includes program elements that may be necessary,
such as an operating system, a database management system, and "device
drivers" used by the processor 1905 to interface with peripheral devices.
Appropriate program elements are known to those skilled in the art.

[0276]Note that the processor 1905 and the storage device 1925 may be, for
example, located entirely within a single computer or other computing
device or located in separate devices coupled through a communication
channel.

[0277]Input device 1915 may comprise, for example, a player slot card
interface, a keypad, a touch-screen, a microphone and/or any other device
which allows a player to input information into gaming device 1615.
Output device 1920 may comprise, for example, a display area, a
microphone, and/or any other device that allows gaming device 1615 to
output information to a player. Gaming device 1615 may comprise, for
example, a slot machine, video poker machine, video keno machine, or a
video blackjack machine. A combination of these type of machines may be
used in embodiments where casino server 1605 is in communication with
more than one gaming device 1615.

[0278]Turning now to FIG. 20, therein depicted is a schematic illustration
of a player device 1620. Player device 1620 is an illustration of an
embodiment of the player device of the same number depicted in FIG. 16.
Player device 1620 may be, for example, a personal computer (PC), laptop,
personal digital assistant, a cellular telephone, a pager, and/or any
other device that allows a player to remotely monitor and participate in
play of a gaming device in accordance with the present invention. Player
device 1620 comprises a processor 2005 in communication with a
communications port 2010 and a storage device 2015. Storage device 2015
stores a program 2020. The processor 2005 performs instructions of the
program 2020, and thereby operates in accordance with the present
invention. The program 2020 may be stored in a compressed, uncompiled
and/or encrypted format. The program 2020 furthermore includes program
elements that may be necessary, such as an operating system, a database
management system, and "device drivers" used by the processor 2005 to
interface with peripheral devices. Appropriate program elements are known
to those skilled in the art. Note that the processor 2005 and the storage
device 2015 may be, for example, located entirely within a single
computer or other computing device or located in separate devices coupled
through a communication channel.

[0279]It should be noted that any and all of the processors 1705, 1805,
1905, and 2005 may comprise one or more microprocessors such as one or
more INTEL® Pentium® processors. Further, any and all of the
storage devices 1720, 1815, 1925, and 2015 may comprise any appropriate
storage device, including combinations of magnetic storage devices (e.g.,
magnetic tape and hard disk drives), optical storage devices and
semiconductor memory devices, such as Random Access Memory (RAM) devices
and Read Only Memory (ROM) devices.

[0280]Examples of databases that may be used in connection with the system
1600 will now be described in detail with respect to FIGS. 21 through 23.
Each figure depicts a database in which the data is organized according
to a data structure in accordance with embodiments of the present
invention. The data may be stored, for example, on a computer readable
medium and be accessible by a program executed on a data processing
system. The schematic illustrations and accompanying descriptions of the
databases presented herein are exemplary, and any number of other
database arrangements could be employed besides those suggested by the
figures.

Player Database

[0281]Referring to FIG. 21, a table represents one embodiment of the
player database 1720 that may be stored at the casino server 1605 shown
in FIG. 16 according to an embodiment of the present invention. The table
includes entries identifying players that may be participating in
contracts for flat rate play sessions with system 1600. The table also
defines fields 2105, 2110, 2115, 2120, 2125, 2130, and 2135 for each of
the entries. The fields specify (i) a player identifier 2105 that
uniquely identifies a player; (ii) a name 2110 associated with the
player; (iii) an address 2115 that facilitates communications with the
player; (iv) a financial account identifier 2120, such as a credit or
debit card account, associated with the player through which payment may
be obtained and to which player winnings may be credited; (v) demographic
information 2125 that may be utilized to determine a price or other terms
for a contract; (vi) credits 2130 that represent the amount of casino
credits associated with the player; and (vii) a lifetime coin in 2135
that represents the amount of coin in wagered by the player over the
course of his or her relationship with the casino and/or insurer.

Gaming Device Database

[0282]Referring to FIG. 22, a table represents one embodiment of the
gaming device database 1725 that may be stored at the casino server 1605
shown in FIG. 16 according to an embodiment of the present invention. The
table includes entries identifying gaming devices operated by the casino.
The table also defines fields 2205, 2210, and 2215 for each of the
entries. The fields specify a (i) a gaming device identifier 2205 that
identifies a gaming device; (ii) a name 2210 associated with the gaming
devices, such as, for example, Diamond Mine®; and (iii) a
manufacturer 2215 of the gaming device.

Contract Database

[0283]Referring to FIG. 23, a table represents one embodiment of the
contract database 1730 that may be stored at the casino server 1605 shown
in FIG. 16 according to an embodiment of the present invention. The table
includes entries identifying contracts that may or have been purchased
via the system 1600. The table also defines fields 2305, 2310, 2315,
2320, 2325, 2330, 2335, 2340, and 2345 for each of the entries. The
fields specify (i) a contract identifier 2305 that identifies a contract
that has been purchased or is available for purchase by a player; (ii) a
player identifier 2310 that identifies a player, if any, that may be
associated with the contract; (iii) an initial bankroll 2315; (iv) a
description 2320 that describes the terms of the contract; (v) a cost
2325 of the contract; (vi) a result 2330 that indicates the current
status of the contract; (vii) an amount owed the player 2335; (viii) an
amount owed the insurer 2340; and (ix) a total amount owed the insurer
2345.

[0284]A method that may be used in connection with the system 1600
according to an embodiment of the present invention will now be described
in detail with respect to FIG. 24. The method shown in FIG. 24 may be
performed, for example, by a casino server 1605 in response to a player's
request to purchase a contract and after determining the price and terms
of the contract the player wishes to purchase. This flow chart does not
imply a fixed order to the steps, and embodiments of the present
invention may be practiced in other orders.

[0285]The method 2400 begins upon receipt of payment from a player for a
fixed number of pulls in step 2405. In other embodiments this step may
comprise receipt of payment for a fixed duration of time during which the
player may play. Receipt of payment may comprise, for example, receipt of
a monetary input into a gaming device 1615 or receipt of (and, e.g.
approval of a charge on) a financial account identifier. The received
payment, or an indication of it, is then transmitted to an insurer in
step 2410. Outcomes are then generated for a fixed number of pulls in
step 2415. An adjustment of a tally of the player's accumulated credits
based on the outcomes is performed in step 2420.

[0286]In step 2425 it is determined whether the adjusted tally exceeds a
predetermined threshold. If it does, the method 2400 proceeds to step
2435 where the player is paid the amount by which the tally exceeds the
threshold. Payment to the player may be achieved by, for example,
outputting a monetary amount comprising the payment to the player at the
gaming device or by crediting the amount of the payment to a financial
account identifier associated with the player. If it is determined in
step 2425 that the adjusted tally does not exceed the predetermined
threshold then the method 2400 proceeds to step 2430 in which the amount
by which the tally falls short of the threshold is collected from the
insurer.

CONCLUSION

[0287]Although the foregoing preferred embodiments employ slot machines,
it is within the scope of the present invention to employ other types of
gaming devices, such as video poker machines, video roulette machines,
and the like. For example, in an embodiment using a video poker machine,
the player selected price parameters include identifying only specific
card hands, such as a royal flush, as active in the jackpot structure.

[0288]Thus, while the present invention has been described in terms of
certain preferred embodiments, other embodiments that are apparent to
those of skill in the art are also intended to be within the scope of the
present invention. For example, the present invention may be practiced by
an online casino utilizing only software and not involving traditional
slot machines. Accordingly, the scope of the present invention is
intended to be limited only by the claims appended hereto.