WO2008152412A1 - Appareil de jeu en réseau - Google Patents

Appareil de jeu en réseau Download PDF

Info

Publication number
WO2008152412A1
WO2008152412A1 PCT/GB2008/002063 GB2008002063W WO2008152412A1 WO 2008152412 A1 WO2008152412 A1 WO 2008152412A1 GB 2008002063 W GB2008002063 W GB 2008002063W WO 2008152412 A1 WO2008152412 A1 WO 2008152412A1
Authority
WO
WIPO (PCT)
Prior art keywords
gameplay
server
dealer
remote
gaming apparatus
Prior art date
Application number
PCT/GB2008/002063
Other languages
English (en)
Inventor
Vincent Leonard
Original Assignee
Inspired Gaming (Uk) Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inspired Gaming (Uk) Limited filed Critical Inspired Gaming (Uk) Limited
Publication of WO2008152412A1 publication Critical patent/WO2008152412A1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements

Definitions

  • 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.
  • 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.
  • 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.
  • the terminals are used to place bets and are therefore equipped with means to generate payment of either cash, vouchers or tokens.
  • 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.
  • a live game e.g. casino game
  • 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.
  • 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.
  • the invention may provide networked gaming apparatus capable of scanning and identifying elements of gameplay e.g. playing cards rapidly and with minimal error.
  • 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.
  • 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.
  • a computer generated display 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.
  • 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.
  • RFID radio frequency identification
  • 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.
  • 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.
  • 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.
  • the viewpoint of the gameplay information display on a terminal display may be centred on the gameplay region associated with that terminal.
  • 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.
  • 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.
  • 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.
  • communications to and from the server are via the Extensible Messaging and Presence Protocol (XMPP) .
  • XMPP Extensible Messaging and Presence Protocol
  • 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.
  • 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
  • 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.
  • the blackjack game is played at a table that is arranged to receive local (at-table) players, who participate in the game as normal.
  • at least one gameplay region i.e. dealing position
  • 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.
  • 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) .
  • RFID Radio frequency identification
  • the RFID chip 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.
  • 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.
  • Optical recognition apparatus may be provided at the playing surface.
  • 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.
  • XML Extensible Markup Language
  • 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) .
  • 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.
  • 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.
  • 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.
  • TITO ticket-in, ticket-out
  • the server 112 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.
  • 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.
  • 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.
  • 102 may run a table player display application 128, which communicates with the card server 121 via the XMPP server
  • 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.
  • 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.
  • 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.
  • each player in turn may be presented with one or more options e.g. ⁇ hit', ⁇ stand', ⁇ double' , ⁇ split' or ⁇ take insurance' .
  • options may all be presented in a second game state, e.g. under the general banner ⁇ make a play' .
  • 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.
  • 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 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.
  • a hand where there are nine remote players playing the same position at the blackjack table may play out as follows:
  • 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.
  • 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.
  • 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 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.
  • the gameplay information display data can be corrected.
  • This may be done via the dealer console.
  • 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.
  • the option to save or cancel is given.
  • 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.
  • a consistent strategy e.g. a basic strategy such as x hit until 17'
  • 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.
  • GUI Graphical User Interface
  • 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.
  • 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.
  • 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) .
  • the terminal is also arranged to collect remote gameplay data from the player via the GUI to send to the server.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 may be displayed on the playing surface display unit.
  • 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.
  • 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.
  • 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.
  • the camera may be able to record and report information relating to dealer activity, live player activity, result statistics and the like.
  • 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 .
  • Cards of rank 2 through 10 are scored according to their face value. All picture cards are 10 points.
  • Aces can be worth 1 or 11 points.
  • the highest hand in blackjack is an ace and any 10-point card and is called a blackjack.
  • a winning blackjack pays 3:2. 5. If both player and dealer have a blackjack the bet is a push.
  • the bet is a push.
  • a round of blackjack begins with each player placing a bet in the circle or logo directly in front of him.
  • 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.
  • 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.
  • 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.”

Abstract

La présente invention développe la fonctionnalité d'un appareil de jeu en réseau existant en offrant la possibilité à des joueurs qui ne sont pas assis à une table de jeux (101) de participer à la partie de façon interactive sur des terminaux (114) à une partie en direct recevant également des participants locaux “en jeu”. Des informations et des instructions sont distribuées à proximité de l'appareil de sorte que ni les participants à la table ni les participants à distance n'ont un avantage sans pour autant causer de retards de jeu inutiles.
PCT/GB2008/002063 2007-06-11 2008-06-09 Appareil de jeu en réseau WO2008152412A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0711237.8 2007-06-11
GB0711237A GB0711237D0 (en) 2007-06-11 2007-06-11 Networked gaming apparatus

Publications (1)

