AU2006203564B2 - Method and Apparatus for Controlling the Cost of Playing an Electronic Gaming Device - Google Patents

Description

P/00/011 28/5/91 Regulation 3.2

NO

00

AUSTRALIA

Patents Act 1990

ORIGINAL

COMPLETE SPECIFICATION STANDARD PATENT Name of Applicant: IGT Actual Inventors Address for service is: John F Acres, Alec Ginsberg, David Wiebenson WRAY ASSOCIATES Level 4, The Quadrant 1 William Street Perth, WA 6000 Attorney code: WR Invention Title: Method and Apparatus for Controlling the Cost of Playing an Electronic Gaming Device Details of divisional application: 2003200581 filed 14 February 2003 The following statement is a full description of this invention, including the best method of performing it known to me:- IND- 1/2-

O

CField of the Invention The present invention relates to electronic gaming machines, also referred to oo00 herein as gaming devices, interconnected by a computer network and more particularly to a method of configuring such machines.

Description of the Related Art IThis specification describes aspects of prior art networked gaming device systems. However, neither such aspects of prior art networked gaming device systems nor the description contained herein of such aspects of prior art networked gaming device systems is to be taken as forming part of the common general knowledge solely by virtue of the inclusion herein of reference to and description of such aspects of prior art networked gaming device systems.

Casinos typically include electronic gaming machines (EGMs) such as slot machines and video poker machines. The slot machines usually includes three reels that each have a plurality of symbols printed thereon. After the player applies a wager to the machine, he or she starts play by triggering a switch that starts the reels spinning. Each reel stops at a random position and thereby presents three symbols one from each reel. Some combinations of symbols do not pay any jackpot. Others pay varying amounts according to predetermined combinations that appear in a pay table displayed on the machine.

Video poker machines include a video monitor upon which the images of cards appear, as if dealt by a dealer from a shuffled deck, in response to player inputs to the machine. The player wins jackpots dependent upon the amount wagered and in accordance with the cards that are dealt.

When a new EGM, whether a slot or poker machine, is made available for gaming, it must first be configured. A programmable read only memory (PROM) is installed in each new EGM. The PROM includes data that controls the behavior of the machine, and typically also includes data that establishes the IN- 1/3payback percentage, such data being referred to herein as the paytable. The bJ paytable defines the average percentage of wagers that is returned to the players in the form of jackpots over time. Gaming regulations in many 00 jurisdictions require the paytable to be stored in the PROM. The PROM must consequently be changed if the casino desires to change the paytable. Some \0 -2- Sjtwisdictions, however, permit the casino to change the paytable by setting options at each EGM. Such options are selected by using a key switch at each oo machine that places the machine into a configuration mode. When in this mode, the casino employee configures the machine for such things as the maximum 7- 5 jackpot that can be paid by the machine before a hand payment is required. The n rate at which the jackpot meter increments may also be selected as well as O special effects generated by thei machine in response to a jackpot. And if the jurisdiction permits, the paytable may be changed when the machine is in the configuration mode. Otherwise, the only way to change the paytable is to replace the PROM with another containing a different paytable.

Poker machines, when placed in a configuration mode as described above,, display information about the status of the various options on the video monitoi that:is used to display the cards and other information when the game is played~ On the poker machine, sound, background color, and card decoration, which may be configured to display the casino's logo, are examples of the parameters that can be changed when the machine is in the configuration mode. It is easier to configure the poker machine because the monitor displays the status oft' various options as well as lists of options, from which a parameter can be selected and implemented. Slot machines, on the other hand, do not have a monitor and are therefore difficult to configure because the only displays available to indicate status are four-digit alphanumeric readouts that are used to display the amounts on the credit meter or the jackpot meter. Configuring a slot machine as described above can take about twenty to thirty minutes of casino time. Installing machines in a new casino, which may number in the thousands, or changing the parameters on pre-existing machines, is consequently a very labor intensive process.

It is also a process that lends itself to implementing, either inadvertently or otherwise, the wrong parameters. Thus, a group of machines that are supposed to be configured identically may include one or more that vary from one another because of an incorrect input during the configuration process.

-3tOf Some EGMs include a primary game and. a secondary game. For example, the primary game may include a slot machine that periodically permits the player t 0 play the secondary game before the next reel spin on the slot machine. Some secondary games award a prize after the player spins a wheel. The prize is indicated on a sector of the wheel, which stops at a random location after being spun. Because the secondary game must be configured in the same manner as the primary game, the same types of disadvantages are associated with

ID

Ssecondary games.

In addition, some EGMs include a dedicated progressive in which a percentage of all wagers made on that machine goes into a separate pool that is awarded by the machine. The payback percentage for such a game must also be configured, either by the casino or via a paytable included in a PROM, and.

therefore presents similar problems; It would be desirable for a casino operating a plurality of EGMs to be able to change the effective wager per unit time required of a player of the machines.

The wager per unit time, which is the cost to the player for playing the EGMs, is i a function of the payback percentage and the game speed. The faster the game: speed and the lower the payback percentage, the more money the casino retains, and vice versa. Increasing the wager per unit time increases casino revenues up to a point. If the casino simply selects a very low payback percentage (or a very fast game speed) on all of its machines, the players may feel that they get better returns elsewhere. It would, however, be desirable for the casino to be able to vary the wager per unit time in.accordance with the demand on the casino floor. In other words, during evenings and into the early morning hours on weekends and especially on certain holidays there are greater numbers of players placing wagers than, on a Tuesday morning between 7:00 am and noon. It would therefore be desirable for the casino to set the cost to the player at a higher level during high demand periods and at a lower level, to attract players, during low demand periods.

r ND -4-

O

Ie It would be quite cumbersome to change payback percentage, either by switching the PROMs from machines, or by placing the machine in a 0 configuration mode in jurisdictions that permit changing pay tables in response to casino configuration. Changing game speed by switching PROMs or by 5 placing the machine in a configuration mode would be equally cumbersome. It would be impractical to make such changes in a large casino even weekly, much less daily.

\O

In addition to varying the cost to the players, the wager per unit time, in response to periods of high and low demand in the casino, it would be desirable to change the player cost in response to the status of a particular player. The casino likes to track players to identify big players and to conduct direct mail marketing. Casino management therefore encourages players to sign up for, receive. iand use a playertr.ackingcard, which the ptayer inserts into a card reader associated with each EGM. The casino can therefore identify players based on previous or current rates of play and vary the wager per unit time for that player accordingly.

It might also be desirable to change the cost to the player depending upon their status as a person that the casino would like to encourage to play their games or as the companion of such a person or of a person known to wager large amounts. Changing player cost in response to player status by switching PROMs or reconfiguring the machines is not possible.

In addition to the foregoing it would be desirable to change the manner in which the player perceives the EGM. In other words, it would be desirable to change the sound effects and appearance of the machine in response to time, the rate at which the interconnected machines are played, or the status of a player.

\O

c DISCLOSURE OF THE INVENTION In accordance with one aspect of the present invention there is provided a method of 0 configuring electronic gaming machines interconnected by a computer network to a host computer comprising: implementing selected configuration parameters at each machine; Spermitting play to occur at the machines; operating a player-tracking system on the network; (N monitoring the level of play of a tracked player on multiple gaming machines; Stransmitting data relating to the monitored status over the network; Sstoring the status data on a computer connected to the network; selecting a machine being played by the player; generating a computer message based at least in part on the stored status data; issuing the message from the host computer; and changing a configuration parameter of the selected machine responsive to the message.

Preferably, the changed configuration parameter comprises game speed.

Preferably, the changed configuration parameter comprises payback percentage.

Preferably, the changed configuration parameter comprises game appearance.

Y

-6- SBRIEF DESCRIPTION OF THE DRAWINGS ;The present invention will now be described, by way of example, with 00 5 reference to the accompanying drawings, in which: Figure 1 is an illustration of an embodiment of a system for monitoring n and configuring gaming devices.

I 10 Figure 2 is a block diagram of an embodiment of an electronic module associated with each gaming device to permit monitoring and configuring thereof.

Figure 3 is a schematic diagram of a data communication node of the electronic module of Figure 2.

Figure 4 is a schematic diagram of a discrete machine interface circuit of the electronic module of Figure 2.

Figure 5 is a schematic diagram of a player tracking module of the electronic module of Figure 2.

Figure 6 is a schematic diagram of a card reader circuit of the electronic module of Figure 2.

IDFIG. 7A is an exploded view of an embodiment of a card reader.

FIG. 7B is a rear perspective view of the card reader of FIG. 7A.

FIG. 7C is a front perspective view of the card reader of FIG. 7A.

;Z FIG. 8 is a schematic diagram of a display circuit of the player tracking oo 5 module of FIG. 2.

FIG. 9 is a schematic diagram of a personality board of the electronic module of FIG. 2.

SFIG. 10 is a schematic diagram of a triac driver circuit of the electronic Smodule of FIG. 2.

FIG. 11 is a schematic diagram of a relay driver circuit of the electronic module of FIG. 2.

FIG. 12 is a block diagram of a communication board included in each floor controller of FIG. 1.

FIG. 13 is a flow chart for the power-on procedure for the data dommunication node (DCN) of FIG. 2, which is implemented in firmware executed by the DCN controller.

FIG. 14 is a flow chart for processing of the discrete gaming device inputs, of FIG. 13.

FIG. 15 is a flow chart for the step of incrementing meter counts associated with each gaming device of FIG. 14, which is implemented in firmware executed by the DCN controller.

FIG. 16 is a flow chart for the step of processing the serial interface between the gaming device and the data communication node of FIG. 13, which is implemented in firmware executed by the DCN controller.

FIG. 17 is a flow chart for the step of processing the netvork interface between the floor controller and the data communication node of FIG. 13, which is implemented in firmware executed by the DCN controller.

IO

O

be FIG. 18 is a flow chart for the step of processing the network S- message of FIG. 17, which is implemented in firmware executed by the DCN controller.

FIG. 19 is a flow chart for the step of processing the data S 5 communication node request of FIG. 18, which is implemented in firmware executed by the DCN controller.

FIG. 20 is a flow chart for the step of FIG. 13 of processing the player tracking interface, which is implemented in firmware executed by C- the DCN controller.

FIG. 21 is a flow chart for the step of processing a valid inserted card of FIG. 20, which is implemented in firmware executed by the DCN controller.

FIG. 22 is a flow chart for the step of processing player tracking information ofFIG. 21, which is implemented in firmware executed by the DCN controller.

FIG. 23 is a flow chart for the power-on procedure for the player tracking (PT) node of FIG. 2, which is implemented in firmware executed by the IPT controller.

FIG. 24 is a flow chart for the step of processing the DCN intkrface of FIG. 23, which is implemented in firmware executed by the PT controller.

FIG. 25 is a flow chart for the step of processing the DCN message of FIG. 24, which is implemented in firmware executed by the IPT con troller.

FIG. 26 is a flow chart for the step of processing the card reader bezel update of FIG. 23, which is implemented in firmware executed by the PT controller.

FIG. 27 is a flow chart for the step of processing the card reader of FIG. 23, which is implemented in firmware executed by thePT con troller.

ID- 9/1

O

FIG. 28 is a flow chart for the power-on floor controller process, which is ;implemented in software executed by the floor controller.

00 oo FIG. 29 is a flow chart for the message processing step of FIG. 28, which is implemented in software executed by the floor controller.

FIG. 30 is a flow chart for the message handling step of FIG. 29, which is N implemented in software executed by the floor controller.

O

SFIG. 31 is a flow chart for the step of assigning unique machine addresses of FIG. 30, which is implemented in software executed by the floor controller.

FIG. 32 is a flow chart for the system monitoring step of FIG. 28, which is implemented in software executed by the floor controller.

FIG. 33 is a flow chart for the event handling step of FIG. 32, which is implemented in software executed by the floor controller.

FIG 34. is a flow chart for a bonus control, which is implemented in software executed by the floor controller.

FIG. 35 is a schematic diagram of an embodiment of a plurality of electronic gaming machines interconnected by a computer network to a host computer in which the method in accordance with the present invention may be performed.

FIG. 36 is a schematic diagram of a slot machine and associated hardware which is typical of each of the electronic gaming machines in the network shown in Fig. FIG. 37 is a flow chart that depicts operation of the FIG. 35 network in accordance with an embodiment of the method of the present invention.

NO -9/2- 0 FIG. 38 is an exemplary time line for a one week period that shows O ~changes in the player cost per unit time in response to the time of day.

o00 FIG. 39 is an exemplary time line for a one year period that shows changes in the player cost per unit time in response to the day of the year.

\O

FIG. 40 is an exemplary pay table for an electronic gaming machine in the network shown in Figs 35 and 36.

\O

DETAILED DESCRIPTION An embodiment of a system for operating networked gaming devices and an associated computer network are described herein in detail with reference to Figures 1 to 34 of the accompanying drawings. Embodiments of the method of the present invention are described herein with particular reference to Figures to 40 and may be implemented in a system and network as described with reference to Figures 1 to 34.

A Table of Contents for the Detailed Description is set out below.

Table of Contents I. SYSTEM ORGANIZATION A. SYSTEM OVERVIEW B. DATA COMMUNICATION NODE 1. OVERVIEW 2. CONTROLLER AND MEMORY 3. NETWORK INTERFACE 4. SERIAL MACHINE INTERFACE 'o -9/3-

O

SERIAL DISPLAY INTERFACE 6. DISCRETE MACHINE INTERFACE 00 7. MACHINE CONFIGURATION

IO

O

01)G. PLAYE.R TRACI(IN G MODULE L. OV~ERVIZ

V

002. S'ERIkL DI&PIA'Y CIR=UT 3- SERIAL WXANSION ?Qln*rS 4. CARD READER

D.ISPLAY

6. D-iscRE.TE. IN'Pu'T SECTION D. PERSONALITY

BOARD

E. BON'US DISPLAY DRIVE RS F. FLOOR CONTROLLER.

ILOPERATION

A. DATA COMMUNICATION

NODE

1. POWER UP PROCEDURE 2. READiNG UNIQUE IDENTIFICA'IION NU4MBER 3. M~lTQIN~GAujNG DiEVICS .150CREE INPUT 4. PRocsSSING. GAMING DEVICr- SERIAL INTERF'ACE, PROCESSiNG NsTWORK

INTERFACSE

6. PROCESSING- PLAYER TRACKIN.G

INTERFACE

PROCESSING CA-RD INSE TIrON B. PLAYE R TRACKING

MODULE

1. POWE R UP PRtOCEDURE 2. PROCESSING DCN INTEmr-ACE 3, PROCESSING DisPLAY

UPDATE

4. PROCESSING BEZE L UPDATE 5, PROCESSING

CARD'READER

C. FLOOR

CONTROLLER

1. POWER UP PROCEDURE 2. MESSAE

PROCESSING

3. ASSIGNING GAMIlNG D~viCE

ADDRESSES

-11

O

S4. SYSTEM MONITORING

;Z

BONUS CONTROL 00 Ill. PREFERRED EMBODIMENTS OF THE PRESENT INVENTION n I1. SYSTEM ORGANISATION A. SYSTEM OVERVIEW A system for operating a plurality of gaming devices is shown generally at 10 in Figure 1. The system, hereinafter described, monitors and reconfigures a plurality of gaming devices or machines 12-16 and 22-26. The system includes the following capabilities: remote reconfiguration, accounting data extraction, integrated player tracking, and cashless play. Remote configuration includes sending a reconfiguration command from a host computer to one or more of the gaming devices. The gaming devices, on receiving a reconfiguration command, will reconfigure its jackpot payout schedule in accordance with the reconfiguration command.

This reconfiguration, in the preferred embodiment, comprises activating a bonus payout schedule. This bonus payout schedule is in addition to the normal pay table of the gaming device. This bonus payout schedule provides for additional bonus payouts in addition to the payouts specified by the device's normal pay table. The difference between the two may be important for regulatory reasons.

For example, in the United States of America, the composition of the pay table is subject to regulation by the various state gaming commissions while the bonus payout schedule is not. The preferred embodiment currently activates only the bonus payout schedule responsive to the reconfiguration command, while not altering the payout table. The invention, however, is not limited to activating only the bonus payout schedule. Other embodiments, which would be subject to regulatory approval, could modify the device's payout table. The preferred embodiment, however, does not.

The system, implements a variety of bonusing events through this reconfiguration process. These bonusing events include: a multiple jackpot ;wherein the gaming device reconfigures its payout to be a multiple of its default payout schedule; a bonus jackpot wherein the gaming device reconfigures its payout schedule to payout an additional bonus amount when certain conditions are met; and a progressive jackpot wherein two or more N gaming devices are combined in a progressive jackpot having a progressive jackpot payout schedule.

The system also provides for integrated player tracking and accounting data extraction. The system 10 provides for player tracking and accounting data extraction over the same network. The player tracking allows the casino to run certain promotional events. The integrated player tracking and accounting data extraction also allows the system to support cashless play wherein a credit is given to a player over the network.

The system 10 includes one or more floor controllers 18 and 28.

Each floor controller supports up to a predetermined maximum number of gaming devices. In the preferred embodiment of the system 10, each floor controller can support up to 1024 gaming devices. The preferred embodiment of the system 10 also supports up to eight floor controllers.

Thus, the system 10 can support up to 8192 separate gaming devices.

The system supports a multiplicity of various gaming devices. The gaming devices 12-16 and 22-26 shown in FIG. 1 are the type having a pull handle for initiating a game, slot machines. However, the invention is not limited to such gaming devices. The gaming devices shown in FIG. 1 can also be gaming tables or push button operated machines as well, e.g, video poker. As will be described hereinafter, the system supports any gaming device providing traditional discrete O connections, coins-in, coins-out, etc., as well as those having serial interfaces, as described below.

The floor controllers 18 and 28 are, in the preferred embodiment of OO the system 10, IBM-compatible personal computers. Each floor controller is responsible for monitoring the activity level of the corresponding gaming devices connected thereto and issuing commands to the associated gaming IN devices to reconfigure their payout schedules during certain bonusing Sevents. The floor controllers issue status requests to each of the individual I gaming devices to determine the activity level of each. In the event the floor 0 10 controller detects any activity, the floor controller communicates that activity to a file server 32, which is connected to the floor controllers via a high speed network 38 connected therebetween.

In the preferred embodiment of the system 10, the file server 32 includes a high performance personal computer or work station having a large hard disk capacity in order to store the gaming device activity therein.

In the preferred embodiment of the system 10, the high speed network 38 is a ten megabyte ethernet network. The system 10 also includes commercially available network software to support the industry-standard ethernet network 38. An example of such network software is Novell network software sold by Novell of Provo, Utah. The file server 32 also includes a database program by which reports can be generated using the data stored on the file server. Such reports include, e.g. area, model, denomination and summary reports. The database software also allows a user to generate custom reports. The database software is based on the industry-standard Paradox database language.

The system 10 also includes a pit terminal 34 which is also connected to the ethemrnet network 38. The pit terminal 34 is also a standard personal computer, in the preferred embodiment, and can be used to monitor the gaming device activity in the pit. This terminal 34 Oil)Can also be used as a security mnonito'ring device to -detect any unanticipated events like MLs or payouts.

