Networked computerized wager-based game system

Abstract

A wager-based gaming system provides a wager-based game playable by a player from a player computer on the table. The player computer receives player inputs, including wagers, from the player and transmits them to a game server communicably connected thereto and which applies game logic defining the game and defined in a game logic module, to generate game outputs, including an outcome for the game for the player, which is displayed on the player computer. The game logic module is selectable and configurable from a backend server and which contains player data for the player, including an account balance from which the wagers may be placed. A card reader connected to the player computer reads a portion of the player data is validated against the player data on the backend to authorize or deny access to the player data.

Description

CROSS REFERENCE TO RELATED APPLICATION

Benefit of U.S. Provisional Application for Patent Ser. No. 60/794,140, filed on Apr. 24, 2006, is hereby claimed.

FIELD OF THE INVENTION

The present invention concerns computerized wager-based games, and more particularly a networked computer wager-based gaming system and method, as well as a table therefor.

BACKGROUND OF THE INVENTION

Networked computerized wager-based game systems in which players play a wager-based game, such as poker, blackjack, bingo, roulette or other like games involving placement of wagers, using computers connected on a network, such as the Internet, are well known in the art. For example, PartyGaming PLc of Gibraltar provides a system (accessible from URL: www.partypoker.com) in which players may play a game of poker from their home computers over the Internet. However, such systems typically require players to download cumbersome, and often voluminous, client software applications to their own personal computers so as to be able to play. In addition, such systems typically offer little face-to-face social interaction with other players. Also, not all players wish to download such client applications to their own personal computers, due to security concerns regarding viruses, spyware, or the like.

The security concerns and lack of face-to-face interactions noted above for such systems as those provided by PartyGaming Plc are somewhat obviated by systems that allow users to physically sit around a table in which each player has a computer upon which the user plays, all of the computers being networked to one another as well as to computers elsewhere to allow players to participate, if desired, in games played at other tables in other locations. Such computerized tables often include a central display unit which allows all players at the table to observe game play, for that particular table or elsewhere. An example of such a system with such a table is the PokerPro™ table and system provided by PokerTek inc. (URL: www.pokertek.com). This system allows users to play a wager-based game from individual computers situated on a table having a large central display unit and to place wagers using credits assigned to magnetic strip cards assigned to the user. Unfortunately, such magnetic strip cards are notoriously insecure and can be easily copied by unauthorized users, thus creating a risk of fraud.

Accordingly, there is a need for an improved networked computerized poker game system and table therefor.

SUMMARY OF THE INVENTION

It is therefore a general object of the present invention to provide an improved networked computerized wager-based game system and table therefore which offers greater security for players and an improved interactive face-to-face interactive experience.

An advantage of the present invention is that the computerized network wager-based game system and table provided thereby allows users to play the game in physical proximity to one another at the table, thereby allowing face-to-face interaction between players.

A further advantage of the game system and table provided by the present invention is that players may securely place wagers for the game.

Still another advantage of the present invention is that players may play the wager-based game provided by the game system and the table without having to download software to their own personal computers.

Still another advantage of the present invention is that response time of game system is minimized.

Yet another advantage of the present invention is that the wager-based game available for play on the table may be seamlessly and instantly changed to another wager-based game.

Still another advantage of the present invention is that a portion of the wager-based game may be replayed for any player computer on a requested computer without interrupting play on other player computers.

In accordance with an aspect of the present invention, there is provided a wager-based gaming system comprising:

• • at least one table having at least one respective player computer disposed thereupon for receiving player inputs from a player for a respective game for the table playable on the player computer and for displaying game outputs therefor, the player inputs comprising at least one wager for the game and the game outputs comprising an outcome therefor;
  • for each player computer, a respective card reader communicably connected thereto for reading at least a portion of respective player data for the player from a respective microprocessor on a respective smart card therefore when the smart card is inserted therein, the portion being stored on the microprocessor;
  • at least one game server communicably connected to each player computer and storing respective game logic defining the game for applying the game logic to the player inputs to generate the game outputs; and
  • a backend server to which each game server, and thereby the player computer, is communicably connected and upon which all the player data is stored for validating whether there is correspondence between the portion read by the card reader against the player data stored on the backend server, the backend server authorizing access to the player data stored thereon from the player computer for playing the game if said correspondence is validated.

In accordance with another aspect of the present invention, there is provided a method for providing wager-based gaming on a table, said method comprising the steps of:

• • receiving a smart card having a microprocessor in a smart card reader situated at said table and communicably connected to at least one respective player computer for the table and upon which at least one respective game for said table is playable, said microprocessor having at least a portion of respective player data relating to said player stored thereupon, all said player data being stored on a backend server connected to said player computer;
  • reading said portion into said player computer with said card reader;
  • validating whether there is correspondence of said portion with said player data on said server computer;
  • if said correspondence is validated, authorizing use of said respective player data from said gaming computer while said player plays said game thereupon, generating game outputs by applying game logic defining said game to respective player inputs input by said player on said player, said respective player inputs comprising at least one respective wager made by said player, said respective game outputs comprising a respective outcome for said game for said player.

Other objects and advantages of the present invention will become apparent from a careful reading of the detailed description provided herein, with appropriate reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Further aspects and advantages of the present invention will become better understood with reference to the description in association with the following Figures in which:

FIG. 1 is a system diagram of a networked computerized wager-based game system for playing poker, in accordance with an embodiment of the present invention;

FIG. 2 is a diagram showing the modules of a backend server for the system shown in FIG. 1;

FIG. 3 is a data scheme diagram showing data stored in the database of the backend server for the system shown in FIG. 1;

FIG. 4 is a diagram showing the modules of a game server for the system shown in FIG. 1;

