AU2014200341A1 - Method of credit input and a gaming system - Google Patents

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. 5030473_1 (GHMatters) P71729.AU.3 16/01/14 130Gt -140 Figure 1

Description

Title METHOD OF CREDIT INPUT AND A GAMING SYSTEM 5 Related Application This application is a divisional application of application no. 2011202440 filed 25 May 2011, which was itself a divisional application of application no. 10 2008202090 filed 12 May 2008, the disclosures of both of which are incorporated herein by reference. Field 15 The present invention relates to a method of credit input and a gaming system. Background to the Invention 20 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 25 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 30 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 35 replaced by a gaming machine. As such games are developed, there is a need to provide a 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 2 credit input technique which suits these game types. Summary of the Invention 5 In a first aspect, the invention provides a method of credit input for a multi-player gaming system having a 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 10 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 new tokens available to the player, the method comprising: receiving a credit input; 15 generating, using the controller, a credit record associated with the gaming system including data indicative of the credit input; displaying in the new token display area, one or more tokens indicative of the credit input; 20 associating, using the controller, a credit identifier with the credit record; issuing a voucher having the credit identifier printed thereon; receiving, via the player interface, an 25 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 first interface area; issuing a request for the credit identifier in 30 response to receiving the instruction; receiving, via a keypad, the credit identifier; verifying, using the controller, the credit identifier received via the keypad with respect to the credit record; 35 displaying the one or more tokens in the first interface area, in response to verifying the credit identifier; and 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 3 monitoring a movement of at least one of the one or 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. 5 In an embodiment, the method further comprises associating a player provided credit identifier with the credit record. 10 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. 15 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. 20 In an embodiment, the player account is linked to a player tracking device. In an embodiment, receiving a credit input comprises 25 receiving a currency input. In a second aspect, the invention provides a multi-player gaming system comprising: a display; 30 a credit input mechanism; a key pad; a player interface; a voucher printer; and a credit manager, 35 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 4 tokens wagered by the player and the display having a new token display area for displaying new tokens available to the player, the credit manager arranged to: 5 generate a credit record including data 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; 10 associate a credit identifier with the credit record; issue a voucher having the credit identifier printed thereon via the voucher printer; issue a request for the credit identifier, 15 in response to an instruction to allocate the one or more 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 20 identifier; and 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 25 monitors a movement of at least one of the one or 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. 30 In an embodiment, the gaming system comprises a player interface controller adapted to provide a plurality of player interfaces. In an embodiment, the gaming system comprises a touch 35 screen display and the player interface controller is adapted to provide at least part of each player interface on with the touch screen display. 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 5 In an embodiment, the player interface controller is adapted to add and remove player interfaces. 5 In an embodiment, the credit input mechanism comprises a bill acceptor. In an embodiment, the credit input mechanism comprises a coin acceptor. 10 In an embodiment, the credit input mechanism comprises a ticket reader. In an embodiment, the credit input mechanism is adapted to 15 obtain a credit amount from a player account. In an embodiment, the display is a horizontal display. In an embodiment, the display is 2 to 3 m across its 20 diagonal. It should be noted that any of the various individual features of each of the above aspects of the invention, and any of the various individual features of the 25 embodiments described herein including in the claims, can be combined as suitable and desired. Brief Description of the Drawings 30 In order that the invention may be more clearly ascertained, an embodiment incorporating all aspects of the invention will now be described in relation to the accompanying drawings in which: 35 Figure 1 is a plan view of a gaming table of an embodiment; 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 6 Figure 2 is a functional block diagram of a gaming system on an embodiment; Figure 3 is a further block diagram showing a credit 5 manager in more detail; Figure 4 is a schematic diagram showing a networked embodiment; 10 Figure 5 is a schematic diagram of a player interface; Figure 6 is a schematic diagram of a player interface where a player enters a code; 15 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. 20 Detailed Description Referring to the drawings, there is shown a gaming system arranged to handle credit input in respect of a multi 25 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. 30 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. 35 In a second form, a distributed architecture is provided wherein some of the components required for implementing 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 7 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 5 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 10 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 15 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 20 on the game being played, operating conditions, and so on. Other variations will be apparent to persons skilled in the art. Figure 1 is a plan view of a virtual gaming table 100 25 having a horizontally oriented display 120 and a log on terminal 140. As can been from Figure 1, the gaming table 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 30 the display is used to display information common to all players; in the example shown in Figure 1 a display of a roulette game. As shown in Figure 2, from a functional perspective, a 35 virtual table 200 comprises a game controller 220, a common display 212 and a variable number of player interfaces 210. As described in detail below, in the 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 8 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 5 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 10 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. 15 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 instead of program code running on a processor 215 to 20 implement the required functions. The game controller's processor 215 processes the game play instructions in accordance with game play rules and outputs game play outcomes to the display. Typically, the 25 game play instructions are stored as program code in a memory 270. 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 30 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 as credit data 272 and game rule data 274 stored in a memory 35 270 of the game controller 220. The game controller 220 has a number of modules including a display controller 230 for controlling what is displayed both in the common 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 9 display area 212 of a gaming table 212 and on each of the player interfaces 210. The display 120 incorporates a touch screen. Herein such 5 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 need not cover the entire display. For example central 10 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 players. The display 120 itself is typically a wide 15 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 plurality of sub-units located adjacent to one another 20 under the control of the display controller 230 to display both the player interfaces 210 and the common display area 212. The display controller 230 controls the display to display 25 the individual player interfaces based on data provided by the interface controller 240 and the outcome determiner 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 30 to associate them with individual player interfaces 210 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 35 game based on the game rule data 274. Similarly, the outcome determiner 260 provides data to the display controller 230 regarding the game outcomes for individual 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 10 players. This may be displayed in a display region of the player interface 210 on the common display or both. A person skilled in the art will appreciate that depending 5 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 data 272 is maintained separately for each player 10 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 interface. Alternatively the player position maybe 15 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 20 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 25 terminal 280 to request a player interface for the game either manually, or by swiping or otherwise providing a 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 30 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. 35 At least one credit input/output mechanism 290 is provided which can be shared by all players of the gaming system. 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 11 In one embodiment, the credit input/output mechanism includes a voucher printer 295. A player provides credit to the credit input/output 290 by inserting currency using 5 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 be stored on a player account server 412 such as is shown 10 in Figure 4. Figure 3 is a further block diagram showing credit manager 300 in more detail. Referring to figure 3, credit manager 300 processes data received from the credit record and the 15 credit creates a record in credit data 272 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 a voucher printer 295. The voucher has the credit identifier on it 20 so that the player can enter it at a player interface 210 using a virtual key pad. The credit manager controller 220 processes the 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 25 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 30 interface has been allocated the credit, tokens corresponding to the credit will be present within the player's player interface 210. To this end, the credit manager 300 has a number of 35 modules including a credit record generator 310 which 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 12 from a set of identifiers. Both the credit record generator 310 and the credit identifier issuer 320 are adapted to communicate data to the credit data 272 of the memory. 5 The credit manager 300 also includes an identifier 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 10 response to an attempt by a player to allocate the credit to their player interface. A credit identifier processor and credit allocator 340 processes input requests and if the credit identifier is 15 correct updates the credit data 272 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. 20 However, other tokens such as coins or the like may be employed. With reference to Figure 2, the interface controller provides to display controller 230 data stored (in memory 25 270) as interface data 273 that specifies which parts of the player interface are assigned to the different areas of the player interface 210. Figure 5 is a schematic diagram of such a player interface (shown generally at 500), which has a chip stack area 510, a bet manipulation 30 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 player interface and their current locations within the player interface 500. The touch screen processor 250 determines when a player 35 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 13 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. 5 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 10 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 (stored in memory 270 as manipulation rules data 276) in respect of a player's touching of the tokens. In 15 the embodiment, after a new credit record is created by 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 20 reaches over to the new token display area 213 on the 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 25 area, such as the bet manipulation area 520 or the chip 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 30 keypad 620 as shown in Figure 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 35 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 14 player's total of chips is also updated 722. Figure 8 is a flowchart 800 showing a method of the embodiment. Accordingly there is implemented method 800 5 where a credit input is received 810, a credit record is generated 820, a credit identifier is associated with a credit 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 10 interface 840. If a user attempts to allocate the tokens to themselves the user is prompted for a credit identifier 850. At step 860 the method involves receiving and processing the credit identifier and if the identifier is correct at step 870 the method involves allocating the 15 credit record to the credit meter of the player interface 870. Various further features or modifications will be apparent to persons skilled in the art. For example, the code will 20 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 25 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. 30 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, transaction records are subsequently retrieved over the network when the player approaches the game. 35 Further, while Figure 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 15 provided as part of the log-on terminal 140 shown in Figure 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 5 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 10 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 15 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, 20 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 25 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 30 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 35 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 16 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 5 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. 10 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 15 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 be re 20 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 large number of incorrect passwords attempts are made. 25 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 30 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 make it convenient for a player to reach the virtual 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 17 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 5 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 alternative embodiment. The gaming system 400 includes a 10 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 associated with game play on the gaming tables 402, and/or 20 used to display other representations, for example promotional or informational material. In a thick client embodiment, game server 405 implements part of the game played by a players using a gaming table 25 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 management server 406 may manage storage of game programs 30 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 carry out the Jackpot game. 35 In a thin client embodiment (or networked gaming embodiment), game server 405 implements most or all of the 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 18 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 provides the game controller. The gaming table 403 will 5 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. Player accounts may be maintained by player account server 10 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 device to the credit input/output mechanism 290 of the 15 virtual gaming table 403. Servers are also typically provided to assist in the administration of the gaming network 400, including for example a gaming floor management server 408, and a 20 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 may be run as a single "engine" on one server or a 35 separate server may be provided. For example, the game server 405 could run a random generator engine. Alternatively, a separate random number generator server 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 19 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 5 tables 403. 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 10 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 15 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 20 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 25 forms a part of the common general knowledge in the art in any country. 5030473_1 (GHMatters) P71729.AU.3 16/01/14