00p 00 The system 10 further includes any number of fill and Jackpot processing terminals 36, Tlhese terminals 36 are placed in the cage and/or the change booth areas of the casino -for fill and hand-paid jackpot processing. When a fill is required, a floor person goes to the nearest Cl cashier's boothi and states the ga~ming device number requiringn aill. The IND booth attendant enters the number in-to the fill and jackpot processing Cl terminal 36 located in the cashier's boothi. The terminal 36 then looks up the record associated with the particular gai.ning device in the ile server 32 to determine the correct fll arnount. The terminal 36 also calculates a theoretical hopper balance for the particular device based on the latest meter information, as described further below. If the calculation shows a, sincant. hoppe alanrea -Warning is given. on the computer screen from which security can then be alerted.

A -fill and jackpoL processing termiinal -36 prints a fill ticet upon deinmand. If the calculated hopper balance was nearly zero, the terminal.

36 cause the words "compuerverified" to be printed on the ticket in place of a supervisor's signature. In the event that the calculated 'hopper .0 balance was not near zero, an extra signature is required to complete the fill transaction. The system follows a similar procedure for processing hand-paid jackpots.

A dispatch station (not shown) can also be included in the system.

The dispatch station allows the casino to monitor activity on the gaming.

devices and "run the casino" from one location. The dispatch station allows the dispatcher to monitor customer service, maintenance, and security events and direct other casino personnel to handle these situations appropriately. For example, during hopper empties (fills) and jackpot events, as indicated by the dispatcher station, the dispatcher could radio down to the floor to have someone verify the event. The O dispatcher station can also indicate when a machine door is opened without a technician 0 card inserted, for example, in which case the dispatcher could take the appropriate course of action.

;The above-described system 10 is but one embodiment of a system in which the oO 5 method according to the invention has application. The system tasks can be allocated in a variety of ways amongst the system computers including floor controllers 18 and 28, file server 32, pit terminal 34 and fill and jackpot terminals 36. In some cases, the pit 110 terminal 34 and fill and jackpot terminals 36 can even be eliminated and their tasks In q allocated to the floor controller or file server. In fact, because the file server 32 is N 10 essentially a virtual hard disk for the floor controllers 18 and 32, the floor controllers and

INO

the file server can be considered a single host computer for the system B. DATA COMMUNICATION NODE 1. OVERVIEW In order to communicate with the floor controller, each gaming device includes therein an electronic module 40, as shown in FIG. 2. This module 40 can be inserted into a variety of pre-existing gaming devices. The module allows the host computer to uniquely identify the gaming device on the network, including the device type. The module 40 includes two main subcomponents: a data communication node 42 and a player tracking module 44. The data communication node 42 keeps track of the coinsin, coins-out, coins to drop, games played, jackpot occurrences and other related functions of the associated gaming device. The player tracking module 44 keeps track of the player that is playing the associated gaming device. Together, the data communication node 42 and the player tracking module 44 allow the floor controller connected to the associated gaming device to monitor and control the activity of the gaming device. The system hereinafter described in detail includes the following capabilities: slot accounting, player tracking, bonus jackpots and cashless play.

01) 2. CoNRo.LLE AND MwmOIY The data, cormmunicatioxi node (DCN) 4.2 includes a data 00 connunica Lion node controller 4.6, which in the preferred em.-bodiment, is an I-ID16473258PIO controller mnanufactured by Hitachi of Tokyo, Japan.

S. The 1JCN 42 is coupled to the player trackinig controller 44 through bus interface logic 45. The bus -interface logic 451is conventional Interface logic including, for example, transceivers, as is known in the art of digital design.

A memnory 48 is connected to the DON controller 46. The memory includes programn memory for storing programn instructions for the DCN controller 46. In the preferred embodiment, this programi memory includes a nonvolatile read-only memory (RfOM). H-owever, this program memory c ould also be flash or -battery" backed RAM in order for the p~gtain~flem 4rb~ patedb the floor con trollr -In the event flash is or 'bttery back RW is u-se- the for !ontro-ler, wo. ld download the updated program. to the D CN. controller and the 0ON controller would overwrite the program memo-ry with the down lqaded program.

The memnory 48 also includes systemn memory,.e.g., static randomaccess mnemory (SRAM) for storing the ga-ming device information. This 2o gaming device information includes at least the following mieters: coinsin, coins-out, coins to drop, gamnes played, jackpot occurrences.

A

separate meter counter is kept in memory 48 for each of these Values. To increase reliability of the data, in the preferred embodiment, a redundant set of these counters is kept in a physically separate memory device within memory 48. Moreover, the memory devices storing these counters aire nonvolati le so that in the event of a power failure the counts will be retained. The nonvolatile memories can either be battery-backed

SRAM

or electrically erasable programmable read-only mnemory (E EPROM).

Although muemory 48 is shown external to DGN controller 46, much if not all of the mnemory 48 car) be included in the DCN controller 46.

00 3. Th owO1U INTr-.tF-ACE, The data com-muflication node 42 alzo Includes a network taterface 49 for connecting the data cormrunicat1ofl node 42 to the associa ted floor controller. The network interface is coupled to the floor controller through a personality board 202, described below.

A mnore detailed drawing of n etwork interface 49 is shown in FIG.

3. In FIG. 3, the DCN controller 46 receives data from the floor controller over conductor 52 which is optically isolated from a connector 51 by optical isola tor circuit 54. The IDGN controller 46 transmits data to the .0 floor controller ove~r conductor 5.6, which is optically isolated fromn the connector 51 by optical isolator circuit 58. Each of the opto-isolator circuits 54 and 58 include an opto-coupler as are known in the art. A bus.

222 (FIG. 2) is connected be tween the network interface 49 and the persivrnality board 2-02.

4. .SE1--AL~ MAC1N MU, RFC1 Referring to. FIG. 2, the daO~ cornmunica tion node includes a serhd.

mnachine interrace 60.. The serial -machine inter-fate, 60 allows the'data COT1Mmunication node 42 to corxnunicate with the associated gain device advance serial interface as contra-sted with the discrete interface, to be de cribed further hereinafter. A bus 224 (FIG. 2) connects the serial mnachine interface 60 to the associated gamiing device at coonnctor 62. The serial interface, in the preferred ernbodiment, is a standard

RS-

232 three wire interface.

Referring to FIG. 3, the DCN controller 46 receives data from the gaming device over conductor 64 which is connected between the DCN controller 46 and a differential to single-ended converter 66. The iDCN controller 46 transmits data to the gaming device over conductor 68 connected between the DC~N controller 46 and the converter 6.6. The converter 66 converts the differential input.-, o~f the serial interface 62 to a single-enided output which is transmitted over conduc tor 64 to the DCN 01) -controller 46. The converter 66 also converts. the single-en-ded iput received -from -the flON controller 46 to a differential output signal and 00 transmits that to the seria interface 62. The serial machine interface i.% the means by which the DGN controller communicates certain reconfiguration data, referred to as reconfiguration commands, to the machine. These reconfiguration commands cause the machines to activate a bonus payout table to allow the miachine to append bonus payments to their standard jackpot payouts, as specified by their Payout -table, during certain bonus activities.

,105.- SERIAL DISPLAY INrE RFAcE The data coinmunication node 42 further includes a serial display interface 70 illustrated in more detail in FIG. 3. The serial display includes logic coupled between the DCN controllecr 46 and an) expnsiflcontecor71 ]The. expansion connector 71 allows the DCN I'S con troller 46 to commiunic ate with an expansion de'vice connected thereto.

6. DISCn11117 MIAINE

INTERFACE

The data communication node 42 also includes a discrete machiine interface 72, which is shown in detail in FIG. 4. The discrete machine interface 72 includes a plurality of op to-coup 1 ers 78 coupled between the so discrete outputs fro-m the gaming device or machine and the DCGN controllexr 46. The discrete outputs of th~e machine are received at terminals 74A-74J of a connector 74 via a cable (not shown) connected between the machine and the connector 74. The discrete outputs are coupled to corresponding inputs 76A-76J via opto-cou ipiers 78. The discrete outputs from, the m-achine include: an EXTRA signal, a POWER signal, a COIN IN signal, a COIN OUT signal, a COIN DROP signal, a JACKPOT signal, a HANDLE signal, a TILT signal a SLOT DOOR signal, and a DROP DOOR signal. Each of these signals correspond to a known event in the machine. For example, when a coin is dropped in the mnachine a COIN IN signal appears on terminal 74C. This COIN IN ;Z ~Signal is then transtnifted. to the DON controller 46 on line 760C -via the associated opto-coupler.

All of the signal lines 76A-76J include a puilup resistor nT puildown capacitor, which combined form an RC0 network on the associated line. The resistors are, in the preferred embodiment, in the formi of a resistor pack 80 and the capacitors are individual discrete capacitors 82. Alternatively, t~he capacitors can be removed for highspeed signals-.

7. MACImNQE CONFICI.JRM1ON

CIRCUIT

The data communication node 42, as shown in FIGS. 2 and 3, further includes a 'machine configuration circuit 84. In the preferred embodimecnt, as shown in FIG. 3, the machine configurration circuit 84 includes a parallel to serial converter 86, which includes eight parallel in puts Why a serial input SIN, rl cloc input OLK, a strobe in-put STB3, and a serial oupu SQ3 Te parallel- inpu ts IN are Connected to a personality board, as described hereinafter., to receive a unique machine configuration -number therefromn, which uniquely identifies the type of inachine that the data commnunication node is connected to. In the preferred embodiment, the machine identification number is comprised of six bits. Therefore, the two remaining parallel inputs can be used to provide additional inputs, such as additional discrete machine inputs,-to the DCN controller 46.

The -machine configuration number presented on the parallel inputs of the parallel to serial converter 86 is latched therein responsive to a strobe signal received at the strobe STB input. .A strobe input is generated by the DCN controller 46 On conductor 90 which is coupled to the strobe s'minput. The parallel data is clocked out of the converter 86 to the DCN controller 46.on conductor 88 and connected between the serial output. SOUT of the converter 86 and an input of the DOCN controller 46 responsive to a clock signal received on the clock input CLJK

IO

of the converter 86. The dock signal is generated by the DON controller S46 and is transmitted to the converter 86 via conductor 92 which is 00 coupled between an output of the DCN controller 46 and the clock input CLK of the converter 86.

The converter 86 also includes a serial input SIN for receiving serial In input data. The serial input SIN is coupled to an expansion terminal 94C 8 of expansion connector 94. Conductors 90 and 92 are also coupled to the S expansion terminal 94 to provide the clock and strobe signals thereto.

O The expansion terminal 94 therefore provides the means for the DON to controller 46 to access additional serial information through the parallel to serial converter 86. In the preferred embodiment, the parallel to serial converter 86 is part number 4021 manufactured by Toshiba Corporation of Tokyo, Japan.

C. ,PLAYER Ra CING IODULE

OVERVIEW",

Referring again to FIG. 2. the module 40 coupled to each of the gaming devices includes a player tracking module 44. The player tracking (PT) module 44 includes a player tracking controller 98, a card reader 100, a serial display driver 101, a display 102, and expansion interfaces 104 and 106. The player tracking controller 98 communicates with the data communication node controller 46 through bus interface logic 110. The DCN controller 46 and PT controller 98 maintain a smaster-slave relationship, respectively. Therefore, all communication is initiated by the DCN controller 46. The bus interface logic is conventional logic and its design is well-known in the art of digital electronics.