FIG. 5 is a diagram showing interactions of data between the personal player computer, the game server, and the backend server for the system shown in. FIG. 1;

FIG. 6 is a diagram showing the modules of a game module for the player computer of the system shown in FIG. 1;

FIG. 7 is diagram showing a scheduling agent for the remote configuration module of the backend server of the system shown in FIG. 1;

FIG. 8 is a diagram showing a replay request for execution by the system shown in FIG. 1; and

FIG. 9 is a perspective view of an exemplary table for the system shown in FIG. 1.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to FIG. 1, therein is shown a system diagram of a networked computerized wager-based game system, shown generally as 10, in accordance with an embodiment of the present invention. As shown, system 10 has at least one table 26 at which players may play a respective wager-based game for the table 26, preferably a wager-based card game, in which wagers 300 of money may be made, such as poker, blackjack, bingo, roulette, or the like. Each table 26 has at least one respective player computer (PC) 12 disposed thereupon and upon which a player plays the game on the system 10. Each PC 12 also has a respective card reader (CR) 14 therefor disposed on table 26 and communicably connected to the PC 12. For the purposes of describing the system 10, the term communicably connected used in this specification designates any connection, direct or indirect, between any components of the system 10, including connection by the network 28, such that they the components may exchange data.

Reference is now made to FIGS. 1, 2, and 3. Each player preferably has a smart card (SC) 18, having a microprocessor 154 disposed thereon, which is insertable into the CR 14. The microprocessor 154 contains at least a portion of respective player data 200 for the player, with all of the respective player data 200 for each player being stored in a database (DB) 64 on a backend server 24 communicably connected to network 28, game server (GS) 20, table server computer (TBS) 40 and links 30, 32 to each PC 12, and thereby to each CR 14. As shown in FIG. 3, the respective player data 200 identifies the player and includes financial information such as, for example, a respective account balance 202, redeemable for money and from which wagers 300 may be placed during play of the game and to which winnings based on an outcome 302 of the game are creditable by addition thereto. For identifying the player, the player data 200 may include a player identifier 204 and password 206 which must be entered by player at PC 12 when SC 18 is inserted into CR 14 to verify the identity of the player. The portion of the player data on the microprocessor 154 preferably includes at least the player identifier 204, but may also include all of the player data 200, if desired. Further, the CR 14 may read or write the player data 200, or any portion thereof, to the microprocessor 154 on the SC 18 when the SC 18 is inserted therein, thus allowing the portion of the player data 200 on the SC 18 to be updated whenever the player data 200 is modified on the BS 24. The player data 200 may be transmitted back and forth between PC 12 and CR 14, as well as between each CR 14 and the respective table base station computer (TBS) 40 for the table 26, which generally controls all PCs 12 and CRs 14 disposed thereat and to which each PC 12, and each CR 18 on the table 26, is communicably connected. It should be noted that, while only two PCs 12 are shown at table 26, there may be more PCs 12 I desired. In fact, as explained below, there are, preferably, ten PCs 12, each with one corresponding CR 14, per table 26. In addition, there may be more than one table 26 in the system 10 and each table 26 may be at the same, or at a different, geographical location.

Each PC 12 may, optionally, have a currency receiver (CUR) 150 communicably connected thereto, and thereby to the TBS 40, GS 20, and BS 24 and disposed on the table 26. The currency receiver 150 receives an optional respective player deposit of currency, i.e. money such as banknotes or coins, from the player and determines the respective deposit value, i.e. the monetary value, of the respective player deposit, which is creditable, by addition thereto, to a session balance 212, redeemable for money, maintained by the system 10 while the player is playing at a given PC 12 and which is creditable, by addition thereto, for updating the respective account balance 202 of the player. Each table 26 may also have, for each respective PC 12 thereof, a respective ticket printer and reader (TKT) 152 communicably connected to the PC 12 and thereby the TBS 40, GS 20, and BS 24 which prints and reads tickets having a monetary value inscribed thereon and which is attributable to the session balance 212 and/or the account balance 202.

Referring again to FIG. 1, TBS 40 controls a large central display unit (CDU) 16, typically a liquid crystal display (LCD), which is situated in the centre of table 26 and which allows each player to monitor the progress of the game, except for private player data 210, including the exact cards in a player's hand which have not yet been revealed to other players, which is generally shown only on the display of the player's PC 12. TBS 40 provides bidirectional communicable connection between PC 12, CUR 150, TKT 142, and CR 14 at table 26 through internal network links 32 and network 28 to GS 20 and back-up game server (BGS) 22. The network 28 is preferably an Internet type network with external network links 30 being Internet network links. However, network 28 and external network links 30 may be of any type as long as bidirectional communication between elements GS 20, BGS 22, BS 24, and Table Station Base (TBS) 40 are provided thereby, thereby ensuring that elements 20, 22, 24, and 40 are communicably connected. At table 26, CR 14, PC 12, TKT 142, CUR 150, and CDU 32 are all communicably connected to each other by internal table network links 32. Table network links 32 are preferably Internet/Ethernet links, but may be any kind of network link that allows transmission of data between elements 12, 14, 16, 150, 152, of table 26. Additionally, while CR 14 is shown as being connected directly to both PC 12 and TBS 40, it is sufficient that CR 14 only be connected to one of PC 12 and TBS 40, provided that a communicable connection, either direct or indirect through PC 12, is furnished for CR 14 to TBS 40. Similarly, while TKT 152 and CUR 150 are shown as being connected by links 32 only to their respective PCs 12, they could, instead or in addition thereto, be connected by links 32 to TBS 40. The system 10 may also have an optional monitoring computer (MC) 170 communicably connected by external network links 30 to the GS 20 and BGS 22, as well as to BS 24 by network 28. The MC 170 permits monitoring, i.e. viewing, of all players and the game and requesting of replays of portions of the game, such as a hand of cards in card wagering-based game, by a user, such as a system administrator or an employee of a venue, such as a casino or the like, in which the system 10 is deployed. In addition, if desired, the MC 170 may also, by accessing the BS 24, be used for configuring the system 10, including, notably, the game.

