Electronic Banking Management For Betting Games

Abstract

Electronic banking management for betting games is described. In one implementation, a multiparticipant electronic gaming table has a banking engine that dynamically determines current participants and authenticates qualified participants as banker candidates. The banking engine tracks game flow in order to determine when to offer the banking role to other participants. In one implementation, the system has an accounts manager that tracks wagers during the game, updates participant account balances, tracks transactions of each participant holding the banking role, and balances the bank of each participant in the banking role.

Description

BACKGROUND

In some gambling games, such as Poker, players compete against each other for the best card combination. In other gambling games, such as Baccarat and Blackjack, the participants bet on having better cards than the dealer or banker. In “banking” games, there is one participant who assumes the role of banker. This participant-banker competes against each of the other participants individually. Often the banker has a slight built-in advantage over the other participants. Many casino and card room games are banking games.

Banking games can include, for example, the above-mentioned Baccarat and Blackjack, and also Pai Gow Poker; Red Dog/High Card Pool/Slippery Sam/Shoot in which the participant bets that one of his cards will be higher than and the same suit as a card turned by the banker; Quitlok (Kvitlech); Yablon/In Between/Ace-Deuce in which the participant bets on whether a third card will be between the first two cards dealt; Let It Ride in which the participant combines his three cards with the dealer's two cards, and is paid at fixed odds according to how good a poker hand they make; Caribbean Poker in which the participant wins if five cards form a better poker hand than the banker's five cards; Three-Card Poker in which the participant forms poker-like combinations with three cards, and tries to beat the dealer's three cards; and Casino Hold'em Poker in which the participant and banker are each dealt two cards and make the best poker hand they can out of these and five shared cards.

In many jurisdictions, banking card games fall within Class III gaming. For example, in participant-banked Blackjack, participants do not play against each other, but play against the participant-banker. The participant-banker has a certain percentage advantage over all other participants similar to the advantage that the “house” or gaming operation has in traditional Blackjack. This banker advantage is a fundamental characteristic of banking games. The establishment hosting the gaming operation typically does not participate in, or have any interest in the outcome of the participant-banked game. The establishment usually makes money by collecting an ante from each participant per hand. One of the participants takes on the role of banker, collecting all losses and paying all winnings.

In some places, organizations underwrite or provide participants to act as “corporate bankers” in participant-banked betting games. Such a corporate banker typically carries around a large case of wagering chips, i.e., “the bank” to be used in the participant-banked game. Although such sponsored banking creates profit because of the odds advantage given to the participant-banker, there are some disadvantages in conventional participant banking. It is relatively easy for the participant-banker to cheat, either alone or in collusion with others, when leveraging the chips or funds that belong to an organization. In some gambling localities, such organizations that back banking games lose several million dollars per month to the dishonesty of the corporately backed participant-bankers and mishandling of the banking transactions in a game.

SUMMARY

Electronic banking management for betting games is described. In one implementation, a multiparticipant electronic gaming table has a banking engine that dynamically determines current participants and authenticates qualified participants as banker candidates. The banking engine tracks game flow in order to determine when to offer the banking role to other participants. In one implementation, the system has an accounts manager that tracks wagers during the game, updates participant account balances, tracks transactions of each participant holding the banking role, and balances the bank of each participant in the banking role.

This summary section is not intended to give a full description of the electronic banking management for betting games, or to provide a list of features and elements. A detailed description of example embodiments of the electronic gaming system follows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a top view of a multiparticipant electronic gaming table that includes an exemplary banking engine.

FIG. 2 is a top view of another multiparticipant electronic gaming table that includes the exemplary banking engine.

FIG. 3 is a block diagram of an exemplary game processing system for multiple participants, including an exemplary banking engine.

FIG. 4 is a block diagram of an exemplary game processing system of networked individual playing stations, including the exemplary banking engine.

FIG. 5 is a block diagram of another exemplary game processing system of networked gaming machines that each accommodate multiple participants, including the exemplary banking engine.

FIG. 6 is a block diagram of the exemplary banking engine of FIGS. 1-5, in greater detail.

