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.

Description

CROSS-REFERENCE TO RELATED PATENT APPLICATIONS

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

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

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.

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.

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

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.

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.

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

FIG. 1 illustrates one embodiment of a gaming system according to an aspect of the invention;

FIG. 2 illustrates an example client game device for use with the system of FIG. 1;

FIG. 3 illustrates a block diagram for an example client game device in accordance with FIGS. 1 and 2;

FIG. 4 illustrates another embodiment of the gaming system for a live table game; and

FIGS. 5 and 6 illustrate example flowcharts for inducing wagering in a gaming system.

DETAILED DESCRIPTION OF THE EMBODIMENTS

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.

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.

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.