It should be noted that system 10 is conceived as a distributed network. Specifically, game client module 120, used on PC 12, and possibly TBS 40, to interact with player, the back end interfaces and back end business modules used on TBS 40, and game server modules for controlling game logic on GS 20 and BGS 22, are all independent from one another. At the same time, system 10 is implemented using a dynamic n-tier hierarchy, notably with regard to software for PC 12, TBS 40, GS 20, and BGS 22, which facilitates management of multiple games in multiple locations. Asynchronous message-based communication protocols are used for communication between elements 12, 14, 40, 20, 22, and 24, between each other and over network 28, to reduce delays in message handling throughout system 10, such that there is no perceptible delay for players when playing. The dual server configuration, i.e. GS 20 and BS 24, further facilitate speed of system 10 by assigning management of databases and business modules, such as the cashier functions for updating financial information of a player, statistical analysis, player tracking, monitoring play in progress at table 26, and monitoring history of play at table 26 to BS 24, leaving GS 20, and BGS 22 if required, to manage actual game play, and the logic associated therewith, for the multiple games that may be in progress at any one moment in system 10.

To describe the manner in which playing of the game is handled by the system 10, reference is now made to FIGS. 4, 5, and 6. In general, the game is played by a player by entering player inputs 112, including at least one wager 300, into the PC 12 which displays a game interface 122 provided by a game software client module 120 resident on the PC 12 for the game and into which the player inputs are entered. The PC 12 transmits the player inputs, typically via the TBS 40, to the GS 20 which applies the game logic in the game logic module 46 to the player inputs 112 to generate game outputs 114, including an outcome 302 for the player for the game. The game outputs 114 are transmitted to the PC 12 where they are displayed, by the game client module 120, on the game interface 122. The GS 20 also is responsible for managing artificial intelligence of robot players, i.e. non-human robot players managed by system 10 and against which human players may play. Administration of financial information, including any wagers 300 and winnings of player is, however, generally managed by BS 24. The game outputs 114 are also transmitted by the GS 20 to the BS 24, as part of game data relating to the game for storage and processing thereon. Player data 200, which may be received as part of player inputs 112 and/or from SC 154 via CR 32, as well as the player inputs themselves 112 are also be transmitted from GS 20 to BS 24 for storage thereon. More specifically, the BS 24 has a history module 68 which stores all player inputs 112 and game outputs 114 for each PC 12, on the BS 24 preferably in the database DB 64 thereon. The DB 64 is, preferably, also used for storing player data 200, and game configuration information 108, and a schedule 102. Each player input 112 and game output 114 is stored on the BS 24 in association with the PC 12 from which the player input is entered and for which the game output 114 applies. The inputs 112 and output 114 may also be stored in association with the player information 200, if the player has been identified by verification of the portion of the player information 200 on the SC 18 with the player information stored on the BS 24. The BS 24 also, provided the portion on of the player data 200 on the SC 18 has been verified by the BS 24 against the player data 200 stored thereon, may transmit player data 24 to the GS 20 and the PC 12 for use by the player while playing the game on the PC 12. Additionally, the BS 24 transmits game data, including game configuration 108 to the GS 20 for configuring the game logic module 46.

Referring to FIGS. 1, 2, 3, and 5, each player preferably obtains a respective SC 18 before commencing play for the first time on the system 10. The player then proceeds to a table 26 and inserts the SC 18 into a CR 14 of a PC 12 that is not currently in use. The player then enters an initial input to the PC 12 to indicate that the player wishes to play the game thereon. The initial input may be a player input 112 entered directly on the PC 12. The initial input may also be insertion of the SC 18 into the CR 14 or deposit of a player deposit of currency into the CUR 20, both of which cause the PC 12 to generate an event transmitted to the GS 20.

If the player inserts the SC 18 into the CR 14, the portion of the player data 200 in the microprocessor on the SC 18 is then read by the CR 14 and transmitted therefrom, possible via PC 12, to the TBS 40, which then transmits the portion through links 30 and network 28 to BS 24. The BS 24 then verifies that the portion of the player data 200 received from the SC 18 corresponds, i.e. is identical to, the player data 200 stored on the BS 24. This verification may also involve entry by player of a player access code 206, submitted along with the portion of the player data 200 on the SC 18 to the BS 24 for verification thereof. Alternatively, the access code 206 could, if stored as part of the portion of the player data on the SC 18, be verified, i.e. checked for identity, with the portion read by the CR 14. Should correspondence between the portion of player information 200 on the SC 18, and the access code 206 if required, with the player information 200 stored on the BS 24 be successfully verified, then the BS 200 authorizes use of the player information 200 from the PC 12 at which the SC 18 was inserted into the CR 14 and will communicate player information 200, notably the account balance 202 for the player, back and forth therewith, as well as with the GS 20 while the player plays the game 200. Thus, if the verification is successful, the account balance 202, among other things, will be made available to the player on the PC 12 for placing wagers 300 therefrom. When player has finished playing, the BS 24 updates the player data 200, including the account balance 202 such as the amount of money credited to a player's account balance 202. For purposes of security, microprocessors on SC 18 and CR 14 use 128 bit authentication and triple data encryption standard (3DES) encryption for storage and exchange of all data therebetween. 3DES may also be used for transmitting all data over network 28. Thus, use of SC 18 provides significant additional security versus use of standard magnetic strip cards. Also, it should be noted that all, or a portion of, player data, including financial information, may also be stored on BS 24, possibly in addition to, or in substitution for, SC 18. Once validation is complete, player may play a wager-based game, the logic of which is generally managed by GS 20. If the SC 18 is not inserted into the CR 14, or if the portion of the player data 200 on the SC 18 does not match the player data on the BS 24, i.e. the correspondence is not verified, then access to the player information 200, including the account balance 202, from the PC 12 is denied for playing the game therefrom.