FIG. 7 is an exemplary method of electronic banking management for betting games.

DETAILED DESCRIPTION

Overview

This disclosure describes electronic banking management for betting games. An example system has a banking engine or applies exemplary methods that manage participant-banked betting games, such as Baccarat, Blackjack, Pai Gow Poker, etc., as played around an electronic gaming table in a card room or casino.

In one implementation, an exemplary system has a participant tracking engine that keeps a list of current participants, and a list of participants authorized and willing to bank a particular round of a game. In a given banked card game, whether played with real cards or electronic virtual cards, a primary banker is assigned (voluntarily) and a secondary or even tertiary banker may also volunteer to be assigned. “Banker” as used herein refers to the participant who is acting as banker in a particular round of a game, but the banker for a particular round is not necessarily a player in that round, or a player in any round.

In one implementation, the banking engine or system graphically rotates an offer to be banker around a multiplayer setting. In another implementation or mode, the banking engine authenticates participants to be potential bankers, and then accepts designation of the next banker via a live host. The live host can rotate the banking position by physically offering the banking position among the participants. The live host then resets the banking position by actuating a switch, such as a touch screen icon, a shoe key, or a shoe button.

In some legal jurisdictions, game play may only proceed two rounds or two “playing hands” before the banking responsibility must be offered around the table. This theoretically provides fairness, as each participant can then bet first, be dealt last, etc.

The exemplary banking engine tracks games, playing hands, recent banking history, and much of the information about games played, e.g., wins, losses, wagers, etc., so that a great deal of information can be used to administer and track participant banking. An electronic gaming table that includes the exemplary banking engine can automatically sense when banking should be offered to other participants and can implement solicitation of the next participant-banker. In one implementation, the banking engine can manage the participant banking along a spectrum that includes fully-hosted table games to non-hosted table games. For example, a live host can be used to offer the banking role to participants determined by the banking engine and at a time and sequential order determined by the banking engine. Or, the live host can allow components of the banking engine to offer the banking role around the table. The exemplary banking engine tracks the banking role and its movement among participants, as well as banker solicitation and banking transactions and also resets the parameters for deciding when to next solicit a new banker as appropriate.

In one implementation, the exemplary banking engine displays a current banker icon, marker, or “puck” on the current banker's visual display, or on each participant's display, and/or on a common display for all at the table to view. The banking engine can display a “solicit banker” menu or set of options to each participant in turn as it solicits a new participant-banker. The banking engine can also generate a user interface for the current participant-banker, to provide the current banker the option of passing the banking role after one playing hand or, e.g., after two playing hands.

In one implementation, the exemplary banking engine passes around an offer to bank to each individual participant in order of active playing positions and tracks who is in an active playing position by whether they have money on the table. If the participant has money that has already been put on the table then they are in an active position, so banking is offered to such participants.

In one implementation, besides managing a primary banking role, the banking engine designates a secondary bank and typically designates a corporate banking position as the secondary bank. The secondary bank may be explicitly locked by the electronic gaming machine to a specific player position designated as the corporate bank. In another implementation, the banking engine designates a tertiary bank. Under some playing rules, the primary banking role passes or at least is offered to other participants at least after every two hands of the particular game. An exemplary lock-out feature stops the gaming action and calls an administrator for a reset, for example, if an offer to take the banking role passes around the group of participants, e.g., twice, without anyone accepting the banking role.

In one implementation, without a live host or dealer, an offer rotation component of the banking engine includes a timer to pass the banking solicitation around in a sequence, unassisted. In another implementation, the banking engine solicits all participants at once for a set time interval, temporarily offering a touch screen to each viable banking candidate to allow anyone qualified to select whether they want to be considered a banker or not.

In one implementation, an exemplary electronic gaming table system has the option of accepting fees, such as an ante or a rake. The system also has the option of not accepting fees, e.g., when the gaming table can create additional profit by dealing many more hands than conventional gaming tables by using virtual cards displayed on the participants' user interfaces instead of real cards. Such an implementation of an exemplary gaming table system that has the banking engine may attract more participants because the participants can save money by foregoing the per-hand ante or rake fees. In one implementation, a fee can be set according to a schedule that includes a number of bet ranges that determine the fee. Fees can be enabled or disabled depending on whether the house wants to collect a fee or not.

