WO2008152412A1

WO2008152412A1 - Networked gaming apparatus

Info

Publication number: WO2008152412A1
Application number: PCT/GB2008/002063
Authority: WO
Inventors: Vincent Leonard
Original assignee: Inspired Gaming UK Ltd
Current assignee: Inspired Gaming UK Ltd
Priority date: 2007-06-11
Filing date: 2008-06-09
Publication date: 2008-12-18
Anticipated expiration: 2009-12-11
Also published as: GB0711237D0

Abstract

The present invention develops the functionality of existing networked gaming apparatus by providing the ability for players not seated at a card table (101) to participate interactively by way of terminals (114 ) with a live game also having local λat-game' participants. Information and instructions are distributed around the apparatus so that neither at-table participants nor the remote participants have an advantage yet without causing unnecessary delays in gameplay.

Description

NETWORKED GAMING APPARATUS

This invention relates to electronic gaming, e.g. on terminals located in pubs, casinos or betting offices, where a gaming result at a player terminal is determined by an event occurring remotely from that terminal, e.g. elsewhere in a venue hosting the player terminal or at a separate geographical location.

Providing the facility to play games over electronic networks is common. For example, players may participate in games provided on-line, i.e. playable over the Internet, interactive television or other suitable networks. Electronic gaming or betting terminals are another well known means for providing a variety of games in casinos, betting shops, pubs and the like e.g. over a private network. Typically, the terminals are arranged to receive credit in the form of coins, notes or bar- coded tickets from a user in order to permit the user to participate in game play. Conventional terminals in casinos and/or betting shops permit the user to gamble their credit on the game or games offered by the terminal.

It is known to network gaming terminals within a venue. For example, casinos have found that the provision of networked betting terminals spatially separated from the location, e.g. table, where a game is being played provides a private betting space that is desirable for some users. Furthermore, more players may participate in a game because physical constraints on space e.g. on the number of players who can fit around a table, are removed. One example of such a system is described in EP 1151768. The conventional use of gaming terminals in venues other than casinos can be different. Typically, only a few e.g. one or two terminals are provided in each venue (betting shop or pub) . These terminals may be connected to a central server via a global network (e.g. wide area networks) in order to monitor their usage, to generate results (game outcomes) centrally, and to download games, results or other updates without the need for an operator physically to attend the terminal. Typically, the terminals are used to place bets and are therefore equipped with means to generate payment of either cash, vouchers or tokens. In some conventional systems, the bets are based on external events, e.g. which may occur at the same location as the terminal (e.g. a roulette table in a casino) or externally to the venue (e.g. the result of a horse race occurring elsewhere in the country) or an off-site (remote) random number generator.

The present invention develops the functionality of existing networked gaming apparatus by providing the ability for remote players to participate interactively with a live game (e.g. casino game) which may also have local ^λat-game' participants. Existing arrangements comprise two types: games where all players participate using a networked terminal, and games where there are a mix of remote (terminal) players and live (at-table) players. In the latter type, the remote terminals on the network are merely passive observers of the live game (e.g. roulette) . They are arranged to obtain the a gaming result e.g. to determine the outcome of a player bet placed using the terminal from the live game. The mix of at-table participants and remote players has been thought unsuitable for games where interaction is required, i.e. where participants give instructions e.g. to a card dealer to arrive at the game outcome or where a player's game strategy may depend on how other participants choose to play. One problem is how to obtain and distribute information and instructions around the system so that neither at-table participants nor remote participants have an advantage yet without causing unnecessary delays in gameplay. Accordingly, the invention may provide networked gaming apparatus capable of scanning and identifying elements of gameplay e.g. playing cards rapidly and with minimal error. Moreover, for functionality with interactive games, the apparatus of the invention may be capable of recording the live gameplay of at-table players, e.g. how hands are played out, without requiring the at-table players or dealer also to play electronically, e.g. via an at-table electronic terminal. At its most general, the present invention provides networked gaming apparatus where a computer generated display showing gameplay information from both at-game and remote players is provided by combining remote gameplay data received from remote player terminal with live gameplay data from a live (e.g. real) gameplay surface captured using a sensor device at the gameplay surface. Data may be captured in real time to permit interactive participation in a game played on the live gameplay surface by both remote and at-table players. By providing the computer generated display to both remote and at-table players, every player may be able to see the same gameplay information. The apparatus of the invention may be particularly suitable for card games, e.g. blackjack, poker, baccarat or the like, where players may need to interact with the dealer to determine the outcome of their hand and/or where betting behaviour of other players may influence a player's game strategy. The sensor device may be optical recognition apparatus, e.g. a camera capturing images of the gameplay surface or of cards as they are dealt from a card shoe. Alternative sensing technologies may be used, e.g. radio frequency identification (RFID) chips mounted in cards, betting chips or other playing pieces. Thus, according to the invention there may be provided networked gaming apparatus comprising: a server communicably connected to at least one participating remote player terminal, each participating remote player terminal having a display unit and an instruction input unit and being arranged to communicate remote gameplay data to the server based on instructions received at the instruction input unit; a playing surface for hosting gameplay; a display unit associated with the playing surface; a sensor device communicably connected to the server and arranged to sense gameplay at the playing surface, generate live gameplay data and communicate the live gameplay data to the server; and processing means arranged to execute software instructions to generate a gameplay information display based on the live gameplay data and remote gameplay data received at the server, and cause the generated gameplay information display to be displayed on the display unit of each participating remote player terminal and the playing surface display unit . The processing means may include a processor in the server. This processor may be arranged to execute an application for determining an outcome of each game based on the remote gameplay data and the live gameplay data. The determined outcome may be communicated to the terminals. This arrangement can centralise processing and make the apparatus more efficient. During gameplay, the server' s processor may be arranged to communicate the generated gameplay information display to the display unit of each participating remote player terminal and the playing surface display unit for display thereon. Alternatively, the server may be arranged to combine the received live gameplay data and remote gameplay data into a format suitable for processing by a processor at each participating remote player terminal (or the display unit associated with the playing surface) . In such a case the processing means is distributed across the networked gaming apparatus and the gameplay information display is generated at each participating remote player terminal or at the playing surface display unit.

