CA2929334A1 - A method and system for providing interactive off-table betting on games - Google Patents

Abstract

A method, system and related program and user interfaces are provided for facilitating dynamic and interactive off-table betting by observers via their computing devices on live and real-time card games on a hand-by-hand basis. An Off-table cloud manager system is configured to present to the observers' computing devices displays, at predefined times during the live game, the odds for each player in improving and winning their hand such that observers can place bets thereon via their computing devices. The bets are managed via the off-table cloud manager system which communicates via secure communications to the house where the game is played. There exists synchronization between the observer computing devices and the dealer tablets.

Description

A Method and System for Providing Interactive Off-Table Betting on Games FIELD OF THE INVENTION
[0001] The present invention relates generally to a method and system for facilitating dynamic and interactive off-table betting with live and real-time card games, such as Poker games, and the individual players.
BACKGROUND OF THE INVENTION

[0002] Currently, betting systems for card games offer several disadvantages.
First, there exist online betting systems which take wagers on live Poker games, however the wager is accepted on the overall tournament outcomes and the observers placing the bets are not involved during the various stages of the game.
Additionally, the existing wagering tools offer derivative betting in an online environment such that there is minimal control available for wagering on the outcomes of on-line games. For example, there is potential of collusion such that a player could be presenting themselves as both a player and an observer placing bets, thereby cheating the system.

[0003] Accordingly, it would be desirable to provide an interactive and dynamic off-table betting tool that allows wagering on games such as Poker, Blackjack, Craps, Roulette or any other house game. Additionally, it would be desirable for the dynamic off-table betting tool to allow observers to interact with and place wagers at various defined intervals throughout the game while the game is being played and with minimal interruptions to the game while avoiding collusion issues.
SUMMARY

[0004] Accordingly, there is provided a system and method for providing off-table betting of a live real-time game played by a plurality of players and associated dealer to observers via their computing device physically located externally to the game being played, the method comprising providing real-time video streaming of the game as it is being played to each observer's computing device; detecting the cards being played at each hand via a plurality of RFID readers each associated with each player's computing device and communicating the cards to each observer's computing device via secure messaging means; calculating and presenting odds to each observer's computing device and observer's user interface after a hand is played and in real-time, and, following a pre-defined amount of time, requesting and receiving wagers in real-time for each hand being played from each observer's computing device provided by the corresponding observer; and presenting notification messages on a dealer user interface of the dealer's computing device for delaying the game for the pre-defined amount of time thereby allowing wagers to be received.

[0005] In some aspects, the wagers can be received in real-time based on the odds for each player's hand improving and winning. In other aspects, each observer can be authenticated against a database of credentials for determining whether a wager can be received from the observer. In yet another aspect, the observer computing device and the dealer computing devices can be synchronized. The game event data can be delayed for a determinant amount of time to align to the video stream. In still other aspects, the real-time video streaming can be paused for the pre-defined amount of time. In still further aspects, further receipt of wagers subsequent to the expiry of the pre-defined amount of time can be denied.
BRIEF DESCRIPTION OF THE FIGURES

[0006] Figure 1 depicts components of the off-table betting system architecture including at least one graphical user interface for interacting with an observer to place wagers, an off-table betting cloud manager and the house architecture in accordance with one embodiment;

[0007] Figure 2 depicts the off-table betting architecture in accordance with one embodiment;

[0008] Figures 3a and 3b illustrate the dealer perspective workflow diagram in accordance with one embodiment;

[0009] Figures 4a and 4b illustrate the play orchestration perspective workflow diagram in accordance with one embodiment;

[0010] Figure 5 illustrates the observer orchestration perspective workflow diagram in accordance with one embodiment;

[0011] Figure 6 depicts the initialization messaging process of the off-table betting system of Figure 1 in accordance with one embodiment;

[0012] Figure 7 illustrates the hand begin messaging operation steps of the off-table betting system of Figure 1 in accordance with one embodiment;

[0013] Figure 8 illustrates the pre-flop messaging operation steps implemented by the system of Figure 1 in accordance with one embodiment;

[0014] Figure 9 illustrates the flop and turn messaging operation implemented by the system of Figure 1 in accordance with one embodiment;

[0015] Figure 10 illustrates the river messaging operation implemented by the system of Figure 1 in accordance with one embodiment;

[0016] Figure 11 illustrates the hand completion messaging operation implemented by the system of Figure 1 in accordance with one embodiment;

[0017] Figures 12a and 12b illustrate wager efficacy and minimal play distribution workflow implemented by the system of Figure 1 in accordance with one embodiment;

[0018] Figure 13 illustrates card detection and hand completion operations implemented by the system of Figure 1 in accordance with one embodiment;

[0019] Figure 14 illustrates the pocket cards detection state machine operation implemented by the system of Figure 1 in accordance with one embodiment;

[0020] Figure 15 illustrates the observer user interface of Figure 1 in operation during bet taking in accordance with one embodiment;

[0021]
Figure 16 illustrates the mechanisms for aligning audio, video and game events by translating from real-time at source to vector time at consumption;.

[0022]
Figure 17 illustrates an audio/video and game event data alignment process;

[0023]
Figure 18 illustrates a table of Dealer and Player User Interface prompts;
and

[0024]
Figures 19a-19s illustrate exemplary Dealer and Player User Interface prompts.
DETAILED DESCRIPTION

[0025]
Persons of skill in the art will appreciate that the method(s) and system(s) described herein may be implemented using programmed processor of one or more computers such as in a server(s)/ client(s) relationship.
The application for implementing the off-table betting system (see Figure 1) for the observer and graphical user interfaces discussed herein may be provided via a web browser or a native application. Information captured from any one of the RFID (Radio Frequency Identification) detector, video composition (via a camera), the play orchestration tool, the Wager Orchestration 106 tool, observer preferences and settings related to the wagers and the observer interface 110, the odds for each portion and hand of the game being played as provided by the odds book tool, the game rules and other information related to the facilitating of wagers being placed may be stored to a database or other storage solution coupled to a computing device.

[0026]
The Off-table betting system (OTB) 100 (Figure 1) described herein can be understood in relationship to High Stakes Cash Poker (or other live card games) to facilitate placing bets on each of the players in the game and specifically each hand being played in a live cash poker game (or other such card game).

[0027]
In one embodiment, OTB is specifically designed to allow Observers to place a bet on whether a particular Player's hand will either improve or win or both.

[0028] The term high stakes cash poker as referred to herein can include any of the family of card games referred to as poker that are played at high stakes.
For example, Texas Hold'em can be played as a high stakes cash game. This means Players bring their own cash to the table and play 'table stakes' ¨ meaning Players can win or lose the entire amount of cash they have at the table at any time. If they run out of chips they can simply buy more chips with cash. 'High stakes' is a relative term but by today's standards it means Players are buying in for example, $10,000 -$1,000,000+. The largest cash games are played in Vegas and Macau where Players regularly buy-in for example ¨$500,000+ and sessions can last for many hours.
Hold'em overview

[0029] Texas Hold'em is provided as one embodiment of a poker game that can be used with the OTB 100. The following provides a review on typical cards/hands in Texas Hold'em that can be used for the off-table betting system discussed herein. The rules discussed herein are incorporated into the off-table betting system for determining degree of success or failure in the bet placed by the observer. Embodiments that include other poker games can similarly have their rules included in the off-table betting system.
Pocket cards and the blinds

[0030] The game is played by dealing each player two cards face down.
These are called the player's 'pocket cards' or 'hole cards'. The player receiving the first pocket card is called the Small Blind and the player to their left is called the Big Blind.
They are 'blind' because they are forced to make bets to create a pot before any cards are dealt. The player to the right of the Small Blind is the nominal dealer and in front of them, on the poker table is a Puck that visually identifies them as the nominal dealer for the current hand. The Puck moves around the table to the left after each hand and this dictates the order of the game for the actual Dealer.
Community cards ¨ the flop, turn and river

[0031] The winner of a hand is the Player that makes the best 5-card poker hand (or the last person to fold their hand) out of a combination of their pocket cards and 5 community cards. The community cards are shared amongst all Players and are presented face up in the centre of the table by the Dealer in stages. Before the community cards are revealed and after the pocket cards are dealt a round of betting occurs. In this round of betting, unlike subsequent rounds, the Big Blind is the last to decide. After this initial round of betting the Dealer places three cards at once face up.
These are called the Flop. At this stage the Players engage in another round of betting;
the nominal dealer is the last to act in each round of betting after the Flop.
After the Flop, the Dealer reveals one more card face up. This is called the Turn card.
At this point a third round of betting is conducted. And finally, a fifth card is dealt face up in the centre of the board alongside the other four. This is called the River. A
final round of betting is conducted before a winner is determined.
Who wins a hand of Hold'em?

[0032] The winner in Hold'ern Poker is the last person to fold or the Player that holds the best hand in the case where the last bet is called by other Players.
Each Player holds 4 distinct 5-card hands at showdown (the stage after the River where Players reveal their hands to determine a winner). 1) the 5 community cards revealed in the centre is 'the board' and when the board wins the pot is split (considered a tie), 2) the player uses one of their cards and 4 of the community cards, 3) the player uses the other one of their pocket cards and 4 of the community cards, 4) the player uses both of their pocket cards and 3 of the community cards.

[0033] The Players best hand is the one that ranks highest of the 4 hands above.
The winning hand among all the players in the game is the hand that ranks highest amongst the best hands of each Player.
Hand Rankings

[0034] The following hand rankings are used as a set of pre-defined rules for facilitating the determination of the winner in the off-table betting system of Figure 1.

The following rules can be stored in a storage associated with one or more computing devices for the off-table betting system. As discussed, the winning hand is the hand that ranks the highest among the best hands of all the Players. The following describes how hand rankings are determined.

[0035] High Card - a series of unrelated cards where the highest card in one hand wins if it is the highest card amongst all hands and no other hand is better than High Card. Card rankings are: Ace, King, Queen, Jack, Ten, Nine, Eight, Seven, Six, Five, Four, Three and Two. Suits are not relevant in High Card Hands.
Therefore two hands with identical cards but different suits would be considered tied hands.

[0036] One Pair ¨ a hand where two of the five cards are of the same value.
One pair beats another pair if the value of the cards making the pair is higher in rank than that of the other pair. When two hands have the same pair then the High Card Hand wins.

[0037] Two Pair ¨ a hand having 2 distinct Pairs amongst five cards is a Two Pair hand. The rules for the best two pair are the same as for One Pair hands.

[0038] Three of A Kind (a Set, Trips) - a hand having three of the five cards with the same value. The best three of a kind is determined similarly to Paired hands.

[0039] Straight ¨ a hand making a contiguous sequence among the five cards based on the card rankings. Ace is a special card in Hold'em such that it can be both the highest card and the lowest card for purposes of making straights.
Example: A, 2, 3, 4 ,5 and T, J, Q, K, A are both straights. The second straight beats the first straight.
The first straight is a five-high straight, the second is an Ace-high straight. Again suits do not determine strength of a straight (unless all five cards are the same suit) and so two five-high straights tie.

[0040] Flush ¨ a hand comprised of all five cards of the same suit. In Hold'em it is not possible for two Players to make flushes in different suits in the same hand and so to determine the best flush is to determine the highest card within the flush that is distinct between the hands.

