AU2011202440B2

AU2011202440B2 - Method of credit input and a gaming system

Info

Publication number: AU2011202440B2
Application number: AU2011202440A
Authority: AU
Inventors: Martin Lyons; Robert Muir
Original assignee: Aristocrat Technologies Australia Pty Ltd
Current assignee: Aristocrat Technologies Australia Pty Ltd
Priority date: 2007-06-07
Filing date: 2011-05-25
Publication date: 2013-10-24
Anticipated expiration: 2028-05-12
Also published as: EP2000995A3; US20090117995A1; AU2008202090A1; AU2011202440A1; EP2000995A2

Abstract

A method of credit input for a multi-player gaming system, the method comprising: receiving a credit input; 5 generating a credit record associated with a gaming system including data indicative of the credit input; associating a credit identifier with the credit record; issuing a voucher having the credit identifier printed thereon; receiving, via a keypad, the credit identifier; verifying 10 the credit identifier, received via the keypad, against the credit record; and in response to verifying the credit identifier, associating the data indicative of the credit input with the player interface. 2683301_ (GHMalters) P71729AU.2 25/05/11 Figure 1

Description

AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION Standard Patent Applicant: Aristocrat Technologies Australia Pty Limited Invention Title: METHOD OF CREDIT INPUT AND A GAMING SYSTEM The following statement is a full description of this invention, including the best method for performing it known to me/us: -2 Title METHOD OF CREDIT INPUT AND A GAMING SYSTEM 5 Related Application This application is a divisional application of Australian application no. 2008202090 the disclosure of which is incorporated herein by reference. 10 Field The present invention relates to a method of credit input and a gaming system. 15 Background to the Invention Traditionally, electronic gaming machines have taken the form of slot machines where a player plays a game 20 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 25 "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 30 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. 35 As such games are developed, there is a need to provide a credit input technique which suits these game types. 2683301_1 (GHMatters) P71729.AU 2 25/05/11 - 3 Summary of the Invention In a first aspect, the invention provides a method of credit input for a multi-player gaming system having a 5 display, a controller and a player interface associated with a keypad, the player interface having a first interface area operable to display tokens available to a player for wagering and a second interface area operable to display tokens wagered by the player and the display lo having a new token display area for displaying new tokens available to the player, the method comprising: receiving a credit input; generating, using the controller, a credit record associated with the gaming system including data is indicative of the credit input; displaying in the new token display area, one or more tokens indicative of the credit input; associating, using the controller, a credit identifier with the credit record; 20 issuing a voucher having the credit identifier printed thereon; receiving, via the player interface, an instruction to allocate the one or more tokens to the player, the instruction comprising a player moving the one 25 or more tokens from the new token display area to the first interface area; issuing a request for the credit identifier in response to receiving the instruction; receiving, via a keypad, the credit identifier; 30 verifying, using the controller, the credit identifier received via the keypad with respect to the credit record; displaying the one or more tokens in the first interface area, in response to verifying the credit 35 identifier; and monitoring a movement of at least one of the one or more displayed tokens from the first interface area to 2683301_3 (GH4auers) P71729.AU.2 23/09113 -4 the second interface indicative of the moved at least one of the one or more displayed tokens having been wagered. In an embodiment, the method further comprises associating 5 a player provided credit identifier with the credit record. In an embodiment, the display is a touch screen display and the method comprises monitoring the output of the 10 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. 15 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 20 tracking device. In an embodiment, receiving a credit input comprises receiving a currency input. 25 In a second aspect, the invention provides a multi-player gaming system comprising: a display; a credit input mechanism; a key pad; 30 a player interface; a voucher printer; and a credit manager, the player interface having a first interface area operable to display tokens available to a player for 35 wagering and a second interface area operable to display tokens wagered by the player and the display having a new token display area for displaying new tokens available to 26833013 (GHMaters) P71729.AU.2 23/09/13 -5 the player, the credit manager arranged to: generate a credit record including data indicative of credit input via the credit input mechanism; 5 cause the display to display one or more tokens indicative of the credit input in the new token display area; associate a credit identifier with the credit record; 10 issue a voucher having the credit identifier printed thereon via the voucher printer; issue a request for the credit identifier, in response to an instruction to allocate the one or more tokens, the instruction comprising a player moving the one is or more tokens from the new token display area to the first interface area, receive, via the keypad, the credit identifier; and verify the credit identifier, received via 20 the keypad, against the credit record, whereafter the gaming system displays the one or more tokens in the first interface area; and monitors a movement of at least one of the one or more displayed tokens from the first interface area to the 25 second interface indicative of the moved at least one of the one or more displayed tokens having been wagered. In an embodiment, the gaming system comprises a player interface controller adapted to provide a plurality of 30 player interfaces. 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 35 on with the touch screen display. In an embodiment, the player interface controller is 26833013 (OHMaUrs) P71729.AU.2 23/09/13 -6 adapted to add and remove player interfaces. In an embodiment, the credit input mechanism comprises a bill acceptor. 5 In an embodiment, the credit input mechanism comprises a coin acceptor. In an embodiment, the credit input mechanism comprises a 10 ticket reader. In an embodiment, the credit input mechanism is adapted to obtain a credit amount from a player account. 15 In an embodiment, the display is a horizontal display. In an embodiment, the display is 2-3m across the diagonal. Brief Description of the Drawings 20 An embodiment incorporating all aspects of the invention will now be described in relation to the accompanying drawings in which: 25 Figure 1 is a plan view of a gaming table of an embodiment; Figure 2 is a functional block diagram of a gaming system on an embodiment; 30 Figure 3 is a further block diagram showing a credit manager in more detail; Figure 4 is a schematic diagram showing a networked 35 embodiment; Figure 5 is a schematic diagram of a player interface; 26833013 (GNM&aers) P71729.AU.2 23/09/13 7 Figure 6 is a schematic diagram of a player interface where a player enters a code; 5 Figure 7 is a schematic diagram of a player interface updated after tokens have been assigned to a player; and Figure 8 is a flowchart showing a method of the embodiment. 10 Detailed Description Referring to the drawings, there is shown a gaming system arranged to handle credit input in respect of a multi 15 player game. The gaming system is preferably implemented as a virtual gaming table, where a horizontally oriented 26833013 (OHMattrs) P71729.AU.2 23/09/13 -8 touch screen display is used by players to participate in a game. The gaming system can take a number of different forms. 5 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. 10 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 is 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 20 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 25 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 30 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. 35 Figure 1 is a plan view of a virtual gaming table 100 having a horizontally oriented display 120 and a log on terminal 140. As can been from figure 1, the gaming table 268330M1 (GHMatters)P71729.AU 2 25/05/11 - 9 is surrounded by seven chairs 130 indicating seven possible player positions. Two player interfaces 124a, 124b are active on the display 120. A central area 122 of the display is used to display information common to all 5 players; in the example shown in Figure 1 a display of a roulette game. As shown in Figure 2, from a functional perspective, a virtual table 200 comprises a game controller 220, a 10 common display 212 and a variable number of player interfaces 210. 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 15 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 20 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. 25 In the embodiment, a number of the functional modules of the game controller are implemented by a processor 215. However, a person skilled in the art will appreciate that other techniques such dedicated hardware could be used 30 instead of program code running on a processor 215 to implement the required functions. The game controller's processor 215 processes the game play instructions in accordance with game play rules and 35 outputs game play outcomes to the display. Typically, the game play instructions are stored as program code in a memory 270. Herein the term "processor" is used to refer 2683301_1 (GHMatters) P71729AU2 25/05/11 - 10 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 5 purpose computer (e.g. a PC) or a server. These functions are carried out based on data such as credit data 272 and game rule data 274 stored in a memory 270 of the game controller 220. The game controller 220 10 has a number of modules including a display controller 230 for controlling what is displayed both in the common display area 212 of a gaming table 212 and on each of the player interfaces 210. 15 The display 120 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 display 120. A person skilled in the art will appreciate that the "touch screen" sensor 20 need not cover the entire display. For example central area 122 as shown in Figure 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 25 players. The display 120 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 (2m - 3m) across the diagonal. However, a person skilled in the art will appreciate that the display could be formed a 30 plurality of sub-units located adjacent to one another under the control of the display controller 230 to display both the player interfaces 210 and the common display area 212. 35 The display controller 230 controls the display to display the individual player interfaces based on data provided by the interface controller 240 and the outcome determiner 2683301_ (GHMatters) P71729.AU.2 25/05/11 - 11 260. The interface controller also provides data to the touch screen processor 250 to enable it to interpret touches on the touch screen display, for example, in order to associate them with individual player interfaces 210 s and to provide this data to the outcome determiner 260. In this manner, individual player instructions can be correctly provided to the outcome determiner 260 so that the outcome determiner 266 can determine the result of the game based on the game rule data 274. Similarly, the 10 outcome determiner 260 provides data to the display controller 230 regarding the game outcomes for individual players. This may be displayed in a display region of the player interface 210 on the common display or both. 15 A person skilled in the art will appreciate that depending on the game, the outcome determiner 260 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 20 data 272 is maintained separately for each player interface in memory 270. The log-on terminal 280 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 25 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 30 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. 35 To participate in the game a player uses the log-on terminal 280 to request a player interface for the game either manually, or by swiping or otherwise providing a 2683301l (GHMaters) P71729.AU.2 25105/1 1 - 12 player tracking device to the log on terminal 280. That is, depending on the embodiment the log on terminal may read magnetic cards, smart cards, RFID tags or another suitable data carrier. 5 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. 10 At least one credit input/output mechanism 290 is provided which can be shared by all players of the gaming system. In one embodiment, the credit input/output mechanism includes a voucher printer 295. A player provides credit is to the credit input/output 290 by inserting currency using a bill 291 or coin 292 acceptor or by providing their player trading device to the reader 294 and specifying an amount, e.g. by use of a keypad 296, to be retrieved from an account associated with the tracking device which may 20 be stored on a player account server 412 such as is shown in Figure 4. Credit manager 300 processes data received from the credit record and the credit creates a record in credit data 272 specifying the amount of input credits and associates a credit identifier with the credit record, 25 typically by generating a unique credit identifier. A voucher is printed by a voucher printer 295. The voucher has the credit identifier on it so that the player can enter it at a player interface 210 using a virtual key pad. The credit manager controller 220 processes the 30 input credit identifier and verifies it against records stored as credit data 272. 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 35 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 2683301_1 (GHMatters) P71729.AU.2 25/05/11 - 13 present within the player's player interface 210. To this end, the credit manager 300 has a number of modules including a credit record generator 310 which 5 generates a credit record corresponding to the amount of input credit, a credit identifier issuer 320 which issues credit identifiers in accordance with predetermined rules, for example, it may generate the identifier randomly or from a set of identifiers. Both the credit record 10 generator 310 and the credit identifier issuer 320 are adapted to communicate data to the credit data 272 of the memory. The credit manager 300 also includes an identifier 15 requester 330 adapted to request that a player enter an identifier and cause the display controller to display this request on one of the player interfaces 210 in response to an attempt by a player to allocate the credit to their player interface. 20 A credit identifier processor and credit allocator 340 processes input requests and if the credit identifier is correct updates the credit data 272 such that a credit meter associated with the player interface includes the 25 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. 30 With reference to Figure 2, the interface controller provides to the display controller, data stored as interface data 273 which specifies which parts of the player interface are assigned to the different areas of 35 the player interface 500, which has a chip stack area 510, a bet manipulation area 520 and a bet commitment area 530 so that these areas are displayed to a player. Token data 275 specifies the number of tokens associated with a 2683301_ (GHMatters) P71729.AU.2 25/05/11 - 14 player interface and their current locations within the player interface 500. The touch screen processor 250 determines when a player touches the screens and employs the token data to determine which token or tokens the 5 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. 10 In an alternative mode of control, the touch screen processor 250 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 15 in a direction they wish the chip to go to impart a vector velocity to the chip. The touch screen processor 250. The touch screen processor 250, implements manipulation rules 276 in respect of a player's touching of the tokens. In the embodiment, after a new credit record is created by 20 the credit manager, the credit manager 300 causes the display controller 230 to display in a new token display area 213 of the common display 212, tokens corresponding to the amount of credit in the credit records. A player reaches over to the new token display area 213 on the 25 common display 212, touches the tokens in the new display area 213 and drags them towards their player interface area. When the tokens are released by the player within the player's interface area 500 or within a specific sub area, such as the bet manipulation area 520 or the chip 30 stack area 510, the touch screen processor advises the credit manager 300 that a player has attempted to allocate the tokens to their player interface. The identifier requester 330 causes the display controller 230 a virtual keypad 620 as shown in Figure 6 and a request for a player 35 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 2683301_ (GHMatters) P71729.AU 2 25/05/1) - 15 as described above, the credit amount, in the example shown in Figure 7, 575 units of chips are added to the player's chip stack area 510 in this case in a pile of five 100 unit chips 712, and three 25 unit chips 714. The 5 player's total of chips is also updated 722. Accordingly there is implemented a method 800 where a credit input is received 810, a credit record is generated 820, a credit identifier is associated with a credit 10 record 830. Tokens corresponding to the credit record are displayed 835. The touch screen is monitored for an attempt to allocate the tokens to a player interface 840. If a user attempts to allocate the tokens to themselves the user is prompted for a credit identifier 850. At step 15 860 the method involves receiving and processing the credit identifier and if the identifier is correct at step 870 the method involves allocating the credit record to the credit meter of the player interface 870. 20 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 25 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 30 player appends to their normal code. Further, where the virtual table is networked, the terminal may contact the casino management system 412 and pass the transaction record to it. In this embodiment, 35 transaction records are subsequently retrieved over the network when the player approaches the game. Further, while Figure 2, shows the credit manager and credit data being common functional components of the 2683301_1 (G-Matters) P71729 AU 2 25/05/11 - 16 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 terminal 140 shown in Figure 1. In this case, an initial credit record may be s 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 10 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. 15 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 20 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 25 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 30 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 35 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 2683301_1 (GHIMatters) P71729AU.2 25/05/11 - 17 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. s 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 10 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 is 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 20 and once the time runs out the ticket would need to be re inserted to the terminal 140 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 25 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 30 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. 35 In some embodiments, tokens corresponding to new credit records may be displayed at a plurality of locations to 2683301_1 (GHMatters) P71729.AU2 25/05/11 - 18 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 s interface or a dormant interface may revert to a view such as shown in Figure 6 - i.e. default to a credit identifier entry mode. Figure 4 shows a gaming system 400 in accordance with an 10 alternative embodiment. The gaming system 400 includes a network 401, which for example may be an Ethernet network. Gaming tables 403, are connected to the network 401. The gaming tables 202 provide a player operable interface for the gaming system 400. 15 One or more displays 404 may also be connected to the network 401. The displays 404 may, for example, be associated with one or more gaming tables 203. The displays 404 may be used to display representations 20 associated with game play on the gaming tables 402, and/or used to display other representations, for example promotional or informational material. In a thick client embodiment, game server 405 implements 25 part of the game played by a players using a gaming table 403 and the gaming table 403 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. A database 30 management server 406 may manage storage of game programs and associated data for downloading or access by the gaming devices 402 in a database 406A. Typically, if the gaming system enables players to participate in a Jackpot game, a Jackpot server 407 will be provided to monitor and 35 carry out the Jackpot game. In a thin client embodiment (or networked gaming 2683301_ (GHMarters) P71729.AU.2 25/05/1I - 19 embodiment), game server 405 implements most or all of the game played by a player using a gaming table 403 and the gaming table 403 essentially provides only the player interface. With this embodiment, the game server 405 5 provides the game controller. The gaming table 403 will receive player instructions, pass these to the game server 405 which will process them and return game play outcomes to the gaming table 403 for display. 10 Player accounts may be maintained by player account server 412 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 15 device to the credit input/output mechanism 290 of the virtual gaming table 403. Servers are also typically provided to assist in the administration of the gaming network 400, including for 20 example a gaming floor management server 408, and a licensing server 409 to monitor the use of licenses relating to particular games. An administrator terminal 410 is provided to allow an administrator to run the network 401 and the devices connected to the network. 25 The gaming network 400 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 a firewall 411. 30 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 35 may be run as a single "engine" on one server or a separate server may be provided. For example, the game server 405 could run a random generator engine. 2683301_ (GHMtters) P71729.AU2 25/05/1 - 20 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 5 may run a plurality of different games as required by the tables 403. Further variations will be apparent to persons skilled in the art and should be understood as falling within the 10 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. 15 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, 20 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 25 herein does not constitute an admission that the prior art forms a part of the common general knowledge in the art in any country. 2683301_1 (GHfMaters) P71729AU.2 25/05/1