The gameplay information display may be customised at each display. Thus, in one embodiment, the viewpoint of the gameplay information display on a terminal display may be centred on the gameplay region associated with that terminal. Meanwhile, the gameplay information display on the playing surface display may have a neutral viewpoint or may show the dealer's viewpoint. In both cases, the same total information content may be displayed.

The playing surface may be a table having gameplay regions associated with each participant (e.g. dealer, live (at-table) player and remote player) . The table may be a card table and the gameplay regions may be areas on the table allocated to receive the cards which make up a player's hand.

The sensor device may be optical recognition apparatus arranged to capture images of the playing surface and to generate the live gameplay data based on those captured images. For example, the optical recognition apparatus may be arranged to capture an image of the gameplay regions and interpret the captured image to determine the live gameplay data. For example, the optical recognition apparatus may be arranged to recognise one or more cards dealt into a gameplay region. The live gameplay data may be an identification of the card (e.g. suit and value) and position (e.g. gameplay region) in which it appears. US Patent Application Publication No. 2007/0077987 discloses optical recognition apparatus capable of performing this function. A camera for capturing images of the playing surface may be provided for each gameplay region. Alternatively, a single camera overlooking the whole playing surface may be provided.

In one embodiment, communications to and from the server are via the Extensible Messaging and Presence Protocol (XMPP) . For example, an XMPP server may be provided as a communications interface between the server and each participating remote player terminal, optical recognition apparatus, playing surface display unit or any other external component (e.g. dealer display mentioned below) . The apparatus may include a dealer display unit communicably connected to the server and arranged to display dealer instructions from the remote terminal, wherein the dealer instructions are based on the remote gameplay data received by the server. The server may generate the dealer instructions.

The server may be connected to a database which is arranged to store the remote gameplay data and live gameplay data received at the server e.g. to the progress of games to be recorded and to provide an audit trail. The database may also store game configuration data, e.g. to enable a game to be customised for a particular location (e.g. casino). The networked gaming apparatus may further include one or more non-participating terminals, the or each non- participating terminal comprising a display unit, the processing means causing the generated gameplay information display also to be displayed on the display unit of the or each non-participating terminal.

Further options and preferences are described below in relation to an embodiment of the invention with reference to the accompanying drawings, in which: Fig. 1 is a schematic diagram of a networked gaming apparatus that is an embodiment of the invention;

Fig. 2 is a component map showing communication links between components of the invention;

Fig. 3 is a block diagram which illustrates data fields contained in a database that is arranged to store gameplay data; and

Fig. 4 is a screenshot of a gameplay information display that can be provided by an embodiment of the invention.

The embodiment discussed below is based on the card game blackjack. Clearly the technical principles underlying this specific implementation are applicable to similar interactive casino games, e.g. involving cards, dice or the like. The invention provides the technology to enable a casino patron to participate from a remote player terminal in a live (real) game of blackjack which may involve at-table players. In the embodiment, the blackjack game is played at a table that is arranged to receive local (at-table) players, who participate in the game as normal. However, at least one gameplay region (i.e. dealing position) is reserved for remote players,- e.g. players playing via a remote terminal. The invention may be arranged to permit one or more remote players to play the same hand, and to permit remote players to select a position at the table to be reserved for them. In one embodiment, only one position is reserved for all remote players. In that case, each remote player may play the same hand. In another embodiment, every position at the table may be for a remote player. These options may be configurable for a particular venue. The configuration data may be stored in the database (discussed below) .