The exemplary banking engine can track wagers in real time and keep track of each participant's monetary balance. The banking engine can also track the transactions of each current bank, as the banking role is passed between participants, and balance each bank's transactions.

Example Systems

The exemplary banking management systems and methods to be described below can be used with wagering games, such as those games that are playable on multiparticipant electronic gaming tables. For example, the exemplary banking management systems and methods described herein can be used on table game platforms such as those described in U.S. Pat. No. 5,586,766 and U.S. Pat. No. 5,934,998 to Forte et al.; and U.S. Pat. No. 6,165,069, U.S. Pat. No. 7,048,629, and U.S. Pat. No. 7,255,642 to Sines et al., each of these incorporated herein by reference.

FIG. 1 shows an example layout of an electronic gaming table 100. The illustrated example gaming table 100 has a size that seats eight participants maximum. Other implementations can seat a different number of participants. The gaming table 100 has a user interface for each participant, i.e., participant user interfaces 102, 104, 106, 108, 110, 112, 114, and 116. A participant's user interface 102 may consist of an electronic display for presenting visual images and may further consist of a touch screen display for interactive capability. Depending upon implementation, each participant user interface 102 may also include various other forms of interactive interface, such as pointing devices, light sensors, wagering chip sensors, etc.

The illustrated example gaming table 100 also includes a common display 118 in the center of the gaming table 100, for presenting visual information to all participants. The common display 118 may present general information redundantly in two, four, or more visual orientations so that the displayed information is oriented correctly for each participant.

The example electronic gaming table 100 of FIG. 1 has an example layout that is useful for unhosted card games, although using a live dealer at gaming table 100 is not ruled out. The example gaming table 100 as shown typically uses virtual playing cards and virtual chips. However, the gaming table 100 can be configured to use any combination of real playing cards, virtual playing cards, real wagering chips, and/or virtual gaming chips. When real playing cards are used, a live shoe that reads the identity of each card sends the card identity information to the electronic processor (not shown) that runs the game. When real wagering chips are used, light sensors, optical sensors, scanning technology, weigh cells, RFID technology, etc., may be used with specially constructed chips or conventional standard chips to sense chip presence and chip values.

In FIG. 1, “participant 2” has been designated as the participant-banker by the exemplary banking engine 120 located in or under the table in the electronics of the gaming table 100. The banking engine 120 displays a “banker” icon, text, or marking 122 on the current banker's user interface 104. The banker marking 122 may also be displayed on the common display 118 and/or on each of the other participants' displays.

FIG. 2 shows another example layout of an electronic gaming table 200. In the illustrated example gaming table 200, multiple user interfaces 202, 204, 206, 208, 210, and 212 form a semi-circular array for seating participants. The participant user interfaces may consist of electronic visual displays with touch screen capability or other forms of user interface. The example gaming table 200 is shaped to accommodate a live dealer on the opposing side of the semi-circular array, but using a live dealer or host is not required. When the example gaming table 200 is not hosted, a common display 214 can be included on the side opposing the participants'semi-circle.

In FIG. 2, “participant 2” has been designated the participant-banker by the exemplary banking engine 120 located in or under the table in the electronics of the gaming table 100. The banking engine 120 displays a “banker” icon, text, or marking 122 on the current banker's user interface 204. The banker marking 122 may also be displayed on the common display 214 and/or on each of the other participants' displays.

FIG. 3 shows an example game processing system 300 that can be included in the gaming tables 100 and 200. The game processing system 300 includes the exemplary banking engine 120. The illustrated configuration of the exemplary game processing system 300 is meant to provide only one example arrangement for the sake of overview. Many other arrangements of the illustrated components, or similar components, are possible within the scope of the subject matter. Such an exemplary game processing system 300 can be executed in hardware, or combinations of hardware, software, firmware, etc.

