CROSS-REFERENCE TO RELATED APPLICATIONS This application is a continuation-in-part of U.S. patent application Ser. No. 09/967,221 filed Sep. 28, 2001, entitled INTEGRATED DISPLAY AND INPUT SYSTEM, which is hereby incorporated herein by reference. This application is also a continuation-in-part of U.S. patent application Ser. No. 10/943,771 filed Sep. 16, 2004, entitled USER INTERFACE SYSTEM AND METHOD FOR A GAMING MACHINE, which is hereby incorporated herein by reference. This application is related to co-pending U.S. patent application Ser. No. ______, filed Jan. 25, 2007, entitled STORE AND FORWARD PATRON ACCOUNT MESSAGING METHOD.
COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
FIELD OF THE INVENTION This invention relates generally to a player messaging system and, more particularly, to a system and methodology for player messaging via a back-end server patron account.
BACKGROUND Traditionally, gaming machines have been designed for gaming purposes only. In this regard, gaming machines have been constructed only to include gaming functionality. Recently, however, casino owners have become aware that by adding additional features to gaming machines, they may be able to maintain a player's attention to the gaming machines for longer periods of time. This, in turn, leads to the player wagering at the gaming machine for longer periods of time, thereby increasing casino profits.
Customers demand product differentiation and steady improvements. Additionally, patrons want to be assured that they are afforded some degree of special treatment. Some previous attempts to achieve such results, including having casino personnel provide personalized services (players' clubs and other loyalty programs) have resulted in improved slot performance in exchange for the perceived attentiveness. Notably, this perceived attention is, in and of itself, a commodity. Patrons participate more readily when they feel they have more access and attention.
SUMMARY Briefly and in general terms, in accordance with one presently preferred embodiment, a patron messaging system is disclosed for contacting a patron via a patron loyalty system. The patron messaging system includes: a patron message database, a message entry and management system, one or more gaming devices, and a display device operatively associated with each gaming device. The patron message database stores patron messages for eventual transmission to a patron. The message entry and management system enables an operator to enter and manage messages intended for one or more patrons. Additionally, the message entry and management system is operatively associated with the patron message database. The one or more gaming devices are interconnected to the patron message database through a network. Additionally, each gaming device is operatively associated with a message response system. The patron messages are viewable via the display device and may be responded thereto via the message response system.
In accordance with another aspect of a presently preferred embodiment, the patron message database that stores patron messages for eventual transmission, forwards the stored patron messages to the gaming device at which the patron is located upon the detection of a patron card on the system. In some embodiments, the retrieval of patron messages requires a personal identification number. In other embodiments, the retrieval of patron messages requires a username and a password. Referring to another aspect, typically patron messages may be designated as private or public. In this regard, patron messages designated as private require satisfaction of additional security measures for viewing.
In accordance with still another aspect, in one embodiment the display device on which the patron messages are viewable is a separate device than a gaming display device used for game play on the gaming device. In other embodiments, the display device on which the patron messages are viewable is the same display device used for game play on the gaming device. Moreover, in one embodiment, the display device only displays text-based patron messages. However, in other embodiments, the display device displays multi-media graphically-enabled patron messages.
In accordance with yet another aspect, in one embodiment the message response system includes an input device, such as a keypad or a touch-screen. The patron messaging system enables many types of functionality including, by way of example only, and not by way of limitation: targeted messaging to groups of patrons, third party marketing, paging services, patron-to-patron messaging services, and combinations thereof. In some embodiments, the patron messaging system is offered as a pay service to casino patrons. In other embodiments, the patrons are offered financial incentives for accepting marketing messages from the patron messaging system. Such financial incentives by way of example only, and not by way of limitation: free game credits, store discounts, restaurant discounts, hotel room discounts, enhanced game odds, enhanced game bonuses, and combinations thereof.
In another aspect of a preferred embodiment, acknowledging receipt of a patron message activates other processes including: issuing bonuses, sending a waitress to the patron's gaming station, issuing complementary drinks, and combinations thereof. Further, in some embodiments, the patron messages have additional parameters including abilities to save messages after viewing, the print messages after viewing, automatically delete message after viewing can be, and prompt for additional message deletion options.
Other features and advantages of a disclosed embodiment will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate by way of example, the features of the disclosed embodiment.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 illustrates a relational diagram of a display and input system utilizing a two processor platform gaming device in conjunction with a gaming system;
FIG. 2 illustrates a relational diagram of the two processor platform gaming device and gaming system ofFIG. 1, without the display and input system;
FIG. 3 illustrates a front view of a display screen of a gaming device while a gaming interface is activated for game play in conjunction with a small systems interface window displaying scrolling text;
FIG. 4 illustrates a front view of the display screen of the gaming device inFIG. 3, while a gaming interface is activated for game play in conjunction with a partial screen systems interface displaying a 12 digit keypad;
FIG. 5 illustrates a front view of the display screen of a gaming device while a gaming interface is activated;
FIG. 6 illustrates a front view of the display screen of the gaming device inFIG. 5, while a full screen player services interface is activated;
FIG. 7 illustrates a front view of the display screen of the gaming device inFIG. 5, while a full screen employee systems interface is activated;
FIG. 8 illustrates a relational diagram of the security architecture of a display and input system that shows the information security boundary logically dividing the critical game security components inside of the boundary from the non-critical components outside of the boundary; and
FIG. 9 illustrates patron messaging system for storing and forwarding a patron via a patron account and loyalty system.
DETAILED DESCRIPTION An embodiment of the display and input system is directed towards the integration of system functions with gaming functions on a video display screen of a gaming device. The display and input system provides enhanced player satisfaction and excitement, as well as improved gaming device reliability, interactivity, flexibility, security, and accountability. Referring now to the drawings, wherein like reference numerals denote like or corresponding parts throughout the drawings and, more particularly toFIG. 1, there is shown a display andinput system10 constructed in accordance with one disclosed embodiment.
Referring now toFIG. 1, a preferred embodiment is a display andinput system10 for players and casino employees. The display andinput system10 provides an enhanced means for displaying service andsystem information14 via asystem network18 to a player and/or to a casino employee. The display andinput system10 enables part or all of avideo display screen40 in agaming device50, which had previously been used only as agaming interface30, to be utilized as asystems interface20 for data entry and retrieval of the service andsystem information14. The systems interface20 accesses service andsystem information14 from thesystem network18. This is a dramatic improvement over traditional system components (input/output peripherals) that have been used in the past to access service andsystem information14 from thesystem network18. As shown inFIG. 2, these traditional system components include 2-line, 20 character VF displays and 12-digit keypads. Referring again toFIG. 1, it should be noted that preferred embodiment of the display andinput system10, does not control game play itself (e.g., game play betting, game play flow, or game play operation). Rather, the preferred display andinput system10 provides only a limited form of game play monitoring, indirectly, with respect to the monitoring of player points.
As shown inFIG. 2, current gaming devices utilize thevideo display screen40 solely as agaming interface30 for thedevice50. Thegaming interface30 provides access to thedisplay screen40 associated with game play where the player participates in gaming activity. However, in the preferred embodiment as shown inFIG. 1, the display andinput system10 integrates both thesystems interface20 and thegaming interface30 via thevideo display screen40, which; again, was previously used only for game play via the gaming interface. In one embodiment, thesystems interface20 of the display andinput system10 includes a touch-screen keypad and display. In this manner, service andsystem information14 from thesystem network18 is displayed to players through thesystems interface20 within thedisplay screen40. Further, thesystems interface20 provides a player with direct interactive access to the service andsystem information14 in thesystem network18, preferably by using thedisplay screen40 as a touch-screen input device. This type of systems interface20 provides greater simplicity, flexibility, player excitement, interactivity, and developmental options than usingtraditional system components60 that provide only limited service/system access, typically through codes or command lines.
A preferred embodiment display andinput system10 uses agame platform70 as its foundation. Thegame platform70 uses two separate processors connected by a serial line, preferably RS-232. The first processor, referred to as the input/output processor80 (IOP), contains no video or sound hardware. TheIOP80 is responsible for all hard real time processing requirements (e.g., approximately sub 200 milliseconds), which are typically hardware driven requirements. TheIOP80 contains all of thegame logic34, random number generators (RNG), host input/output (I/O), device I/O, and the core main and personality EPROMs. The term “mains,” refers to the majority of the code that runs the physical hardware and peripherals related to the wagering game. The term “personalities” refers to code that contains the rules of the wagering game, which include by way of example only, and not by way of limitation, game odds, probabilities, winning symbols, and the like.
The second processor is a diskless, PENTIUM class PC-basedprocessor90. Theprocessor90 accesses a CD-ROM (read-only drive) that controls video and sound output. The graphics, sound files, presentation software, and basic operating system are stored on the CD-ROM. A modified BIOS chip, referred to as a BIOS+, provides typical PC boot functions, as well as verification and decryption algorithms. ThePENTIUM class processor90 is generally defined as a processor capable of supporting a graphic user interface (GUI) gaming environment. In other preferred embodiments, a non-PENTIUM class (but, substantially equivalent) processor is utilized instead of thePENTIUM class processor90. Nevertheless, it will be appreciated that this processor can be of any type including, by way of example only, and not by way of limitation, another non-PENTIUM INTEL processor, Advanced Micro Devices (AMD) processor, MOTOROLA processor, or the like.
A preferred embodiment of the display andinput system10, enables thesystem components60 to take advantage of thegame platform70, by enabling thesystem components60 to communicate directly with theprocessor90, which provides the functionality of a graphic user interface (GUI), instead of having to access service andsystem information14 from thesystem network18 through a Game Monitoring Unit (Network Interface Card). This communication between thesystem components60 and theprocessor90 enables the processor to display the service andsystem information14 from thesystem network18 through asystems interface20 via thedisplay screen40. Moreover, theprocessor90 accesses the service andsystem information14 from thesystem network18 and displays the information in thesystems interface20 without involving thegame logic process34 in theIOP gaming processor80. Thus, in a preferred embodiment, thegaming interface30 is displayed on thedisplay screen40 by thegame logic process34 in theIOP80, while thesystems interface20 is displayed on thedisplay screen40 by thesystems logic process26 in theprocessor90.
In a preferred embodiment, theprocessor90 runs two processes: thegame display process24 and thesystems logic process26. Thesystems logic process26 provides access tosystem information14 on asystem network18 via thesystems interface20. Thegame display process24 includes audiovisual capabilities necessary to generate a wagering game via thegaming interface30. Typically, these two processes are kept separate due to regulatory concerns.
As described above, thegame logic process34, runs on theIOP80. TheIOP80 runs thegame logic process34 that includes the game rules necessary to generate a wagering game via thegaming interface30. Referring again to thePENTIUM class processor90, thegame display process24 is the master process and thesystems logic process26 is the slave process. In response to a proper command, thegame display process24 relinquishes control of thevideo display screen40 to thesystems logic process26. After thesystems logic process26 has completed its functions, the systems logic process then returns control of thedisplay screen40 to thegame display process24.
The display andinput system10 utilizes thevideo display screen40 andgame platform70 to make casino services more accessible and friendly to casino patrons. In one preferred embodiment of the display andinput system10, the hardware configuration of thegame platform70 employs an existing gamingcommunication systems network18, thus decreasing implementation costs for the casino. A standardgaming network interface16 to thesystems network18, such as a Mastercom system, includes a multi-drop bus method of communicating to a keypad and display. The Mastercom system is available from Bally Manufacturing, and is described in U.S. Pat. No. 5,429,361 to Raven et al. incorporated herein by reference. One such currently utilized bus is an EPI bus (Enhanced Player Interface bus), and uses industry standard I2C hardware and signaling. The network interface16 (or equivalent system) also controls the flow of funds used with thegaming device50 within a particular casino. By utilizing the display andinput system10, thegaming network interface16 can be instructed to move funds between player's accounts and gaming devices by merely touching thedisplay screen40. In addition, many other more sophisticated commands and instructions may be provided. The display andinput system10 improves the player and casino employee interface to thegaming device50, directly at the gaming device itself.
A preferred embodiment provides a mechanism for the EPI bus to inputsystem information14 into and to retrieve system information from theprocessor90 of thegame platform70. This mechanism is preferably an I2C converter card100. The I2C converter card100 has multi-master capabilities, i.e., the card is capable of participating as both a slave and as a master. Thismulti-master card100 enables system information14 (such as information input by a player into asystems interface20 keyboard) to be sent from thePENTIUM class processor90 to theslot system network18. Likewise, thecard100 also enables system information14 (such as display messages) to be sent from thesystems network18 to theprocessor90 of thegame platform70 for viewing by the player through thesystems interface20.
Specifically, in one preferred embodiment of the display andinput system10, the I2C converter card100 is added to theprocessor90 of thegame platform70. This enables thegame platform70 to speak and understand the I2C protocol message set, and thus, communicate directly with some of the system components60 (i.e., the keypad and display). Accordingly, in a preferred display andinput system10, the functionality of these system components60 (the keypad and display) is integrated into asystems interface20, and the external hardware of these system components60 (the keypad and display) is eliminated. In another preferred embodiment of the display andinput system10, a PC board is used to convert I2C bus messages into a PC-acceptable form over a serial port. Thus, this embodiment would not require an I2C converter card100.
As shown inFIG. 2,system components60 for casino patrons and casino employees ongaming devices50 traditionally have been external devices that are attached to the gaming devices. Thesesystem components60 usually include a card reader, a keypad, and a 2-line VF display for each machine. In traditional gaming devices, thesesystem components60 are small electronic components that are added to the machine and controlled by a network interface card (referred to hereinafter as a game monitoring unit (GMU)). Thesesystem components60 communicate through the GMU to access service andsystem information14 from thesystem network18. This is in lieu of communicating through thegaming platform70. Typically, these prior system components60 (e.g., keypad, card reader, and display) communicate through the GMU using a defined I2C protocol message set.
In a preferred embodiment, the display and input system10 (shown inFIG. 1) replaces the traditional 12-digit keypad and 2-line VF display system components60 (shown inFIG. 2), which possess only limited functionality, with asystems interface20 having a touch-screen keypad and video display, and that is incorporated into thevideo display screen40 of thegaming device50. In other preferred embodiments, thesystems interface20 utilizes various other data input techniques commonly known in the art, instead of the touch-screen data entry. Thus, implementation of the display andinput system10 is an efficient, and highly beneficial, interchanging of parts that integrates the functionality ofprior system components60 into thesystems interface20, while eliminating the external hardware of those components which limited their potential utility.
In the embodiment described above, the card reader is retained as anexternal system component60 and not integrated into thesystems interface20. Thus, the cardreader system component60 still communicates through the GMU in order to access service andsystem information14 from thesystem network18, instead of communicating through thegame gaming platform70. This configuration limits the amount of information resident on an identification card (which the cardreader system component60 will scan) to only an identification number or code. However, in other preferred embodiments, all of thesystem components60 in thegaming device50 are integrated into thesystems interface20. This enables communication directly through thegame platform70 to access service andsystem information14 from thesystem network18. As such, there is no need for additional assistance from the GMU.
In an earlier configuration of thegame platform72, as shown inFIG. 2, information input into thedisplay screen40 by a player is sent only to theIOP80, and not to thePENTIUM class processor90. This configuration is utilized in theearlier game platform72 because thedisplay screen40 is used solely by thegaming interface30 that is run by thegame logic process34 located in theIOP80. Thus, the display andinput system10, as shown inFIG. 1, must also enable theprocessor90 to “see” information that is input to thedisplay screen40. This is performed by aY adapter110 that is connected to the output of thedisplay screen40. TheY adapter110 is a cable that routes the information from thedisplay screen40 to both theIOP80 and theprocessor90. TheIOP80 is generally in control of thedisplay screen40 via thegaming interface30, however, when the screen focus shifts to thesystems interface20, theprocessor90 assumes control of thedisplay screen40 using theY adapter110 so as to “see” touch-screen commands from the player via thesystems interface20.
Additionally, in theearlier game platform72 configuration, as shown inFIG. 2, information sent to thedisplay screen40 comes solely from theIOP80. ThePENTIUM class processor90 is not configured to control thedisplay screen40 in theearlier game platform72 design. Thus, the display andinput system10, as shown inFIG. 1, also includes calibration software130 that enables thePENTIUM class processor90 to calibrate itself to thedisplay screen40. The calibration software130 enables theprocessor90 to also send information to thedisplay screen40 for viewing by the player via thesystems interface20.
Traditionally, theprocessor90 employed in thegame platform70 has two on-board serial ports. Typically in thegame platform70, both PENTIUM on-board serial ports have been used. One serial port is used to communicate with theIOP80, while the other serial port is dedicated to the Game Authentication Terminal (GAT) function. This port is used by gaming regulators in order to attach to agaming device50 and perform verification operations. In a preferred embodiment of the display andinput system10, three serial ports are usually required, since thePENTIUM class processor90 must also be connected to thedisplay screen40. Thus, in order to accommodate the third serial connection from thedisplay screen40 to theprocessor90, a port expander card is added to theprocessor90, in a preferred embodiment. Alternatively, USB (Universal Serial Bus) can be used for such connections. TheIOP80 is connected to thenetwork interface16 by a serial line, preferably RS-232, in both theearlier game platform72 configuration (as shown inFIG. 2) and in thegame platform70 utilized in conjunction with the display and input system10 (as shown inFIG. 1). Moreover, USB can be implemented for these connections, as well.
In another preferred embodiment of the display andinput system10, the functions currently preformed by thenetwork interface16 are included within the systems logic processes26 that are run on theprocessor90. Preferably, the EPI bus on the I2C converter card100 is still used to connect to any remainingsystem components60, such as the card reader. Alternatively, USB can be used for such peripheral connections. However, in another preferred embodiment, the functionality of all remainingsystem components60, such as the card readers, is incorporated into thesystems interface20 run by thePENTIUM class processor90. This configuration removes the need for the GMU.
In an alternate preferred embodiment, thePENTIUM class processor90 has control over thegame logic process34 and receives touch-screen data directly from thedisplay screen40. Moreover, in this embodiment, theIOP80 is only responsible for hard real time tasks (sub200 millisecond tasks) such as de-bouncing buttons, monitoring reel spins, time outs, and other generally hardware related tasks. Thus, in this embodiment, all game logic processes34, game display processes24, and systems logic processes26 are performed by thePENTIUM class processor90. This embodiment of the display andinput system10 also allows for game rules and personalities to be downloaded via thesystem network18. Additionally, in this configuration theY adapter110 is not required, since only thePENTIUM class processor90 need directly interact with thedisplay screen40.
In this embodiment, multiple processes remain on theprocessor90. At a minimum, agame logic process34 and asystems logic process26 are included which communicate with one another over a well-defined interface. Additionally, in this embodiment, thecurrent system network18 is replaced by an industry standard, such as 10/100 base T Ethernet running overCat 5, 4 or 3. Thus, a standard 10/100 base T Ethernet card is added to thePENTIUM class processor90 in this embodiment. Preferably, the network employs TCP/IP, http, and XML messaging or a variant of XML. Nevertheless any suitable protocol may be used.
The display andinput system10 enables thegame platform70 to run asystems interface20 on thedisplay screen40 of thegaming device50 which previously had been only able to run agaming interface30. The systems interface20 enables casino patrons and employees to access service andsystem information14 from thesystem network18 directly through thedisplay screen40 of thegaming device50, and preferably includes a touch-screen keypad and display. Integrating thegaming interface30 and systems interface20 together in thedisplay screen40 provides increased flexibility and functionality, while maintaining thegame logic process34 on theIOP80 and thesystems logic process26 on theprocessor90. Separating thegame logic process34 on theIOP80 from thesystems logic process26 on thePENTIUM class processor90 provides for increased security, as well as increased compatibility due to interchangeability.
Accordingly, changes can be made to the systems interface20 (and remaining system components60) or to thegame logic process34 without impacting one another. This allows independent development organizations to proceed separately, if desired, with one organization directed towards thegame logic process34 and the other organization directed towards thesystems interface20. Yet, when a player views thedisplay screen40 of thegaming device50 that has incorporated the disclosed embodiment, the service andsystem information14 accessed through theprocessor90 appears to be integrated withgame logic process34 that is being run in theIOP80, just as thesystems interface20 and thegaming interface30 are integrated in thedisplay screen40.
A preferred embodiment of the display andinput system10 provides access to service andsystem information14 from thesystem network18 that is of interest to the player or the casino employee. Significantly, a preferred display andinput system10 is game independent. In other words, since the display andinput system10 does not affect or control game play, thesystem10 can be interchangeably utilized in conjunction with most any game, while still providing access to service andsystem information14 from thesystem network18 for the casino patron and employee provided that the game platform70 (or gaming platform with equivalent functionality) is utilized.
The advent of thegame platform70 created an environment that was ripe for the development of the display andinput system10, incorporating thesystems interface20 with a keypad and display into thevideo display screen40 of agaming device50. Since thegame platform70 includes aPENTIUM class processor90 that employs a GUI (e.g., “WINDOWS environment,” or alternatively a LINUX environment or a JAVA applet), this gaming platform enables multiple applications to be run simultaneously (providing many potential advantages for use within a gaming environment). Thus, the display andinput system10 enables an area on thedisplay screen40 to be allocated as asystems interface20 in order to show player messages that would previously have had to be displayed on an separate display device (e.g., a 2-line VF display device); such device being attached to thegaming device50. In another embodiment, a touch-screen button and/or an identification card are used by the player to activate a fullscreen systems interface20 allowing access to system functions such as cashless withdraw, balance requests, system requests, points redemption, and the like. By having theentire display screen40 accessible for thesystems interface20, the usefulness of the interface for the casino patrons (and employees) is dramatically improved.
In one embodiment, the display andinput system10 identifies the player or employee using a traditional “dumb” identification card (i.e., a card with no memory or other type of updating functionality). The display andinput system10 does not use the identification card to record winnings, losses, game plays, or any other type of information. Instead, the identification card contains only a unique player or employee identification number that is permanently and unalterably embedded within the card. All other player information (winnings, losses, game plays, etc.) is stored and accessed on a back-end server, as referenced by the number from the identification card. It will be appreciated, however, that other type of cards may be used, e.g., smart cards, but the enhanced processing and memory capabilities are not required to practice a disclosed embodiment of the display andinput system10.
In one embodiment of the display andinput system10, as shown inFIG. 3, asmall message area112 on thedisplay screen40 is reserved for use by thesystems interface20 during game play. In this specific embodiment, the systems interface20 scrolls system messages to the player within thissmall message area112 of thedisplay screen40, while the remainder of the display screen is used bygaming interface30. The scrolling message can be set at any desired length. This message might state, for example, “Welcome to Harrah's Las Vegas! You have 1200 bonus points. Would you like to make a hotel or dinner reservation?” Additionally, by inserting a player identification card into a card reader and/or selecting aplayer services button114, asystems interface keypad116 is activated for additional player services functionality, as shown inFIG. 4.
Referring now toFIGS. 5-7, in another embodiment, thedisplay screen40 includes a touch-screen button118 that activates a fullscreen systems interface20 when selected. (In some embodiments insertion of an identification card is also required.) In this embodiment, thegame logic process34 in theIOP80 recognizes when this touch-screen button118 on thedisplay screen40 is selected and, in response, relinquishes control of thedisplay screen40 to thePENTIUM class processor90, thus deactivating (or minimizing) thegaming interface30 and activating (or maximizing) thesystems interface20. Meanwhile, theprocessor90 running thesystems interface20 takes control of thedisplay screen40 and provides a means of directly accessing the service andsystem information14 from thesystem network18 using touch-screen data entry. This is accomplished without involving thegame logic process34 in theIOP80.FIG. 5 shows thedisplay screen40 of thegaming device50 with only the fullscreen gaming interface30 activated, in accordance with a disclosed embodiment.FIG. 6 shows thedisplay screen40 of thegaming device50 with only the full screen player services interface20 activated, in accordance with a disclosed embodiment.FIG. 7 shows thedisplay screen40 of thegaming device50 with only the full screenemployee systems interface20 activated, in accordance with a disclosed embodiment.
In one exemplary embodiment of the display andinput system10 that utilizes a card reader (or other identification technique) to recognize a particular player, thesystems interface20 displays a textual greeting to that player, for example, “Welcome, Mr. Smith!” in response to recognizing Mr. Smith's identification card. Preferably, as shown inFIG. 6, thesystems interface20 also has touch-screen icon buttons120 including, by way of example only, and not by way of limitation, “Beverages,” “Change,” “Services,” “Transactions,” and “Return to Game.” Further, each of theseicon buttons120, when selected, launches a new full screen display within thesystems interface20 to display to the player. For example, in one embodiment, when the “Transactions”icon buttons120 is selected, a new screen is activated that includes the text, “Mr. Smith, Account Balance: Bonus Points=1200, Player Funds=$150, Available Credit=$850, Casino Matching Funds Available=$25,” as well as the “Return to Game”icon buttons120. As a further example, when the player selects a “Cashless Withdraw” button in other embodiment, a new screen is activated that includes a touch-screen keypad and the textual question, “How much do you want?” as well as “Enter,” “Clear,” and “Back” buttons. Preferably, this interface also includes an “Information” button that, when selected, launches a new screen within thesystems interface20 that provides answers to frequently asked questions and other useful information. Moreover, the interface preferably includes a “History” button that, when selected, launches a new screen within thesystems interface20 that provides a history log of all transactions and other actions performed on thatgaming device50.
As discussed above, a preferred embodiment of the display andinput system10, as shown inFIG. 1, uses agame platform70 as its foundation. Thegame platform70 itself, is a highly advantageous system, that enables casino owners to draw off of the large library of casino game functions available in a traditional master processing unit (MPU) stand-alone platform, while adding the graphics and sound capabilities of a personal computer. Current stand-alone MPU systems also contain drivers for all types of casino games (slot, poker, keno, etc.). TheIOP80 in thegame platform70 is derived from a traditional MPU stand-alone platform, and provides access to the above-described library of casino game functions and drivers for these casino games.
However, the PC industry has a large number of tools that can create graphics and sound very efficiently. For this and other reasons, thegame platform70 includes aPENTIUM class processor90 running an operating system that accepts PC sound and graphics content. In one preferred embodiment, the operating system in theprocessor90 of thegame platform70 is MICROSOFT NT embedded. Thegame platform70 combines the strengths of a traditional stand-alone MPU game engine with the audio and visual capabilities that are available in the PC industry. Thus, thegame platform70 enables PC content to be used directly on a game platform vis-à-vis a WINDOWS operating system environment (or other suitable graphic user interface (GUI)).
TheIOP80 in thegame platform70 differs from the traditional stand-alone MPU architecture in several ways. For example, in thegame platform70 the contents of the graphics chips are not located in the IOP80 (as they are in the MPU), but rather are replaced by enhanced graphics and animations stored on the CD-ROM. Additionally, in thegame platform70 the contents of sound chips are not located on the IOP80 (as they are in the MPU), but rather they are replaced by enhanced sound files stored on the CD-ROM. ThePENTIUM class processor90 has presentation software for displaying the graphics and sound upon request from thegame logic process34 within theIOP80.
In one preferred embodiment, thegame platform70 utilizes an “EPROM and CD-ROM paired” design. In this configuration, theIOP80 contains thegame logic34, random number generators (RNG), and core mains and personalities. In addition, theIOP80 does all of the input/output activities for driving hoppers, buttons, lights, acceptors, etc. These functions are all contained on EPROM and are verifiable by traditional IC testing techniques. The BIOS+on the PENTIUM motherboard verifies the CD-ROM before loading any properties on to the PENTIUM RAM. The CD-ROM contains the operating system, display, and audio and graphics programs.
One preferred example of the media flow proceeds in the following sequence. (1) Verify the boot chip using traditional IC verification techniques. (2) The power comes up. The BIOS+ runs a self-verification on its own code. (3) Theprocessor90 begins executing the BIOS+. (4) The BIOS+ comes up far enough to read the CD-ROM. Verification is run on the entire CD-ROM contents using a SHA-1 algorithm contained with in the BIOS+. (5) A private key encrypted SHA-1 value, located in a secure location on the CD-ROM, is decrypted with the public key and algorithm contained on the BIOS+. (6) The results of the SHA-1, and now decrypted SHA-1 value, are compared. A match allows the operating system, program files, graphics, and audio to be loaded into the PENTIUM's RAM from the CD-ROM. (7) Since theIOP80 can boot faster from EPROM, the IOP waits to hear that the PENTIUM has booted and loaded all needed software components into RAM. (8) TheIOP80 then checks the PENTIUM software levels using the same scheme used to match game driver levels to personality chip requirements. If the versions are acceptable, theIOP80 confirms that the game personality contained in the EPROM matches the game personality on the CD-ROM. (9) The game then proceeds, driven by theIOP80. Thus, the game personality contained in the EPROM on theIOP80, and the game personality on the PENTIUM CD-ROM, are a matched set. If the two do not match, a fatal tilt results, rendering the game inoperable. This also means that the regulators must approve both the EPROM and the CD-ROM for every game released for distribution and approval.
In another preferred embodiment, thegame platform70 utilizes a “CD-ROM controlled” design. In this configuration, with the introduction of the BIOS+ driven SHA-1 CD-ROM verification, the game personality contents are placed only on the CD-ROM, and not on an EPROM located in theIOP80. This design provides the advantage of reducing the testing and distribution workload for gaming regulators. By utilizing this configuration, only a CD-ROM needs to be tested and released for new game content. This also eliminates the potential for compatibility mismatches between a personality chip in an EPROM of theIOP80, and in the CD-ROM contents associated with thePENTIUM class processor90. Moreover, this “CD-ROM controlled” design also eases the need for compatibility checks between theIOP80 andPENTIUM class processor90. Existing game driver level checks between theIOP80 mains and the game personalities remain in place and are equally effective in this RAM-based personality design. Once thePENTIUM class processor90 boots and successfully verifies the contents of the CD-ROM, a binary image of the game personality is downloaded from the CD-ROM to a RAM chip located within theIOP80. This RAM chip occupies the same socket that the game personality EPROM did in theIOP80 in the “paired”design game platform70.
In thegame platform70, since there are two motherboards, theIOP80 andPENTIUM90, each must have an operating system. TheIOP80 preferably uses VRTX as its operating system. VRTX is a reliable, real-time operating system with multi-tasking capabilities that has been used in the gaming environment for many years. ThePENTIUM class motherboard90 preferably uses MICROSOFT WINDOWS NT embedded. NT embedded is particularly effective since many tools and developers are available for producing creative content on WINDOWS-style platforms. However, other operating systems could also be selected in other embodiments, depending on many factors, including the desired graphic user interface (GUI).
WINDOWS NT embedded differs from standard desktop operating systems, such as WINDOWS98 and WINDOWS NT, which require a hard drive. These operating systems make use of a swap file to move programs and data between RAM and a hard disk. However, NT embedded eliminates the need for a swap file. NT embedded is customizable in this regard, allowing the swap file size to be set to zero so that no writable mass storage device is required. Further, NT embedded is preferably modified and compiled with only those components required to run a particular game (or games). In other words, there are no additional drivers or services provided. Typically, there is no GUI interface, keyboard, mouse drivers, or TCP/IP stack (or networking capabilities whatsoever). Preferably, this modified version of NT embedded is completely stand-alone and provides none of the traditional accessing “handles.”
Referring now to security requirements, a primary objective of the security design is to satisfy all security requirements and gaming jurisdiction directives. The relevant directives require that the verification information and the verification code reside on a “conventional ROM device.” However, pursuant to the proposed amendments to Gaming Regulations, a “conventional ROM device” may include FLASH memory components provided that they cannot be altered while installed in a gaming device. To satisfy these directives, the verification algorithm in thegame platform70 resides on a conventional ROM device, secured within the PENTIUM/IOP assembly.
The security architecture logically divides the game security components inside and outside of an information security (INFOSEC) boundary. The critical game security components are located on the inside the INFOSEC Boundary, as shown inFIG. 8. On the secure inside of the INFOSEC Boundary, thegame platform70 includes theIOP80 and thePENTIUM class processor90, connected by a serial line. Preferably, theIOP portion80 of the design is based on a MOTOROLA 68332 and EPROMs on a VRTX operating system. Preferably, on thePENTIUM portion90, the BIOS+ chip plugs into the PENTIUM motherboard and is physically secured within the PENTIUM assembly chassis. The conventional ROM device is socketed into thePENTIUM motherboard90 and can be covered with a tamper-evident material. The CD-ROM assembly92 is logically outside of the INFOSEC boundary. The CD-ROM assembly92 contains a commercial off-the-shelf CD read-only reader and the game CD-ROM. The game CD-ROM assembly92 contains a custom version of NT embedded as the operating system, presentation programs, audio content, and video content.
Thegame platform70 provides a secure boot and initial CD-ROM verification. The EPROM verification software resides within theIOP80. The verification software verifies all EPROMs on the IOP board80 (i.e., mains and personalities) upon application of power to thegame platform70. Next, after the application of power to the platform, the BIOS+ performs a self-verification on all of its code. Once satisfactorily completed, thePENTIUM class board90 begins executing code from the BIOS+ contained in the conventional ROM device. This process verifies the conventional ROM device and detects any substitution of the BIOS+.
Upon boot-up of the PENTIUM, the BIOS+ executes a SHA-1 verification of the entire CD-ROM. The digital signature is calculated and compared with an encrypted signature stored in a secure location on the CD-ROM using the RSA private/public key methodology. If the signatures compare, the BIOS+ allows the modified NT embedded operating system to boot from the CD-ROM, followed by the game presentation software. After verification of the total CD-ROM, the modified (and now verified) NT embedded operating system is loaded from the CD-ROM into the PENTIUM RAM. Next, display programs and content are verified, before being loaded into the IOP RAM to be executed for normal game operation.
Thegame platform70 performs many verification processes during boot-up and operation. Each game personality EPROM image on theIOP80 is compared with those on the accompanying CD-ROM. Further, verification of all files on the CD-ROM is conducted by an algorithm that originates on the BIOS+. TheIOP board80 informs thePENTIUM90 of any tilts that occur. Additionally, theIOP80 initiates re-verification of the CD-ROM. Moreover, on the EPROM-controlledIOP80, memory is continuously tested in order to immediately catch any changes.
The advantages of utilizing the display andinput system10 are numerous. These advantages include, by way of example only, and not by way of limitation, simplification of the use and appearance of thesystems interface20 by integrating theinterface20 into thedisplay screen40; providing fonts and icons which are larger and more aesthetically appealing; providing special services to players, (e.g., multiple languages, assistance for handicapped individuals); lowering overall system costs by eliminating hardware components; lowering maintenance costs as a result of the fewer hardware components; facilitating interactive uses of thesystems interface20 andgame interface30; providing the ability to customize the “look and feel” of thesystems interface20 for players and casino employees; facilitating the efficiency of modifying thesystems interface20; and allowing system features and components to be modified without affecting the game design or logic.
Referring now toFIG. 9, in a presently preferred embodiment, a “store-and-forward”patron messaging system200 enables personalized messages to be sent to the player at agaming device210 for any of several purposes, including by way of example only, and not by way of limitation: (1) enabling broadcasts to specific groups identified by marketing, (2) enabling a variety of player-specific or group-specific promotional efforts, and (3) using the game position (i.e., a gaming device210) as a communications station. Typically, these messages are sent from the casino that is hosting the patron, however, in some embodiments, the casino may store and forward messages from individuals (e.g., friends, family, and the like) or from third parties (restaurants, airlines, transportation service companies, outside marketing companies, and the like). Such “externally originating” store and forward messages from individuals that are sent via outside e-mail accounts, mobile phones, and/or PDAs (personal digital assistants) will be discussed in further detail below.
The “store-and-forward”patron messaging system200 is a feature that can be implemented on aplayer tracking device215, such as a GMU (Game Monitoring Unit) (e.g., the MC300 GMU or other similar device) of agaming device210. Themessaging system200 provides an expanded level of service to patrons of casino loyalty clubs, promoting the improved actual and perceived access that derives from increased personalization. As a result, additional features for marketing and product differentiation are provided.
In a presently preferred embodiment, the “store-and-forward”patron messaging system200 provides increased personalization also promotes membership in a property's loyalty program (e.g., “your card keeps you connected”). Themessaging system200 provides product differentiation as well as a platform that enables future expansion of this feature as a new method of contacting patrons. Further, with thisindividualized messaging system200, alerts and other notifications generated by the system can be combined with various degrees of personalization so that the player receives additional attention. Moreover, other applications also including by way of example only, and not by way of limitation: specialized messages for slot tournaments, special offers, event notification, and the like.
In one presently preferred embodiment, thepatron messaging system200 is a store-and-forward messaging system that enables specific personalized messages to be created, stored on a system-side server, and forwarded to an Enhanced Player Interface panel (or iView-type player tracking device) where a given patron is engaged in slot play (or other gaming play). This is typically initiated when the player inserts a (loyalty) club card into a card reader at agaming device210. Specifically, in one embodiment, a message entry and management component of the “store-and-forward”patron messaging system200 is a lightweight application that is installed at one or more central locations, (e.g. one or more cages, a loyalty club booth, a front desk, a concierge, and the like). Typically, themessaging system200 enables an operator to (1) enter a short message intended for a specific loyalty club member, or (2) review and accept an incoming short message intended for a specific loyalty club member. In one embodiment, such a message is stored on a system server (often, but not necessarily, a back-end server system), and then is forwarded to the specified patron at thegaming device210 when the system detects the player card in use on the casino floor.
In a presently preferred embodiment, thepatron messaging system200 preferably, but not necessarily, utilizes a PIN (personal identification number) system to help ensure that these personalized messages reach only the intended recipient, since these messages are typically more individualized and/or private than normal (standardized) system messages. In one embodiment, thepatron messaging system200 system is implemented as an extension of a player loyalty system. Additionally thepatron messaging system200 may also support other group targeted messaging, third party marketing, paging services, patron-to-patron messaging, and the like. In another aspect of one embodiment, specific types of functionality, such as patron-to-patron paging, are offered as an additional pay service; possibly as part of an “a la carte” type of optional feature. In still another aspect of one embodiment, patrons are offered financial incentives (e.g., free credits; store, restaurant, or hotel room discounts, enhanced game odds or bonuses, and the like) for accepting marketing messages (e.g., casino marketing message, third party marketing, and the like).
In one presently preferred embodiment, the “store-and-forward”patron messaging system200 is a closed, internal messaging system for sending personalized messages to casino patrons that may be read and acknowledged (including possibly responding thereto) using an Enhanced Player Interface panel or iView-type player tracking device as an interface terminal. Additionally such a message, since it is necessarily brief, could be printed on a ticket printer. The issuing of a return receipt to the sender that confirms receipt of message is another component in a preferred embodiment of thepatron messaging system200.
In another presently preferred embodiment, the “store-and-forward”patron messaging system200 also includes support for “externally originating” messages and/or e-mails. These “externally originating” store and forward messages may be sent from individuals via outside e-mail accounts, mobile phones, and/or PDAs. For example, if someone knows that their friend (John Smith) likes to play at Harrah's casino, they could send John a message at the e-mail address of: jsmith@harrahs.player.com. Such a message might read, “John, give me a call when you get this message. Bob.” The “store-and-forward”patron messaging system200 would then store this message, and forward the message to John Smith when it detected his “card-in.”
In another aspect of a presently preferred embodiment, a “store-and-forward”patron messaging system200 that enables “externally originating” store and forward messages also utilizes a filter system for spam or other undesirable e-mails. Examples of filter systems include, by way of example only, and not by way of limitation: a “white list” of approved individuals and/or e-mail addresses; CAPTCHAS (Completely Automated Public Turing test to tell Computers and Humans Apart) or other optical recognition tests designed to distinguish computers from humans; and/or a Challenge and Response test that responds to incoming e-mail messages by sending a challenge to the claimed sender of the e-mail. The Challenge and Response filter then requires the sender to perform some action outlined in the challenge message to assure delivery of their message, which otherwise will typically not be delivered.
As described above, in one specific embodiment, the “store-and-forward”patron messaging system200 is implemented as a feature of a GMU (e.g., the MC300 GMU, or other suitable player tracking device215). Typically, thepatron messaging system200 works in concert with a server-side system, specifically a loyalty or player tracking systems. In this regard, thepatron messaging system200 is programmable to relay or forward stored, personal messages to individual patrons. Other possible uses of themessaging system200 include, by way of example only, and not by way of limitation: (1) notification to a patron that his table is ready at the restaurant (enabling him to continue slot play while waiting), (2) a directed alert to one or more players that the airport shuttle has arrived (enabling continued slot play rather than standing outside to wait), (3) personal paging (rather than using the public address system), and (4) delayed paging of a patron who is expected to arrive later.
As explained above, in one embodiment, thepatron messaging system200 functions as an extension of a loyalty club system (e.g. CMS/CMP). Typically, a CMS/CMP (casino management personnel/system) system performs casino player tracking and collects regular casino floor and player activity data. Thepatron messaging system200 stores a message (typically text, but as game-side user interface progress, graphics and other multimedia contents may also be included in the message) until the player's card is detected on the casino floor (e.g., by a card reader in a gaming device210). In one embodiment, the message text itself is entered using a message entry and management system that enables an operator to (1) identify the loyalty club member, (2) enter a brief message, and (3) enter any other relevant processing particulars (auto-delete on delivery, require PIN entry to read message, delete if not read in 5 days, or other options as adopted in the design). Further, in another aspect of one embodiment, the receipt of such a message triggers other processes including, by way of example only, and not by way of limitation: issuing bonuses, sending a server to the patron's gaming station, complementary drinks, and the like.
In one presently preferred embodiment, the “store-and-forward”patron messaging system200 has three components: (1) a message entry andmanagement system220 through which an operator enters and manages message texts intended for individuals or groups of individuals, (2) apatron message database230, which is typically integrated into the casino loyalty system's server-side application, and (3) amessage response system240 that is typically incorporated into the code of the player tracking device215 (e.g., MC300 GMU code) to handle delivery and response interaction with the player at the game terminal itself.
Additionally, in one embodiment, the GMU215 (other player tracking device in which thepatron messaging system200 is incorporated) does not communicate directly with the loyalty/player tracking system servers (e.g., CMS/CMP) but rather depends on a SDS server (or other suitable interfacing network infrastructure) to bridge those components. Thus, in such a network configuration, a protocol extension is utilized between SDS and the CMS/CMP servers (e.g., or other message protocol modification at the GMU215).
In one presently preferred embodiment, the message entry andmanagement system220 is integrated into the player tracking software. In another presently preferred embodiment, the message entry andmanagement system220 is implemented as a stand-alone application that is installed at stations normally without requiring access player tracking data. In such an environment, entering a personalized message presents a naturally well suited feature (e.g., concierge functions) to player tracking and player loyalty systems and programs.
In another aspect of a presently preferred embodiment, messages are optionally classified as: (1) private (created for viewing by one person only, requiring a PIN for access), (2) group (a limited broadcast for people waiting for a shuttle, a group waiting for a restaurant reservation, and the like), or (3) public (broadcast to all or most of the patrons currently playing slots; other casino games; or games of a particular theme, denomination, wager amount, location, or the like). In still another aspect of one embodiment, messages have additional parameters including, by way of example only, and not by way of limitation: (1) the ability to be marked for automatic deletion once they have been confirmed as read, (2) the ability to be set to expire if not read within a certain number of days, or (3) the ability to have messages marked as important, with an optional notification to the originator if the message is not picked up within a given period of time.
In one aspect of a presently preferred embodiment, once the loyalty (player tracking) system detects a card insertion by a player who has a stored message waiting, an alert is sent to the player informing him of waiting message. This alert is added to any other messages that my be normally sent to a player at the start of game play (depending upon the details of the particular loyalty system). In one embodiment, after the player responds to the alert (confirming that he's ready to receive the message), the message is transmitted (typically, but not necessarily, via a SDS server) to the GMU215 (or other suitable player tracking device). The GMU215 (or other suitable player tracking device) in turn sends the message to an attacheddisplay device250. In one embodiment, the player then acknowledges that he has read the message. Once the player acknowledges that the message has been read: (1) the message can be saved, (2) the message can be printed, (3) the message can be automatically deleted, or (4) the player can be prompted with message deletion options, depending on that message's settings.
Continuing, in another aspect of a presently preferred embodiment, after confirmation has been obtained that the player has read the message, theGMU215 notifies the SDS server that the message had been read. At this point the SDS server forwards this message to the loyalty server (e.g., CMS/CMP server) for final processing. Typically, but not necessarily, for messages marked as “private,” the loyalty system transmits the expected PIN along with the message so that theGMU215 may authenticate the player's identity before releasing the message text. Alternatively, in another embodiment, the PIN query is formulated as a separate message and sent back to the loyalty system for authentication. However, this method does result in somewhat increased network traffic.
Currently, somedisplay devices250 employed by manycasino gaming devices210 are a two-line VFD (EPI) unit, with a line width of20 characters. Therefore, in these type of gaming embodiments, it is efficient to limit the message to a length that is manageable in such ashort display device250. Aslarger display devices250 with more capabilities are deployed (e.g., iView-type multi-media-enabled screens) the length limit may be extended. As such, in a presently preferred embodiment, the message length limit is configurable. Similarly, since some EPI (enhanced player interface) input devices are numeric keypads, responses are typically limited to yes/no or multiple choice lists in these embodiments. For input devices that are deployed with touch-screen capabilities, the possible kinds of response are expanded to include short reply messages.
Although the disclosed embodiments has been described in language specific to computer structural features, methodological acts, and by computer readable media, it is to be understood that the disclosed embodiment defined in the appended claims is not necessarily limited to the specific structures, acts, or media described. Therefore, the specific structural features, acts and mediums are disclosed as exemplary embodiments implementing the disclosed embodiment.
Furthermore, the various embodiments described above are provided by way of illustration only and should not be construed to limit the disclosed embodiment. Those skilled in the art will readily recognize various modifications and changes that may be made to the disclosed embodiment without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the disclosed embodiment, which is set forth in the following claims.