One important feature of the embodiment is a sensor device which can scan each dealt cards and determine the card number and suit as well as which player is receiving that card. This determined content is used in the generation of a gameplay information display which is presented to all players so that the status of the game is available to all players equally at all times. Three technologies suitable for implementing the sensor device are discussed briefly below: 1. Radio frequency identification (RFID) chips may be built into each individual playing card and/or betting chip. RFID readers may be provided (e.g. lying flat) under the table cloth of the blackjack table at each gameplay position, e.g. where cards are dealt for each player and the dealer. As cards are dealt (or betting chips deposited) into a reader's gameplay region, the RFID chip is energised and its unique code is picked up communicated to a central server. The server is able to ascertain to whom the card is dealt or who made a bet by identifying the reader from which it receives the card identification. This technology can be used to record each hand without requiring any dealer interaction. 2. An intelligent shoe, i.e. a card shoe fitted with a scanner may be arranged to read each card as it is dealt. The number and suit of the card may then be provided to a server for further processing. The shoe may be provided with player identification unit, e.g. push buttons for the dealer to press, so that the identified card can be matched with a player.

3. Optical recognition apparatus may be provided at the playing surface. For example, a camera may overlook the table, either for the dedicated purpose of identifying dealt cards or using combined with an existing security camera feed. The camera is arranged to scan each card that arrives into a gameplay region (i.e. region of the playing surface associated with a particular player) . The number and suit of the card and the specific gameplay region can be identified and communicated to the server for further processing. This system has does not require any dealer interaction and possesses the additional benefit that each player's strategic behaviour (i.e. their gameplay decisions) can be observed in real time.

The third option - optical recognition apparatus - is used in the embodiment described below. This type of technology is produced by Tangam Gaming Inc., and is described in e.g. US Patent Application Publication No. 2007/0077987. The apparatus may comprise a camera and an associated server arranged to execute software to identify every card dealt and what position it went to. The apparatus may therefore identify individual player gameplay, i.e. each individual's set of card, as they are dealt. The camera server is arranged to communicate every card and every decision in real time via a data file (e.g. in Extensible Markup Language (XML) format) to a central (game) server for further processing.

Fig. 1 is a network diagram of gaming apparatus 100 that is an embodiment of the invention. The apparatus 100 is based around a blackjack table 101 which provides a playing surface on which a dealer 104 deals cards from a card shoe 103 for participating players. The blackjack table 101 is arranged to receive players at the table itself (referred to herein as at-table players) . A display unit (e.g. plasma screen) 102 is provided above the dealer 104 where it is viewable by players playing at the table 101. The display unit 104 is arranged to display the gameplay information display, which is described in more detail below. A dealer console 106 is provided next to the dealer, which is arranged to display gameplay instructions for the dealer 104 e.g. from remote players. The dealer console 106 may be a tablet or touch screen PC that the dealer can interact with to control the flow of the game, report errors and receive information about the terminal status. A camera 108 is arranged to capture images of the blackjack table 101. The captured images are processed by software running on a camera server 110 to recognise the position and identity of dealt cards .

A server 112 is communicably connected to the camera server 110, the display unit 102 and the dealer console 106. The server 112 acts as an intermediary between the blackjack table 101 and a plurality of remote terminals 114 (connected to the server via a router 116) . In the illustrated embodiment the server 112 is shown connected to a signal blackjack table. However, the server may be arranged to control simultaneously independent games on a plurality of blackjack tables.

The remote terminals 114 may be of the conventional type. Each terminal 114 may have a processor arranged to execute software instructions to allow a player at that terminal (referred to herein as a remote player) to participate in a blackjack game played on the blackjack table 101. Each terminal 114 comprises a display unit (e.g. LCD or CRT screen) and an instruction input unit (e.g. keypad, joystick, rollerball, touchscreen or the like) to enable the remote player to participate in the game by observing gameplay and sending instructions for interacting with the game. Each terminal 114 may include credit receiving means (not shown) arranged to receive a variety of monetary inputs. For example, the credit receiving means may include one or more of a coin slot, a credit card receptacle, paper currency reader, token receptacle and barcode reader. The monetary input may be direct, e.g. cash, i.e. coins or notes. Alternatively, the monetary input may be indirect e.g. via credit card or bar-coded ticket, tokens, etc.

Each terminal 114 may include payment awarding means (not shown) arranged to deliver winnings to user by direct means (e.g. cash) or indirect means, e.g. by token, printed cheque, bar-coded ticket, etc. The credit receiving means and payment awarding means may comprise a "ticket-in, ticket-out" (TITO) system to permit cashless gaming.