The exemplary game processing system 300 includes a computing device 302, which may be a desktop, server, or notebook style computer, or other device that has processor, memory, and data storage. The computing device 302 thus includes a processor 304, memory 306, data storage 308; and interface(s) 310 to communicatively couple with the participant “1” user interface 102, the participant “2” user interface 104, . . . , and the participant “N” user interface 312. The game processing system 300 includes a gaming engine 314, game rules 316, and the exemplary banking engine 120, shown as software loaded into memory 306.

The interfaces 310 can be one or more hardware components that drive the visual displays and communicate with the interactive components, e.g., touch screen displays, of the multiple participant user interfaces 102, 104, . . . , 312.

FIG. 4 shows another example game processing system 400 that can be included in the gaming tables 100 and 200, or that can be implemented as a network of individual playing stations. The game processing system 400 includes the exemplary banking engine 120. The illustrated configuration of the exemplary game processing system 400 is meant to provide only one example arrangement for the sake of overview. Many other arrangements of the illustrated components, or similar components, are possible within the scope of the subject matter, e.g., that shown in FIG. 3. In FIG. 4, such an exemplary game processing system 400 can be executed in hardware, or combinations of hardware, software, firmware, etc.

The exemplary game processing system 400 includes a server computing device 402, which can be a computer or other device that has processor, memory, and data storage. The server computing device 402 thus includes a processor 404, memory 406, data storage 408, and an interface, such as a network interface card (NIC) 410, to communicatively couple over a network 412 with remote computing devices, such as computing device “1” 414 that hosts the participant “1” user interface 416; computing device “2” 418 that hosts the participant “2” user interface 420; . . . ; and computing device “N” 422 that hosts the participant “N” user interface 424. The game processing system 400 includes a gaming engine 314, game rules 316, and the exemplary banking engine 120, shown as software loaded into memory 406.

The participant computing devices 414, 418, and 422 may be desktop or notebook computers, or may be workstations or other client computing devices that have processor and memory, but may or may not have onboard data storage. Typically, a player station does not have data storage. Such modules may be “dumb” in that they have no bootable device, communicate with the game banking engine 120, but receive images and instructions from the server 402. Thus, in one implementation, a player computing device 414 are visual displays with graphics processing power and user interface components.

FIG. 5 shows another example game processing system 500, consisting of a network of gaming machines that each may have “n” players. The game processing system 500 is similar to that shown in FIG. 4, except that the client nodes of the network 412 are multiplayer gaming machines (e.g., 100 and 200) instead of individual gaming stations. That is, each node of the network 412 can accommodate multiple players. In another implementation, the network 412 has a mixture of client nodes consisting of individual playing stations as in FIG. 4 and multiplayer gaming stations as in FIG. 5.

FIG. 6 shows the exemplary banking engine 120 of FIGS. 1-4 in greater detail. The illustrated configuration of the exemplary banking engine 120 is meant to provide only one example arrangement for the sake of overview. Many other arrangements of the illustrated components, or similar components, are possible within the scope of the subject matter. Such an exemplary banking engine 120 can be executed in hardware, or combinations of hardware, software, firmware, etc.

The exemplary banking engine 120 includes a participant tracking engine 602, a game tracking engine 604, an accounts manager 606, and a banker rotation manager 608. It is worth noting that other implementations of the banking engine 120 may not possess or may not use all of the illustrated components. For example, in one implementation, the banking engine 120 rotates the banker role around an electronic gaming table 100 or 200 without using the accounts manager 606.

The participant tracking engine 602 may further include a current participant list 610, a banking candidate authenticator 612, a list of banker candidates 614, and list of current banker(s) 616, including a primary banker 618 and a secondary banker 620; . . . ; and tertiary banker (if desired).

The game tracking engine 604 may further include a playing hand tracker 622 and a win/loss tracker 624. The accounts manager 606 may further include a wager tracking engine 626, a database of participant balances 628, a banked wagers tracker 630, and a bank balancer 632.

The banker rotation manager 608 may further include a playing hand counter 634, a manual offer interface 636, banker assignment history 638, an offer rotator 640, and a user interfaces controller 650. The offer rotator 640 may further include a banker solicitation manager 642, a timer 644, a loop counter 646, and a lock-out module 648.