If access to the player data 200 is not available, a player may still play the game from a PC 12 by depositing a player deposit of currency into the CUR 150. Whenever a player deposit is made, the CUR 150 determines the deposit value thereof which is transmitted to the PC 12 and from the PC 12 to the GS 20. The GS 20 credits the deposit value to a session balance 212, redeemable for money and from which wagers 300 may be placed, based on winnings or losses determined by game outcomes 302, maintained by the GS 20 while the player plays the game on the PC 12. The session balance 212 is initially set at zero by the GS 20 when the player commences playing the game on the PC 12 by making an initial input, for example a first player deposit into the CUR 150 or inserting SC 18 into CR 14, whichever is done first. The deposit value of each player deposit is automatically credited, i.e. added, by the GS 20 to the session balance 212. Similarly, when correspondence between the portion of the player data 200 stored on the SC 18 and the player data 200 on the BS 24 is verified, the BS 24 transmits the account balance 202 to the GS 20 which credits the account balance 202 to the session balance 212. The session balance 212 is also transmitted from the GS 20 to the BS 24 and stored thereon, preferably in DB 64. As the player plays the game on the PC 24, the session balance 212 is also updated by the GS 24 by adding winnings and subtracting losses, based on outcomes 302 for the respective wagers 300 therefrom. When the player stops playing on the PC 12, for example by entering a request to terminate play thereon or to redeem the session balance, the session GS 20 transmits the session balance to the BS 24 which, if correspondence of the portion of player data 200 on SC 18 with player data 200 on the BS 200 has been validated, assigns the session balance 212 to the account balance 202, thus updating the account balance 202, and resets the session balance to zero. If correspondence of the portion of player data 200 on SC 18 with player data 200 on the BS 200 has not been validated, then the BS 24 generates a ticket output containing the session balance 212 which is transmitted to a printer, preferably the ticket reader and printer (TKT) 152, communicably connected to the PC which generates a ticket having the session balance 212 inscribed thereupon and which is redeemable for cash.

Optionally, the ticket may be machine readable by TKT 152, thus allowing the ticket to be inserted thereinto for another PC 12 to be credited to the session balance 212 thereon. If desired, the player may also request a similar procedure for redeeming the account balance 202 when correspondence of the portion of player data 200 on SC 18 with player data 200 on the BS 200 has been validated. Further, if desired readable tokens and token readers and receivers may also be connected to PCs 12 to deposit and track credits to the session balance 212 and/or account balance 202. The CUR 150 is banknote or coin reader and receiver, as is well known in the art and can accept multiple currencies, as is well known in the art.

Having presented the general manner in which the game is played on the system, the components thereof are now described in greater detail. Referring now to FIGS. 5 and 6, each PC 12 has a distributed network software game client module 120 installed thereon, which provides a player's interface upon which the game, including player inputs 112 and game outputs 114 therefor, is displayed and by which the player enters the player inputs 112. The game client module 120 provides communication to the GS 20 and the BS 24, via the TBS 40. While implementable on any operating system, for platform, the game client module 120, as well as PC 12, are generally designed to function using the Microsoft® Windows® operating system, although elements 12, 120. The game interface 122 includes, for each game playable on the PC 12, a respective specific game interface elements module 124 which contain interface elements that are specific to the game playable on the PC 12 and a general client platform (GCP) module 126 which includes common interface elements common to every game playable on the PC 12. Based on scheduling instructions 180 entered or stored on the BS 24, a designated specific game interface elements module 124 for a designated game can be actuated, for example loaded, by the game client module 120, thus instantly changing the game interface 120 to the respective game interface 120 required for the designated game. Thus, the game client module 120 is game-independent and can dynamically support a large variety of wager-based games, such as poker, blackjack, bingo, roulette, etc., and allows the game interface 122 that is available on all PCs 12 at a table 26 to be almost instantaneously changed from the BS 24. In general, the same type of game, whether it be blackjack, poker, bingo, etc. is loaded on all PCs 12 for a table 26 at any given time.

To facilitate multi-lingual environments, game client module 120 allows the language used to be play game on PC 12 to be instantly switched by clicking a mouse, when connected to PC 12, pressing a single button on PC 12, or by selecting a single icon displayed on PC 12. To enhance realism of game play, the game client module 120, notable the game interface 122, presents a different perspective of the game currently being played by players at the table 26, based on the position of the PC's 12 display on table 26. Typically, and as explained in further detail below, PCs 12 will be panel personal computers with displays embedded in the top of table 26 or extending upwardly therefrom. For additional security, the system 10 provides for automatic detection of failures of the PC 12, game client module 120 on PC 12, and CDU 16, as well as automatic recovery thereof upon detection of failure.

The game client module 120 is also resident on the MC 170 and TBS 40, thus allowing the game to be displayed on the MC 170 and on the CDU 16 controlled by the TBS 40. However, the respective game client modules 120 on the MC 170 and the TBS 40 are configured for displaying player inputs 112 and game outputs 114, i.e. displaying the game, and not for receiving player inputs 112 from players.

