US20090117995A1

Movatterモバイル変換

Info

Publication number: US20090117995A1
Application number: US12/134,124
Authority: US
Inventors: Martin Stephen Lyons; Robert Linley Muir
Original assignee: Aristocrat Technologies Australia Pty Ltd
Current assignee: Aristocrat Technologies Australia Pty Ltd
Priority date: 2007-06-07
Filing date: 2008-06-05
Publication date: 2009-05-07
Also published as: AU2008202090A1; EP2000995A3; AU2011202440A1; EP2000995A2; AU2011202440B2

Abstract

A gaming system for multiple players using horizontal touch screen displays. A credit input/output mechanism receives currency or a trading device, and may include an input amount. A credit record is generated as well as an associated unique credit identifier. Credits specified by the credit record may be allocated relative to a player interface in accordance with input to a touch screen display.

Description

RELATED APPLICATIONS

This application claims priority to Australian Provisional Patent Application No. 2007903070, having an international filing date of Jun. 7, 2007, entitled “Method of Credit Input and a Gaming System,” which is hereby incorporated by reference herein in its entirety.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[Not Applicable]

MICROFICHE/COPYRIGHT REFERENCE

[Not Applicable]

BACKGROUND OF THE INVENTION

The present invention relates to a method of credit input and a gaming system. Traditionally, electronic gaming machines have taken the form of slot machines where a player plays a game involving reels that spin and prizes are awarded based on the position at which the reels stop relative to win lines selected by the player. Originally, these machines were mechanical with physically rotating reels. In many modern slot machines, the mechanical reels have been replaced by “virtual reels displayed as spinning on a video display.

More recently, there has been a move towards implementing other types of games such as table games including poker, blackjack or roulette on electronic gaming machines including as multi-player games. Motivations for doing so include that less staff may be required and games can be played more quickly when a human dealer or croupier is replaced by a gaming machine.

As such games are developed, there is a need to provide a credit input technique which suits these game types.

BRIEF SUMMARY OF THE INVENTION

In a first aspect, the invention provides a method of credit input for a multi-player gaming system, the method comprising:

- receiving a credit input;
- generating a credit record associated with a gaming system including data indicative of the credit input; and
- associating a credit identifier with the credit record.

In an embodiment, the method further comprises receiving the credit identifier from a player interface of the gaming system; and allocating the credit specified by the credit record to the player interface.

In an embodiment, the method further comprises issuing the credit identifier.

In an embodiment, the method further comprises associating a player provided credit identifier with the credit record.

In an embodiment, the method further comprises displaying one or more tokens corresponding to the credit record on a display of the multi-player gaming system.

In an embodiment, the method comprises issuing a request for the credit identifier in response to an attempt to allocate the one or more tokens with a player interface.

In an embodiment, the method comprises monitoring for an attempt to allocate one or more tokens with a player interface by monitoring for an attempt to move the one or more tokens to within the player interface.

In an embodiment, an attempt to allocate one or more tokens with a player interface comprises an attempt to move the one or more tokens to a designated part of the player interface.

In an embodiment, the display is a touch screen display and the method comprises monitoring the output of the touch screen for an attempt to move the one or more tokens.

In an embodiment, receiving a credit input comprises receiving a ticket having a credit value.

In an embodiment, receiving a credit input comprises obtaining credit from a player account.

In an embodiment, the player account is linked to a player tracking device.

In an embodiment, receiving a credit input comprises receiving a currency input.

In a second aspect, the invention provides a multi-player gaming system comprising:

- a credit input mechanism; and
- a credit manager arranged to:
  - generate a credit record including data indicative of the credit input; and
  - associate a credit identifier with the credit record.

In an embodiment, the credit manager is further arranged to:

- receive the credit identifier from a player interface of the gaming system; and
- allocate the credit specified by the credit record to the player interface.

In an embodiment, the gaming system comprises a player interface controller adapted to provide a plurality of player interfaces.

In an embodiment, the credit manager is adapted to issue a request for the credit identifier in response to an attempt to allocate the credit record to a player interface.

In an embodiment, the gaming system comprises a touch screen display and the player interface controller is adapted to provide at least part of each player interface on with the touch screen display.

In an embodiment, the credit manager is arranged to cause the display to initially display one or more tokens corresponding to the credit record at a position separate to each player interface.

In an embodiment, the touch screen is operable to allow a player to move the one or more tokens from the initial display position to a player interface to attempt to allocate the credit record.

In an embodiment, each player interface is operable to enter a credit identifier.