[0041] Full House ¨ a hand containing both Three of a Kind and a Pair.
The Full House with the highest Three cards is the best. Where two hands both use the same Three of a Kind, the hand with the highest Pair component determines the best hand. Example: if the board shows As, Ac, Jd, 9s, 9d and one Player holds [Ad, Kc]
and another holds [Ah, Jc], the second Player has the best hand because the pair of Jacks is better than the pair of nines.

[0042] Four of a Kind (Quads) ¨ a hand having four of the five cards with the same value. Rules for the best Quads are the same as for Three of a Kind and Pairs.

[0043] Straight Flush -is a hand that is both a Straight and a Flush. The best Straight Flush is a Royal Flush : Ts, Js, Qs, Ks, As, for example. In Hold'em it is not possible for two players to have straight flushes with different suits and so to determine the best hand is to determine the highest card within the hand that is distinct between the hands.
How a determination is made that a hand has improved

[0044] As described above, in one embodiment, the off-table betting system and method is a tool that allows an Observer to place a bet on whether a Player's hand will improve and win. Based on the hand rankings above we see how a Player's hand can win ¨ i.e. either by having the Player bet and cause all others to fold their hands or by making the best hand at showdown. A player's hand is considered to improve if a hand gets better by moving up the rank order. In one example, if a Player is dealt a pocket pair of Aces, any combination of community cards that results in a hand of Two Pair or better will improve the Player's hand. As another example, if a Player is dealt [5s, 6s] in the pocket then any five, any six, any series of cards that make a straight such as two, three, four and, any combination of cards all of which are spades will result in an improved hand.

[0045] It is noted that there is a difference between a player's hand strengthening and a player's hand improving (e.g. moving up the rank order). For example, a hand that produces a 4 card straight along with 4 cards of the same suit has strengthened, but it has not improved as it is still just a High Card hand. The potential for the hand to materialize into an improved hand such as a flush or a straight on subsequent community cards has improved but the hand itself has not.
Cash games versus Tournaments

[0046] Embodiments can be used in either cash games or tournament games.
A
preferred embodiment of the off-table betting system is designed for derivative betting on cash games as opposed to tournament play.

[0047] A cash game referred to herein can mean for example, a Player sits down at the table by buying in for an amount within a range, based on the stakes (set by the house) of the game. Every chip at the table is essentially equivalent to cash.
A Player may add more cash at any time within the range and may leave at any time.

[0048] Conversely, in a tournament, the chips are not equivalent to cash and Players play until they are out of chips. When they run out of chips they may or may not be able to buy back in depending on the tournament rules and they may or may not win any money depending on what position they finished among the other Players in the tournament and the payout structure for the tournament.

[0049] Further, preferably, cash games for the off-table betting system described herein can occur on a single table, for example with a minimum of 2 players and a maximum of 10 whereas a tournament can be single table elimination or be comprised of many tables and thousands of Players.
System Overview

[0050] The following provides a description of an overview of the off-table betting system 100 operation in reference to Figures 1 and 2, in a preferred embodiment. The off-table betting system 100 comprises a house computing system 116 including a video composition system 102, a play orchestration subsystem 104, accounting/reporting subsystem 122 and the Off-table betting Table hardware and software components coupled to the remaining subsystems within the house computing system 116. The house computing system 116 also is coupled to and communicates with one or more dealer tablets 208 (as part of the OTB Table Components 124). Each dealer tablet 208 being digitally coupled to player tablets 204 and RFID readers 202. In a preferred embodiment, the house computing system 116 can reside at a physical location which is hosting the cash game. However, one or more modules and/or subsystems of the house system 116 may reside on computing systems coupled to, but external to, the house system 116 and/or at external physical locations. Preferably, at least the OTB
Table components 124, reside at the physical location where the live game is being played. Additionally, the dealer tablets 208 reside at this location.
Preferably, the player tablets 204 reside at the physical location where the game is being played to avoid collusion. In this way, it is ensured that the player at the player tablet 204 is different from the observer at the observer interface 110. The house computing system 116 is configured to communicate with the Off-Table Betting (OTB) Cloud Manager subsystem 118. The OTB cloud subsystem 118 communicates to the house computing system 116 via secure communication means such as a virtual private cloud gateway.
The observers 110 are validated and their bets are placed and controlled via the OTB
Cloud Manager subsystem 118. The OTB Cloud Manager subsystem 118 also handles generation of odds to be presented at pre-defined intervals to the observer at interface 110 placing the bets.

[0051] 1. A continuous composite video stream is sent to the Web Server (Wager Orchestration system 106) from the Video Composition module 102. The composite video provided by module 102 is comprised of video streams from the plurality of Player Tablets 204 as well as any other video streams that may also make up part of the game broadcast ¨ such as from an overhead camera for example.

[0052] 2. As cards are dealt to the Players by the Dealer (e.g. via Dealer Tablets 208), the digital identifier of each card is picked up by the Player Tablet's RFID reader 202 (Figure 2) and the cards are recorded in the storage of Player Tablet 204 and can be used for future hand-history analysis (e.g. by the OTB Cloud Manager Tool 118).
The unique card identifiers are then forwarded to the Play Orchestration 104, Wager Orchestration 106 and the Odds Book 108 along with the Player identifier for odds to be calculated and cards to be presented to the Observer interface(s) 110.

[0053] 3. At this point, the card game progresses as it normally would with Players engaging in pre-flop betting. As Players fold their cards pre-flop, the cards are sent to the Muck Zone 206 and the Dealer Tablet 208 detects the folded cards and sends the card identifiers from the RFID Reader 202 to the Play Orchestration 104, Wager Orchestration 106 and the Odds Book 108 for reconciliation and user interface (e.g. 110) presentment.

[0054] 4. The Dealer presses the "flop" button on the Dealer Tablet 208 user interface and this puts all Tablets (e.g. 204) in a state of pre-flop. When Player Tablets 204 are put into pre-flop mode, as a secondary measure all Player Tablets 204 confirm the cards that they are detecting via RFID (e.g. via Reader 202) and resend this information to the Odds Book module 108. At this point, the Odds Book module can safely calculate pre-flop odds for those Players still in the hand (i.e.
still engaged in the game as monitored by the OTB Cloud Manager 118) and seeing the flop of the first three community cards.

[0055] At this point, a graphical representation of the Player's cards along with their respective odds is presented to the Observers 112 via the Web Server (e.g. wager orchestration system 106). The Wager Orchestrator 106 is initialized to accept bets.

[0056] 5. The Wager Orchestrator system 106 is configured to accept bets from Observers 112 (e.g. via interface 110) while counting down for some pre-configured amount of time (e.g. 30 seconds). Visual cues and/or audible cues are presented to the Observer 112 via the Interface 110, such as an icon including an emptying hour-glass icon or a meter bar along with audible cues such as a bell or a digitized voice for representing the pre-determined amount of time remaining (not shown).

[0057] 6. When the Wager Orchestrator system 106 closes the betting for the hand it sends a signal to the Dealer Tablet 208 that then provides a cue (e.g.
a visual cue) to the Dealer via the user interface on the Dealer Tablet 208. This visual and audible cue tells the Dealer that the system is ready for the hand to proceed.

[0058]
At this point the Dealer can proceed via the Dealer Tablet 208 with the hand by dealing, for example, the flop, turn and river cards into the Community Card Zone (e.g. see Figure 2) while the Players via the Player Tablets 204 complete the hand with subsequent betting on each round as they normally would.

[0059]
7. As the flop, turn and river are dealt to the Community Card Zone the Dealer Tablet 208 detects each card and sends the card identifiers (via the RFID
Reader 202) to Play Orchestration 104, and the OddsBook 108 modules implemented within a computing device. When the final river card is dealt the OddsBook 108 deduces the notional winning hand but not until all the betting is complete and the chips are shipped to the actual winner can the clearing of the bets be completed.

[0060]
Once the Dealer (via Tablet(s) 208) determines the actual winner and ships the pot the Dealer then indicates, via the user interface on the Dealer Tablet 208, which Player actually won. The identifier of the winning Player is sent to the Wager Orchestration system 108 and the Clearing System 114.

[0061]
It is noted that the Dealer referred to herein can include an automated and/or semi-automated dealer operated via the dealer tablet 208 and its associated computing device processor. For example, the dealer tablet 208 may be configured to process/deal the cards according to the off-table betting system 100 and its pre-defined criteria described herein.

[0062]
8. Given the winning Player, the Clearing System 114 is configured to adjust account balances and the Observers 112 are presented the results of their wager on the hand.
Odds Making and Efficacy

[0063]
One advantage of the system 100 is to enable the house to provide a game for Observers 112 to participate in wagering much like in Blackjack, Craps, Roulette or any other house game by placing a bet on the outcome of each or any hand of a game of Texas Hold'em (those skilled in the art realize that it can be any form of game with various streets of betting such as Omaha as well). It is further envisaged that, in one embodiment, the OTB system can include additional limitations by considering for example Player's preferences, the odds and payout rule modifications.
Advantages of OTB over alternative gaming

[0064] In a preferred embodiment, one advantage of the Off Table Betting (OTB) system 100 is that observers can communicate remotely via the observer interface 110 and don't have to be physically present in the house (in the same physical location or building as the OTB table components 124) to place a wager. But further, the broadcasting of the game from the house computing system 116 allows involvement by Observers 112 via interface 110 that would not be included otherwise in the game being played.

[0065] One advantage that the OTB system and method presented according to Figure 1 has over other concepts of derivative betting is that the live high stakes game that is being wagered on is closed and controlled (e.g. within the house system 116), whereas no such control is available for wagering on the outcomes of existing on-line games (such as online poker games). In this way collusion (i.e. someone being a Player and an Observer) is impossible. Further, the OTB system 100 and the OTB

cloud manager 118 allows wagers on real-time, current or "live" games and the wagers can be dynamically placed in real-time hand for hand. As will be described in one embodiment, the OTB system 100 allows the placing of bets at pre-defined times (e.g.
just prior to the flop in Texas Holdem, or after the first five cards are placed in Open Face Chinese Poker) during the live play of the game and not simply in relation to each tournament, which allows observers 112 (via the observer interface 110) to remain involved and betting throughout the gaming process. It will be envisaged that the OTB
system 100 can also allow wagers on overall tournament outcomes in addition to dynamic wagers asserted at each hand.
Odds making and payout rules

[0066] As was discussed above, the odds and rules of the OTB system 100 is configured to provide long term viability for the house in a preferred embodiment. As such, the exemplary odds making and rules of OTB are as follows as provided for example at the Games Rules Component 120:

[0067] At the OTB system 100 only the display of cards of the Players seeing the flop are shown to the Observers, in one embodiment, the following steps are used by the OTB system 100 and the wager orchestrator system 106:
1 All cards dealt to Players (e.g. displayed on tablets 204) may be used for odds calculations 2 Odds are presented for each Player seeing the flop that represent the likelihood of the Player's hand improving and winning after the flop, turn and river have been dealt 3 If two or more Players tie then nothing is paid out (wagers may be pushed and commissions may still be taken) 4 If the winning Player does not improve their hand then nothing is paid out (commission may still be taken)