Referring now to FIGS. 1, 3, and 4, each GS 20 has multiple virtual gaming logic modules 46 resident and stored thereon. Specifically each GS 20 has, for each game playable on the respective PCs 12 communicably connected, by TBS 40, to the GS 20, one respective gaming logic module 46 for the game and which defines the game. Based on dynamic game-room instances of games being played on system 10, GS 20, and notably game logic modules 46, allow players to play a specific game together in a virtual game room, along with other players registered to play in the same virtual game-room. The game-rooms created by the virtual gaming logic module 46 reproduce all of the real game's rules and level of confidentiality, with the possibility of playing with the security and anonymity of a network-based game, or of playing face-to-face with other players at table 26 where players are physically present. To facilitate rapid changes of game available on PC 12, for example changing game on PC 12 software client from poker to bingo, GS 20 has a common game platform 64 into which various logic modules 46, as well as artificial intelligence (AI) robot player modules 48, can be rapidly loaded to actuate the game logic module 24, again by executing a simple command, such as a scheduling instruction 180, from BS 24. AI robot player modules 48 control play of non-human robot players with which human players may also play. In general, each module 46, 48 is adapted to, i.e. defines, the rules of the specific game, such as poker or bingo, for which the modules 46, 48 are used. In addition, GS 20, in conjunction with BS 24, allows for parameters of games to be instantly adjusted dynamically, again based on scheduling instructions 180 and game configuration information 108 stored on the BS 24. Further, GS 20 supports, in conjunction with BS 24, self-service functions for player management by players, for example deposit and withdrawal of cash from the account balance 202, which is part of player data. GS 20 also logs game play, which is transmitted thereby to BS 24 and stored thereon, preferably in database 64, by history module 68. As shown in FIG. 4, all modules 46, 48, 62 on GS 20 and BGS 22 are capable of bidirectional communication with each other. However, the connections shown by arrows between modules 46, 48, 62 in FIG. 4 are exemplary and other configurations for communication between modules 46, 48, 62 are possible, provided all modules 46, 48, 62 can communicate either directly or indirectly with one another and with BS 24, TBS 24, and PC 12.

It should be noted that GS 20, BGS 22, and BS 24 are modules which are resident on server computers 20, 22, 24, 40. To ensure increased reliability and availability, system 10 has backup game server (BGS) 22, which is essentially identical to GS 20 and synchronized therewith. Should GS 20 become unavailable, BGS 22 will automatically assume tasks of GS. In addition, GS 20, as well as BGS 22, automatically detects and manages failure of any PC 12, as well as the software client thereon. GS 20 and BGS 24 are preferably implemented on computer systems using the LINUX operating system. However, other operating systems, such as Microsoft® Windows® may be used, provided they can provide the communications required for system 10.

As shown in FIG. 1, TBS 40, GS 20, BGS 22, and BS 24 may each be housed on separate respective server computers. However, if desired, TBS 40 and GS 20, as well as the BS 24 if desired, could also be resident on a single server computer, for example the server computer 40 at the table 26 upon which the TBS 40 is resident provided they are communicably connected. The GS 20 and BS 22 could also be resident on single server computer 20, 22, 24 remote from the table 26. However, for purposes of reliability, as discussed above, it is desirable that BGS 20 and GS 20 be housed, i.e. resident or hosted, on separate communicably connected server computers.

Reference is now made to FIGS. 1, 2, and 3. BS 24 manages and monitors all aspects of server activity, including activity of GS 20 and BGS 22, and provides for administration of system 10 and of main database 64, in which player data 200 is stored, possibly in addition to any player information stored in microprocessor on smart card 18. The communication and authentication server (CAS) module 66 of BS 24 is a server-side software application that manages the interaction and communication of the various server components, including GS 20 and BGS 22, as well as software clients on PC 12. The BS 24 has a multi-tier architecture that allows the user interface for any given module 52, 54, 56, 58, 60, 66, 64 of BS 24, as well as for GS 20, BGS 22, to reside on BS 24 or on any computer with access to the BS 24 over network 28 or any other network to which BS 24 is connected. In addition to the database 64 and CAS 66, BS 24 has the following modules: monitoring system module 52, cashier system module 58, player services module 60, management system module 54, history and statistics module 68, and remote configuration module 56.

BS 24, as well as modules 52, 54, 56, 58, 60, 66 therefor are, preferably, implemented on a Microsoft® Windows NT® platform. However, other operating systems may be deployed. Further, modules 52, 54, 56, 58, 60, 66 may contain both software and hardware elements and are capable of communicating with each other, as well as with database 64, either directly or indirectly. Further, some of the modules 52, 54, 56, 58, 60, 66 may be relocated or shared with GS 20 and BGS 22 if desired. Each module 52, 54, 56, 58, 60 is explained in further detail below.

Remote configuration module 56 provides remote hardware configuration for PCs 12, TBS 40, and all other elements 14, 16 of tables 26 terminals and tables. For example, this module 56 provides remote activation and deactivation of PCs 12 and TBS 40, as well as remote changing of hardware options for PC 12, TBS 40, and tables 26. Remote configuration module 56 also provides a seat reservation system for reserving seats at tables 26 for both tournaments and regular game-play, including waiting-list management for seats and seat assignment. Remote configuration module 56 also provides an operator access control subsystem, tournament configuration and player registration, and game room management and configuration.

Additionally, and referring to FIGS. 2, 3, 6, and 7, remote configuration module 56 furnishes an automatic scheduling agent (SA) 100 which allows scheduling of automated configuration operations of the game-room in which a game is played, as well as of other software components and modules of system 10. More specifically, scheduling agent 100 reads and writes a programmable schedule 102 stored on BS 24, preferably in DB 64, and defined, i.e. programmed, by a user using the scheduling agent 100. The schedule 100 contains scheduling instructions 103 which specify an optional designated time 104 for execution of the scheduling instruction 103, a designated game logic module 46, and thereby a designated game and designated respective game specific interface elements module 124 therefor, and, optionally, game configuration information 108 specifying a game configuration for the designated game logic module 46 and, optionally, the respective game specific interface elements module 124 for the designated game defined by designated respective game logic module 46.

