U.S. patent application number 11/361441 was filed with the patent office on 2006-09-14 for system and method for inducing wagering in a poker-type game.
Invention is credited to Neil D. Nicastro.
Application Number | 20060205484 11/361441 |
Document ID | / |
Family ID | 36992190 |
Filed Date | 2006-09-14 |
United States Patent
Application |
20060205484 |
Kind Code |
A1 |
Nicastro; Neil D. |
September 14, 2006 |
System and method for inducing wagering in a poker-type game
Abstract
A system and method for inducing wagering in a poker-type game
are provided. In one aspect, wagering is induced by providing an
opportunity for game participants and/or spectators to place one or
more side bets on the occurrence of an event during the game. A
payout for each side bet is determined by: 1) detecting the facts,
for example, known by a player, defining a current state of play in
the game; and 2) according to the current state of play in the
game, determining the probability of the event occurrence. In some
embodiments, the side bet may be an insurance bet. In another
aspect, the system and method induce wagering by determining a
player's probability of winning the game and indicating to the
player a potential payout relative to the player's probability of
winning the game. The potential payout may be, for example, an
inverse of a determined probability.
Inventors: |
Nicastro; Neil D.; (Lake
Forest, IL) |
Correspondence
Address: |
GARDNER CARTON & DOUGLAS LLP;ATTN: PATENT DOCKET DEPT.
191 N. WACKER DRIVE, SUITE 3700
CHICAGO
IL
60606
US
|
Family ID: |
36992190 |
Appl. No.: |
11/361441 |
Filed: |
February 24, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60660389 |
Mar 10, 2005 |
|
|
|
Current U.S.
Class: |
463/25 |
Current CPC
Class: |
G07F 17/3244 20130101;
G07F 17/32 20130101; G07F 17/3227 20130101; G07F 17/3293 20130101;
G07F 17/3288 20130101 |
Class at
Publication: |
463/025 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Claims
1. A system for inducing wagering in a poker-type game, the system
comprising: at least one client game device including a user
interface configured to provide at least one card and initiate a
wager request relative to an event; and a game server in
communication with the at least one client game device to receive
the wager request, wherein the game server, substantially
simultaneously with initiation of the wager request, determines a
probability of occurrence for the event relative to the at least
one card and communicates to the at least one client game device a
payout according to the probability of occurrence.
2. The system of claim 1 further comprising a database in
communication with the game server, the database storing a data
structure including a plurality of historical gameplay data entries
relative to a plurality of players.
3. The system of claim 2 wherein the game server further determines
the probability of occurrence for the event relative to at least
one historical gameplay data entry of the plurality of historical
gameplay data entries.
4. The system of claim 1 further comprising a game-state detection
means in communication with the game server.
5. The system of claim 4 wherein the game-state detection means
comprises an optical recognition system including at least one
camera.
6. The system of claim 4 wherein the game-state detection means
comprises an RFID system including an RFID reader and at least one
RFID tag connected to at least one of a plurality of wagering chips
and the at least one card.
7. The system of claim 4 wherein the game-state detection means
comprises a barcode system including a barcode scanner and at least
one barcode connected to at least one of a plurality of wagering
chips and the at least one card.
8. The system of claim 1 further comprising a means for preventing
cheating.
9. The system of claim 8 wherein the means for preventing cheating
comprises an algorithm executing on the game server, and wherein
the game server adjusts the payout according to the algorithm.
10. A method for inducing wagering in a multi-stage poker-type
game, the method comprising: dealing, during at least one stage of
the game, at least one card to at least one player; detecting, at
each stage of the game, an instant state of the game relative to
the at least one card; determining probabilities, relative to the
instant state of the game, for occurrences of a plurality of
events; accepting a wager from the at least one player that at
least one event of the plurality of events will occur; and
determining an outcome of the wager.
11. The method of claim 10 further comprising: constructing a pay
table relative to the probabilities; and providing the pay table to
the at least one player.
12. The method of claim 11 wherein the constructing step further
comprises: accessing at least one data entry of a historical
gameplay data structure; and calculating a plurality of wager
payouts relative to the probabilities and the at least one data
entry.
13. The method of claim 11 further comprising, after the
constructing step and before the providing step: offering to
provide the pay table to the at least one player; requiring payment
of a fee from the at least one player; and determining receipt of
the fee.
14. The method of claim 10 wherein the steps of: a) detecting, at
each stage of the game, an instant state of the game relative to
the at least one card; and b) determining probabilities, relative
to the instant state of the game, for occurrences of a plurality of
events; are performed substantially continuously during each stage
of the game.
15. A method for inducing wagering in a poker-type game having a
plurality of wagering stages, the method comprising: dealing,
during at least one wagering stage of the plurality of wagering
stages, at least one card to a player; determining, at each
wagering stage, an instant probability that the player will win the
game relative to the at least one card; determining, at each
wagering stage, a potential payout according to at least the
instant probability; and indicating to the player, at each wagering
stage, the potential payout.
16. The method of claim 15 wherein the step of determining, at each
wagering stage, a potential payout comprises calculating an inverse
of the instant probability.
17. The method of claim 16 further comprising the step of adjusting
the inverse of the instant probability to provide a predetermined
expected return.
18. The method of claim 15 further comprising: detecting at each
wagering stage an instant state of the game relative to the at
least one card; determining event probabilities, relative to the
instant state of the game, for occurrences of a plurality of
events; accepting a wager from at least one of the player and a
spectator that at least one event of the plurality of events will
occur; and determining an outcome of the wager.
19. The method of claim 18 further comprising: constructing a pay
table relative to the event probabilities; and providing the pay
table to at least one of the player and the spectator.
20. The method of claim 19 wherein the constructing step further
comprises: accessing at least one data entry of a historical
gameplay data structure; and calculating a plurality of wager
payouts relative to at least one of the event probabilities and the
at least one data entry.
Description
CROSS-REFERENCE TO RELATED PATENT APPLICATIONS
[0001] This patent application claims the benefit of U.S.
Provisional Patent Application No. 60/660,389, filed Mar. 10, 2005,
the entire content of which is incorporated herein by
reference.
FIELD OF THE INVENTION
[0002] The present invention relates generally to gaming systems
and methods. More particularly, the invention relates to a system
and method for inducing wagering in a poker-type game such as, for
example, Hold'em.
BACKGROUND OF THE INVENTION
[0003] Casino gaming is currently one of the highest profile growth
industries in the United States. Lured by the opportunity to win
cash, prizes and bulging jackpots, casino gamers wager billions of
dollars annually playing table and electronic games. In an effort
to attract new garners and keep the interest of traditional gamers,
casinos are supplementing their traditional table game offerings
such as Blackjack, Craps, and Roulette with electronic games that
include new, exciting options. Electronic games are now offered in
many forms including slot machines, card games such as draw poker
and Blackjack, dice games, and numerous variations and combinations
of the aforementioned. Electronic games often incorporate unique
lights, music, video displays, and interactive or competitive
elements.
[0004] Advantageously, many electronic games also allow new garners
to learn and practice gameplay aspects of table games such as
fundamentals and etiquette so as to avoid uncomfortable situations,
intimidation or embarrassment during a table game with real people.
For example, an inexperienced Blackjack player sitting at an
"anchor" position of a Blackjack table often receives the
disapproval (and, sometimes, outright hostility) of his or her
fellow players due to "hitting" his or her hand, thereby taking the
card that would have caused the dealer to bust. Such a situation
may have been avoided if the inexperienced player had practiced
playing Blackjack with an electronic game.
[0005] New garners are generally intimidated by casino poker rooms,
which offer games such as Hold'em and other variations of poker,
because the games are competitive and involve adversarial
interaction with other live players. To gain experience and
confidence before playing a live, adversarial poker game, for
example, in a casino poker room, many garners are turning to their
personal computers to play live, networked poker games via various
Internet sites with other live players who are distributed over a
wide geographic area. However, such presently-available Internet
sites have limitations in inducing wagering and keeping gamers'
interest, particularly during downtime periods during the game,
such as, for example, when a player folds. A system and method that
overcame such limitations would be an important improvement in the
art.
SUMMARY OF THE INVENTION
[0006] The disclosed system and method provides for improved user
experience in connection with poker-type games. In one aspect, the
present system and method are applied to a live, traditional (i.e.,
non-banked) poker-type game that may be played at a casino game
table, over a casino communication network via a plurality of
electronic gaming machines or over the Internet via personal
computers or the like. In one embodiment, the system and method
induce wagering by providing an opportunity for game participants
and spectators to place one or more side bets on the occurrence of
an event at various stages of the game. A payout for each side bet
is determined by determining the current state of play in the game,
for example, by determining facts known to one or more players
and/or spectators at an instant of the game and, according to the
current state of play in the game, determining the probability of
the event occurrence.
[0007] In another embodiment, the system and method induce wagering
by offering an insurance side bet to a player, the bet helping the
player to recover at least a portion of his or her wagers if the
player loses in the game. In this embodiment, determination of an
insurance premium and insurance bet payout for a player desiring to
place an insurance side bet may be based on determining the current
state of play in the game, for example, determining facts known to
that player desiring to place the insurance side bet, and,
according to the current state of play in the game, determining the
probability of the player losing. Optionally, to make the insurance
premium a more attractive wager, the insurance premium may
additionally be determined according to one or more behavior
profiles or models of one or more other players participating in
the game. The behavioral model may be based on a generalized
profile of the behavior of players of the game or an individualized
model of a specific player's behavior based on historical data of
the player's past plays.
[0008] In another aspect, the present system and method are applied
to a banked or non-banked, stand-alone or networked video
poker-type game. In an embodiment, the system and method induce
wagering by determining a game payout according to the probability
of winning the game that is determined at each stage of the game,
and indicating that payout to the player. For example, the game
payout may be determined to be the cumulative inverse of a winning
probability at each betting juncture or opportunity. Thus, the
method and system disincline a player from folding and instead,
keep a player interested and wagering in the game, particularly if
the player has an extremely low probability of winning.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] FIG. 1 illustrates one embodiment of a gaming system
according to an aspect of the invention;
[0010] FIG. 2 illustrates an example client game device for use
with the system of FIG. 1;
[0011] FIG. 3 illustrates a block diagram for an example client
game device in accordance with FIGS. 1 and 2;
[0012] FIG. 4 illustrates another embodiment of the gaming system
for a live table game; and
[0013] FIGS. 5 and 6 illustrate example flowcharts for inducing
wagering in a gaming system.
DETAILED DESCRIPTION OF THE EMBODIMENTS
[0014] Referring now to the Figures, an example system for inducing
wagering in a poker-type game is provided. As shown in FIG. 1, one
embodiment of a gaming system 100 includes a game server 110, a
game database 120, a game network 130 and a plurality of client
game devices 140, 150, 160 labeled "Game Computer 1" through "Game
Computer N." Although the example gaming system 100 is illustrated
as a client-server type system, it should be appreciated that the
gaming system 100 may be configured otherwise, for example, as a
peer-to-peer or ad hoc system. As shown, the client game devices
140, 150, 160 are in communication with the game server 110 via the
network 130. Although only three client game device 140, 150, 160
are illustrated, it should be appreciated that fewer or additional
client game devices may be provided. The network 130 may be any
type of network known in the art including wired and wireless
networks, a local area network (LAN), a wide area network (WAN), a
virtual private network (VPN), the Internet or the like. Each of
the client game devices 140, 150, 160 communicates with the game
server 110 and database 120 via the network 130 to provide a user
of each client game device 140, 150, 160 with a live (i.e.,
real-time), multiple-player, non-banked poker-type game, such as
Hold'em, for example. Hereinafter, the following terms: user,
gamer, player, game participant, and participant are used
interchangeably to refer to an individual playing the game via the
gaming system 100.
[0015] As known in the art, a non-banked poker-type game, for
example, a poker table game, is a game where a plurality of
participants pool their wagers into a "pot" so that the winner
takes all, generally less a fee for the house. Alternatively,
banked poker, such as is played on an electronic video poker
machine, is a game where a participant wagers against the house
that the participant will achieve certain posted winning card
combinations listed on a pay or payout table. Casinos profit from
non-banked poker by charging a rental for the use of the table or
by taking a percentage of the winning pot, whereas in a banked
poker game the house is the book or odds-maker and establishes the
odds for a game to be less than a statistical 100% (e.g., 98%) to
profit by that variance without overly frustrating the player.
Although there has been a marked increase in interest among the
general public to play non-banked poker games against other live
players, for example, as evidenced by the popularity of the
numerous poker tournament shows currently on TV, many beginner and
novice players find live poker table games to be too intimidating.
To this end, the example gaming system 100 of FIG. 1 obviates the
potential for player intimidation and apprehension. Furthermore,
the example gaming system 100 employs a method for inducing
wagering such that the game operator (i.e., house) keeps gamers'
interest thereby deriving additional revenue.
[0016] The client game devices 140, 150, 160 may be configured
within one location (e.g., a casino) or throughout many
geographically separated locations (e.g., a number of casino
properties) to permit gamers to play against other people located
within the same casino or distant casinos without having to be at
the same table. Use of client game devices 140, 150, 160 provides
anonymity to players to alleviate adversarial interaction with
other players during the game. One example client game device for
use in the gaming system 100 is illustrated in FIG. 2. As shown,
the client game device is embodied as a typical video draw poker
machine 200 and includes an informational display module 210, a
card display module 220, an actuator module 230 for controlling
play of the game, a start button 240, a coin and bill acceptor
module 250, and a credit/debit card and player card acceptor module
260. In some embodiments the machine 200 may include a ticket-in
ticket-out module in addition to or as an alternative to at least
one of the modules 250 and 260. The display modules 210, 220 and
actuator module 230 provide a user interface for the player to
interact with other game participants of the game system 100. As
can be appreciated, the informational display module 210 may be any
type of display known in the art, for example, a CRT, LCD panel,
LED array, etc. configured to display information about the game
being played. For example, the informational display module 210 may
show information relative to other players (e.g., player notes),
play statistics, pay tables, wagers (e.g., including any side bets
and insurance bets), etc. Furthermore, the card display 220 may be
any type of display known in the art and, moreover, may be separate
or integral with the informational display module 210. As shown,
the card display module 220 is configured to show the rank and suit
of five player cards, but may be configured to show fewer or
additional cards. For example, depending on the poker variation
being played, the card display module 220 may be configured to
distinguish between: 1) up and down cards dealt to the user of the
machine 220 and up and down cards dealt to other players; and 2)
down (i.e., hole) cards dealt to the user of the machine 220 and
common/community cards.
[0017] As illustrated, the actuator module 230 includes five
buttons, which may be used in a draw poker game for holding and
discarding one or more cards, but the actuator module 230 may
include fewer or additional buttons. Indeed, the actuator module
230 may additionally or alternatively include a keyboard, mouse,
joystick, joypad, trackball and other user input devices known in
the art. As can be appreciated, other machines may include, for
example, a touch-sensitive screen interface for the displays 210,
220 and actuator module 230. In other embodiments, the client game
devices may be personal computers, personal digital assistants
(PDAs), wireless phones or any suitable electronic device that
include a user interface to interact with other game participants
and a communication interface to communicate with the game server
110.
[0018] Turning now to FIG. 3, a block diagram for an example client
game device, for example, the video poker machine 200 of FIG. 2 is
provided. As shown in FIG. 3, the client game device includes a
game client computer 300, a user input module 320, a network
interface module 340, a card reader module 360 and a currency
module 380. The client computer 300 comprises a processor 302, a
memory 304 storing, inter alia, a game program that is executed by
the processor 302, a random number generator (RNG) 306, a clock 308
and a display driver 310. The processor 302 may be an integrated
circuit (IC) microprocessor, microcontroller or the like that is
known in the art. The memory 304 may be integral with or separate
from the processor 302 and may comprise one or more types of
memory, for example, RAM, ROM, EEPROM, etc. The RNG 306 may
communicate with the processor 302 to determine one or more of
player cards and community cards that are dealt during a game. The
clock 308 may communicate with the processor to facilitate
communication with one or more other client game devices and the
game server 110. The display driver 310 communicates with the
processor 302 and is configured to interface with a display device
(e.g., FIG. 2, modules 210, 220) to display information relative to
the game being played and the like. The data input module 320 as
shown includes inputs 322-332 that may be actuated by the user for
the purpose of controlling gameplay (e.g., wagering, folding,
discarding/selecting cards, selecting options, etc.) The inputs
322-332 may be hard or soft buttons and fewer or additional inputs
may be provided according to the game being played. A network
interface module 340 is in communication with the processor 302 for
interfacing the client game device with the game server (e.g., game
server 110, FIG. 1) and/or other client game devices (e.g., client
game devices 140, 150, 160, FIG. 1). The network interface module
340 may facilitate communication via any suitable communication
protocol, for example, TCP/IP, X.25 and other protocols known in
the art.
[0019] As further shown in FIG. 3, the card reader module 360
includes a card reader 362 configured to accept a wager-funding
source such as a credit, debit or bank card, and a player card
reader 364 configured to accept a player-identifying card such as a
player's club card issued by one or more casinos. Although two card
readers 362, 364 are provided, fewer or additional card readers may
be provided, as can be appreciated. Moreover, the currency module
380 includes a hopper controller 382, a hopper 384 and a currency
acceptor 386. As known in the art, the hopper controller 382
controls operation of the hopper 384, which is an electromechanical
device that sorts, holds and releases coins, in response to
communications received from the processor 302. The currency
acceptor 386 may be configured to receive one or more of paper
bills and coins to fund the player's wagering. As should be
appreciated, the block diagram of FIG. 3 merely illustrates
components of one example client game device and is not to be
construed as limiting to the system and method herein. For example,
as previously stated, some embodiments of the computer 300 may
include a ticket-in ticket-out module, in addition to or as an
alternative to at least one of the modules 360 and 380. As
mentioned previously, a client game device may minimally include a
user interface and a communication interface. For example, one
embodiment of the system may be substantially similar to
Internet-based poker games. In some embodiments, the network may
also facilitate and automate the operation of poker tournaments or
the like.
[0020] As shown in FIG. 4, in one embodiment, the present game
system for inducing wagering may be applied to a traditional gaming
table and live table game. As discussed hereinafter in further
detail, the gaming table 400 of FIG. 4 may include various data
collection means known in the art configured to collect game data
or facts (e.g., player down cards, community/common card, wagers, a
player's available wager funds, etc.) relative to each game
participant's game play and/or behavior. For example, as shown, the
gaming table 400 may include a camera 420 so that the system 100
may employ optical recognition processes to identify one or more of
the game participants, cards and chips at the table 400.
Alternatively or additionally to the illustrated camera 420, other
game-state detection means may be provided, for example, a radio
frequency ID (RFID) reader for reading RFID tags configured on or
in chips and cards, a barcode scanner for scanning barcodes on
cards and chips, etc.
[0021] In one aspect, the present system and method for inducing
wagering are applied to a non-banked game wherein a casino operator
may realize revenue from the client game devices in either the
traditional manner by charging a rental fee and/or by taking a
percentage of the winnings. Furthermore, the casino operator may
realize additional revenue by offering each player an opportunity
to place one or more side bets. In this way, the casino or game
operator can offer banked gaming opportunities (e.g., sport book,
jackpots, etc.) to participants and/or spectators simultaneously
with the non-banked game that is being played. For instance, before
or during the non-banked game a player (or spectator) may want to
make a side bet that an "event" will occur at an instance during
the game. Herein, an event may include the following occurrences: a
player wins, a player loses, a player folds, a player makes a
particular hand (e.g., relative to a video poker pay table), a
player receives one or more particular cards, and the like. A pay
table that is offered to the side bettor relative to the side bet
is constructed based on: 1) one or more of the game server 110
(FIG. 1) and client game devices 140, 150, 160 (FIG. 1) determining
facts relative to the current state of play in the live game, for
example, facts known to one or more players and/or spectators; and
2) according to the facts, calculating a probability for the event
to occur. Pay out to the side bettor is determined by the outcome
of live play in the game. It should be appreciated that pay tables
herein are not static and/or predetermined, for example, selected
or otherwise constructed before the start of a game. Rather, pay
tables vary dynamically from player to player (and spectator to
spectator) and from bet to bet since the facts are constantly
changing during the game and a construction of a pay table by the
system 100 (FIG. 1) is a one-time action, occurring substantially
simultaneous and instantaneous with the player making the side bet
according to a probability that is calculated relative to facts at
an instant of the game.
[0022] In one embodiment an example method for offering side bets
to game participants by the game system is illustrated in the
flowchart of FIG. 5. As shown in FIG. 5, the game starts at block
502 where one or more players identify themselves and become
registered by the system to play the game. Players may register
with a player's club card, by entering a user identification number
and/or password/PIN or in other ways known in the art. At block
504, before the game commences with the dealing of cards, the
players may initially be offered a side bet payout table and the
opportunity to make a side bet on the occurrence of an event, which
may be separate from the ultimate outcome of the game. By offering
an opportunity to a player to make a side bet, the system may
generate a query, probe or reminder after which the player may
accept or decline the opportunity. Alternatively, one or more
players may actively make a side bet, for example, relative to the
various facts known by each of the one or more players by
requesting a pay table for an event occurrence. If one or more
players make a side bet, the cards are dealt to the players in
block 506. At block 508, the system detects the facts of the game
at that instant and determines if the event has occurred. The
system may, at this time, pay out winnings to a side bettor if the
event has occurred. Depending on the event that is selected as the
subject of the side bet, the event may not have yet occurred,
particularly during a multi-stage wagering game such as draw and
stud poker variations. Thus, the game continues at block 510. At
block 520, the system determines if the game has ended or, for
example, if another stage (e.g., card-dealing and/or wagering) of
the multi-stage game is commencing. If a winner of the game has
been determined according to the dealt cards, the game ends at
block 522 and the winner is paid. All losing side bets are
forfeited and collected by the game operator. All winning side bets
may be paid if they have not already been paid earlier, for
example, at the determining block 508.
[0023] Alternatively, at block 520, if the game has not ended and
another game stage is commencing, at block 518 the system may offer
opportunities for one or more players to make side bets. Of course,
as previously discussed, the payout tables for side bets at this
instant will differ from previously offered payout tables, even if
the same side bet is being made since the facts of the game, for
example, known to the side bettor, change as the game progresses
and, therefore, are different at block 518 than at block 504. The
system constructs the side bet payout table based on a calculation
of the probability of the event occurrence, which is the subject of
the side bet, relative to the facts of the game, for example, known
to the side bettor, at that instant. After making a side bet at
block 518, at least one additional card may be dealt at block 506
for the new game stage. Again at block 508 the system detects the
facts of the game at that instant and determines if the event has
occurred. The system may, at this time, pay out winnings to a side
bettor if the event is determined to have occurred. Depending on
the event that is selected as the subject of the side bet, the
event may not have yet occurred, and the game continues at block
510. At block 520, the system determines if the game has ended or,
for example, if another stage (e.g., card-dealing and/or wagering)
of the multi-stage game is commencing. If a winner of the game has
been determined according to the dealt cards, the game ends at
block 522 and the winner is paid. If at block 518, one or more
players decline the opportunity to make a side bet, the system
deals additional cards at block 512. Next, at block 514, the system
detects the facts of the game at that instant and determines if one
or more events that are the subjects of one or more side bets have
occurred. The system may, at this time, pay out winnings to one or
more side bettors if events are determined to have occurred. Again,
depending on the event that is selected as the subject of the side
bet, the event may not have yet occurred, and the game continues at
block 516 with the offering to one or more players of another
opportunity to make side bets. If additional side bets are made at
block 516, additional cards may be dealt at block 506.
[0024] As can be appreciated, the system and method herein induce
wagering by offering multiple opportunities for players and/or
spectators to place one or more side bets during the course of the
game. Players may be induced to place a side wager, for example, on
a "long-shot" event occurrence because the payout for such an event
is high since the probability of the event occurring that is
determined by the system may be extremely low. Thus players may bet
small sums multiple times with the low expectation of winning such
that the game operator realizes additional revenue from the side
bets. Of course, the illustrated flowchart steps that may be
performed by the game system may be performed in a different order.
Indeed, other processing steps may be included or substituted for
the illustrated steps according to the state of the game, side bet
that is being offered, player behavior and other aspects of the
game.
[0025] Furthermore, as can be appreciated, if a player is placing a
side bet relative to his or her hand, the pay table may differ from
when other players or spectators bet on that player's hand since
the player has knowledge of his or her cards (i.e., particularly
face-down cards), or the spectator may have knowledge of other
players' face down cards. Further, the pay table for a side bet
will vary dynamically from player to player (and spectator to
spectator) and bet to bet, according to the facts that define the
state of the live game. That is, for example, if a player is dealt
a pair, that player will not be allowed to place a side bet on
having a hand with one pair. Further, that same player's pay table
may reflect a significantly lower payout for a hand with
three-of-a-kind since there is a greater probability (1 in 13 if
playing with a single deck) of achieving three-of-a-kind while
holding a pair. Moreover, spectators' pay tables may differ from
the players pay tables (e.g., provide higher payouts) since the
spectators have no control over the game outcome. When a player or
spectator wishes to place a side bet prior to the deal (e.g., at
ante), the pay table for the side bet may be substantially similar
to a known table, such as for video poker (e.g., pair of jacks or
better). Furthermore, a player may also want to bet against the
house that, irrespective of whether the player wins the hand
against the other players, the player will achieve a winning hand
against a posted pay table like in banked poker games. Moreover,
side bets may include the opportunity to win a progressive jackpot
prize.
[0026] Turning now to FIG. 6, in another embodiment, one or more of
the side bets may be an insurance bet such that in the system and
method for inducing wagering, each player may be offered the
opportunity to purchase insurance on his or her hand at a given
point of a live game. In this way, one or more players may be
induced to not fold, remain in the game and continue wagering even
though the players' hands are not promising. One aspect of the
insurance offering will essentially protect the player against
ultimately losing the game. One example method for inducing
wagering by offering insurance to game participants is illustrated
in FIG. 6. Of course, the illustrated processing steps that may be
performed by the game system may be performed in a different order.
Indeed, other processing steps may be included or substituted for
the illustrated steps according to the state of the game, insurance
that is being offered, player behavior and other aspects of the
game. As shown in FIG. 6, the game starts and at block 602 one or
more players identify themselves and become registered by the
system to play the game. Players may register with a player's club
card, by entering a user identification number and/or password/PIN
or in other ways (e.g., ticket-in ticket-out) known in the art. At
block 604 the system determines if a registered player has a
profile, for example a data structure stored in the database 120
(FIG. 1), that describes one or more of a player's historical
gameplay and behavior. If the player does have a stored profile,
the stored profile is retrieved at block 606. Alternatively, if the
player is new, for example, and does not have a stored profile, a
player profile is initiated with default or generalized values for
that player in block 608. At block 610, the system starts recording
or otherwise storing actions, gameplay and behaviors of each play
to that player's profile.
[0027] At block 612, the game system deals the player card and any
community/common cards. At block 614 the game system may, according
to facts at that instant, the fact being one or more of the dealt
cards known by a player (down cards), community/common cards (and
any undealt cards), determine the probabilities of each player
winning the game. Relative to the winning probabilities, the system
may then, in block 616, construct an insurance premium/payout
table. In some instances, which will be discussed in further detail
below, the system may additionally calculate insurance premiums
according to one or more profiles of other players in the game to
make the premium more attractive to a player. For example, a player
may have a recurring tendency or behavior to raise his or her wager
at a particular instance of the game that corresponds with that
player's attempt to bluff his or her fellow players. Such a
recurring tendency or behavior may be captured in the player's
profile and used to adjust the winning probability and premium
calculations for other players. In the aforementioned example with
one player having a tendency to bluff fellow players, insurance
offerings to that player's competitors may have lower premiums
since it may be more likely that the bluffing player has a low hand
(or no hand at all). Next, in block 618, the players may be offered
a side bet that is an opportunity to make an insurance bet on the
occurrence of an event, which is game outcome of a player
ultimately losing the game. By offering an opportunity to a player
to make an insurance side bet, the system may generate a query,
probe or reminder after which the player may accept or decline the
opportunity. Alternatively, one or more players may actively
initiate the insurance side bet, for example, by requesting a pay
table, insurance quotation or premium. If the player declines the
insurance bet at block 618, the game continues in block 620, for
example, with additional card-dealing and/or wagering stages in a
multi-stage wagering game such as draw and stud poker variations.
At each stage of the game, the system may again, according to the
facts of the game at that instant, the facts being one or more of
the down cards known to a player, community/common cards (and any
undealt cards), determine at block 622 the probabilities of each
player winning the game. Relative to the winning probabilities, the
system may then, in block 624, construct an insurance
premium/payout table. At block 626, the system determines if the
game has ended or, for example, if another stage (e.g.,
card-dealing and/or wagering) of the multi-stage game is
commencing. If the system determines that the game has ended at
block 626, the system stops recording player behavior and the
winner is paid in block 628. Furthermore, at block 628, any losing
players making an insurance bet are at least partially compensated
by the system according to the insurance premiums that were
paid.
[0028] Alternatively, in block 618 if the player accepts the
insurance offer, the player then pays the insurance premium in
block 630. Next, the game play continues in block 632, for example,
another stage of the multi-stage game. At each stage of the game,
the system may again, according to the dealt cards,
community/common cards (and any undealt cards) determine at block
634 the probabilities of each player winning the game. Relative to
the winning probabilities, the system may then, in block 636,
construct an insurance premium/payout table. At block 638, the
system determines if the game has ended or, for example, if another
stage (e.g., card-dealing and/or wagering) of the multi-stage game
is commencing. If the system determines that the game has ended at
block 638, the system stops recording player behavior in block 640
and the winner is paid. Furthermore, at block 642, any losing
players making at least one insurance bet are at least partially
compensated by the system according to the insurance premiums that
were paid. Although opportunities for players to make other side
bets, for example, according to FIG. 5, are not shown, such side
bet opportunities including probability calculations and payout
table construction may be included in the method of FIG. 6 as
well.
[0029] As can be appreciated, after receiving an insurance
offering, a player can then choose whether to pay the insurance
premium, which will provide for recovery of at least a portion of
that player's wagers in the game. The player may be offered
insurance at each round of play with the premium at each round of
play being based at least on the facts, for example, known to a
player, defining the current state of play in the live game. For
example, if a player is dealt a hand that is one card away from a
straight, but has doubts of achieving the straight, then the player
may be offered or request a quote for insurance based on at least
the probability of obtaining the straight to win the game. Since
such an insurance premium quote may provide some indication to the
player of the likelihood of the player winning at the current state
of play, the system and method may be configured to charge the
player a fee to obtain the insurance premium quote. After paying a
fee to receive the quote, the player can then opt to obtain
insurance (i.e., pay an insurance premium) from the house based on
that probability chart so that any subsequent losing bet during
that hand would be reimbursed. Once the insurance premium is paid,
the player may, in some embodiments, need to continue to pay the
premium in each subsequent stage of the game to ensure an insurance
payout. In another embodiment, the player may discontinue paying
the insurance premium at a stage of the game and receive a partial
insurance payout based on the stages of the game that were insured.
In one embodiment, the system determines the likelihood of the
player ultimately winning the hand based on probability
calculations relative to the facts known to the player at that
point of play in the game and charge an insurance premium for the
surety. However, in another embodiment, the system determines the
likelihood of the player ultimately winning the hand based on the
probabilities calculated from the current state of play in the game
combined with a behavioral model for the other players'
behavior.
[0030] As known in the art, a behavioral model may be based on a
generalized model of player behavior playing the given game.
Alternatively, the behavioral model may be based on an individual
model of behavior for a specific player based on that player's
history of play for the given type of game or for the current game.
In still another alternative, both the generalized model and
individual models for the other players in the live game are used
to determine the insurance premium. Different weights may be
applied to the general model and the individual model or models and
the different weights may be based on the amount of historical data
used to form the individual models. Historical data on play for a
specific player is stored in a database in order to build the
individual model. The different weights may be varied over time as
the amount of historical data for a specific player increases.
[0031] As noted above, the insurance quotation/premium can be
determined in one or more various ways. In one embodiment, the game
server or client game device determines an insurance premium
strictly on the basis of a mathematical calculation of odds based
on each player's cards. In other embodiments, the game server
determines an insurance premium for a particular player based on a
behavioral model or profile for that player's competitors. A
behavioral profile for each player may either be a generic profile
or an individual profile. A generic profile generally describes the
gameplay of a typical player that is determined by, for example,
gameplay data collection of all historical players by the game
server. An individual profile may describe trends in an
individual's gameplay that differ from a generic profile. For
example, a player may have a recurring tendency or behavior to
raise his or her wager at a particular instance of the game that
corresponds with that player's attempt to bluff his or her fellow
players. Such a recurring tendency or behavior may be captured in
the player's individual profile and used to adjust the insurance
odds and premium calculations for other players. In the
aforementioned example with one player having a tendency to bluff
fellow players, insurance offerings to that player's competitors
may have, for example, lower premiums since it may be more likely
that the bluffing player has a low hand (or no hand at all). In
some instances data collection of a player's gameplay by the game
server may adapt a generic profile over a period of time to better
fit the player's actual gameplay behavior. Individual profiles may
be stored in the database 120 illustrated in FIG. 1 and retrieved
by the game server 110 and/or client game devices 140, 150, 160 for
the purpose of constructing pay tables, calculating insurance
premiums and the like. Additionally or alternatively, player
profiles may be stored in the memory 304 (FIG. 3) of a client game
device. Insurance premiums, payout tables, etc. may be calculated
based on a weighting of the aforementioned generic profile,
individual profile and mathematical probability calculation at an
instant during the game. In some embodiments, the insurance
premium, probability and payout tables may be based on or otherwise
affected by pari-mutuel factors (e.g., how players and/or
spectators are betting, what types of side bets the players and/or
spectators are placing, etc.)
[0032] Although the illustrated embodiment provides a system
offering the computerized gambling play and calculating the odds
and payouts with distributed, networked computers for use by the
live players and a server, the exemplary methods described herein
may indeed provide substantially similar gameplay features (e.g.,
side bets and insurance) to players at a live gambling table. Data
collection regarding the state of play may be manually entered or
derived from, for example, bar code readers that read bar codes
from the cards dealt, radio frequency identifying transponders/tags
implanted in the cards, optical character recognition using cameras
to determine which cards have been dealt or similar means of
automated data collection known in the art or may be developed in
the art. Further, as can be appreciated, player behavioral data
regarding the players in the game can be collected in a live game
in the same way. Thus, the dealer and/or game data collection means
could make a calculation of odds at each stage of play and factor
in the behavioral history of the other players in determining a
premium to offer a given player.
[0033] Collection of historical data regarding players may be
accomplished in a number of ways. For example, a player identifier
may be included in at least one message from a client game device
to the server in a networked game. Alternatively, an identifier for
the client game device (e.g., a network address, machine ID, or the
like) may be utilized to collect historical data for a given
session of play in a networked game and the client identifier used
to identify the player for that session. Facial recognition
technology may be utilized to identify players using cameras in a
live game. Further, other biometric techniques known in the art
(e.g., fingerprint or retinal scanning) may also be used to
identify a specific player. Other techniques currently known to
those of skill in the art may be used to obtain such player
identification data and other techniques may arise.
[0034] In another aspect, the system and method for inducing
wagering may be applied to a banked, stand-alone (e.g., video
poker) or networked game. In an embodiment, a multiple-stage poker
game with wagering at each stage (e.g., Hold'em) is provided
wherein a winner does not win the "pot" comprising wagers from the
game participants, but rather receives a game payout that is
determined according to the probability of winning the game at each
stage of the game. For example, if the probability of a player
winning the hand at a given bet juncture (e.g., after the "flop")
is 2%, the potential payoff for that player at that particular bet
juncture may be 50 (the inverse of 2%) credits, dollars, etc. If
the player bets at that juncture and subsequently wins the game,
the player is paid 50 credits, dollars, etc. relative to that bet
juncture. The total winning payout for a game may be determined
according to the inverse probability determined at each bet
juncture. For example, the total winning payout may be the sum of
the plurality of determined inverse probabilities. Of course, the
total winning payout for a game need not strictly be the
cumulative/accumulated (i.e., sum of) inverse probabilities, and,
in some embodiments, may be adjusted to be slightly less (e.g.,
multiplied or divided by a fractional or decimal value) to vary
(e.g., increase) the expected return for the game operator. In an
example Hold'em game with six players, a player's first bet is the
ante and the player's probability of winning the game is 1 in 6.
Thus, the payoff relative to the first bet for the player would be
6. The two "hole" cards (i.e., player down cards) are dealt and the
player bets again with the payoff for this bet juncture being the
inverse of the probability that a hand with those hole card will be
the best hand of the six players. The 3 "flop" (i.e.,
common/community) cards are displayed and the player bets
again--the probability for this bet juncture being calculated
relative to the player's hold cards and the flop cards (i.e., what
is the probability that the player's hand with those community cars
will be the superior winning hand). This methodology continues at
all bet points. The better a player's hand is at each
card-dealing/betting stage of the game, the lower the payoff. For
example, a player that achieves a royal flush as a hand relatively
early in the game has a near 100% chance of winning and, therefore,
will receive a payout of about I to 1 at the bet junctures
subsequent to achieving the royal flush. The weaker a player's hand
is at each stage, the higher the payoff. Thus, by offering a high
payout for a low probability of winning, many players who would
otherwise fold due to having a poor hand may now be induced to not
fold, stay in the game and continue wagering.
[0035] Various methods for preventing cheating during a game may be
provided. Cheating in the various embodiments may be in the form of
player-spectator or player-player cooperation/collusion and the
like known in the gaming art. To this end, the system and method
may provide a means that prevents players and/or spectators from
identifying each other. Other cheat prevention means may include
the game system running one or more various algorithms known in the
Internet poker art, modifying pay table construction and/or
insurance premium calculations according to random or pseudo-random
variables relative to one or more players' gameplay, inconsistent
offering of side bets and insurance to one or more players relative
to a random or pseudo-random variable and other techniques known in
the art. The system may prevent the offering of insurance or other
side bet to a player based on the detection of player collusion.
Alternatively, the system may randomly or pseudo-randomly prohibit
the offering of insurance or bets to disrupt collusion and deter
cheating.
[0036] While the invention has been illustrated and described in
detail in the drawings and foregoing description, the same is to be
considered as illustrative and not restrictive in character, it
being understood that various exemplary embodiments have been shown
and described and that all changes and modifications thereto that
come within the spirit of the invention are desired to be
protected. Although the present system and method are described
herein in the context of a poker-type game, it should be understood
that the present system and method may be applied to other card
games such as, for example, blackjack, dice games, and other types
of competitive games as well.
* * * * *