[0068] These rules serve to smooth out the variability and complexity when you consider bluffing in the game. In this manner, it is advantageous for the off-table betting system 100, in a preferred embodiment, to require that a Player's hand (e.g.
via tablet 204) improve to get paid removes the complex element of bluffing from the derivative game and it smoothes the odds across Players seeing the flop. This makes it viable for the house to clear the wagers and be profitable over the long run.
Insurance when no hand has improved

[0069] In one embodiment of the off-table betting system 100 (e.g. of Figures 1-2), the off-table betting system 100 is configured to allow an Observer (e.g.
via interface 110) to pull back some percentage of his initial wager after the flop or turn under the condition that no hand has improved. This additional insurance criteria may be predefined within the wager orchestration system 106. The percentage that can be pulled back can be variable. For example, if an Observer chooses to pull back on the flop, when no Player's hand has improved, the percentage might be 50% whereas if the Observer chooses to pull back after the turn, when no Player's hand has improved, the percentage might be 10%. The intention is to have this variable insurance adjustable based on the operators preferences.

[0070] In one embodiment of the OTB betting system 100 is configured to receive information relating to Player tendencies, Player position, Player track record and other factors (e.g. stored in a storage or database associated with either the house computing system 116 or the cloud manager subsystem 118) are used in odds making by the odds book module 108. Further, in another embodiment, there is provided an OTB
system 100 where odds can be calculated on each street, not just pre-flop, and where wagers can be made throughout a hand.
Problems of Collusion

[0071] With the hole created by the closure of online poker to US
citizens, American casinos have a huge opportunity to pick up the pieces and fill a market hole in online gaming. The off-table betting system 100 is advantageous as it facilitates live in-house gaming with online wagering as described herein.

[0072] The solution of coupling the live in-house game with the online derivative game (OTB system 100 as described herein) presents several hurdles that are preferably addressed by the OTB system 100. There are several problems; the primary one being collusion. Simply, there is no solution to ensure that a person is not both an Observer and a Player in existing games. That is, when the game being wagered on is on-line there is no way to ensure that a player in the game is not also betting on the game as an observer of the game. Further it is not possible to prohibit an on-line player from conspiring with someone observing the game so that they can create an edge in the game. Surely if such a system existed only fools would play in the game being observed.
Solution to Collusion

[0073] The OTB system 100 (e.g. Figure 1 and 2) and resulting architecture provides the following keys to solving the collusion problem:

1. The size of the bets placed in the OTB system, relative to the stakes of the game being wagered on are preferably relatively small, as pre-defined for example by the Game Rules module 120. Accordingly, this restriction amount is determined by the wager orchestration module 106 and the odds book 108 such as to significantly reduce the odds or reason for a player via tablet 204 to be same as observer via interface 110. In one example, if the game being wagered on is a Texas Hold'em game with a $1m buy-in and a $1000, $2000 blind structure then the maximum bet on any hand that an observer would be allowed to place would be at most 1120th the size of the big blind ¨ approximately $100.
Note: this would be comparable to the range of stakes at a typical casino for Black Jack, Roulette, Craps or other table games.
2. The live game is preferably in a controlled environment such as to avoid the player, playing via tablet 204 to be the same as an observer via interface 110.
Because the game is live, held in a casino, and is of sufficiently high enough stakes the Players are easily limited. Further, by placing restrictions on the use of external devices (e.g. electronics) while at the live game table, it is impossible for a player to also be a participant in the OTB betting at the same time as they are playing in a live hand at the table.
3. Combining 1 and 2 above along with the method of odds making (e.g. as provided by the odds book module 108) there is essentially zero incentive for financial gain through collusion.
a. As a Player (e.g. via tablet 204) throwing a hand in the live game to benefit a group of Observers would certainly expose the Player (e.g. via tablet 204) as a cheater since the hand would be played oddly and unprofessionally.
b. Further, the Player (e.g. via tablet 204) would have to throw multiple hands to make it financially fruitful for the Observers which would surely be very costly for the Player. That is, throwing a hand post flop can be very expensive compared to what may be shared by a benefitting group of Observers e.g. via interface 110.
c. Even if the Player signals to the Observers , via the video feed, a pre-meditated action. For example, the Player could pull his left ear with his right hand signalling to the knowing Observer that the Player will dump the hand when facing aggression post flop. This is the best the Player could do to collude and the approach fails because:
i. No guarantee his hand will not improve to a virtual nut hand post flop which would surely expose him as a cheater were he to dump.

But his colluding partners have placed their wagers against him already and so this is a conflict ii. No guarantee he will face aggression from opponents in the hand iii. No guarantee his opponent's hands will improve if he does dump his hand iv. And since the house only pays in a case where a hand improves and wins post flop there is no risk to the house of attempts at collusion by Players.
Technical Challenges for OTB system 100 and its components

[0074] There are numerous technical challenges to overcome by the OTB
system 100. Some of the challenges are outlined below (in reference to Figures 1 and 2):
1. Wager Efficacy - How to synchronize the live broadcast of the poker game (via the video composition system 102) with the wagering by Observers process by wager orchestration 106? I.e. ,when and on what are the Observers betting and how can we be assured that the progression of the cash game does not adversely affect the efficacy of the house and the wagers? This is addressed by the Play Orchestration subsystem 104, Wager Orchestration system 108, Dealer Interface (e.g. dealer tablets 208), Observer Interface 110 and the real-time odds calculation engine (OddsBook 108) software and/or hardware components and their associated computing device(s), processors and storage elements(not shown).
In a preferred embodiment, to address the wager efficacy issue a mechanism of synchronized countdown clocks between the Play Orchestration and Wager Orchestration components together with visually cueing the Dealer via the Dealer interface is used. Exception handling mechanisms are also utilized to disqualify a hand from wagers if the Dealer acts out of line with the cues on the Dealer interface. Further, in one aspect, disabling some or all of the table cameras from broadcasting during the countdown period is possible for assuring wager efficacy and minimizing chances of exception handling.
2. Game Disruption - How to not disrupt the cash game in progress while accepting wagers from Observers? i.e. the opposite of (1) above ¨ how can the game progress at a natural pace while at the same time accepting wagers from potentially thousands of Observers? This is addressed by the Play Orchestration subsystem 104, Wager Orchestration system 106, OddsBook module 108, Dealer Interface 208 and Observer Interface 110 software and/or hardware components.
A mechanism of synchronized countdown clocks between the Play Orchestration and Wager Orchestration components together with visually cueing the Dealer via the Dealer interface and the Observers via the Observer interface is utilized in one embodiment to address the Game Disruption issue. Denial of wagers received after clocks have expired can also be used.
3. Hand detection and completion ¨ how to have the system electronically detect Player's cards, know when hands are folded, and determine winning hands in coordination with Dealer confirmation in a timely way. The system 100 is configured to allow Players (via tablet 204) and the Dealer to essentially act as they would in any other live cash game with minimal prompts and distractions from the game at hand and minimal disruptions from the OTB Cloud Manager 118 while taking wagers from an observer 110.
4. Preferably, individual RFID readers at each Player tablet serves to independently prompt each Player to manipulate their cards until card detection is assured.
Regular polling of the RFID reader by the Player tablet is used to determine when cards are folded in conjunction with prompting the Player for confirmation via the Player tablet interface. Real-time odds - How can Odds be generated in real-time to satisfy (2) above? This is managed by the interaction between the Play Orchestration 104, Wager Orchestration 106 and the OddsBook 108 components. The OddsBook is programmed to calculate odds in a central system when presented with all cards dealt/detected.
5. Disparate Observers- How to allow Observers to be geographically disparate from each other and the game while still being able to maintain the progress of the game and give all Observers a fair chance to wager? This is handled by Wager 106 and Play Orchestration 104 components.
In one embodiment, synchronization of countdown clocks together with variable fidelity of the video broadcast is used to ensure that volume and performance of Observers does not disrupt the game.
6. Observer Integrity and proper accounting - How to manage cash balances that are changing based on the results of potentially large number (e.g.
thousands) of wagers and hand outcomes and potentially multiple live cash games simultaneously. This is managed by the interaction of the Observer AAAA 112, Wager Orchestration 106, and the Clearing System 114 components.

Asynchronous transaction logging, floating Observers in real-time for their wager amount and performing post-hand (or post-game) reconciliation is preferably used in one embodiment.
7. Player Value - How to provide Players (e.g. via their associated tablets 204) with hand histories and statistics. This is handled by the Player Interface 204.
According to one embodiment, providing Players with a user interface to upload the hand results and notes to a separate system for subsequent post-game analysis. Uploads may include archived video footage of the Player or all Players and possibly other Player's pocket cards.
8. Observer Reporting - How to provide Observers with hand histories and accounting/reporting? This is handled by the Observer Interface 110, Wager Orchestration system 106, the Clearing System 114 and the Observer AAAA 112 components.
In one aspect, a separate website will allow Observers to login and view all prior wagers and results and manage their accounts.
High-level Component Architecture

[0075] Figure 1 depicts the software and/or hardware components of one or more computing devices for providing the off-table betting system 100 and the corresponding network architecture. The following components are discussed in relation to the off-table betting system 100 architecture of Figure 1.
OTB Cloud Manager Subsystem 118

[0076] The OTB Cloud Manager subsystem 118 is a collection of software and/or hardware components of one or more associated computing devices that can be located in 'the cloud' (i.e. not necessarily in the same physical infrastructure as The House) with an internet facing gateway for the Observer Interface 110 to gain access to the game and a Virtual Private Cloud (VPC) gateway to the House computing system 116 (the host of the cash game. i.e. the casino).
Observer AAAA(4A) 112

[0077] The Observer 4A 112 system is the component configured for providing one or more of the following services: Authentication (e.g. of observers placing request to place a bet), Authorization (e.g. of observers), Access (e.g. of observers) and Accounting associated with the observers accessing through interface 110, the player tablets 204 and the dealer tablets 208. Preferably, the observer system 112 is associated with a database of credentials that enables Authenticated Observers to gain authorization to access the Web Server (Wager Orchestration system 106). The Wager Orchestration system 106 then periodically confirms with the Observer 4A 112 to ensure Access remains granted for the observers and that Accounting is sufficient to allow play to continue.
Odds Book Module 108

[0078]
The Odds Book module 108 is a software and/or hardware component associated with one or more computing devices of the OTB cloud manager 118 that calculates special odds to be presented to the Observers of the game (e.g. via 110).
The odds are based on card values received from each Player's tablet (Player Tablet 204) as the dealer distributes the pocket cards.
Wager Orchestration System 106

[0079]
Wager Orchestration system 106 is a software and/or hardware components associated with one or more computing devices of the OTB cloud manager 118 that accepts bets from registered Observers 110 of the game after the odds are presented by the Odds Book Module 108. Bets are accepted and cleared for each hand and the Wager Orchestrator System 106 ensures an organized approach to opening and closing for bets on each hand.

[0080]
In a preferred embodiment, for security and integrity reasons, the Wager Orchestration system 106 is the only network communication interface into the OTB
system for Observer devices 110. That is, the observer interface 110, in a preferred embodiment, only communicates with the house computing system 116 via a remote OTB cloud manager 118 system (and specifically only the wager orchestration system 106) and its proprietary VPC messaging gateway depicted in Figure 1. For example, preferably, when displaying the Balance of Funds to the Observer, the Observer interface 110 receives this information (via polling or event messages) from the Wager Orchestration system 106; it does not independently query the Clearing 114 and Accounting 122 system for that data.