Claims (17)

1. A method of credit input for a multi-player 5 gaming system having a 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 10 the display 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 15 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 21 the second interface indicative of the moved at least one of the one or more displayed tokens having been wagered.

2. A method as claimed in claim 1, further 5 comprising associating a player provided credit identifier 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 10 method comprises monitoring the output of the touch screen 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 15 ticket having a credit value.

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, 25 wherein receiving a credit input comprises receiving a currency input.

8. A multi-player gaming system comprising: a display; 30 a credit input mechanism; a key pad; a player interface; a voucher printer; and a credit manager, 35 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 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 22 tokens wagered by the player and the display having a new token display area for displaying new tokens available to the player, the credit manager arranged to: 5 generate a credit record including data 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; 10 associate a credit identifier with the credit record; issue a voucher having the credit identifier printed thereon via the voucher printer; issue a request for the credit identifier, 15 in response to an instruction to allocate the one or more 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 20 identifier; and 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 25 monitors a movement of at least one of the one or 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. 30

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

10. A gaming system as claimed in claim 9 comprising 35 a touch screen display and the player interface controller is adapted to provide at least part of each player interface with the touch screen display. 5030473_1 (GHMatters) P71729.AU.3 16/01/14 - 23

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. 10

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

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

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

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

17. A gaming system as claimed in claim 16, wherein the display has a diagonal measurement of 2 to 3 m. 5030473_1 (GHMatters) P71729.AU.3 16/01/14