In an embodiment, the player interface controller is adapted to add and remove player interfaces.

In an embodiment, the credit input mechanism comprises a bill acceptor.

In an embodiment, the credit input mechanism comprises a coin acceptor.

In an embodiment, the credit input mechanism comprises a ticket reader.

In an embodiment, the credit input mechanism is adapted to obtain a credit amount from a player account.

In an embodiment, the display is a horizontal display.

In an embodiment, the display is 2-3 m across the diagonal.

In a third aspect, the invention provides a credit manager for a multi-player gaming system arranged to:

- process a credit input;
- generate a credit record based on the credit input; and
- associate a credit identifier with the credit record.

In an embodiment, the credit manager is further adapted to issue a request for the credit identifier in response to an attempt to allocate the credit record to a player interface of the gaming system.

In an embodiment, the credit manager is arranged to cause a display of the gaming system to initially display one or more tokens corresponding to the credit record at a position separate to the player interface.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

An embodiment incorporating all aspects of the invention will now be described in relation to the accompanying drawings in which:

FIG. 1 is a plan view of a gaming table of an embodiment;

FIG. 2 is a functional block diagram of a gaming system on an embodiment;

FIG. 3 is a further block diagram showing a credit manager in more detail;

FIG. 4 is a schematic diagram showing a networked embodiment;

FIG. 5 is a schematic diagram of a player interface;

FIG. 6 is a schematic diagram of a player interface where a player enters a code;

FIG. 7 is a schematic diagram of a player interface updated after tokens have been assigned to a player; and

FIG. 8 is a flowchart showing a method of the embodiment.

DETAILED DESCRIPTION OF THE INVENTION

Referring to the drawings, there is shown a gaming system arranged to handle credit input in respect of a multi-player game. The gaming system is preferably implemented as a virtual gaming table, where a horizontally oriented touch screen display is used by players to participate in a game. The gaming system can take a number of different forms.

In a first form, a stand alone gaming table is provided wherein all or most components required for implementing the game are present or located next to a player operable virtual gaming table.

In a second form, a distributed architecture is provided wherein some of the components required for implementing the game are present located with the gaming table and some of the components are located remotely. For example, a “thick client” architecture may be used wherein part of the game is executed locally by the player operable gaming table and part of the game is executed remotely, such as by a gaming server; or a “thin client” architecture may be used wherein most of the game is executed remotely such as by a gaming server and a player operable gaming table is used only to display audible and/or visible gaming information to the player and receive gaming inputs from the player.

However, it will be understood that other arrangements are envisaged. For example, an architecture may be provided wherein a gaming table is networked to a gaming server and the respective functions of the gaming table and the gaming server are selectively modifiable. For example, the gaming system may operate in stand alone gaming table mode, “thick client” mode or “thin client” mode depending on the game being played, operating conditions, and so on. Other variations will be apparent to persons skilled in the art.

FIG. 1 is a plan view of a virtual gaming table100 having a horizontally oriented display120 and a log onterminal140. As can been fromFIG. 1, the gaming table is surrounded by seven chairs130 indicating seven possible player positions. Two player interfaces124a,124bare active on the display120. Acentral area122 of the display is used to display information common to all players; in the example shown inFIG. 1 a display of a roulette game.

As shown inFIG. 2, from a functional perspective, a virtual table200 comprises agame controller220, acommon display212 and a variable number of player interfaces210. As described in detail below, in the embodiment the number of player interfaces depends on the number of players playing the game. In some embodiments there may be a single player interface for each player so that each time a player enters the game an interface is added. In other embodiments, a minimum number of player interfaces may always be displayed even though it is possible they are not all being used and additional player interfaces added as necessary, when the minimum is exceeded. Unused interfaces may function in an attract mode. In further embodiments, a player may request an additional player interface. For example, some players may wish to play two hands of cards simultaneously where the gaming table implements a card game.

In the embodiment, a number of the functional modules of the game controller are implemented by aprocessor215. However, a person skilled in the art will appreciate that other techniques such dedicated hardware could be used instead of program code running on aprocessor215 to implement the required functions.

The game controller'sprocessor215 processes the game play instructions in accordance with game play rules and outputs game play outcomes to the display. Typically, the game play instructions are stored as program code in amemory270. Herein the term “processor” is used to refer generically to any device that can process game play instructions in accordance with game play rules and may include: a microprocessor, microcontroller, programmable logic device or other computational device, a general purpose computer (e.g. a PC) or a server.