[0081] In other words the Wager Orchestration system 106 is the consolidation point for all interface items presented to Observer devices via interfaces 110.
Play Orchestration Subsystem 104

[0082] The Play Orchestration subsystem 104 receives signals from the Tablets (e.g. dealer tablets 208 and the player tablets 204) at the OTB table 124 and drives the user interfaces of the tablets to control the game in synchronization with the Wager Orchestration System 106. The play orchestration subsystem 104 is associated with one or more computing devices and processors of the house computing device 116.

[0083] Beyond the OTB table 124, the Play Orchestration 104 interfaces primarily with the Odds Book module 108 and the Wager Orchestration system 106.
Clearing 114 and Accounting 122 System

[0084] The Clearing System 114 is a software and/or hardware component that is preferably the centralized authority for Observer's Balance of Funds, and it approves wagers on behalf of the Wager Orchestration System 106. The Clearing System may also take a portion of the total wager and allocate it to an operating account as a service fee on each hand. The clearing system 114 is associated with one or more computing devices of the OTB cloud manager 118.

[0085] The Clearing system is reconciled every 24 hours (or other pre-defined timing) with the accounting system of each House computing system 116.
Game Rules 120

[0086] Game Rules 120 is a software and/or hardware component (associated with one or more computing devices of the OTB cloud manager 118) that provides certain parameters to the Play 104 and Wager Orchestration 106 systems to control game operations. Since the OTB cloud manager subsystem 118 can orchestrate wagering for multiple games across multiple houses, each game may have a unique set of parameters that control various aspects of the game. E.g. Odds skewing factors or insurance rates and whether or not to even allow insurance as an option.

[0087] On initialization and periodically, Play Orchestration 104 for each table queries the Games Rules 120 service to configure various aspects of the game (in particular insurance availability, insurance rates, and odds skewing factors).

[0088] Communication between the Play Orchestration 104 and the Odds Book 106 includes the odds skewing factors and communication between the Play Orchestration 104 and the Wager Orchestration 106 include the insurance parameters.
The House Computing System 116

[0089] The House Computing System 116 represents a physical location, typically a casino, which is hosting the cash game. Digitally coupled to the house computing system and associated computing device(s) 116 there is a customized OTB
poker table 124 that is used by the House Computing system 116 to enable game play with OTB system 100. In addition to the physical OTB poker table 124 there are a number of software and/or hardware components present.
Video Composition System 102

[0090] The video composition system 102 comprises software and/or hardware components (e.g. including cameras and other video processing equipment/software) that establishes a video feed for the Observer Interface 110 that is comprised of a composite of the video streams received from each Player Tablet 204 (see Figure 2) and the video stream of the main table camera(s) associated with the house computing system 116.
OTB Table 124

[0091] The OTB table 124 is a poker table customized for facilitating a Dealer Tablet 208 in the position facing where the Dealer sits, and Player Tablets 204 facing the positions where the Players sit as illustrated in Figure 2.
Dealer Tablet 208

[0092] The Dealer Tablet 208 is a tablet device such as a commercially available tablet including an Android tablet or other tablet with a front facing camera capable of video and with USB or other input interface for receiving RFID signals. The Dealer Tablet 208 is equipped with software and/or hardware to read RFID signals from an RFID reader 204 attached to the tablet. The Dealer deals a special deck of cards that contains cards with embedded RFID tags which uniquely identifies each of the 52 cards in the deck. When cards are dealt into the Community Card Zone the Dealer Tablet 208 detects these cards and sends the digital representation of each card to the Play Orchestration 104 component.

[0093] Further, the Dealer Tablet 208 displays on its associated user interface cues to the Dealer for when to begin a new hand, when to pause before dealing the community cards, and for manually confirming hand completion. The cues are presented to the Dealer as signals are received from the Play Orchestration 104 and other components (described in more detail below).
Player Tablet 204

[0094] The Player Tablet 204 is similar to the Dealer Tablet 208 in that it includes a computing device, a processor, storage, and RFID readers 202. The Player Tablet 204 processes the RFID signals as cards are dealt within proximity of the Player Tablet (Player Zone) and the card identifiers are sent to the Odds Book 108 for odds calculations. Further, a video feed, using the front facing camera, is continuously sent to the Video Composition 102 component for redirection to the Internet for Observers to view via interface 110.

[0095]
The Player Tablet 204 may also present to the Player an interface of hand histories, the current hand, and other information relevant to their game such as Voluntarily Put money In Pot (VPIP) and other player statistics (as stored in its storage/database).
Accounting and Reporting 122

[0096]
The Accounting and Reporting system 122 receives events from the Clearing system 114 and provides an audit capability to support back-office financial transactions between the House 116, Observers 110, and the OTB Operator that are driven by the OTB cloud manager subsystem 118.
Workflows

[0097]
The overall system is intended to allow for a many-to-many relationship between the number of games in progress, the location of the games and the orchestration components that manage the games and wagering via the Dealer Interface 208, Player Interface 204 and the Observer Interface 110 components.
It is noted that the observer interface 110 is connected to an observer computer (not shown) for each observer, the observer computer containing at least a processor; a user interface and display unit for presenting the information from the OTB cloud manager 118 and the video from the video composition 102; a memory and/or storage means for containing statistics and other storage information received from the OTB
cloud manager 118

[0098]
This section shows high level data flows and workflow from various perspectives within the system:
Dealer perspective in Figure 3, Orchestration perspective in Figure 4 (Play 104 and Wager 106 combined), and Observer perspective in Figure 5 (e.g. via interface 110).
Game Control States Specifically for the game of Texas Hold'em, there are six primary states of game control:
1. Initialization 2. Hand Begin 3. Pre-Flop 4. Flop and Turn 5. River 6. Hand Completion For other games, such as Open Face Chinese Poker for example, the game states between Initialization and Hand Completion would obviously align to the states of the particular game.

[0099] At each stage various components are involved in various inter-component communications to orchestrate the hand for hand wagering.
Initialization

[00100] Referring to Figure 6, initialization begins with Play orchestration 314 starting up and becoming available. Other components are pre-configured to know the address of the Play orchestration 314 component and when they start up they look to register with Play orchestration 104.

[00101] As Observer AAAA 311 authenticates Observer Browser 310 via authentication messages 301 and approves Observer's status to participate it in turn registers the Observer with the Wager Orchestration component 312 via register Observer message 302.

[00102] Player Tablets 316 are informed of the address for the Video Composition component 313 in the response to registration message 305 and subsequently connect to Video Composition 102 to establish a video feed via message 306.

[00103] Similarly the Dealer Tablet 315 registers 304 and may also establish a video feed with Video Composition 313.

[00104] The Main Table Camera(s) 317 are pre-configured to establish video streams with Video composition 313 and may simply be hardwired into the Video composition system 313.

Hand Begin

[00105] Referring to Figure 7, when Play orchestration 410 is initialized and ready for a hand to start it sends a message 401 to the Dealer Tablet 411 ultimately instructing the Dealer to begin a new hand.
Pre-Flop

[00106] Referring to Figure 8, Pre-flop again is initiated by Play orchestration 512.
It confirms cards 501 and confirms the contents of the muck 502, requests odds to be calculated from the OddsBook 513 via message 503 and then waits for wager completion 508 before proceeding.

[00107] The OddsBook 513 calculates odds and forwards the book to the Wager Orchestration 514 via message 504.

[00108] The Wager Orchestration 514 then presents the odds 505 to the Observers 515 and waits for a pre-configured amount of time to accept wagers from the Observers. Wager Orchestration 514 confirms all bets 507 with the Clearing System 516.
Flop and Turn

[00109] Referring to Figure 9, Play orchestration 611 initiates both the flop and turn stages. They are similar messaging patterns: Play orchestration 611 confirms the contents of the community cards (flop or flop and turn) 601 with the Dealer Tablet 610; it then tests if insurance is an option via messaging 602 with the Oddsbook 612.
If insurance is an option, the play orchestration 611 then informs the Wager Orchestration 613 that it should present an insurance sell option 604 to the registered Observers 614.
If insurance is taken by an Observer 614 then the Clearing System 615 is informed via an insurance sold message 606.
River

[00110] Referring to Figure 10, at the river stage the Play orchestration 711 again initiates and asks the Dealer 710 to confirm the river card. It then proceeds to hand completion stage.

Hand Completion

[00111] Referring to Figure 11, during hand completion the Play orchestration 811 requests the outcome of the hand from the Dealer Tablet 810 via hand confirmation message 801. The results of 801 are forwarded to the Odds Book 812 via the results confirmation message 802 so that the Odds Book can determine the expected winning hand in the case of a showdown. The hand result is then sent to Wager Orchestration 813 via the message 803 so that results can be presented to the Observers 814 via messages 804. In parallel the hand is adjudicated and accounts are updated when the Clearing System 815 receives the message 805 from Play orchestration 811.
Inter-component message design details

[00112] This section describes various inter-component messaging and component functional design to address some of the problems outlined in Technical challenges section above.
Game Control - Wager Efficacy and minimizing Game Disruption

[00113] In order to ensure that the live broadcasting of the game does not impact the proper clearing of bets and while at the same time to ensure the live game is not disrupted in an unnatural way, a series of Play and Wager orchestration steps can be coordinated. These steps are outlined in the message/state transition diagram of Figure 12. Although a number of steps are shown, not all steps and messages are required for implementing an embodiment of the invention.
The Hand Begin Stage Hand Begin - ><init>

[00114] Before any hands begin the Player devices (e.g. 204) initialize and make themselves known to the Play orchestration 104 system. The Play orchestration system is configured to expect a pre-determined number of Player devices between 2 and 10.
Hand Begin -><register>

[00115] Before any wagering can begin each authenticated Observer (e.g.
via interface 110) registers with the Wager Orchestration system 106.

Hand Begin -><start hand>

[00116] Once the Play orchestration 104 receives the expected number of <init>
messages, and after performing its own initialization, it instructs the Dealer Interface 208 to start the hand by sending the Dealer tablet 208 the <start hand>
message. The Dealer tablet, when receiving this message displays a hand begin prompt that cues the Dealer to begin the hand.
Hand Begin -><hand started>

[00117] After the Dealer has completed dealing the pocket cards to all Players and dismisses the hand begin prompt, the Dealer interface/tablet sends the <hand started> message to the Play orchestration 104 system and then presents another prompt that warns the Dealer to wait before showing the community flop cards ¨
the flop ready prompt

[00118] NOTE: The Play orchestration 104 can also receive Hand Begin-><detected card> (see hand detection and completion below) messages from Player tablets as the RFID system picks up cards as they are being dealt. So the Play orchestration 104 system is likely able to deduce that a new hand has begun before this <hand started> message is received. However, preferably, the Dealer controls the pace of the game (e.g. according to messages received from the Play Orchestration and/or Wager Orchestration 106) and so this is the official message that indicates the start of the hand.
The Pre-Flop Stage

[00119] The purpose of the pre-flop stage is to cue the Dealer to control the game at a pace so that all wagering can be completed by the Observers before the Dealer produces the three flop cards.
Pre-Flop -><flop ready>

