US20090264190A1

US20090264190A1 - Customized player alerts

Info

Publication number: US20090264190A1
Application number: US12/106,792
Authority: US
Inventors: Dwayne A. Davis; Michael M. Oberberger; Christiaan R. Champagne
Original assignee: International Game Technology
Current assignee: International Game Technology
Priority date: 2008-04-21
Filing date: 2008-04-21
Publication date: 2009-10-22

Abstract

Some implementations of the invention allow a player to specify type(s) of wagering conditions about which the player would like to receive notification. The player may also be able to specify the mode of notification desired, e.g., text message, email, voice message, etc. Wager gaming notification parameters may, for example, comprise information regarding an occurrence of a wager gaming outcome. Some such wager gaming notification parameters may involve an occurrence (or a non-occurrence) of a wager gaming outcome within a specified time or a specified number of plays. Player notifications may include raw data, probability data, graphical data, navigation data and/or location data.

Description

FIELD OF THE INVENTION

The present invention relates generally to wagering devices and methods.

BACKGROUND OF THE INVENTION

Wager gaming has become a multi-billion dollar business. Casino owners and operators strive to make the gaming environment more attractive, more entertaining and more rewarding to casino patrons.
Jackpots are features of wager gaming that are known to heighten patron interest and excitement. When patrons know that a jackpot has become very large, their interest in the corresponding wagering game intensifies. However, existing displays in casinos may not provide such information to a wide enough audience. It would be desirable to provide improved methods, devices and systems.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow chart that outlines some implementations of the invention.

FIG. 2 is flow chart that outlines steps of receiving wager gaming notification parameters according to some implementations of the invention.

FIGS. 3A and 3B illustrate graphical user interfaces (“GUIs”) that may be used to obtain user input regarding some features of the invention.

FIGS. 4A through 4E illustrate GUIs that may be used to obtain user input regarding additional features of the invention.

FIGS. 5A through 5D illustrate GUIs that may be used to obtain user input regarding other features of the invention.

FIG. 6 is flow chart that outlines steps of alternative implementations of the invention.

FIGS. 7A through 7C illustrate GUIs that may be used to provide player notifications according to some implementations of the invention.

FIG. 8 is a diagram of a mobile device that may be used to implement, at least in part, some features of the invention.

FIG. 9 depicts an example of a gaming establishment and related devices that may be used for some implementations of the invention.

FIG. 10 depicts an Arbiter that may be used to implement, at least in part, some features of the invention.

FIG. 11 is a diagram of a network device that may be configured according to some implementations of the invention.

DESCRIPTION OF EXAMPLE EMBODIMENTS

In this application, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid obscuring the present invention. Accordingly, the methods described herein may include more (or fewer) steps than are indicated. Moreover, the steps of such methods are not necessarily performed in the order indicated.
Reference will now be made in detail to some specific examples of the invention, including the best modes contemplated by the inventors for carrying out the invention. Examples of these specific embodiments are illustrated in the accompanying drawings. While the invention is described in conjunction with these specific embodiments, it will be understood that it is not intended to limit the invention to the described embodiments. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims.
Various techniques and mechanisms of the present invention will sometimes be described in singular form for clarity. However, it should be noted that some embodiments include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. For example, a system may use a logic device, such as a processor, in a variety of contexts. However, it will be appreciated that a system can use multiple logic devices for similar purposes, while remaining within the scope of the present invention. Similarly, a host device, server, etc., may be described as performing various functions. In some implementations, a single device may perform such functions, whereas in other implementations the functions may be performed by multiple devices.
Furthermore, the techniques and mechanisms of the present invention will sometimes describe and/or illustrate a connection between two entities. It should be noted that a connection between two entities does not necessarily mean a direct, unimpeded connection, as a variety of other entities may reside between the two entities. For example, a processor may be connected to memory, but it will be appreciated that a variety of bridges and controllers may reside between the processor and memory. Consequently, an indicated connection does not necessarily mean a direct, unimpeded connection unless otherwise noted. Moreover, there may be other connections between entities than are indicated herein, e.g., in network diagrams.
Overview
Some players may be interested in receiving information regarding one or more types of wagering conditions. This information may relate to the size of a jackpot, to the “line” in sports betting, to “hot” or “cold” wager gaming machines, or to other wagering conditions of interest.
Accordingly, some implementations of the invention allow a player to specify type(s) of wagering conditions about which the player would like to receive notification. The player may also be able to specify the mode of notification desired, e.g., text message, email, voice message, etc. Collectively, the wagering conditions and notification mode(s) may sometimes be collectively referred to herein as “wager gaming notification parameters” or the like.
Some embodiments of the invention provide a wager gaming system, which may include the following elements: apparatus for receiving a player's wager gaming notification parameters; apparatus for determining when a wagering condition corresponds with the wager gaming notification parameters; and apparatus for providing a notification to the player when the wagering condition corresponds with the wager gaming notification parameters.
In some embodiments, the receiving apparatus may comprise a user interface. For example, the receiving apparatus may comprise at least one display and/or other apparatus for presenting a graphical user interface for receiving wager gaming notification parameters. The determining apparatus may, for example, comprise a logic system that includes one or more logic devices (e.g., processors, programmable logic devices, etc.).
The wager gaming notification parameters may comprise information regarding a notification mode for providing the notification to the player. The providing apparatus may be configured for providing the notification according to the notification mode. The notification mode may comprise one or more of a text message, a voice message, an email message, etc.
The wager gaming notification parameters may comprise information regarding an occurrence of a wager gaming outcome within a specified time or a specified number of plays. However, the wager gaming notification parameters may comprise information regarding a non-occurrence of a wager gaming outcome within a specified time or a specified number of plays. Moreover, the wager gaming notification parameters may comprise other factors, e.g., a probability of an occurrence or non-occurrence of a wager gaming outcome.
Some implementations of the invention provide a wager gaming method, which may include the following steps: receiving a player's wager gaming notification parameters; determining when a wagering condition corresponds with the wager gaming notification parameters; and providing a notification to the player when the wagering condition corresponds with the wager gaming notification parameters. The receiving step may comprise receiving the wager gaming notification parameters via a user interface.
The wager gaming notification parameters may comprise information regarding a notification mode for providing the notification to the player and wherein the providing apparatus comprises apparatus for providing the notification according to the notification mode. The wager gaming notification parameters may comprise information regarding an occurrence of a wager gaming outcome within a specified time or a specified number of plays.
However, the wager gaming notification parameters may comprise other data, e.g., information regarding a non-occurrence of a wager gaming outcome within a specified time or a specified number of plays, the probability of an occurrence or non-occurrence of a wager gaming outcome, etc.
The wager gaming notification parameters may comprise information regarding a sporting match, poker games, tournaments, etc. In some implementations, the wager gaming notification parameters may comprise roulette game data, e.g., data involving roulette game outcomes, such as game outcomes relating to specified portions of a roulette wheel.
The providing step may involve providing the player with at least one of a text message, a voice message or an email message. The notification may comprise information regarding a probability of the wagering condition. For example, the notification may comprise information regarding an outcome of a Keno game, information regarding a dealer or croupier of a table game. In some instances, the notification may identify at least one wager gaming machine or gaming table.
These and other methods of the invention may be implemented by various types of hardware, software, firmware, etc. For example, some features of the invention may be implemented, at least in part, by a personal digital assistant, by a portable gaming device and/or other type of mobile device, by one or more host devices, RFID readers, servers, cameras, etc. Some embodiments of the invention are provided as computer programs embodied in machine-readable media. The computer programs may include instructions for controlling one or more devices to perform the methods described herein.
Alternative embodiments of the invention provide a wager gaming system that may include an interface system for receiving a player's wager gaming notification parameters and a logic system comprising at least one logic device. The logic system may be configured determine when a wagering condition corresponds with the wager gaming notification parameters and to cause a notification to be made to the player if the wagering condition corresponds with the wager gaming notification parameters.
The interface system may comprise at least one user interface. Alternatively, or additionally, the interface system may comprise at least one network interface. The receiving apparatus may comprise hardware, software, etc., configured for presenting a graphical user interface for receiving wager gaming notification parameters.
The wager gaming notification parameters may comprise information regarding a notification mode for providing the notification to the player. The logic system may cause the notification to be made according to the notification mode. The notification mode may comprise at least one of a text message, a voice message, an email message, etc.
The wager gaming notification parameters may comprise information regarding an occurrence of a wager gaming outcome within a specified time or a specified number of plays. The wager gaming notification parameters may comprise information regarding a non-occurrence of a wager gaming outcome within a specified time or a specified number of plays. The wager gaming notification parameters may comprise a probability of an occurrence or non-occurrence of a wager gaming outcome.

DETAILED DESCRIPTION