Based on information (live gameplay data) received from the camera server 110 and information received from each terminal 114 (remote gameplay data) , the server 112 is arranged to generate gameplay information display- data, which is displayed on the terminal display units and display unit 102, and dealer instruction data, which is displayed on dealer console 106. The server components are discussed in more detail with respect to Fig. 2. However, it can be seen in Fig. 1 that in this embodiment the server 112 comprises a XMPP component 118, which sends and receives messages to and from all peripheral components (i.e. terminals 114, dealer console 106, camera server 110) . The XMPP component 118 therefore handles all messaging traffic e.g. by relaying information to all connected peripherals about the status of the game and players' hands. In an embodiment where there are no live players (i.e. an all electronic setup), the XMPP server may assume control of the game. The dealer 104 in such a case simply becomes a dumb entity that receives instructions from the dealer console 106, e.g. "deal card", "do not deal card", etc. The XMPP component 118 can communicate the data it receives to a game server 120, which is arranged to process that data to determine the outcome of the game and to assemble the gameplay information display data, which may include details of the status of the game and options available to an active player. The game server 120 is connected to a database server 122, which can store the received gameplay data and generated information display data to provide an audit trail and enable any disputes to be resolved.

One advantage of the illustrated embodiment is that dealer interaction with the operation of the electronic part of the game is minimal. For example, the dealer does not need to identify to whom a card is dealt other than putting it in the relevant region of the blackjack table 101. This is a normal operation for a dealer in a live blackjack game. However, in case a mistake is made by the dealer or by the optical recognition apparatus, the dealer console 106 may be operable (e.g. by the dealer or his supervisor) to permit a correction to be sent to the server 112.

Fig. 2 is a component map showing the server 112 and the elements with which it interacts in more detail. As mentioned above, the server includes an XMPP server 118 which provides bidirectional messaging with presence between various clients and the main game server (shown as card server 121 in this diagram) . The XMPP server may be an off-the-shelf implementation of the XMPP standard e.g. using Openfire (previously Wildfire) product from Jive Software.

The clients of the XMPP server 118 include end user (remote player) terminal 114, dealer terminal 106, table player display 102 and camera server 110.

The end user terminal 114 operates a core application 124 which provides the player credit management operations for a variety of content (e.g. different game types) that may be available on the terminal. A blackjack content application 126 is provided on top of the core application 124. This application provides the graphical content in which a player is offered cards during their turn, and present the options available for gameplay and to place bets. The blackjack content application 126 communicates with the card server 121 via the XMPP 118 to send remote gameplay data and receive the gameplay information data upon which the graphical content and options for gameplay are based. The dealer terminal 106 and the table player display

102 may run a table player display application 128, which communicates with the card server 121 via the XMPP server

118 to receive gameplay information data which is used to generate a display showing gameplay status for all players (remote, live and dealer) . The table player display application 128 may also include instruction for the dealer, e.g. indicating whether or not a remote player requires an additional card. The table player display application 128 may be embodied as a simple flash application e.g. which can subscribe to a chat room in the XMPP server 118 and therefore receive updates from the card server 121 in XML format. The updates may fall into two classes. A first class may be a suite of data on current state of gameplay. A second class may be up to date statistics for display. The blackjack content application 126 may subscribe to the same classes of information. The data may be suitably abstracted so that the actual form of display is determined at the respective application (s) .

The camera server 110 runs an optical recognition application 130 that is arranged to transform the images captured by the camera into live gameplay data e.g. identifying card type and position. This data is forwarded (e.g. in XML format) to the card server 121 via the XMPP server 118.

The card server 121 is connected to the XMPP server 118 to receive live and remote gameplay data from the camera server 110 and player terminal 114. The card server runs a blackjack application (plugin) 132 to control gameplay, e.g. determine game status and options available to players and at the end of each game determine the result and calculate appropriate winnings e.g. for remote players. The blackjack plugin 132 may perform the bulk of the gameplay processing. To keep the client devices as simply as possible it is desirable to have as much logic as possible concentrated here. The blackjack plugin 132 may be written as a Java web application (even though most communications are via XMPP) for ease of deployment and management.

The card server 121 also communicates with a card database 122. The database 122 stores standing data which records the progress of games and provides an audit trail. The database 122 may also store any local venue configuration data. The database 122 may be implemented using MS SQL 2000 SP 4.

A reporting application 134 is connected to the database 122 to enable the contents of the database to be accessed separately from gameplay, e.g. to permit game outcomes to be verified, disputed claims to be cleared, and performance to be measured.

Fig. 3 shows a selection of data fields that are suitable for database 122 to record the progress of a card game. This data model is generic for any turn based card game, and implies that the software can "replay" a hand internally into the plugin application 132 or reporting application 134 to determine or validate a- result.

The game_type field 300 identifies the game (e.g. plugin application 132) operating on the card server 121. In this embodiment the entry may be BLACKJACK. Having the ability to store different fields makes the apparatus extensible, i.e. capable of running a variety of games, e.g. poker, baccarat or the like.

