U.S. patent application number 11/456758 was filed with the patent office on 2006-11-02 for methods and apparatus for facilitating accelerated play of a flat rate play gaming session.
Invention is credited to James A. Jorasch, Robert C. Tedesco, Jay S. Walker.
Application Number | 20060247031 11/456758 |
Document ID | / |
Family ID | 38049380 |
Filed Date | 2006-11-02 |
United States Patent
Application |
20060247031 |
Kind Code |
A1 |
Walker; Jay S. ; et
al. |
November 2, 2006 |
METHODS AND APPARATUS FOR FACILITATING ACCELERATED PLAY OF A FLAT
RATE PLAY GAMING SESSION
Abstract
According to some embodiments of the present invention, methods
and apparatus are provided for expediting one or more plays of a
flat rate play session at a gaming device. In some embodiments, any
remaining plays of a session may be determined in an expedited or
substantially instantaneous manner. In some embodiments, a player
may select one or more options for how expedited plays are
displayed at a gaming device.
Inventors: |
Walker; Jay S.; (Ridgefield,
CT) ; Jorasch; James A.; (New York, NY) ;
Tedesco; Robert C.; (Fairfield, CT) |
Correspondence
Address: |
Michael D. Downs
Five High Ridge Park
Stamford
CT
06905
US
|
Family ID: |
38049380 |
Appl. No.: |
11/456758 |
Filed: |
July 11, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11273510 |
Nov 14, 2005 |
|
|
|
11456758 |
Jul 11, 2006 |
|
|
|
10001089 |
Nov 2, 2001 |
|
|
|
11456758 |
Jul 11, 2006 |
|
|
|
09518760 |
Mar 3, 2000 |
6319127 |
|
|
11456758 |
Jul 11, 2006 |
|
|
|
08880838 |
Jun 23, 1997 |
6077163 |
|
|
09518760 |
Mar 3, 2000 |
|
|
|
10331438 |
Dec 27, 2002 |
|
|
|
11273510 |
|
|
|
|
09879299 |
Jun 12, 2001 |
6634942 |
|
|
11273510 |
|
|
|
|
09437204 |
Nov 9, 1999 |
6244957 |
|
|
09879299 |
Jun 12, 2001 |
|
|
|
08774487 |
Dec 30, 1996 |
6012983 |
|
|
09437204 |
Nov 9, 1999 |
|
|
|
60627670 |
Nov 12, 2004 |
|
|
|
60637338 |
Dec 17, 2004 |
|
|
|
60282792 |
Apr 10, 2001 |
|
|
|
60373750 |
Apr 18, 2002 |
|
|
|
Current U.S.
Class: |
463/25 |
Current CPC
Class: |
G07F 17/3244 20130101;
G07F 17/3269 20130101; G07F 17/32 20130101 |
Class at
Publication: |
463/025 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A method comprising: executing at least one play of a flat rate
play session in accordance with a first rate of play; and executing
at least one play of the flat rate play session in accordance with
a second rate of play that is different from the first rate of
play.
2-20. (canceled)
Description
CLAIMS TO BENEFIT OF PRIORITY
[0001] This application claims the benefit of priority of the
following U.S. Provisional Patent Applications:
[0002] (1) U.S. Provisional Patent Application No. 60/627,670,
filed on Nov. 12, 2004, and entitled GAMING DEVICE OFFERING A FLAT
RATE PLAY SESSION AND METHODS THEREOF; and
[0003] (2) U.S. Provisional Patent Application No. 60/637,338,
filed on Dec. 17, 2004, and entitled GAMING DEVICE OFFERING A FLAT
RATE PLAY SESSION AND METHODS THEREOF.
[0004] This application is also a continuation-in-part of the
following U.S. Patent Applications:
[0005] (1) U.S. patent application Ser. No. 10/001,089, filed on
Nov. 2, 2001, and entitled GAMING DEVICE FOR A FLAT RATE PLAY
SESSION AND A METHOD OF OPERATING SAME; which claims the benefit of
priority of U.S. Provisional Patent Application No. 60/282,792,
entitled GAMING CONTRACTS, filed on Apr. 10, 2001, and is also a
continuation-in-part of U.S. patent application Ser. No.
09/518,760, filed on Mar. 3, 2000, entitled GAMING DEVICE FOR A
FLAT RATE PLAY SESSION AND A METHOD OF OPERATING SAME, and issued
on Nov. 20, 2001, as U.S. Pat. No. 6,319,127 B1; which is a
continuation of U.S. patent application Ser. No. 08/880,838, filed
on Jun. 23, 1997, entitled GAMING DEVICE FOR A FLAT RATE PLAY
SESSION AND A METHOD OF OPERATING SAME, and issued on Jun. 20,
2000, as U.S. Pat. No. 6,077,163; and
[0006] (2) U.S. patent application Ser. No. 10/331,438, filed Dec.
27, 2002, and entitled METHOD AND APPARATUS FOR AUTOMATICALLY
OPERATING A GAME MACHINE; which (a) claims the benefit of priority
of U.S. Provisional Patent Application No. 60/373,750, filed on
Apr. 18, 2002, and entitled METHOD AND APPARATUS FOR AUTOMATICALLY
OPERATING A GAME MACHINE; and (b) also is a continuation-in-part of
U.S. patent application Ser. No. 09/879,299, filed on Jun. 12,
2001, entitled SYSTEM AND METHOD FOR AUTOMATED PLAY OF MULTIPLE
GAMING DEVICES, and issued on Oct. 21, 2003, as U.S. Pat. No.
6,634,942; which is a continuation-in-part of U.S. patent
application Ser. No. 09/437,204, filed on Nov. 9, 1999, entitled
AUTOMATED PLAY GAMING DEVICE, and issued on Jun. 12, 2001, as U.S.
Pat. No. 6,244,957; which is a continuation of U.S. patent
application Ser. No. 08/774,487, filed on Dec. 30, 1996, entitled
AUTOMATED PLAY GAMING DEVICE, and issued on Jan. 11, 2000, as U.S.
Pat. No. 6,012,983.
[0007] The entirety of each of the applications identified in this
section is hereby incorporated by reference in this disclosure.
BACKGROUND OF THE INVENTION
[0008] Commonly-owned U.S. application Ser. No. 10/001,089, filed
Nov. 2, 2001 and entitled GAMING DEVICE FOR A FLAT RATE PLAY
SESSION AND A METHOD OF OPERATING SAME describes various methods
and systems for facilitating a flat rate play session. However,
such flat rate play session methods and systems may be further
enhanced and augmented for the benefit of players, gaming system
manufacturers, and casinos, by making available additional modes,
options, and features of operation.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Various embodiments of the present invention are described
in this disclosure with reference to the accompanying drawings. In
the drawings, like reference numerals indicate identical or
functionally similar elements. The leftmost digit(s) of a reference
numeral typically identifies the figure in which the reference
numeral first appears. Some of the drawings and accompanying
descriptions presented indicate some exemplary arrangements for
stored representations of information. As will be understood by
those skilled in the art and in light of this disclosure, a number
of other arrangements may be employed besides those shown.
Similarly, the illustrated entries in the exemplary arrangements
represent exemplary information, but those skilled in the art will
understand that the number and content of the entries can be
different from those illustrated.
[0010] 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.
[0011] FIG. 2A is a schematic view of the slot machine of FIG.
1.
[0012] FIG. 2B is a plan view of the slot machine of FIG. 1.
[0013] FIG. 3 is a schematic view of the slot network server of
FIG. 1.
[0014] FIG. 4 is a schematic view of a casino player database of
the server of FIG. 3.
[0015] FIG. 5 is a schematic view of the flat rate database of the
slot machine of FIG. 2.
[0016] FIG. 6 is a schematic view of the payout table of the slot
machine of FIG. 2.
[0017] FIG. 7 is a schematic view of the calculation table of the
slot machine of FIG. 2.
[0018] FIGS. 8A and 8B are overall flow diagrams of the operation
of the system of FIG. 1.
[0019] FIG. 9 is a detailed flow diagram of the operation of the
system of FIG. 1.
[0020] FIG. 10 is a flow diagram of the process of terminating play
of the system of FIG. 1.
[0021] FIGS. 11A and 11B are flow diagrams of the process of
resuming play of the system of FIG. 1.
[0022] FIGS. 12A and 12B are overall flow diagrams of the operation
of another embodiment of the present invention.
[0023] FIG. 13 is a flow diagram of the process of receiving a
payout in the embodiment of FIG. 12.
[0024] FIG. 14 is a schematic view of the flat rate price package
database of the slot machine of FIG. 2.
[0025] FIG. 15 is an overall flow diagram of the operation of
another embodiment of the present invention.
[0026] FIG. 16 is an overall schematic view of a system according
to another embodiment of the present invention.
[0027] FIG. 17 is a schematic view of the casino server of FIG.
16.
[0028] FIG. 18 is a schematic view of the insurer device of FIG.
16.
[0029] FIG. 19 is schematic view of the gaming device of FIG.
16.
[0030] FIG. 20 is a schematic view of the player device of FIG.
16.
[0031] FIG. 21 is a table illustrating an embodiment of the player
database stored in the casino server of FIG. 17.
[0032] FIG. 22 is a table illustrating an embodiment of the gaming
device database stored in the casino server of FIG. 17.
[0033] FIG. 23 is a table illustrating an embodiment of the
contract database stored in the casino server of FIG. 17.
[0034] 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.
[0035] FIG. 25 depicts an exemplary display in accordance with one
or more embodiments of the present invention.
[0036] FIG. 26 depicts an exemplary display in accordance with one
or more embodiments of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0037] According to some embodiments of the present invention,
methods, apparatus, and articles of manufacture are provided for
conducting one or more plays of a session at a first rate of play
and then conducting one or more plays of the session at a second
rate of play (e.g., one that is faster than the first rate of
play). According to one embodiment, a player may choose an option
that will automatically execute all remaining plays of a session at
an accelerated or expedited pace.
[0038] According to one embodiment of the present invention, a
player may conduct a session associated with a contract or flat
rate play that includes both manually initiated play and
automatically initiated play.
[0039] Numerous embodiments are described in this patent
application, and are presented for illustrative purposes only. The
described embodiments are not intended to be limiting in any sense.
The invention is widely applicable to numerous embodiments, as is
readily apparent from the disclosure. These embodiments are
described in sufficient detail to enable those skilled in the art
to practice the invention, and it is to be understood that other
embodiments may be utilized and that structural, logical, software,
electrical and other changes may be made without departing from the
scope of the present invention. Accordingly, those skilled in the
art will recognize that the present invention may be practiced with
various modifications and alterations. Particular features of the
present invention may be described with reference to one or more
particular embodiments or figures that form a part of the present
disclosure, and in which are shown, by way of illustration,
specific embodiments of the invention. It should be understood,
however, that such features are not limited to usage in the one or
more particular embodiments or figures with reference to which they
are described. The present disclosure is neither a literal
description of all embodiments of the invention nor a listing of
features of the invention that must be present in all
embodiments.
[0040] The terms "an embodiment," "embodiment," "embodiments," "the
embodiment," "the embodiments," "an embodiment," "some
embodiments," "an example embodiment," "at least one embodiment,"
"one or more embodiments," and "one embodiment" mean "one or more
(but not necessarily all) embodiments of the present invention(s)"
unless expressly specified otherwise.
[0041] The terms "including," "comprising," and variations thereof
mean "including but not limited to", unless expressly specified
otherwise.
[0042] The term "consisting of" and variations thereof mean
"including and limited to", unless expressly specified
otherwise.
[0043] The enumerated listing of items does not imply that any or
all of the items are mutually exclusive. The enumerated listing of
items does not imply that any or all of the items are collectively
exhaustive of anything, unless expressly specified otherwise. The
enumerated listing of items does not imply that the items are
ordered in any manner according to the order in which they are
enumerated.
[0044] The terms "a," "an," and "the" mean "one or more", unless
expressly specified otherwise.
[0045] The term "based on" means "based at least on" unless
expressly specified otherwise.
[0046] The methods described (regardless of whether they are
referred to as methods, processes, algorithms, calculations, and
the like) inherently include one or more steps. Therefore, all
references to a "step" or "steps" of such a method have antecedent
basis in the mere recitation of the term "method" or a like term.
Accordingly, any reference in a claim to a "step" or "steps" of a
method is deemed to have sufficient antecedent basis.
[0047] Headings of sections provided in this patent application and
the title of this patent application are for convenience only, and
are not to be taken as limiting the disclosure in any way.
[0048] Devices that are in communication with each other need not
be in continuous communication with each other, unless expressly
specified otherwise. In addition, devices that are in communication
with each other may communicate directly or indirectly through one
or more intermediaries.
[0049] A description of an embodiment with several components in
communication with each other does not imply that all such
components are required. To the contrary, a variety of optional
components are described to illustrate the wide variety of possible
embodiments of the present invention.
[0050] Further, although process steps, method steps, algorithms or
the like may be described in a sequential order, such processes,
methods and algorithms may be configured to work in alternate
orders. In other words, any sequence or order of steps that may be
described in this patent application does not, in and of itself,
indicate a requirement that the steps be performed in that order.
The steps of described processes may be performed in any order
practical. Further, some steps may be performed simultaneously
despite being described or implied as occurring non-simultaneously
(e.g., because one step is described after the other step).
Moreover, the illustration of a process by its depiction in a
drawing does not imply that the illustrated process is exclusive of
other variations and modifications thereto, does not imply that the
illustrated process or any of its steps are necessary to the
invention, and does not imply that the illustrated process is
preferred.
[0051] It will be readily apparent that the various methods and
algorithms described may be implemented by appropriately programmed
general purpose computers and computing devices, for example.
Typically a processor (e.g., a microprocessor) will receive
instructions from a memory or like device, and execute those
instructions, thereby performing a process defined by those
instructions. Further, programs that implement such methods and
algorithms may be stored and transmitted using a variety of known
media.
[0052] When a single device or article is described, it will be
readily apparent that more than one device/article (whether or not
they cooperate) may be used in place of a single device/article.
Similarly, where more than one device or article is described
(whether or not they cooperate), it will be readily apparent that a
single device/article may be used in place of the more than one
device or article.
[0053] The functionality and/or the features of a device may be
alternatively embodied by one or more other devices that are not
explicitly described as having such functionality/features. Thus,
other embodiments of the present invention need not include the
device itself.
[0054] The term "computer-readable medium" refers to any medium
that participates in providing data (e.g., instructions) that may
be read by a computer, a processor or a like device. Such a medium
may take many forms, including but not limited to, non-volatile
media, volatile media, and transmission media. Non-volatile media
include, for example, optical or magnetic disks and other
persistent memory. Volatile media include dynamic random access
memory (DRAM), for example. Transmission media include coaxial
cables, copper wire, and fiber optics, including the wires that
comprise a system bus coupled to the processor. Transmission media
may include or convey acoustic waves, light waves, and
electromagnetic emissions, such as those generated during radio
frequency (RF) and infrared (IR) data communications. Common forms
of computer-readable media include, for example, a floppy disk, a
flexible disk, hard disk, magnetic tape, any other magnetic medium,
a CD-ROM, DVD, any other optical medium, punch cards, paper tape,
any other physical medium with patterns of holes, a RAM, a PROM, an
EPROM, a FLASH-EEPROM, any other memory chip or cartridge, a
carrier wave, and any other medium that a computer can read.
[0055] Various forms of computer readable media may be involved in
carrying an instruction (or a plurality or sequence of
instructions) to a processor. For example, sequences of instruction
(a) may be delivered from RAM to a processor, (b) may be carried
over a wireless transmission medium, and/or (c) may be formatted
according to numerous formats, standards or protocols, such as
Bluetooth, TDMA, CDMA, and 3G.
[0056] Certain preferred embodiments of the present invention will
now be described in greater detail with reference to the drawings.
Although some of the embodiments discussed in this disclosure are
directed to reeled slot machines or video poker machines, it should
be understood that the present invention is equally applicable to
other gaming devices, such as video blackjack machines, video
roulette, video bingo, video pachinko, video lottery, video keno,
and the like.
[0057] Various examples of embodiments comprising methods for
facilitating play of video poker are described and some examples of
embodiments comprising a video poker gaming device or other type of
gaming device configured or configurable to allow for play of video
poker are also described.
[0058] In accordance with various embodiments of the present
invention, there are provided a method, apparatus, and article of
manufacture for providing a gaming session using a gaming
device.
[0059] In one embodiment, the method includes initiating a game
play session of a gaming device after receiving an indication of
payment for the game play session. The session preferably spans a
pre-established duration. A duration may comprise, without
limitation, a specified amount of time, a specified number of
winning outcomes, and/or a specified number of game plays (e.g.,
handle pulls of a slot machine).
[0060] 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.
[0061] In accordance with one embodiment, a flat rate play session
is associated with a contract, wherein the contract specifies terms
such as, for example, a price to be paid by a player to establish
the contract, a duration of play of a gaming device, and/or a
threshold of credits above which the player may collect winnings
for the game play session (e.g., from a gaming device). The terms
of the contract may be determined based on player selected price
parameters and/or operator controlled price parameters. In some
embodiments, a contract may involve a third party that acts as an
insurer.
[0062] In accordance with one embodiment, a game play session may
be purchased by means of purchasing a contract from a casino or a
third party such as an insurance provider, wherein the contract
specifies terms such as, for example, a price to be paid by the
purchaser for the contract.
[0063] In one embodiment, the method includes identifying at least
one price parameter, determining a contract price based upon the at
least one identified price parameter, and initiating a game play
session of at least one gaming device. The game play session may be
initiated upon receiving an indication of payment of the entire
contract price, upon receiving an indication of payment of a
portion of the contract price, or before any payment is
provided.
[0064] 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.
[0065] In accordance with some embodiments of the present
invention, a game play session may be associated with a contract.
According to one embodiment, a player may establish a contract
(e.g., with an insurer, such as a casino or another entity) or
similar agreement to use a gaming device, such as a slot
machine.
[0066] 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. In such an embodiment, the player enjoys the fixed number
of pulls without the risk of any loss beyond the cost of the
contract.
[0067] In accordance with one embodiment, a contract may be
purchased at a gaming device. The gaming device at which a contract
is purchased may be different than the one or more gaming devices
at which the session corresponding to the contract is executed.
[0068] Some embodiments of the present invention provide for
determining a price for a contract for a block of handle 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 one
thousand pulls, then the contract for the block of one thousand
pulls could by sold for $35. Various ways for determining a price
for a set of handle pulls are discussed herein.
[0069] As discussed herein, various embodiments of the present
invention are directed generally to a method and apparatus for
operating a gaming device for a flat rate play session. For
example, a contract for a session of game play may specify a fixed
number of handle pulls for a determined contract price. As used
herein, a 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 may be 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, an interval may be described as two hours, one hundred
spins, fifty winning spins, etc.
[0070] In one embodiment 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 fiat 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. 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 or other payment. 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.
[0071] It should be noted that, as used herein, the terms
"contract" "gaming contract," "session," "gaming session," "play
session," "flat rate session" and "flat rate play session" may be
used interchangeably to describe flat rate session play of the
present invention, wherein players provide a flat price and in
exchange execute a plurality of game plays administered by a gaming
device. For example, if a gaming device is described as storing a
number of gaming contracts with operator-specified parameters, it
may be understood that such contracts are in essence pricing
arrangements that allow for players to execute one or more gaming
sessions by providing a flat rate price.
[0072] The following definitions define the terms used to describe
the contract embodiments of the present invention:
[0073] 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.
[0074] 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.
[0075] 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:
[0076] 1. The player pays the insurer a fixed amount up front
[0077] 2. The player must make a predetermined number of handle
pulls, no more and no less.
[0078] 3. The player need not pay any additional money after
purchasing the contract.
[0079] 4. The player keeps any net winnings after all handle pulls
have been completed.
[0080] 5. 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.
[0081] 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.
[0082] Gaming Device--Any electrical, mechanical, or
electromechanical 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.
[0083] Gross winnings--the total of a players 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.
[0084] 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.
[0085] Net winnings--the total of a players 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.
[0086] Various aspects of embodiments of the present invention
related to contracts are described in detail below.
1. Description of the Contract
[0087] 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.
[0088] 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.times.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.
[0089] 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 players behalf. For example, the
instructions will tell the machine how fast to gamble, when to
quit, and then where to send winnings.
2. Amount of Play
[0090] A contract may place one or more of the following exemplary
restrictions on play covered by the contract:
[0091] 1. The player must make a minimum number of handle
pulls.
[0092] 2. The player may not make more than a maximum number of
handle pulls.
[0093] 3. The player must play for a certain minimum time
period.
[0094] 4. The player must play for less than a certain maximum time
period.
[0095] 5. The player must maintain a minimum rate of play.
[0096] 6. The player may not exceed a maximum rate of play.
[0097] 7. The total coin in over the course of the contract must
exceed a certain minimum amount.
[0098] 8. The total coin in over the course of the contract must
not exceed a certain amount.
[0099] 9. The player must play until obtaining a specified
outcome.
3. Wager Denomination
[0100] 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.
[0101] 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.
[0102] Since play may occur in credit mode, each wager might
consist of wager 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.
4. Winnings Threshold
[0103] 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.times.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.times.600 pulls). Thus, in the above
example, the players 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 players performance.
[0104] At the end of a contract, a players 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.times.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.
[0105] 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.
[0106] Rather than insuring against all of a players 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.
[0107] 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.
[0108] 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.
[0109] 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.
[0110] 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.
[0111] 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.
[0112] 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.
5. Player Decisions
[0113] 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.
[0114] 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.
[0115] 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.
6. Contract Price
[0116] 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 players loss would count as zero in figuring out the
player's average win, since the player does not have to pay for
losses.
[0117] 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, some exemplary
computations will be described below with respect to only one or
the other method of pricing a contract.
[0118] 1) In one example computation, 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.
[0119] To price a contract using the method of pricing described
above, for example, 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.
[0120] 2) In another example computation, 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.
[0121] 3) In yet another example computation, 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 -
.infin. 0 .times. w .times. .times. P .function. ( w ) ##EQU1##
where P(w) is the probability of w.
[0122] 4) In another example computation, using 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.
[0123] 5) In still another example computation method, 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 players 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."
[0124] 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 .function. ( x ) = 1 .sigma. .times. 2 .times. .pi.
.times. e - ( x - .mu. ) 2 2 .times. .sigma. 2 . ##EQU2## In this
formula, .sigma. is the standard deviation, and .mu. 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 .mu..sub.0 and standard
deviation .sigma..sub.0. Then, assuming each handle pull is
independent, n handle pulls of the slot machine may be described by
a function with mean .mu.=.mu..sub.0n and standard deviation
.sigma.=.sigma..sub.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.
[0125] 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: .intg. -
.infin. 0 .times. 0 * .times. f .function. ( x ) .times. d x +
.intg. 0 .infin. .times. x * .times. f .function. ( x ) .times. d x
= .intg. 0 .infin. .times. x * .function. ( x ) .times. d x .
##EQU3##
[0126] We proceed to solve the integral: .intg. 0 .infin. .times. x
* .times. f .function. ( x ) .times. d x = .times. .intg. 0 .infin.
.times. x * .times. 1 .times. ( 2 .times. .pi..sigma. ) .times. exp
.function. ( - ( x - .mu. ) 2 / ( 2 .times. .sigma. 2 ) ) .times. d
x = .times. 1 / ( 2 .times. .pi..sigma. ) .times. .intg. 0 .infin.
.times. x * .times. exp .function. ( - ( x - .mu. ) 2 / ( 2 .times.
.sigma. 2 ) ) .times. d x = .times. 1 / ( 2 .times. .pi..sigma. )
.times. .intg. 0 .infin. .times. [ ( x - .mu. ) * .times. exp
.function. ( - ( x - .mu. ) 2 / ( 2 .times. .sigma. 2 ) ) + .times.
.mu. * .times. exp .function. ( - ( x - .mu. ) 2 / ( 2 .times.
.sigma. 2 ) ) ] .times. d x = .times. 2 .times. .sigma. 2 / ( 2
.times. .pi..sigma. ) * .times. ( - 1 / 2 ) * .function. [ exp
.function. ( - ( x - .mu. ) 2 / ( 2 .times. .sigma. 2 ) ) ] 0
.infin. + .times. .mu. .times. .intg. 0 .times. .infin. .times. 1 /
( 2 .times. .pi..sigma. ) .times. exp .function. ( - ( x .times. -
.times. .mu. ) 2 / ( 2 .times. .sigma. .times. 2 ) ) .times. d x
##EQU4##
[0127] We deal with the two terms separately: 2 .times. .sigma. 2 /
( 2 .times. .pi..sigma. ) * .times. ( - 1 / 2 ) * .function. [ exp
.function. ( - ( x - .mu. ) 2 / ( 2 .times. .sigma. 2 ) ) ] 0
.infin. = .times. - .sigma. 2 / ( 2 .times. .pi..sigma. ) *
.function. [ 0 - exp .function. ( - .mu. 2 / ( 2 .times. .sigma. 2
) ) ] = .times. .sigma. 2 .times. exp .function. ( - .mu. 2 / ( 2
.times. .sigma. 2 ) ) / ( 2 .times. .pi..sigma. ) = .times. n
.times. .times. .sigma. 0 2 .times. exp .function. ( - n 2 .times.
.mu. 0 2 / ( 2 .times. .pi..sigma. 0 2 ) ) / ( 2 .times. .pi.
.times. n .times. .times. .sigma. 0 ) = .times. n 3 / 4 .times.
.sigma. 0 3 / 2 .times. exp .function. ( - n .times. .times. .mu. 0
2 / ( 2 .times. .sigma. 0 2 ) ) / ( 2 .times. .pi. ) ##EQU5## and
##EQU5.2## .mu. .times. .intg. 0 .infin. .times. 1 / ( 2 .times.
.pi..sigma. ) .times. exp .function. ( - ( x - .mu. ) 2 / ( 2
.times. .sigma. 2 ) ) .times. d x = .times. .mu. .times. .intg. -
.mu. / .sigma. .infin. .times. 1 / ( 2 .times. .pi..sigma. )
.times. exp .function. ( - y 2 / 2 ) .times. .sigma. .times. d y =
.times. .mu. .times. .sigma. .times. .intg. - .mu. / .sigma.
.infin. .times. 1 / ( 2 .times. .pi. ) .times. exp .function. ( - y
2 / 2 ) .times. d y = .times. .mu. .times. .sigma. .function. [ 1 -
.intg. .infin. - .mu. / .sigma. .times. 1 / ( 2 .times. .pi. )
.times. exp .function. ( - y 2 / 2 ) .times. d y ] ##EQU5.3## (
where .times. .times. y = ( x - .mu. ) / .sigma. ) ##EQU5.4##
[0128] The integral is the cumulative distribution function for a
zero mean, unit standard deviation Gaussian, for which tables
exist. We denote it by N(-.mu./.sigma.). Continuing: .mu. .times.
.intg. 0 .infin. .times. 1 / ( 2 .times. .pi..sigma. ) .times. exp
.function. ( - ( x - .mu. ) 2 / ( 2 .times. .sigma. 2 ) ) .times. d
x = .mu. .times. .sigma. .function. [ 1 - N .function. ( - .mu. /
.sigma. ) ] = n .times. .times. .mu. 0 .times. n 1 / 4 .times.
.sigma. 0 .function. [ 1 - N .function. ( - n .times. .times. .mu.
0 / ( n .times. .times. .sigma. 0 ) ) ] = n 5 / 4 .times. .mu. 0
.times. .sigma. 0 .function. [ 1 - N .function. ( - n .times.
.times. .mu. 0 / .sigma. 0 ) ] ##EQU6##
[0129] Recombining the two terms we get: .intg. 0 .infin. .times. x
* .times. f .function. ( x ) .times. d x = n 5 / 4 .times. .sigma.
0 3 / 2 .times. exp .function. ( - n .times. .times. .mu. 0 2 / ( 2
.times. .sigma. 0 2 ) ) / ( 2 .times. .pi. ) + n 5 / 4 .times. .mu.
0 .times. .sigma. 0 .function. [ 1 - N .function. ( - n .times.
.times. .mu. 0 / .sigma. 0 ) ] ##EQU7##
[0130] 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.
[0131] 6) In another example computation, 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.
[0132] Other types of computations may be readily apparent to those
skilled in the art in light of the present disclosure. 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 players losses, then
the insurer might price the contract at $20 to insure itself a $5
average profit.
7. Automated Play
7.01. Introduction
[0133] In various embodiments of the present invention, a gaming
device may be configured to execute a number of game plays
automatically (i.e., without receiving player input in association
with one or more game plays of a gaming contract or session).
Various methods for administering a plurality of game plays without
receiving continuous input from a player are described in
Applicants U.S. Pat. No. 6,012,983, filed Dec. 30, 1996, entitled
"AUTOMATED PLAY GAMING DEVICE"; U.S. Pat. No. 6,634,942, filed Jun.
12, 2002, entitled "SYSTEM AND METHOD FOR AUTOMATED PLAY OF
MULTIPLE GAMING DEVICES"; U.S. application Ser. No. 10/635,986,
filed Aug. 7, 2003, entitled "SYSTEM AND METHOD FOR REMOTE
AUTOMATED PLAY OF GAMING DEVICES"; U.S. application Ser. No.
10/636,520, filed Aug. 7, 2003, entitled "SYSTEM AND METHOD FOR
COMMUNICATING GAME SESSION INFORMATION"; and U.S. application Ser.
No. 10/331,438, filed Dec. 27, 2002, entitled "METHOD AND APPARATUS
FOR AUTOMATICALLY OPERATING A GAME MACHINE"; the entirety of each
are incorporated in this disclosure by reference.
[0134] In various embodiments of the present invention, play in
accordance with a contract may include at least one play that is
initiated automatically. In some embodiments, play in accordance
with a contract may include at least one play that is initiated
automatically and at least one play that is manually initiated. In
some embodiments, a player may be able to switch back and forth
between manual and automated play as often as he likes. 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
a mode for "automated play" or "automatic play." The player may
later have the option of taking the gaming device out of automated
play and of manually initiating handle pulls.
[0135] In some embodiments, a player may specify that a contract is
to involve automated play when the player establishes the contract.
In one example, a player establishes a contract for an hour of play
at ten hands of video poker per minute, in which the gaming device
will execute the contract by automatically spinning and generating
outcomes. As discussed above, a player may optionally set up a
contract to schedule a temporary pause or stoppage in automated
play (e.g., for fifteen minutes after the first half-hour of
automated play).
[0136] In some embodiments, a player may establish a gaming
contract and then during the corresponding gaming session, the
player may request or indicate a desire for a portion of the plays
under the contract to be executed automatically. For example, as
described in various ways in this disclosure, a player may
establish a gaming contract lasting a period of time (e.g., one
hour) or a number of plays (e.g., 500 hands of video poker). At
some point during the contract, the player may indicate (e.g.,
using an input device, such as a physical button or icon of a
touch-sensitive display screen) a desire that a plurality of game
plays are to be executed automatically (e.g., a gaming device
and/or server should initiate and/or resolve at least one game play
without the player pressing a "deal," "draw," and/or "hold"
button).
[0137] In one or more embodiments, a player may specify a length of
time or number of game plays during which automated play should be
utilized (e.g., the player specifies that the gaming device will be
on "Auto-Play" for ten minutes, for sixty hands, for the remainder
of a contract, etc.). In some embodiments, a player may set a
gaming device on automated play indefinitely. For example, the
gaming device may be configured to continually execute game plays
until (i) an input is received indicating that automated play
should be deactivated, or (ii) the number of game plays or amount
of time associated with a gaming contract are used or expire.
[0138] Thus, a player may actuate and/or request a feature or
option for automated play (e.g., by actuating an appropriately
labeled input device) at any time before and/or during a gaming
session (e.g., when time and/or at least one play is remaining in a
gaming contract). The gaming device may then be configured to
continually execute game plays without further player input until,
for example, (i) an input is received indicating that the automated
play feature should be deactivated, (ii) the number of game plays
and/or amount of time associated with the gaming contract are used
or expire, (iii) a particular outcome is reached (e.g., a Royal
Flush), (iv) a length of time or number of game plays indicated by
a player (e.g., twenty of the remaining fifty game plays, half of
the remaining time, 90% of the remaining game plays) has been used
or expire, (v) the player wins a predetermined number of
consecutive outcomes, and/or (vi) the players credit balance
increases by twenty-five credits (e.g., so that the player can take
over manual control when the machine "gets hot"), etc.
[0139] It will be readily understood in light of this disclosure
that a player may choose to remain at a gaming device that is
executing a plurality of game plays automatically for the player in
association with a gaming contract or session, but some types of
players may prefer to leave (at least temporarily) a gaming device
that is playing automatically. In one example, a player can sign up
for a contract, and then have the contract executed automatically
by a gaming device. In some embodiments, the player can view a
running tally of his accumulated credits and/or a representation of
some or all of his outcomes using another device (e.g., from home
using a computer to view results on the Internet). As discussed
above, in some embodiments a player may indicate instructions or
decisions that may be used in conducting automated play when the
player is not present at a gaming device.
[0140] One example of automated play is discussed below with
respect to an exemplary feature called "Cruise Control," for which
it is expected that a player will remain at the gaming device for
most if not all of the automated play (e.g., to view outcomes as
they are generated). In another example of automated play discussed
below with respect to an exemplary feature called "Walk-Away," it
is assumed that the player might not remain at the gaming device
during all of the automated play.
[0141] In some embodiments, 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 ten 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 ten seconds. If in the same ten-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 ten-second interval.
[0142] As can be seen from the above two examples, in some
embodiments 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.
7.02. Activating/Deactivating Automated Play
[0143] According to some embodiments, activating a feature or
option for automated play (e.g., a Walk-Away feature) may comprise
one or more of: (i) receiving a request from a player to activate
the feature, (ii) determining a code or password that may be used
to activate/deactivate the feature, (iii) activating the feature
(e.g., receiving a code and automatically executing game plays
thereafter), and (iv) outputting an indication that the feature is
active (e.g., a display screen outputs a message such as, "This
machine in use by Player 8160916" or "Automated Play in
Progress").
[0144] In some embodiments, automated play may then be deactivated
upon one or more of a variety of conditions, including but not
limited to (i) an input or other indication that automated play
should be deactivated is received (e.g., a code or password is
entered by a player or casino representative, a signal is received
from a casino server), (ii) the number of game plays or amount of
time associated with the gaming contract are used or expire, (iii)
a particular outcome is reached (e.g., a Royal Flush), and so
on.
[0145] In some embodiments, a player may activate an automated play
feature (e.g., a Walk-Away feature) and choose not to disengage the
feature (e.g., the player does not return) until after the gaming
session is complete.
7.03. Codes and Passwords
[0146] In some embodiments, a gaming device or casino personnel may
provide a code to a player upon the player's request of an
automated play feature (e.g., a Walk-Away feature). As discussed in
this disclosure, codes and passwords may be useful in some
embodiments for activating and/or deactivating automated play.
[0147] For example, in one embodiment, a random number may be
generated or otherwise determined by a gaming device and/or server
(e.g., between a range of random numbers, such as 00001-99999). The
number may then be assigned to a particular player (e.g., the
number is stored as a database record associated with the player),
and output to the player (e.g., via a printer, display screen,
etc.). In another example, a gaming device may store or otherwise
communicate with a database storing a number of non-numeric (e.g.,
"dinosaur") or partially-numeric passwords (e.g., "purple47"), from
which one may be randomly chosen, assigned and output to a
player.
[0148] In other embodiments, a player may enter a desired password.
For example, the player may be prompted by a gaming device to enter
a password. In one such embodiment, a gaming device may specify
(output to a player) various limitations associated with possible
passwords players may choose. Various embodiments are contemplated,
including but not limited to: (i) each password must contain at
least one numeric character, (ii) each password must be between
four and eight characters in length, (iii) the password is not
"Vegas," "lucky," "1234" or any other password deemed unacceptable
(e.g., due to its commonality), and so on. In one example, a gaming
device may store or otherwise communicate with a database
containing a list of various unacceptable passwords (e.g., as
specified by an operator).
[0149] In some embodiments, a code or password may comprise an
identifier that may be used to identify the player, such as a
player tracking number, a biometric (e.g., a thumbprint), financial
account number, or driver's license number.
7.04. Stored Strategies
[0150] For some types of games, a player typically makes strategy
decisions when the gaming device is not set for automated play. For
example, in a draw video poker game, the player is typically
responsible for deciding which cards of a dealt five-card hand to
hold in an attempt to improve the hand with a draw. Accordingly, in
some embodiments of the present invention, when a gaming device is
configured to play automatically on the player's behalf, the gaming
device may be operable to hold or discard certain cards of a dealt
hand in accordance with one or more strategy protocols (e.g.,
stored within a memory of the gaming device and/or a server). For
example, a protocol comprising "perfect strategy" rules may
indicate, based on tested mathematical simulations, which cards of
a dealt five-card draw poker hand should be held so as to maximize
the expected value of the hand.
[0151] It should be noted that in some embodiments of the present
invention, perfect strategy may alter depending upon the player's
credit balance. For example, if the player has a sufficiently
negative credit balance, and very little time remaining in a
session, the only strategy that may yield a positive credit balance
may be to draw exclusively toward a high-paying outcome, such as a
Royal Flush or Four-of-a-Kind (e.g., as only a substantial payout
will bring the player's balance above zero credits, whereby the
player would be able to collect some amount of currency at the end
of the session).
[0152] Thus, in some embodiments, when a request is received to
execute a number of game plays in association with automated play,
the present invention may comprise executing hold/discard decisions
of a video poker game based on one or more stored strategy rules.
In some embodiments, only one preset strategy (e.g., preset by a
gaming device manufacturer or casino operator) may be available
(e.g., maximize expected value). In other embodiments, a player may
choose from a number of strategy options for automated play (e.g.,
"Always maximize expected value," "Always maximize my chances of
getting a winning hand" or "Always draw for the Royal Flush,"
etc.).
[0153] It should also be noted that such stored strategy protocols
may also be used to offer strategy hints to players, rather than be
used to automatically decide which cards to hold and discard for a
player when automated play is activated. For example, various
strategy recommendations may be output to a player when automated
play is not activated. Various methods of outputting such
recommendations are contemplated, including but not limited to
written recommendations (e.g., text is output via a display
screen); auditory recommendations (e.g., a voice recording is
output via audio speakers); highlighting, shading, outlining an
other graphical alterations (e.g., the recommended "hold" cards are
automatically outlined for the player); and so on.
7.05. "Cruise Control" Example
[0154] In some embodiments, a player may set a gaming device on
automated play indefinitely. For example, while playing out a video
poker gaming contract that entitles the player to an hour of
unlimited hands of video poker, the player may decide he no longer
wishes to press a deal button, select hold cards, press a draw
button, and so on, yet wants to remain seated in front of the
gaming device to watch game play occur. The player may actuate an
input device to indicate such a desire (e.g., the player presses a
button labeled "Activate Cruise Control" or "Activate Automatic
Play"). Accordingly, the gaming device may be configured to
continually execute game plays until (i) an input is received
indicating that automated play should be deactivated, or (ii) the
number of game plays or amount of time associated with the gaming
contract are used or expire.
[0155] Thus, in accordance with some embodiments of the present
invention, a gaming device may execute a number of game plays,
while a player watches the machine perform strategy decisions and
receives payouts for winning outcomes (e.g., winning hands in video
poker). Winning outcomes may be accompanied by additional
animations or sound effects to call the player's attention to the
device. Various input devices may then enable the player to regain
control, change the speed with which outcomes are presented, and so
on.
7.06. "Walk-Away" Example
[0156] In various embodiments, a player may leave a gaming device,
and the gaming device may continue automated play on the players
behalf. For example, a gaming device may execute a number of game
plays while a player is not present at a gaming device. As
described above, the machine may perform strategy decisions and may
continue to present payouts for winning outcomes. Winning outcomes
may be accompanied by additional animations or sound effects, even
if the player is not at the gaming device (or is not expected to
remain at the gaming device). For instance, outputting indications
of winning outcomes may be desirable in order to attract the
attention of passers-by or nearby players, who may become
interested in the automated play mode. As described above, various
input devices may enable a player to regain control, change the
speed with which outcomes are presented, and so on, if the player
returns to the gaming device (e.g., before automated play
terminates).
[0157] For example, a player may actuate a "Walk-Away feature
(e.g., by actuating an appropriately labeled input device) at any
time during a gaming session, such that the gaming device may then
be configured to continually execute game plays without further
player input until (i) an input is received indicating that
Walk-Away should be deactivated, (ii) the number of game plays or
amount of time associated with the gaming contract are used or
expire, (iii) a particular outcome is reached (e.g., a Royal
Flush), etc.
[0158] Thus, a player may not be present while a gaming device
executes a plurality of game plays in association with an automated
play feature. In accordance with some embodiments, the player may
then return to the gaming device at some later point while the
feature is activated, and deactivate the feature using a code.
Thus, the player may rest assured that although the player may not
be present at the machine, no other player may approach the gaming
device and execute a number of game plays in association with the
gaming contract (e.g., the code may be provided only to the first
player, may be chosen by the first player as a private password,
etc.). The player may also not return until after the gaming
session is complete.
8. Offering the Contract
[0159] 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.
[0160] 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 players
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.
9. Agreeing to the Contract
[0161] 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. Of course, rather than a touch screen, a player may use
special buttons, keys, or voice input devices to specify a desired
contract and/or contract term(s). Other types of input devices will
be readily apparent to those skilled in the art.
[0162] The player might use menus to customize a contract for
himself. For example, 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.
[0163] 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. For example, the player might
select a contract while visiting the Web site provided by the
casino server. 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. Of
course, as discussed above, some terms may be presented to the
player via the Internet.
[0164] According to one embodiment, after accepting a contract 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.
[0165] 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.
[0166] According to one embodiment, when accepting a contract,
especially a contract in which the player will be remote from the
casino as outcomes are generated for him, the player may be asked
to provide an email address, address, phone number, etc., to which
generated outcomes and other session information may be sent.
[0167] According to one embodiment, 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.
[0168] According to various embodiments of the present invention, a
player may confirm acceptance of or entry into a contract by paying
for it. The player might pay by 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. In some embodiments, a player may receive
a contract or a contract indicator (e.g., a token or symbol) to
bring to a gaming device. The gaming device might then recognize
the contract indicator, for example, a bar code, and then execute
the corresponding contract.
[0169] In some embodiments, payment for a contract need not
necessarily be paid upfront (e.g., before execution of a contract
is initiated). A player may commit to paying in the future, for
example, or may agree to a payment schedule of one or more
installments. According to one embodiment, a player might provide
payment for a contract only under certain specified conditions,
such as if the player has lost money during execution of the
contract. Some exemplary payment schedules, without limitation, are
as follows: [0170] 1. The player agrees to pay the full price of
the contract at some designated future date. [0171] 2. The player
pays a fixed percentage of the full price of the contract on a
periodic basis until the full price of the contract has been paid
off. [0172] 3. Interest accrues on any unpaid portion of the
contract price. The player pays a fixed amount on a periodic basis
until the price of the contract and any accrued interest on the
unpaid portion of the contracts price has been paid. [0173] 4. The
player pays a portion of the contract price on a periodic basis,
and the required payments are modulated based on the player's
current winnings from the contract. In one example, during any
given scheduled pay period, the player might pay 10% of the
contract price if his net winnings from the contract are negative,
but only 5% of the contract price if his net winnings from the
contract are positive. Then, at the termination of the contract, if
the player has not paid the full amount for the contract, the rest
of the price of the contract is deducted from the players winnings.
If the player's winnings still do not cover the remaining price of
the contract, then the player is billed for the rest of the price
of the contract.
[0174] In some embodiments, if the player is to make future
payments in order to pay for a contract, the future payments are
charged automatically by the casino server to a financial account
of the player. A player's financial account might include a credit
card, debit card, or checking account, for example. The player may
further agree not to close his financial account before payment for
the contract has been completed. Also, as discussed herein, any
player winnings may be added automatically to the player's
financial account according to the terms of the contract.
10. Instruction Sets
[0175] 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?
[0176] Since the contract covers a large number of pulls, it is
possible for 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 ten pulls per minute, a player might decide he would like a
fifteen minute break between the first half-hour and the second
half-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 half-hour. The gaming device
might then freeze for fifteen minutes, preventing other players
from stepping in and allowing the contract holding player to take
his fifteen minute break. The device can then unlock after fifteen
minutes, perhaps with the entry of a password, and resume the
generation of outcomes.
[0177] One advantage 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. In some embodiments, as discussed
in this disclosure, a player can then view a running tally of his
accumulated credits over the Internet while in Virginia, for
example.
[0178] In general, player instructions associated with a contract
will include some action to be performed as well as some triggering
condition for the performance of the action. As an example, a
player instruction may be to increase the rate of handle pulls
provided accumulated player credits exceed one hundred. In this
example, the action is to increase the rate of handle pulls, and
the triggering condition is whether accumulated player credits
exceed one hundred. The following exemplary player actions may be
part of a player's instructions:
[0179] 1. Increase or decrease a wager amount on one or more handle
pulls.
[0180] 2. Increase or decrease a rate of wagering.
[0181] 3, Cease gambling.
[0182] 4. Change the way outcomes are displayed.
[0183] The following example conditions may trigger one or more of
the above example actions:
[0184] 1. The player has just won or lost on one or more handle
pulls.
[0185] 2. The player has just won a certain amount on one or more
handle pulls.
[0186] 3. Any player defined sequence of wins and losses has
occurred on prior handle pulls.
[0187] 4. The player has approached or left the vicinity of the
gaming device.
[0188] 5. The current time has reached a particular time of
day.
[0189] 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 two pulls per second. He
therefore enters into a contract which is to be executed by the
machine at two pulls per second for the next eight 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 six minutes, and so the contract ends.
[0190] 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 players presence.
[0191] 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. For instance, the player may add instructions to
always draw to a four card open-ended straight flush.
11. Times of Execution
[0192] 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.
[0193] 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.
[0194] 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.
[0195] 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 one hundred
outcomes at a time, each block being generated from 8 p.m. to 9
p.m. 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 p.m. to 9 p.m. 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.
[0196] 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
12. Viewing the Contract's Execution
[0197] 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
players 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.
[0198] 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.
[0199] 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.
[0200] 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.
[0201] 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.
[0202] 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.
13. Revenue Management
[0203] 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:
[0204] 1. Times or dates on which the contract is to be
executed.
[0205] 2. The gaming device on which the contract is to be
executed
[0206] 3. Flexibility in the contract's execution.
[0207] 4. A player's playing history.
[0208] 5. The importance of the player as a customer of the
casino.
[0209] 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.
[0210] 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.
[0211] 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.
[0212] 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.
14. Settlement
[0213] 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.
[0214] 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.
[0215] 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.
[0216] 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.
[0217] 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
meantime, 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.
[0218] 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.
[0219] 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.
[0220] 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.
[0221] 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.
[0222] 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.
[0223] 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.
[0224] 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 player's
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.
[0225] 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.
[0226] 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.
[0227] 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.
B. Systems and Processes
[0228] 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 one 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.
[0229] 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.
[0230] 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.
[0231] 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.
[0232] 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.
[0233] 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.
[0234] 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.
[0235] 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.
[0236] 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.
[0237] The databases stored in the data storage device 224 include
a probability table 226, a calculation table 227, a payout table
228, a flat rate price package database 229, and a flat rate
database 246. As discussed in greater detail below, the flat rate
database 246 and the calculation table 227 store information
related to the flat rate play session and calculation of the flat
rate price, respectively. The flat rate price package database 229
stores information describing different preestablished flat rate
packages as custom designed by the casino.
[0238] 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.
[0239] 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.
[0240] 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 1106 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.
[0241] 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.
[0242] 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.
[0243] 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.
[0244] 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.
[0245] 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.
[0246] Complimentary points awarded 424 is further illustrative of
additional information a casino may store in a players record. As
described below, a players 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.
[0247] 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 players
visits, the amount of money wagered, and the like.
[0248] 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.
[0249] 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 players
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.
[0250] 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."
[0251] 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.
[0252] 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.
[0253] 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.
[0254] 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 calculating a flat rate
price. There 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.
[0255] For example, the price algorithm may operate as follows. The
first step is to determine a "base" flat rate price. This may be
calculated as follows: Base Price=[(amount
wagered).times.(interval)].times.[(expected coins awarded for all
active pay combinations over a cycle/expected coin-in over a
cycle)].
[0256] For example, the following Base Price calculation represents
a player selecting three dollar coins per handle pull, an interval
of five hundred 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: Base .times.
.times. Price = [ ( $3 ) .times. ( 500 ) ] .times. [ ( 2 .times. ,
.times. 160 / 10 .times. , .times. 648 ) ] = $1 .times. , .times.
500 .times. .202855 = $304 .times. .28 ##EQU8##
[0257] 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 a 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 .times. .times. Adjusted .times. .times. Price = $304
.times. .28 .times. 150 .times. % = $456 .times. .42 ##EQU9##
[0258] 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.
[0259] The Base Price or (Profit Adjusted Price) could be further
modified by various other operator selected price parameters, such
as one or more of the following:
Time of Day (TD)
[0260] 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. For example: TABLE-US-00001
Midnight to 4 am 70% 4 am to 8 am 80% 8 am to 12 pm 90% 12 pm to 4
pm 100% 4 pm to 8 pm 120% 8 pm to Midnight 140%
Day of Week (DW)
[0261] With the heaviest volume of visitors falling on Fridays and
Saturdays, these days will necessitate higher flat rate session
costs. For example: TABLE-US-00002 Monday to Thursday 80% Friday
120% Saturday 140% Sunday 100%
Player Status Rating (PSR)
[0262] For top customers such as high rollers, the cost of a flat
rate session may be reduced as a customer retention tool. For
example: TABLE-US-00003 1 (High Roller) 80% 2 (Good customer) 90% 3
(Average) 100% 4 (Low) 120%
Slot Machine Usage (SMU)
[0263] 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%
[0264] In another example of calculation of a flat rate price, in
addition to the player selected price parameters discussed above,
the following operator selected parameters (also discussed above)
are incorporated into the price: The player is in the casino at 2
a.m. on a Wednesday, there is low slot machine usage, and the
player has an average rating. The calculations below reflect these
conditions: Base .times. .times. Price = $304 .times. .28 ##EQU10##
Final .times. .times. flat .times. .times. rate .times. .times.
price = ( Base .times. .times. Price ) .times. TD .times. DW
.times. PSR .times. SMU = $304 .times. .28 .times. 70 .times. %
.times. 80 .times. % .times. 100 .times. % .times. 80 .times. % =
$304 .times. .28 .times. 44.8 .times. % = $136 .times. .32
##EQU10.2##
[0265] 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 or minimum prices 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.
[0266] Those of ordinary skill in the art will appreciate that
modifications could be made to the exemplary 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 seven
hundred hands per hour while a beginner might only be expected to
reach three hundred hands per hour.
[0267] 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.
[0268] 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 a slot machine. 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
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.
[0269] 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.
[0270] 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.
[0271] 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.
[0272] 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.
[0273] 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.
[0274] 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.
[0275] 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.
[0276] 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.
[0277] 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.
[0278] 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.
[0279] 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.
[0280] 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.
[0281] 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.
[0282] 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 one
hundred plays for the price of 90 or discounted timed sessions. To
encourage repeat, high stakes play, higher player status ratings
result in greater discounts.
[0283] 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, fat rate play commences.
[0284] 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.
[0285] 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.
[0286] 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.
[0287] 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.
[0288] 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.
[0289] 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.
[0290] 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.
[0291] 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.
[0292] 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.
[0293] 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.
[0294] 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 players 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.
[0295] 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.
[0296] 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.
[0297] 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.
[0298] 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.
[0299] 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.
[0300] 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.
[0301] 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.
[0302] 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.
[0303] 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.
[0304] 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.
[0305] 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.
[0306] 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.
[0307] 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 players 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.
[0308] 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.
[0309] 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.
[0310] 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.
[0311] An alternate embodiment of the present invention will now be
described with reference to FIG. 15. The operation of slot machine
102, 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.
[0312] In step 1510, the player presses a "flat rate play" button
on the slot machine 102. 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 102. 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 102.
Alternatively, player interface 264 could incorporate several `flat
rate play` buttons, each representing a different flat rate price
package.
[0313] 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.
[0314] In step 1522, the CPU 210 receives an indication of payment
from the coin acceptor 248 and reconfigures the parameters of slot
machine 102 to meet the specifications of the flat rate price
package selected by the player. Finally, in step 1524, flat rate
play begins.
[0315] 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 102. 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.
[0316] 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.
[0317] 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.
[0318] 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.
[0319] 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.
[0320] 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).
[0321] 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.
[0322] 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.
[0323] 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.
[0324] 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.
[0325] Referring again to the figures, FIG. 16 is a schematic
representation of an embodiment of a system configured to carry out
the contract embodiments described herein. 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.
[0326] 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.
[0327] 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.
[0328] 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.
[0329] 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.
[0330] 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.
[0331] 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.
[0332] 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, a video bingo machine, a video lottery
terminal, a video pachinko machine, or a video blackjack machine. A
combination of these types of machines may be used in embodiments
where casino server 1605 is in communication with more than one
gaming device 1615.
[0333] 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.
[0334] 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.RTM. Pentium.RTM. 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.
[0335] 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.
[0336] 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.
[0337] 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.RTM.; and (iii) a manufacturer 2215 of the
gaming device.
[0338] 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.
[0339] 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.
[0340] 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.
[0341] 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.
C. Example Embodiments for Accelerated Play of a Contract
[0342] According to some embodiments of the present invention, a
player may modify one or more parameters of a session that has
already started or of a contract that has remaining time and/or
plays. For example, a player may have purchased a contract for 600
plays of a video poker game for a flat rate price. The
corresponding game session begins. For example, the player may
initiate the first deal of cards, or as described in this
disclosure, at least some play of the session may be automated
(e.g., does not require input by the player to generate outcomes).
At some point during the corresponding game session (e.g., after
250 hands have been played), the player may opt to modify one or
more parameters of the session, including, but not limited to, the
rate of play and the way in which outcomes are displayed.
[0343] According to some embodiments of the present invention, the
rate of play of a session may be changed. For example, the play may
be expedited or accelerated, or may be decreased. For example, a
player may have provided input to change a rate at which play is
performed. For example, the player may have pressed a "speed up" or
"slow down" button of a gaming device, player device, or other type
of communication device.
[0344] In one embodiment, a player may select an option (e.g., by
actuating an appropriately labeled input device of a gaming
device), such that some portion of a gaming contract (e.g., for
video poker) may be resolved in an expedited manner (e.g., a number
of remaining hands are automatically played in rapid secession or
simultaneously).
[0345] Accelerating play may comprise modifying one or more
parameters of play. In one embodiment, the number of outcomes
displayed and/or generated per handle pull or spin is modified. For
example, in embodiments of the present invention in which a player
may request or initiate game play (e.g., manually by actuating a
spin or deal button of a gaming device) the number of results
displayed at a time upon receiving the request from the player may
be increased. For instance, a player may be playing a session in
which each push of a "Spin" button executes and displays one spin
of a reeled slot machine. When play is accelerated, each push of
the `Spin` button may execute and display three spins (e.g.,
simultaneously or in succession).
[0346] In another example, a player executes an option for
expedited play of a session such that for the next 100 spins,
results are to be displayed four at a time. For example, the player
is offered the option via a corresponding button of a gaming device
or via a message displayed to the player at a gaming device, and
the player accepts the option (e.g., by pressing a corresponding
location of a touchscreen). Accordingly, each time the player
executes a spin by pressing a "Spin" button, four results are
displayed at once. Similarly, if automated play is being used for
the session, the gaming device may display results four at a time
for the next one hundred spins. It will be understood that during
automated play some or all of the outcomes may be generated before
they are displayed. For example, all one hundred spins, or some
portion of the one hundred spins, could be determined before any of
the results are displayed four at a time. The gaming device could
be automatically determining outcomes even while it is displaying
the results of previous outcomes.
[0347] In another embodiment, expediting play may comprise changing
the period of time it takes for an outcome to resolve after a
request (e.g., from a player) or instruction (e.g., automatically
provided by software of a gaming device or server) to generate the
outcome. For example, the period of the animation of a spin in a
video slot machine game may be changed from three seconds to one
second or two seconds. In another example, the animation or other
displayed representation of the resolution of the outcome (e.g.,
the spinning of reels) may be turned off or eliminated completely
(e.g., only the end result may be shown). Some known gaming devices
allow for players to press a Spin button a second time (after
pressing a first time to initiate a spin) to trigger stoppage of
reel animations. Accordingly, by decreasing or eliminating the
duration of presentation of results, some embodiments of the
present invention provide the advantage that a player does not need
to press an input device twice to expedite presentation of a
result.
[0348] According to another embodiment, the time between the
execution of successive handle pulls, spins, deals, or other types
of game plays may be changed. In one example, the time between
spins (e.g., if spins are being executed automatically on the
player's behalf) may be adjusted so that the rate of determination
and/or presentation of outcomes is increased. In another example, a
player executes an option for expedited automated play of a session
such that for the next 100 spins, results are to be displayed four
at a time. The player also adjusts a parameter for the time between
spins to specify that the next four automated results are shown
every five seconds. Accordingly, the gaming device automatically
displays four results at a time (e.g., without requiring the player
to initiate the generation or display of each set of four spins)
every five seconds.
[0349] In another embodiment, the length of time that "resolved" or
final outcomes persist on a display of a gaming device may be
decreased to expedite play. For example, if automated play is
activated, the length of time that a display of a final hand of
cards, a final reel result, or other type of screen persists may be
changed from five seconds to three seconds.
[0350] Thus, it will be understood that in accordance with various
embodiments of the present invention, various types of parameters
related to the generation and/or display of outcomes may be altered
in accordance with expedited play. For example, as discussed above,
any one or more of the following parameters may be changed to
effect expedited or accelerated play: (a) the length of time
between the execution of outcomes (e.g., the frequency with which
outcomes are determined automatically), (b) the length of time
taken to display resolution of game play (e.g., to deal cards, to
show spinning reels), and (c) the length of time that results of
play are represented (e.g., how long a final hand of cards is
displayed).
[0351] FIG. 25 depicts an example display area 2500 that may be
displayed to a player at a gaming device. The display area 2500 may
be useful, in accordance with some embodiments of the present
invention, for allowing a player access to various options and
features of a flat rate play gaming session at a gaming device via
a touchscreen. Various alternative ways of representing the
information in the example display area 2500 will be readily
apparent to those skilled in the art Although display area 2500 is
discussed as being displayed using a touchscreen, it will be
understood that the information and functionality described with
respect to 2500 may be implemented using other types of hardware
(e.g., buttons of a slot machine cabinet) and/or software. Further,
it will be readily understood in light of the present disclosure
that many different types and configurations of information other
than that depicted in example display area 2500 may be presented to
a player at a gaming device.
[0352] Display area 2500 includes a display area 2502 for
information related to automated play of a session and another
display area 2515 for information related to rate of play of a
session. Display area 2502 includes a button 2505 for
activating/deactivating a "Cruise Control" feature and a button
2510 for activating/deactivating a "Walk-Away" feature.
[0353] Display area 2515 includes a button 2520 for slowing down
the rate of play and a button 2525 for speeding up the rate of
play. As described in this disclosure, adjusting the rate of play
may include changing the rate at which outcomes are generated, the
length of time it takes to display the resolution of outcomes, the
number of results that are displayed at once, etc. Fast Finish!
button 2530 allows a player to execute any remaining plays of a
session automatically in an expedited fashion, as described in this
disclosure. Display Options button 2535 allows a player to access
options for how results are displayed. Some specific examples of
display options are discussed with respect to FIG. 26.
[0354] FIG. 26 depicts an example screen 2600 that may be output to
a player of a flat rate play session at a gaming device (e.g.,
after pressing the Display Options button 2535 of FIG. 25). A
display area 2605 indicates the number of spins remaining in the
players session. This information may be useful to the player in
configuring the display of expedited play. The number of remaining
plays may be determined in any of various ways discussed in this
disclosure (e.g., based on whether the session is based on a number
of total plays or an amount of time). Another display area 2610
indicates a parameter for the number of results to display per
screen, and includes a selectable location (e.g., a checkbox) for
indicating that the player wants to have all remaining results
displayed at once. Display area 2610 also includes selectable
arrows for increasing and decreasing the currently selected number
of results to display per screen. Similarly, display area 2615
includes selectable arrows for increasing and decreasing the
selected length of the animation used to depict the resolution of
outcomes (e.g., how long it takes for reels to spin at a video slot
machine).
[0355] Display area 2620 illustrates some examples of different
options for the size and positioning of displayed results. Option
2625 indicates that each of the four results will be displayed in
equal sizes in the indicated pattern. Option 2630 indicates that
one result will be displayed in a larger size above the other three
results, which will be displayed in the cascading pattern
indicated. Option 2635 indicates that all four results will be
displayed in equal sizes in the indicated pattern. In one
embodiment, the gaming device will automatically update the
available size/position options based on the currently selected
number of results to display per screen. Other options and
size/position configurations (e.g., for four or for any particular
number of displayed results) will be readily apparent to those
skilled in the art in light of this disclosure. Button 2640 allows
for any changes or requests of the player to be accepted and/or
saved. In some embodiments, pressing the button 2640 will prompt
the gaming device and/or a server to reconfigure play in accordance
with the selected display options.
[0356] According to one embodiment of the present invention, a
player may specify a number of game plays of a session for which
any of the described alterations should be put into effect (e.g.,
next 100 spins). In an alternative embodiment, the player may
specify a period of time of a time-based session for which
expedited play should be provided. For example, the player may
request that the next five minutes of timed play be accelerated. A
number of plays corresponding to the desired period of time may be
determined as discussed in this disclosure.
[0357] According to another embodiment, any alterations a player
makes or requests may persist until turned off. For example, a
player may enable an accelerated mode that triples the rate of play
by pressing a corresponding button. Play continues at an
accelerated pace until the player presses the button again to
deactivate the accelerated mode.
[0358] According to at least one embodiment, as discussed in this
disclosure, at least two outcomes of a session are generated with
minimal or no delay. According to one embodiment, a player requests
that at least two outcomes of a flat rate play session (e.g., any
remaining plays of a contract) are generated automatically with
minimal or no delay between them.
[0359] According to some embodiments of the present invention, a
flat rate play session associated with a contract is initiated at a
first rate of play. A number of remaining plays is determined, and
the number of remaining plays is performed at a second rate of play
that is faster than the first rate of play. In some embodiments, a
player associated with the contract may request that the remaining
plays be determined at the second rate of play (e.g., by actuating
a corresponding button of a gaming device, such as the Fast Finish!
button 2530 of FIG. 25).
[0360] In one embodiment, all of the remaining plays are determined
substantially at the same time. The determined plays may or may not
be rendered for the player (e.g., by a display of a gaming device).
For example, a player may simply wish to conclude play under a
contract as quickly as possible, receive any winnings, and leave a
gaming device, without viewing any representation of the play
(e.g., displayed hands of poker, displayed results of reel
spins).
[0361] In some embodiments, the results of the plays performed at
the second rate of play may be displayed in a manner selected by a
player. In some such embodiments, the remaining game plays may be
determined substantially concurrently or in very fast succession
(e.g., that would appear instantaneous to a player if they were
displayed as they were generated), but the player may view (or
replay) a representation of the remaining game plays at a desired
pace. In this way, a player may have the option of quickly
resolving remaining plays of a gaming session (e.g., in order to
receive a payout and/or leave a gaming device), while also having
the option to view one or more of the rapidly executed
outcomes.
[0362] In some embodiments, play under a contract may have already
started. In such embodiments, when a player requests that a
contract be resolved rapidly, it may be necessary to determine the
number of game plays to provide. A number of remaining game plays
associated with a contract may be determined in one or more various
manners.
[0363] For example, if the duration of a contract is measured by a
specific number of game plays (e.g., a contract for 200 hands of
video poker), a gaming device may simply subtract the number of
game plays that have already been initiated (e.g., seventy-five)
from the total number of game plays purchased or available to the
player (e.g., 200) to determine the number of remaining game plays
(e.g., 125).
[0364] In another example, if the duration of a contract is
measured in time (e.g., thirty minutes of play), an estimated
number of remaining game plays may be determined based on the time
remaining under the contract. For instance, a player in the middle
of a video poker gaming contract who wants to expedite resolution
of the contract may select a "Fast-Finish" option (e.g., by
pressing a corresponding location of a touchscreen). A number of
game plays may be determined based on the time remaining from the
point at which the player selects the Fast-Finish option (e.g.,
twelve minutes may remain of the thirty minutes purchased).
[0365] In various embodiments, the determined number of plays to be
provided may be based on (i) a predetermined, fixed number of game
plays per unit time (e.g., players requesting Fast-Finish are
automatically rewarded seven poker hands per minute remaining);
(ii) an average number of game plays per unit time based on the
player's rate of play (e.g., if the player averaged five hands per
minute before requesting Fast-Finish, the player may be given five
hands for each minute remaining); (iii) the greater of the fixed
number and the player-specific average number; (iv) a predetermined
number of game plays based on the time remaining (e.g., three hands
if less than two minutes remaining, fifteen hands if time remaining
is between two minutes and five minutes); and so on.
[0366] Accordingly, a player who desires to conclude a gaming
contract before it is scheduled or otherwise likely to finish may
still receive at least an approximate number of game plays that the
player may be entitled to.
[0367] As described above, a player may be able to accelerate play
for any portion of plays or time remaining in his session (not only
the remainder of a session). Thus, embodiments of the present
invention are not limited to finishing all of the remaining play of
a session, but could allow for expedited play of any number of
plays (or any amount of time) of a session.
[0368] According to one or more embodiments, a player may select an
option for how results of spins, handle pulls, or hands will be
displayed (e.g., all at once, five per screen, three seconds per
screen, and so on). The ability to configure display of results may
be advantageous for various types of session play, and may be
particularly beneficial in association with automated play and/or
expedited play of a session.
[0369] Some methods and apparatus allowing for concurrent play of a
plurality of games of chance (e.g., on a single display screen) are
known. Some examples are described in U.S. Pat. No. 6,652,378 to
Cannon et al, entitled GAMING MACHINES AND SYSTEMS OFFERING
SIMULTANEOUS PLAY OF MULTIPLE GAMES AND METHODS OF GAMING,
incorporated by reference in this disclosure. According to some
embodiments of the present invention, where multiple outcomes are
to be displayed simultaneously (e.g., four per screen), a player
may determine one or more various parameters for the displaying of
the multiple outcomes, including, but not limited to, (a) the
display size of each result, and (b) the position of the
results.
[0370] According to some embodiments of the present invention, the
size and/or position of a result may be based on the payout
associated with the result. For example, referring to option 2630
of FIG. 26, the largest payout for any given set of results to be
displayed simultaneously may be shown at the position identified as
"Result 1" (the largest of the depicted results for that
option).
[0371] In another embodiment, the player may select options for how
results are to be displayed, in which the options are based on
whether an outcome is a winning outcome or not. In one example, a
player may be able to indicate a preference for winning outcomes.
In another example, a player may be able to select an option to be
shown only winning outcomes. In another example, the player may be
able to select an option to be shown only outcomes associated with
payouts over a certain threshold or predetermined amount (e.g.,
twenty coins). In yet another example, the player may be able to
select an option such that winners will generally be shown in a
first area (e.g., toward the top of the display screen) and losing
outcomes will generally be shown in a second area (e.g., toward the
bottom of the display screen).
[0372] It will be readily understood in light of the present
disclosure that in some cases, the number of outcomes to be
generated, and the number of results to be displayed (e.g., as
selected by a player), could result in the last screen of a
session, for example, displaying less than the selected number of
results to display. For example, with thirty-seven spins remaining
in a session, a player chooses an option to display four results at
a time. Accordingly, the last screen (i.e., the tenth subsequent
screen) of the session would only have one result to display.
[0373] In accordance with one embodiment, in such circumstances the
final screen of play may be automatically configured to present the
fewer number of results in an optimal manner (e.g., in a way that
is organized and/or graphically pleasant). For instance, referring
to the above example, after the player selects the display options,
each of the first nine sets of four results is displayed on a
screen subdivided into equal quadrants (with one set of reels in
each quadrant). The final result (i.e., the thirty-seventh
outcome), however, is displayed at an expanded size to occupy the
entire available screen.
[0374] The following describes a hypothetical scenario involving
one or more of the embodiments described in this disclosure for
expedited play and display of multiple results, and is presented
for purposes of illustration only. The scenario is not to be
understood as limiting any of the embodiments described in this
disclosure. According to the scenario, a player buys a session of
400 spins. The player begins play and plays the first 100 spins by
executing each game play manually by actuating a "Spin" button. A
single result is presented for each play. The player decides he
wants the next 200 spins played in an expedited manner, but then he
wants the session to return to "normal" play after those 200 spins.
Accordingly, the player accesses a menu that offers options for
expedited play. First he selects a number of game plays for which
play will be expedited (i.e., 200). He then selects an option such
that twenty outcomes will be displayed for each actuation of the
"Spin" button. The player then presses the spin button ten separate
times, and upon each press the slot machine displays twenty
results. After the 200 expedited spins are provided, the slot
machine automatically reconfigures itself to return to displaying
one outcome at a time.
D. Additional Description of Various Embodiments
[0375] According to one or more embodiments of the present
invention, a player who desires to leave a gaming device before a
gaming contract is scheduled or otherwise likely to finish may
possess a variety of options for continuing the contract, pausing
play, accelerating play, or terminating the contract.
[0376] In one or more embodiments, aspects of the present
invention, such as determining or otherwise offering contract
pricing, may be practiced by replacing and/or augmenting one or
more components (e.g., hardware and/or software components) of an
existing gaming device. Thus, in one or more embodiments, the
invention may be applied as a retrofit to existing gaming devices
currently available for play within various casinos.
[0377] For example, a memory (e.g., computer chip) of the gaming
device may be replaced or added, the replacement or additional
memory storing a program for instructing the processor of the
gaming device to operate in accordance with one or more embodiments
of the present invention. In another example, data output via the
gaming device (e.g., graphical and/or textual data displayed on the
gaming device) may be replaced or added, the replacement or
additional data indicating to a player information relevant to one
or more aspects of the present invention.
[0378] In a specific example, a gaming device may comprise various
electronic components mounted to one or more printed circuit boards
(PCBs). Such components may include various hardware described
herein, such as a communications port and various controllers of
peripheral devices (e.g., a display controller), as well as a
memory for storing programming instructions (software) and a
processor for carrying out such instructions. One form of memory
commonly found gaming devices is electronically erasable
programmable read-only memory (EEPROM or EPROM). Thus, in one or
more embodiments of the present invention, an EEPROM storing
contract pricing instructions (as well as instructions for carrying
out other functions performed by the gaming device) may replace an
EEPROM previously installed in a gaming device, such that the
gaming device may be configured to operate in accordance with
various processes of the present invention.
[0379] For example, a "pricing module" may be made available for
purchase to various casino operators. The module, which may
comprise various hardware and software (e.g., an EEPROM storing
software instructions), may be installed in an existing gaming
device (e.g., a video-reel slot machine, a video poker machine,
etc.), such that when the module is installed, players of the
device may elect (i) to play a game offered by the gaming device
without purchasing a flat rate session or contract, or (ii) to play
a game offered by the gaming device by means of purchasing a flat
rate session or contract. Thus, players who are familiar with the
games offered by various gaming devices may elect to pay for them
in a different or similar manner as they are accustomed to. It
should be noted that one advantage of flat rate session play and
gaming contracts (which may be enabled by the installation of the
pricing module) lies in the ability to offer players discounts or
perceived discounts for agreeing to play and/or pre-paying for a
large number of game plays, for a long period of time, etc.
[0380] Accordingly, as described above, a gaming device may be
configured to allow a player to select one of two "modes" of the
gaming device, and to enable the selected mode. If a player selects
a "standard" mode in which a flat rate price will not be received
for a plurality of game plays, the gaming device may be configured
to operate in a manner similar to how it operated before the
installation of the pricing module (e.g., players make funds
available for each game play). If a player selects a "flat rate"
mode and a flat price is paid for the privilege of executing a
plurality of game plays, the gaming device may then be operable to
execute a gaming session or contract play as described herein.
[0381] In one example, a touch-sensitive display screen may be
configured to output a prompt asking a player to select a mode of
operation. Such a prompt may be output in occurrence to various
trigger conditions (e.g., coins, bills or tickets are inserted; a
credit balance increases from zero to some other number; a player
presses a "play" button; a motion, weight, infrared or other sensor
detects the presence of a player; etc.). Accordingly, a player may
select a mode of operation (e.g., by pressing an appropriately
labeled icon of a touch-sensitive display screen), and upon
receiving the players selection, the gaming device may be
configured to operate in the selected mode.
[0382] In other embodiments, a peripheral device may be useful for
implementing one or more embodiments of the present invention into
the operation of a conventional gaming device. For example, in
order to avoid or minimize the necessity of modifying or replacing
a program already stored in a memory of a conventional gaming
device, an external or internal module that comprises a peripheral
device may be inserted in, connected to or otherwise associated
with the gaming device.
[0383] In still further embodiments, rather than configure existing
gaming devices to execute pricing logic by installing or connecting
new hardware and/or software, such pricing logic may be downloaded
into an existing memory of one or more gaming devices. U.S. Pat.
No. 6,805,634 to Wells et al. teaches methods for downloading data
to gaming devices in such a manner. The entirety of U.S. Pat. No.
6,805,634 is incorporated by reference herein for all purposes.
Thus, in some embodiments, an existing gaming device may be
reprogrammed to accommodate new pricing functionality of the
present invention without the need, or by minimizing the need, to
remove and replace hardware within the gaming device.
[0384] As described, in some embodiments, once prices have been
determined in association with various contracts, such contracts
may then be offered to players of gaming devices (e.g., players may
peruse, using a menu output via a touch-sensitive display screen of
a gaming device, various gaming contracts and prices associated
therewith). Thus, an operator may program a gaming device such that
players may review a variety of gaming contracts offered by the
device. In one such example, a gaming device may output or
otherwise display a "rate card," indicating various durations and
wager amounts associated with a price (e.g., 30 minutes of play,
wherein the customer wagers $0.25 per bet, has a retail price of
$30; an hour of play, wherein the player wagers $1 per game play,
has a retail price of $150; etc.).
[0385] In some embodiments, a player may enter into a contract or
otherwise participate in a flat rate play session to play a game
which comprises an initial set of indicia, based on which initial
set of indicia a final set of indicia is determined. In such a
game, a payout may be determined based on whether the final set of
indicia is a winning set of indicia (e.g., whether the final set of
indicia corresponds to a payout in a payout schedule). Further, in
such a game the player may be required or provided with an
opportunity to make a decision or selection based on the initial
set of indicia; the final set of indicia may be determined based on
the player decision or selection. For example, assuming a player is
participating in a flat rate play session of a video poker game,
during play of the game the player may be provided with an initial
set of cards and be provided an opportunity to discard at least
some of these cards. A final set of cards, based on which a payout
is determined, may be determined by replacing any cards that the
player has selected to be discarded. In another example, a reeled
slot machine game (e.g., either a video slot machine or a
mechanical reel slot machine) may output an initial outcome along a
payline as an initial outcome but may be programmed to adjust one
or more of the reels (e.g., by "nudging" a reel or allowing a
player to re-spin a reel) to determine a final outcome. A payout
may be provided based on the final outcome along the payline after
one or more of the reels is adjusted.
E. Conclusion
[0386] Although some of the foregoing embodiments employ slot
machines or video poker machines, it is within the scope of the
present invention to employ other types of gaming devices, such as
video roulette machines, video blackjack machines and the like.
[0387] 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.
* * * * *