Claims

1. A method of credit input for a multi-player gaming system having a display, a controller and a player s interface associated with a keypad, the player interface having a first interface area operable to display tokens available to a player for wagering and a second interface area operable to display tokens wagered by the player and the display having a new token display area for displaying 10 new tokens available to the player, the method comprising: receiving a credit input; generating, using the controller, a credit record associated with the gaming system including data indicative of the credit input; 15 displaying in the new token display area, one or more tokens indicative of the credit input; associating, using the controller, a credit identifier with the credit record; issuing a voucher having the credit identifier 20 printed thereon; receiving, via the player interface, an instruction to allocate the one or more tokens to the player, the instruction comprising a player moving the one or more tokens from the new token display area to the 25 first interface area; issuing a request for the credit identifier in response to receiving the instruction; receiving, via a keypad, the credit identifier; verifying, using the controller, the credit 30 identifier received via the keypad with respect to the credit record; displaying the one or more tokens in the first interface area, in response to verifying the credit identifier; and 35 monitoring a movement of at least one of the one or iMore displayed tokens from the first interface area to the second interface indicative of the moved at least one 26833013 (OHMatws) P71729.AU,2 23/09/13 - 22 of the one or more displayed tokens having been wagered.

2. A method as claimed in claim 1, further comprising associating a player provided credit identifier 5 with the credit record.