At the designated time 64, the scheduling agent 100 reads the scheduling instruction 103 and transmits the scheduling instruction to the GS 20. The GS 20 receives the scheduling instruction 103 and, once any instance of any game for the game logic module 46 currently activated thereon has been completed, typically by generation of the outcome 302 therefor and updating of the session balance 202, deactivates, i.e. unloads the respective game module 46 currently activated thereon. The GS 20 then immediately activates, i.e. loads into the CGP 62, the designated game logic module 46 in the scheduling instruction 103 as well as any configuration information 106 therefor in the scheduling instruction. At the same time, the GS 20 sends a message to the game client module 120 to deactivate, i.e., unload, the game specific interface elements module 124 for the game that has just terminated and to activate, i.e. load, the designated game specific element module 124 for the designated by designated game logic module 64 as well as any game configuration information 108 applicable thereto. Alternatively, the GS 20 may send, as soon as the GS 20 receives the scheduling instruction 103, the message to the game client module 120 instructing the module 120 to deactivate the game specific interface element module 124 for the game currently and to activate the designated game specific element module 124 in the configuration specified in any configuration information 108 applicable thereto, as soon as any instance of the game currently in progress has terminated. In either way, the designated game logic module 46 and the designated game specific interface elements 104 are activated, thus making the designated game seamlessly available for playing on the PCs 12 on the table 26, as soon any instance of the game currently activated on the GS 20 has completed without restarting any PCs 12, the GS 20, or the BS 24.

It should be noted that scheduling instructions 103 may also entered, at any time, from remote configuration module 56 with the option of being immediately executed, i.e. without assignment of a pre-determined time 104 of execution thereto, thus allowing for spontaneous and seemless changes to the game playable on the PC 12. Thus, the scheduling agent 100, provides for dynamic selection and configuration of a selected game, i.e. the designated game defined by the designated gaming logic module 46 specified in the scheduling command, among the plurality of games for which gaming logic modules 46 are available on the GS 20 and game specific interface modules 124 are available on the game client module 120.

The management system module 64 provides for game administration of games, management of smart cards 18, management of special promotions associated with system 10 or with entities which have implemented system 10, and creation and scheduling of tournaments, including result notification for tournaments and scheduling notification for tournaments.

Cashier system module 58 provides for player management, and notably of player data, tournament registration for tournaments, as well as, in conjunction with management system module 64, and management of smart cards 18.

Player services module 60 is responsible for provision of services to player using player data. Accordingly, player services module 60 manages and updates player account balances 202, as part of player data 200, and transactions affecting the account balance, such as deposits or withdrawals to account balance 202. Player services module 60 also allows system 10 to dynamically generate a dynamic tournament schedule for players.

Monitoring system module 52 provides real-time monitoring of the hardware status of system 10, including all elements of tables 26, especially PC 12 and TBS 40, as well as servers 20, 22, 24. In addition, monitoring system module 52 monitors all active players, any tournaments of games that may be in progress on system 10, and of running-game rooms in which players are playing. Monitoring system module 52 also provides for viewing of statistics for casinos for which system 10 is implemented, including total rake, total money in currently in play, and seat occupancy at tables 26.

History and statistics module 68 tracks and compiles statistics for system 10. These statistics include: daily income and transaction reports, game room history, table profit reports, player history, and all player inputs 112 and game outputs 114, which are stored by the history module 68, preferably in the DB 64, on the BS 24. History and statistics module 68 also provides data mining to allow for customizable reports and data sheets.

Referring now to FIGS. 2, 3, and 8, the history module 68 also provides replays of the game or a requested replay portion thereof. Specifically, a replay request 250 may be entered into the gaming client module 120 on any of the PCs 12 participating in a game or a monitoring computer 170. The replay request 250 specifies a requested portion 256 of the player inputs 112 and game outputs 114 for the game, for example a hand of a wager-based card game, at least one designated computer 12 identifying the PC 12 for which the requested portion of the player inputs 112 and game outputs 114 were generated, and at least one requested computer, namely the TBS 40 for the CDU 16, PC 12, or the MC 170 on which the requested portion 256 is to be displayed in sequence, thereby replaying the portion. The game client module 120 transmits the replay request 250 to the GS 20, which in turn transmits the replay request to the BS 24. The history module 68 on the BS then retrieves the requested portion 256, typically from DB 64 and the BS 24 sends the requested portion to the GS 20. The GS 20 then suspends processing of player inputs 112 on the designated PCs 12, thereby suspending play thereon, and transmits the requested portion to the requested computer 12, 170 with a replay instruction to display the player inputs 112 and player outputs 114 in sequence. The game client 120 on the requested computer 12, 170 then display the player inputs 112 and player outputs 114 in sequence, thereby replaying the requested portion 206. Once the requested portion 206 has been replayed the requested computer sends a message to the GS 20 indicating that the requested portion has been replayed, and the GS re-enables processing of player inputs 112 on the designated PCs 12, allowing play of the game to resume. PCs 12 other than the designated PCs 12 remain unaffected by the replay request 250 thus allowing play to continue thereon during processing of the replay request.