[00120] This message is sent from the Dealer interface 208 to Play orchestration 104 when the Dealer dismisses the prompt being displayed after dealing the pocket cards to each of the Players. Subsequently, the Dealer Interface 208 prompts the Dealer with another user interface prompt that instructs the Dealer to wait before showing the community flop cards ¨ the flop warning prompt.

[00121] NOTE: In a preferred embodiment, the Dealer does not disclose any community cards until the Dealer Interface prompts the Dealer to produce the flop and so the flop warning prompt being shown can be accompanied with a periodic audible cue that ensures the Dealer heeds the prompt while managing the pre-flop game as normal. Further, there can be a "Burn Zone" to the right of the Dealer Interface that can be monitored by the Dealer tablet to detect the "burn card". Burn cards are cards that are discarded before each of the flop, turn and river by the Dealer. If activity in the "Burn Zone" is detected, via RFID signals, before Play orchestration 104 has sent the <flop proceed> message then the audible cues can get much louder and more frequent to ensure attention by the Dealer. At this point the audible cues continue until the Dealer acknowledges the warning prompt.

[00122] At this point Play orchestration 104 is aware that all Players have received pocket cards: 1) because the Dealer has indicated such via the Dealer Interface 208 and the <flop ready> message and 2) ideally because the Player Tablets 204 have sent a perfect number of <card received> messages to Play orchestration 104. (see hand discover and completion below).
Pre-Flop-><confirm cards>

[00123] While the Play orchestration 104 should have enough information at this point to know which Players are still in the hand to see the flop based on the messages that are part of hand detection and completion (see below). The Play orchestration 104 can take a final step before requesting odds and cueing the Dealer to proceed.
The <confirm cards> message can be sent to each Player Tablet requesting that it respond with the pocket cards that each is currently detecting.
Pre-Flop-><pocket cards>

[00124] This message can be sent from each Player Tablet 204 to Play orchestration 104 to indicate whether or not the associated Player has cards and if so what those cards are.
Pre-Flop-><confirm muck>

[00125] As cards are folded by Players the Dealer moves the folded cards into the "Muck Zone". When the Dealer Interface receives this message the muck confirmation prompt prompts the Dealer to confirm that all of the folded cards are within the "Muck Zone".
Pre-Flop-><mucked cards>

[00126] This message can be sent from the Dealer tablet 208 to the Play orchestration 104 after the Dealer dismisses the prompt. The Dealer interface can re-poll the "Muck Zone" RFID interface and sends the cards detected as part of this message.
Pre-Flop-><calc odds>

[00127] Now with confirmation as to which Player's still have cards and what those cards are and with the contents of the "Muck Zone", at this stage the Play orchestration 104 has all the information it needs to request odds from the OddsBook subsystem 108 by sending the <calc odds> message.
Pre-Flop-><odds book>

[00128] Provided with each Players 'pocket cards and the contents of the muck (via <calc odds> message), special odds are calculated for each Player still in the hand.
These odds are forwarded to Wager Orchestration 106 to be available for Observers to wager on.

[00129] At this point the Wager Orchestration system 106 begins an internal wager countdown clock counting down for X seconds (where X is a configurable amount of seconds).
Pre-Flop-><wager ready>

[00130] <wager ready> is a simple signal from the Wager Orchestration system 106 to all registered Observer Interface systems 110 that an odds book is ready for the current hand and that wagers will be accepted for the next X seconds.

[00131] NOTE: In a preferred embodiment, we expect 10<=X<=25 seconds should be sufficient for optimizing overall playability.

[00132] NOTE: Depending on the network architecture and the Observer Interface technology, directly connecting and pushing asynchronous messages to the Observer device may not be effective. As such this message may be missed, skipped or ignored and the Observer Interface can pick up the odds book during a regular polling interval to the Wager Orchestration system.
Pre-Flop-><request odds>

[00133] The Observer Interface 110 requests odds for the current hand from the Wager Orchestration 106. It makes this request in response to the <wager ready>
signal or it makes this request on a regular polling interval.
Pre-Flop-><present odds>

[00134] This message is sent by Wager Orchestration in response to the <request odds> message. This message contains the digital representation of the Player's cards for those Player still in the hand and about to see the flop. This message also contains a value for the Observer Countdown Clock. This value is set by Wager Orchestration to the current value of the internal Wager Countdown Clock less some configurable amount to account for latency and processing time.

[00135] When receiving this message the Observer Interface presents the Observer the odds and wager buttons and begins a visual clock countdown with an initial value set to Observer Timeout Clock.

[00136] The wager buttons are enabled and allow an Observer to place a bet as long as the Observer Timeout Clock is still ticking down. When the timeout clock is done the wager buttons are disabled (disabled and hidden).

[00137] At this point there are two types of clocks ticking: 1) the master Wager Countdown Clock within the Wager Orchestration system and 2) multiple instances of the Observer Timeout Clock ¨ one for each registered Observer running within the interface application (browser for example) Pre-Flop-><place wager>

[00138] When an Observer places a bet by clicking one of the wager buttons, the Observer Interface 110 sends this message to the Wager Orchestration 106.

[00139] This message indicates which Player's hand the Observer is betting on.

Pre-Flop-><wager approve>

[00140] This message is a request to the Clearing & Accounting (Clearing) system 114 from Wager Orchestration 106 to obtain approval to accept the wager from the specified Observer(s) 110. A wager could be declined due to insufficient funds or other reasons.

[00141] If the wager is accepted then the amount of the wager is deducted from the Observer's Balance of Funds, and a response is returned to the Wager Orchestration indicating approval.
Pre-Flop-><wager approval>

[00142] This message is sent from Clearing 114 to Wager Orchestration 106 in response to the <wager approve> request. It either approves or declines the Observer(s) specified in the <wager approve> request. Reason messages and/or reason codes may be provided if the wager is declined or otherwise.

[00143] When Wager Orchestration 106 receives this message it uses the data to formulate the <wager accept> message as a response back to the Observer interface.
Pre-Flop-><wager accept>

[00144] There are a couple scenarios where a wager may be declined. For example:
1. The Observer is authenticated to multiple Wager Orchestration systems 106 and wagering on multiple games. In which case timing may result in insufficient funds to complete the bet. (see<wager approve> message above).
2. The Wager Countdown Clock is stopped and no more bets are being accepted for the current hand.

[00145] If the wager is accepted then the content of the <wager accepted>
message is TRUE and if the wager was declined for any reason the message is FALSE
and also contains an explanation message.
Pre-Flop-><wagers closed>

[00146] As bets are accepted they are kept track of within the memory resident data structures of the Wager Orchestration system 106. When the Wager Countdown Clock reaches zero, no more bets are accepted and the <wagers closed> message is sent to the Player Orchestration system to enable the live game to resume.
The Flop Stage

[00147] The purpose of the flop stage messaging is to cue the Dealer to control the progress of the game so that insurance options can be taken or declined by Observers before the turn card is produced.
Flop-><flop proceed>

[00148] After receiving the <wagers closed> message from Wager Orchestration, Play orchestration 104 moves the hand into the "Flop" state and it sends <flop proceed>
to the Dealer Tablet 208.

[00149] This message causes the Dealer Tablet 208 to release the waitprompt and then prompts the Dealer to proceed with the flop. At this point the Dealer first produces the community flop cards and then dismisses the prompt.
Flop-><present flop>

[00150] At this point the Play orchestration 104 may be aware of the flop cards as a result of messages from the hand detection and completion workflow. This message is sent from the Dealer Interface to the Play orchestration 104 once the Dealer dismisses the prompt on the Dealer Interface.

[00151] This message includes all three cards that have been detected via the Dealer Tablet's RFID system as making up the community flop cards.
Flop-><confirm flop>