3. A method as claimed in any claim 1 or claim 2, wherein the display is a touch screen display and the method comprises monitoring the output of the touch screen 10 for an attempt to move the one or more tokens.

4. A method as claimed in any one of claims 1 to 3, wherein receiving a credit input comprises receiving a ticket having a credit value. 15

5. A method as claimed in any one of claims 1 to 4, wherein receiving a credit input comprises obtaining credit from a player account. 20

6. A method as claimed in claim 5, wherein the player account is linked to a player tracking device.

7. A method as claimed in any one of claims 1 to 6, wherein receiving a credit input comprises receiving a 25 currency input.

8. A multi-player gaming system comprising: a display; a credit input mechanism; 30 a key pad; a player interface; a voucher printer; and a credit manager, the player interface having a first interface 35 area operable to display tokens available to a player for wagering and a second interface area operable to display tokens wagered by the player and the display having a new 26833013 (OHMmnus) P71729.AU.2 23/09I13 - 23 token display area for displaying new tokens available to the player, the credit manager arranged to: generate a credit record including data 5 indicative of credit input via the credit input mechanism; cause the display to display one or more tokens indicative of the credit input in the new token display area; associate a credit identifier with the 10 credit record; issue a voucher having the credit identifier printed thereon via the voucher printer; issue a request for the credit identifier, in response to an instruction to allocate the one or more is tokens, the instruction comprising a player moving the one or more tokens from the new token display area to the first interface area, receive, via the keypad, the credit identifier; and 20 verify the credit identifier, received via the keypad, against the credit record, whereafter the gaming system displays the one or more tokens in the first interface area; and monitors a movement of at least one of the one or 25 more displayed tokens from the first interface area to the second interface indicative of the moved at least one of the one or more displayed tokens having been wagered.