The user interfaces controller 650 may further include a banker solicitation interface disparticipant 652 and a current banker icon disparticipant 654.

Example Operation of the Banking Engine

The exemplary banking engine 120 is directed toward managing banking games when played on multiparticipant electronic gaming tables, such as gaming tables 100 and 200.

In one implementation, the banking engine 120 initializes with input of the identity, table position, and account credentials of a starting banker. The participant tracking engine 602 uses available login and/or presence information to compile a dynamic list of current participants 610. A given participant may leave or arrive at the table, typically between hands in an electronic card game. Additionally, a given participant may sit out or pass on a given hand or round.

The banking candidate authenticator 612 determines whether a given participant can be a banker candidate 614 according to pre-established credentials entered into the banking engine 120. For example, some participants may be pre-authorized to be banking candidates upon proving their identity to a card reader or logon screen.

The participant tracking engine 602 keeps a database or list of current bankers 616, that is, bankers who are presently holding the banking role for the current round of the current game. The game tracking engine 604 follows the game flow and thus tracks the playing hands as they unfold and can be set to follow and even record the wins and losses of each participant, including the participant-banker.

The banker rotation manager 608 has a playing hands counter 634 that tallies the playing hands detected by the playing hand tracker 622. As dictated by a threshold number of playing hands being completed, the playing hands counter 634 triggers the offer rotator 640 to solicit a subsequent participant to hold the banking role. A manual offer interface 636 allows a live host to solicit the next banker and actuate a switch or a user interface to inform the banking engine 120 of the next banker, once determined by the live host. Thus, in one implementation, the banking engine 120 authenticates possible banking candidates, e.g., via the authenticator 612, but the live host manually rotates and/or physically offers the banking role to other participants and then resets the banking position via a touch screen, shoe key and/or shoe buttons. This accelerates the game play and takes advantage of a live hosted gaming machine or table versus the offer rotator 640 graphically rotating the banking offer through all the participant positions.

Alternatively, the banking engine 120 consults a banker assignment history 638 and the list of banker candidates 614 and electronically commences solicitation of a subsequent banker(s). First, the banking engine 120 may check and update the list of current participants 610 and the banker candidate list 614, because various participants may enter or leave the game between hands. The banking engine 120 may also update and check the participant balances 628 in the accounts manager 606 to ensure that candidate bankers still have a requisite amount of money value, either in their account or on the table as a bet for the current hand, to be on the candidate banker list 614.

The offer rotator 640 may apply various solicitation schemes to find a participant willing to be the next banker. Many times, the same participant-banker assumes the banking role over and over. In such cases, the banking engine 120 offers the periodic solicitation of a new banker to meet local or regional gaming codes that specify offering the banking role to other participants after so many rounds of the game. The “house” hosting a gaming table that has the exemplary banking engine 120 may also impose a change-of-banker rule to encourage fair treatment among participants who want to have the banking role.

In one scenario, the offer rotator 640 may solicit subsequent bankers through the electronic user interfaces 102, 104, . . . , built into the gaming table. For example, the offer rotator 640 may offer the banking role to each qualified participant in turn by extending an accept-or-refuse user interface to each qualified participant for a predetermined interval of time, e.g., 5 or 10 seconds apiece.

In another scenario, the offer rotator 640 solicits subsequent bankers by extending the acceptance or refusal user interface to all participants (who are qualified to be banker) at once. The offer rotator 640 may switch to this scenario algorithmically, based on number of participants 610, number of banker candidates 614, and the ratio between the two. In other words, offering the banking role around the table at the cost of a time interval applied by the timer 644 to each participant in sequence may become redundant and tiring when the participants themselves understand that only one or two participants want to be banker. Thus, the offer rotator 640 may offer accept-or-refuse interfaces to qualifying participants that provide input from the participants to quickly optimize the way in which the “solicit banker” manager 642 solicits participants for the banking role.

In some jurisdictions, the lock-out module 648 stops the game, halts the offer rotator 640, and stops the solicitation of bankers when the loop counter 646 determines that the banking role has been solicited around the gaming table a certain number of times, e.g., twice, with no participant accepting the banking role. In such cases, the banking engine 120 may signal an administrator or pit boss to manually unlock the game and reset the banker solicitation count.