Referring now to FIG. 1, an overview of some generalized methods of the invention will now be described. Subsequent discussions herein will provide examples of these general features in greater detail. As with other methods described herein, the methods described with reference to FIG. 1 may include more (or fewer) steps than are indicated in flow chart 100. Moreover, the steps of these and other methods described herein are not necessarily performed in the order indicated.
In step 101, a player's wager gaming notification parameters are received. Wager gaming notification parameters may, for example, comprise information regarding an occurrence of a wager gaming outcome. Some such wager gaming notification parameters may involve an occurrence (or a non-occurrence) of a wager gaming outcome within a specified time or a specified number of plays.
Preferably, the wager gaming notification parameters can be customized, at least to some extent, according to information desired by a player. Some players are looking for “streaks,” trends or “hot” wager gaming machines, roulette wheels, players, etc. For example, some players may believe that certain wager gaming machines tend to “hit” big payouts more frequently than other wager gaming machines. Some such players may wish to receive a list of wager gaming machines that have hit the most often during a particular time interval (e.g., during the past week, month or year) or number of plays (during the last 100 plays, 1000 plays, etc.).
Some players would value information regarding the machines that had the biggest jackpot hits during the past year. Many players may be interested in the current total of a progressive jackpot, a lottery, etc.
Other players may wish to know information relating to thresholds, such as payout thresholds. For example, a player may choose to be notified when a progressive jackpot reaches or exceeds a predetermined monetary threshold. The size of the threshold of interest may vary, e.g., according to the number of participating wager gaming machines: a threshold for a progressive involving a relatively large number of wager gaming machines may be higher than the threshold for a progressive involving a relatively small number of machines. For example, a player may select a relatively low threshold, (e.g., $10K or less) for a progressives based on a bank of 6 or 8 wager gaming machines, whereas the player may select a threshold of $1 million for a progressive involving thousands of machines.
However, other players may wish to be notified when different types of thresholds are met or exceeded, such as game outcome thresholds, probability thresholds, etc. As an example of a game outcome threshold as a wagering condition, a player may wish to know which video poker machines in a casino have hit a straight flush or better during a particular time interval (e.g., on a particular day, during the past week, etc.) or during a specified number of plays. As an example of a probability threshold, a player may request notification when a wagering condition occurs having a probability of 1 in 100,000 or more. The player may further specify a time interval, a number of plays, etc.
Sports betting may involve other types of wagering conditions about which players may seek notification. In some types of sports betting, for example, bets may be won or lost according to the “line.” Suppose the Raiders are playing the 49'ers and the line is 6.5. If a player bets on the Raiders and the Raiders win by 6 points, the player loses, but if the Raiders win by 7 points, the player wins. If the player bets on the 49'ers and the Raiders win by less than 7 points, the player wins. Sports betting may also be made according to the “over/under.” An over/under bet is a prediction that a particular statistic for a game (e.g., the combined score of the two teams) will be either higher or lower than a stated number. The line and over/under are typically set by a casino, a sports book, etc. These values may vary in time and may also vary from casino to casino.
Therefore, a player may ask for notification whenever the line or the over/under for a particular game reaches a certain value. For example, the player may request notification when the line for a particular football game is greater than, less than or equal to a certain value. The player may be interested in receiving notification regarding other types of sports betting, including but not limited to golf, tennis, basketball, baseball, hockey, soccer, horse racing, boxing, and mixed martial arts. The wagering conditions of interest may vary with the sport and/or the type of game, so a player's desired wager gaming notification parameters may vary accordingly.
Still other players may wish to be notified about alternative wagering conditions. For example, some players may seek information regarding “cold” wager gaming machines, perhaps believing that wager gaming machines are due for hitting a jackpot if they have not hit in a relatively long time and/or a relatively large number of plays.
Similarly, a player may want to be notified about machines that have not “hit” at or above a particular threshold for a period of time. As described elsewhere, the threshold may be a monetary threshold, a game outcome threshold or another type of threshold. For example, a player may want to receive information regarding all video poker machines that have not hit at four of a kind or better in a predetermined number of plays (e.g., 10,000 plays), within a predetermined period of time (e.g., 3 days), etc. Some players may wish to be notified about slot machines that have not paid out more than a predetermined monetary threshold (e.g., more than $500) per play within a predetermined time period, within a predetermined number of plays, etc. Similarly, a player may wish to know what slot machines have not had a progressive jackpot hit within a predetermined time period or within a predetermined number of plays.
A player may also seek other information regarding a table game, a wager gaming machine, etc. For example, some players may desire information regarding the age of a wager gaming machine. Some players believe that new machines will hit big jackpots more often. Accordingly, some players may wish to know when new wager gaming machines are deployed and/or may wish to have the age of a machine be presented along with other notification data. On the other hand, some players may believe that an older roulette wheel may provide less random results than a newer roulette wheel. Therefore, some players may desire information regarding the length of time a roulette wheel has been in use, the extent of such use, whether the wheel has been maintained, the time since the last maintenance event, etc.
Some players may also desire information regarding a dealer, a croupier, a craps shooter, an athlete scheduled to play in a sports competition, etc., perhaps believing that the influence of a particular person (or the lack thereof) may affect the outcome of a game. For example, patrons interested in sports wagering may wish to know as much as possible regarding factors that may affect the performance of key athletes, such as indicia of their health (e.g., evidence of recent injuries), reports of recent arrests and/or other factors that may affect an athlete's physical or mental condition. Some players may wish to know of tables at which a craps player is “on a roll” and seems to be having a lucky streak.
Similarly, a player may believe that a croupier's consistency of throw, spin, ball size, etc., may cause certain zones of a roulette wheel to be hit more often than other zones. Therefore, some players may seek information regarding zones of a roulette wheel that are being hit more than other zones within a predetermined number of spins, a predetermined period of time, etc. A player may wish to know how often his or her “favorite number” has been hit. Some players may believe that an inexperienced card dealer will provide less random card game outcomes than a more experienced dealer. Therefore, some players may wish to know which dealers are relatively less experienced than others.
Many other types of notifications are contemplated by the inventors and are within the scope of the present invention. For example, some players may desire notification when seats in a poker room become available, when a seat at a blackjack table becomes available, when a particular wager gaming machine becomes available, etc. Some players may wish to be notified about tournaments, e.g., when tournaments of a particular type are scheduled, how to enroll, whether places in the tournaments are available, etc.
Some patrons may wish to receive (or at least be willing to receive) offers, advertisements, etc. In some implementations, offers may bear some logical relationship to a patron's indicated wager gaming notification parameters. For example, an offer may be related to a location of a particular wager gaming machine, gaming table, etc., about which a player will receive notification according to his or her wager gaming notification parameters. According to some such implementations, the offer may relate to a restaurant, a bar, a retail establishment or other such commercial entity that is located near a wagering location of interest. However, such offers may or may not relate to wager gaming notification parameters selected by the patron.
The wager gaming notification parameters may also include information regarding a mode for providing the notification to the player, which will sometimes be referred to herein as a “notification mode” or the like.
Step 101 may, for example, involve a process of receiving data from a patron. In some implementations, for example, such data may be received via a process such as that described below with reference to FIGS. 2 through 5D. However, step 101 may also reference other processes, e.g., a step of receiving wager gaming notification parameters that have previously been received by a first device (such as a kiosk, a personal computer, a personal digital assistant, a wager gaming machine, a cellular telephone, etc.). For example, the wager gaming notification parameters may be received by the first device and transmitted to a storage device, to a host device, to a server, etc.
In step 105, wagering conditions are monitored according to the received wager gaming notification parameters. For example, the wagering conditions may be monitored by one or more servers, host devices, etc., based on input from wager gaming machines, networked gaming tables and various other devices configured for communication via a gaming network. Depending on the types of wagering conditions to be monitored, input may also be received from sources outside a gaming establishment. For example, if the wager gaming notification parameters involve wagering on one or more sporting matches, information about the players, the weather, the current “line” or other wagering parameters, etc., may be obtained from outside sources (e.g., via the Internet) and evaluated according to the received wager gaming notification parameters.
If an observed wagering condition corresponds to a player's wager gaming notification parameters, the player will be notified according to his or her indicated notification parameters. (Step 115.) For example, if the player had requested to be contacted via email, the player would be sent an email notification. As described in more detail below with reference to FIG. 6, the patron may also receive information according to his or her location, according to a follow-up request for information and/or other criteria.
In step 120 it is determined whether the process will continue. For example, it may be determined that a patron has indicated that he or she no longer wishes to receive notifications, etc., at least temporarily. The patron may, for example, have switched off a device configured for receiving notifications, may have sent a message indicating that he or she does not wish to receive notifications for the time being, etc.
In some implementations, at least some the wager gaming notification parameters may pertain to a particular gaming establishment. When a patron is determined to be leaving that gaming establishment, to be more than a predetermined distance from the gaming establishment, etc., in some implementations the patron will no longer receive notifications pertaining to that gaming establishment.
A method 200 for obtaining a player's wager gaming notification parameters will now be described with reference to FIG. 2 and FIGS. 3A through 5D. In the example of method 200, a player may indicate wager gaming notification parameters by interacting with a series of graphical user interfaces (“GUIs”). These GUIs may be provided, for example, on a kiosk, on a player's personal computer, mobile device (e.g., a personal digital assistant [“PDA”], cellular telephone, etc.), on a wager gaming machine, on a television screen (e.g., in a casino's hotel room) or on some other device.
It will be appreciated that method 200 is merely one example of how a player's wager gaming notification parameters may be obtained and that any other suitable method may be used within the scope of the present invention. For example, other types of GUIs, other user interfaces, etc., may be used to obtain a player's wager gaming notification parameters. Pull-down menus (or the like) may be used in combination with GUIs, e.g., in order to reduce the total number of necessary screens or panels. At least some wager gaming notification parameters may be inferred from a player's observed wagering patterns. These may be determined, e.g., by reference to a player loyalty database. Alternatively, or additionally, a player's wager gaming notification parameters may be determined by another person (e.g., a casino attendant) and entered by the attendant.
In step 201 of method 200, a first GUI is provided. One example of a GUI that could be presented at this stage is depicted in FIG. 3A. GUI 300 includes a message field 301, which provides a greeting and instructs the patron to select a type of wager gaming that is of interest to the player.
Various wager gaming options are provided in area 303. In this example, a patron has the option of selecting poker, blackjack, keno, roulette, slots/video poker or sports betting. Here, a patron has selected Roulette. Other implementations may provide more or fewer selections of wager gaming options. Still other implementations may allow a patron to indicate one or more wager gaming options that are not displayed, e.g., by filling in a blank field.
In this example, the patron may indicate whether he or she is a member of a player loyalty program by selecting an option in area 305. In this instance, the patron has indicated that she is not a member of a player loyalty program.
GUI 300 also provides audio button 307 and help button 309. In this example, if audio button 307 is activated, various other options are presented (not shown), including an option of activating an audio version of the GUI (e.g., in which at least some of fields of GUI 300 are provided in audio form), adjusting the volume, etc. When activated, help button 309 provides an explanation for at least some of fields of GUI 300 and/or other (e.g., subsequent) GUIs. If audio button has also been activated, such explanations may be provided in audio form if so desired.
Activating “Enter” button 311 will indicate the patron's acceptance the selections on GUI 300. Referring now to FIG. 2, it is determined in step 210 that there are additional options available and/or additional information to be acquired regarding the selections made on GUI 300. Therefore, activating “Enter” button 311 will cause a modified screen and/or an additional screen to be presented. (Step 215.) This will lead to further options consistent with the selections made on GUI 300.
In this example, GUI 400 a of FIG. 4A is presented next. Here, because the patron had indicated an interest in roulette games in area 303 of GUI 300, GUI 400 a allows the patron to indicate further information regarding roulette-based wager gaming notification parameters.
Here, area 401 a prompts the patron to indicate roulette-based wager gaming notification parameters of interest. Such a prompt (and/or other information) may be made in an audio fashion, e.g., if audio button 307 or 407 has been activated.
Area 403 allows the patron to indicate an interest in specific game outcomes (e.g., particular numbers hit, red or black, etc.), hits in predetermined areas of a roulette wheel, “hot or “cold” tables or players, or other roulette-based wager gaming notification parameters that are not listed on GUI 400 a. Further examples of such roulette-based wager gaming notification parameters are described below.
The patron may also indicate in area 405 whether any location and/or navigation data should be provided along with a notification. For example, directions to a roulette table of interest and/or a map indicating such a roulette table, etc., may be provided. In some implementations, real-time navigation features may be provided, such as those described in U.S. patent application Ser. No. ______ (attorney docket no. IGT1P410/P-1222), entitled “Real-Time Navigation Devices, Systems and Methods,” which is hereby incorporated by reference. According to some such implementations, a patron may be presented with image data that may include images from cameras positioned at various locations, e.g., within a wager gaming establishment. The patron may be guided to a destination of interest by a highlighted path (or the like), audio prompts, etc.
Information button 409 can provide further information regarding the items on GUI 400 a and/or regarding other related topics. “Back” button 413 allows the patron to return to GUI 300.
In this example, when any of the features in area 403 are selected and the “Enter” button 411 is engaged, it will be determined in step 210 (see FIG. 2) that there are additional options for the received wager gaming notification parameters. Therefore, a modified GUI (e.g., a pull-down menu or the like) or another GUI will be presented. (Step 215.)
Because the patron selected “Hits in Predetermined Areas” from area 403, GUI 400 b of FIG. 4B provides the patron with additional selections that pertain to areas of a roulette wheel. The selections indicated in area 415 pertain to a roulette wheel having 36 numbers, including zero, such as the roulette wheel depicted in FIGS. 7B and 7C. Accordingly, the patron is provided the option of selecting quarters, sixths or twelfths, because 36 numbers may be divided evenly into these fractions. In this example, the specific number ranges corresponding to these fractions are predetermined and need not be selected by the patron.
However, in some cases a patron may indicate a desire to select desired areas or number ranges of interest. In some implementations, if the patron chooses the field corresponding to “Select Desired Areas” or “Select Number Ranges” in area 415, the patron will be presented with a GUI having a depiction of a roulette wheel, e.g., similar to that shown in FIG. 7A. The patron may then select desired areas and/or number ranges of interest by interacting with this GUI.
The patron may also indicate whether a detailed analysis is desired (see area 417) and whether the patron wishes to select parameters for the analysis (see area 419). In this case, the patron has indicated that a detailed analysis should be provided upon the patron's request, instead of being provided automatically or not being provided at all. When the patron activates Enter button 411, the selections on GUI 400 b will be accepted and a corresponding follow up GUI will be presented.
In this example, the next GUI is shown in FIG. 4C. In this case, because the patron indicated that a detailed analysis was desired and that the patron wished to select parameters for the analysis, GUI 400 c includes field 421 for indicating an analysis type and area 423 for indicating an analysis presentation style. In this example, in area 421 a patron may select an analysis and the presentation based upon the hits for particular roulette numbers, hits within a specified area, etc. (“Raw Hit Data”) or to have the analysis and the presentation based upon both raw hits and probability information (“Hits and Probabilities”).
Here, the patron has selected “Hits and Probabilities” and has also selected to accept the system defaults regarding hit and probability parameters. If the patron had chosen to select hit and/or probability parameters, further choices would be provided in one or more follow-up GUIs, pull-down menus, or the like.
Some patrons may wish to know about hits on one or more favorite or “lucky” numbers, may wish to set raw hit and/or probability thresholds for notification, etc. For example, a patron may wish to be notified when a particular number, a particular fraction of the roulette wheel, etc., has not been hit within a predetermined number of spins. Alternatively, or additionally, a patron may wish to be notified when a particular number, a particular fraction of the roulette wheel, etc., has been hit more than a specified number of times during a predetermined number of spins.
Some patrons may wish to set probability thresholds for notification. For example, this patron has indicated that the analysis should be based, at least in part, on hits within quarters of a roulette wheel. Accordingly, such a patron may wish to be notified when the hit frequency for a particular quarter (or for any quarter) of a roulette wheel substantially deviates from once every four times, e.g., when a quarter of a roulette wheel has been hit more than ⅓ of the time during a predetermined time, number of spins, etc.
A patron may also set a raw hit and/or a probability threshold based on other criteria, such as color criteria. For example, a patron may as to be notified when either red or black has been hit more than a threshold number of times and/or percentage of the time within a predetermined time, number of spins, etc.
In some implementations, the players may be able to select the parameters of any such criteria without constraint. In other implementations, a player may be provided with predetermined numbers of plays, numbers of days, etc., and will need to select from predetermined ranges. For example, the player could be presented with predetermined ranges of plays (e.g., the last 100 plays, the last 500 plays, the last 1,000 plays, the last 5,000 plays, the last 10,000 plays, etc.), predetermined periods of time (e.g., the last 30 minutes, the last hour, the last day, the last 3 days, the last week, the last month), etc.
Area 423 allows the patron to specify details regarding analysis presentation. As noted elsewhere, such a presentation may be provided automatically upon notification or may be provided upon request. Some examples of analysis presentation will be described below with reference to FIGS. 7A-7C. Here, the patron may select the appropriate field of area 423 to indicate an analysis presentation that includes numbers and text only or numbers, text and graphics. Some such notifications may indicate, e.g., raw hits and/or probability deviations in graphical form. For example, some such analysis presentations may indicate peaks over numbers/ranges of numbers/areas that are being disproportionally “hit.”
As mentioned elsewhere herein, some implementations of the invention provide information and/or analysis regarding particular individuals. Area 425 allows a patron to select one such type of information: a patron can indicate whether the system should provide information and/or analysis regarding a particular croupier. For example, a patron may wish for a hit frequency and/or probability analysis to re-start whenever the croupier at a roulette table changes. This would allow data to be acquired that is specific to the new croupier. A patron may wish to know at which table a particular croupier is working, perhaps believing that this croupier has a style that tends to produce less than random game outcomes.
After making selections on GUI 400 c, in this example the patron will have the option of choosing a preferred notification mode and notification device type. GUI 400 d of FIG. 4D allows the patron to choose whether to receive a notification via a voice message, a text message, email and/or in another mode. (See area 427.)
Area 428 allows a patron to select event-based or time-based notifications. As an example of event-based notification, a player who is currently free to participate in wagering games may wish to receive notification of specified wagering conditions as soon as they arise, so as not to miss a wagering opportunity. However, if a patron knows that he or she will not be available to participate in wagering games until a particular time (e.g., until after work), the patron may choose to be notified only at that time and/or during the noon hour, known break times, etc. Some implementations of the invention allow a patron to specify one or more particular times of day if time-based notification is selected. In the example shown in FIG. 4D, a patron may specify time intervals for notification, which may be expressed in units of days. Partial days are acceptable, e.g., 0.1 of a day, 0.25 of a day, etc. In some implementations, a patron may choose to have at least some notifications saved (at least for a period of time), so that the patron may review them at a time of the patron's convenience.
The patron may indicate the type of device(s) for receiving notifications in area 429. Here, the patron has requested to receive notification on her own device, so a GUI is presented that allows the patron to provide more details regarding this device: GUI 400 e of FIG. 4E allows the patron to specify device type (see area 431) and device identification/address information (see area 431).
At this stage, it is determined that there are no additional options that the patron needs to provide regarding the previously-received parameters (see step 210 of FIG. 2), but it is also determined that the patron wishes to continue specifying some wager gaming notification parameters. (Step 220.) In this example, the patron has activated “Back” buttons 413 until she reached GUI 300 once again.
Referring to FIG. 3B, the patron now chooses “Slots/Video Poker” from area 303. She also decides to acknowledge that she is actually a member of a casino's player loyalty program. (See area 305.) She accepts these selections by activating “Enter” button 311.
GUI 500 a of FIG. 5A is then presented. Area 501 a prompts the patron to indicate the type(s) of slot information or video poker information of interest. As mentioned above, such prompts may be made and/or other information may be presented in audio form. In area 503, the patron is presented with a number of choices that include specific game outcomes, hot or cold machines, jackpots or other outcomes. Here, the patron indicates an interest in video poker outcomes.
Area 505 proves a field for the patron to indicate her player loyalty program number. In some implementations, one or more databases of a player loyalty program may be referenced to provide information relevant to the present invention. For example, player preference data from such a database may be referenced to determine, at least in part, the types of wager gaming opportunities, offers, etc., that may be of interest to the patron. Notifications provided to the player may be based, at least in part, upon such data. Moreover, the player's actual responses to notifications, offers, etc., may be recorded and stored in a player loyalty program database.
When the player activates Enter button 511, these choices are accepted and GUI 500 b is presented. (See FIG. 5B.) Because the patron has indicated an interest in video poker outcomes, the patron is prompted to select relevant details. (See area 501 b.) Area 515 presents the patron with poker outcome types; she selects “Four of a Kind of Better” as a basis of a wager gaming notification. She indicates a desire to select her own parameters (see area 517) instead of accepting default parameters. She also indicates a desire to receive location and/or navigation data, e.g., in connection with at least some types of notification. (See area 519.) When the player activates Enter button 511, these choices are accepted.
GUI 500 c is then presented. (See FIG. 5C.) The patron is prompted to select her preferred analysis type and presentation. (See area 501 c.) In area 521, she selects an analysis based upon hits and probabilities and indicates her wish to select relevant parameters. She chooses an analysis presentation that includes numbers, text and graphics. (See area 523.) She then accepts her selections by clicking on button 511.
This action causes GUI 500 d to be presented (see FIG. 5D.) The patron is prompted to select her preferred hit/probability parameters for analysis and presentation. (See area 501 d.) In area 525, the patron may choose from various threshold types for her selected game outcome of “at least four of a kind.” Her threshold choices include at least one hit per an indicated number of games (or days, which may include partial days) or no hits per an indicated number of games (or days). She may also select “other options” if she desires an analysis and/or presentation based upon other thresholds or criteria.
Here, the patron selects a threshold of “no hits per 5,000 games.” In this example, if the patron activates information button 509, she will be presented with the odds of attaining her selected game outcome.
At this stage, it is determined that there are no additional options to provide the patron, according to the selections that she has made. (See step 210 of FIG. 2.) Moreover, it is determined that the patron does not wish to continue. (See step 220 of FIG. 2.) For example, the patron may activate an “End” button (not shown), switch off the device used to enter these data, etc. The patron's parameters are stored (step 225) and the process ends. (Step 230.) Those of skill in the art will appreciate that the step of storing the patron's parameters may preferably occur at various times throughout the above-described process. However, in some implementations, these data may be stored locally until the process appears to be at or near completion, then stored in a central location, e.g., in a storage device used by a casino computer network, by a network storage device, etc.
Some examples of monitoring wagering conditions and providing notifications will now be described with reference to FIGS. 6 through 7C. Referring first to FIG. 6, in step 601 wagering conditions are monitored according to received wager gaming notification parameters. These parameters may, for example, have been received through a process such as that described above.
The monitoring process may involve various devices and/or people, which may be inside and/or outside a casino. Wager gaming machines, networked table games, etc. may be polled by one or more servers, host devices, etc., of a casino network. Alternatively, or additionally, such devices may send relevant information to such servers, host devices, etc., without the need for polling. Casino attendants or other individuals may provide updates regarding the wager gaming outcomes, etc., for some wagering activities, e.g., of table games that are not automated and/or configured for communication with a network. Information regarding sporting events, key players, coaches, etc., may be obtained from outside news sources. In some implementations, such information may be provided by RSS (Really Simple Syndication) feeds or the like, which are configured to aggregate relevant data.
In this example, when it is determined (see step 605) that a wagering condition corresponds with a patron's wager gaming notification parameters, the patron is notified according to his or her notification parameters. (See step 610.) Accordingly, this example illustrates a type of “event-based” notification, as described above with reference to FIG. 4B. As noted above, in alternative implementations, such notification data will be stored until a time that the patron has indicated and the patron will be notified at the indicated time. Although the latter implementations may be sometimes referred to as “time based” rather than “event based,” the time of notification may in some instances be based upon an event (e.g., of the patron being within a jurisdiction that allows wager gaming, of the patron having a receiving device with a setting that indicates “notification mode” or the like, of the patron being within a gaming establishment, etc.).
Some examples of patron notifications and subsequent related communications are provided by FIGS. 7A through 7C. FIG. 7A indicates a notification 700 a that may be displayed on a device that a patron has identified for receipt of notifications, e.g., as described above. Here, notification 700 a provides an example of a notification that may be sent according to the wager gaming notification parameters indicated by the patron with reference to FIGS. 4A through 4E.
Accordingly, notification 700 a may be sent as an email (see FIG. 4D) to the patron's PDA (see FIG. 4E) and displayed upon the patron's PDA. For example, a server (or the like) of a casino computer network may cause the email to be sent. Alternatively, or additionally, a device of the casino's computer network may cause information to be sent to a patron's device and the patron's device will present a display in a predetermined format, but based upon the received information.
Because the patron indicated that a detailed analysis would be provided upon request (see FIG. 4B), field 701 provides general information regarding a wagering condition that corresponds to the patron's roulette-based wager gaming notification parameters. In this example, the patron is provided with a simple message that anomalous hits have been detected on a particular roulette table.
The patron may or may not wish to obtain further information regarding this notification. In this instance, it is determined that the patron desires further information (see step 615 of FIG. 6): the patron selects “Yes” in field 705 and activates “Reply” button 710.
Therefore, further details and analysis are provided (see step 620 of FIG. 6): GUI 700 b of FIG. 7B is then presented on the patron's PDA. In this example, the details and analysis are provided, at least in part, according to the patron's previously-indicated wager gaming notification parameters. Because the patron had previously indicated a desire to receive notifications based (in part) upon quarters of a roulette wheel, GUI 700 b includes further information about anomalous hits in a quarter of a roulette wheel in area 715: 110 of the last 400 hits were in a particular quarter of the roulette wheel. Area 720 provides a graphical depiction of a roulette wheel and identifies the quarter of interest.
Again, the patron may or may not believe that this is an interesting wagering condition. For example, the patron may or may not believe that the notification involves a wagering condition that is sufficiently anomalous to indicate a possible benefit to the patron. Here, it is determined that the patron desires still further information (see step 615 of FIG. 6): the patron selects “Yes” in field 715 and activates “Reply” button 710.
Accordingly, further details and analysis are provided (see step 620 of FIG. 6): GUI 700 c of FIG. 7C is then presented on the patron's PDA. In area 725, a breakdown is provided of the number of hits for each roulette number in the indicated quarter. The total of all these hits equals 110, as previously indicated, but the breakdown shown in area 725 provides the patron with yet more information regarding the wagering condition. It is determined that the patron does not desire further analysis at this time (see step 615 of FIG. 6): the patron selects “No” in field 730 and engages the “Reply” area 710.
However, it is determined that the patron would like to obtain location and/or navigation information (see step 615 of FIG. 6): the patron has selected “Yes” in field 735, indicating that the patron would like directions to roulette table 15. Therefore, location and/or navigation information data are provided. (See step 630 of FIG. 6.)
For example, directions to roulette table 15 and/or a map indicating roulette table 15 may be provided.
As noted elsewhere herein, some implementations may provide real-time navigation features such as those described in U.S. patent application Ser. No. ______ (attorney docket no. IGT1P410/P-1222), entitled “Real-Time Navigation Devices, Systems and Methods,” which has been incorporated herein by reference. According to some such implementations, the patron may be presented with image data that may include images from cameras positioned at various locations, e.g., within a wager gaming establishment. The patron may be guided to roulette table 15 by a highlighted path (or the like), audio prompts, etc. While en route or while at the destination, the patron may be presented with information about the casino, offers of potential interest (e.g., according to the patron's preference data), etc.
In this example, the patron reaches roulette table 15 and begins a wager gaming session. (See step 635 of FIG. 6.) Information about the patron's wager gaming session will be stored. (Step 640.) In some implementations, the patron's preference data and/or wager gaming notification parameters may be modified according to observed wager gaming of the patron. If the patron indicates a desire to continue monitoring of wagering conditions according to her wager gaming notification parameters (e.g., according to a setting of her portable device), it will be determined in step 645 that the process will continue. If not, the process will end, at least temporarily. (Step 650.)
FIG. 8 is a simplified block diagram of an exemplary mobile device 800 in accordance with a specific embodiment of the present invention. As illustrated in the example of FIG. 8, mobile device 800 may include a variety of components, modules and/or systems for providing functionality relating to one or more aspects of the present invention. For example, as illustrated in FIG. 8, mobile device 800 may include one or more of the following:

- At least one processor 810. In at least one implementation, the processor(s) 810 may include functionality similar to processor(s) 310 of FIG. 3.
- Memory 816, which, for example, may include volatile memory (e.g., RAM), non-volatile memory (e.g., disk memory, FLASH memory, EPROMs, etc.), unalterable memory, and/or other types of memory. In at least one implementation, the memory 816 may include functionality similar to memory 316 of FIG. 3.
- Interface(s) 806 which, for example, may include wired interfaces and/or wireless interfaces. In at least one implementation, the interface(s) 806 may include functionality similar to interface(s) 306 of FIG. 3.
- Device driver(s) 842. In at least one implementation, the device driver(s) 842 may include functionality similar to device driver(s) 342 of FIG. 3.
- At least one power source 843. In at least one implementation, the power source may include at least one mobile power source for allowing the mobile device to operate in a mobile environment.
- Authentication/validation components 844 which, for example, may be used for authenticating and/or validating local hardware and/or software components and/or hardware/software components residing at a remote device. In at least one implementation, the authentication/validation component(s) 843 may include functionality similar to authentication/validation component(s) 344 of FIG. 3.
- Geolocation module 846 which, for example, may be configured or designed to acquire geolocation information from remote sources and use the acquired geolocation information to determine information relating to a relative and/or absolute position of the mobile device. For example, in one implementation, the geolocation module 846 may be adapted to receive GPS signal information for use in determining the position or location of the mobile device. In another implementation, the geolocation module 846 may be adapted to receive multiple wireless signals from multiple remote devices (e.g., gaming machines, servers, wireless access points, etc.) and use the signal information to compute position/location information relating to the position or location of the mobile device.
- Wireless communication module(s) 845. In one implementation, the wireless communication module 845 may be configured or designed to communicate with external devices using one or more wireless interfaces/protocols such as, for example, 802.11 (WiFi), 802.15 (including Bluetooth™), 802.16 (WiMax), 802.22, Cellular standards such as CDMA, CDMA2000, WCDMA, Radio Frequency (e.g., RFID), Infrared, Near Field Magnetics, etc.
- User Identification module 847. In one implementation, the User Identification module may be adapted to determine the identity of the current user or owner of the mobile device. For example, in one embodiment, the current user may be required to perform a log in process at the mobile device in order to access one or more features. Alternatively, the mobile device may be adapted to automatically determine the identity of the current user based upon one or more external signals such as, for example, an RFID tag or badge worn by the current user which provides a wireless signal to the mobile device for determining the identity of the current user. In at least one implementation, various security features may be incorporated into the mobile device to prevent unauthorized users from accessing confidential or sensitive information.
- Information filtering module(s) 849.
- One or more display(s) 835.
- One or more radio frequency identification readers 855.
- One or more radio frequency identification tags 857.
- One or more user I/O Device(s) 830 such as, for example, keys, buttons, scroll wheels, cursors, touchscreen interfaces, audio command interfaces, etc.
- Audio system 839 which, for example, may include speakers, microphones, wireless transmitter/receiver devices for enabling wireless audio and/or visual communication between the mobile device 800 and remote devices (e.g., radios, telephones, computer systems, etc.). For example, in one implementation, the audio system may include components for enabling the mobile device to function as a cell phone or two-way radio device.
- Magnetic strip reader 825, which, for example, may be configured or designed to read information from magnetic strips such as those on credit cards, player tracking cards, etc.
- Optical scanner 827, which, for example, may be configured or designed to read information such as text, barcodes, etc.
- Camera 829 which, for example, may be configured or designed to record still images (e.g., digital snapshots) and/or video images.
- Other types of peripheral devices 831 which may be useful to the users of such mobile devices, such as, for example: PDA functionality; memory card reader(s); fingerprint reader(s); image projection device(s); ticket reader(s); etc.

According to a specific embodiment, the mobile device of the present invention may be adapted to implement at least a portion of the features associated with the mobile game service system described in U.S. patent application Ser. No. 10/115,164, which is now U.S. Pat. No. 6,800,029, issued Oct. 5, 2004, (previously incorporated by reference in its entirety). For example, in one embodiment, the mobile device 800 may be comprised of a hand-held game service user interface device (GSUID) and a number of input and output devices. The GSUID is generally comprised of a display screen which may display a number of game service interfaces. These game service interfaces are generated on the display screen by a microprocessor of some type within the GSUID. Examples of a hand-held GSUID which may accommodate the game service interfaces are manufactured by Symbol Technologies, Incorporated of Holtsville, N.Y.
The game service interfaces may be used to provide a variety of game service transactions and gaming operations services. The game service interfaces, including a login interface, an input/output interface, a transaction reconciliation interface, a ticket validation interface, a prize services interfaces, a food services interface, an accommodation services interfaces, a gaming operations interfaces, a multi-game/multi-denomination meter data transfer interface, etc. Each interface may be accessed via a main menu with a number of sub-menus that allow a game service representative to access the different display screens relating to the particular interface. Using the different display screens within a particular interface, the game service representative may perform various operations needed to provide a particular game service. For example, the login interface may allow the game service representative to enter a user identification of some type and verify the user identification with a password. When the display screen is a touch screen, the user may enter the user/operator identification information on a display screen comprising the login interface using the input stylus and/or using the input buttons. Using a menu on the display screen of the login interface, the user may select other display screens relating to the login and registration process. For example, another display screen obtained via a menu on a display screen in the login interface may allow the GSUID to scan a finger print of the game service representative for identification purposes or scan the finger print of a game player.
The user identification information and user validation information may allow the game service representative to access all or some subset of the available game service interfaces available on the GSUID. For example, certain users, after logging into the GSUID (e.g. entering a user identification and a valid user identification information), may be able to access the food services interface, accommodation services interface, or gaming operation services interface and perform a variety of game services enabled by these game service interfaces. While other users may be only be able to access the award ticket validation interface and perform EZ pay ticket validations.
Using the input/output interface, a user of the GSUID may be able to send and receive game service transaction information from a number of input mechanisms and output mechanisms. The input/output interface may allow the GSUID user to select, from a list of devices stored in a memory on the GSUID, a device from which the GSUID may input game service transaction information or output game service transaction information. For example, the GSUID may communicate with a ticket reader that reads game service transaction information from bar-coded tickets. The bar-codes may be read using a bar-code reader of some type. The bar-coded tickets may contain bar-code information for awards, prizes, food services, accommodation services and EZ pay tickets. Additionally, the bar-coded tickets may contain additional information including player tracking information that relate the ticket to a specific game player. The information on a ticket is not necessarily in bar-code format and may be in any format readable by a particular ticket reader. As another example, the GSUID may input information from a card reader that reads information from magnetic striped cards or smart cards. The cards may contain player tracking information or other information regarding the game playing habits of the user presenting the card.
The GSUID may output game service transaction information to a number of devices. For example, to print a receipt, the GSUID may output information to a printer. In this game service transaction, the GSUID may send a print request to the printer and receive a print reply from the printer. The printer may be a large device at some fixed location or a portable device carried by the game service representative. As another example, the output device may be a card reader that is able to store information on a magnetic card or smart card. Other devices which may accept input or output from the GSUID are personal digital assistants, microphones, keyboard, storage devices, gaming machines and remote transaction servers.
The GSUID may communicate with the various input mechanisms and output mechanisms using both wire and wire-less communication interfaces. For example, the GSUID may be connected to a ticket reader by a wire connection of some type. However, the GSUID may communicate with a remote transaction server via a wire-less communication interface including a spread spectrum cellular network communication interface. An example of a spread spectrum cellular network communication interface is Spectrum 24 offered by Symbol Technologies of Holtsville, N.Y., which operates between about 2.4 and 2.5 Gigahertz. As another example, the GSUID may communicate with the printer via an infra-red wire-less communication interface. The information communicated using the wire-less communication interfaces may be encrypted to provide security for certain game service transactions such as validating a ticket for a cash pay out. Some devices may accommodate multiple communication interfaces. For example, a gaming machine may contain a wire-less communication interface for communication with the GSUID or a port where a cable from the GSUID may be connected to the gaming machine.
Another type of game service interface that may be stored on the GSUID is an award ticket validation interface. One embodiment of the award ticket interface may accommodate the EZ pay ticket voucher system and validate EZ pay tickets as previously described. However, when other ticket voucher systems are utilized, the award ticket validation interface may be designed to interface with the other ticket voucher systems. Using the award ticket validation interface, a game service representative may read information from a ticket presented to the game service representative by a game player using the ticket reader and then validate and pay out an award indicated on the ticket.
Typically, the award ticket contains game service transaction information which may be verified against information stored on a remote transaction server. To validate the ticket may require a number of game service transactions. For example, after the obtaining game service transaction information from the award ticket, the GSUID may send a ticket validation request to the remote transaction server using the spread spectrum communication interface and receive a ticket validation reply from the remote server. In particular, the validation reply and the validation request may be for an EZ pay ticket. After the award ticket has been validated, the GSUI may send a confirmation of the transaction to the remote server. In other embodiments, the award ticket interface may be configured to validate award information from a smart card or some other portable information device or validate award information directly from a gaming machine.
As game service transactions are completed, game service transaction information may be stored on a storage device. The storage device may be a remote storage device or a portable storage device. The storage device may be used as a back-up for auditing purpose when the memory on the GSUID fails and may be removable from the GSUID.
Another type of game service interface that may be stored on the GSUID is a prize service interface. As an award on a gaming machine, a game player may receive a ticket that is redeemable for merchandise including a bike, a computer or luggage. Using the prize service interface, the game service representative may validate the prize service ticket and then check on the availability of certain prizes. For example, when the prize service ticket indicates the game player has won a bicycle, the game service representative may check whether the prize is available in a nearby prize distribution center. The GSUID may validate the prize ticket and check on the availability of certain prizes by communicating with a remote prize server. Further, the game service representative may have the prize shipped to a game player's home or send a request to have the prize sent to a prize distribution location. The game service transactions needed to validate the prize ticket including a prize validation request and a prize validation reply, check on the availability of prizes and order or ship a prize may be implemented using various display screens located within the prize interface. The different prize screens in the prize service interface may be accessed using a menu located on each screen of the prize service interface. In other embodiments, the prize service interface may be configured to validate prize information from a smart card or some other portable information device or validate award information directly from a gaming machine.
Another type of game service interface that may be stored on the GSUID is a food service interface. As an award on a gaming machine or as compensation for a particular amount of game play, a game player may receive a ticket that is redeemable for a food service including a free meal, a free drink or other food prizes. Using the food service interface, the game service representative may validate the food service ticket and then check on the availability of certain prizes. For example, when the game player has received an award ticket valid for a free meal, the food service interface may be used to check on the availability of a dinner reservation and make a dinner reservation. As another example, the GSUID may be used to take a drink order for a player at a gaming machine. The GSUID may validate the food service ticket and check on the availability of certain food awards by communicating with a remote food server. The game service transactions needed to validate the food ticket, check on the availability of food services, request a food service and receive a reply to the food service request may be implemented using various display screens located within the food service interface. These display screens may be accessed using a menu located on each screen of the food service interface. In other embodiments, the food service interface may be configured to validate food service information from a smart card or some other portable information device.
Another type of game service interface that may be stored on the GSUID is an accommodation service interface. As an award on a gaming machine or as compensation for a particular amount of game play, a game player may receive a ticket that is redeemable for a accommodation service including a room upgrade, a free night's stay or other accommodation prize. Using the accommodation service interface, the game service representative may validate the accommodation service ticket and then check on the availability of certain accommodation prizes. For example, when the game player has received an award ticket valid for a room upgrade, the accommodation service interface may be used to check on the availability of a room and make a room reservation. As another example, the GSUID may be used to order a taxi or some other form of transportation for a player at a gaming machine preparing to leave the game playing area. The game playing are may be a casino, a hotel, a restaurant, a bar or a store.
The GSUID may validate the accommodation service ticket and check on the availability of certain accommodation awards by communicating with a remote accommodation server. The game service transactions needed to validate the accommodation ticket, check on the availability of accommodation services, request an accommodation service and receive a reply to the accommodation service request may be implemented using various display screens located within the accommodation service interface. These display screens may be accessed using a menu located on each screen of the accommodation service interface. In other embodiments, the accommodation service interface may be configured to validate accommodation service information from a smart card or some other portable information device.
Another type of game service interface that may be stored on the GSUID is a gaming operations service interface. Using the gaming service interface on the GSUID, a game service representative may perform a number of game service transactions relating to gaming operations. For example, when a game player has spilled a drink in the game playing area, a game service representative may send a request to maintenance to have someone clean up the accident and receive a reply from maintenance regarding their request. The maintenance request and maintenance reply may be sent and received via display screens selected via a menu on the screens of the gaming operations service interface. As another example, when a game service representative observes a damaged gaming machine such as a broken light, the game service representative may send a maintenance request for the gaming machine using the GSUID.
Another type of game service interface that may be stored on the GSUID is a transaction reconciliation interface. Typically, the GSUID contains a memory storing game service transaction information. The memory may record the type and time when particular game service transactions are performed. At certain times, the records of the game service transactions stored within the GSUID may be compared with records stored at an alternate location. For example, for an award ticket validation, each time an award ticket is validated and paid out, a confirmation is sent to a remote server. Thus, information regarding the award tickets, which were validated and paid out using the GSUID, should agree with the information regarding transactions by the GSUID stored in the remote server. The transaction reconciliation process involves using the transaction reconciliation interface to compare this information.
Another type of game service interface that may be stored on the GSUID is a voice interface. Using the spread spectrum cellular network incorporated into the GSUID, a game service representative may use the GSUID as a voice communication device. This voice interface may be used to supplement some of the interfaces previously described. For example, when a game player spills a drink the game service representative may send maintenance request and receive a maintenance reply using the voice interface on the GSUID. As another example, when a game player requests to validate a food service such as free meal, the game service representative may request a reservation at a restaurant using the voice interface on the GSUID.
Yet another game service interface that may be provided by the GSUID is a gaming device performance or metering data transfer interface. As mentioned, the GSUID preferably contains memory to record any wireless transfer of performance or metering data from the gaming device. More preferably, this wireless data transfer interface is particularly suitable for metering data in gaming devices which support multi-game platforms with multi-denomination inputs. For example, in a multi-game gaming device, which typically includes separate denomination meters for each game of the multiple games, a single gaming maintenance personnel is capable of downloading this metering data quickly and efficiently into the GSUID for subsequent data processing.
Some networks described herein provide methods and devices for managing one or more networked gaming establishments. Such networks may sometimes be referred to herein as server-based gaming networks, Sb™ networks, or the like. Some such gaming networks described herein allow for the convenient provisioning of networked gaming machines and other devices relevant to casino operations. Game themes may be easily and conveniently added or changed, if desired. Related software, including but not limited to player tracking software, peripheral software, etc., may be downloaded to networked gaming machines and other devices, such as kiosks, networked gaming tables, player stations, etc.
Relevant information is set forth in U.S. patent application Ser. No. 11/225,407 (Attorney Docket No. IGT1P237/P-1051), by Wolf et al., entitled “METHODS AND DEVICES FOR MANAGING GAMING NETWORKS” and filed Sep. 12, 2005, in U.S. patent application Ser. No. 10/757,609 by Nelson et al., entitled “METHODS AND APPARATUS FOR GAMING DATA DOWNLOADING” (Attorney Docket No. IGT1P213/P-657) and filed on Jan. 14, 2004, in U.S. patent application Ser. No. 10/938,293 by Benbrahim et al., entitled “METHODS AND APPARATUS FOR DATA COMMUNICATION IN A GAMING SYSTEM” (Attorney Docket No. IGT1P199/P-909) and filed on Sep. 10, 2004, in U.S. patent application Ser. No. 11/225,337 (Attorney Docket No. IGT1P185/P-1017) by Nguyen et al., filed Sep. 12, 2005 and entitled “DISTRIBUTED GAME SERVICES,” in U.S. patent application Ser. No. 11/225,408 (Attorney Docket No. IGT1P253) by Kinsley et al., entitled “METHODS AND DEVICES FOR AUTHENTICATION AND LICENSING IN A GAMING NETWORK” and filed Aug. 1, 2005, in U.S. patent application Ser. No. 11/078,966 (Attorney Docket No. IGT1P034X2/P-277 CIP2) by Nguyen et al., filed Mar. 10, 2005 and entitled “SECURED VIRTUAL NETWORK IN A GAMING ENVIRONMENT,” in U.S. patent application Ser. No. 11/173,442 (Attorney Docket No. IGT1P153/P-991) by Kinsley et al., filed Jul. 1, 2005 and entitled “METHODS AND DEVICES FOR DOWNLOADING GAMES OF CHANCE” and in U.S. patent application Ser. No. 11/810,888 (Attorney Docket No. IGT1P390/P-1200) by Graham et al., filed Jun. 6, 2007 and entitled “DATABASE QUERIES WITHIN A GAMING MACHINE,” all of which are hereby incorporated by reference in their entirety and for all purposes.
Some such networks include devices that provide functionality relating to the present invention. For example, information may conveniently be collected from networked devices, including but not limited to cameras, RFID readers, gaming machines, etc. Such devices, and other devices, may be controlled by servers, host devices, etc., to further the objects of the invention. For example, a camera may be controlled to zoom in and/or higher-resolution images may be acquired for a particular patron of interest. One or more of servers, host devices, cameras or other devices may be configured with software for patron identification, patron tracking, event detection and/or making responses thereto.
One example of an Sb™ network is depicted in FIG. 9. Those of skill in the art will realize that this architecture and the related functionality are merely examples and that the present invention encompasses many other such embodiments and methods.
Here, casino computer room 920 and networked devices of a gaming establishment 905 are illustrated. Gaming establishment 905 is configured for communication with central system 963 via gateway 950. Gaming establishments 993 and 995 are also configured for communication with central system 963.
In some implementations, gaming establishments may be configured for communication with one another. In this example, gaming establishments 993 and 995 are configured for communication with casino computer room 920. Such a configuration may allow devices and/or operators in casino 905 to communicate with and/or control devices in other casinos. In some such implementations, a server in computer room 920 may control devices in casino 905 and devices in other gaming establishments. Conversely, devices and/or operators in another gaming establishment may communicate with and/or control devices in casino 905.
For example, a server of casino 905 or central system 963 may be provisioned with relatively more advanced software (e.g., 3-D facial recognition software) for patron identification than servers of other networked locations. Such a server may process patron identification requests from devices in casino 905 as well as patron identification requests from devices in gaming establishments 993 and 995.
Here, gaming establishment 997 is configured for communication with central system 963, but is not configured for communication with other gaming establishments. Some gaming establishments (not shown) may not be in communication with other gaming establishments or with a central system.
Gaming establishment 905 includes multiple gaming machines 921, each of which is part of a bank 910 of gaming machines 921. In this example, gaming establishment 905 also includes a bank of networked gaming tables 953. However, the present invention may be implemented in gaming establishments having any number of gaming machines, gaming tables, etc. It will be appreciated that many gaming establishments include hundreds or even thousands of gaming machines 921 and/or gaming tables 953, not all of which are necessarily included in a bank and some of which may not be connected to a network.
Some gaming networks provide features for gaming tables that are similar to those provided for gaming machines, including but not limited to bonusing, player loyalty/player tracking and the use of cashless instruments. Relevant material is provided in U.S. patent application Ser. No. 11/154,833, entitled “CASHLESS INSTRUMENT BASED TABLE GAME PROMOTIONAL SYSTEM AND METHODOLOGY” and filed on Jun. 15, 2005 (attorney docket no. IGT1P035X3), U.S. Provisional Patent Application No. 60/858,046, entitled “AUTOMATED PLAYER DATA COLLECTION SYSTEM FOR TABLE GAME ENVIRONMENTS” and filed on Nov. 10, 2006 (attorney docket no. IGT1P061X5P), U.S. patent application Ser. No. 11/129,702, entitled “WIDE AREA TABLE GAMING MONITOR AND CONTROL SYSTEM” and filed on May 15, 2005 (attorney docket no. IGT1P115), U.S. patent application Ser. No. 11/425,998 entitled “PROGRESSIVE TABLE GAME BONUSING SYSTEMS AND METHODS”, filed Jun. 22, 2006 (attorney docket no. IGT1P238/P-1049) and U.S. patent application Ser. No. 11/225,299, entitled “UNIVERSAL CASINO BONUSING SYSTEMS AND METHODS” and filed on Sep. 12, 2005 (attorney docket no. IGT1P243), all of which are incorporated herein by reference. Accordingly, software related to such features may be provided and/or controlled, and related data may be obtained and/or provided, according to the present invention.
Some configurations can provide automated, multi-player roulette, blackjack, baccarat, and other table games. The table games may be conducted by a dealer and/or by using some form of automation, which may include an automated roulette wheel, an electronic representation of a dealer, etc. In some such implementations, devices such as cameras, radio frequency identification devices, etc., may be used to identify and/or track playing cards, chips, etc. Some of gaming tables 953 may be configured for communication with individual player terminals (not shown), which may be configured to accept bets, present an electronic representation of a dealer, indicate game outcomes, etc.
Some gaming networks include electronically configurable tables for playing table games. U.S. patent application Ser. No. 11/517,861, entitled “CASINO DISPLAY METHODS AND DEVICES” and filed on Sep. 7, 2006 (attorney docket no. IGT1P106X2), describes some such tables and is hereby incorporated by reference. An operator may select a desired game, such as a poker game or a blackjack game, and the table will be automatically configured with geometrical patterns, text, etc., which are appropriate for the desired table game. The desired type of table game may be selected by a control on the table itself or according to instructions received from, e.g., a server or a casino manager via a network interface.
Gaming establishment 905 also includes networked kiosks 977. Depending on the implementation, kiosks 977 may be used for various purposes, including but not limited to cashing out, prize redemption, redeeming points from a player loyalty program, redeeming “cashless” indicia such as bonus tickets, smart cards, etc. In some implementations, kiosks 977 may be used for obtaining information about the gaming establishment, e.g., regarding scheduled events (such as tournaments, entertainment, etc.), regarding a patron's location, etc. Software related to such features may be provided and/or controlled, and related data may be obtained and/or provided, according to the present invention. For example, in some implementations of the invention, kiosks 977 may be configured to receive information from a patron, e.g., by presenting graphical user interfaces similar to those described above and illustrated in FIGS. 4A through 6D.
In this example, each bank 910 has a corresponding switch 915, which may be a conventional bank switch in some implementations. Each switch 915 is configured for communication with one or more devices in computer room 920 via main network device 925, which combines switching and routing functionality in this example. Although various communication protocols may be used, some preferred implementations use the Gaming Standards Association's G2S Message Protocol. Other implementations may use IGT's open, Ethernet-based SuperSAS® protocol, which IGT makes available for downloading without charge. Still other protocols, including but not limited to Best of Breed (“BOB”), may be used to implement various aspects of the invention. IGT has also developed a gaming-industry-specific transport layer called CASH that rides on top of TCP/IP and offers additional functionality and security.
Here, gaming establishment 905 also includes an RFID network, implemented in part by RFID switches 919 and multiple RFID readers 917. An RFID network may be used, for example, to track objects (such as mobile gaming devices 970, which include RFID tags 927 in this example), patrons, etc., in the vicinity of gaming establishment 905. Some examples of how an RFID network may be used in a gaming establishment are set forth in U.S. patent application Ser. No. 11/655,496, entitled “DYNAMIC CASINO TRACKING AND OPTIMIZATION” and filed on Jan. 19, 2007 (Attorney Docket No. IGT1P082C1X1/P-713 CON CIP) and in U.S. patent application Ser. No. 11/599,241, entitled “DOWNLOADING UPON THE OCCURRENCE OF PREDETERMINED EVENTS” and filed on Nov. 13, 2006 (Attorney Docket No. IGT1P118C1X1/P-303 CON CIP), all of which are hereby incorporated by reference.
As noted elsewhere herein, some implementations of the invention may involve “smart” player loyalty instruments, such as player tracking cards, which include an RFID tag. Accordingly, the location of such RFID-enabled player loyalty instruments may be tracked via the RFID network. In this example, at least some of mobile devices 970 may include an RFID tag 927, which includes encoded identification information for the mobile device 970. Accordingly, the locations of such tagged mobile devices 970 may be tracked via the RFID network in gaming establishment 905. Other location-detection devices and systems, such as the global positioning system (“GPS”), may be used to monitor the location of people and/or devices in the vicinity of gaming establishment 905 or elsewhere.
Various alternative network topologies can be used to implement different aspects of the invention and/or to accommodate varying numbers of networked devices. For example, gaming establishments with large numbers of gaming machines 921 may require multiple instances of some network devices (e.g., of main network device 925, which combines switching and routing functionality in this example) and/or the inclusion of other network devices not shown in FIG. 9. Some implementations of the invention may include one or more middleware servers disposed between kiosks 977, RFID switches 919 and/or bank switches 915 and one or more devices in computer room 920 (e.g., a corresponding server). Such middleware servers can provide various useful functions, including but not limited to the filtering and/or aggregation of data received from switches, from individual gaming machines and from other devices. Some implementations of the invention include load-balancing methods and devices for managing network traffic.
Storage devices 911, Sb™ server 930, License Manager 931, Arbiter 933, servers 932, 934, 936 and 938, host device(s) 960 and main network device 925 are disposed within computer room 920 of gaming establishment 905. In practice, more or fewer devices may be used. Depending on the implementation, some such devices may reside in gaming establishment 905 or elsewhere.
One or more devices in central system 963 may also be configured to perform, at least in part, tasks specific to the present invention. For example, one or more servers 962, storage devices 964 and/or host devices 960 of central system 963 may be configured to implement the functions described in detail elsewhere herein. These functions may include, but are not limited to, communications with and/or collecting data from devices such as cameras 909, RFID readers 917, wager gaming machines 921, gaming tables 953, mobile devices 970, etc.
For example, one or more of the servers of computer room 920 may be configured with software for receiving a player's wager gaming notification parameters, determining when a wagering condition corresponds with the wager gaming notification parameters and/or providing a notification to the player when the wagering condition corresponds with the wager gaming notification parameters. Moreover, one or more of the servers may be configured to receive, process and/or provide image data from cameras 909, to provide navigation data to patrons (e.g., to indicate the location of and/or directions to a gaming table, a wager gaming machine, etc., associated with a wager gaming notification), etc.
For example, navigation data (which may include map data, casino layout data, camera image data, etc.) may be provided by one or more of the servers of computer room 920 to mobile devices 970. Some implementations of the present invention include a plurality of networked cameras 909, which may be video cameras, smart cameras, digital still cameras, etc. In some such implementations, such cameras may provide, at least in part, real-time navigation features such as those described in U.S. patent application Ser. No. ______ (attorney docket no. IGT1P410/P-1222), entitled “Real-Time Navigation Devices, Systems and Methods,” which has been incorporated herein by reference.
Other devices that may be used in connection with the present invention do not appear in FIG. 9. For example, some networks for implementing the present invention may include not only various radio frequency identification (“RFID”) readers 917, but also RFID switches, middleware servers, etc., some of which are not depicted in FIG. 9. These features may provide various functions related to the present invention. For example, a server (or another device) may determine a location of a mobile device 970 according to the location of an RFID reader that reads an RFID tag 927.
The servers and other devices indicated in FIG. 9 may be configured for communication with other devices in or outside of gaming establishment 905, such as host devices 960, kiosks 977 and/or mobile devices 970, for implementing some methods described elsewhere herein. For example, host devices 960, kiosks 977 and/or mobile devices 970 may be used to provide some of the graphical user interfaces and related functionality described above, e.g., with reference to FIGS. 4A through 7C. Servers (or the like) may facilitate communications with such devices, receive and store patron data, provide appropriate responses, etc., as described elsewhere herein.
Some of these servers may be configured to perform tasks relating to accounting, player loyalty, bonusing/progressives, configuration of gaming machines, etc. One or more such devices may be used to implement a casino management system, such as the IGT Advantage™ Casino System suite of applications, which provides instantaneous information that may be used for decision-making by casino managers. A Radius server and/or a DHCP server may also be configured for communication with the gaming network. Some implementations of the invention provide one or more of these servers in the form of blade servers.
Some preferred embodiments of Sb™ server 930 and the other servers shown in FIG. 9 include (or are at least in communication with) clustered CPUs, redundant storage devices, including backup storage devices, switches, etc. Such storage devices may include a “RAID” (originally redundant array of inexpensive disks, now also known as redundant array of independent disks) array, back-up hard drives and/or tape drives, etc.
In some implementations of the invention, many of these devices (including but not limited to License Manager 931, servers 932, 934, 936 and 938, and main network device 925) are mounted in a single rack with Sb™ server 930. Accordingly, many or all such devices will sometimes be referenced in the aggregate as an “Sb™ server.” However, in alternative implementations, one or more of these devices is in communication with Sb™ server 930 and/or other devices of the network but located elsewhere. For example, some of the devices could be mounted in separate racks within computer room 920 or located elsewhere on the network. Moreover, it can be advantageous to store large volumes of data elsewhere via a storage area network (“SAN”).
Computer room 920 may include one or more operator consoles or other host devices that are configured for communication with other devices within and outside of computer room 920. Such host devices may be provided with software, hardware and/or firmware for implementing various aspects of the invention. However, such host devices need not be located within computer room 920. Wired host devices 960 (which are desktop and laptop computers in this example) and wireless devices 970 (which are PDAs in this example) may be located elsewhere in gaming establishment 905 or at a remote location.
Some embodiments of the invention include devices for implementing access control, security and/or other functions relating to the communication between different devices on the network. In this example, arbiter 933 serves as an intermediary between different devices on the network. Arbiter 933 may be implemented, for example, via software that is running on a server or another networked device. Some implementations of Arbiter 933 are described in U.S. patent application Ser. No. 10/948,387, entitled “METHODS AND APPARATUS FOR NEGOTIATING COMMUNICATIONS WITHIN A GAMING NETWORK” and filed Sep. 23, 2004 (the “Arbiter Application”), which is incorporated herein by reference and for all purposes. In some preferred implementations, Arbiter 933 is a repository for the configuration information required for communication between devices on the gaming network (and, in some implementations, devices outside the gaming network). Although Arbiter 933 can be implemented in various ways, one exemplary implementation is discussed in the following paragraphs.
FIG. 10 is a block diagram of a simplified communication topology between gaming machine 921, network computer 1023 and Arbiter 933. Network computer 1023 may be, for example, a server or other device within computer room 920 or elsewhere. Although only one gaming machine 921, one network computer 1023 and one Arbiter 933 are shown in FIG. 10, it should be understood that the following examples may be applicable to different types of networked devices in addition to gaming machine 921 and network computer 1023, and may include different numbers of network computers 1023, Arbiters 933 and gaming machines 921. For example, a single Arbiter 933 may be used for secure communications among a plurality of network computers 1023 and tens, hundreds or thousands of gaming machines 921. Likewise, multiple Arbiters 933 may be utilized for improved performance and other scalability factors.
Referring to FIG. 10, the Arbiter 933 may include an arbiter controller 1021 that may comprise a program memory 1022, a microcontroller or microprocessor (MP) 1024, a random-access memory (RAM) 1026 and an input/output (I/O) circuit 1028, all of which may be interconnected via an address/data bus 1029. The network computer 1023 may also include a controller 1031 that may comprise a program memory 1032, a microcontroller or microprocessor (MP) 1034, a random-access memory (RAM) 1036 and an input/output (I/O) circuit 1038, all of which may be interconnected via an address/data bus 1039. It should be appreciated that although the Arbiter 933 and the network computer 1023 are each shown with only one microprocessor 1024, 1034, the controllers 1021, 1031 may each include multiple microprocessors 1024, 1034. Similarly, the memory of the controllers 1021, 1031 may include multiple RAMs 1026, 1036 and multiple program memories 1022, 1032. Although the I/ O circuits 1028, 1038 are each shown as a single block, it should be appreciated that the I/ O circuits 1028, 1038 may include a number of different types of I/O circuits. The RAMs 1024, 1034 and program memories 1022, 1032 may be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example.
Although the program memories 1022, 1032 are shown in FIG. 10 as read-only memories (ROM) 1022, 1032, the program memories of the controllers 1021, 1031 may be a read/write or alterable memory, such as a hard disk. In the event a hard disk is used as a program memory, the address/ data buses 1029, 1039 shown schematically in FIG. 10 may each comprise multiple address/data buses, which may be of different types, and there may be an I/O circuit disposed between the address/data buses.
As shown in FIG. 10, the gaming machine 921 may be operatively coupled to the network computer 1023 via the data link 1025. The gaming machine 921 may also be operatively coupled to the Arbiter 933 via the data link 1049, and the network computer 1023 may likewise be operatively coupled to the Arbiter 933 via the data link 1047.
Communications between the gaming machine 921 and the network computer 1023 may involve different information types of varying levels of sensitivity resulting in varying levels of encryption techniques depending on the sensitivity of the information. For example, communications such as drink orders and statistical information may be considered less sensitive. A drink order or statistical information may remain encrypted, although with moderately secure encryption techniques, such as RC4, resulting in less processing power and less time for encryption. On the other hand, financial information (e.g., account information, winnings, etc.), download information (e.g., game and/or peripheral software, licensing information, etc.) and personal information (e.g., social security number, personal preferences, etc.) may be encrypted with stronger encryption techniques such as DES or 3DES to provide increased security.
As disclosed in further detail in the Arbiter Application, the Arbiter 933 may verify the authenticity of devices in the gaming network, including but not limited to devices sending queries and/or remote procedure calls to gaming machines. The Arbiter 933 may receive a request for a communication session from a network device. For ease of explanation, the requesting network device may be referred to as the client, and the requested network device may be referred to as the host. The client may be any device on the network and the request may be for a communication session with any other network device. The client may specify the host, or the gaming security arbiter may select the host based on the request and based on information about the client and potential hosts. The Arbiter 933 may provide encryption keys (session keys) for the communication session to the client via the secure communication channel. Either the host and/or the session key may be provided in response to the request, or may have been previously provided. The client may contact the host to initiate the communication session. The host may then contact the Arbiter 933 to determine the authenticity of the client. The Arbiter 933 may provide affirmation (or lack thereof) of the authenticity of the client to the host and provide a corresponding session key, in response to which the network devices may initiate the communication session directly with each other using the session keys to encrypt and decrypt messages.
Alternatively, upon receiving a request for a communication session, the Arbiter 933 may contact the host regarding the request and provide corresponding session keys to both the client and the host. The Arbiter 933 may then initiate either the client or the host to begin their communication session. In turn, the client and host may begin the communication session directly with each other using the session keys to encrypt and decrypt messages. An additional explanation of the communication request, communication response and key distribution is provided in the Arbiter Application.
Referring again to FIG. 9, the communication link(s) between casino 905 and central system 963 preferably have ample bandwidth and may, for example, comprise one or more T1 or T3 connections and/or satellite links having comparable bandwidth, etc. Network 929 is the Internet in this example. However, it will be understood by those of skill in the art that network 929 could include any one of various types of networks, such as the public switched telephone network (“PSTN”), a satellite network, a wireless network, a metro optical transport, etc. Accordingly, a variety of protocols may be used for communication on network 929, such as Internet Protocol (“IP”), Fibre Channel (“FC”), FC over IP (“FCIP”), Internet SCSI (“iSCSI,” an IP-based standard for linking data storage devices over a network and transferring data by carrying SCSI commands over IP networks) or Dense Wavelength Division Multiplexing (“DWDM,” an optical technology used to increase bandwidth over existing fiber optic backbones).
If a host device is located in a remote location, security methods and devices (such as firewalls, authentication and/or encryption) should be deployed in order to prevent the unauthorized access of the gaming network.
Similarly, any other connection between gaming network 905 and the outside world should only be made with trusted devices via a secure link, e.g., via a virtual private network (“VPN”) tunnel. For example, the illustrated connection between Sb™ server 930, gateway 950 and central system 963 (that may be used for communications involving peripheral device software downloads, etc.) is advantageously made via a VPN tunnel. Details of VPN methods that may be used with the present invention are described in the reference, “Virtual Private Networks-Technologies and Solutions,” by R. Yueh and T. Strayer, Addison-Wesley, 2001, ISBN#0-201-70209-6, which is incorporated herein by reference and for all purposes. Additionally VPNs may be implemented using a variety of protocols, such as, for example, IP Security (IPSec) Protocol, Layer 2 Tunneling Protocol, Multiprotocol Label Switching (MPLS) Protocol, etc. Details of these protocols, including RFC reports, may be obtained from the VPN Consortium, an industry trade group (http://www.vpnc.com, VPNC, Santa Cruz, Calif.).
Alternatively, a permanent virtual circuit (“PVC”) can be established to provide a dedicated and secure circuit link between two facilities, e.g., between a casino and central system 963. A PVC is a virtual circuit established for repeated use between the same data terminals. A PVC could be provided, for example, via AT&T's Asynchronous Transfer Mode (“ATM”) switching fabric. Some implementations provide a dedicated line from an endpoint (e.g., from casino 905) into the ATM backbone. Other implementations provide a connection over another network (e.g., the Internet) between an endpoint and the nearest device of the ATM backbone, e.g., to the nearest edge router. In some such implementations, the fixed-sized cells used in the ATM switching fabric may be encapsulated in variable sized packets (such as Internet Protocol or Ethernet packets) for transmission to and from the ATM backbone.
For security purposes, information transmitted to, on or from a gaming establishment may be encrypted. In one implementation, the information may be symmetrically encrypted using a symmetric encryption key, where the symmetric encryption key is asymmetrically encrypted using a private key. The public key may, for example, be obtained from a remote public key server. The encryption algorithm may reside in processor logic stored on the gaming machine. When a remote server receives a message containing the encrypted data, the symmetric encryption key is decrypted with a private key residing on the remote server and the symmetrically encrypted information sent from the gaming machine is decrypted using the symmetric encryption key. A different symmetric encryption key is used for each transaction where the key is randomly generated. Symmetric encryption and decryption is preferably applied to most information because symmetric encryption algorithms tend to be 100-10,000 faster than asymmetric encryption algorithms.
Some network implementations may use Trusted Network Connect (“TNC”), which is an open architecture provided by the Trusted Network Connect Sub Group (“TNC-SG”) of the Trusted Computing Group (TCG). TNC enables network operators to provide endpoint integrity at every network connection, thus enabling interoperability among multi-vendor network endpoints. Alternatively, or additionally, the Secure Internet File Transfer (“SIFT”) may be employed. SIFT allows devices to send and receive data over the Internet in a secure (128-bit encryption) method of transport.
Providing secure connections between devices in a gaming network, such as the connections between the local devices of the gaming network 905 and central system 963, allows for the deployment of many advantageous features. For example, a customer (e.g., an employee of a gaming establishment) may be able to log onto an account of central system 963 to obtain the account information such as the customer's current and prior account status. Automatic updates of a customer's software may also be enabled. For example, central system 963 may notify one or more devices in gaming establishment 905 regarding new products and/or product updates. For example, central system 963 may notify server (or other device) in computer room 920 regarding new software, software updates, the status of current software licenses, etc. Alternatively, such updates could be automatically provided to a server in computer room 920 and downloaded to networked gaming machines.
After the local server receives this information, relevant products of interest may be identified (by the server, by another device or by a human being). If an update or a new software product is desired, it can be downloaded from the central system. Similarly, a customer may choose to renew a software license via a secure connection with central system 463, e.g., in response to a notification that the software license is required.
In addition, providing secure connections between different gaming establishments can enable alternative implementations of the invention. For example, a number of gaming establishments may be owned and/or controlled by the same entity. In such situations, having secure communications between gaming establishments makes it possible for a gaming entity to use one or more servers in a gaming establishment as an interface between central system 963 and gaming machines in multiple gaming establishments. For example, new or updated software may be obtained by a server in one gaming establishment and distributed to gaming machines in that gaming establishment and/or other gaming establishments. A server in one gaming establishment may perform services, such as patron identification services, in response to a request from a device in another gaming establishment.
FIG. 11 illustrates an example of a network device that may be configured for implementing some methods of the present invention. Network device 1160 includes a master central processing unit (CPU) 1162, interfaces 1168, and a bus 1167 (e.g., a PCI bus). Generally, interfaces 1168 include ports 1169 appropriate for communication with the appropriate media. In some embodiments, one or more of interfaces 1168 includes at least one independent processor and, in some instances, volatile RAM. The independent processors may be, for example, ASICs or any other appropriate processors. According to some such embodiments, these independent processors perform at least some of the functions of the logic described herein. In some embodiments, one or more of interfaces 1168 control such communications-intensive tasks as encryption, decryption, compression, decompression, packetization, media control and management. By providing separate processors for the communications-intensive tasks, interfaces 1168 allow the master microprocessor 1162 efficiently to perform other functions such as routing computations, network diagnostics, security functions, etc.
The interfaces 1168 are typically provided as interface cards (sometimes referred to as “linecards”). Generally, interfaces 1168 control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 1160. Among the interfaces that may be provided are FC interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, ASI interfaces, DHEI interfaces and the like.
When acting under the control of appropriate software or firmware, in some implementations of the invention CPU 1162 may be responsible for implementing specific functions associated with the functions of a desired network device. According to some embodiments, CPU 1162 accomplishes all these functions under the control of software including an operating system and any appropriate applications software.
CPU 1162 may include one or more processors 1163 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 1163 is specially designed hardware for controlling the operations of network device 1160. In a specific embodiment, a memory 1161 (such as non-volatile RAM and/or ROM) also forms part of CPU 1162. However, there are many different ways in which memory could be coupled to the system. Memory block 1161 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc.
Regardless of network device's configuration, it may employ one or more memories or memory modules (such as, for example, memory block 1165) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example.
Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). The invention may also be embodied in a carrier wave traveling over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher-level code that may be executed by the computer using an interpreter.
Although the system shown in FIG. 11 illustrates one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the network device. The communication path between interfaces may be bus based (as shown in FIG. 11) or switch fabric based (such as a cross-bar).
While this invention is described in terms of preferred embodiments, there are alterations, permutations, and equivalents that fall within the scope of the invention. It should also be noted that there are many alternative ways of implementing the present invention. It is therefore intended that the invention not be limited to the preferred embodiments described herein, but instead that the invention should be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention.

Claims

1. A wager gaming system, comprising:

means for receiving a player's wager gaming notification parameters;

means for determining when a wagering condition corresponds with the wager gaming notification parameters; and

means for providing a notification to the player when the wagering condition corresponds with the wager gaming notification parameters.

2. The wager gaming system of claim 1, wherein the receiving means comprises a user interface.

3. The wager gaming system of claim 1, wherein the determining means comprises a logic system.

4. The wager gaming system of claim 1, wherein the wager gaming notification parameters comprise information regarding a notification mode for providing the notification to the player and wherein the providing means comprises means for providing the notification according to the notification mode.

5. The wager gaming system of claim 1, wherein the wager gaming notification parameters comprise information regarding an occurrence of a wager gaming outcome within a specified time or a specified number of plays.

6. The wager gaming system of claim 1, wherein the wager gaming notification parameters comprise information regarding a non-occurrence of a wager gaming outcome within a specified time or a specified number of plays.

7. The wager gaming system of claim 1, wherein the wager gaming notification parameters comprise a probability of an occurrence or non-occurrence of a wager gaming outcome.

8. The wager gaming system of claim 1, wherein the receiving means comprises means for presenting a graphical user interface for receiving wager gaming notification parameters.

9. The wager gaming system of claim 3, wherein the logic system comprises at least one processor.

10. The wager gaming system of claim 4, wherein the notification mode comprises at least one of a text message, a voice message or an email message.

11. A wager gaming method, comprising:

receiving a player's wager gaming notification parameters;

determining when a wagering condition corresponds with the wager gaming notification parameters; and

providing a notification to the player when the wagering condition corresponds with the wager gaming notification parameters.

12. The wager gaming method of claim 11, wherein the receiving comprises receiving the wager gaming notification parameters via a user interface.

13. The wager gaming method of claim 11, wherein the wager gaming notification parameters comprise information regarding a notification mode for providing the notification to the player and wherein the providing means comprises means for providing the notification according to the notification mode.

14. The wager gaming method of claim 11, wherein the wager gaming notification parameters comprise information regarding an occurrence of a wager gaming outcome within a specified time or a specified number of plays.

15. The wager gaming method of claim 11, wherein the wager gaming notification parameters comprise information regarding a non-occurrence of a wager gaming outcome within a specified time or a specified number of plays.

16. The wager gaming method of claim 11, wherein the wager gaming notification parameters comprise a probability of an occurrence or non-occurrence of a wager gaming outcome.

17. The wager gaming method of claim 11, wherein the providing step comprises providing the player with at least one of a text message, a voice message or an email message.

18. The wager gaming method of claim 11, wherein the wager gaming notification parameters comprise information regarding a sporting match.

19. The wager gaming method of claim 11, wherein the wager gaming notification parameters comprise roulette game data.

20. The wager gaming method of claim 11, wherein the notification comprises information regarding a probability of the wagering condition.

21. The wager gaming method of claim 11, wherein the notification comprises information regarding an outcome of a Keno game.

22. The wager gaming method of claim 11, wherein the notification comprises information regarding a dealer or croupier of a table game.

23. The wager gaming method of claim 11, wherein the notification identifies at least one wager gaming machine or gaming table.

24. The wager gaming method of claim 19, wherein the roulette game data comprise roulette game outcomes relating to specified portions of a roulette wheel.

25. A wager gaming system, comprising:

an interface system for receiving a player's wager gaming notification parameters; and

a logic system comprising at least one logic device and configured to do the following:

determine when a wagering condition corresponds with the wager gaming notification parameters; and

cause a notification to be made to the player when the wagering condition corresponds with the wager gaming notification parameters.

26. The wager gaming system of claim 25, wherein the interface system comprises a user interface.

27. The wager gaming system of claim 25, wherein the interface system comprises at least one network interface.

28. The wager gaming system of claim 25, wherein the wager gaming notification parameters comprise information regarding a notification mode for providing the notification to the player and wherein the logic system causes the notification to be made according to the notification mode.

29. The wager gaming system of claim 25, wherein the wager gaming notification parameters comprise information regarding an occurrence of a wager gaming outcome within a specified time or a specified number of plays.

30. The wager gaming system of claim 25, wherein the wager gaming notification parameters comprise information regarding a non-occurrence of a wager gaming outcome within a specified time or a specified number of plays.

31. The wager gaming system of claim 25, wherein the wager gaming notification parameters comprise a probability of an occurrence or non-occurrence of a wager gaming outcome.

32. The wager gaming system of claim 25, wherein receiving means comprises means for presenting a graphical user interface for receiving wager gaming notification parameters.

33. The wager gaming system of claim 28, wherein the notification mode comprises at least one of a text message, a voice message or an email message.