[00152] The Play orchestration 104 sends this message back to the Dealer Interface and the Dealer Interface displays the 3 cards in the message to the Dealer via the user interface and prompts the Dealer to confirm that they match what was actually flopped (see Exception handling for details on when these don't match) via the confirm flop prompt.

Flop-><flop confirmed>

[00153]
This message is sent back to Play orchestration 104 from the Dealer interface when the Dealer dismisses the confirm flop prompt.

[00154]
This message includes the 3 cards that are actually on the flop. (see Exception handling for other details).
Flop-><turn ready>

[00155]
Immediately after the <flop confirmed> message, the Dealer Interface presents a turn ready prompt to the Dealer. The Dealer proceeds to manage the live game as they normally would- accepting bets, mucking folded hands, and controlling the game, etc.. When all the betting is completed and the Dealer is ready to show the turn card the Dealer dismisses the turn ready prompt and this results in this message being sent to Play orchestration 104.

[00156]
Immediately after this prompt is dismissed another prompt is presented ¨
the turn warning prompt - similar to the pre-flop warning prompt of the Pre-Flop-><flop ready> state.
However, unlike the pre-flop wagering that takes place, placing an insurance bet is less critical in terms of the timing for when the turn is revealed in relation to when insurance options are presented and taken. Nonetheless, at this stage the Dealer interface can monitor the "Burn Zone" similarly to Pre-Flop and provides an audible alert while this wait prompt is showing.
Flop -><insurance check>

[00157]
Once Play orchestration 104 receives the <flop confirmed> message from the Dealer Interface it immediately checks with the OddsBook 108 to see if insurance is an option. The OddsBook 108 receives the message which includes the 3 flopped cards and quickly determines if insurance is available (i.e. if no hand has improved then insurance is an option otherwise it is not).
Flop-><insurance avail>

[00158]
This is the response message from the OddsBook 108 and it includes a TRUE in the message if insurance is an option and FALSE otherwise.

Flop-><insurance ready>

[00159] If insurance is an option then this message is sent from the OddsBook 108 to the Wager Orchestration system 106 to trigger the insurance option with the Observers.
Flop-><sell insurance>

[00160] This message is sent from Wager Orchestration 106 to all registered Observer computing devices to indicate that the Observer interface should present an insurance option to the associated Observer (see Observer interface diagram below).
The insurance option can be presented as a simple yes/no dialog to the user on the user interface.

[00161] NOTE: Depending on the network architecture and the Observer interface technology this event may not be able to be pushed to all Observer interfaces.
Flop-><request ins>

[00162] This message is a request to the Wager Orchestration 106 to determine if insurance is an option. It is either a polling request or is done in response to the <sell insurance> or the <insurance clock> message depending on the network architecture and the technology of the Observer interface 110.
Flop-><insurance clock>

[00163] This message can be first pushed from the Play orchestration 104 system to the Wager Orchestration system 106 once the Play orchestration 104 receives the <turn ready> (or <river read>) message from the Dealer Interface. The <turn ready>
message indicates to the Play orchestration 104 that the Dealer is ready to reveal the next community card and so at this stage, if insurance is an option, a clock must be started at the Wager Orchestration 106 and Observer Interfaces 110.

[00164] This message can then forwarded to all registered Observer interfaces 110, where possible, and otherwise it is returned as a response to the <request ins>
message from Observer interface.

[00165] When the Wager Orchestration system 106 receives this message it can start an insurance clock, and includes a time value in the message payload that is some amount less than the insurance clock time [the amount is configurable and needs to be sufficient enough to accommodate for round trip time and processing time in order to ensure that the acceptance of insurance is complete before the Dealer produces the next community card).

[00166] When the Observer interface receives this message it starts a visual countdown from the time provided. If the Observer interface isn't already providing an insurance option dialog it does at this point. The Observer interface will stop taking insurance once this timer expires.
Flop><insurance closed>

[00167] This message is sent from the Wager Orchestration system 106 to the Play orchestration 104 system when the internal insurance clock expires and all insurance has been accepted or is being declined subsequently.

[00168] This message tells Play orchestration 104 that it is now timely for the Dealer to proceed with revealing the next community card.
The Turn Stage

[00169] The purpose of the Turn Stage is identical to the Flop Stage in that it is intended to cue the Dealer to control the game at a pace such that Observers can elect to take insurance or decline it when the system determines that insurance is available.
Turn-><turn proceed>

[00170] After receiving the <insurance closed> message from Wager Orchestration 106, Play orchestration 104 moves the hand into the "Turn" stage and it sends <turn proceed> to the Dealer Tablet 208.

[00171] This message causes the Dealer Interface to release the turn warning prompt and then prompts the Dealer to proceed with the turn via the turn proceed prompt. At this point the Dealer first produces the community turn card and then dismisses the prompt.

Turn -><present turn>

[00172] At this point the Play orchestration 104 may be aware of the turn card as a result of messages from the hand detection and completion workflow. This message is sent from the Dealer Interface to the Play orchestration 104 once the Dealer dismisses the prompt on the Dealer Interface.

[00173] This message includes the turn card that has been detected via coupled to the dealer tablet 208 as making up the community cards.
Turn -><confirm turn>

[00174] The Play orchestration 104 sends this message back to the Dealer Interface and the Dealer Interface displays the 4 cards in the message to the Dealer via the user interface and presents the Dealer with a confirm turn prompt to confirm that they match the four currently revealed community cards (see Exception handling for details on when these don't match).
Turn -><turn confirmed>

[00175] This message is sent back to Play orchestration 104 from the Dealer interface when the Dealer dismisses the confirm turn prompt.

[00176] The message can include the 4 cards that are actually shown in the community card zone. (see Exception handling for other details).
Turn -><turn ready>

[00177] Immediately after the <turn confirmed> message, the Dealer Interface presents a river ready prompt to the Dealer. The Dealer proceeds to manage the live game as they normally would by accepting bets, mucking folded hands, and controlling the game, etc.. When all the betting is completed and the Dealer is ready to show the river card the Dealer dismisses the river ready prompt and this results in this message being sent to Play orchestration 104.

[00178] Immediately after this prompt is dismissed another prompt is presented ¨
the river warning prompt.

Turn -><insurance check>

[00179] Once Play orchestration 104 receives the <turn confirmed> message from the Dealer Interface it immediately checks with the OddsBook 108 to see if insurance is an option. The OddsBook 108 receives the message which includes the four community cards and determines if insurance is available (i.e. if no hand has improved then insurance is an option otherwise it is not).
Turn -><insurance avail>

[00180] This is the response message from the OddsBook 108 and it includes a TRUE in the message if insurance is an option and FALSE otherwise.
Turn -><insurance ready>

[00181] If insurance is an option then this message can be sent from the OddsBook 108 to Wager Orchestration 106 to trigger the insurance option with the Observers.
Turn -><sell insurance>

[00182] This message is sent from Wager Orchestration 106 to all registered Observer devices to indicate that the Observer interface 110 should present an insurance option to the associated Observer. (see Observer interface diagram below).
The insurance option is presented as a simple yes/no dialog to the user on the user interface.

[00183] NOTE: Depending on the network architecture and the Observer interface technology this event may not be able to be pushed to all Observer interfaces.
Turn -><request ins>

[00184] This message is a request to the Wager Orchestration 106 to determine if insurance is an option. It is either a polling request or is done in response to the <sell insurance> or the <insurance clock> message depending on the network architecture and the technology of the Observer interface.
Turn -><insurance clock>

[00185] This message can be first pushed from the Play orchestration 104 system to the Wager Orchestration system 106 once the Play orchestration 104 receives the <turn ready> (or <river read>) message from the Dealer Interface. The <turn ready>
message indicates to the Play orchestration 104 that the Dealer is ready to reveal the next community card and so at this stage, if insurance is an option, a clock must be started at the Wager Orchestration 106 and Observer Interfaces 110.

[00186] This message is then forwarded to all registered Observer interfaces 110, where possible, and otherwise it is returned as a response to the <request ins>
message from Observer interface 110.

[00187] When the Wager Orchestration system 106 receives this message it starts an insurance clock, and includes a time value in the message payload that is some amount less than the insurance clock time (the amount can be configurable and preferably sufficient enough to accommodate for round trip time and processing time in order to ensure that the acceptance of insurance is complete before the Dealer produces the next community card).

[00188] When the Observer interface 110 receives this message it starts a visual countdown from the time provided. If the Observer interface 110 isn't already providing an insurance option dialog it can at this point. The Observer interface 110 will stop taking insurance once this timer expires.
Turn -><insurance closed>

[00189] This message can be sent from the Wager Orchestration 106 to the Play orchestration 104 system when the internal insurance clock expires and all insurance has been accepted or is being declined subsequently.

[00190] This message tells Play orchestration 104 that it is now timely for the Dealer to proceed with revealing the next community card.
The River Stage

[00191] The purpose of the River Stage of messages is to cue the Dealer to ensure the final composition of community cards to ensure the Hand Completion stage commences accurately.

River-><river proceed>

[00192] After receiving the <insurance closed> message from Wager Orchestration 106, Play orchestration 104 moves the hand into the "River"
stage and it sends <river proceed> to the Dealer Tablet.

[00193] This message can cause the Dealer Interface to release the river warning prompt and then prompts the Dealer to proceed with the river ¨ the river proceed prompt. At this point the Dealer first produces the community river card and then dismisses the prompt (NOTE: prompt can be automatically dismissed as the community zone RFID detects the river card).
River -><present river>

[00194] At this point the Play orchestration 104 may be aware of the river card as a result of messages from the hand detection and completion workflow. The <present river> message can be sent from the Dealer Interface to the Play orchestration once the Dealer dismisses the prompt on the Dealer Interface.

[00195] This message can include the river card that has been detected via the Dealer Tablet's RFID system as making up the community cards.
River -><confirm river>

[00196] The Play orchestration 104 sends this message back to the Dealer Interface and the Dealer Interface displays the 5 community cards to the Dealer via the user interface and presents the Dealer with a confirm river prompt to confirm that they match the five currently revealed community cards (see Exception handling for details on when these don't match).
River -><river confirmed>

[00197] This message is sent back to Play orchestration 104 from the Dealer interface when the Dealer dismisses the confirm river prompt.

[00198] This message can include just the identification of the final river card or alternatively all 5 community cards that are actually shown in the community card zone.
(see Exception handling for other details).

The Hand Complete Stage

[00199] The purpose of the messages of the Hand Complete stage is to cue the Dealer to conclude the hand and declare an ultimate winner of the hand so that the system can complete the clearing of the wagers.
Hand Complete-><hand complete>

[00200] This message can be sent from Play orchestration 104 to the Dealer Interface to indicate that it expects the hand to complete shortly. This message causes the Dealer Interface to prompt the Dealer to confirm the Players that are remaining at a showdown via the player showdown confirmation prompt or to indicate the only Player remaining after the final round of betting completes. See the Dealer Interface user interface diagrams below. The mechanism to indicate to Play orchestration the Players remaining in the hand is to select the icon that represents the Players visually on the interface of the Dealer Tablet. This is done in coordination with the hand detection and completion messages.
Hand Complete-><hand outcome>

[00201] While the Play orchestration 104 should be able to deduce the Player that wins the hand as a result of messages received via hand detection and completion, this message can be provided as a confirmation from the Dealer that the hand has concluded and can also include the Player identification (e.g. such as position of Player at the table) of either the outright winner or the Players left at showdown.

[00202] This message can be subsequently forwarded to the OddsBook 108 for determining the winner: 1) the result is obvious if only one Player remains due to betting, 2) the remaining hands are tied, or 3) there is one hand that is the best hand.
Hand Complete-><hand result>

[00203] The OddsBook 108 determines the winning Player based on the information provided in the <hand outcome> message received and returns the result in this message to the Play orchestration 104.

Hand Complete-><hand confirm>

[00204] With the expected winner now known to Play orchestration 104, this message can be sent to the Dealer Interface which results in a confirm winner prompt to prompt to the Dealer to confirm that they have indeed awarded the pot to the winner indicated.

[00205] NOTE: If the Dealer cannot confirm that the winner(s) possess the cards that the system proposes via the confirm winner prompt (see interfaces section below) then an exception situation is triggered. See exception handling below.
Hand Complete-><hand confirmed>

[00206] This message can be sent back to the Play orchestration 104 from the Dealer Interface when the confirm winner prompt is dismissed by the Dealer.
See Exceptions for handling extreme cases where the Dealer and the system do not agree.
Hand Complete-><hand adjudicated>

[00207] At this point the winner of the hand has been determined by the OddsBook 108 based on electronic information and confirmed by the Dealer via the Dealer Interface 208. This message can be sent from Play orchestration 104 to the Wager Orchestration system 106 and to the Clearing system 114 for processing.

[00208] When this message is received at the Clearing system 114 the hand result is reconciled with all the wagers received in the Pre-Flop-><wager approval>
requests and the Observers balance of funds is adjusted accordingly.
Hand Completed-><result ready>

[00209] When the <hand adjudicated> message is received by the Wager Orchestration system 106 it presents the individual results of the various wagers from each Observer by using the contents of this message along with the Pre-Flop-><odds book> message received earlier.

[00210] The Wager Orchestration 106 can push a <result ready> message to each Observer interface 110.

[00211] NOTE: This message may or may not be utilized depending on the network architecture and the technology used for creation of the Observer interface 110.
Hand Completed-><request result>

[00212] The Observer client, after receiving the <result ready> message, can then request the results of the hand from Wager Orchestration 106.

[00213] In architectures where the <result ready> message is not effectively pushed to the Observer interface 110, the Observer client can poll for the hand results on a regular interval using this message.
Hand Completed-><present result>

[00214] The Wager Orchestration 106 can sends this message in response to the <request result> message and it indicates to the Observer its results of its wager on the hand just completed.
Card detection and hand completion

[00215] In a preferred embodiment, the off-table betting system 100 performs in a preferred manner by allowing ready detection of hands and the determination of the completion of hands so that the Dealer can be cued via the Dealer interface to govern the game optimally for both Players and Observers.