The user interface controller 650 may extend various user interfaces for participant and banker input, and thus includes the “solicit banker” interface disparticipant 652 and the “current banker” icon disparticipant 654. The user interfaces controller 650 may also extend a user interface allowing each participant to manually opt out of being considered for the banking role, “until further notice,” or for a set interval of gaming rounds.

Likewise, the user interface controller 650 may extend an interface to the current banker to allow opting out of the banking role earlier than the automatic banker solicitation initiated by the banking engine 120.

The accounts manager 606, when used, applies the wager tracking engine 626 to maintain a record of participant money and/or wager chip balances in real time. The banked wagers tracker 630 detects transactions of the current banker in order for the bank balancer 632 to perform balancing of the bank of each participant holding the banking role.

A “secondary banker” banking role can be implemented by the banking engine 120 and can be set to a known corporately backed participant-banker. Likewise, in some implementations, a tertiary banker can be solicited by the banker rotation manager 608. A secondary banker role can be utilized if the primary banker cannot “cover” all bets on the table. In such a case, a secondary banker may elect to cover the remaining bets. Likewise, a tertiary banker may be utilized in the same manner.

Example Method

FIG. 7 shows an exemplary computer-executable method 700 of electronic banking management for betting games. In the flow diagram, the operations are summarized in individual blocks. The exemplary method 700 may be performed by hardware, or combinations of hardware, software, firmware, etc., for example, by components of the exemplary banking engine 120.

At block 702, current participants are tracked to establish banker candidates for the betting game. Participants may be tracked by participation in the game or by credentials offered by the participant. Hence, various levels of participant tracking may run simultaneously. An anonymous participant, not eligible to be a banking candidate, may be known to the exemplary method 700 only by hands played in an electronic card game and by wagers made.

Another participant may be tracked according to identity information provided by the participant and by a money value or an account proved by the participant. Still another participant, a corporately backed participant-banker, may be authenticated and tracked by identity and account information known throughout a casino system.

The exemplary method 700 follows participants as they enter and until they exit a game, and as they participate in hands or game rounds, or pass. Each participant may also be tracked according to money on the table, to determine each participant's eligibility to be on the candidate banker list.

At block 704, a time to change bankers is determined and a next banker is solicited from among the banker candidates. The exemplary method 700 may count game hands and apply rules for changing bankers that have been promulgated by the local legal jurisdiction or promulgated by the “house” to encourage fair treatment among participants who want to assume the banking role. The exemplary method 700 may solicit subsequent bankers through the electronic user interfaces built into the gaming table. For example, the exemplary method 700 may offer the banking role to each qualified participant in turn by extending an accept-or-refuse user interface to each qualified participant for a predetermined interval of time, e.g., 5 or 10 seconds apiece.

In another implementation, the exemplary method 700 solicits subsequent bankers by extending an acceptance-or-refusal user interface simultaneously to all qualified participants at once. This latter technique can be useful when repetitious and sequential offering of the banking role to a full table of qualified participants becomes redundant.

The exemplary method 700 also includes allowing each participant to manually opt out of being considered for the banking role. Likewise, the exemplary method 700 includes extending a user interface to the current banker to allow the current banker to opt out of the banking role before the exemplary method automatically tries to pass on the banking role to another participant.

Conclusion

Although exemplary systems have been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed systems, methods, and structures.

Claims

1. A computer-executable method, comprising:

determining a first participant holding a banking role in a multiparticipant wagering game;

tracking rounds of the multiparticipant wagering game;

after a predetermined number of the rounds, offering the banking role to other participants in the multiparticipant wagering game; and

assigning the banking role to a second participant.

2. The computer-executable method as recited in claim 1, further comprising authenticating at least some of the participants to be candidates for holding the banking role.

3. The computer-executable method as recited in claim 1, wherein offering the banking role includes determining an amount of money associated with each participant and offering the banking role only to participants that have an amount of money surpassing a threshold.