Configurable (e.g. locally configurable or venue dependent) game options may be set in the game_type_properties field 302. This field may contain arbitrary flags denoting house preferences for certain options within a game, e.g. a flag labelled ALLOW_SPLIT could denote whether or not the split option is to be enabled.

Participants in the game may be registered in the database 122. For example, there is a dealer field 304 and a user field 306. This may enable dealer performance to be recorded and analysed and player performance and behaviour to be tracked, e.g. for awarding loyalty bonuses and the like. A position_type field 308 may associate each participant with their respective position, e.g. DEALER (of which there may only be one in any game) , TABLE (for a live at-table player) and ELECTRONIC for a remote terminal player. Each participant is also linked to a physical position in a venue, i.e. a certain seat or gameplay region on a certain table. This can be coded, e.g. 1703 may represent the third seat from the dealer on table 17 in a casino. Position field 310 may store a fixed set of data representing all available positions and contain a link between each position and entries in the position_type field 308.

A hand field 312 stores data to identify each round (i.e. independent game) of blackjack. A hand can have any number of players (plus dealer) . The hand identification data stored in the hand field 312 is linked with the game type and dealer identification information stored in the game_type field 300 and dealer field 304 respectively.

A hand position field 314 links the above data to record which participants occupied which positions for which hand. After the hand is concluded, the winnings associated with the hand can be recorded e.g. matched to the winning user. This field is therefore useful for obtaining gameplay statistics.

A card field 316 may contain a fixed set of data identifying the 52 playing cards in a pack. This information can be used to assemble a card__id entry in a dealt__card field 318, which records each dealt card, i.e. what the card is and at what position it is received. Where a player splits, he effectively has two or more playable card combinations at the same position. Each dealt card is therefore assigned a split_index entry so that the combinations can be distinguished.

A stake field 320 can store details of a bet placed at a certain position for a certain hand. The apparatus is arranged to operate e.g. under the ultimate control of software running on the server 112 in one of a plurality of game states. Each game state may be dependent on the state of the playing surface, and therefore may be determined by the server 112 based on the live gameplay data received from the camera server 110. Other ways of determined game state are possible, e.g. via direct instruction from the dealer 104. For example, in blackjack before any cards are dealt each player must place a stake. This may be a first game state, referred to under the banner ^Λplace your stake' . When all hole cards are dealt (e.g. two per player) each player in turn may be presented with one or more options e.g. ^Λhit', ^λstand', ^λdouble' , ^Λsplit' or ^λtake insurance' . These choices may all be presented in a second game state, e.g. under the general banner ^λmake a play' . In one embodiment, there may be a maximum time (e.g. 5 to 10 seconds) for selecting a play. Before a player' s turn to play and when a player has finished their ^Λmake a play' by standing or busting out, there may be a third game state, referred to under the banner 'no more bets' .

The apparatus may be arranged to permit new players only during a particular game state, e.g. the ^Λplace your stake' phase. If players join during another game state, they may be permitted to place chips down but they will not be dealt in until next round.

The action associated with commencing each game states is summarised in Table 1.

Table 1: Trigger actions for game states

Where there are a number of remote players playing the same position (hand) on the table, the apparatus is arranged to wait until it receives remote gameplay data from each of the participating terminals or until a preset play time has expired (whichever comes first) before sending instructions to the dealer console 106 e.g. to inform the dealer to deal another card to the hand or to move onto the next position.

By way of example, a hand where there are nine remote players playing the same position at the blackjack table may play out as follows:

- Dealer deals the two hole cards e.g. totalling 13 the relevant position on the table.

- The hole cards are displayed on all the remote terminals . - Each terminal present options for response (e.g. stand, hit etc.) to its remote player.

- Two players decide to stand, one player does not make a decision in the preset play time, and six players decide to hit.

- When the preset play time runs out (because one player did not make a response in time) , the dealer is instructed to deal another card to the relevant position on the table because at least one remote player has decided to hit. If a decision was received from all the terminals before the end of the preset play time, the instruction to the dealer may be sent earlier.

- The additional card (e.g. having a value of 5) is displayed on all of the terminals (including those where the decision was to stand on 13) , but the options for further play (e.g. stand, hit) are presented only on the terminals whose players chose to hit.

- Four (of the six remaining) remote player choose to stand on 18, while the other two choose to hit. - When the response is received from the six ^λin- play' terminals, the dealer is instructed to deal another card to the relevant position on the table because at least one remote player has decided to hit .

- The additional card (e.g. having a value of 9) is displayed on all of the terminals (including those where the decision was to stand on 13 or 18) .

- The two players who decided to hit are now bust on 27. The remote players turn therefore ends and the dealer moves to the next position on the blackjack table. - The two players who bust lose; the players stood on 13 and 18 must wait for the dealer' s turn before finding out whether they have won. The rules for deciding a win are summarised in an appendix at the end of the description.