[00216] As described above, in a preferred embodiment, the OTB table 124 is equipped with 6 (more or less) Player tablets 204, each with their own RFID
receiver 202 capable of detecting RFID signals from cards and other RFID enabled objects (e.g.
as may be used for example for authentication purposes) as they reach proximity to the tablet. The OTB table can also be equipped with a Dealer Tablet that provides up to 3 distinct zones for detecting: the community cards zone, the muck zone (where Player's cards are discarded), and the burn zone (where the Dealer discards a card between each of the Flop, Turn and River).

[00217] In this preferred embodiment, because there are up to 7 people at a table all acting independently and arbitrarily moving, possibly with cards in their hands, it is important that Play orchestration 104 explicitly instruct the OTB table devices 124 to read their respective zones and report what they discover in a controlled way.
For example, it is likely that some Player's will naturally fold their cards by tossing them through the Community Zone, and not necessarily directed to the muck.

[00218]
The above workflow regarding Game Control, assumes an orderly detection of Player's pocket cards, knowledge of folded cards, knowledge of the community cards, and knowledge of the contents of the muck.
Hand Begin Stage

[00219]
Reference is now made to Figure 13. This section describes the control messages in more detail. Emphasis is on fold detection after the Hand Begin stage of play.

[00220]
In general, after the Hand Begin stage of play, each Player will have been dealt pocket cards and the Player Tablet will continually run a state machine for detecting Player's pocket cards. See Hand Begin-><position cards> below (e.g.
in reference to Figure 13).

[00221]
At the beginning stage of each hand the dealer is dealing cards around the table. It is very plausible/likely that the Dealer will not perfectly throw the cards the same way every time and so even though each Player has a zone where RFID
detects cards, adjacent devices may also pick up cards intended for other Players as well.
Hand Begin -><card detected>

[00222]
These messages are sent from the RFID receiver 202 to the Player tablet 204 device as cards are detected during dealing of the pocket cards.
Hand Begin-><new card>

[00223]
This message goes from the Player Tablet 202 to the Play orchestration 104 to indicate that a Player has been dealt a card. Under ideal conditions, each Player Tablet detects exactly 2 cards and notifies Play orchestration 104 of those 2 cards and those 2 cards are in fact the Player's pocket cards. However, at this point, Play orchestration 104 cannot be certain of this. At this point Play orchestration 104 can only be certain that:

1. Dealing of pocket cards has begun and 2. If all messages together indicates a set of distinct card pairs with cardinality equal to that of the cardinality of the Players, that then dealing of the pocket cards has completed.

[00224] Under most operating conditions this will be the case.
Hand Begin-><flop ready>

[00225] As indicated from the prior workflow, this message is sent from the Dealer tablet 208 when the Dealer dismisses the flop ready prompt.

[00226] This confirms to the Play orchestration 104 that dealing of pocket cards is complete and that each Player should be able to produce exactly 2 distinct pocket cards (provided they have not instantly folded).
Hand Begin ¨><position cards>

[00227] This message can be sent from the Play orchestration 104 to each Player tablet 204 after receiving the <flop ready> message from the Dealer tablet.

[00228] At this point each Player Tablet 204 interface can prompt the respective Player to position their pocket cards precisely over their respective zone via the position cards prompt. At time the Player tablet 204 processes the RFID signals via reader 202 to detect exactly 2 cards. This cycle continues until either the Player confirms, via the interface prompt, that it has folded or until the Player tablet successfully identifies the 2 pocket cards.

[00229] NOTE: Optionally, at this point the Player tablet 204 can visually display the representation of the pocket cards to the Player and have the Player confirm the cards. However, it is not expected that this will be required, nor is it expected that this would be particularly appealing to the Players since it may increase the possibility of exposing the pocket cards to other Players.
Fold detection

[00230] Once all Players have been dealt pocket cards (post Begin Hand), it is possible for a Player to fold at any time. Even though a game protocol is in place it is still possible for Players to fold out of turn or before pocket cards can be determined for certainty by the system.

[00231] Consequently, a key to hand detection and completion is the determination of folded cards.
<fold>

[00232] At any time after the Hand Begin stage the Play orchestration 104 can receive a <fold> messages from any one of the Player tablets 204.

[00233] If the Player still holds their cards, but outside of the pocket card detection zone for too long, the <fold> message can still get sent from the Player tablet 204 regardless of the Player's active confirmation via the did-you-fold prompt.
<confirm fold>

[00234] This message is sent from the Play orchestration 104 to the Dealer Tablet 208 after receiving a <fold> message from a Player tablet 204.

[00235] At this point the Dealer interface can display a user interface that highlights the Player graphically on the Dealer interface and prompts the Dealer to confirm that the Player has in fact folded (confirm-player-folded prompt).
Further detail is provided in the Figures illustrating the Dealer User Interface diagrams.
<fold confirmed>

[00236] This message can be sent from the Dealer tablet 208 once the Dealer has either confirmed or reversed the implication that the associated Player folded.

[00237] At this point, in order to reverse the implicated fold, the Dealer will instruct the Player to return their cards to their associated pocket card zone.

[00238] If confirming the fold, the Dealer can explicitly move the cards folded to the muck zone, and then confirm that the associated Player folded by taking the action on the Dealer interface.

[00239] The <fold confirmed> message can include a Boolean value true or false indicating whether or not an indicated Player actually has folded.

Flop Stage

[00240] During this stage, detection of the first three community cards is separated from detection of the folded cards.
Flop-><flop proceed>

[00241] When the Dealer tablet 208 receives this message it can be used to enable the community card zone RFID reader and the Dealer can proceed to burn one card and then produce the 3 flop cards in the community card zone.

[00242] It is at this point where Players may disrupt the process by tossing their pocket cards into the community card zone with the, albeit ignorant, intention of folding.
Flop-><card detected>

[00243] As cards are produced in the community zone the RFID receiver sends these messages to the Dealer tablet 208. Once at least 3 messages of this type are detected the Dealer Interface can present the Dealer with a present flop prompt. This prompt is used to give the Dealer time to clear any mucked cards in the community zone and move them to the muck zone before having the Dealer tablet 208 send the flopped cards to the Play orchestration 104.
Flop-><present flop>

[00244] Once the Dealer has moved all other cards to the muck zone and has shown all three flop cards in the community zone, the Dealer dismisses the present flop prompt and this message is sent from the Dealer tablet 208 to the Play orchestration 104 to reveal to the system the community cards.
Flop-><confirm flop>

[00245] This message can be provided as a confirmation message that echoes the community cards received in the <present flop> message back to the Dealer Interface.
The Dealer Interface presents to the Dealer the cards that it believes are the community cards. The Dealer then dismisses this prompt for the hand to continue.

[00246] NOTE: In one embodiment, if, in the rare circumstances, the Dealer is presented with more cards in this message than are actually in the community zone then the Dealer can disclose the additional cards as accidentally exposed cards before the hand can proceed. (This is similar to when cards are physically exposed.
The reason is because it is very plausible that Players are able to see what is presented on the Dealer tablet 208 interface. If even one Player sees the additional cards then to be fair to the game all Players must be aware of the card. This should not affect the efficacy of the OTB game.) Flop-><flop confirmed>

[00247] This message can be sent after the Dealer confirms the cards that were physically shown as the flop in the community zone via the flop confirmation prompt.
Further detail is provided in the Figure illustrating the Dealer User Interface ¨ Flop Confirmation diagram.
Turn Stage

[00248] During this stage, detection of the four community cards is separated from the folded pocket cards.
Turn-><turn proceed>

[00249] When the Dealer tablet 208 receives this message it can enable the community card zone RFID reader and the Dealer proceeds to burn one card and then produce the fourth turn card in the community card zone.

[00250] It is at this point where Players may disrupt the process by tossing their pocket cards into the community card zone with the, albeit ignorant, intention of folding.
Turn ->< turn detected>

[00251] As cards are produced in the community zone the RFID receiver 202 can send these messages to the Dealer tablet 208. Once at least 1 message of this type is detected the Dealer Interface presents the Dealer with a present turn prompt.
This prompt is used to give the Dealer time to clear any mucked cards in the community zone and move them to the muck zone before having the Dealer tablet 208 send the community cards to the Play orchestration 104.
Turn -><present turn >

[00252] Once the Dealer has moved all other cards to the muck zone and now shows four cards in the community zone, the Dealer dismisses the present turn prompt and this message is sent from the Dealer tablet 208 to the Play orchestration 104 to reveal to the system the community cards.
Turn -><confirm turn >

[00253] This message can be provided as a confirmation message that echoes the community cards received in the <present turn> message back to the Dealer Interface.
The Dealer Interface presents to the Dealer the cards that it believes are the community cards. The Dealer can then dismisses this prompt for the hand to continue.

[00254] NOTE: If, in the rare circumstances, the Dealer is presented with more cards in this message than are actually in the community zone then the Dealer can disclose the additional cards as accidentally exposed cards before the hand can proceed. (This is similar to when cards are physically exposed. The reason is because it is very plausible that Players are able to see what is presented on the Dealer tablet 208 interface. If even one Player sees the additional cards then to be fair to the game all Players must be aware of the card. This should not affect the efficacy of the OTB
game.) Turn ->< turn confirmed>

[00255] This message is sent after the Dealer confirms the cards that were physically shown as the turn in the community zone via the turn confirmation prompt.
Further detail is provided in the Figure illustrating the Dealer User Interface ¨ Flop Confirmation diagram.
Turn Stage

[00256] During this stage, detection of the four community cards is separated from detection of folded pocket cards from.
River->< river proceed>

[00257] The Dealer tablet 208 can receive this message to enable the community card zone RFID reader 202 and the Dealer proceeds to burn one card and then produce the fifth and final river card in the community card zone.

[00258] It is at this point where Players may disrupt the process by tossing their pocket cards into the community card zone with the, albeit ignorant, intention of folding.

River ->< river detected>

[00259] As cards are produced in the community zone the RFID receiver sends these messages to the Dealer tablet 208. Once at least 1 message of this type is detected the Dealer Interface can present the Dealer with a present river prompt. This prompt is used to give the Dealer time to clear any mucked cards in the community zone and move them to the muck zone before having the Dealer tablet 208 send the community cards to the Play orchestration 104.
River -><present river >

[00260] Once the Dealer has moved all other cards to the muck zone and now shows four cards in the community zone, the Dealer can dismiss the present river prompt and this message is sent from the Dealer tablet 208 to the Play orchestration 104 to reveal to the system the community cards.
River -><confirm river >

[00261] This message can be provided as a confirmation message that echoes the community cards received in the <present river> message back to the Dealer Interface.
The Dealer Interface presents to the Dealer the cards that it believes are the community cards. The Dealer then dismisses this prompt for the hand to continue.

[00262] NOTE: If, in the rare circumstances, the Dealer is presented with more cards in this message than are actually in the community zone then the Dealer can disclose the additional cards as accidentally exposed cards before the hand can proceed. (This is similar to when cards are physically exposed. The reason is because it is very plausible that Players are able to see what is presented on the Dealer tablet 208 interface. If even one Player sees the additional cards then to be fair to the game all Players must be aware of the card. This should not affect the efficacy of the OTB
game.) River ->< river confirmed>

[00263] This message can be sent after the Dealer confirms the cards that were physically shown as the turn in the community zone via the river confirmation prompt.
Further detail is provided in the Figure illustrating the Dealer User Interface ¨ Flop Confirmation diagrams.

Hand Complete

[00264]
At this stage the Play orchestration 104 can be aware that the river has been produced and that the final round of betting is occurring. If all but one Player folds, the hand outcome may be deduced by Play orchestration 104 via the fold detection mechanisms described above.
Regardless, the messages for hand completion as described in the prior workflow set Game Control are still required since the order of folding may not necessarily coincide with declaration of the winning hand in a showdown situation.

[00265]
This stage involves conclusion of the hand and can also involve confirmation of the hand outcome by the Dealer. With respect to hand detection and completion the relevant messages in this stage can simply involve the fold detection mechanisms described above.
Exception Handling Big Blind Folds