In the preferred embodiment, the player tracking module 44, with the exception of the card reader 100 and the display 102, resides on a single printed circuit board, while the data communication node 42 resides on a separate printed circuit board. The player tracking module 44ad the data communicationriode 42 are then connected by a cable III such as a ribbon cable- 00 2. SERIuAL DISPLAY GCICUIT A more detailed drawing of the player tracking module 44 is shown in FIG. 5. In FIG, 5, the serial display circuit 101 includes a transistor Q1. and a resistor R1 connected to the base thereof. A conductor 112 is3 connected between the PT controller 98 and the resistor RI to provide a drive signal to transistor QI. The drive signal causes transistor Q1 to conduct ai current. and thereby drive a display connected to the collector of Q1 at a terminal 114 of a connector 115. In the preferred embodiment, the terminal 114 is connectable to a small vacuum florescent display-to Provide serial display data thereto.

3. SE MAL EXPANsioN PonTs The: pyer: txzaelfl mrQ4l 44 Jals ludes. two serialI expansion ports 104 and 106. Eachi of the: expasion por t s 104 and 106 includes 3: differential to single-ended con-verter 116 and 11., respectively. In the preferred embodiment, these convyerters 116 and 118 are part number LTC49O manufactured by Linear Technology Corporation of Milpitas, California. The PT controller 918 communicates with each converter via two single-ended, serial signal lines: an. input signal line and-an output signal line. The converters convert the single ended signals appearing on these lines to differential signals. The differential signals, however, can -be used as single-ended signals as is known in the art. The first expansion port -104 interfaces the player tracking node 44 with a large 2r vcu firsetisly 102 (FIG. 5) used to display player tracking mnessages, as described further below. rThe display is 6.0nnected to the connecter 115, in the preferred embodiment, by a czble 103. The other expansion ports 106 provides the player tracking module with future expansion capabilities to support additional' features.

4. CA=R READER~ Referring now to FIGS. 6 and 7, the card reader 100 will now be 00 described. FIG. 6 shows the electrical schematiefor the card reziderwhile F3IG. 7 shows the -mechanical drawing thereof. In-FIG. 7A, in exploded view of the card reader is shown. The card reader includes a plastic bezel, 116 having a card reader opening 118 formed therealong for eevnga card 120 therein- The bezel'116 includes guide rails 122 and 124 disposed at opposite, respective lateral ends of the opening 118. The guide rails Cl 122 and 124 have stops 126 and '128, respectively. The guide rails 122 AD and 124'guide the card 120 through the opening .118 until an end of the card 120 contacts stops 126 and 128. The card is shown fully inserted-in.

FIGS. 7B and 7C with the end of the card 120 abutting the stops 126, 128.

The card reader also includes a printed circuit board 130 having a lgI ttdioaI. openi to allow the gutide rails 122 and 124 to be inserted therein in order to allIow the pinted circui.dt -board 130 to be pushed up.

flush against a mounting plate 132 of the bezel 116, as shown in FIGS. 7B and 7C. Mounted on one side of thte printed circuit board 130 is an array of photodiodes 134 and an array of photodetectorS 136. -The photodiodes 134 are mounted on the printed circuit board along on~e side' of the opening in the printed circuit board, while the photodetectors 136 are mounlted on the printed circuit- board along an opposite side of the opening. The photodiodes and the photodetectors are vertically aligned in a one-to-one relationship, one photodiode for each photodetector.

In the preferred embodiment, the array of photodiodes includes eight individual diodes spaced equidistance along the opening in the printed circuit board 130. The photodlodes 134 are miounted along the opening in the printed circuit board 130 so as to align with separate rows Of openings in the card 120, as described further below. The card reader also includes optional light masks 13:8 and 140. The light mask 138 is associated with the array of photodiodes 134 and has a plurality of

IO

0 openings therein, each opening corresponding to an individual photodiode in the array 134. Similarly, light mask 140 is associated with the array of photodetectors 136 and also has one opening for each of the 00 photodetectors. The light mask 138 is mounted on the printed circuit board 130 beneath the array of photodiodes 134 along the opening in the Sprinted circuit board 130. The light mask 138 is aligned with the Sphotodip des 134 so that the openings in the light mask 138 are directly beneath a corresponding photodiode in the array. The light mask 138 minimizes the amount of light emitted by a photodiode that can be S o10 detected by a photodetector other than the corresponding photodetector.

The light mask 140 is mounted on top of the photodetector array 136 so that the openings therein align with the individual photodetectors. The light mask 140 further eliminates extraneous light from the photodiodes as well as extraneous ambient light.

Also mounted on the printed circuit board 130 are a plurality of light-emitting diodes 142, as shown in FIG. 7C in broken line. The lightemitting diodes are mounted on a side of the printed circuit board opposite the side on which the photodiodes and photodetectors are mounted on. The light-emitting diodes 142 are mounted around the perimeter of the opening in the printed circuit board 130 and are received Sin a recessed portion 144 of the bezel 116. The light-emitting diodes 142 comprise a means for providing visual feedback to a user inserting a card 120 into the bezel 116, as described further below. In the preferred embodiment, the light-emitting diodes 142 are dual light-emitting diodes capable of producing two primary colors and a third combination color.

Referring now to FIG. 6, an electrical schematic of the card reader is shown. The'schematic includes the array of photodiodes 134 disposed along one side of the card reader opening 118 and the array of photodetectors 136 disposed along the opposite side of the opening 118.

In the preferred embodiment, there are eight photodiodes and eight 01) corresponding photodetectors. The phoLodiodes are arranged in pairs, with the two photodiodes within each pair being connectedinaeri 0_ fash ion. The anode of the first photodiode in the pair is coupled to the supply voltage through resistor, while the cathode of a second photadiode in -the pair is connected to an output of a driver circuit 144. The driver circuit, in the preferred embodiment, includes two open collector inverters connected in parallel. A signal lis provided to the driver circuit 144 by the PT controller 98 over a conductor 146. A signal on conductor .146 causes the driver -circuit 144 to conduct current and thereby actuate the .0 photodiodes 134 substantially simultaneously.

The photodetectors 136 are -comprised of a- plurality. -of ligh~tsensitive phototransistors PDI-PD8. Thie emitters of the photo transistors PD1-PDB are all coupled to gr-ound. The collectors of phototr-ansistor PD1 and 'PDS aremannected togzether and to a con ductor 148 by which the PT is con3trollIer 98 8 enses light dtce yehrpototran'siitor FP91 or PDB.

Phototransistors Pfl2 and.P1)7 arn sirailarly connected withi the collectors of each being. connected -to a conductor 150- The collectors or.

ph-ototransistors P1)2 and PD6I are also commrronly. connected to a conductor 152. The collectors of the center phototransistors P6 and 120 PD5, however, are connected to separate conductors 156. and '154, respectively. Also connected to each of the conductors 148-156 is a corresponding pullup resistor. In the preferred embodiment, the pullup resistors are included in a resistor pack 158. Each of the conductors 148- 156 are connected to a connector 170, which is coupled to the PTP controller 98 as described below.

Based on the a bove configuration of the phototransiStors PD1 and P1)8, only five conductors are required to sample all eight of the phototransistors. Without more information, however, -the player tracking controller 98 would be unable to determine which of the two phototransistors commonly connected to a particular conductor, e.g., conductor 148, detected light. For example, if either phototransistor PD1 eq or phototransistor PD8 detect light, the voltage level on conductor 148 Swill drop from a high voltage of approximately 5 volts to a low voltage of 00 approximately 0.7 volts. Without more information, the player tracking controller 98 would be unable to determine which of the two phototransistors, PD1 or PD8, actually sensed the light.

In However, the card 120, as shown in FIG. 7A, includes a first slot 150 by which the PT controller 98 can determine which of the two photodetectors detected the light, as described below.

The card 120 includes five rows of slots 152-160. The rows of slots 152-160 are arranged in a matrix with the corresponding slot locations within each of the rows being aligned in columns. Only the first slot 150 of row 152 cannot be aligned with any other slots, slot 150 is in a column all by itself. The individual slots within the rows of slots 152- 160 encode unique player tracking information. Each slot represents a single binary bit in the player tracking information. Either one of two conventions can be used to encode the information. First, a slot can represent a binary 1 and no slot can represent a binary 0. Second, a.slot can represent a binary 0 and no slot can represent a binary 1. The player tracking information can include: a unique player identification number, the casino issuing the card, player membership information, etc.

In the preferred embodiment, the card includes five rows of slots each having a maximum number of nine individual slots, thereby producing 45 possible slots. The first row of slots 152, however, is not used to encode player tracking information, but instead is used to synchronize the sampling of the player tracking information by the player tracking controller 98. Thus, only 36 slots are used to encode player tracking information in the preferred embodiment. This still allows 2A36 possible combinations, which is more than adequate.

IO

0 The PT controller 98 uses the first row 152 to synchronize the j sampling as follows. The PT controller 98 continuously samples the outputs of PD4 and PD5 looking for a slot. If a slot is detected on either 00 PD4 and PD5 and no other slots are detected by any other phototransistors the'PT controller 98 determines that the detected slot must be slot 150. The PT controller 98 then continuously samples the tI output of the phototransistor that detected slot 150. Once a new slot is 0 detected by that phototransistor, the PT controller 98 then samples the IO outputs of the other phototransistors, PD1-PD3 and PD6-PD8, on O 1o conductors 148, 150 and 152 for slots in of the other rows. Thus, the PT controller 98 synchronizes the sampling of the other rows of slots to the detection of a slot in the first row 152.

It is important for the card reader to detect the orientation of the card in order to correctly interpret the player identification information is encoded on the card. The card reader detects the orientation of the card 120 by detecting the slot 150. If slot 150 is detected by phototransistor PD4, then the card reader knows that the card is in the orientation shown in FIG. 7A. In that case, the card reader knows that the player tracking information is actually being detected on phototransistors PD5-PD8, and can interpret the player tracking information accordingly. If, however, phototransistor PD5 detects slot 150, then the card reader knows that the card 120 is oriented 180 degrees from that shown in FIG. 7A. In that case, the card reader knows that the player tracking information is being detected by phototransistors PD1-PD4, and can interpret the information accordingly. The PT controller 98 can simply transpose the player tracking information sensed on conductors 148-152 depending upon the detected orientation of the card. Thus, the card reader .100 .is able to correctly interpret the player tracking information regardless of how the player inserts the card 120 into the bezel 116 of the card reader. This can be accomplished with only five

IO

1 .conductors between the eight phototransistors PD1-PD8 and the PT controller 98.

oo The card reader further includes a plurality oflight-emitting diodes 142 that are mounted on the printed circuit board 130 and received in the recess 144 of the bezel 116, as shown in FIG. 7C. The LEDs 142 are t mounted on the printed circuit board 130 so as to surround the card 8 reader opening 118 as shown in FIG. 6. In the preferred embodiment, the Scard reader includes 24 dual diodes arranged in pairs. The dual diodes have two separate diodes, each being able to emit a different primary color of light In the preferred embodiment, the dual diodes emit either red or green light. The dual diodes can also emit a third combination color if the two individual diodes in the dual diode are actuated simultaneously so that the two primary colors combine. In the preferred embodiment, thisa comiation color is approximately orange due to the 1i differences in the i siies of e rt and green light.

The dual diodes are essentially treated as two individual diodes.

The red diodes R in the dual diodes are driven by a driver circuit 162, while the green diodes G in the dual diodes are driven by another driver circuit 164. The driver circuits 162 and 164 are, in the preferred embodiment, two open collector drivers connected in parallel, as with driver 145. However, other equivalent driver circuits would be apparent to those skilled in the art.

The dual diodes are arranged in pairs with the anodes of one of the dual diodes being coupled to the supply voltage +5V and the cathodes of 2 the other dual diode being connected to the output of the corresponding driver circuit. Accordingly, the red diodes are commonlydriven by driver circuit 162, which is responsive to a signal received from the PT contro ler 98 on conductor 166. Similarly, the green diodes are commonly driven by driver circuit 164, which is responsive to a signal received from the PT controller 98 on conductor 168. Therefore, the PT controller 98 can

O

be selectively actuate the red diodes, the green diodes or both by generating the corresponding signals on conductors 166 and 168.

All of the conductors over which the PT controller communicates with the card reader, 146-156 and 166-168, are connected to a connector 170 as shown in FIGS. 6 and 7A. The player tracking module n 44 then includes a cable 172 that is connected between the connector 170 0 and the PT controller 98, as shown in FIG. SAlthough the preferred embodiment of the card reader is an optical N card reader, the invention is not limited to such. The lighted bezel can be 1o used in conjunction with any form of card reader such as a magnetic card reader, a bar code reader, etc. The method of providing visual feedback to the player herein described is a general-method which can be used with :I a plurality of cards and card readers.

is Referring now to FIG. 8, a schematic for the displa circuit 102 of the player tracking module 44 is shown. The circuit 102 includes a display controller 174, which in the preferred embodiment is a part number HD6473258P10 manufactured by Hitachi of Tokyo, Japan.

Coupled to the display controller 174 is a memory 176 via bus 178. The memory 176, in the preferred embodiment, is a 32KB SRAM. The memory 176 stores the variables and parameters necessary for the controller 174 to communicate with both the PT controller 98 and the display driver 186. The bus 178 includes the necessary address lines, data lines and control lines to interface in memory 176.

In the preferred embodiment, the display 102 includes a vacuum fluorescent display (VFD) 184, which is organized as a 16 x 192 display matrix. Such displays are well-known in the art of digital electronics.

The VFD 184 is driven by a driver circuit 186, which includes a plurality of individual drivers serially interconnected. In the preferred 3o embodiment, these serial drivers are part number UCN5818EPF-1,

NO

Smanufactured by Allegro Microsystems, Inc. ofWorcester, M assachsets- The driver circuit 186 is connected to the VFD 184 by bus 188. whbch 0 includes 160 individual conductors. The manner in which the 160 bus lines are connected between the driver circuit 186 and the VFD 184 is known in the art, and is therefore not described in detail herein.

SThe display controller 174 interfaces with the driver circuit 186 by Sa plurality of signal lines 190. These signal lines transmit the standard Sdriver interface signals to the driver circuit 186. These signals include: a clock signal CLOCK, serial input data signal SDATA, a frame signal to FRAME, a strobe signal STROBE, two output enable signals OE1/ and OE2/, a column clock signal COL CLOCK, and a column output enable signal COL OE/. These signals have well known functions in the display art and are therefor not discussed in detail. The signal names having a repesent active low signals wile al other signals are active hi..

s The display controller 174 g tes th sig s in the require a sequence in order to serially clock the reformatted display data to the driver circuit. One of ordinary skill in the art could program the display controller 176 to generate these signals in order to display the desired message on the VFD 184 based on the foregoing description.

The display 102 also includes a serial interface 192. The serial interface 192 is the means by which the PT controller 98 communicates a player tracking message to the display 102. In the preferred embodiment, the serial interface 192 includes two opto-isolator circuits: one for the serial send data, the other for the serial transmission data.

The display controller 174 is connected to the serial interface 192 over a two conductor serial bus 194, one conductor for receiving serial data from the serial interface 192, the other for transmitting serial data thereto.

A