These functions are carried out based on data such ascredit data272 andgame rule data274 stored in amemory270 of thegame controller220. Thegame controller220 has a number of modules including adisplay controller230 for controlling what is displayed both in thecommon display area212 of a gaming table212 and on each of the player interfaces210.

The display120 incorporates a touch screen. Herein such a display is referred to as “touch screen display”. Accordingly, it will be appreciated that the player interfaces share a common display120. A person skilled in the art will appreciate that the “touch screen” sensor need not cover the entire display. For examplecentral area122 as shown inFIG. 1 need not necessarily have a touch screen capability. The touch screen is preferably a multi-touch screen capable of processing simultaneous or near simultaneous instructions from a number of different players. The display120 itself is typically a wide screen, large format display such as a plasma or LCD display of a size in the order of 80-120 inches (2 m-3 m) across the diagonal. However, a person skilled in the art will appreciate that the display could be formed a plurality of sub-units located adjacent to one another under the control of thedisplay controller230 to display both the player interfaces210 and thecommon display area212.

Thedisplay controller230 controls the display to display the individual player interfaces based on data provided by theinterface controller240 and theoutcome determiner260. The interface controller also provides data to thetouch screen processor250 to enable it to interpret touches on the touch screen display, for example, in order to associate them with individual player interfaces210 and to provide this data to theoutcome determiner260. In this manner, individual player instructions can be correctly provided to theoutcome determiner260 so that the outcome determiner266 can determine the result of the game based on thegame rule data274. Similarly, theoutcome determiner260 provides data to thedisplay controller230 regarding the game outcomes for individual players. This may be displayed in a display region of the player interface210 on the common display or both.

A person skilled in the art will appreciate that depending on the game, theoutcome determiner260 may determine independent results for each player such as in a game like roulette or results that depend on the game play of other players such as in a competitive game like poker.Credit data272 is maintained separately for each player interface inmemory270. The log-on terminal280 typically includes a touch screen display allowing a player to enter their name and assign to themselves a player position number—i.e. a particular player interface. Alternatively the player position maybe assigned by the game system. In alternative embodiments, players may be assigned positions anonymously by providing them with a temporary access code, printed by the log-on terminal on a voucher. In still further embodiments, the player is given an entitlement to a player interface by the log-on process and the player interface is allocated or generated based on where the player sits relative to the table.

To participate in the game a player uses the log-on terminal280 to request a player interface for the game either manually, or by swiping or otherwise providing a player tracking device to the log onterminal280. That is, depending on the embodiment the log on terminal may read magnetic cards, smart cards, RFID tags or another suitable data carrier.

The player may also use the log-on terminal to log out of the game or alternatively may operate the player interface to log out of the game.

At least one credit input/output mechanism290 is provided which can be shared by all players of the gaming system.

In one embodiment, the credit input/output mechanism includes avoucher printer295. A player provides credit to the credit input/output290 by inserting currency using abill291 orcoin292 acceptor or by providing their player trading device to thereader294 and specifying an amount, e.g. by use of akeypad296, to be retrieved from an account associated with the trading device which may be stored on aplayer account server412 such as is shown inFIG. 4.Credit manager300 processes data received from the credit record and the credit creates a record incredit data272 specifying the amount of input credits and associates a credit identifier with the credit record, typically by generating a unique credit identifier. A voucher is printed by avoucher printer295. The voucher has the credit identifier on it so that the player can enter it at a player interface210 using a virtual key pad. Thecredit manager controller220 processes the input credit identifier and verifies it against records stored ascredit data272. If the credit identifier is verified, the amount of credit is associated with the player interface used to enter the credit identifier. In this respect, a credit balance is maintained within the credit data for each player interface. Thus, the credit is transferred to the credit balance for the player interface. Once the player interface has been allocated the credit, tokens corresponding to the credit will be present within the player's player interface210.

To this end, thecredit manager300 has a number of modules including acredit record generator310 which generates a credit record corresponding to the amount of input credit, acredit identifier issuer320 which issues credit identifiers in accordance with predetermined rules, for example, it may generate the identifier randomly or from a set of identifiers. Both thecredit record generator310 and thecredit identifier issuer320 are adapted to communicate data to thecredit data272 of the memory.

Thecredit manager300 also includes anidentifier requester330 adapted to request that a player enter an identifier and cause the display controller to display this request on one of the player interfaces210 in response to an attempt by a player to allocate the credit to their player interface.