The display may show a summary of how all the remote players play the hand; Table 2 below shows such a summary for the hand described above.

As mentioned above, in the event of dealer error or a camera misread the gameplay information display data can be corrected. This may be done via the dealer console. For example, during a manual correction operation (e.g. accessible using login and password), the dealer console may display a table layout showing the system' s interpretation of all hands in the current round. Each position may be selectable, whereby a position that is different on the screen to what it is on the table can be highlighted. The screen may then display options for correction, e.g. all available cards or all cards dealt in that round. Each hand may thus be corrected. At each position the option to save or cancel is given. Once all positions have been corrected in the system the user can select continue. This will bring the user back to the main screen where the dealer can end the game, which processes the result. In another embodiment, it may be possible to automatically correct the hand by rearranging the cards on the table to a more readable layout. The camera could then take a new snapshot of every position and display the recalculated hands on each screen.

The blackjack table may include a visible or audible signal to indicate when the remote player (s) have completed their turn (i.e. have stood or bust). This signal can act as a prompt for the dealer to move to the next hand. In an embodiment where only the first playing position is for remote players, the signal is a indication that play has moved to the first live player.

Most casinos require the dealer to play a consistent strategy (e.g. a basic strategy such as ^xhit until 17') . Once a dealer has played his hand, the result may be displayed on the dealer console to permit the dealer to confirm or override the system interpretation before the result is used to determine the game outcome for each remote player. This system can avoid payouts based on erroneous readings. A confirm sends a message to the server that this game is complete and to go ahead and calculate the payouts for all terminals.

The system may detect if a strategy other than that ascribed is played by the dealer i.e. if the dealer tries to complete the round too early. An audible alarm may sound and an alert logged. The dealer may then complete the round properly.

The following steps outline steps in typical gameplay for the dealer where the dealer plays a remote player (at a terminal) and a live player: i. Dealer plays first card to remote player, ii. Dealer plays first card to live player, iii. Dealer deals himself face down. iv. Second card to remote player. v. Second card to live player. vi . Second card to dealer face up. vii. Dealer console indicates whether or not to deal to remote player (e.g. using suitably coloured LED or audible or visual instruction) . viii. When remote player's turn is finished a live play signal is produced (e.g. a light for all live players to see) . ix. Dealer plays out live player as normal. x. Dealer plays their own hand. xi . Dealer ends game by pressing end on dealer console (this may be automatic) . xii. Dealer removes cards from table and system pays out accordingly.

Each terminal is arranged to present a player with a Graphical User Interface (GUI) generated by an application running on the terminal based on the gameplay information data from the server. The player can interact with the GUI to send remote gameplay instructions to the server to take part in the game on the blackjack table.

Fig. 4 shows an example of a typical GUI. The screen view may be based on existing online gaming sites. Typically, such screen have animated portions to render gameplay more realistic, e.g. the card being dealt and turned over may be shown as an animated action.

In this embodiment, the GUI is implemented on a touch screen and therefore comprises a number of gameplay areas which may be selected on have icons dragged thereon to enable the user to send instructions to the server. The touch screen and GUI therefore make up an instruction input unit for the player terminal.

The terminal is arranged to generate the GUI based on gameplay information data from server. The gameplay information data comprises data from the blackjack table and data from the terminal and other remote terminal (if present) . As mentioned above, the terminal is also arranged to collect remote gameplay data from the player via the GUI to send to the server. Thus, in Fig. 4 there is a place bets region 200 into which a player can drag betting chip icons 208 from his credit to place a bet on the next game. A previously placed bet may be displayed at previous bet region 210. As a short cut to dragging the icons, a player may select the re-bet option 212 to place the bet displayed in the previous bet region 210. Place bet regions 214 for other players (e.g. at- table players or remote players) are also provided on the GUI. The terminal may be arranged to cause chips to appear in this regions corresponding to bets made by players at the table or at other terminals. Bets placed at the table are detected by the camera and local gameplay data provided to the server from the camera server includes information about the amount and location of each bet. This information can be forwarded to the terminal by the server in the gameplay information data. The cards dealt to the player are displayed in a gameplay region 202. The displayed images correspond to the real cards dealt to the remote player on the blackjack table which are detected by the camera. The hands of other players and the dealer hand 204 may be displayed in a similar fashion. The screenshot in Fig. 4 shows the end of a game, with the dealer's hand fully displayed and a game outcome display 216 informing the player that he has won.

A credit display 206 which summarises the player's financial situation is provided in a banner across the bottom of the screen. This is conventional.

During gameplay, the application (content) on the terminal will act under commands from the server (e.g. sent in the gameplay information data) to display options for the player according to the local and remote gameplay data received by the server. Thus, depending on what has been dealt to a player (detected on the blackjack table by the camera) the server may instruct the terminal application to present suitable options to the player, e.g. options such as HIT, STAND, DOUBLE or SPLIT may appear at the bottom of the screen for selection by the player.

Another option may be INSURANCE, e.g. if the dealer has a card of value ten showing. In this case, the dealer's ten card may be highlighted (e.g. may pop up or be illuminated) on the GUI. This will draw the player's attention to this. Insurance may be offered to all players before normal play resumes. At the terminal during the terminal player' s turn, the content may be arranged to provide a viewpoint of the game in which the player' s cards take up a large part of the screen when playing. After the player's turn the viewpoint may become more neutral, e.g. their cards may shrink back down to the position they are playing at. In this arrangement the full table is visible with the player's hand and the live players' hands in the correct relative positions.

A screen similar to Fig. 4 (albeit without player specific credit details) may be displayed on the playing surface display unit.

In this embodiment, each remote player has a seven second maximum decision time per card. The value of the timeout time may be configurable, e.g. pulled from an . ini file stored on the database server. If no decision has been made in this time the application may be arranged to automatically record a STAND decision.

Where there is more than one remote terminal playing the same hand, the display may show the statistics of how the other remote players are playing the hand. Table 2 shows schematically what the display may look like.

Stood on 13 3 players

Table 2 : Remote player hand status

The following steps illustrate typical gameplay for a player at a remote terminal: i. Remote player places stake chips on place bets region 200 of computer generated table. ii. Player's first card appears in gameplay region 202 on the screen. iii. Other player's cards and dealer's card appears on their respective gameplay regions 214, 204 on the screen, iv. Second card is dealt and appears in all positions including dealer. v. Remote player opts to hit, stand, split, double or take insurance and plays out hand. vi . The screen may continue to show additional cards after the remote player stands if other remote players are playing the same hand and continue to hit. vii . Cards received by other players during their turns are displayed in their respective gameplay regions . viii. The dealer's hand and subsequent cards are displayed in the dealer's gameplay region 204. ix. Game outcome is determined and displayed on terminal and player's credit adjusted accordingly.

The optical recognition apparatus used in the embodiment may serve a reporting function in addition to its role as gameplay facilitator. For example, the camera may be able to record and report information relating to dealer activity, live player activity, result statistics and the like.

As mentioned above, the remote players may be able to select a position at the live table to play from. All the position may be taken by remote players. In one embodiment, the player may select between seven or more positions. Each position may be taken by only one player (live or remote) . Thus, when a player selects a position it is reserved for him until he exits the game. The reserved position may be shown greyed out on the other terminals .

Appendix: Blackjack game rules

For the sake of clarity, the rules of casino blackjack considered herein are as follows:

1. Cards of rank 2 through 10 are scored according to their face value. All picture cards are 10 points.

2. Aces can be worth 1 or 11 points.

3. The highest hand in blackjack is an ace and any 10-point card and is called a blackjack.

4. A winning blackjack pays 3:2. 5. If both player and dealer have a blackjack the bet is a push.

6. Aside from a blackjack, a winning hand pays even money.

7. The player wins if his hand has more points than the dealer, without going over 21. 21 is the highest score. 8. If either the player or dealer go over 21 it is called a bust and a busted hand automatically loses .

9. If both the player and the dealer bust the player loses (this is the house edge) .

10. If the player and the dealer tie, the bet is a push.

11. A round of blackjack begins with each player placing a bet in the circle or logo directly in front of him.

12. Then the dealer will give each player and himself two cards. Player cards are usually dealt face up.

13. One dealer card is dealt face up (the up card) and the other face down (the hole card) . 14. In the event the dealer has an ace as the up card he will allow the players to insure their hands against a blackjack 15. The insurance bet in blackjack pays 2:1 if the dealer has a blackjack. 16. After all players have had a chance to accept or decline insurance the dealer will check the hole card.

17. After it has been established that the dealer does not have a blackjack the players in turn may play their hands.

18. If the player is satisfied with his hand as-is he may STAND.

19. If the player wishes to take another card (HIT) he may continue to do so until he either stands or busts.

20. If the player feels he needs one and only one more card then he may double his bet (DOUBLE) and be dealt one more card, good or bad. This option is only offered on the first two cards, and on the first two cards after splitting. 21. If the player's first two cards are of equal point value he may split them into two hands (SPLIT) . a. In this event each card is the first card of a new hand, b. The player must also make another wager, of equal value to the first wager, for the second hand. c. Splitting after splitting is allowed; The player can split up to 2 or 3 times if another splitting opportunity arises, d. Doubling after splitting is usually but not always allowed. 22. After all players have played their hands, from the dealer's left to right, the dealer will play his hand.

23. The dealer has no free will, he must always play by house rules. These are the dealer must hit until he reaches a score of 17.

24. (Optional) If the dealer has a soft 17, i.e. an ace and any number of cards totalling 6, he must also hit.

25. If the dealer busts, all players that did not bust automatically win.

26. (Optional) The player may surrender on the first two cards. If the player does not like his prospects he may forfeit half the bet as well as his cards. This option is offered after the dealer checks for blackjack, known as "late surrender."

Claims

1 A networked gaming apparatus comprising: a server communicably connected to at least one participating remote player terminal, each participating remote player terminal having a display unit and an instruction input unit and being arranged to communicate remote gameplay data to the server based on instructions received at the instruction input unit; a playing surface for hosting gameplay; a display unit associated with the playing surface; a sensor device communicably connected to the server and arranged to sense gameplay at the playing surface, generate live gameplay data and communicate the live gameplay data to the server; and processing means arranged to execute software instructions to generate a gameplay information display based on the live gameplay data and remote gameplay data received at the server, and cause the generated gameplay information display to be displayed on the display unit of each participating remote player terminal and the playing surface display unit .

2 A networked gaming apparatus according to claim 1, characterised in that the processing means may include a processor in the server.

3 A networked gaming apparatus according to claim 2, characterised in that the processor is arranged to execute an application for determining an outcome of each game based on the remote gameplay data and the live gameplay data and including the outcome in the generated gameplay information display. 4 A networked gaining apparatus according to claim 2 or claim 3 characterised in that the server' s processor may be arranged to communicate the generated gameplay information display to the display unit of each participating remote player terminal and the playing surface display unit for display thereon during gameplay.

5 A networked gaming apparatus according to claim 1 characterised in that the server may be arranged to combine the received live gameplay data and remote gameplay data into a format suitable for processing by a processor at each participating remote player terminal (or the display unit associated with the playing surface) .

6 A networked gaming apparatus according to claim 5 characterised in that the processing means is distributed across the networked gaming apparatus and the gameplay information display is generated at each participating remote player terminal or at the playing surface display unit .

7 A networked gaming apparatus according to any or claims 1 to 6 characterised in that the gameplay information display is customised at each display.

8 A networked gaming apparatus according to claim 7 characterised in that the viewpoint of the gameplay information display on a terminal display is centred on the gameplay region associated with that terminal and the gameplay information display on the playing surface display shows either a neutral viewpoint or the dealer' s viewpoint . 9 A networked gaming apparatus according to any of claims 1 to 8 characterised in that the playing surface comprises a table having gameplay regions associated with each participant (e.g. dealer, live (at-table) player and remote player) .

10 A networked gaming apparatus according to claim 9 characterised in that the table may be a card table and the regions may be areas on the table allocated to receive the cards which make up a player's hand.

11 A networked gaming apparatus according to claim 9 characterised in that the sensor device comprises optical recognition apparatus arranged to capture images of the playing surface and to generate the live gameplay data based on those captured images.

12 A networked gaming apparatus according to claim 11 characterised in that the optical recognition apparatus is arranged to capture an image of the gameplay regions and interpret the captured image to determine the live gameplay data.

13 A networked gaming apparatus according to claim 12 characterised in that the optical recognition apparatus is arranged to recognise one or more cards dealt into a gameplay region.

14 A networked gaming apparatus according to claim 13 characterised in that the live gameplay data comprises an identification of the card (e.g. suit and value) and position (e.g. gameplay region) in which it appears.

15 A networked gaining apparatus according to claim 11 characterised in that the optical recognition apparatus comprises for each gameplay region a camera for capturing images of the playing surface.

16 A networked gaming apparatus according to claim 11 characterised in that the optical recognition apparatus comprises a single camera overlooking the whole playing surface.

17 A networked gaming apparatus according to any of claims 1 to 16 characterised in that communications to and from the server are via the Extensible Messaging and Presence Protocol (XMPP) .

18 A networked gaming apparatus according to claim 17 characterised in that an XMPP server is provided as a communications interface between the server and each participating remote player terminal, optical recognition apparatus or playing surface display unit.

19 A networked gaming apparatus according to any previous claim characterised in that it further includes a dealer display communicably connected to the server and arranged to display dealer instructions from each participating remote player terminal, wherein the dealer instructions are based on the remote gameplay data received by the server. 20 A networked gaining apparatus according to claim 19 characterised in that the server may generate the dealer instructions .

21 A networked gaming apparatus according to any previous claim, characterised in that it further comprises a database arranged to store the remote gameplay data and live gameplay data received at the server, the server being connected to the database to enable the progress of games to be recorded and to provide an audit trail.

22 A networked gaming apparatus according to claim 21 characterised in that the database stores game configuration data to enable a game to be customised for a particular location.

23 A networked gaining apparatus according to any- previous claim, characterised in that it further comprises one or more non-participating terminals, the or each non-participating terminal comprising a display- unit, the processing means causing the generated gameplay information display also to be displayed on the display unit of the or each non-participating terminal.