connector 196 is also coupled to the serial interface 192. The connector 196 includes four terminals. Two of the connector terminals are dedicated to receiving serial input data and the other two terminals are dedicateid to transmitting seria data. A cable (not shown) couples the display 102 to the player tratking module 44 between connectors 1.9( 00 (FIG. 8) and connector 115 (FIG. 6. D=scR= IN~ur SE,.coN The display 102 further includes a discrete input section 198. The discrete inp-ut section 198 is an interface between the discrete outputs of C) a gaming device and the display controller 174 mxuchi in the same way IND that the discrete machine interface 72 allows the data communication node to interface with a gaining device. Although in the preferred embodiment the discrete input section is unconnected to any discrete ma-chine inputs, the discrete input section 198 allows the display iO2-to operate as a stand-alone module for gamning devices in certain coinfigurations. The discrete input section provides discrete input signals orinexternal. davice to, the di,!play con troller 174 over a bus.200. "re 1 iscrete inpu6 i~ctiorin8 i0 1de op.strruit S.U-611 as part.

number TLP620 manuifactured by Toshiba Corporatio-n of Tokyo, Japan which provide single-ended input signals to the display controller 174.

D. PERSONALITY

BOARD

Referring now to FIG. a personality board 202 is sho wn in schematic form. TPhe personality board 202 uniquely identiFies the gamning device on the network. The personality board 202 indicates the type of gamning device, slot machine or video poker, including the manufacturer, and provides a uniquenmachine identification number that the host computer can use to uniquely address the gaming device. The personality board 202 allows the de vices to be readily removed and reins talled in the network without any mianual reconfi-guration by thle operator, such as resetting dip switches.

The personality board 202 couples the data communication node 42 to a gaining device. The personality board 202 includes two connectors 204 and 206 and an identification circuit 208. The connector 204 couples

IND

'tothedaa cmmuict, n nde42, as described further below. The connector 206 connects to thle particular gamixig device. The compOnents 00 shown in F'IG. 9 are mounted en a printed circuit board that is uoun ted8 inside a connector harness (not shown). The person ality board allows the NO 5 D~CN Lo be easily removed and reinrstalled from the network with minimal effort.

The personality board uniquely identifies the machine by providing both a configurfltion number, which indicates the type of gaining device that is connected to the connector 206 and a unique identification, whbich is used by the system 10 to mnaintainl records on the Machine. The configuration number includes a six bit binary ]lumber which indicates the type of gaming device connected to the personality board 20:2. E~ach machine type is assigned a unique configuration nim'bexna thi re~i ertxbrizs encoded oh lines is which are connected to terminaiLs'204:Q-204V, respectively, of connector 204. Each line represents one bit of the binary configuration number.

The ndivdualline areeither tied to a supply voltago to representa binary one or to ground to represent a binary zero. The six bit Configuration number used in the preferred embodiment can encode up to 2 Ab6 different combinations5 and, there fore, different machine type S.

The configuration number for the embodiment shown in FIG. 9 is equal to 3C11.

The configuration lines CNFG.O-GNFG35 are coupled to the inputs of parallel to serial converter 86 (FIG. through a connector (not shown).

The terminals 204Q-204V of con-nector 204 have corresponding terminals 85Q-85V of connector 85, as indicated by corresponding lettered suffixes.

This same lettering convention is used throughout.

The configurationl number is used by the DCN controller 46 as a m-eans of interpreting the discrete input signals receiyed from the machine through connector 206. Individual conductors coupled between connect r 204 and 20)6 are labeled to correspond to the iMaChiue type having a conafiguratian number 3TH. For a differen t machine type having 00 a different configuration number, many of these conductors may have different functions. By providinig a unique configuration number, the DCN controller can interpret the signals received on these lines accordingly.

The personality board 202 also includes an identification cirut 0 INO which provides a uniejue machline identification number to the data communication node 42. The unique identification number is stored in a nonvolatile memory 2.10 and provided to a terminal 204N on conductor 1D. In the preferred embodiment, the nonvolatile memory 210 is a pqrt number DIS2224 irianuFactured by Dallas Semniconductor of Dallas, Texas.

In the preferred embodiment, the nonvolatile memory 210 includes a 32 bit:R-OMY. havingy a..factory-las-ered unique serial. number stored therein.

is This, Serial ntlxdlber ie. thel MiAchne identification nu mbe'r, can be read out of the memory 210 by the flCGN contIroller 46 to uniquely identify -the machine connected thereto. The protocol -for reading the identificatio'n number out of the memory 210, as is described in the data sheet for the part, is well known in the art.

210 The identification circuit 208 includes a number of discrete components. The memory 210 has -a Zeiler diode 212 coupled across the power and ground terminals of 213 and 215 thereof. The identification circuit 202 also includes a first diode 214 coupled between the power terminal 213 and a data output termninal 217. The circuit 208 further inlludes a second diode 216 coupled between the data output terminal 217 and the ground terminals 215. A resistor 218 is in terposed betweenl the data output terminal 217 and the connector terminal 204N. The terminal 204N is coupled to a corresponding terminal 714N of connector 7.4 (FIG. 4) by a bus 220 (FIG. 2).

O

0 The discrete outputs from the machine, coin in, coin out, etc., are also supplied to the data communication node 42 via bus 220. The 00 bus 220 connects connector 7 4 of the data communication node 42 and the connector 204 of the personality board 202 such that terminals having corresponding lettered suffixes are connected. For example, terminal 74C of connector 74 is connected to terminal 204C of connector 204 by a C individual conductor within bus 220. All the other terminals are similarly Sconnected by the bus 220.

C The network interface 49 of the data communication node 42 is also to coupled to the personality hoard by a bus 222, as shown in FIG Bus 222 includes four conductors which connects the four terminals of connector 51 with four corresponding terminals of connector 204, as indicated by the common lettered suffixes. It is over these four lines that the .)GN controer 46 indirectly comunicates with the floor controller.

is The serial machine interface 60 is also coupled to the personality board 202 by a bus 224, as shown in FIG. 2. The bus 224 includes four conductors which couple four terminals 62DD and 62EE of connector 62 with corresponding terminals 204DD and 204EE, respectively. It is over these four conductors that the DCN controller 46 communicates reconfiguration commands to the machine. The DCN controller transmits data through the terminal 204DD, which is provided to the machine on conductor MACHINE RX. The machine responds to the configuration command on the conductor MACHINE TX. The use of these two conductors will become more apparent in the description of the operation hereinbelow.

Although buses 220, 222, 224 and 226 have been described as separate buses, the individual conductors within these buses could, and are in the preferred embodiment, combined into a single bus that is connected between the data collection node 42 and the personality board 202. To connect the data collection node 42 and the personality board 202 a connector (not shown) is mounted on the data collection node 42 and a mating connector (not shown) is mounted an the personality board, 2-02.

00 The two connectors are then mated together to connect the clatacollectiorn node 42 to the personality board 202. The personality board -is then coupled to the corresponding gaming device by a cable 225 (FIG.2).

1E. BONUS DISPLAY DRIVEiRS Cl Referring now to FIG'S. 10 and 11, two bonus display drivers are shown. The data communication node 42 is designed to support either of the display drivers. The data communication niode 42 is coupled to the display driver of FIG. 10 through connector 228. An opto coupler 23.0 optically isolates the data communication node from a triac cirtuit 232.

whiich includes, a triac: 234. One terminal of the tiac 234 is connected to a terminal 236B of a coninector 236. Another terminal of the triac 234 is.

copnc'I to rnn1Z.Co onctor A bonus display sucha a light-or sound genberating m nsi cupled. ac ross eminals 236B andl 236C so tha t the triac 234 could drive the external bonus display responsive to an actuation signal froin the data communication node 42.

A second embodiment of the display driver is shown in FIG. 11. In this emblodiment, the data coinmunicztion node 421is coupled to the driver circuit throuigh connector 238. The driver circuit of FIG. U includes a relay 240 operatively coupled to a transistor 242. The relay 240 is a twoposition relay which toggles between the two positions responsive to a current passing through transistor 242. The transistor 242 conducts a current responsive to an actuation signal received on terminal 238B from the data comimunication node 42.

The display drivers are used by the data coninUnic~tionlnode 42 to activate a display on the gaming device which indicates that the machine is now in a bonus mode or condition.

F. FLOOR CONErROLL-DR ;Z As shown in FIG. 1,.the floor controller is directly conn0eted toboth the igh pee netork38 and a plurality of gaming device. The floor.

on troller is reSPOnsibke for monitoring the activiy of eac Of the gaming1 devices connected thereto and reporting this activity to the database 32.

in In addition, the floor controller is responsible for transmitting a reconfiguration command to a selected one or more of the gaming devices during certain bonus cntir&Teeoditions will be described in detail in Lhe operation section below.

The floor controller is connected to the associated gamring devices by current loop networks. 'Because of the limitations of the current loop network, only a predetermined number of gaming devices can be supported on any one current loop network. In the preferred euibodimeflt, each current loop n~etwork supports up to 64 gamning dev ices.

Uooeo'tr~ t t p orrCthan. this pre deter 'Ifd nmeof gaming devices, each floor controller is equipped with a carn-munica~ian board 246, asshown in FIG. 12. The communication board 246 supports up to 1.6 seaaecurrent loop -networks. The board is a standard size card that fits into one of the ISA card slots in tiw back of the -floor controller. The board includes a male edge connector (not shown) which mates with a.femnale back plane connector (not shown) in the floor con trollier. The back plane connector provides. the floor controller CPU data, address, and control lines to the commnunication board 246 to enable the comnmunicationD board and the floor controller CPU to communicate.

The communication board 246 includes eight separate microcontroli ers 248A-2481-1. The microcoritrollers communicate with the floor controller through ISA bus interface logic 247 over buses 249A and 2493. The inicrocontrollers are shown in a daisy-chain connection in FIG.

12, but any other equivalent interconnection scheme can be used. The data received from the floo~r con troller microprocessor is passed between the inicrocontrollers from 248A to 248!-L as indcaebtharos ac 00 microcontroller is responsible for passing the data a-long and. determining .Whether the data includes a miessage for a machine connected to its corresponding cur-rent loop networks.

in Each mnicroc ontroller is responsible for two current loop networks.

Each microcon troller commnuni-cates with its associated gaming devices via two corresponding current loop networks. Two serial signal lines 251 connect each mnicrocon troller to a current loop driver circuit 250. The driver circuit 250 provides the necessary current drive to support the current loop network. Each pair of serial signal bles 251 has- a corresponding pair of current loop lines 253. The current loop driver circuit 250 can either be locatLed on the comnmu ni cation board as shown in FIG. i2 or on a sepa rate printed. circuit board (not shown). If located on is a separate board, the: currtt lo6oP dxi7ver crct 250 cau be connected to the commru-nica tion board'by a cable.

In the preferred ernbodimnht, the hist inicrocoo tr-oler 248H is solely responsible for communicating with the floor controller microprocessor.

Ail of the data received from the mnachiries over the various curreA loop networks are passed along to the microcontroller 248H by the associated microcontroller. The microcontroller 248H1 analyses the data and determines whether the data needs to be commuanicated to the floor controller- If not, the last mi6crocon troller records the communication but does not forward the data to the floor controller. This helps off-load some of the floor controller commrunication processing to the commiunication board.

O

cK fn. OPERATION The above-described system allows a casino in which the system is 00 installed to run promotions on any properly equipped gaming machines while simultaneously gathering player tracking and accounting data from 5 all machines. The system provides the capability for the casino to select which of the plurality of machines are used in any given promotion, The O .system further allows any number of different promotions to operate ID simultaneously.

Each promotion involves sending a reconfiguration command from the floor controller to a gaming device that has been selected to be part of a given promotion over the associated network. Upon receipt of the reconfiguration command, the gaming device reconfigures its payout schedule in accordance with the received reconfiguration command. As described above, reconfiguring a gaming device payout schedule, in the ,s preferred enbodient i:ncludes-activating a bous payout schedule that pays out bonus amounts in addition to the amount determined by the device payout table.

A partial list of the promotions according to the invention include, but are not limited to: a multiple jackpot wherein the gaming Hevice reconfigures its payout to be a multiple of its default payout schedule; a bonus jackpot wherein the gaming device reconfigures its payout schedule to payout an additional bonus amount when certain conditions are met; and a progressive jackpot wherein two or more gaming devices are combined in a progressive jackpot having a progressive jackpot payout schedule. In addition to these, many other promotions are possible by the above-described system for controlling and monitoring a plurality of gaming devices.