To provide the reader with additional details on table 26, reference is now made to FIG. 9, which shows an exemplary table 26, typically podium based, for system 10. Table 26 shown in FIG. 9 is an 8 ft×5 ft long wooden oval table which contains a 37-inch LCD CDU 16, ten x86 architecture panel PCs having having 10.4″ displays as PCs 12, and ten CRs 14. A leather padded armrest 80 extends around top 82 of table 26, the top 82 being covered by Scotch Guard®, with felt on top of the Scotch Guard®. Each PC 12 has a 10.4 display 94 extending from top at, preferably, a 15 degree incline therewith, although the degree of incline may also be adjustable. Further each display 84 is a 5-wire resistive touch screen integrated with panel PC of PC 12. PC 12 and display 84 are housed in National Electrical Manufacturers Association NEMA 4 rated ventilated metal housing. CDU 16 is also NEMA 4 rated. Further PC 12 and display 84 are modular and removable without tools for simple and fast replacement or repair. CR 14 are slot loaded with acrylic covers. The base 260 of the table 26, which may square, as shown, or oval, for example in the shape of a racetrack, and houses the TBS 40.

Referring again to FIG. 1 and FIG. 9, an exemplary version of TBS 40 is now presented. TBS 40 preferable contains the computer for TBS 40 as well as all power and networking equipment required for table 26 and all elements 12, 14, 16 thereof. Preferably, the base 260 of the TBS 40 houses the TBS 40 on a lockable ventilated pull-out closure mechanism, for example a pull-out door with a lock, allowing for facilitated access to TBS 40 when maintenance is required. Further, TBS 40 is removable from table 26 and interchangeable. A light automatically turns on when the door is opened. A hole at the bottom of TBS 40 provides for facilitated connection of the TBS to a power supply, such as a power outlet. Speakers are attached to doors. In addition, TBS 40 also houses: power equipment for each of the PCs 12, displays 84, and CDU 16, networking equipment for each PC 12, computer for TBS 40 which acts as a server for PC 12, a 16-port hub switch to which computer of TBS and each PC 12 is connected via Ethernet, and a power management system that allows all electrical components to connect via one plug using a single phase.

While a specific embodiment has been described, those skilled in the art will recognize many alterations that could be made within the spirit of the invention.

Claims

1. A wager-based gaming system comprising:

at least one table having at least one respective player computer disposed thereupon for receiving respective player inputs for a player for a respective game for said table playable on said player computer and for displaying game outputs therefor, said respective player inputs comprising at least one wager and said game outputs comprising an outcome therefor;

for each player computer, a respective card reader communicably connected thereto for reading at least a portion of respective player data for said player from a respective microprocessor, on a respective smart card therefor when said smart card is inserted therein, said portion being store on said microprocessor;

at least on game server communicable connected to each player computer and storing game logic defining said game for applying said game logic to said respective player inputs and generating thereby said game outputs; and

a backend server to which each game server, and thereby said player computer, is communicably connected and upon which all said player data is stored for validating whether there is correspondence between said portion read by said card reader against player data stored thereon, said backend server authorizing access to said player data stored thereon from said player computer for playing said game if said correspondence is validated.

2. The system of claim 1, wherein said player data comprises a respective account balance for said player and from which said wager may be placed said respective account balance being updated based on said outcome.

3. The system of claim 1, wherein said respective player data is writable to said microprocessor by said card reader when said smart card is inserted therein and said correspondence is validated, said backend server transmitting said portion to said card reader when said portion is modified thereon for writing on said microprocessor to update said portion.

4. The system of claim 1, wherein said portion is stored on said card reader in encrypted format, said portion being transmitted between said backend server and said card reader in said encrypted format.

5. The system of claim 1, wherein all of said player data is also stored on said microprocessor.

6. The system of claim 1, further comprising at least one server computer, each server computer being communicable connected to one another by at least one network and upon which said game server and said backend server reside, each game server residing on a respective server computer therefor communicably connected by said at least one network to said player computer.

7. The system of claim 2, further comprising, for each player computer, a respective currency receiver communicably connected thereto for receiving a respective player deposit of currency and determining a deposit value therefor, said deposit value being creditable to said respective account balance by said backend server when updating said account balance.

8. The system of claim 7, wherein said game server stores a respective session balance for each player computer while said player plays said game thereon, said game server initially setting said respective session balance to zero, updating said respective session balance based on said outcome, and crediting each said respective deposit value thereto, said game server, if said correspondence is validated for said player on said player computer, adding said respective account balance to said respective session balance and transmitting said respective session balance to said backend server which assigns said respective session balance to said respective account balance for said player, thereby updating said respective account balance.

9. The system of claim 8, wherein said game server, when said correspondence is not validated and when requested by said player input, transmits said respective session balance to said backend server, said backend server generating a ticket output containing said respective session balance for printing as a ticket by a printer communicably connect to said player computer upon which said player is playing, said ticket being redeemable for one of money and credit to said session balance on any said gaming machine for playing said game thereupon.

10. The system of claim 1, wherein said player computer is a panel personal computer having a touch screen upon which said respective player inputs may be entered for playing of said game and upon which said respective player inputs and game outputs are displayed.

11. The system of claim 1, wherein said game is a selected game selectable from a plurality of games from said backend sever, said game server having, for each game of said plurality, a respective game logic module therefor stored thereon and comprising said game logic, each game logic module being selectively activatable and deactivateable on said game server from said backend server to respectively select and deselect said selected game.

12. The system of claim 11, wherein said player computer comprises a game client module comprising a respective game interface for receiving said respective player inputs, said game client module transmitting said respective player inputs to said game server and receiving said game outputs therefrom, said game interface displaying said game by displaying at least a portion of said respective player inputs and said game outputs.