4. The computer-executable method as recited in claim 1, wherein tracking rounds includes tracking playing hands of an electronically mediated card game and tracking wins and losses of each participant in the card game.

5. The computer-executable method as recited in claim 1, wherein assigning the banking role to a second participant includes authenticating at least some of the participants to be candidates for holding the banking role;

determining the banking position via a live host rotating the banking position via physically offering the banking position to other participants; and

wherein resetting a new banking position is accomplished by the live host actuating a touch screen, a shoe key, or a shoe button.

and the banking role around an electronic gaming table in a sequence.

6. The computer-executable method as recited in claim 1, wherein offering the banking role includes rotating a solicitation of the banking role via a visual solicitation on each of multiple user interfaces corresponding to multiple participants around an electronic gaming table.

7. The computer-executable method as recited in claim 6, wherein offering the banking role includes soliciting each of the other participants via extending a user interface to each participant for a predetermined interval of time before extending the user interface to the next participant.

8. The computer-executable method as recited in claim 6, further comprising rotating the solicitation of the banking role around the electronic gaming table a predetermined number of times, then locking-out the game when the predetermined number of the rotations is reached, wherein the locking-out requires a reset to recommence the electronic wagering game.

9. The computer-executable method as recited in claim 1, further comprising extending a user interface to the first participant holding the banking role to allow the first participant to opt out of the banking role before the predetermined number of rounds.

10. The computer-executable method as recited in claim 1, further comprising designating a current banker via an icon or marking displayed on at least one of multiple visual displays of a multiparticipant electronic gaming table.

11. The computer-executable method as recited in claim 1, further comprising:

tracking wagers during the multiparticipant wagering game;

updating participant account balances during the multiparticipant wagering game;

tracking transactions of each participant holding the banking role; and

balancing a bank of each participant holding the banking role.

12. A system comprising:

a multiparticipant electronic gaming table;

a banking engine in the multiparticipant electronic gaming table; a participant tracking engine in the banking engine to determine a current list of participants and to authenticate participants for a current list of banker candidates; a game tracking engine in the banking engine to track a game flow and to track rounds of a game being played on the multiparticipant electronic gaming table; and

a banker rotation manager in the banking engine to determine when to change bankers based on the tracked rounds and to solicit a next banker for the game.

13. The system as recited in claim 12, wherein the banking engine:

determines a first participant holding a banking role in the game;

tracks rounds of the multiparticipant wagering game;

after a predetermined number of the rounds, offers the banking role to other participants in the multiparticipant wagering game; and

assigns the banking role to a second participant.

14. The system as recited in claim 12, wherein the banking engine determines an amount of money associated with each participant and offers the banking role only to participants that have an amount of money surpassing a threshold.

15. The system as recited in claim 12, wherein the banking engine tracks playing hands of an electronically mediated card game and tracks wins and losses of each participant in the card game.

16. The system as recited in claim 12, wherein the banking engine authenticates at least some of the participants to be candidates for holding the banking role;

determines the banking position via a live host rotating the banking position via physically offering the banking position to other participants; and

resets a new banking position via the live host actuating a touch screen, a shoe key, or a shoe button.

rotates a solicitation of the banking role via a visual solicitation on each of multiple user interfaces corresponding to multiple participants around an electronic gaming table.

17. The system as recited in claim 16, wherein the banking engine rotates the solicitation of the banking role around the electronic gaming table a predetermined number of times, and then locks-out the game when the predetermined number of the rotations is reached.

18. The system as recited in claim 1, wherein the banking engine:

tracks wagers during the game;

updates participant account balances during the game;

tracks transactions of each participant holding the banking role; and

balances a bank of each participant holding the banking role.

19. A banking engine, comprising:

a participant tracker to list current participants and banker candidates associated with a game played around a multiparticipant electronic gaming table; and

a banker rotation manager to determine when to change bankers and to solicit a next banker for the game from among the banker candidates.

20. The banking engine as recited in claim 19, further comprising an accounts manager to:

track wagers during the game;

update participant account balances during the game;

track transactions of each participant holding the banking role; and

balance a bank of each participant holding the banking role.