[00266]
Problem if wagers are taken on Big Blind (BB) and they fold before the flop is presented. In this case all wagers are pushed back.
Pocket Card Detection Failure

[00267]
At showdown, if actual cards don't match what the system detected then the winners are paid and all other bets are pushed back. i.e. it costs the system to be wrong.
Accurate Accounting and Balance of Funds

[00268]
Requests from Wager Orchestration 106 to Clearing & Accounting 114 and 122 for balance of funds Real-time Odds Calculations

[00269] To ensure game and derivative game flow and efficacy the calculation of odds and presentment of odds should be near real-time and accurate.

Disparate Observers

[00270] In a preferred embodiment, the OTB system 100 allows Observer to place wagers from any location where Internet access is available. To ensure minimal game disruption, authentication is preferably quick.
To ensure wager efficacy the authorization of observers is also preferably quick and reliable.
Observer Volume and latent networks

[00271] In a preferred embodiment, potentially thousands of Observers via the OTB system 100 are allowed to place wagers on hands in real-time. This must be done without disrupting the game and accurately to maintain wager efficacy.
Player Value

[00272] As will be understood, Players make concessions to accommodate the OTB derivative game. To compensate, additional value can be provided to the Players through the Player Interface 204.
User Interface Designs

[00273] The following provides exemplary snapshots of user interface displays provided by the dealer tablets 208 as the off-table betting system 100 progresses during a game.
Dealer and Player Prompts Summary

[00274] Dealer and player prompts that can be provided on the user interface of the Dealer and Player interfaces are summarized in Figure 18. The name of the prompt is provided as the "Ul Name", the Player or Dealer interface component is identified by "Ul Component", and notes are provided describing use of the prompts.
Dealer Ul Prompts

[00275] Dealer Ul Prompt diagrams that can be used in some embodiments are detailed in Figures 19a-19q.
Figure 19a - Dealer Ul- hand begin prompt

[00276] Dealer can press the "ok" button to indicate that dealing has begun.

Figure 19b - Dealer Ul - flop ready prompt

[00277] Dealer can press the "ok" button when they are ready to produce a flop ¨
i.e. all pre-flop betting has taken place.
Figure 19c - Dealer Ul - flop warning prompt

[00278] This prompt can have an audible beep and may flash the dialog to keep the Dealer's attention. If the Dealer produces the flop while this dialog is present then the Dealer presses the "Exception" button to trigger the Exception Handling process.
Figure 19d - Dealer Ul - muck confirmation prompt

[00279] This prompt may overlay other prompts at various stages of game control.
The Dealer can press the "Hands Mucked" button to dismiss the prompt after moving all discards to the Muck Zone. The Player icons without the card annotation to the top right are the Players that the system is deducing have folded.
Figure 19e - Dealer Ul - present flop prompt

[00280] Dealer can press the "ok" button to dismiss this prompt before or after producing the flop cards.
Figure 19f - Dealer Ul ¨ confirm flop prompt

[00281] The Dealer can either presses the "Exception" button if the cards presented in the dialog do not match what are actually revealed in the community zone or, the Dealer can touch each and every card that is active thereby confirming each card. In this model, card images can be presented with a black border to indicate they are active. Once touched the border can disappear, the card image becomes no longer touch sensitive and the system registers the card as correct. Other mechanisms could be used to indicate a card as not-yet-confirmed (i.e. "active") such as lightening the color of cards already confirmed.

[00282] NOTE: It is possible that more than three cards are presented in this dialog. This can occur if Muck Confirmation did not happen in a timely way. In this case the Dealer selects the three cards that are exposed as the flop cards and can then declare the additional card(s) as exposed to the Players.

Figure 19g - Dealer Ul ¨ turn ready prompt

[00283] Similarly to the flop ready prompt, the Dealer can press the "ok"
button after all betting is complete after the flop and the Dealer is ready to reveal a turn card.
Figure 19h - Dealer Ul - turn warning prompt

[00284] Similarly to the flop warning prompt, the Dealer can press the "Exception"
button if they reveal the turn card while this prompt is still present.
Otherwise the Dealer pauses until this dialog can be automatically dismissed by the system and the Ul changes to clear the Dealer to present the turn card.
Figure 19i - Dealer Ul ¨ turn proceed prompt

[00285] Similarly to the flop proceed prompt, the Dealer can press the "ok" button before or after revealing the turn card. The muck confirmation prompt can be present atop of this dialog initially. Once the muck is confirmed then this dialog can be presented.
Figure 19j - Dealer Ul ¨ confirm turn prompt

[00286] Similarly to flop confirmation, now on the turn, the Dealer can confirm the turn card.

[00287] NOTE: It is possible that more than four cards are presented in this dialog. This can occur if Muck Confirmation did not happen in a timely way. In this case the Dealer can select the one card that is the turn card and can then declare the other card(s) as exposed to the Players.
Figure 19k - Dealer Ul - river ready prompt

[00288] Similarly to the flop ready prompt, the Dealer can press the "ok"
button after all betting is complete after the turn and the Dealer is ready to reveal a river card.
Figure 191 - Dealer Ul - river warning prompt

[00289] This prompt can have an audible beep and can flash the dialog to keep the Dealer's attention. If the Dealer produces the river while this dialog is present then the Dealer can press the "Exception" button to trigger an Exception Handling process.

Figure 19m - Dealer Ul - present river prompt

[00290]
Dealer can press the "ok" button to dismiss this prompt before or after producing the river card.
Figure 19n - Dealer Ul ¨ confirm river prompt

[00291]
Similarly to turn confirmation, now on the river, the Dealer can confirm the river card.

[00292]
NOTE: It is possible that more than five cards are presented in this dialog.
This can occur if Muck Confirmation did not happen in a timely way. In this case the Dealer can select the one card that is the river card and can then declare the other card(s) as exposed to the Players.
Figure 190 - Dealer Ul - player showdown confirmation prompt

[00293]
The Dealer can touch each Player icon that represents each Player about to go to showdown. When touched a context menu can be provided and the Dealer can either indicates that the Player is showing down or is folding. When the status of each Player remaining with cards is set then the Dealer can press the "Done"
button.

[00294]
In the event that a Player icon is greyed out without cards but the actual Player has cards then this can result in an Exception situation, the Dealer can press the "Exception" button, and Exception Handling can be triggered and the wagers are pushed back

[00295]
NOTE: This screen may change dynamically based on fold detection.
That is, if a Player folds during the final round of betting while this dialog appears to the Dealer, the fold confirmation prompt can overlay this dialog and then when the fold is confirmed the status of this dialog can be modified accordingly.
Figure 19p - Dealer Ul - confirm winner prompt

[00296]
In the case where there was a showdown between two or more Players the Ul can show the pocket cards of all Players at showdown.

[00297]
The Dealer can press the "Confirm" button to confirm the winner. In the case where the displayed pocket cards do not match the actual cards then the Dealer awards the hand as they normally would but should press the "Exception" button at completion so that wagers can be pushed back.
Figure 19q - Dealer Ul ¨ fold confirmation prompt

[00298] Dealer can press "Confirmed" button if the highlighted Player has folded and the Dealer has mucked the cards. Dealer can press "False" button if the highlighted Player has not folded.
Player Ul Prompts

[00299] Player Ul Prompt diagrams that can be used in some embodiments are detailed in Figures 19a-19q.
Figure 19r - Player Ul ¨ Have you folded prompt

[00300] This dialog can be shown on the Player Interface when the RFID
system detects that the cards are not within vicinity of the Player. As a convenience it can show the community cards and highlights the Player's position at the table. The Player can press "Yes" button if they have folded. The Player can press the "No" button if they have not intended to fold ¨ in which case they can be instructed to subsequently return their cards to within vicinity.
Figure 19s - Player Ul ¨ position cards

[00301] The Player can be instructed to position their cards in vicinity to their person (i.e. "Please place your cards in the 'pocket zone") and this prompt can disappear when the cards are detected via RFID (e.g. RFID Reader 202). After a short period of time the have you folded prompt reappears if the cards are not detected.
Observer User Interface

[00302] Referring now to Figure 15, an exemplary layout of the observer user interface is provided. It should be obvious that other alternative layouts exist for the Observer User Interface. For example, the main table video can be centrally located with the Players tiled along the side.
Alignment of AudioNide and Digital Game Events

[00303] The audio/video from the game and the game event data are processed and transmitted at different rates. In particular, video can require significant amounts of processing before it can be consumed in a standardized way at the Observer User Interface (e.g. a web browser). The challenge then becomes ensuring that digital game events, such as card detection and presentment are sufficiently paused to align with the corresponding audio and video that represents the game. This issue is further illustrated in Figure 16.

[00304] One solution to this data alignment problem can be to introduce a variable determinant that specifies a delay in the consumption of the Game Event Data at the target. Figure 17 provides a process diagram that illustrates how the Determinant can be computed. A table camera subsystem 900 produces a bundle of video frames and associates them with a vector time value VTi. VTi is requested and received from a shared Vector Time Service 901. The frame bundle is received by the Video Composer 902 within the Observer Presentation System 904. The Video Composer compiles the video frames into a video format that can be consumed by the Observer User Interface 906. At the time the video clip is created a vector time VTj is requested from the shared Vector Time Service 902. Using the VTj and the VTi received with the frame bundle a Determinant can be calculated. The Determinant is some function of the parameter x=VTj-VTi and may be, but not likely, simply equal to x. The function of x likely considers other variables such as average latency between the Observer Presentation System 904 and the Observer Ul 906. The Determinant is pushed into the Game Event Data Handler 903. The Game Event Data Handler 903 uses the Determinant to delay the emitting of event messages to the Observer User Interface 906.

Claims (8)

CLAIMS:

1. A method for providing off-table betting of a live real-time game played by a plurality of players and associated dealer to observers via their computing device physically located externally to the game being played, the method comprising:
(a) Providing real-time video streaming of the game as it is being played to each observer's computing device;
(b) Detecting the cards being played at each hand via a plurality of RFID
readers each associated with each player's computing device and communicating the cards to each observer's computing device via secure messaging means;
(c) Calculating and presenting odds to each observer's computing device and observer's user interface after a hand is played and in real-time, and, following a pre-defined amount of time, requesting and receiving wagers in real-time for each hand being played from each observer's computing device provided by the corresponding observer; and (d) Presenting notification messages on a dealer user interface of the dealer's computing device for delaying the game for the pre-defined amount of time thereby allowing wagers to be received.

2. The method of claim 1 wherein the wagers are received in real-time based on the odds for each player's hand improving and winning.

3. The method of claim 1, wherein the method further comprises authenticating each observer against a database of credentials for determining whether a wager can be received from the observer.

4. The method of claim 1 wherein the observer computing device and the dealer computing devices are synchronized.

5. The method of claim 1 wherein the game event data is delayed for a determinant amount of time to align to the video stream.

6. The method of claim 1 wherein the method further comprises denying further receipt of wagers subsequent to the expiry of the pre-defined amount of time.

7. A computer system configured to perform a method in accordance with any of the preceding method claims.

8. A computer storage medium, including a memory configured to store instructions for configuring a computer system to perform a method in accordance with any of the preceding method claims.