The system 10 also allows for improved player tracking. As with standard player tracking, the above-described system monitors and reports how many coins are played by each player. The system O however, also includes the ability to record how long each player spends at each machine and the number of coins won, games played, and hand jackpots Z won by each player. All this information is stored on the database, which can be OO later analyzed for future targeted direct mailing campaigns. The player tracking according to the system also allows the casino to schedule buses and other groups and measure their profitability. The system also allows for cashless play IN as well as advanced accounting and security features. V) Another feature of the above-described system is jackpot announcements. The jackpot announcement feature displays a message on a reader board or display located in the casino which announces a jackpot as (soon as a jackpot is won, as soon as the reels stop spinning. The floor controller generates the jackpot announcement once a DCN connected thereto indicates a jackpot is won. An example of such a message might be: "Now paying on machine 1342, a jackpot of $300." With prior art data collection systems, the amount of the jackpot is only known after the payment is made.

Even then the system must account for partial pays, hopper empty, etc.

An advantage of the current system over prior art systems is the ability to implement better tournament systems. In a slot tournament, players pay a fee to play. All play during the session is free. The players accumulate credits instead of cash. The person with the most credits at the end of the toumrnament wins. Games are usually manually altered to provide payouts of 200 to 300% to make the games more fun. The games are altered manually by replacing the read only memory (ROM) in the gaming devices.

One exciting aspect of tournament play is to see who is ahead. No current system can display this information in real time. This is because current systems can only measure winnings as they are added to the credit meter or paid from the hopper (some casinos use tournament

INO

M tokens instead). Since credits are usually added at a rate of 10 per second, a 1,000 credit win can take 100 seconds to register. Casinos attempting to 0_ create display boards showing who is ahead are frustrated by the lag time.

The jackpot announcement of the system allows casinos to display the player with the most credits by comparing the number of credits for each player. This comparison and display is performed real time as each transaction is completed.

In order to implement each of these features, the various computers and microcontrollers each execute software or firmware. This software and firmware routines are described below. These routines are described with reference to accompanying flow charts. These flow charts would enable one of ordinary skill in the art of computer programming to write a corresponding computer program which the computer or microcontroller could execute.

A. DATA COMMUNICATION

NODE

1. POWER UP PROCEDURE Referring now to FIG. 13, a power up procedure 252 for the data communication node is shown. This procedure is executed by the DCN controller 46 when initially powered up. The first step of the procedure is to validate the RAM to ensure that it is not corrupted and to set up all the DCN hardware. Validating the RAM involves writing known patterns of 1 s and Os to the DCN RAM. This RAM can either be internal to the DCN controller 42 or external as shown in FIG. 2. Setting up the DCN hardware includes initializing timers and interrupts.

Next the DCN controller checks the RAM in step 255 by reading the pattern of 1s and Os back out of the RAM to ensure that the RAM is fully functional. If the RAM turns out to be defective the DCN controller goes into an endless loop in 256.

IO

bD 2. READING UNIQUE IDENTIFICATION NUMBER If the RAM is' fuy functional, the DCN then reads the unique identification number from the personality board. As described above, this unique identification number is stored in a nonvolatile memory. 210 s on the personality board. Reading the unique ID number out of the t nonvolatile memory involves following the memory manufacture's Sinterface protocol as specified in the nonvolatile memory data sheet. The 0 unique identification number provides a means for uniquely identifying the gaming device.

o1 After the unique ID has been read from the personality board, the DCN processes the discrete machine inputs in step 260. This step will be described in further detail in Subsection 3, MONITORING GAMING

DEVICE

DISCRETE INPUT below. After the discrete inputs have been processed in stp 20, the DCN processes the machine serial interface in step 262.

is This step is described further belo in Subsection 4,PRoCIassING

GAMING

DEVICE SERIAL INTERFACE. Next, the DCN processes the network S interface, the interface between the DCN and the floor controller connected thereto. The process network interface step 264 is described further below in Subsection 5, PROCESSING NETWORK INTERFACE. Finally, the DON processes the player tracking interface in step 266. This step is described below in Subsection 6, PROCESSING CARD INSERTION.- At the completion of step 266 the DCN loops back to step 260 and continuously, sequentially executes steps 260-266.

3. MONITORING GAMING DEVICE DISCRETE INPUT Referring now to FIG. 14, the DCN step of monitoring the gaming device discrete inputs 260 will now be described. The DCN first reads the discrete inputs on input lines 76 in step 267. One particular set of discrete inputs is shown in FIGS. 4 and 9 for a particular gaming device.

The actual discrete inputs present will depend on the machine type, as indicated by the configuration number, which is also read by the DCN controller 46. Most gaming devices provide at least some of the following discrete inputs: coins in, coins out, coins to drop, games payed, attendant Spaid jackpots, slot door, drop door, progressive jackpots, and bill validators. The system supports all of these discrete inputs as well as others.

t The DCN keeps track of the machine activity by maintaining Sseveral meters in memory. Each meter, in the preferred embodiment, includes six digits. Moreover, to improve the reliability of the system, c- the DON maintains redundant backup copies of these meters with an o0 order to replace the original meters in the event that the originals are corrupted. In step 268, the DCN increments the meters as required based on the discrete inputs. The meters are maintained even in the event that the DCN is disconnected from the floor controller. Once the DCN is reconnected to the floor controller, all the activity level information is then available. Step 28 will discssed further below.

Next, the DCN processes the drop door signal in step 270. The drop door signal DROP DOOR indicates that the drop door on the machine has been opened. This is an important event and is therefore processed separately.

In step 272, the DCN validates the meter values to determine whether the values stored in the meters are valid. The DCN checks whether the meter values are valid in step 274. In the preferred embodiment, a check sum is maintained for each meter value. Thus, the DCN in step 274 checks to see whether the check sum is correct based on the current meter value. If the meter values are okay, the discrete input monitoring step 260 is complete. If the meter values are not valid, the DCN replaces the meter values with the redundant back copy of the meter values in step 278, and then the step 260 is complete.

Referring now to FIG. 15, increment meter step 268 is shown in further detail. The sequence shown in FIG. 15 is repeated for each meter

O

value that has changed. The first step is to adjust the meter value based on the discrete inputs and to calculate the associated check sum. Next, 00 the DON determines whether the particular meter has an active associated countdown count in step 282. Some games or promotional D activities require the player to reach a certain level of activity in order to be eligible for certain bonus points. These countdown counts are used to determine whether the player..has achieved this level of activity. For example, the player may be required to play a certain number of coins before being awarded any points. If the countdown count is active, the DCN adjusts the current players count down values in step 284 based on the corresponding adjustment of the associated meter.

In step 286, the DCN sets the current message to the count down message. The count down message indicates to the player when he or she willbe .ible for the. onus points. Finally, in step 88 the DCN sets the 1s current bezel color and rate to a count down color and rate. This color and rate information is subsequently transmitted to the player tracking node for processing, as described further below. The countdown color indicates the bezel color and the count down rate indicates that flashing rate of the bezel color displayed during the count down message.

4. PROCESSING GAMING DEVICE SERIAL

INTERFACE

Referring now to FIG. 16, a process 262 for processing the gaming device serial interface is shown. The serial machine interface 60, as shown in FIG. 2, allows the DCN controller 46 to communicate with the gaming device through the personality board. This serial machine interface allows the DCN controller 46 to transmit reconfiguration commands to the gaming device in order to reconfigure the payout schedule of the machine in accordance wi th the reconfiguration command.

In addition, the serial machine interface provides an additional means for determining the activity level of the gaming device. Instead of reading the discrete machine inputs, the DCN controller 46 can transmit a status 1

O

request command to the machine over the serial interface and the machine can respond back with the requested status information.

o Any communication protocol can be used to implement this communication path over the serial machine interface, as is known in the s art. An example of one such protocol uses a data packet including a Scommand code, a message sequence number, a CRC, and a variable 8 length message. In the preferred embodiment, either the DCN controller g 46 or the machine-can initiate co m m unications over the serial machine Sinterface. However, if the machine detects that the DCN is trying tosend to. a message to the machine, the machine must abort its message and attempt to resend the message at a later time.

The preferred embodiment of the system supports many different reconfiguration commands. A partial list of the reconfiguration commands is given below in Table 1. These reconfiguration commands are sent from the DCN controller 46 to the machine over the serial machine interface wherein the machine reconfigures its payout schedule in accordance with the particular reconfiguration command. Ihe reconfiguration commands do not originate with the DCN, instead the reconfiguration commands originate from the floor controller and are 2o transmitted to a particular machine over the associated current loop network or the command can originate at one of the other computers on the high speed network. The DON is simply responsible for forwarding the reconfiguration command onto the gaming device on receipt of the reconfiguration command over the associated current loop network a coupled between the floor controller and the DON.

Table 1 Examples of Reconfiguration Commands 1. Bonus Pay From Hopper (Coin Format) 2. Bonus Pay to Credit Meter (Coin Format) 3. Bonus Pay from Hopper (Dollar Format) 4. Bonus Pay To Credit Meter (Dollar Format)

(O

0 5. Add Non-cash outable credits to Game S6. Begin Double Jackpot Time oO 7. Stop Double Jackpot Time s The actual process of processing the machine serial interface begins in step 292 wherein the DCN polls the machine to determine its level of "activity. This polling step includes sending a status message from the DON to the machine over the serial machine interface. In response, the \N machine will send a packet of status information indicating the current 0 1o amount of activity on the machine. The status information included in the response will depend on the type of machine that the DON is communication with.

The data communication node 42, in step 294, waits for a reply to the status request. If a reply is received, the DCN indicates that the machine is "on line" in step 296 and processes the machine reply in 298.

The step of processing the machine reply includes updating the meter values, as done when processing the discrete inputs. After the machine reply has been processed, the process 262 is complete.

If the DCN does not receive a reply from the machine in step 294, the DCN indicates that the machine is "off line". The DCN will wait for a predetermined amount of time before deciding that the reply is not received. In the preferred embodiment,..this predetermined period is approximately 110 milliseconds.

PROCESSING NETWORK INTERFACE Another step in the DCN power up procedure 252 is the step of processing the network interface 264. This step is described with reference to FIGS. 17-19. The network interface refers t9 the current loop that connects the particular DCN with the associated floor controller.

The following description assumes that the DCN has received a valid message from the associated floor controller. Because there are multiple

IO

SDCNs connected to anyone current loop, the floor controller must include some means for addressing a particular machine.

o0 Although each machine includes a unique identification number which could be used as the actual address for each DON on the current loop, it is unnecessary to use the unique identification as the actual address because there are only a limited number of DCNs connected to 8 each current loop. Accordingly, in the preferred embodiment of the invention, the floor controller uses a shorthand token representation of the DCN's unique identification number to address the DN. In the preferred embodiment, a single byte address is used to address a DCN on any given current loop. This one-byte address allows up to256 DCNs to be supported on any given current loop network. In the preferred embodiment, however, only 64 such DCNs are connected to a single current loop and therefore the single byte address is more than adequate.

s1 The single byte address substantially reduces the amount oftraffi on the current loop network by reducing the number of bytes from four in the unique identification number to one for the shorthand token representation.

The floor controller is responsible for generating the uniqu~ single byte address for each data communication node on a given current loop network. The process of assigning unique single byte addresses to the DCNs is described below in Section

C.

Once all the DCNs have been assigned a unique address, the DON can begin monitoring the current loop network for messages addressed to it. If the DCN detects a message addressed to it, the DCN executes step 264. The DCN first checks to see whether the message is valid in step 304. This check is done by computing the CRC value ofthe message and comparing it to the CRC included with the message. If the two CRCs match, the message is valid and the DON processes the network message 3o in step 306. Processing the network message is described further below

IO

Swith reference to FIGS. 18 and 19. Once the message has been processed, the DCN sends a reply back to the floor controller over the current loop 00 network in step 308. The actual substance of the reply will depend on the message received in step 306. If the message is invalid, the DCN does not reply.

i Referring now to FIG. 18, the first step of processing the network S'message is to determine what type of message was sent from the floor ND controller in step 312. There are three basic types of messages that the Ofloor controller sends to the DCN. The first is a request for data from the o1 DCN. If this type of message is detected the DCN builds the data requested and transmits the data in a reply message. The main use of this message type is to gather status and meter information from the

DCN.

Another type of message is one including configuration data for the s1 DCN. This message allows the floor controller to implicitly set the DCN's memory to a fixed value. This message is used to override the DCN's internal variables, to get a DCN out of a lock-up condition, or to download new firmware to the DCN for execution. On receiving this type of message, the DCN simply overwrites its memory with the confighration data included in the configuration message in step 316. The DCN then builds an appropriate acknowledgment and transmits this acknowledgment message to the floor controller in step 320.

The other type of message is one sent in response to a DCN request.

The DCN processes this data in step 318, which is described further in FIG. 19. If the message includes either the configuration data or the data in response to a DCN request, the DCN builds an acknowledge message in step 320 and transmits this message to the floor controller.

The step ofprocessing a floor controller message sent in response to a DCN request will now be described with reference to FIG. 19. The first step of processing this type of message is for the DCN to determine what

NO

bJ) type of data is included in the message. Once again there are three types of data that can be included in this message type: a reconfiguration 0 0 command, card data, or other minor data. The DCN makes this determination in step 324 by analyzing one of the bytes in the data p.acket of the message. This byte will be referred to herein as the command byte.

S ,If the command byte indicates that the message contains reconfiguration 0 data, the command byte equals a reconfiguration command, the DON stores the reconfiguration data in a predefined data structure in memory.

0 Listed below in Table 2 is an example of a data structure for storing the io reconfiguration data.

Table 2 Reconfiguration Data Structure 1. Bonus Type 2 Mystery Jackpot Data: Nuber of oins to a0warrd B. Number oseconds tu award C. Pay award to 3. Bonus Time Data A. Jackpot MuPtiphier o2 B. Jackpot Payout Limitations C. Number of Seconds to Keep Bonus Time Active D. Minimum Activity Level The bonus type field of the data structure indicates the type of bonus state the machine is to be placed in. Examples of potential bonus modes include progressive/nonprogressive, multiple jackpot, or mystery jackpot. If the mystery jackpot is indicated, the mystery jackpot data included in the structure specifies the conditions under which the mystery jackpot is paid out. The mystery jackpot can be set to payout, after a certain number of coins in, handle pulls, which is specified by subfields of the mystery jackpot data.

The bonus time jackpot is a promotion wherein the machine pays out more than that dictated by its default payout schedule. In one b embodiment of the bonus time promotion, the payout schedule of the machine can be modified to be a multiple of its default to payout schedule, 00 as specified in subfield of the bonus time data. This promotion can be used to encourage gaming activity during off-peak hours, midnight 1 5 to 4 a.m. on weeknights. Alternatively, the bonus time promotion can be activated on a random basis. The timing of the multiple jackpot is specified by the casino on one of the computers connected to the network.

ND The bonus time data also specifies the conditions under which the player 0 becomes eligible for the bonus time jackpot. The subfield of the bonus time data specifies whether the player is eligible for the bonus time data only if the player is playing the maximum coin in the machine. Subfield limits the bonus time promotion to a predetermined number of seconds. This field limits the bonus time promotion to a predetermined n mber of seconds; ikthe player does not hit a jackpot within this 1s specified time period, the bonus time promotion concludes. The minimum activity level can also be specified in subfield This field can be used to specify the minimum activity level required by the player in order to be eligible for the bonus time jackpot. For example, the player can be required to play at least 20 coins over the last three minutes in order to be eligible for the bonus time jackpot. An indicator light on the player's machine can be used to indicate when the player reaches the minimum activity level and thereby becomes eligible for the bonus time jackpot.

In another embodiment of the bonus time promotion, a bonus amount is awarded in addition to the payout according to the default of the payout schedule of the machine. The amount of the bonus jackpot is specified in subfield of the bonus time data. For example, this bonus time promotion might include five bonus amounts of $10, $25, $50, $100 and $500, which is specified by subfield When a player hits a particular jackpot, whichever bonus amount is specified by the bonus amount subfield this amount is automatically paid out in addition to the

I_

NO

payout amount determined by the machine's default payout schedule.

00 This bonus time promotion can also be used in combination with subfields and to specify the conditions under which the player is eligible for this bonus time jackpot award.

the DCN has stored the reconfiguration data in step 326, the DON will then send the appropriate reconfiguration command to the machine over the serial machine interface in step 328. The machine, responsive to the received reconfiguration command, reconfigures its Spayout schedule in accordance with the received reconfiguration command. For example, if the reconfiguration command specifies a multiple jackpot condition, the machine will reconfigure its payout to be a multiple of its default payout schedule. The machine will reconfigure its payout schedule in a similar manner for the other bonus types.

.The other tye of data that can be. incded in a response from a s1 DCN request is card data or player tracking data. This data is sent tp the DCN in response to a status message from the DON to the floor controller wherein the status message indicates that a player card has been inserted. Included in this message is the card ID number detected Y the card reader. In response to this status message the floor controller will .o transmit a card insertion message to the DCN. The card insertion message includes information associated with the particular player

ID

number. An exemplary card insertion message data packet is listed below in Table 3.

TABLE 3 Card Insertion Message Data Packet 1. Card Identification Number 2. Player First Name 3. Player Last Name 4. Current Point Balance 5. Casino Code

\O

0

IN

;Z1 Upon receipt of the card insertion message, the DCN stores the 0 player's name and points in order for this inforation to be displayedon the VFD display associated with the player tracking node. Then, a DCN sets the current message to a data received message in step 334. Finally, S 5 a DCN sets the current bezel color and bezel rate to a data received bezel color and bezel rate in step 336. The bezel color specifies the bezel color IN to be displayed by the card reader and the bezel rate specifies the flashing.

rate of the card reader LEDs. This bezel information is subsequently transmitted to the player tracking node for processing thereby.

The final data type that can be included in the message sent from the floor controller in response to a DCN request is generically classified as other minor data. This data includes general system or DCN specific information such as display information.

PR.OC SSNG PLAYER TRACKING INTERFACE The next step in the DCN process is processing of the player tracking interface 266. .The DCN maintains a variable that indicates what message is to be sent to the player tracking node. This variable is referred to as the current message variable. Before transmitting a message to the player tracking node, the DCN first checks this variable wo to see which of a plurality of messages should be sent to the player tracking node.

The process 266 begins in 340 by sending the current message to the player tracking node that is specified by the current message variable.

In addition to the current message, the DCN sends the bezel color and bezel rate information to the player tracking node. The bezel color and bezel rate information could have been specified by the floor controller or by the DCN itself.

Next, the DCN determines the card status in step 342. If there is no card inserted in the card reader, the DCN sets the current message variable to an attract message. This message specifies that the player

O

0 O ;Z tracking node is to display a message which will attract players to e 00 machine. Similarly, the DCN sets the current bezel color and bezel rate Sto an attract bezel color and rate in step 346. This attact color and rate is part of the attract message thatwill be sent to the player tracking node 0 5 when the current message is-sent.

If the DCN determines that a good card has been inserted in the Scard reader, the DCN processes the valid card in step 350. This step is described further below with reference to FIG. 21.

If, however, the card status indicates that a bad card has been 1o inserted, an invalid card number, the DCN sets the current message variable to specify a card error message in 352 and the DON sets the current bezel color and bezel rate to a card error color and rate in 354.

This card error information is included with the card error message that is sent to the player trackI i tde' when thcurrent.=essage is sent.

7. PROCESSING CARD

INSERTION

Referringnow to IG.21, the process 350 for processing a valid card insertion is shown. The first step that the DCN executes is to determine whether the card data corresponding t the valid cardhas been receed from the floor controller in step 356. If not, the DCN builds a network request message for the player name and points associated with the card ID number in step 358. Next, the DCN sets the current messagevariable to specify a card inserted message is to be transmitted in step 360.

Finally, the DCN sets the current bezel color and rate to a card inserted color and rate, which indicates to the player that the system is still z2 processing the card number. This information is sent to the player tracking node when the current message is sent.

If the card data has been received from the floor controller, the DCN then determines in step 366 whether player tracking has started for the particular player. Ifplayer trackinghas not yet started, the DCN sets the current message variable to the data received message in step 368 and sets the current bezel color and rate to data received color and rate in step 370. If player tracking has started, the DCN processes the player tracking in step 372, as described with reference to FIG. 22.

0_ Processing player tracking 372 begins with the step of determining whether the player has received new points in 374. These points can be considered roughly as the equivalent of "frequent flyer miles" used by airlines. These points allow the system to run promotionals whereby individuals are given points or credit associated with their card that can be redeemed toward the purchase of goods or services offered by the casino.

Typically these points are redeemed at a redemption counter in the casino for meals or clothing, for example. The points, therefore, are an additional inducement to encourage play.

The player tracking system allows the casino to determine how and when the player is issued points. The casino can specify the type and number of coins that must be played before a player is awarded a given number of points. The system uses this specified information to inform the player of his or her progress towards receiving additional points. The system encourages play by informing the player of how many additional coins must be played before receiving additional points. For example, a player who is only one coin away from receiving points, but who desires to stop playing, may decide to play "one last coin" in order to receive the points. The system informs the player by displaying a message on the vacuum florescent display indicating how many coins the player is away from receiving additional points.

Referring now to FIG. 22, player tracking 372 begins with the step of determining whether the player has received new points in 374. If no new points have been received, the DCN sets the current message variable to specify a countdown message in step 376 and sets the current bezel color and bezel rate to a countdown bezel color and rate in step 378.

O

(N

The countdown bezel color and rate indicates the player's progress oO towards being awarded additional points.

If new points have been received, such as where the player has played a given number of coins, the DCN sets the current message variable to a points won message in step 382 and sets the current bezel Scolor and rate to a points won color and rate in step 384. The points won S. message informs the player of the number of points won.

SThe above-described tracking process provides a means for providing visual feedback to the player inserting the card into the card 1o reader. By modifying the bezel color and bezel rate, the data communication node provides immediate feedback to the player concerning the proper insertion of the card. If the player inserts the card properly into the card reader so that the card reader senses a valid user id* ification nutmber, the.ard reader provides positive visual feedback to the user by illuminating the bezel. On the other hand, if the user improperly inserts the card. so that the card reader cannot read the user identification number, the card reader can provide negative visual feedback to the player by illuminating the bezel with a different color and/or flashing rate. In the preferred embodiment, this positive visual feedback includes flashing the green LEDs to produce a flashing green signal around the card reader opening. The negative visual feedback includes flashing the red LEDs. A third combination color is used during the processing of the player tracking information. This process provides immediate feedback to the player concerning the insertion of the card in the card reader.

B. PLAYER TRACKING

MODULE

The system described above allows for improved player tracking by recording each and every machine transaction including: time of play, machine number, duration of play, coins in, coins out, hand paid jackpots and games played. The player tracking is conducted over the same N network as the accounting data is extracted. This allows the system to provide

O

Obonusing to certain individual players as well as during certain times. As with standard player tracking, the above-described system monitors and reports how many coins are played by each player. The system described herein, however, also includes the ability 00 5 to record how long each player spends at each machine and the number of coins won, games played, and hand jackpots won by each player. The system is able to record all this information because the it operates on a transaction by transaction basis. Each INO transaction, whether it be a coin in, a handle pull, etc., is recorded by the system. Other prior art systems simply compile the player tracking information at the completion of play.

All the transaction information is stored on the database, which can be later analyzed for future targeted direct mailing campaigns. The player tracking allows the casino to schedule buses and other groups and measure their profitability. Because the system records each transaction, the casino can reconfigure their casinos to better match the tastes and demands of their customers.

This improved player tracking system also allows the casino to calculate theoretical wins exactly because the system always includes the most current information. The operation of the player tracking procedure is described below.

1. POWER UP PROCEDURE The operation of the player tracking module will now be described with reference to FIG. 23 where the powerup process 400 for the player tracking node is shown. As in the data communication node, the player tracking node first validates the RAM and sets up its associated hardware in step 402. Next, the player tracking node tests the RAM in step 404 to determine whether the RAM is functioning properly. If not, the player tracking node, player tracking controller, terminates its program in an error condition in step 406. If the player tracking RAM is fully

O

)x functional, the player tracking node sequentially executess 408-414.

;Z In step 408 the player tracking controller processes the DCN i face oo between the player tracking controller and the DCN controller. In step S410 the player tracking controller updates the player tracking display.

s In step 412 the player tracking controller updates the bezel- Finally, the n player tracking controller processes the card reader in step 414.. Each of Sthese steps will now be described further below.

S. 2. PROCESSING DCN INTERFACE SReferring now to FIG. 24, thesteps for processing the DCN interface t1o are shown. First, the player tracking controller checks for a new message received from the DCN in step 416. If a new missage has been received, the player tracking controller overwrites its current message buffer with the new message and updates the bezel color and rate values with those contained in the new current message. Then, the player tracking controller buids a card status rlermes e in step 420. The card staths.: message indicates whether a cardhas been inserted and if so whether the card was a good card or a bad card, the card was read properly by the card reader. If a valid card, the card status reply message also includes the identification number encoded on the card. This step might also involve transposing the number encoded on the card depending on the Sorientation in which the card was inserted into the card reader. This card status reply message in then sent to the DCN in step 422.

3. PROCESSING DISPLAY

UPDATE

The process of updating the player tracking display is shownin

FIG.

2s 25 at 410. This process begins .vith the player tracking controller scanning the display message' for display attribute information.

Examples of such display attribute information is given below in Table 4.

Each display attribute specifies a different graphic mode for the player tracking display.

I

(O

W TABLE 4- DISPLAY ATTRIUTE

NFORMATION

S1 Flash Rate 00 2. Center Display 3. Set Display Intensity 4. Use Small Lower Font Use Small Upper Font 6. Use Normal Large Font 7. Set Pause Time O 8. Set Scroll Speed S. 9. Center and Melt 0 10. Center and Scroll Down 0 11. Center and Scroll Up c 12. Scroll Down and Stop 13. Scroll UP and Stop 14- Scroll Left and Stop and End of Message Scroll Down 16. Scroll Up 17. Scroll Right 18. Scroll Left 2o 19. Reverse Vdeo Normal The player tracking controller then determines whether any such attribute information is found in the display message. If so, the player 2. tracking controller sets up the display driver to incorporate the graphics mode specified by the attribute information. The player tracking controller then strips out any display attribute information from the display message in step 432 because the display attribute information is embedded in the display message. The remaining data in the display message is the actual text to be displayed by the player tracking display, the player's name. The player tracking controller then sends this text to the display in step 434, which is then displayed by the player tracking display.

4. PROCESSING BEZEL

UPDATE

The player tracking node is also responsible for updating the bezel, both in terms of its color and flashing rate. This process 412 is shown in FIG. 26. The first step in processing the bezel update is to.determine to

NO

O

oo bezel color as specified by the DCN and then drive the appropriate LEDs in the card reader. As described above, the preferred embodiment of the card reader includes dual diodes having two primary colored diodes that can be driven separately or in combination to produce three different S colors, Next, the process determines the bezel rate as specified by the DCN.

In a first case, the bezel rateis. zero or off and thus the player tracking controller turns the LEDs off in step 442 in this case. If the bezel rate specifies a flashing rate, the player tracking controller flashes the bezel at the appropriate bezel rate in step 442. Flashing the bezel involves.

turning the LEDs on and off at the specified rate. This can be accomplished by a timer interrupt or a timing loop executed by the player tracking controller. The final option is that the rate can be infinite or effectively a s6lid zel cola.. In this case, the player tracking controller 1. simply leaves the card reader LEDs on in step 446. This completes the processing bezel update process 412.

PROCBSSING CARD READER The next process step for the player tracking node is to process the card reader. This process 414 is shown in FIG. 27. The first step is for the player tracking controller to determine the card status in 450. In the preferred embodiment, the card status is determined by comparing the checksum of the card, as read off the card by the card reader, to a computed checksum' of the data read off the card. Other methods of determining card status can be used as well depending on the type of card reader employed.

If the player tracking controller determines that a valid card was inserted in the card reader, the player tracking controller sets a card status variable equal to good card. This card status is then subsequently transmitted to the DCN controller. Then, the player tracking controller ,o sets a card ID variable equal to the identification number read by the

IO

O

oo card reader in step 454. The card status and the card ID provide the DCN with sufficient information to instigate the player tracking.

If, on the other hand, the card reader indicates that the card was read improperly or that the card is an invalid card for the card reader, the player tracking controller sets the card status variable to bad card in step 458 and the card ID variable is cleared in step 460. If neither a valid or invalid card condition was detected in 450, the player tracking controller sets the card status variable to no card in step 462 and clears out the card ID in 460.

o C. FLOOR

CONTROLLER

1. POWER UP PROCEDURE Referring now to FIGS. 28-32, the process 464 operable on the floor controller will now be described. The process 464 is shown in FIGS. 28- 32 in flow chart forms. These flow charts would enable one of ordinary skill in the art to implement the process in computer software using an appropriate computer programming language.

The floor controller process 464 begins at step 466 by opening the database tables in the file server. As described above, the file server includes a commercially-available database program which stores the 2o machine activity information as well as player tracking information and associated system characteristic parameters. This step 466 can also include fetching some or all of these system characteristics in order to trigger certain events such as bonus jackpots, as described below.

In step 468, the floor controller terminates any active player tracking sessions in the database. Because player tracking may have been in progress when the floor controller became inoperable, when the floor controller powers up or becomes operable, there may be player tracking sessions initially active. In this step, the floor controller terminates any such active player tracking sessions in order to place the database in an initial state.

IND

Another step that the floor controller executes after becoming operable is to place an initial machine search message in an output message queue oo00 470. This search message is used by the floor controller to determine which machines are connected to the floor controller. This output message is subsequently transmitted to all of the machines coupled to the floor controller

IND

using a global message format, as described below with reference to FIG.

O 31. In the preferred embodiment of the system ,the message handling is D through the use of message queues. Furthermore, the preferred embodiment is both an output queue for outgoing messages from the floor controller to the machines and an input message queue for messages coming from the machines to the floor controller. Queues are well-known data structures in the art of computer science and are therefore not further discussed herein. Alternatively, the message-handling could be done without the use of the queues. In such an embodiment the outgoing messages would be sent immediately rather than being queued, and any incoming messages would be processed immediately.

The bulk of the work performed by the file server process 464 is performed in message processing step 472. In this step, the floor controller processes all messages sent to or received from the machines connected thereto. This step will be described further below with references to FIGS.

29 through 31.

The process 464 also includes a system monitoring step 474. This system monitoring step 474 administers certain system-wide events. These system-wide events include the counting-related events and bonusing events. The floor controller continuously checks to see whether any of these events have been triggered. If any event has been triggered, such as a bonusing event, the floor controller takes the appropriate action to handle the event. The event may be triggered by the time and day or by usritrentiot).or other evenL The system onitorngstp44wl be described fuirther below with eeec oFG.3 n 3 The final step in Process 46.4 is for the floor controller to check for a termination condition in. step 476. Intepeere moi entth IND checks to determine whether an ESCape keyaspeed c-i If an SC key was pressed the floor controller terminates the process 464. If rno ESC key was pressed7 the floor controller loops back to step 472 0- herein th m s a e p o e s n step and the system onito rinlg step are repeated. -The floor controller continues in. telo 7-7 ni h X0 termni.Tation condition is sensed.

2. MIUSSAG1B

PROCESSING

As described above, the. floor controller acts as a gateway between the m iachines conxiectedrthere-to and the file server, as shown in FIG. 1.

The floor controller is responsible for forwardling the machine. activity received from the various mnacines to the database. The floor controller accomplishes this communlicationl through the use of mnessages- Th Ie message processing step 472 is shown in more detail in FIG. 29.

The first step in processingy the messages is for the floor cot~troller to sead. any messages that are queued-up in the outputrnessage queue to the appropriate data commQunicaion node in step 480. As described above, the output message queue is a simple data structure that is. used to store .any pending messages. Included in the message is a destinationl address by which the floor controller cani deterinme which of the plura lity of data commnilfication nodes to send the rness-age to. Next the floor controller receives any incoming messages from the data, communi cation nodes coupled to the floor controller in step 482. Once an incoming.

message has been received, the floor controller parses through the -message data included in the incoming mesae in steps 484 through 486.

In the preferred embodiment, the floor controller Parses through the message data one byte at a time. Thus, in step 484 the floor controller

O

<D

reads the next byte in the incoming message, and in step 486 the floor OO controller checks to see whether this is the last byte in the message. In the preferred embodiment, the message includes a message length field which indicates the number of data bytes included in the message. In this case, a floor controller in step 486 checks to see whether the number O of bytes read in step 484 is equal to the number of bytes specified by the 0 message length field.

O Once the input message data has been parsed out of the incoming -message, the floor controller takes the appropriate match in response to Ib the message data in step 488. This step is described further below with reference to FIGS. 30 and 31. Following the message-handling step 488; the floor controller checks in step 490 to determine whether any response is pending. The floor controller makes this determination by checking a transactins-in-progress strete which indicates whether the floor 1i controller needs to respond to any previous message. If a response is pending, the floor controller queues up an appropriate outgoing message in the output message qeue in step 492. Otherwise, the floor controller completes the message processing step 472.

Referring now to FIG. 30, the message-handling step 488 is shown in more detail. The message-handling step begins by verifying that the message data corresponds to a valid message in step 496. In the preferred embodiment, the message includes a cyclical redundancy check (CRC) by which the floor controller can determine whether the message is valid or corrupt. Only if the message is valid will the floor controller perform any additional message-handling steps. The floor controller also parses through the message in step 496 to determine what type the message is. The message type determines the appropriate floor controller action. In the preferred embodiment, the messages include a command code which indicates the type of message.

IO

O

to The first type of message can be one which includes new meter information. The floor controller checks in step 498 to determine whether 0 0 the message includes this type of information. If the message includes new meter information, the floor controller saves the new meter s information locally in step 500. The floor controller maintains local copies of the meter information in order to minimize the amount oftraffic on the O high-speed network. Because the machine meters change so rapidly, N0 forwarding this new meter information on to the file server each time one 0of these meters is altered would produce an excessive amount of network 1o traffic on the high-speed network. Therefore, in the preferred embodiment, the floor controller saves this new meter informa tion locally in step 500 and only forwards the new information on to the file server after a predetermined amount of time has elapsed.

Another type of message.is one which requests data. The floor.

is controller checks in step 502 to determine whether the message type is one requesting data. Typically, these data requests will be for player tracking information such as where a player inserts a card into a card reader whereupon the data communication associated therewith sends the identification number encoded on the card to the floor controller requesting the player tracking data associated with the player identification number. If the floor controller detects a data request in step 502, the floor controller looks up the requested data in the database on the file server in step 504. Also, in step 504, the floor controller marks a response pending in the transactions in progress structure to indicate that this requested data needs to be sent back to the DCN. As described above, the floor controller queues up outgoing messages responsive to the transactions in progress structure.

Another message type is one used by the floor controller to establish new machine addresses. The floor controller periodically checks to determine whether any new DCN has been coupled to its associated Scurrent loop networks in order to assign a unique address to that Of machine. In step 506, the floor controller checks to see whether the incoming message is in response to such a process. If the incoming oo message is in response to a machine search, the floor controller aign a new machine address to the responding machine in step 508. The Sentire process of assigning new machine addresses is described below with reference to FIG. 31.

NO Finally, the floor controller in step 510 handles any miscellaneous messages. .These miscellaneois messages are used primarily for 8 debugging and trouble-shooting the machines.

3. ASSIGNING GAMING DEVICE

ADDRESSES

as described above, in the preferred embodiment of the invention, the floor controller uses a shorthand token representation of the DCN's unique identification number to address the DCN. In the preferred 1s embodiment a single byte address is used to address a DCN on any given current loop- T te.a aess ~ds to 256 DCNs to be supported on any given current loop network. In the preferred embodiment, only 64 such DCNs are connected to a single current loop network and therefore the single byte address is more than adequate.

The single byte address substantially reduces the amount of trafficQn the current loop network by reducing the number of bytes from four in the unique identification number to one for the shorthand token representation.

The floor controller is responsible for generating the unique single s2 byte address for each data communication node on a given current loop network. The process 508 of assigning unique addresses to the DCNs on the current loop network is shown in FIG. 31. The process begins by defining a range of unique identification numbers in step 512. Initially this will be a large range.

O

0) Next, the floor controller sends out a message to all of the DONs on 00 the current loop network in step 514. The floor controller comnmunictes 'with the DCNs by using a standard communication protocol. In the preferred embodiment, this protocol defines a message format including S a destination ID, a source ID, a message length, a data packet and a CRC.