13. The system of claim 13, wherein said game client module comprises a respective game specific interface elements module for said game interface that defines respective game specific interface elements specific to said selected game and a general client platform module containing common interface elements for said game interface and which are common to all said games of said plurality of games, said respective game-specific interface module being activated for said game interface when said respective game logic module for said selected game is activated to enable playing of said selected game.

14. The system of claim 11, wherein said backend server comprises a remote configuration module for transmitting scheduling instructions designating a designated said respective game logic module for a designated said game to said game server, said game server deactivating said respective game logic module for said selected game once said game server determines said outcome for any instance of said selected game in progress when said scheduling instruction is received and subsequently activating said designated said respective game logic module, said designated said game thereby being selected as said selected game.

15. The system of claim 14, wherein said game server transmits a message specifying said designated said game to said game client when said designated said game logic module is activated, said game client deactivating said respective game-specific interface elements module for said selected game and activating said respective game-specific interface elements module for said designated said game.

16. The system of claim 10, wherein said back end server comprises a programmable schedule, said programmable schedule defining at least one programmed time at which a respective said scheduling instruction associated therewith is to be sent to said game server, said programmable schedule enabling automated and scheduled selection of said selected game.

17. The system of claim 16, wherein said scheduling instruction further comprises configuration information specifying a game configuration for said designated said game, said game server activating said designated said game logic module and configuring said designated said game in accordance with said game configuration.

18. The system of claim 14, further comprising, for

a respective table server computer therefor, said table server computer being securely housed in said table to prevent access by said player thereto and communicably connected to said game server and to each player computer on said table and providing communication of said player inputs and said game outputs therebetween; and

a common display unit disposed on said table and communicably connected to said table server computer, said table server computer having said game client resident thereon and displaying said game on said common display unit.

19. The system of claim 18, further comprising, at least one monitoring computer communicably connected to said game server and having said game client module resident thereon, said game client module on said monitoring computer being configured for limiting use of said monitoring computer to displaying said game.

20. The system of claim 14, wherein said backend server comprises a history module, said game server transmitting all player inputs entered into each said game client on each said player computer to play said game and all said game outputs generated to said backend server, said history module storing all said player inputs and said game outputs on said backend server.

21. The system of claim 20, wherein said game client is configured for receiving a replay request from a user thereof for replay of at least a portion of said player inputs and said game outputs for said game for at least one designated said player computer designated in said replay request on a requested computer designated in said replay request and having said game client module resident thereon, said game client module transmitting said replay request to said game server which transmits said replay request to said backend server, said history module retrieving said requested portion from said history module and transmitting said requested portion to said game server, said game server suspending said player inputs on said designated said personal computer, thereby suspending play of said game thereon and said game client on said requested computer displaying each player input and each game output of said requested portion in sequence, thereby replaying said portion.

22. The system of claim 17, wherein said requested computer is at least one of said designated gaming computer, said monitoring computer, and said table server computer.

23. A method for providing wager-based gaming on a table, said method comprising the steps of:

receiving a smart card having a microprocessor in a smart card reader situated at said table and communicably connected to at least one respective player computer for the table and upon which at least one respective game for said table is playable, said microprocessor having at least a portion of respective player data relating to said player stored thereupon, all said player data being stored on a backend server connected to said player computer;

reading said portion into said player computer with said card reader;

validating whether there is correspondence of said portion with said player data on said server computer;

if said correspondence is validated, authorizing use of said respective player data from said gaming computer while said player plays said game thereupon, generating game outputs by applying game logic defining said game to respective player inputs input by said player on said player, said respective player inputs comprising at least one respective wager made by said player, said respective game outputs comprising a respective outcome for said game for said player.

24. The method of claim 23, wherein said player data comprises a respective account balance for said player and from which said respective wager may be placed, said method further comprising the step of, if said correspondence is validated, updating said respective account balance based on said respective outcome.

25. The method of claim of claim 23, further comprising the steps of:

assigning a respective session balance to said player computer and from which said respective wagers may be made;

accepting said wagers against said session balance while said player plays said game; and

updating said session balance based on said outcome.

26. The method of claim 25, further comprising the steps of:

receiving a respective player deposit of currency from said player in a currency receiver connected to said player computer;

determining a deposit value of said deposit; and

adding said deposit value to said session balance.

27. The method of claim 26, wherein said player data comprises an account balance redeemable for money and from which said wager may be placed, said session balance being initially set to said account balance if said correspondence is validated, said session balance being otherwise initially set to 0.

28. The method of claim 26, wherein after said updating of said session balance for said player computer, said respective account balance for said player playing on said player computer is updated by assigning said session balance thereto if said correspondence has been validated.

29. The method of claim 23, wherein said game is a selected game selected from a plurality of games, each game having a respective game logic module therefor stored on a game server connected to said backend server, said method further comprising the steps of:

transmitting a scheduling instruction for actuating a designated said respective game logic module for a designated said game designated in said scheduling instruction to said game server; and

after said outcome, for any instance of said selected game in progress on said game server has been generated thereby, deactuating said game logic module for said selected game and actuating said game logic module for said designated said game, said designated said game thereby being selected and actuated as said selected game.

30. The method of claim 29, further comprising the step of prior to said step of transmitting said scheduling instruction, consulting a schedule stored on said backend server which defines said scheduling instruction and a time for transmitting said scheduling instruction.

31. The method of claim 23, further comprising the steps of:

receiving a replay request requesting replay of at least a requested portion of said player inputs and game outputs for at least one designated player computer and specifying a requested computer for displaying said portion;

retrieving said requested portion from said backend server, all said player inputs and said game outputs being stored thereupon;

transmitting said requested portion retrieved to said requested computer;

suspending play of said game on said designated computer;

displaying said requested portion on said designated computer, thereby replaying said requested portion; and

re-enabling play of said game on said designated computer.