A credit identifier processor andcredit allocator340 processes input requests and if the credit identifier is correct updates thecredit data272 such that a credit meter associated with the player interface includes the credit balance of the relevant credit record.

The most common, example of a gaming “token” is a chip. However, other tokens such as coins or the like may be employed.

With reference toFIG. 2, the interface controller provides to the display controller, data stored as interface data273 which specifies which parts of the player interface are assigned to the different areas of theplayer interface500, which has achip stack area510, abet manipulation area520 and abet commitment area530 so that these areas are displayed to a player.Token data275 specifies the number of tokens associated with a player interface and their current locations within theplayer interface500. Thetouch screen processor250 determines when a player touches the screens and employs the token data to determine which token or tokens the player has touched. In an exemplary embodiment, a player moves a token by touching the touch screen in the vicinity of token and dragging their finger across the screen to a new position. When the player releases or removes their finger from the touch screen the movement is completed.

In an alternative mode of control, thetouch screen processor250 is configured to detect the speed at which a player moves their hand relative to the screen such that a player can “flick” a token by rapidly moving their finger in a direction they wish the chip to go to impart a vector velocity to the chip. Thetouch screen processor250.

Thetouch screen processor250, implementsmanipulation rules276 in respect of a player's touching of the tokens. In the embodiment, after a new credit record is created by the credit manager, thecredit manager300 causes thedisplay controller230 to display in a newtoken display area213 of thecommon display212, tokens corresponding to the amount of credit in the credit records. A player reaches over to the newtoken display area213 on thecommon display212, touches the tokens in thenew display area213 and drags them towards their player interface area. When the tokens are released by the player within the player'sinterface area500 or within a specific sub-area, such as thebet manipulation area520 or thechip stack area510, the touch screen processor advises thecredit manager300 that a player has attempted to allocate the tokens to their player interface. Theidentifier requester330 causes the display controller230 a virtual keypad620 as shown inFIG. 6 and a request for a player to “enter code”625 to thereby request that the player submit the credit identifier that they received previously. If the correct credit identifier is entered as described above, the credit amount, in the example shown inFIG. 7, 575 units of chips are added to the player'schip stack area510 in this case in a pile of five 100unit chips712, and three 25 unit chips714. The player's total of chips is also updated722.

Accordingly there is implemented amethod800 where a credit input is received810, a credit record is generated820, a credit identifier is associated with acredit record830. Tokens corresponding to the credit record are displayed835. The touch screen is monitored for an attempt to allocate the tokens to aplayer interface840. If a user attempts to allocate the tokens to themselves the user is prompted for acredit identifier850. Atstep860 the method involves receiving and processing the credit identifier and if the identifier is correct atstep870 the method involves allocating the credit record to the credit meter of theplayer interface870.

Various further features or modifications will be apparent to persons skilled in the art. For example, the code will typically be in a string of alphanumerical characters, for example a number or word or mixture of the two. Further an alternative to issuing an identifier to a player is to allow a player to choose their own code. Where the player has a player tracking device with a code associated therewith, this may be a code previously associated with the tracking device for the player or alternatively a short password may be generated for the player that the player appends to their normal code.

Further, where the virtual table is networked, the terminal may contact thecasino management system412 and pass the transaction record to it. In this embodiment, transaction records are subsequently retrieved over the network when the player approaches the game.

Further, whileFIG. 2, shows the credit manager and credit data being common functional components of the gaming system. A credit input mechanism may be provided as a money terminal and be physically separate or may be provided as part of the log-on terminal140 shown inFIG. 1. In this case, an initial credit record may be established within the money terminal and the virtual table contacts the money terminal to obtain a transaction record stored in memory matching the entered credit identifier. If such a record exists, the associated money amount is credited to the gaming machine and the transaction record is marked as used within the terminal. It will be appreciated that in this example, the credit manager function is provided in combination by the virtual table and the money terminal.

A person skilled in the art will also appreciate that the player will wish to cash out or takes his credits elsewhere at the end of a gaming session. In an embodiment, each player interface is provided with a button or touch screen marked “End Session”. Pressing this action causes the gaming machine to create a new credit record and either generates a credit identifier, uses a credit identifier that was previously input by the player, or generates a short password such as a three digit number and appends it to the password previously input by the player or similar technique. The gaming machine associates the credit record with the credit identifier and the credits are associated with the credit record. If a new password has been generated or a short password has been generated this is displayed to the player. The player must memorise or write down the new password. The transaction record may also be transferred to the casino management system or the money terminal. The credit meter is reset to zero for the player interface and the player can leave the gaming machine. The player then approaches the credit mechanism and, depending upon implementation, the player either inserts the ticket he obtained from the money terminal originally, types in the password or types in the password followed by the short password. This is processed by the money terminal to locate the transaction records. The terminal obtains the credit records and provides a payout to the player.