Other message formats could be used as well. Using this format, the floor controller can communicate with all of the DCNs on the current loop CO network by using a global destination address in the message. This global destination address would indicate to the DCNs that this message to is intended for all DCNs on. the current loop network. This global message would include two unique identification numbers that, taken together, define the range of unique identification numbers established in step 512.

The individual DCNs then cheeks to see whether their unique 1s identification number falls within this range. If a DCN's unique identification number falls within this range and the DCN does not have an address assigned thereto, the DCN then responds to this global message by sending a reply message in response that includes the unique identification number ofthatDCN. In the event that more than one DCN has a unique identification number that falls within this range a network collision will occur and the message will be corrupted. The process 508 checks for this condition in step 516. This condition is indicated by an invalid CRC in the message.

In the event of a network collision, the floor controller can limit the range of unique identification numbers by repeating step 512 in the hope of eliminating this network contention.

If the response has a valid CRC, the floor controller assigns a unique address to the responding DCN, as identified by the unique identification number in the response, in step 518. The floor controller then transmits this address along with the corresponding unique

O

identification number in an assignment message to all of the DGNusing Sa global destination address in step 520. The DCNs then process h- message and in the event thatthe unique identification number inclded in the message corresponds to the DCN's unique identification number, s the DCN adopts the address included in the message. Once the DCN has Cc ,been assigned an address in this manner, the DCN wi interpret all subsequent messages having a destination address equal to the assigned SDCN address as being directed to that DCN. The above-described N address assignment sequence is repeated for each of the remaining DCNs .o on the current loop network in step 522. The floor controller continues this process until the entire range of unique identification numbers has been covered and no more network collisions occur.

