CROSS-REFERENCE TO RELATED APPLICATIONSThe present application claims priority to U.S. Provisional Application Serial No. ______ (not assigned), filed Sep. 11, 2003 (Attorney Docket No: 60518,169) and is a continuation-in-part application of U.S. patent application Ser. No. 09/967,571, filed Sep. 28, 2001.[0001]
FIELD OF THE INVENTIONThe present invention relates generally to gaming machines, and more particularly, to a system and method for remotely accessing the player tracking system.[0002]
BACKGROUND OF THE INVENTIONThe growth and competition in the casino gaming market in recent years and the increasingly sophisticated and complex technology being integrated into the gaming environment, at the individual game, casino management, and auditing levels, presents both challenges and opportunities to game manufacturers, gaming establishment operators, and regulatory agencies. The technological capabilities and requirements of, for example, advanced electronic games, multi-site gaming operations, detailed player tracking, wide area progressive jackpots, and various alternatives to the use of currency and coins by players, all present a potentially huge pool of ever-changing data which can be of great value to casino operators (from a management standpoint) and to regulators from an audit/compliance standpoint.[0003]
Players may also be given an incentive through a player tracking club. Usually, a player is identified during play by a player tracking ID card and/or a player identification number (PIN). The player tracking system tracks the player's play and awards player tracking points according to established criteria. The player tracking points may be redeemed for prizes, such as complimentary meals or merchandise.[0004]
Typically, the player tracking system is accessed at workstation or computers which are linked to a remote server. The computer applications which are used to access the player tracking system for various functions are stored on the workstation.[0005]
However, these types systems are inflexible and do not provide the casino operator with the maximum benefit and advantages available from the information and systems now available.[0006]
The present invention is aimed at one or more of the problems as set forth above.[0007]
SUMMARY OF THE INVENTIONIn one aspect of the present invention, a remote system for use with a gaming system is provided. The gaming system implements a player tracking system and has at least one gaming machine playable by a player. A host computer is coupled to the at least one gaming device by a network. The remote system includes a remote device and a remote network interface coupled to the remote device for exchanging data between the host computer and the remote device The data includes sign-up information to enroll the player in the player tracking system.[0008]
In another aspect of the present invention, a method for enrolling a player in a player tracking system for use with a gaming system, is provided. The gaming system includes at least one gaming device playable by the player. The method includes the steps of sending a fillable form to a remote device and filling out the form with data, by a user, on the remote device for enrolling the player in the player tracking system.[0009]
BRIEF DESCRIPTION OF THE DRAWINGSOther advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings wherein:[0010]
FIG. 1 is a block diagram of a remote system for use with a gaming system, according to an embodiment of the present invention;[0011]
FIG. 2 is block diagram of an gaming machine and a remote device, according to an embodiment of the present invention;[0012]
FIG. 3 is a more detailed block diagram of the remote device of FIG. 2 and a computer program application, according to an embodiment of the present invention;[0013]
FIG. 4 is a block diagram of a web client operating on the remote device of FIG. 2, according to an embodiment of the present invention;[0014]
FIG. 5A is a first flow diagram of a method for enrolling a player in a player tracking system, according to an embodiment of the present invention;[0015]
FIG. 5B is a second flow diagram of a method for enrolling a player in a player tracking system, according to a second embodiment of the present invention;[0016]
FIG. 6 is a diagrammatic illustration of a remote player signup form according to an embodiment of the present invention;[0017]
FIG. 7A is a first flow diagram of a method for remotely accessing player information, according to an embodiment of the present invention;[0018]
FIG. 7B is a second flow diagram of a method for remotely accessing player information, according to a second embodiment of the present invention;[0019]
FIG. 8 is a diagrammatic illustration of a remote player information screen, according to an embodiment of the present invention;[0020]
FIG. 9A is a first flow diagram of a method for remotely accessing information related to a device, according to an embodiment of the present invention;[0021]
FIG. 9B is a second flow diagram of a method for remotely accessing information related to a device, according to a second embodiment of the present invention;[0022]
FIG. 10 is a diagrammatic illustration of a remote asset information screen, according to an embodiment of the present invention;[0023]
FIG. 11A is a first flow diagram of a method for remotely processing jackpot tickets, according to an embodiment of the present invention;[0024]
FIG. 11B is a second flow diagram of a method for remotely processing jackpot tickets, according to a second embodiment of the present invention;[0025]
FIG. 12 is a diagrammatic illustration of a cash ticket information screen, according to an embodiment of the present invention;[0026]
FIG. 13A is a first flow diagram of a method for remotely processing jackpot tickets, according to an embodiment of the present invention;[0027]
FIG. 13B is a second flow diagram of a method for remotely processing jackpot tickets, according to a second embodiment of the present invention;[0028]
FIG. 14A is a diagrammatic illustration of a jackpot information screen, according to an embodiment of the present invention;[0029]
FIG. 14B is a diagrammatic illustration of a fill information screen, according to an embodiment of the present invention;[0030]
FIG. 15A is a first flow diagram of a method for remotely processing hopper fills, according to an embodiment of the present invention;[0031]
FIG. 15B is a second flow diagram of a method for remotely processing hopper fills, according to a second embodiment of the present invention;[0032]
FIG. 16A is a diagrammatic illustration of a hopper fill information screen, according to an embodiment of the present invention;[0033]
FIG. 16B is a diagrammatic illustration of a fill information screen according to an embodiment of the present invention;[0034]
FIG. 17A is a first flow diagram of a method for remotely providing a table rating interface, according to an embodiment of the present invention;[0035]
FIG. 17B is a second flow diagram of a method for remotely providing a table rating interface, according to a second embodiment of the present invention;[0036]
FIG. 18A is a diagrammatic illustration of an open table rating screen, according to an embodiment of the present invention;[0037]
FIG. 19A is a first flow diagram of a method for remotely providing an attendance interface, according to an embodiment of the present invention;[0038]
FIG. 19B is a second flow diagram of a method for remotely providing an attendance interface, according to a second embodiment of the present invention;[0039]
FIG. 20 is a diagrammatic illustration of a player attendance information screen, according to an embodiment of the present invention;[0040]
FIG. 21A is a first flow diagram of a method for remotely providing a surveillance interface, according to an embodiment of the present invention;[0041]
FIG. 21B is a second flow diagram of a method for remotely providing a surveillance interface, according to a second embodiment of the present invention;[0042]
FIG. 22 is a diagrammatic illustration of an alert information screen, according to an embodiment of the present invention;[0043]
FIG. 23A is a flow diagram of a first method for adjusting points assigned to a player in a player tracking system, according to an embodiment of the present invention;[0044]
FIG. 23B is flow diagram of a second method for adjusting points assigned to a player in a player tracking system, according to another embodiment of the present invention;[0045]
FIG. 24 is a diagrammatical illustration of a point adjustment request form, according to an embodiment of the present invention;[0046]
FIG. 25A is a flow diagram of a method for issuing vouchers to a player, according to an embodiment of the present invention;[0047]
FIG. 25B is a flow diagram of a second method for issuing vouchers to a player, according to another embodiment of the present invention;[0048]
FIG. 26 is a diagrammatic illustration of a voucher information screen, according to an embodiment of the present invention;[0049]
FIG. 27A is a flow diagram of a method for redeeming printed vouchers using a remote device, according to an embodiment of the present invention;[0050]
FIG. 27B is a flow diagram of a second method for redeeming printed vouchers using a remote device, according to an embodiment of the present invention;[0051]
FIG. 28 is a diagrammatic illustration of a voucher information form, according to an embodiment of the present invention;[0052]
FIG. 29A is a first flow diagram of a method for displaying a list of outstanding vouchers for a selected player, according to a first embodiment of the present invention;[0053]
FIG. 29B is a second flow diagram of a method for displaying a list of outstanding vouchers for a selected patron, according to a second embodiment of the present invention; and[0054]
FIG. 30 is a diagrammatic illustration of a voucher information dialogue, according to an embodiment of the present invention.[0055]
DETAILED DESCRIPTION OF INVENTIONI. Overview[0056]
With reference to the drawings and in operation, the present invention provides a[0057]system10 and methods related to a player tracking method or to one ormore gaming devices12.
The[0058]gaming devices12 may be electronic orelectric gaming machines13, such as slot or video slot machines, poker or video poker machines, arcade or video arcade games, and the like, but may also include other types ofdevices12A connected to thesystem10, such as virtual gaming machines (for online gaming), electronic interfaces for use with table games, vending machines, token or credit dispensing machines, ticket redemption machines, or any other electric or electronic device connected to the network.
II. The Gaming System[0059]
In one embodiment, the[0060]system10 and methods may be embodied or implemented via an entertaining management and monitoring system orgaming system14 which is shown in block diagram form in FIG. 1. The entertainment andmonitoring system14 may include may additional functions such as, real-time multi-site, slot accounting, player tracking, cage credit and vault, sports book data collection, Point of Sale (POS) accounting, keno accounting, bingo accounting, and table game accounting, a wide area progressive jackpot, and electronic funds transfer (EFT). Two exemplary systems are disclosed in U.S. patent application Ser. No. 09/967,571. filed Sep. 28, 2001, and U.S. Provisional Patent Application Serial ______ (Not Assigned), filed Sep. 11, 2003 (Attorney Docket No. 60,518-169), both of which are hereby incorporated by reference.
In the illustrated embodiment, the[0061]system10 includes eightelectronic gaming machines13A-13H. However, it should be noted that the present invention is not limited to any number ofdevices12 ormachines13. In one embodiment, themachines13 are organized into banks (not shown), each bank containing a plurality ofmachines13.
The[0062]gaming devices12 are connected via anetwork16 to one ormore host computers18, which are generally located at a remote or central location. Thecomputer18 includes acomputer program application20 which maintains one ormore databases22. In one embodiment, the database(s) are Oracle database(s).
The[0063]computer program application20 anddatabases22 may be used to record, track, and report accounting information regarding thegaming devices12 and/or users of thegaming devices12 or players of theelectronic gaming machines13. Additionally, thecomputer program application20 anddatabases22 may be used to maintain information related to player tracking accounts (see below).
In general, the[0064]electronic gaming machines13 are playable by aplayer24. Theplayer24 may select one of theelectronic gaming machines13C to play and insert a coin, credit, coupon, and/or player tracking card (not shown) into the chosengaming machine13C. Generally, theelectronic gaming machines13C have an associated number of credits or coins required in order to play. In the case of video slot or poker games, the game is played and an award in the form of credits may be awarded based on a pay table of thegaming machine13.
With reference to FIG. 2, a block diagram of a suitable[0065]electronic gaming machine13C is shown.
The[0066]machine13C comprises agame controller26, or central processing unit (CPU), a coin-bill management device28, adisplay processor30, aRAM32 as a memory device and a ROM34 (generally provided as an EPROM). TheCPU26 is mainly composed of a microprocessor unit and performs various calculations and motion control necessary for the progress of the game. The coin-bill management device28 detects the insertion of a coin or a bill and performs a necessary process for managing the coin and the bill. Thedisplay processor30 interprets commands issued from theCPU26 and displays desirable images on adisplay36. TheRAM32 temporarily stores programs and data necessary for the progress of the game, and theROM34 stores, in advance, programs and data for controlling basic operation of the machine12C, such as the booting operation thereof, game code and graphics.
Input to the gaming device[0067]12C may be accomplished via mechanical switches or buttons or via a touchscreen interface (not shown).Such gaming machines12 are well known in the art and are therefore not further discussed.
The[0068]player24 is identified via the player tracking card and/or a player identification number entered intoplayer tracking device38 at each gaming machine12 (see below). Player tracking accounts may be used, generally, to provide bonuses to a player, in addition to the award designated by, in the case of a video slot or poker machine, the gaming machine's12 paytable. These bonuses may be awarded to theplayer24 based a set of criteria, including, but not limited to, a) the player's play on the machine12C, b) the player's overall play, c) play during a predetermined period of time, and d) the player's birthday or anniversary, or e) any other definable criteria. Additionally, bonuses may be awarded on a random basis, i.e., to a randomly chosen player or randomly chosengame12. Bonuses may also be awarded in a discretionary manner or based on other criteria, such as, purchases made at a gift shop or other affiliated location.
In one embodiment, the[0069]player tracking device38 includes aprocessor40, a playeridentification card reader42 and/or anumeric keypad44, and adisplay46. In one embodiment, thedisplay46 is a touchscreen panel and thenumeric keypad44 is implemented thereon.
The[0070]player24 may be identified by entry of a player tracking card into the playeridentification card reader42 and/or entry of a player identification number (PIN) on the numerickey pad46. Theplay tracking device38 may also be used to communicate information between thecomputer18 and the corresponding gaming machine12C. Theplayer tracking device40 may also be used to track bonus points, i.e., incentive points or credits, downloaded from thecomputer18.
In one aspect of the present invention, the bonuses are awarded as bonus points. In one embodiment, the bonus points are incentive points. In another embodiment, the bonus points are credits.[0071]
The incentive points may converted to credits using a predetermined ratio. The predetermined ratio may be 1 or any other desired ratio. The predetermined ratio may also be varied based on determined criteria, e.g., the[0072]gaming machine12 being played, the player, or the time of day. Incentive points may be designated as cashable or non-cashable. The incentive points in a player account may be downloaded to one of thegaming machines12 for play.
III. Remote System[0073]
Returning to FIG. 1, the present invention provides a[0074]remote system48 for use with thegaming system14. Theremote system48 provides access to various features or functions of thegaming system14 by one or moreremote devices50.
In the illustrated embodiment, there are four[0075]remote devices50A,50B,50C,50D, however, this is for discussion purposes only. Any number ofremotes devices50 may be included.
The[0076]remote devices50 are connected to thenetwork16 through anetwork link52. In one aspect of the present invention, thenetwork link52 is a wireless connection. In one embodiment, the wireless connection uses the IEEE 802.11 standard, e.g., 802.11b or 802.11g. However, it should be noted that wireless links using other standards may also be used where appropriate, such as a short range radio link (e.g., a link using the technology known as “Blue Tooth”). In another aspect of the present invention, thenetwork link52 may be a wire link.
The[0077]remote devices50 are generally used by auser54 and provides, as discussed below, access to various data and/or functions of thegaming system14.
In one aspect, the[0078]user54 is an employee of the gaming established where thegaming system14 is operating. Typically, theuser54 has an assigned role (or type) based on their job description. Typical roles may include, but are not limited to, system administrator, supervisor, pit, pit manager, slot floor employee, patron host, player's club, security, security supervisor, slot attendant, slot director, slot shift supervisor, slot technician, sports and racebook, surveillance, and table supervisor.
In one embodiment of the present invention, the[0079]remote devices50 provides access to one or more types of data and/or one or more functions based on the assigned role of theuser54. In one embodiment, aremote device50 may provide access to one or more of the following functions: remote patron signup, remote patron information, remote device information, remote cash ticket processing, remote jackpot ticket processing, remote hopper fill ticket processing, remote table rating interface, remote attendance, remote surveillance, adjusting a player's bonus or comp points, issuing comp vouchers to a player, redeeming printed vouchers, listing and redeeming outstanding vouchers assigned to a player, and retrieving and displaying information related to a specificremote device50. Each of these functions is described more fully below.
In one embodiment of the present invention, the[0080]remote device50A may be a mobile computer based on the PALM operating system or Microsoft Windows operating system. With specific reference to FIG. 3 in one embodiment of the present invention, theremote device50A includes a processor58, amemory60 for storing applications and data, and adisplay64. Thedisplay64 may be a touchscreen display. Theremote device50A may also include abar code reader66. Thebar code reader66 may be used to read a player ID card number from the ID card or to read a device ID number from a device12 (see below). One such mobile computer is available from Symbol Technologies, Inc. of Holtsville, N.Y. as model number SPT 1800.
Additionally or alternatively, the[0081]remote device50A may include anID card reader62 capable of reading magnetic stripe ID cards.
In another embodiment, the[0082]remote devices50 are desktop, laptop, notebook, and/or sub-notebook computers.
Returning to FIG. 3, in one embodiment of the present invention, the[0083]remote device50A includes aweb client56 which is stored in thememory60 and run on the processor58. Theweb client56 is connected to thecomputer program application20 running on thehost computer18 through thenetwork link52.
In one aspect of the present invention, all interaction with the user, including the display of data and queries and the input of data, is handled by the[0084]web client56. Theweb client56 is responsible for acquiring user input, e.g., through forms, and formatting and presenting information to theuser54. Theweb client56 is a computer application which is accessed via a web browser, such as Microsoft Internet Explorer, available from Microsoft Corp., of Redmond Calif. Theweb client56 may be written in Hypertext Mark-Up Language (HTML) and include one or more servlets (see below) which may be written in a computer programming language, such as Java.
As shown in FIG. 3, the[0085]computer program application20 implements aremote network interface66. Theremote network interface68 couples theweb client56 with thedatabase22. In one embodiment, theremote network interface68 obtains data from thedatabase22, formats the data, e.g., into an HTML response, and returns the formatted data to theweb client56.
In one aspect of the present invention, the[0086]remote network interface68 is coupled to thedatabase22 by one or more data objects70. In one embodiment, data is stored in thedatabase22 in data tables. The data objects70 handle requests from theremote network interface68, abstracts the required data from the database tables and/or sets data into the database tables.
As shown, in FIG. 3, the data objects[0087]70 include a plurality of first data object (DBOBJECTS)76, at least one second data object (VDBOBJECTS)74, and a third data object (BUSINESS OBJECT)72.
The first data objects[0088]76 are coupled to the database tables and abstract specific database tables for the at least onesecond data object74. The first data objects76 handle retrieving and setting data into specific database tables.
The at least one[0089]second data object74 is coupled to the first data objects76 assemble multiple first data objects76 into a singlethird data object72. The at least one second data object74 abstract the third data object72 from the database tables.
The third data object[0090]72 is coupled to the at least onesecond data object74. The third data object receives queries from the remote network interface, retrieves responsive data from the database (through the first and second data objects74,76), formats the responsive data and returns the responsive data to the remote network interface.
With reference to FIG. 4 in one embodiment, the[0091]web client56 is written in HTML. In the illustrated embodiment, theweb client56 includes aform layer78, amenu layer80, alogin layer82, and aservlet layer84.
The[0092]login layer82 provides security. It allows theuser54 to logon to theremote system48. In one embodiment, theuser54 enters a name and password to logon. Theuser54 may also be required to enter or select the site at which theuser54 is located.
The[0093]menu layer90 allows theuser54, once logged on, to navigate to and between servlets. The servlets are downloaded to theremote device50 from thehose computer18 as needed. Themenu layer90 also handles providing access to those servlets to which theuser54 has access, typically based on an assigned role (see above).
The form and servlet layers[0094]78,84 provides common functionality for the servlets.
A. Remote Player or Patron Signup[0095]
With reference to FIGS. 5A, 5B, and[0096]6, theremote system48 allows theuser54, such as a slot floor employee or patron host to quickly and remotely enroll a player or patron in the player tracking system. Theuser54 will generally have a number of unassigned player ID cards (not shown). Theuser54 may be approached by aplayer24 who requests to enroll or may approach theplayer24 and ask if they would want to enroll.
If the[0097]player24 wants to enroll, theuser54 enters sign-up information or data onto theremote device50A and gives the player24 a player ID card. The sign-up information is sent by theremote device50A to thehost computer18 and stored in thedatabase22 along with the ID card number of the assigned player ID card.
In one embodiment, the[0098]user54 navigates to a servlet for enrolling theplayer24 using themenu layer80. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
In one embodiment, only the player's name and a player identification number (PIN) is required. The player identification number may be selected by the[0099]player24 or be a temporary default PIN assigned to the player ID card. The player ID card number to be assigned to theplayer24 may be read by theID card reader62 or thebarcode reader66, as appropriate.
When the[0100]user54 selected enrollment from the menu layer, theweb client56 relays the request to theremote network interface68. Theremote network interface68 retrieves a signup form and sends the signup form to theremote device50A for display and interaction with theuser54 via theweb client56.
With specific reference to FIG. 5A, a first method[0101]88 for enrolling theplayer24 in the player tracking system using theremote device50A, according to a first embodiment of the present invention is shown. In afirst step90, a fillable signup form is sent to theremote device50A. In asecond step92, the player information (or enrollment data) is entered on the signup form via theremote device50A.
With specific reference to FIG. 5B, a[0102]second method94 for enrolling theplayer24 in the player tracking system using theremote device50A, according to a second embodiment of the present invention is shown.
In a[0103]first step96, the signup form is displayed on theremote device50A. In astep98, if all required information, e.g., a zip code, was entered then themethod94 proceeds to athird step100. If all required information was not entered, then an error message is displayed in afourth step102 and the process returns to thefirst step96.
In the[0104]third step100, the zip code is processed, i.e., the corresponding city and state are determined. In afifth step104, if the zip code is not valid, then themethod94 displays an error message (fourth step102). If the zip code is valid, then themethod94 proceeds to asixth step106.
In the[0105]sixth step106, the enrollment data is stored are stored as records in thedatabase22 and control proceeds to aseventh step108. In theseventh step108, if a room number, i.e., the hotel room hotel in which theplayer24 is residing was entered, then the process proceeds to aneighth step110. Otherwise, themethod96 returns to thefirst step96.
In the[0106]eighth step110, an external system (not shown), may be notified for the creation of room lock keys. One such system In one embodiment as discussed below, the room lock keys may be used for the player tracking system and/or room locks.
An[0107]exemplary signup form110, displayed on theremote device50A by theweb client56 is shown in FIG. 6. As discussed above, in one embodiment the only information required is the player's name and a PIN number. Theexemplary signup form110 includes an entry box for the player's first, middle, andlast names112,114,116 and aPIN entry box118. After the required information has been entered, theuser54 selects asave player button120 to send the data to thehost computer18.
In another embodiment, the[0108]signup form110 requires additional information. The additional information may include, but is not limited to the following: player ID card number (from pre-printed card or left blank for system generated card), address, zip code, country, telephone number(s), room number, number of adult cards, number of child cards, signup date, and one or more notes. Child cards operate only the lock of a hotel room. Adult cards work in the player tracking system and operate the room lock.
Additionally as discussed above, the[0109]display46 is a touchscreen display. In one embodiment, the display may capture a signature of theplayer24. The player's signature may be also be sent to thehost computer18 with the enrollment data and stored in thedatabase22.
B. Remote Patron Information[0110]
With reference to FIGS. 7A, 7B, and[0111]8, theremote system48 allows theuser54, such as a slot floor employee or patron host to quickly and remotely request and receive player information related to aspecific player24. This may be done prior to approaching theplayer24 who is using aspecification gaming machine13 or after theuser54 has been approached by theplayer24.
In the illustrated embodiment, interaction with the[0112]user54, including receiving input and displaying the player information, is accomplished using theweb client56.
In one aspect of the present invention, the[0113]user54 may identify theplayer24 through entry of the player's ID card number into theremote device50A. In one embodiment, the ID card number may be entered manually. In another embodiment, the ID card number may be read from the player's ID card using thecard reader62 or thebarcode reader66 as appropriate.
In another aspect of the present invention, if the[0114]player24 is utilizing one of thedevices12 and has identified themselves to the player tracking system by entry of the ID card into thedevice12 and/or entered in their PIN number, theuser54 may identify theplayer24 by entered a device ID number associated with therespective device12. As discussed below, the player tracking system has associated the ID number of thedevice12 with theplayer24 while theplayer24 is using thedevice12. Thus, using the device ID number, thehost computer18 may determine the ID number of theplayer24.
In one embodiment, the[0115]user54 navigates to a servlet for requesting player information using themenu layer80. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
The servlet displays a request form which is displayed to the[0116]user54. As discussed above, theuser54 may either enter the player ID card number of the player24 (manually or reading it from the ID card) or a device ID number associated with adevice12 being used by theplayer24. Theuser54 enters identification information (in the form of the player ID card number or the device ID number) which is returned to thehost computer18 by theweb client56. Theremote network interface68 receives the identification information, retrieves the player information and returns the player information to theremote device50A where it is displayed.
With specific reference to FIG. 7A, a[0117]first method124 for remotely requesting information relating to aplayer24 is provided. In afirst step126, identification information is received at the remote device. In asecond step128, the identification information is received at the host computer. In athird step130, the player information is retrieved from thedatabase22 as a function of the identification information.
With specific reference to FIG. 7B, a[0118]second method132 for remotely requesting player information using theremote device50A is shown, according to a second embodiment of the present invention.
In a[0119]first step134, the request form is displayed on theremote device50A. In asecond step136, if a player ID card number has been entered, then themethod132 proceeds to athird step138. In thethird step138, the ID card number is validated. In afourth step140, if the ID card number is not valid, an error message is displayed in afifth step142. If the ID card number is valid, then the message proceeds to asixth step144.
In the[0120]sixth step144, the query (request for player information) is processed by thehost computer18. The player (or patron) information is then returned to theremote device50A to be displayed in anseventh step146.
In the[0121]second step136, if an ID card number has not been entered, then themethod132 proceeds to aneighth step148. In theeighth step148, if a device (or asset) number has been entered, then themethod132 proceeds to aninth step150. If a device number has not been entered, then themethod132 proceeds to thefifth step142 and an error message is displayed.
In the[0122]ninth step150, the device number is validated. In atenth step152, if the device number is valid, then control proceeds to thefifth step144. Otherwise, themethod132, proceeds to thefifth step142.
With specific reference to FIG. 8, in one embodiment the returned player information is displayed on the[0123]remote device50A in aplayer information screen152. In the illustrated embodiment, the player information may include, but is not limited to, a player name, a player address, a patron host name, at least one anniversary date, e.g., birthday, wedding anniversary, sign-up date, any meters tracked by the player tracking system, such as bonus points (incentive points or credits), jackpots, coin-out, coin-in, and win/(loss).
C. Remote Device Information[0124]
With reference to FIGS. 9A, 9B and[0125]10, theremote system48 allows theuser54, such as a slot floor employee or a slot technician, to quickly remotely request and receive asset or device information related to angaming device12.
In the illustrated embodiment, interaction with the[0126]user54, including receiving input and displaying the asset information is accomplished using theweb client56.
In one aspect of the present invention, the[0127]user54 may identify thegaming device12, such as anelectronic gaming machine13 by entering identification information. In one embodiment, the identification information is an asset or device ID number. The ID number may be manually entered by theuser54. In another embodiment, theuser54 may use thebarcode reader66 to read a barcode, located on thegaming device12, containing the device ID number.
In one embodiment, the user navigates to a servlet for requested device information using the[0128]menu layer80. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
The servlet displays a request form (not shown) which is displayed to the[0129]user54. After the asset or device ID number entered, the ID number is sent to theremote network interface68, which process the query, and returns the requested device information to theremote device50A where it is displayed.
With specific reference to FIG. 9A, a[0130]first method154 for remotely requesting information related to aspecific gaming device12 is provided. In afirst step156, identification information is received at theremote device50A. In asecond step158, the identification information is received at thehost computer18. In athird step160, the device information is retrieved from thedatabase22 as a function of the identification information.
With specification reference to FIG. 9B, a[0131]second method162 is for remotely requesting device information using theremote device50A is shown, according to an embodiment of the present invention.
In a[0132]first step164, the request form is displayed on theremote device50A. In asecond step166, if an asset number has been entered then themethod162 proceeds to athird step170. Otherwise, an error message is displayed in afourth step168.
In the[0133]third step170, the asset number is validated. In afifth step172, if the asset number is valid then themethod162 proceeds to asixth step174. In thesixth step174, the query (request for asset information) is processed by thehost computer18. The device or asset information is returned to theremote device50A to be displayed in aseventh step176.
With specific reference to FIG. 10, in one embodiment the returned asset information is displayed on the[0134]remote device50A in a remoteasset information screen178. In the illustrated embodiment, the asset information may include, but is not limited to, an asset number, a device number, a denomination (the base denomination the device accepts), a manufacturer, a model, a master prom identifier, a game prom identifier, an online MAC address, an online TCP/IP address, a date on floor, and any or all available system meters, such as, coin in, coin out, games player, and jackpots.
D. Remote Cash Ticket Processing[0135]
In one embodiment, a gaming system includes a gaming machine that may issue a cash ticket. The cash ticket is issued when a player elects to quit playing a particular gaming machine after accumulating a number of credits. The number of credits is generally the sum of an original number of credits, any downloaded credits, any inserted credits, and any winnings (or losses).[0136]
With reference to FIGS. 11A, 11B and[0137]12, theremote system48 allows theuser54, such as a slot floor employee or patron host to quickly and remotely process a cash ticket issued by aparticular gaming machine13. The cash ticket issued by thegaming machine13 includes cash ticket information such as a cash ticket id and a value printed on the cash ticket. Theuser54 may be approached by aplayer24 who requests to cash out a cash ticket and receive the value of the cash ticket.
If the[0138]player24 wants to cash out, theuser54, via theremote device50A, requests a cash ticket form. Theremote network interface68 sends the cash ticket form to theremote device50A.
When the[0139]user54 selects the cash ticket form from themenu layer80, theweb client56 relays the request to theremote network interface68. Theremote network interface68 retrieves the cash ticket form and sends the cash ticket form to theremote device50A for display and interaction with theuser54 via theweb client56.
The cash ticket form may include a cash ticket button for selecting by the[0140]user54 to communicate each step of the cash ticket processing that has occurred. For example, the cash ticket button is a request button that theuser54 selects when theuser54 is approached by theplayer24. The cash ticket button may be an acknowledge button selected by theuser54 after validating the cash ticket and prior to processing the cash ticket. The cash ticket button may also be a process button selected by theuser54 after confirming that the cash ticket may be paid. The cash ticket button may also be a paid button to confirm that theuser54 has paid to theplayer24 the value of the cash ticket. Each time the cash ticket button is selected by theuser54, theremote device50A sends a notification of the event and theremote network interface68 stores the notification in thehost computer18 which then updates the data in the database23 relating to the status of the cash ticket processing.
The cash ticket form may also include a field wherein the[0141]user54 enters the cash ticket id such as a number. Theuser54 enters cash ticket information or data onto theremote device50A to verify that the cash ticket is valid and has not been previously processed. If the cash ticket id is invalid or the cash ticket has already been processed, an error message is displayed at theremote device50A. The cash ticket information is sent by theremote device50A to thehost computer18 where cash ticket information is retrieved and sent back to theremote device50A. In one embodiment, the cash ticket id is entered manually, then theuser54 selects a cash ticket entry button to send the cash ticket form to thehost computer18. In another embodiment, the cash ticket id is encoded in a barcode printed on the cash ticket. The bar code is read by the bar code reader and sent to thehost computer18.
In one embodiment, the[0142]user54 navigates to aservlet24 using themenu layer80 for inputting and retrieving cash ticket information. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
After the validity of cash ticket is confirmed, the cash ticket information is retrieved from the[0143]database22 by theremote network interface68 and displayed to theuser54 at theremote device50A. With specific reference to FIG. 12, in one embodiment the returned cash ticket information is displayed on theremote device50A in a cashticket information screen196.
The cash ticket information includes ticket details[0144]168, such as a gaming machine identifier. The gaming machine identifier includes a gaming machine id and a gaming machine location to identify the gaming machine issuing the cash ticket. The ticket details168 further include a date identifier for identifying the issue date of the cash ticket, a shift identifier for identifying the work shift during which the cash ticket was issued, and a value identifier for identifying the value of the cash ticket, thereby allowing theuser54 to confirm the value printed on the cash ticket and the value stored in thehost computer18.
With specific reference to FIG. 11A, a[0145]first method170 for processing a cash ticket using theremote device50A, according to a first embodiment of the present invention is shown. In afirst step172, a fillable cash ticket form is sent to theremote device50A. In asecond step174, the cash ticket information is entered on the cash ticket form via theremote device50A.
With specific reference to FIG. 11B, a[0146]second method176 for processing the cash ticket using theremote device50A, according to a second embodiment of the present invention is shown.
In a[0147]first step178, the cash ticket form is displayed on theremote device50A. In a second step180 a cash ticket id is entered. In athird step182, the cash ticked id is verified. If the cash ticket id is invalid, then themethod176 proceeds to afourth step184. If the cash ticket id corresponds to a valid unprocessed cash ticket, then themethod178 proceeds to afifth step186. In thefourth step184, an error message is displayed and themethod176 returns to thefirst step178.
In the[0148]fifth step186, the ticket details are retrieved from thedatabase22 and control proceeds to aseventh step188. In theseventh step188, the ticket details are processed and display at theremote device50A. Theuser54 may then pay the player. As discussed above, the user may be required to acknowledge through the selection of the cash ticket button at each step. Once the user has acknowledged that the player has been paid, the remote display displays a cash ticket paid message in aneighth step190.
E. Remote Jackpot Ticket Processing[0149]
In one embodiment, a gaming system includes a gaming machine that may issue a jackpot ticket. In one embodiment, a jackpot ticket is issued by the gaming machine when a play of the game results in a win having an associated number of credits over a predetermined number of credits. Such a jackpot causes the[0150]gaming machine12 to lock up, issue an alert and prevents the player from playing.
In another embodiment, the[0151]gaming machine12 does not issue jackpot ticket. However, theuser54 may be required to go to thegaming machine12 to process the jackpot
With reference to FIGS. 13A, 13B and[0152]14A, theremote system48 allows theuser54, such as a slot floor employee, to quickly and remotely process a jackpot issued by aparticular gaming machine13. The jackpot issued by thegaming machine13 has associated jackpot information such as a jackpot id and a value of the jackpot.
In one embodiment, the jackpot is dispensed by the[0153]gaming machine13, while jackpots above the threshold require interaction with an employee, i.e., theuser54. Additionally, the jackpot may be required to be paid by a cashier. If a jackpot ticket has been issued, theuser54 may be approached by aplayer24 who requests to collect the value of the jackpot. Alternatively, theuser54 may have to travel to thegaming machine13 to process the jackpot.
If the[0154]player24 wants to collect the jackpot, theuser54, via theremote device50A, requests a jackpot form (not shown). Theremote network interface68 sends the jackpot form to theremote device50A.
When the[0155]user54 selects the jackpot form from themenu layer80, theweb client56 relays the request to theremote network interface68. Theremote network interface68 retrieves the jackpot form and sends the jackpot form to theremote device50A for display and interaction with theuser54 via theweb client56.
The jackpot form includes a jackpot button for selecting by the[0156]user54 to communicate each step of the jackpot processing that has occurred. For example, the jackpot button is a request button that theuser54 selects when a jackpot is announced and theuser54 is approached by theplayer24 to collect the jackpot. The jackpot button may be an acknowledge button selected by theuser54 after validating the jackpot and prior to processing the jackpot. The jackpot button may also be a process button selected by theuser54 after confirming that the jackpot may be paid. The jackpot button may also be a paid button to confirm that theuser54 has paid to theplayer24 the value of the jackpot. Each time the jackpot button is selected by theuser54, theremote device50A sends a notification of the event and theremote network interface68 stores the notification in thehost computer18 which then updates the data in thedatabase22 relating to the jackpot status in the jackpot processing.
In one embodiment, the jackpot form lists several fields having jackpot information, including the jackpot identifier, fill detail and jackpot status, for all active jackpots. The[0157]user54 may select either the jackpot identifier or the jackpot status. If theuser54 selects the jackpot identifier, then jackpot detail is displayed on theremote device50A. If theuser54 selects jackpot status, then the jackpot status advances to an advanced jackpot status, a notification is sent to thehost computer18 to update thedatabase22 and theremote device50A displays the updated jackpot status on the jackpot form.
In another embodiment, the jackpot form includes a field wherein the[0158]user54 enters the jackpot id such as a number. Theuser54 enters jackpot information or data onto theremote device50A to verify that the jackpot is valid and has not been previously processed. If the jackpot id is invalid or the jackpot has already been processed, an error message is displayed at theremote device50A. The jackpot information is sent by theremote device50A to thehost computer18 where jackpot information is retrieved and sent back to theremote device50A.
In one embodiment, the jackpot id is entered manually, then the[0159]user54 selects a jackpot entry button to send the jackpot form to thehost computer18. In another embodiment, the jackpot id is read by the bar code reader and sent to thehost computer18.
In one embodiment, the[0160]user54 navigates to aservlet24 using themenu layer80 for inputting and retrieving jackpot information. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
After the validity of jackpot is confirmed, the jackpot information is retrieved from the[0161]database22 by theremote network interface68 and displayed to theuser54 at theremote device50A. With specific reference to FIG. 14A, in one embodiment the returned jackpot information is displayed on theremote device50A in ajackpot information screen238. With reference to FIG. 14B, in another embodiment, the returned fill information is displayed on theremote device50A in afill information screen240.
The jackpot information includes fill detail[0162]198, such as a gaming machine identifier. The gaming machine identifier includes a gaming machine id and a gaming machine location to identify the gaming machine issuing the jackpot. The fill detail198 further includes a gaming date for identifying the issue date of the jackpot, a gaming shift for identifying the work shift during which the jackpot was issued, and a jackpot value for identifying the value of the jackpot, thereby allowing theuser54 to confirm the value printed on the jackpot and the value stored in thehost computer18.
If the[0163]user54 selects the jackpot identifier field on the jackpot form, jackpot detail200 as a function of the jackpot identifier is retrieved from thehost computer18 and displayed at theremote device50A. Jackpot detail200 may include the gaming machine id and the gaming machine location to identify the gaming machine issuing the jackpot. The jackpot detail200 may further include a gaming machine name for identifying the particular game issuing the jackpot, a gaming denomination for identifying the particular type of credit issued, the gaming date for identifying the issue date of the jackpot, and the gaming shift for identifying the work shift during which the jackpot was issued.
With specific reference to FIG. 13A, a[0164]first method202 for processing a jackpot using theremote device50A, according to a first embodiment of the present invention is shown. In afirst step204, a selectable jackpot form is sent to theremote device50A. In asecond step206, the jackpot information is entered on the jackpot form via theremote device50A.
With specific reference to FIG. 13B, in another aspect of the present invention, a[0165]method208 for displaying or processing jackpots is shown. In afirst step210, all pending jackpots are displayed. In one embodiment, the list of pending jackpots includes at least a jackpot id and a jackpot status. In asecond step214, if theuser54 selects jackpot id of a jackpot, themethod208 proceeds to athird step222. If theuser54 selects the jackpot status, themethod208 proceeds to afourth step236. In thethird step222, jackpot details are displayed on theremote device50A. In thefourth step236, the selected jackpot is processed by theuser54.
F. Remote Hopper Fill Ticket Processing[0166]
With reference to FIGS. 15A, 15B,[0167]16A and16B, theremote system48 allows theuser54, such as a slot floor employee to quickly and remotely process a hopper fills in aparticular gaming machine13, i.e., insert credits or coins into the game machine's hopper to be dispensed to theplayer24 when a jackpot has been won, when the game machine has run out or is low on credits. The number of credits remaining in the hopper (not shown) are tracked by the host computer18 (orgame machine13 and relayed to the host computer) which issues an alert when the number of credits remaining reaches a certain amount so that the hopper may be restocked with credits such as coins, tokens, paper money, or the like.
Once an alert is issued, the[0168]user54, via theremote device50A, may acknowledge the alert and request a hopper fill form (not shown). Theremote network interface68 sends the hopper fill form to theremote device50A.
When the[0169]user54 selects the hopper fill form from themenu layer80, theweb client56 relays the request to theremote network interface68. Theremote network interface68 retrieves the hopper fill form and sends the hopper fill form to theremote device50A for display and interaction with theuser54 via theweb client56.
In one embodiment, the hopper fill form includes a hopper fill button (not shown) for selecting by the[0170]user54 to communicate each step of the hopper fill processing that has occurred. For example, the hopper fill button is a request button that theuser54 selects when an alert is announced and theuser54 approaches thegaming machine13 to process the hopper fill. The hopper fill button may also be an acknowledge button selected by theuser54 after validating the hopper fill and prior to processing the hopper fill. The hopper fill button may also be a process button selected by theuser54 after confirming that the hopper is being restocked. The hopper fill button may also be a fill button to confirm that theuser54 has completed restocking the hopper. Each time the hopper fill button is selected by the user, theremote device50A sends a notification of the event and the remote interface stores the notification in thehost computer18 which then updates the data in thedatabase22 relating to the credit status in the hopper fill processing.
In one embodiment, the hopper fill form lists several fields having hopper fill information, including the hopper fill identifier, fill detail and credit status, for all active hopper fills. The[0171]user54 may select either the hopper fill identifier or the credit status. If theuser54 selects the hopper fill identifier, then hopper fill detail is displayed on theremote device50A. If theuser54 selects credit status, then the credit status advances to an advanced credit status, a notification is sent to the host computer to update the database and the remote device displays the updated credit status on the hopper fill form.
In another embodiment, the hopper fill includes a field wherein the[0172]user54 enters the hopper id, such as a number. Theuser54 enters hopper fill information or data onto theremote device50A to verify that the hopper id is valid and has not been previously processed. If the hopper id is invalid or the hopper fill has already been processed, an error message is displayed at theremote device50A. The entered hopper fill information is sent by theremote device50A to thehost computer18 where additional hopper fill information is retrieved and sent back to theremote device50A. In one embodiment, the hopper id is entered manually, then theuser54 selects a hopper fill entry button to send the hopper fill form to thehost computer18. In another embodiment, the hopper id is read from a barcode on the hopper or on thegame machine13 by thebar code reader66 and sent to thehost computer18.
In one embodiment, the[0173]user54 navigates to aservlet24 using themenu layer80 for inputting and retrieving hopper fill information. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
After the validity of hopper is confirmed, the hopper fill information is retrieved from the[0174]database22 by theremote network interface68 and displayed to theuser54 at theremote device50A. With specific reference to FIG. 16A, in one embodiment the returned hopper fill information is displayed on theremote device50A in a hopperfill information screen288. With reference to FIG. 16B, in another embodiment, the returned fill information is displayed on theremote device50A in afill information screen290.
The hopper fill information includes fill detail[0175]248, such as a gaming machine identifier. The gaming machine identifier includes a gaming machine id and a gaming machine location to identify the gaming machine requiring the hopper fill. The fill detail248 may further include a gaming date for identifying the issue date of the fill, a gaming shift for identifying the work shift during which the fill was issued, and/or a credit value for identifying the value of the credits supplied.
If the[0176]user54 selects the hopper fill identifier field on the hopper fill form, hopper fill detail as a function of the hopper fill identifier is retrieved from thehost computer18 and displayed at theremote device50A. In one embodiment, the hopper fill detail includes the gaming machine id and the gaming machine location to identify the gaming machine requiring the credit or hopper fill. The hopper fill detail may further include a gaming machine game for identifying the particular game issuing the credits, a gaming denomination for identifying the particular type of credit issued, the gaming date for identifying the fill date of the hopper, and/or the gaming shift for identifying the work shift during which the hopper was filled.
With specific reference to FIG. 15A, a[0177]first method252 for processing a hopper fill using theremote device50A, according to a first embodiment of the present invention is shown. In afirst step254, a selectable hopper fill form is sent to theremote device50A. In asecond step256, the hopper fill information is entered on the hopper fill form via theremote device50A.
With specific reference to FIG. 15B, a[0178]second method258 for processing the hopper fill using theremote device50A, according to a second embodiment of the present invention is shown.
In a[0179]first step260, theremote device50A displays selectable hopper fill information, including pending fills having a credit status and hopper fill identifier. In an alternate embodiment, the hopper fill form orgaming machines13 having hopper fill information, is displayed on theremote device50A. In one embodiment, the hopper fill information is selectable. In another embodiment the hopper fill information is fillable requiring credit refill.
In a second step[0180]262, theuser54 selects a pending fill. If theuser54 selects the hopper fill identifier, control proceeds to athird step264, the fill detail is displayed and control returns to thefirst step260. If theuser54 selects the credit status, then the credit status advances to an advanced credit status and control returns to thefirst step260. If all required information was not entered, then an error message is displayed and the hopper fill form is displayed again.
Then he hopper id is verified. If the hopper id is not valid, then the[0181]method258 displays an error message (fourth step266). If the hopper id is valid, then the fill detail is retrieved from thedatabase22 and displayed at theremote device50A.
After the hopper is filled with credits by the[0182]user54, the remote display displays a credit filled message.
If the user selects another hopper fill identifier, the hopper fill detail is retrieved from the host computer and displayed on the[0183]remote device50A.
If the user selects a credit status, the credit status advances to an advanced credit status which is then displayed at the[0184]remote device50A.
G. Remote Table Rating Interface[0185]
With reference to FIGS. 17A, 17B, and[0186]18, theremote system48 allows theuser54, such as a slot floor employee or patron host, to quickly and remotely process a table rating and, send and receive table rating information450 related to aspecific player24. A table rating allows thegaming system10 to rate or rank theplayer24 by determining his or her given session or play, determine his or her worth to the casino, and assign a point award.
In the illustrated embodiment, interaction with the[0187]user54, including receiving input and displaying the player information, is accomplished using theweb client56.
In one aspect of the present invention, the[0188]user54 may identify theplayer24 through entry of the player's ID card number into theremote device50A. In one embodiment, the ID card number may be entered manually. In another embodiment, the ID card number may be read from the player's ID card using thecard reader62 or thebarcode reader66 as appropriate.
In another aspect of the present invention, if the[0189]player24 is utilizing one of thedevices12 and has identified themselves to the gaming system by entry of the ID card into thedevice12 and/or entered in their PIN number, theuser54 may identify theplayer24 by entering a device ID number associated with therespective device12. As discussed below, the gaming system has associated the ID number of thedevice12 with theplayer24 while theplayer24 is using thedevice12. Thus, using the device ID number, thehost computer18 may determine the ID number of theplayer24.
In one embodiment, the[0190]user54 navigates to a servlet for requesting player information using themenu layer80. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
The servlet displays a table rating form which is displayed to the[0191]user54. As discussed above, theuser54 may either enter the player ID card number of the player24 (manually or reading it from the ID card) or a device ID number associated with adevice12 being used by theplayer24. Theuser54 enters the player information (in the form of the player ID card number or the device ID number) which is returned to thehost computer18 by theweb client56. Theremote network interface68 receives the player information, retrieves the table rating information450 and returns the table rating information450 to theremote device50A where it is displayed. With specific reference to FIG. 18, in one embodiment the returned table rating information is displayed on theremote device50A in an open tablerating form screen486.
When the player information is entered, the[0192]remote network interface68 determines whether the information is valid. If valid, the table rating information450 is stored in or retrieved from thedatabase22 as a function of the identification information. If invalid, an error message is displayed on theremote device50A. The player information450 includes a player identifier such as a player number, player name and address, and the like.
The purpose of the table rating information[0193]450 is to register and display a patron's risk or ranking at a particular gaming machine. The risk or ranking informs theuser54 about the player's24 spending or risk habits during a given session of play at a gaming machine.
The player information includes a table rating status of open or closed for a[0194]particular gaming machine13. If the status is open, the player is currently playing theparticular gaming machine13, thereby enabling the user to generate a table rating. When theplayer24 decides to discontinue playing, theuser54 swipes the player's24 ID card and brings up the table rating status in a closed status form (not shown) having fillable fields and a status button. Theuser54 enters table rating information about the session, including but not limited to the player name, thegaming machine13, the gaming machine location, the time theplayer24 began play, the time theplayer24 ceased play, the average bet by theplayer24, and the amount won by theplayer24 when leaving thegaming machine13. Theuser54 selects the status button and the table rating is established, sent to the database via the remote network interface and stored therein. Thereafter, any remote devices displaying a table rating form relating to theparticular gaming machine13 displays the newly entered table rating information.
If, after swiping the player's card, the[0195]player24 does not have an open table rating, an open table form is displayed on the remote device. The open table form is fillable by theuser54 with table rating details which may include the player's name, the zone information (gaming machine location), a selectable list of the bank information (gaming machines13) available at that location, a seat identifier at which theplayer24 is seated, the estimated average bet by theplayer24, the bet value the player is opening thegaming machine13 with. The zone information entered by theuser54 may also include bank information as a function of the zone information. The bank information associated with the zone information is displayed and theuser54 selects the appropriate banking information associated with theparticular gaming machine13.
Once the information is entered, the[0196]user54 selects the status button to send and store the table rating details to thedatabase22 and update the table rating status to open. The updated table rating status is sent to all remote devices displaying information for the particular gaming table. The update may be sent automatically or upon request.
With specific reference to FIG. 17A, a[0197]first method452 for remotely requesting table rating information relating to aplayer24 is provided. In afirst step454, a fillable form is sent to a remote device for receiving table rating information. In asecond step456, the table rating information is received at the host computer for processing a table rating for the player.
With specific reference to FIG. 17B, a[0198]second method458 for remotely processing a table rating using theremote device50A is shown, according to a second embodiment of the present invention.
In a[0199]first step460, the table rating form is displayed on theremote device50A.
In a second step, if a player ID card number is entered, then the method proceeds to a third step. The table rating status is then returned to the[0200]remote device50A to be displayed in thethird step464.
In a[0201]fourth step466, if the table rating status is open, the closed status form is displayed on the remote device.
In a[0202]fifth step468, t the table rating is closed and control returns to thefirst step460. In thethird step464, if the table rating status is not open, then themethod458 proceeds to asixth step470.
In the[0203]sixth step470, the system determines if the remote network interface is a casino. System view shows the zones of the system and control proceeds to aseventh step472. If the system view shows the zones then control proceeds to aseventh step472, otherwise control proceeds to aninth step476.
In the[0204]seventh step472, zone information is displayed.
In an[0205]eighth step474, zone is selected and control proceeds to theninth step476.
In the[0206]ninth step476, the system determines if the remote network interface shows the zone view and control proceeds to atenth step478.
If the system shows the zone view, then bank information is shown in the[0207]tenth step478 and control proceeds to aneleventh step480. Otherwise, control proceeds to atwelfth step482.
In the[0208]eleventh step480, a bank is entered, and control proceeds to thetwelfth step482.
In the[0209]twelfth step482, the open rating form is displayed and control proceeds to athirteenth step484.
In the[0210]thirteenth step484, theuser54 enters table rating information.
In the[0211]fourteenth step486, the table rating is opened and control returns to thefirst step460.
H. Remote Attendance[0212]
With reference to FIGS. 19A, 19B, and[0213]20, theremote system48 allows theuser54, such as a slot floor employee or patron host, to quickly and remotely request, send and receive player attendance information350 related to aspecific player24. For example, a marketing or special event may be targeted to patrons or players meeting defined criteria. Each player who attends the event is identified as their attendance is stored in the player tracking system.
In the illustrated embodiment, interaction with the[0214]user54, including receiving input and displaying the player attendance information, is accomplished using theweb client56.
In one aspect of the present invention, the[0215]user54 may identify theplayer24 through entry of the player's ID card number into theremote device50A. In one embodiment, the ID card number may be entered manually. In another embodiment, the ID card number may be read from the player's ID card using thecard reader62 or thebarcode reader66 as appropriate.
In another aspect of the present invention, if the[0216]player24 is utilizing one of thedevices12 and has identified themselves to the gaming system by entry of the ID card into thedevice12 and/or entered in their PIN number, theuser54 may identify theplayer24 by entering a device ID number associated with therespective device12. As discussed below, the gaming system has associated the ID number of thedevice12 with theplayer24 while theplayer24 is using thedevice12. Thus, using the device ID number, thehost computer18 may determine the ID number of theplayer24.
In one embodiment, the[0217]user54 navigates to a servlet for requesting player attendance information using themenu layer80. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
The servlet displays an attendance form which is displayed to the[0218]user54. As discussed above, theuser54 may either enter the player ID card number of the player24 (manually or reading it from the ID card) or a device ID number associated with adevice12 being used by theplayer24. Theuser54 enters identification information (in the form of the player ID card number or the device ID number) which is returned to thehost computer18 by theweb client56. Theremote network interface68 receives the identification information, retrieves the player attendance information350 and returns the player attendance information350 to theremote device50A where it is displayed. With specific reference to FIG. 20, in one embodiment the returned player attendance information is displayed on theremote device50A in an playerattendance information screen384.
When the identification information is entered, the[0219]remote network interface68 determines whether the identification is valid. If valid, the gaming machine information is stored in or retrieved from thedatabase22 as a function of the identification information. If invalid, an error message is displayed on the remote device.50A. The gaming machine information includes a device identification number, and the player attendance information is retrieved from thedatabase22 as a function of the device identification number. The player attendance information350 includes a player identifier such as a player number, player name and address, and the like. The player attendance information350 includes a gaming machine identifier which indicates what gaming machines theplayer24 has attended on a particular day.
The purpose of the player attendance information[0220]350 is to register and display a patrons attendance at a particular gaming machine or marketing event. Attempting to register aplayer24 already registered will generate and display an error.
With specific reference to FIG. 19A, a[0221]first method352 for remotely requesting information relating to aplayer24 is provided. In afirst step354, identification information is received at the remote device. In asecond step356, the identification information is received at the host computer. In a third step358, identification information is stored in the database, i.e., the player before is marked as the player attending the event. In afourth step360, the player attendance information is retrieved from thedatabase22 as a function of the identification information.
With specific reference to FIG. 19B, a[0222]second method362 for remotely requesting player information using theremote device50A is shown, according to a second embodiment of the present invention.
In a[0223]first step364, the attendance form is requested by theuser54 on theremote device50A.
In a[0224]second step366, theuser54 selects and enters an event or gaming via machine and control proceeds to afourth step370.
In a[0225]third step368, an error message is displayed if the user does not enter or select an event and control returns to thefirst step364.
In the[0226]fourth step370, if a player ID card number is entered, then themethod362 proceeds to afifth step372.
In the[0227]fifth step372, the ID card number is validated.
In a[0228]sixth step374, if system determines if the ID card number is not valid, and control proceeds to thethird step368 where an error message is displayed. If the ID card number is valid, then the method proceeds to aseventh step376.
In the[0229]seventh step376, if theplayer24 is not marked as attending the event, the control proceeds to aneighth step378.
In the eight[0230]step378, the player's attendance at the gaming machine is registered by the system, and control returns to thefirst step264.
I. Remote Surveillance[0231]
With reference to FIGS. 21A, 21B, and[0232]22, theremote system48 allows theuser54, such as a slot floor employee or patron host to quickly and remotely process an alert having data including user role information, alert information and alert detail issued by agaming machine13. The user role information is a system where eachuser54 is assigned a role in a hierarchy of roles. The user's role and level on the hierarchy determines which functions and information the user can access and the operations the user can perform.
In the illustrated embodiment, interaction with the[0233]user54, including receiving input and displaying the alert information, is accomplished using theweb client56.
In one aspect of the present invention, an alert form displays all active alerts and displays the alerts on the[0234]remote device50A in an alert form as a function of the user role information. The alert form displays the alert and the date and time it occurred. Theuser54 may identify the alert and select the alert via an alert button to acknowledge that theuser54 is addressing the alert and will clear the alert after it is addressed. After theuser54 addresses the alert and acknowledges that it is addressed, thedatabase22 is updated and the alert form is refreshed with updated alert information.
In the illustrated embodiment, the[0235]user54 selects the alert from the alert form and alert details300 are displayed. The alert details may include, but are not limited to, an alert type for describing the alert and an alert date for describing the date and time that the alert occurred. The alert details300 may further include a device identifier for describing the gaming device the alert occurred on, a zone name for describing the zone of the gaming floor that the device is located in, and a bank name for describing the bank of the gaming floor that the device is located in. Additional alert details300 may include a repository identifier for describing the repository the alert occurred on, a document identifier for describing a document created by the alert, an alert value for describing the value of the alert, and an alert point describing the point value of the alert. The alert details300 may also further include an employee identifier for describing the employee that initiated the alert and an alert message providing a text description of the alert.
In one embodiment, the[0236]user54 navigates to a servlet for requesting alert information using themenu layer80. Themenu layer80 requests the servlet from thehost computer18 from which it is then downloaded to theremote device50A.
In one embodiment, the servlet displays the alert form which is displayed to the[0237]user54. As discussed above, theuser54 may select the alert displayed on the alert form to retrieve the alert detail300 which is returned to thehost computer18 by theweb client56. Theremote network interface68 receives the alert information, retrieves the alert detail300 and returns the alert detail300 to theremote device50A where it is displayed. With specific reference to FIG. 22, in one embodiment the returned alert information is displayed on theremote device50A in analert information screen330.
With specific reference to FIG. 21A, a[0238]first method302 for remotely processing an alert is provided. In afirst step304, alert information is received at the remote device. In asecond step306, the user selects the alert. In athird step308, the alert information is retrieved from thedatabase22 as a function of the selected alert.
With specific reference to FIG. 21B, a[0239]second method310 for remotely requesting player information using theremote device50A is shown, according to a second embodiment of the present invention.
In a[0240]first step312, the alert information is retrieved as a function of the user role.
In a[0241]second step314, the retrieved alert information is displayed on theremote device50A.
In a[0242]third step316, the user selects an alert, then themethod310 proceeds to afourth step318.
In the[0243]fourth step318, alert detail is retrieved and displayed as a function of the selected alert.
In a[0244]fifth step320, the user selects an alert button for refreshing the alert information stored in thesystem10.
In a[0245]sixth step322, the user acknowledges the alert.
In a[0246]seventh step324, the system determines if the alert has already been acknowledged.
In an[0247]eighth step326, if the alert was previously acknowledged, an error message is displayed and the method returns to thefirst step312. If the acknowledgement is valid, then the message proceeds to theninth step328.
In the[0248]ninth step328, the alert is processed by thehost computer18, notification is sent to other processes in the system, including the database and control returns to thefirst step312.
In the[0249]third step316, the user selects the alert button to refresh the alert information displayed at theremote device50A.
Obviously, many modifications and variations of the present invention are possible in light of the above teachings. The invention may be practiced otherwise than as specifically described within the scope of the appended claims.[0250]
J. Patron Point Adjustment[0251]
With reference to FIGS. 23A, 23B and[0252]24, theremote devices50 allow auser54 to display and/or increase a player's point, e.g., bonus points, or comp point balance. In one embodiment, theremote network interface68 exchanges data between thehost computer18 and theremoter device50. The data includes adjustment information to adjust the points associated with aplayer24 in the player tracking system.
In one embodiment, the data includes a point management form (not shown) which is sent from the[0253]remote network interface68 to theremote device50A. The point management form is fillable with player information by theuser54. Theremote device50 sends the player information to theremote network interface68. Once theplayer24 has been identified, theremote network interface68 sends a point adjustment request from to theremote device50A.
With specific reference to FIG. 24, a sample point[0254]adjustment request form506, according to one embodiment, is shown. In the illustrated embodiment, the point adjustment request form allows theuser54 to enter the type of points, the number of points, the reason for the adjustment, and the player ID card number associated with theplayer54. When finished, theuser54 may select an ISSUE button to send the date to the host computer is where thedatabase22 is updated.
With specific reference to FIG. 23B, a[0255]second method510 for adjusting points associated with aplayer24 in a player tracking system is shown. In afirst step512, a request is displayed on theremote device50A. Theuser54 may then fill out the form and send the form back to thehost computer18. In one embodiment, a player ID card number is manually entered on the remote device59A. In another embodiment, the player ID card number is read from the ID card by thebar code reader66 or theID card reader62.
In a[0256]second step514, if a card number was entered, then themethod510 proceeds to athird step516. If a card number was not entered, then themethod510 proceeds to afourth step516 and an error message is displayed. In thethird step516, the card number is validated. In afifth step518, if the card number is valid then themethod510 proceeds to asixth step520. In thesixth step520, approval for the requested transaction is processed. In aseventh step522 if the user oremployee54 has the necessary rights to adjust the player or patron's points then themethod512 proceeds to aneighth step524. Otherwise, the method proceeds to thefourth step516 and an error message is displayed. In theeighth step524, the points are adjusted and the process returns thefirst step512.
K. Comp Point Vouchers[0257]
With reference to FIGS. 25A, 25B and[0258]26, theremote device50 may be used to issue point vouchers or comp point vouchers to aplayer24. The vouchers may be embodied in a paper voucher which is printed on a remote printer carried by theuser54 or may be embodied in a pre-printed voucher having a voucher ID number which is carried by theuser54, and assigned to theplayer24 in the player tracking system. Alternatively, the voucher may be embodied in a record stored in thedatabase22.
In one embodiment of the present invention, the[0259]remote network interface68 exchanges data between thehost computer18 and theremote device50A. The data includes voucher information to issue a voucher to theplayer24 in the player tracking system. The voucher has at least one of an associated product and service. For example, the voucher may be redeemed for the associated product at a related retail store or redeemed for the associated service. Exemplary products includes free dinners and/or drinks.
As discussed below the[0260]remote network interface68 may send a request form to theremote device50A. Theuser54 enters data onto the request form and the remote device sends the data to theremote network interface68.
With specific reference to FIG. 25, in one embodiment of the present invention, a[0261]method530 implements a player tracking system for use with the gaming system. In a first step532 a fillable form is sent to theremote device50A. In asecond step534, the form is filled with data for issuing a voucher to theplayer24.
The[0262]user54 may enter the player ID card number associated with theplayer24 on the request form. In one embodiment, the player ID card number is entered manually. In another embodiment, the player ID card is read from the player ID card by theID card reader62 or thebar code reader66. After the player has been identified, a list of the vouchers for which the patron has enough comp points to purchase are listed. With specific reference to FIG. 26, aplayer voucher form536, according to an embodiment of the present invention, is shown. Theplayer voucher form536 displays the patron name, the player ID card number, the type of voucher being selected and the points associated with the patron in the player tracking system. Theplayer voucher form536 also lists the vouchers for which the patron may purchase based on the number of comp points they have.
With specific reference to FIG. 25B, a flow diagram of a[0263]second method536 for assigning vouchers to a player in a player tracking system is shown. In afirst step540, a first request form is displayed on theremote device50A. The first request form allows theuser54 to select the type of voucher, i.e., either point or comp point and to enter the card number of the player orpatron24. In asecond step542, if a card number was entered then the process proceeds to athird step546. Otherwise, themethod538 proceeds to afourth step544 and an error message is displayed. In thethird step546, the player's ID card number is validated. In afourth step548, if the ID card number is valid, then themethod538 proceeds to afifth step550. Otherwise, themethod538 proceeds to thethird step544 and an error message is displayed. In thefifth step550, if theplayer24 has any points in the player tracking system, then themethod538 proceeds to asixth step552. Otherwise, themethod538 proceeds to thethird step544 and an error message is displayed. In thesixth step552, if there are any active comps or vouchers that theplayer24 can afford based on the number of points associated with theplayer24 in the patron tracking system, then themethod538 proceeds to theseventh step554. Otherwise, the method proceeds to thethird step544 and an error message is displayed. In theseventh step554, a request form orplayer voucher form548 is displayed on theremote device50A. As discussed above, theplayer voucher form548 displays a list of vouchers that the player can afford. If theuser54 selects one of the vouchers and selects the issue button, then the voucher or comps are issued in theeighth step556. In aninth step558, if the comp or voucher was issued without errors then the method returns to thefirst step540. Otherwise, the method returns to thethird step544 and an error message is displayed.
L. Redemption of Printed Vouchers[0264]
With reference to FIGS. 27A, 27B and[0265]28, theremote device50 may be used to validated and process, i.e., redeem, printed vouchers. A printer voucher may be distributed for any number of reasons, for example, including a promotional event. Typically, the voucher may be redeemed for an associated service or product. For example, a printer voucher may be redeemed for a free dinner or drink.
As discussed below in one embodiment, the[0266]remote network interface68 generates and delivers to theremote device50A a request form. Theuser54 may enter a voucher ID number onto the form. By pressing a continue button, the voucher ID may be validated and processed. A status may then be returned to theuser54.
With reference to FIG. 27A, in one embodiment a[0267]method540 is used to redeem a voucher. In afirst step542, a fillable form is sent to theremote device50A. In asecond step544, the fillable form is filled out without voucher information by the user54A. In one embodiment, the voucher information includes a voucher ID number which may be entered manually or by reading a code on the voucher. For example, the code may be a bar code printed on the voucher which is read by thebar code reader66. In athird step546, the voucher ID number is validated and redeemed.
With specific reference to FIG. 28, in one embodiment, once a voucher has been identified by the[0268]remote network interface68, avoucher information form548 is displayed on theremote device50A. Thevoucher information form548 in the illustrated embodiment includes the voucher ID number, a good for field which identifies the product or service for which the voucher may be redeemed, an issued date, and an expiration date. Once theuser54 verifies the data displayed on the voucher information form, theuser54 may press the continue button to validate and except the voucher.
With specific reference to FIG. 27B, a[0269]method550 for validating and processing and redeeming printed vouchers according to another embodiment of the present invention is shown. In afirst step552, a request form is displayed on theremote device50A. The request form allows theuser54 to enter a voucher number or a voucher ID number. In one embodiment, the voucher ID number is entered manually. In another embodiment, the voucher number is read from the printed voucher. For example, the voucher ID number may be encoded into a bar code which is read by thebar code reader66. In asecond step554, if the voucher ID number has been entered then the method proceeds to athird step556. Otherwise, themethod550 proceeds to afourth step558 and an error message is displayed. In thethird step556, the voucher number is validated. In afifth step560, if the voucher number is valid, then the method proceeds to asixth step562. Otherwise, the method proceeds to thefourth step558 and an error message is displayed. In thesixth step562, if the voucher has already or previously been accepted, then themethod550 proceeds to thefourth method step558 and an error message is displayed. Otherwise, themethod550 proceeds to aseventh method step564 and the voucher is marked as accepted within thedatabase22.
M. Voucher Information Retrieval[0270]
With reference to FIGS. 29A, 29B and[0271]30, theremote device50A may be used to display a list of outstanding vouchers for a selected player orpatron24 and allow theuser54 to accept a specific voucher. Typically the voucher has an associated good, i.e., product, or service for which it may be redeemed. For example, a specific voucher may be redeemed for a free dinner and/or drink. In one embodiment, each voucher has a unique voucher ID number and is stored as a record in thedatabase22. In another embodiment, the voucher may be embodied in a printed ticket having the voucher ID printed or encoded thereon. The voucher ID number would be associated with theplayer24 in thedatabase22.
In one aspect of the present invention, at least one voucher is assigned to the[0272]player24 in the player tracking system. The voucher has at least one of the good and/or service for which it may be exchanged. Theremote network interface68 may be used for exchanging data between thehost computer18 and theremote device50A. The data includes voucher information associated with the voucher assigned to theplayer24 in the player tracking system.
In one embodiment, the data exchange between the[0273]remote device50A and theremote network interface68 includes a request form. Theremote network interface68 sends the request form to theremote device50A. The request form may be used by theuser54 for entering information related to the player. Theremote device50A sends the player information to theremote interface68. As discussed below, in one embodiment of the present invention, the player information includes the player ID card number. The player ID card number may be entered manually or may be read by the playerID card reader62 or thebar code reader66, as appropriate. The player ID card number is relayed to theremote network interface68. Theremote network interface68 returns a list of outstanding vouchers associated with theplayer24. Theuser54 may view details related to each voucher. Theuser54 may select one of the vouchers to accept, i.e., redeem for the associated service or good.
With specific reference to FIG. 29A, a[0274]first method570 for redeeming outstanding vouchers for a selectedplayer24 is shown. In afirst step572, a fillable form is sent to theremote device50A. In asecond step574, the form is filled out by theuser54 for identifying the player. In athird step576, voucher information is retrieved through theremote network interface68. As discussed above, once the player has been identified, a list of outstanding vouchers is returned to theremote device50A. A details button (not shown) associated with each voucher in the list may be selected by theuser54 to display voucher information related to the selected voucher. For example, with reference to FIG. 30, an exemplaryvoucher information screen578 is shown. Thevoucher information screen578 may display the voucher ID number, the good or service for which it may be redeemed, the date it was issued, and the date the voucher expires. Thevoucher information screen578 also includes an accept button which may be selected by the user to accept the voucher as it is redeemed.
With specific reference to FIG. 29B,[0275]second method580 for displaying and redeeming outstanding vouchers associated with theplayer24 is shown. In afirst step582, a request form is displayed on theremote device50A. In one embodiment, theuser54 may enter a player ID card number on the request form. In one embodiment, the player ID card number is entered manually. In another embodiment, the player ID card number may be read from the player ID card by theID card reader62 or thebar code reader66. In asecond step584, if an ID card number has been entered, then themethod580 proceeds to athird step588. Otherwise, themethod580 proceeds to afourth step586 and an error message is displayed. In thethird step588, the ID card number is validated. In afifth step590, if the ID card number is not valid, then themethod580 proceeds to thethird step586 and an error message is displayed. Otherwise, the method proceeds to asixth step592.
In the[0276]sixth step592, if theplayer24 does not have any outstanding vouchers, then themethod580 proceeds to thefourth step586 and an error message is displayed. Otherwise, themethod580 proceeds to aseventh step594.
In the[0277]seventh step594, any outstanding vouchers associated with theplayer24 are retrieved from thedatabase22. In aneighth step596, the retrieved outstanding vouchers are displayed on theremote device50A. As discussed above, each voucher in the list has an associated detail button (not shown).
In a[0278]ninth step598, if the detail button for one of the listed vouchers was pressed or selected, then themethod580 proceeds to atenth step600. Otherwise, themethod580 returns to thefirst step592. In thetenth step600, voucher details for the selected voucher are retrieved from thedatabase22. Ineleventh step602, the voucher details for the selected voucher are displayed on theremote device50A. In atwelfth step604, if the accept button for the selected voucher was pressed or selected, then themethod580 proceeds to athirteenth step606. Otherwise, themethod580 returns to theseventh step594.
In the[0279]thirteenth step606, the selected voucher is marked as being accepted and the method returns to theseventh step594.
N. System Information[0280]
In another aspect of the present invention, the[0281]database22 may store information related to theremote devices50, including the current state of theremote device50. As discussed below, this information may be retrieved and displayed on theremote device50A, for example, for purposes of tech support. In one embodiment, theuser54 selects the servlet or applet from themenu layer80. Theremote network interface68 produces an HTML form that displays the information related to theremote device50 to theuser54.
In one embodiment, the data includes information which is associated with a current client being utilized on the[0282]remote device50A. For example, the data may include but is not limited to a TCP/IP address of the current client. An HTTP context of the current client for the current session, an IOP ID of the current client as defined in thedatabase22 and an IOP name of the current client is defined in the database. IOP or input output point is a designator to represent a point of data input or output such as a dedicated terminal, hand held device, etc., that is distinguished usually by its IP address on the network. The IOP ID and name are used to tie transactions that are generated to a particular entity or device.
The data may also include information related to a[0283]current user54 of theremote device50. For example, the data may include an employee ID number and/or the employee name.
Obviously, many modifications and variations of the present invention are possible in light of the above teachings. The invention may be practiced otherwise than as specifically described within the scope of the appended claims.[0284]