In the case where multiple money terminals exist, it is desirable to have a casino management system in order to create unique credit records for each credit input or output. However this is not strictly necessarily provided each credit manager function is arranged to issue unique credit records.

Further, if a player associates their player tracking device with the original transaction, this information can be carried along with every subsequent transaction such that when a player needs to cash out, they only need to reinsert or otherwise associate their player tracking device with a payout terminal to obtain their money. Various techniques can be used to improve the security of the passwords, for example passwords can be time limited and once the time runs out the ticket would need to reinserted to the terminal140 to generate a new ticket or password. This would cut down the number of active passwords at any one time. Further, the gaming table can be arranged to alert an operator or security staff if a large number of incorrect passwords attempts are made.

The above embodiment has been described in relation to a virtual gaming table where players share a display to provide a plurality of player interfaces. Persons skilled in the art will appreciate that the same technique can be applied in any situation whether a plurality of player interfaces such as may be provided by a plurality of stand alone electronic gaming machines, share a common credit input mechanism.

In some embodiments, tokens corresponding to new credit records may be displayed at a plurality of locations to make it convenient for a player to reach the virtual tokens. In other embodiments, a notification may be provided on each player interface that there is a new credit record. In other embodiments, a newly added player interface or a dormant interface may revert to a view such as shown in FIG.6—i.e. default to a credit identifier entry mode.

FIG. 4 shows agaming system400 in accordance with an alternative embodiment. Thegaming system400 includes anetwork401, which for example may be an Ethernet network. Gaming tables403, are connected to thenetwork401. The gaming tables202 provide a player operable interface for thegaming system400.

One ormore displays404 may also be connected to thenetwork401. Thedisplays404 may, for example, be associated with one or more gaming tables203. Thedisplays404 may be used to display representations associated with game play on the gaming tables402, and/or used to display other representations, for example promotional or informational material.

In a thick client embodiment,game server405 implements part of the game played by a players using a gaming table403 and the gaming table403 implements part of the game. With this embodiment, as both the game server and the gaming device implement part of the game, they collectively provide a game controller. Adatabase management server406 may manage storage of game programs and associated data for downloading or access by the gaming devices402 in adatabase406A. Typically, if the gaming system enables players to participate in a Jackpot game, aJackpot server407 will be provided to monitor and carry out the Jackpot game.

In a thin client embodiment (or networked gaming embodiment),game server405 implements most or all of the game played by a player using a gaming table403 and the gaming table403 essentially provides only the player interface. With this embodiment, thegame server405 provides the game controller. The gaming table403 will receive player instructions, pass these to thegame server405 which will process them and return game play outcomes to the gaming table403 for display.

Player accounts may be maintained byplayer account server412 which stores an account including a credit balance for player's having a player tracking device as well as other data such as loyalty data for a loyalty program. A player accesses their account by presenting their player tracking device to the credit input/output mechanism290 of the virtual gaming table403.

Servers are also typically provided to assist in the administration of thegaming network400, including for example a gamingfloor management server408, and alicensing server409 to monitor the use of licenses relating to particular games. Anadministrator terminal410 is provided to allow an administrator to run thenetwork401 and the devices connected to the network.

Thegaming network400 may communicate with other gaming systems, other local networks, for example a corporate network, and/or a wide area network such as the Internet, for example through afirewall411.

Persons skilled in the art will appreciate that in accordance with known techniques, functionality at the server side of the network may be distributed over a plurality of different computers. For example, elements may be run as a single “engine” on one server or a separate server may be provided. For example, thegame server405 could run a random generator engine. Alternatively, a separate random number generator server could be provided. Further, persons skilled in the art will appreciate that a plurality of games servers could be provided to run different games or a single game server may run a plurality of different games as required by the tables403.

Further variations will be apparent to persons skilled in the art and should be understood as falling within the scope of the invention described herein. In particular, it will be apparent to persons skilled in the art that specific features of the above embodiments could be combined to form further embodiments.

In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word “comprise” or variations such as “comprises” or “comprising” is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention.

It is to be understood that the reference to prior art herein does not constitute an admission that the prior art forms a part of the common general knowledge in the art in any country.