4. SYSTEM

MONITORING

Referring now to FIG. 32, the system monitoring step 474 will ow 16 be described. The floor controller is now responsi'ble r nitor certain system-wide conditions to determine whether certain events need to occur. The system monitoring step also handles request for particular machine information. Thus, in step 524, the floor controller determines whether a new request has been placed in the data baselfor such 2o particular machine information. If such a request has been placed, the floor controller responds to the special request for data in step 526 by sending a message to the particular machine requesting the required information. Once the required information has been received, the floor controller processes this information accordingly.

The floor controller also monitors the locally-stored meter information in step 528. If the locally-stored information is changed, the floor controller saves the latest information to the data base in step 530.

As described above, the floor controller saves the meter information locally in order to minimize the trafic to the file server over the high 0o speed network.

O

O

SThe floor controller also monitors the system for certain event 0 triggers in step 532. These triggers can be stored in the data base and fetched by the floor controller during its power-up procedures. These triggers indicate if and when certain events occur. Examples of event triggers include: the drop period, the end-of-day, the bonus period, etc.

If an event trigger has occurred, the floor controller handles the event in C1 step 534.

SThe handle event step 534 is shown in more detail in FIG. 33. The events can basically be bifurcated into accounting events and bonusing o1 events. Accounting events refer to the data communication activity of the system. The accounting events are typically triggered by a certain time of day such as the end of day or the drop period. If an accounting event has been triggered, the floor controller performs the required data base operations in step 538. This step involves updating all of the locally..

stored meter.information and storing the updated meter information into the data base.

The other type of event can be referred to as a bonusing event. The floor controller checks to see whether the event is a bonusingevent in step 540. The bonusing events can also be triggered by the time of day.

so For example, the bonusing eventmay.be triggered from midnight to 4:00 a.m. on weekdays. These bonusing periods can be specified in the data base. If the triggered event is a bonusing event, the floor controller .inserts a corresponding reconfiguration message in the output message queue in step 542. The reconfiguration message includes a 2 reconfiguration command that is sent to an appropriate machine. The machine, upon receiving the reconfiguration commadbd, reconfigures its payout schedule. in accordance with the received reconfiguration command. According to the invention, there are many different reconfiguration commands to implement a multiplicity of different bonusing events. One reconfiguration command specifies that the

O

machine should reconfigure its payout schedule to be a multiple ofits 00 default payout schedule. This reconfiguration command can also specify that the multiple payout schedule should be limited to a predetermined percentage of the coins in. This reconfiguration command can further ,specify that the multiple payout schedule should be limited to only when 0 the maximum coins are played. This reconfiguration command can S..further specify that the multiple payout schedule should be limited to Spayouts in a specified range. This reconfiguration command can also CI specify the multiple payout schedule should payout only when a predetermined level of player activity is reached.

Another reconfiguration command allows any number of machines on the network to be combined in a common jackpot having a common jackpot payout schedule, wherein the reconfiguration command Srecnfigures the. selected machine to payit iti accordance with the common jackpot payout schedule. In this case, the reconfiguration message would be queued up for each of the selected machines to be combined in a common jackpot. One example of a common jackpot is a progressive jackpot. Unlike the prior art progressive jackpot systems, however, the progressive jackpot according to the invention is not limited 0o to a predetermined number of machines. In the prior art progressive jackpot systems, a bank of machines are connected to a common progressive jackpot controller and only those machines can be included.

in the progressive jackpot. In contrast, any machine on the network, including those connected.to other floor controllers can be combined into a common progressive jackpot. Moreover, the number of progressive jackpots is not limited by the number of floor controllers since one floor controller can manage more than one progressive jackpot.

Another reconfiguration command permits the system to implement so-called "automatic mystery jackpots." These "mystery" jackpots allow a machine to payout a mystery jackpot even when a jackpot was not won.

IO

Instead, the reconfiguration command can specify that the mystery 0 jackpot is to occur after a certain number of coins, a certain number of handle pulls, or a variety of other conditions specified by the reconfiguration commands. These mystery bonuses provide the casino s with another way to induce additional gaming activity.

Sc 5. BONUS CONTROL ID Referring now to FIG. 34, a method 550 for controlling the O conditions under which the above-described bonus activities are activated N is shown. It is essential for the system to have complete control over the 1o amount and conditions under which a bonus is paid out in order to insure the profitability of the bonusing system. The method 550 described below provides the required control.

The method 550 begins in step 552 by disabling or turning off the bonuses in the individual machines. This is accomplished by sending a message to the individual DCNs to turn off or deactivate bonusing. Next, the floor controller monitors the activities of the individual machines connected thereto. This step includes monitoring, the coins in and bonuses paid for.the individual machines, as described above., In step 556, the floor controller modifies a bonus pool by a predetermined percentage of all coins played. The bonus pool is essentially a pool of monetary resources that can he allocated for bonus awards. In the preferred embodiment, a predetermined percentage of the monetary value of the coins played are added to the bonus pool. Also in this step, any bonuses paid by the gaming devices are also measured and subtracted from the bonus pool. The use of the bonus pool will become more apparent when the other steps are described hereinbelow.

In step 558, the floor controller determines whether or not bonusing is active. If bonusing is active, the floor controller next determines whether the bonus pool amount has dropped below a predetermined minimum level called the "turn-off' level in 560. This minimum amount

O

;Z or floor can be set by the casino and provides a buffer to account for large Sbonus awards and/or multiple bonus awards that could cause the bonus 00 payout to exceed the bonus pool. Therefore, if the bonus pool drops below the turn-off level, the method 550 branches back to step 552 and, turns s off bonusing. As will described further below, the bonusing remains off until such time as the bonus pool builds up past another minimum level N called the "turn-on" level.

SReturning to step 558, if the bonus is currently not active, the floor C controller determines at step 562 whether the bonus pool has reached a predetermined turn-on level. -This turn-on level can also be set by the casino and provides a buffer above the turn-off level to insure that the bonusing does not behave erratically, bonusing rapidly switching between on and off. If the bonus pool is not above the turn-on level, bonusing is again turned.'f~f in step:552.

If the bonus pool has reached the turn-on level, the floor controller checks to see whether other bonus conditions are met at step 564. These bonus conditions can incdude, but are not limited to, a minimum period of time since the last bonus activation, a minimum level of play in the time period prior to the bonus pool reaching the turn on level, a predetermined time of day, or other predetermined conditions. These conditions give the casino additional control over the honusing promotions. If the conditions are not met, the method 550 branches back to step 552 where the bonusing is again turned off. If, however, the conditions are met in step 564, the bonus is turned on at step 566 and the method 550 branches to step 554 where the machine activity is again monitored.

In the preferred embodiment, the method 550 is embodied in software that is executed by each of the floor controllers in the system.

These floor controllers are then responsible for activating or deactivating the bonusing for the individual machines connected thereto. The system IN -70/1-

\O

callows the floor controller to have multiple bonus pools and to have certain of the machines associated with a given bonus pool. Thus, the floor controller can implement multiple bonusing promotions simultaneously.

00 This system also allows for machines connected to different floor controllers to 5 be combined into a single bonusing promotion. In this case, one of the floor controllers assumes primary responsibility for managing the bonus pool while the other floor controllers act as intermediaries between the primary floor controller Iand the machines connected to the other floor controllers. Thus, the system according to the embodiment allows for much greater flexibility in running bonusing promotionals than heretofore possible. Prior art systems required certain predetermined machines to be connected into a bank for any given bonus award such as a progressive bonus. The system according to the embodiment allows any machine in the casino to be combined in a bonus type situation. The system also insures that the bonusing promotionals will operate substantially in the black, the bonus pool is greater than the bonus payouts.

III. PREFERRED EMBODIMENTS OF THE PRESENT INVENTION Embodiments of the present invention will now be described with reference to FIG. 35 to Turning now to FIG. 35, indicated generally at 1010 is a schematic diagram illustrating electronic gaming machines (EGMs), like EGMs 1012, 1014, interconnected by a computer network. Included therein are three banks, indicated generally at 1016, 1018, 1020, of EGMs. Each EGM is connected via a network connection, like connection 1022, to a bank controller 1024. In the present embodiment of the invention, each bank controller comprises a processor that facilitates data communication between the EGMs in its associated bank and the other components on the network. The bank controller 1024 also includes a CD ROM drive for transmitting digitized sound effects, such as music and the like, to a speaker 1026 responsive to commands issued over the network to bank controller 1024. The bank controller 1024 is also connected IN- 70/2- 0 to an electronic sign 1028 that displays information, such as jackpot amounts b3 and the oO -71 ;Z like, visible to players of machines on bank 1016. Such displays are generated 00 and changed responsive to commands issued over the network to bank 00 controller 1024. Each of the other banks 1018, 1020 of EGMs include associated bank controllers, speakers, and signs as shown, which operate in substantially the same manner.

N Ethernet hub 1030 connects each of the bank controllers associated with banks 1016, 1018, 1020 of EGMs to a concentrator 1032. Another Ethernet hub 1034 connects similar bank controllers (not shown), each associated with an additional bank of EGMs (also not shown), to concentrator 1032. The.

concentrator functions as a data control switch to route data from each of the. banks to a translator 1036. The translator comprises a compatibility buffer., between the concentrator and a proprietary accounting system 1038. It functions to place all the datathelWf fr ea, theb. controletrs into format compatible with accounting system 1038. The present embodiment of the invention, translator 1038 comprises an Intel Pentium 200 MHz Processor operating Microsoft Windows NT Another Ethernet hub 1039 is connected to a configuration workstation 1040, a player server 1042, and to bonus servers 1044, 1046. Hub 1039 facilitates data flow to or from workstation 1040 and servers 1042, 1044, 1046.

The configuration workstation 1040 comprises a user interface. It comprises a personal computer including a keyboard, Intel Pentium Processor and Ethernet card.

The player server 1042 comprises a microcomputer that is used to control messages that appear on displays associated with each EGM. Player server 1042 includes an Intel Pentium Processor and an Ethernet card.

Bonus servers 1044, 1046 each comprise a microcomputer used to control bonus applications on the network. Each bonus application comprises a set of N- 72-

O

rules for awarding jackpots in excess of those established by the pay tables on each EGM. For example, some bonus awards may be made randomly, while others may be made to link to groups of EGMs operating in a progressive 00 jackpot mode. Examples of bonuses that can be implemented by bonus servers 1044, 1046 and a network that could be used to implement the present invention have been hereinbefore described in the description of the system and network with reference to Figures 1 to 34.