9. A gaming system as claimed in claim 8, comprising 30 a player interface controller adapted to provide a plurality of player interfaces.

10. A gaming system as claimed in claim 9 comprising a touch screen display and the player interface controller 35 is adapted to provide at least part of each player interface with the touch screen display. 26833013 (GHAners) P71729AU.2 23/09/13 - 24

11. A gaming system as claimed in claim 9 or claim 10, wherein the player interface controller is adapted to add and remove player interfaces. 5

12. A gaming system as claimed in any one of claims 8 to 11, wherein the credit input mechanism comprises a bill acceptor.

13. A gaming system as claimed in any one of claims 8 10 to 12, wherein the credit input mechanism comprises a coin acceptor.

14. A gaming system as claimed in any one of claims 8 to 13, wherein the credit input mechanism comprises a 15 ticket reader.

15. A gaming system as claimed in any one of claims 8 to 14, wherein the credit input mechanism is adapted to obtain a credit amount from a player account. 20

16. A gaming system as claimed in any one of claims 8 to 15, wherein the display is a horizontal display.

17. A gaming system as claimed in claim 16, wherein 25 the display is 2-3m across the diagonal.

18. A method of credit input substantially as described herein with reference to the accompanying drawings. 30

19. A multi-player gaming system substantially as described herein with reference to the accompanying drawings. 35 26133013 (OHMamnes) P71729.AU.2 23109113