Publication Number Publication Date
WO2008152412A1 true WO2008152412A1 (fr) 2008-12-18

Family

ID=38319149

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2008/002063 WO2008152412A1 (fr) 2007-06-11 2008-06-09 Appareil de jeu en réseau

Country Status (2)

Country Link
GB (1) GB0711237D0 (fr)
WO (1) WO2008152412A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102035856A (zh) * 2010-12-31 2011-04-27 深圳瑞高信息技术有限公司 游戏社区的管理方法、游戏客户终端及其系统
US8088010B1 (en) 2010-07-01 2012-01-03 Otho Dale Hill Online gaming with real-world data
US8152641B2 (en) 2010-07-01 2012-04-10 Otho Dale Hill On line gaming with real-world data
CN103475918A (zh) * 2013-09-04 2013-12-25 深圳市同洲电子股份有限公司 一种自动控制移动终端传感器的方法及装置
WO2014071496A1 (fr) * 2012-11-06 2014-05-15 Garden City Software Corp. Procédé et système permettant de réaliser des paris interactifs hors-table sur des jeux
CN106411680A (zh) * 2015-07-29 2017-02-15 腾讯科技（深圳）有限公司 一种信息交互方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000040313A2 (fr) * 1999-01-07 2000-07-13 Yacob Rafaeli Systeme et procede de jeu de hasard pour joueurs delocalises
US20020147042A1 (en) * 2001-02-14 2002-10-10 Vt Tech Corp. System and method for detecting the result of a game of chance
GB2389540A (en) * 2002-05-30 2003-12-17 Prime Table Games Isle Of Man Game Playing Apparatus
US20070015583A1 (en) * 2005-05-19 2007-01-18 Louis Tran Remote gaming with live table games

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000040313A2 (fr) * 1999-01-07 2000-07-13 Yacob Rafaeli Systeme et procede de jeu de hasard pour joueurs delocalises
US20020147042A1 (en) * 2001-02-14 2002-10-10 Vt Tech Corp. System and method for detecting the result of a game of chance
GB2389540A (en) * 2002-05-30 2003-12-17 Prime Table Games Isle Of Man Game Playing Apparatus
US20070015583A1 (en) * 2005-05-19 2007-01-18 Louis Tran Remote gaming with live table games

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8088010B1 (en) 2010-07-01 2012-01-03 Otho Dale Hill Online gaming with real-world data
US8152641B2 (en) 2010-07-01 2012-04-10 Otho Dale Hill On line gaming with real-world data
CN102035856A (zh) * 2010-12-31 2011-04-27 深圳瑞高信息技术有限公司 游戏社区的管理方法、游戏客户终端及其系统
WO2014071496A1 (fr) * 2012-11-06 2014-05-15 Garden City Software Corp. Procédé et système permettant de réaliser des paris interactifs hors-table sur des jeux
CN103475918A (zh) * 2013-09-04 2013-12-25 深圳市同洲电子股份有限公司 一种自动控制移动终端传感器的方法及装置
CN106411680A (zh) * 2015-07-29 2017-02-15 腾讯科技（深圳）有限公司 一种信息交互方法及装置
CN106411680B (zh) * 2015-07-29 2020-02-28 腾讯科技（深圳）有限公司 一种信息交互方法及装置

Also Published As

Publication number Publication date
GB0711237D0 (en) 2007-07-18

Similar Documents

Publication Publication Date Title
US10460555B2 (en) Table game play using portable electronic devices
US10497207B2 (en) Remote live table gaming terminals and systems
US20200005585A1 (en) Gaming table system permitting play of a shared player hand by multiple players
US8357032B2 (en) Online blackjack tournaments with option to purchase card counting report
US8672735B2 (en) Land-based, on-line poker system
US20020198052A1 (en) Method, apparatus and article for hierarchical wagering
US20060058089A1 (en) Electronic card table and method with player tracking
US20180225928A1 (en) Computer-implemented texas hold'em poker variant
US20140024427A1 (en) Method and system for playing head to head poker games
KR102579793B1 (ko) 커뮤니티 핸드 웨이저링 게임을 제공하는 시스템 및 관련 방법
US11354972B2 (en) Electronic table game poker system and methods
US20150038206A1 (en) Methods of administering wagering games including trading cards and related systems
KR101893564B1 (ko) 라이브 바카라 테이블 게임에서의 내기 기회들
WO2008152412A1 (fr) Appareil de jeu en réseau
US10909815B2 (en) Method and apparatus for administering a token collecting game
CA2846108C (fr) Systeme et procede de jeu hybride
US20220005324A1 (en) Modified blackjack wagering game systems and methods
US10964171B1 (en) Blackjack and wagering gaming methods and systems
US20240046760A1 (en) Progressive poker jackpot system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08762387

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08762387

Country of ref document: EP

Kind code of ref document: A1