O

OFIG. 36 is a highly schematic representation of an electronic slot machine, which Nis typical of each of the machines in the network, that incorporates network communications hardware as described hereinafter. This hardware has been hereinbefore described in the description of the system and network with reference to Figures 1 to 34, and is referred to therein as a data communications node.

Included in EGM 1012 are three reels, indicated generally at 1048. Each reel includes a plurality of different symbols thereon. The reels spin in response to player input after a wager is made. FIG. 40 comprises the paytable for EGM 1012. The first three columns depict different combinations of symbols on the reels. The fourth column of Fig. 40 indicates the amount won on a single coin wager when the combination of symbols in the first three columns appears after the reels spin. Columns five and six indicate the amount won when two and three coins, respectively, are wagered. Any combination of reel symbols other than those shown in FIG. 40 does not result in a payment to the player.

The network communications hardware preferably comprises a mabchine communication interface (MCI) 1050. MCI 1050 facilitates communication between the network, via connection 1022, and microprocessor 1052, which controls the operation of EGM 1012. This communication occurs via a serial port 1054 on the microprocessor to which MCI 1050 is connected.

Microprocessor 1052 is also connected to a programmable read only memory (PROM) 1056, which controls the behavior of EGM 1012, and which may or may not include the paytable of FIG. 40, depending upon how the present invention is IN -73c implemented, as described hereinafter. MCI 1050 may include a random access memory (RAM), which can be used as later described herein.

;Z

MCI 1050 also facilitates communication between the network and a player display 1058, a card reader 1060, a player-actuated push button 1062, and a speaker 1064.

\O

SCard reader 1060 reads a player-tracking card 1066 that is issued by the casino IDto individual players who choose to have such a card. Examples of a suitable Scard reader 1060, player-tracking card 1066 and player-tracking systems have been hereinbefore described in the description of the system and network with reference to Figures 1 to 34. Briefly summarizing such a system, a player registers with the casino prior to commencing gaming. The casino issues a unique player-tracking card to the player and opens a corresponding player account that is stored on accounting system 1038 (in FIG. 35). The account includes the player's name and mailing address and perhaps other information of interest to the casino in connection with marketing efforts. Prior to playing one of the EGMs in FIG. 35, the player inserts card 1066 into reader 1060 thus permitting accounting system 1038 to track player activity, such as amounts wagered and won and rate of play.

In another embodiment of the invention, EGM 1012 in Fig. 36 can be operated in a stand-alone mode, without connection 1022.

Consideration will now be given to the operation of the network and associated equipment depicted in FIGS. 35 and 36. First, selected configuration parameters are implemented at each EGM. As discussed above, these configuration parameters may be implemented by either installing a PROM, like PROM 1056 in FIG. 36, in each EGM to be configured or by placing the EGM in a configuration mode and thereafter generating inputs to the EGM, or a combination of and Alternatively, and also in accordance with the present invention, configuration parameters can be implemented by generating computer commands at configuration workstation 1040 that are transmitted via 74 ;Z the network to a selected one or more of the EGMs. For example, and with 0. reference to FIG. 36, such commands can be transmitted over the network- o. SMCI 1050 via connection 1022. The commands may either reside in the random access memory (RAM) contained within MCI 1050, or can be transferred to RAM (not shown) associated with EGM 1012 via the serial port 1054 of microprocessor 1052. In the latter case, the code so transferred is received by microprocessor 1052 and then stored in the EGM RAM.

in either case, whether stored in MCI 1050 or in RAM associated with the EGM, the configuration parameters are accessible by microprocessor 1052, which: when programmed with the stored configuration parameters causes EGM 1012: to operate in accordance with the parameters. As mentioned above, such: configuration parameters control the behavior of the electronic gaming machine and may include the paytable thatcotros.. the average percent of money that.

the machines returns to players via jackpots.

Next, a plurality of variables related to play on the gaming machines are monitored. Such variables may include the rate at which the intrconrneted machines are played. The casino is therefore able to determine whether or not there is a relatively high level of demand for play or a relatively low levei, the rate is relatively low. The casino's income, of course, increases with the rate of play.

Another variable comprises the time that the interconnected machines are played. The time variable may relate to a specific time of the day, the week, or the year. Each of these time periods includes portions in which play typically occurs at a high rate, evenings, Friday and Saturday nights, and three day weekends, and other portions in which play typically occurs at a low rate. The time variable may also relate to the length of time a particular configuration parameter has been implemented.

r- Still another such variable comprises the status of a player of one of the.

Z machines. The status of the player may comprise whether the player is 0 o recognized by a player-tracking system operated on the network. In the present embodiment of the invention this feature is implemented with player-tracking card 1066 and card reader 1060. Another aspect of the player status relates to

ID

m the level of player play. One aspect of the level of player play includes the rate 0 of play both the current rate as well as the rate over a selected time period.

\O

0Next, a predetermined criterion is established for one of the monitored variables.

For example, in connection with the player status, the predetermined criterion may comprise a predetermined level of player play, establishing a predetermined rate of player play. Another predetermined criterion relates to the level of money wagered on the entire system shown in FIG. 35, which is calculated by accounting system.0. Thi criterion culdcomprise the rate of: money wagered on the entire system, as opposed tothe cerierion set forth above" relating to the rate at which a single player wagers.

Another predetermined criterion may relate to the time. As noted above this could be the time that a particular configuration parameter "has been implemented or could relate to the time of a day, week, or year.

After the predetermined criterion for one of the monitored variables is established, play is permitted to occur .at the machines. When the monitored variable meets the criterion, one or more of the machines, or all, in FIG. 35 is selected, and a computer command is issued. In response to the computer command, a configuration parameter of the selected machine or machines is changed responsive to a command over the network.

Attention is now directed to FIG. 37 wherein indicated generally at 1068 is flow chart of a computer program implementing a portion of a preferred embodiment of the present invention. Computer program 1068 is implemented in software installed on configuration workstation 1040 in FIG. 35. First a criterion is

I

76- ;Z established in box 1070. As discussed above, the criterion may relate to the raf at which the interconnected machines are played, the time the interconnected 00 machines are played, or the status of a player of one of the machines. Next, a first configuration parameter is implemented in box 1072. As discussed above, configuration parameters are implemented by installing a PROM provided by the SEGM manufacturer, by generating inputs to the EGM when placed in the configuration mode, or by downloading configuration data delivered over the network of FIG. 35 to the EGM, or by a combination of the foregoing. Typically N there is an initial configuration implemented via PROM or placing the EGM into a configuration mode. Implementation of initial configuration parameters,,.

however, may be accomplished in any manner in accordance with the present invention.

In box 1074, variables such as rate at which the machines are played, time tha the machines are played, and the status of players, are monitored using the network of FIG. 35. In step 1076 the program compares the monitored variables with the criterion established in block 1070. If it. is not met, the program maintains the first configuration parameter implemented in step 1072 and continues to monitor variables in 1074.

When step 1076 determines that the criterion is met, a second configuration parameter is implemented in box 1078. Thereafter the program monitors system variables in box 1074 and so long as the criterion is met, maintains implementation of the second configuration parameter. When and if the criterion is not met, step 1076 directs that the first configuration parameter be again implemented in box 1072 with continued monitoring and comparison as before.

Considering now FIGS. 38 and 39, additional description will be made of examples of configuring electronic gaming machines in accordance with the present invention in which the predetermined criterion comprises the time that the interconnected machines are played and the changed configuration parameter comprises payback percentage.

-77 SIn a first example, illustrated schematically in FIG. 38, the time that the interconnected machines are played relates to the time of an exemplary week.

00oo A time line 1080 is bisected by long vertical lines, like ines 1082, 1084, which define a single 24 hour day. Each day of the week beginning with Monday and ending with Sunday, is identified on the time line. Each day is bisected by three qn short vertical lines, like line 1086, that are equally spaced between long lines, N like lines 1082, 1084. The distance from one short line to the next adjacent line Stherefore represents a 6 hour period. In the portion of time line 1080 Srepresenting Monday, the short line corresponding to 6:00 pm is identified with a 1, as are the portions of the time line representing Tuesday and Wednesday..:.:j In the portion of the time line representing Tuesday, the time corresponding to :j 2:00 am is designated with a 2. This is also the case for Wednesday and Thursday.

Friday, Saturday, and Sunday similarly include times corresponding to numerals 1 or 2 as depicted.

In the example of FIG. 38, the time period defined between each nupber 1 and the following number 2 is referred to herein as a first time period. The time period between each number 2 and the following number 1 is referred to herein as a second time period. In this example, play on the machines is typically at a high level during the first time period and typically at a low level during the second time period. During the hours of the day, especially weekdays between around breakfast and midafternoon, play in some casinos is typically at a lower level than in the evening beginning around 6:00 pm. Similarly, play on the weekends during the day is at higher level than during weekdays.

The hours of the day defining the first and second periods in FIG. 38 are entered into configuration workstation 1040. A computer command is issued at the start of each period. In response to the command, a payback percentage for one, or more, of the EGMs is implemented. In accordance with the present invention, this payback percentage may be implemented by delivering over the network to

\D

0 -78- 0 each affected machine a code that is stored in a memory associated with the 00 machine and that changes the pay table of the machine. Because some oo jurisdictions would not permit changing the pay table on the machine, there is an alternative way to change the payback percentage to a selected machine or machines.

N Using the alternative way, the network tracks the amount of money played on a 0 selected gaming machine or machines that will have different payback percentages implemented. Responsive to the first command, a predetermined percentage of the money played on the selected machines is allocated to a bonus pool that is also tracked by the network. A bonus period is also initiatedi.

responsive to the first command., During the first period a bonus is paid to the machine or machines on which the first payback percentage is implemented.

Such a bonus may be randomly awarded to- one of these machines or ;may.: comprise an additional payment each time an EGM jackpot is paid inaccordance with the first table. Such bonuses and the. manner of implementing are described in the first embodiment After play occurs on the machines, a.

second computer command is issued at the start of the second period. The second payback percentage for the selected machine or machines is implemented responsive to the second command. In this example, implementation of the second period is equivalent to turning the bonus off, i.e., money is no longer allocated to a bonus period during the second period and bonuses are not paid from the pool.

It can be seen that multiple criteria can be monitored. For example, at all times it might be desirable to provide a higher payback percentage to a player who uses a player-tracking card issued to him or her by the casino. For example, the bonus pool could always be accruing, and paying bonuses to each player using a valid player's card. Such a player would be eligible for still a higher level of bonus, additional percentage would accrue from all amounts wagered during the first period on the time line. Multiple and overlapping bonus pools could therefore be simultaneously accruing a percentage of wagers, and awarding 79 bonuses from such pools, depending upon the rate of machine play, players status, and the time the interconnected machines are played.

00 Turning now to FIG. 39, a second time line defines a year. With certain holidays, for example Memorial Day and Labor Day, play is typically, high at all times S 5 throughout the three day weekend, with each day being represented by a O N vertical line in FIG. 39. The appropriate computer in FIG. 35 is therefore programmed to either override or alter the amount of the payback percentage c change in the first and second periods of FIG. 38 during those weekends. In the example of FIG. 39, the period between December 25th and December 31st is traditionally a very slow time in some casinos so that the payback percentage could be correspondingly altered by either changing the amounts that would normally occur as a result of the parameters in FIG. 38 or substituting a different single one. or. mult i ple pr mtes fi' that Pedo. It i.s o be appreciated thiat" multiple variables may be monitored and multiple configuration parameters may be changed in response to the monitored variables.

Another configuration parameter comprises game speed. With re.pect to an electronic slot machine, the game speed is the time it takes from start of reel rotation until the reels stop spinning. With respect to electronic poker, the time relates to how fast the cards are "dealt," how rapidly they appear on the video monitor display. As discussed above, game speed, along with payback percentage and accrual of wagers in a bonus pool influence the net cost to the player per unit time for playing the casino games. Game speed is therefore one of the configuration parameters that may be changed in response to commands issued over the computer network in response to a predetermined criterion for one of the monitored variables. As with each of the other configurable parameters, an appropriate code input to the EGM serial port 1054, delivered over the network and MCI 1050, is used to change the game speed of the selected EGM.

SConsideration will now be given to the operation of EGM 1012 in stand-alone ;Z mode, without being connected to a network via connection 1022. Initial configuration parameters are implemented as described above, either via 0O Sinstalling PROM, by casino configuration, or by a combination of the two. In this embodiment, the RAM in MCI 1050 is programmed to monitor variables related a to play on the gaming machine, such as coin in, coin out, player status, time that machine is played, etc. The MCI also allocates a predetermined percentage of

O

N the money played on the gaming machine to a bonus pool. A predetermined criterion for one of the variables is stored in the MCI RAM. The MCI compares N 10 the monitored variable to the criterion and initiates a bonus period when the criterion is met. During the bonus period, the machine pays both from the pay table and from the bonus pool based on bonus rules that are stored in the MCI and implemented via communication with EGM processor 1052. The bonus rules could provide for numerous types of payments via the EGM. The bonus could pay, for example, a specified amount from the pool in response to certain winning, or nonwinning, reel combinations. It could pay a multiple of any jackpot awarded by the EGM, or it could pay on a random basis. Numerous other rules could be established for paying from the bonus pool during a bonus period. As described above in connection with the networked implementation' of the invention, this raises the payback percentage to a player of the gaming machine.

Having illustrated and described the principles of the invention in a preferred embodiment thereof, it should be readily apparent to those skilled in the art that the invention can be modified in arrangement and detail without departing from such principles. Modifications and variations such as would be apparent to a skilled addressee are deemed to be within the scope of the present invention.

For example, although an Ethernet network was described in the preferred embodiment of the invention, other high-speed networks such as wireless networks could be used in place thereof.

Throughout this specification, unless the context requires otherwise, the word "comprise", or variations such as "comprises" or "comprising", will be understood IN -81- 0 O to imply the inclusion of a stated integer or group of integers but not the Sexclusion of any other integer or group of integers.

00

Claims (6)

1. A method of configuring electronic gaming machines interconnected by a 00 computer network to a host computer comprising: implementing selected configuration parameters at each machine; permitting play to occur at the machines; INO operating a player-tracking system on the network; Smonitoring the level of play of a tracked player on multiple gaming machines; C-i transmitting data relating to the monitored status over the network; INO storing the status data on a computer connected to the network; C selecting a machine being played by the player; generating a computer message based at least in part on the stored status data; issuing the message from the host computer; and changing a configuration parameter of the selected machine responsive to the message.

2. The method of claim 1, wherein the changed configuration parameter comprises game speed.

3. The method of claim 1, wherein the changed configuration parameter comprises payback percentage.

4. The method of claim 1, wherein the changed configuration parameter comprises game appearance.

A method of configuring electronic gaming machines interconnected by a computer network to a host computer substantially as hereinbefore described with reference to the accompanying drawings.

6. A method of configuring electronic gaming machines interconnected by a computer network to a host computer according to any one of claims 1 to 4 and substantially as hereinbefore described with reference to the accompanying drawings. Dated this Eighteenth day of August 2006. IGT Wray Associates Perth, Western Australia Patent Attorneys for the Applicant