Patent Application
20190051117
This disclosure relates generally to methods to facilitate communications and transactions related to placing, selling, or accepting bets between and among a bookmaker and registered bettors on a system operated by the bookmaker.
Online sports betting is estimated by the American Gaming Association to generate in excess of $100,000,000,000 bet annually. Online bookmakers typically offer an application that can be used by a bettor to register with the system, to open an account, to review bets offered by the bookmaker and to accept desired bets. These applications are typically provided for use on a bettor's mobile computing device, e.g., a smartphone, although bets can also be made via a website from a desktop computer.
It would be desirable for such a system to permit bettors to generate their own bets and offer them to other bettors or to the bookmaker. It would also be desirable for a bettor to sell an already-placed bet to another bettor or to the bookmaker.
To place a bet, a registered bettor must log in to his or her device, navigate to the event the bettor would like to bet on, view the odds, and decide whether or not to bet. Before accepting a bet, the bookmaker must verify the bettor's identity, confirm that the bettor is in a jurisdiction where online betting is permitted, confirm the funds in the account, and determine that the bet is still open, i.e., can still be accepted by a bettor.
The latter determination, confirming the bet is still open, can be problematic due to latency in any of the hardware involved at either end of the transaction, or in any of the networks that relay data between the bettor's device and the bookmaker's system.
Latency can prevent a bettor from having his or her bet accepted, especially in the case of in-game betting, also known as live betting. This is a bet that is made during the course of an already-started event, e.g., a football game. Betting odds can change during the course of a game, sometimes quite rapidly. Delay from the time the bettor sends his or her acceptance until it is received may result in rejection of the bet if the odds have just changed.
In another example, the bookmaker might offer a bet on whether a two-point conversion will be made. There is only a brief time between the touchdown and the start of the next play during which the bet acceptance must be received by the bookmaker. Even if the bet is accepted by the bettor at his or her mobile computing device before the start of the next play, latency may result in the acceptance being received after the play is over and thus result in the bookmaker rejecting the bet.
It would be desirable to facilitate betting on such a system in a way that overcomes the problems created by latency.
Referring to
The gaming device 10 includes a cabinet 15 housing components to operate the gaming device 10. The cabinet 15 may include a gaming display 20, a base portion 13, a top box 18, and a player interface panel 30. The gaming display 20 may include mechanical spinning reels (
The base portion 13 may include a lighted panel 14, a coin return (not shown), and a gaming handle 12 operable on a partially rotating pivot joint 11. The game handle 12 is traditionally included on mechanical spinning-reel games, where the handle may be pulled toward a player to initiate the spinning of reels 22 after placement of a wager. The top box 18 may include a lighted panel 17, a video display (such as an LCD monitor), a mechanical bonus device (not shown), and a candle light indicator 19. The player interface panel 30 may include various devices so that a player can interact with the gaming device 10.
The player interface panel 30 may include one or more game buttons 32 that can be actuated by the player to cause the gaming device 10 to perform a specific action. For example, some of the game buttons 32 may cause the gaming device 10 to bet a credit to be wagered during the next game, change the number of lines being played on a multi-line game, cash out the credits remaining on the gaming device (as indicated on the credit meter 27), or request service from casino personnel, such as by lighting the candle 19. In addition, the player interface panel 30 may include one or more game actuating buttons 33. The game actuating buttons 33 may initiate a game with a pre-specified amount of credits. On some gaming devices 10 a “Max Bet” game actuating button 33 may be included that places the maximum credit wager on a game and initiates the game. The player interface panel 30 may further include a bill acceptor 37 and a ticket printer 38. The bill acceptor 37 may accept and validate paper money or previously printed tickets with a credit balance. The ticket printer 38 may print out tickets reflecting the balance of the credits that remain on the gaming device 10 when a player cashes out by pressing one of the game buttons 32 programmed to cause a ‘cashout’. These tickets may be inserted into other gaming machines or redeemed at a cashier station or kiosk for cash.
The gaming device 10 may also include one or more speakers 26 to transmit auditory information or sounds to the player. The auditory information may include specific sounds associated with particular events that occur during game play on the gaming device 10. For example, a particularly festive sound may be played during a large win or when a bonus is triggered. The speakers 26 may also transmit “attract” sounds to entice nearby players when the game is not currently being played.
The gaming device 10 may further include a secondary display 25. This secondary display 25 may be a vacuum fluorescent display (VFD), a liquid crystal display (LCD), a cathode ray tube (CRT), a plasma screen, or the like. The secondary display 25 may show any combination of primary game information and ancillary information to the player. For example, the secondary display 25 may show player tracking information, secondary bonus information, advertisements, or player selectable game options.
The gaming device 10 may include a separate information window (not shown) dedicated to supplying any combination of information related to primary game play, secondary bonus information, player tracking information, secondary bonus information, advertisements or player selectable game options. This window may be fixed in size and location or may have its size and location vary temporally as communication needs change. One example of such a resizable window is International Game Technology's “service window”. Another example is Las Vegas Gaming Incorporated's retrofit technology which allows information to be placed over areas of the game or the secondary display screen at various times and in various situations.
The gaming device 10 includes a microprocessor 40 that controls operation of the gaming device 10. If the gaming device 10 is a standalone gaming device, the microprocessor 40 may control virtually all of the operations of the gaming devices and attached equipment, such as operating game logic stored in memory (not shown) as firmware, controlling the display 20 to represent the outcome of a game, communicating with the other peripheral devices (such as the bill acceptor 37), and orchestrating the lighting and sound emanating from the gaming device 10. In other embodiments where the gaming device 10 is coupled to a network 50, as described below, the microprocessor 40 may have different tasks depending on the setup and function of the gaming device. For example, the microprocessor 40 may be responsible for running the base game of the gaming device and executing instructions received over the network 50 from a bonus server or player tracking server. In a server-based gaming setup, the microprocessor 40 may act as a terminal to execute instructions from a remote server that is running game play on the gaming device.
The microprocessor 40 may be coupled to a machine communication interface (MCI) 42 that connects the gaming device 10 to a gaming network 50. The MCI 42 may be coupled to the microprocessor 40 through a serial connection, a parallel connection, an optical connection, or in some cases a wireless connection. The gaming device 10 may include memory 41 (MEM), such as a random access memory (RAM), coupled to the microprocessor 40 and which can be used to store gaming information, such as storing total coin-in statistics about a present or past gaming session, which can be communicated to a remote server or database through the MCI 42. The MCI 42 may also facilitate communication between the network 50 and the secondary display 25 or a player tracking unit 45 housed in the gaming cabinet 15.
The player tracking unit 45 may include an identification device 46 and one or more buttons 47 associated with the player tracking unit 45. The identification device 46 serves to identify a player, by, for example, reading a player-tracking device, such as a player tracking card that is issued by the casino to individual players who choose to have such a card. The identification device 46 may instead, or additionally, identify players through other methods. Player tracking systems using player tracking cards and card readers 46 are known in the art. Briefly summarizing such a system, a player registers with the casino prior to commencing gaming. The casino issues a unique player-tracking card to the player and opens a corresponding player account that is stored on a server or host computer, described below with reference to
To induce the player to use the card and be an identified player, the casino may award each player points proportional to the money or credits wagered by the player. Players typically accrue points at a rate related to the amount wagered, although other factors may cause the casino to award the player various amounts. The points may be displayed on the secondary display 25 or using other methods. In conventional player tracking systems, the player may take his or her card to a special desk in the casino where a casino employee scans the card to determine how many accrued points are in the player's account. The player may redeem points for selected merchandise, meals in casino restaurants, or the like, which each have assigned point values. In some player tracking systems, the player may use the secondary display 25 to access their player tracking account, such as to check a total number of points, redeem points for various services, make changes to their account, or download promotional credits to the gaming device 10. In other embodiments, the identification device 46 may read other identifying cards (such as driver licenses, credit cards, etc.) to identify a player and match them to a corresponding player tracking account. Although
During typical play on a gaming device 10, a player plays a game by placing a wager and then initiating a gaming session. The player may initially insert monetary bills or previously printed tickets with a credit value into the bill acceptor 37. The player may also put coins into a coin acceptor (not shown) or a credit, debit or casino account card into a card reader/authorizer (not shown). In other embodiments, stored player points or special ‘bonus points’ awarded to the player or accumulated and/or stored in a player account may be able to be substituted at or transferred to the gaming device 10 for credits or other value. For example, a player may convert stored loyalty points to credits or transfer funds from his bank account, credit card, casino account or other source of funding. The selected source of funding may be selected by the player at time of transfer, determined by the casino at the time of transfer or occur automatically according to a predefined selection process. One of skill in the art will readily see that this invention is useful with all gambling devices, regardless of the manner in which wager value-input is accomplished.
The credit meter 27 displays the numeric credit value of the money or other value inserted, transferred, or stored dependent on the denomination of the gaming device 10. That is, if the gaming device 10 is a nickel slot machine and a $20 bill inserted into the bill acceptor 37, the credit meter will reflect 400 credits or one credit for each nickel of the inserted twenty dollars. For gaming devices 10 that support multiple denominations, the credit meter 27 will reflect the amount of credits relative to the denomination selected. Thus, in the above example, if a penny denomination is selected after the $20 is inserted the credit meter will change from 400 credits to 2000 credits.
A wager may be placed by pushing one or more of the game buttons 32, which may be reflected on the bet meter 28. That is, the player can generally depress a “bet one” button (one of the buttons on the player interface panel 30, such as 32), which transfers one credit from the credit meter 27 to the bet meter 28. Each time the button 32 is depressed an additional single credit transfers to the bet meter 28 up to a maximum bet that can be placed on a single play of the electronic gaming device 10. The gaming session may be initiated by pulling the gaming handle 12 or depressing the spin button 33. On some gaming devices 10, a “max bet” button (another one of the buttons 32 on the player interface panel 30) may be depressed to wager the maximum number of credits supported by the gaming device 10 and initiate a gaming session.
If the gaming session does not result in any winning combination, the process of placing a wager may be repeated by the player. Alternatively, the player may cash out any remaining credits on the credit meter 27 by depressing the “cash-out” button (another button 32 on the player interface panel 30), which causes the credits on the credit meter 27 to be paid out in the form of a ticket through the ticket printer 38, or may be paid out in the form of returning coins from a coin hopper (not shown) to a coin return tray.
If instead a winning combination (win) appears on the display 20, the award corresponding to the winning combination is immediately applied to the credit meter 27. For example, if the gaming device 10 is a slot machine, a winning combination of symbols 23 may land on a played payline on reels 22. If any bonus games are initiated, the gaming device 10 may enter into a bonus mode or simply award the player with a bonus amount of credits that are applied to the credit meter 27.
Referring to
During game play, the spinning reels 22A may be controlled by stepper motors (not shown) under the direction of the microprocessor 40 (
A gaming session on a spinning reel slot machine 10A typically includes the player pressing the “bet-one” button (one of the game buttons 32A) to wager a desired number of credits followed by pulling the gaming handle 12 (
Referring to
Because the virtual spinning reels 22B, by virtue of being computer implemented, can have almost any number of stops on a reel strip, it is much easier to have a greater variety of displayed outcomes as compared to spinning-reel slot machines 10A (
With the possible increases in reel 22B numbers and configurations over the mechanical gaming device 10A, video gaming devices 10B often have multiple paylines 24 that may be played. By having more paylines 24 available to play, the player may be more likely to have a winning combination when the reels 22B stop and the gaming session ends. However, since the player typically must wager at least a minimum number of credits to enable each payline 24 to be eligible for winning, the overall odds of winning are not much different, if at all, than if the player is wagering only on a single payline. For example, in a five line game, the player may bet one credit per payline 24 and be eligible for winning symbol combinations that appear on any of the five played paylines 24. This gives a total of five credits wagered and five possible winning paylines 24. If, on the other hand, the player only wagers one credit on one payline 24, but plays five gaming sessions, the odds of winning would be identical as above: five credits wagered and five possible winning paylines 24.
Because the video display 20B can easily modify the image output by the video display 20B, bonuses, such as second screen bonuses are relatively easy to award on the video slot game 10B. That is, if a bonus is triggered during game play, the video display 20B may simply store the resulting screen shot in memory and display a bonus sequence on the video display 20B. After the bonus sequence is completed, the video display 20B may then retrieve the previous screen shot and information from memory, and re-display that image.
Also, as mentioned above, the video display 20B may allow various other game information 21B to be displayed. For example, as shown in
Even with the improved flexibility afforded by the video display 20B, several physical buttons 32B and 33B are usually provided on video slot machines 10B. These buttons may include game buttons 32B that allow a player to choose the number of paylines 24 he or she would like to play and the number of credits wagered on each payline 24. In addition, a max bet button (one of the game buttons 32B) allows a player to place a maximum credit wager on the maximum number of available paylines 24 and initiate a gaming session. A repeat bet or spin button 33B may also be used to initiate each gaming session when the max bet button is not used.
Referring to
The player selectable soft buttons 29C appearing on the screen respectively correspond to each card on the video display 20C. These soft buttons 29C allow players to select specific cards on the video display 20C such that the card corresponding to the selected soft button is “held” before the draw. Typically, video poker machines 10C also include physical game buttons 32C that correspond to the cards in the hand and may be selected to hold a corresponding card. A deal/draw button 33C may also be included to initiate a gaming session after credits have been wagered (with a bet button 32C, for example) and to draw any cards not held after the first hand is displayed.
Although examples of a spinning reel slot machine 10A, a video slot machine 10B, and a video poker machine 10C have been illustrated in
Gaming devices 71 coupled over an optical line 64 may be remote gaming devices in a different location or casino. The optical line 64 may be coupled to the gaming network 50 through an electronic to optical signal converter 63 and may be coupled to the gaming devices 71 through an optical to electronic signal converter 65. The banks of gaming devices 70 coupled to the network 50 may be coupled through a bank controller 60 for compatibility purposes, for local organization and control, or for signal buffering purposes. The network 50 may include serial or parallel signal transmission lines and carry data in accordance with data transfer protocols such as Ethernet transmission lines, Rs-232 lines, firewire lines, USB lines, or other communication protocols. Although not shown in
As mentioned above, each gaming device 70-75 may have an individual processor 40 (
Thus, in some embodiments, the network 50, server 80, and database 90 may be dedicated to communications regarding specific game or tournament play. In other embodiments, however, the network 50, server 80, and database 90 may be part of a player tracking network. For player tracking capabilities, when a player inserts a player tracking card in the card reader 46 (
The various systems described with reference to
Turning now to
As an alternative, the present invention may be readily implemented with all of the components in system 92 being located at casino 94, as shown in
Considering first offsite location 96, a Database Server 98 collects data from the casino and stores it in a manner that will be later described in connection with the operation of system 92. An Application Server 100 provides support for software applications, to be shortly described, that are installed on various computing devices included in system 92. The application server provides the software applications with services such as security, data services, transaction support, and load balancing.
In the present implementation, many communications between offsite location 96 and casino 94 are conducted through the Internet 62 via a reliable, high-speed connection. In the casino, a wireless router 61 provides a wireless network for various computing devices as will be shortly described. In the present implementation, the wireless network is implemented using the IEEE 802.11 standard.
Included on the wireless network implemented via router 61 are mobile computing devices, in the present implementation tablet computers 102, 104, made by Apple Inc. and sold under the iPad™ brand. There may be many other such iPad computers that are omitted here to simplify the drawing. The iPad computers may be used, as will be described, to monitor the status of service calls on the casino floor, either within an area or department or casino wide. These are typically carried by a casino agent who has responsibility for supervising others in the process of making such service calls, but the iPad computer also receives notifications for service calls that may require a supervisor, i.e., the carrier of the iPad computer. The types of notifications and responses that may be received and made, respectively, on the iPad computer is described in more detail in connection with the operation of system 92.
In addition to iPad computers 102, 104, a plurality of mobile wireless computing devices 106, 108, 110, 112 are also connected to the network implemented via wireless router 61. In the present implementation computing devices 106, 108, 110, 112, are also made by Apple Inc. and sold under the iPod Touch™ brand. There may be many other such iPod touch devices that are omitted here to simplify the drawing. The iPod touch devices are typically carried by a casino employee, such as a floor attendant or slot technician, to communicate regarding service calls on the casino floor, either within an area or department or both. The types of notifications and responses that may be received and made, respectively, on the iPod touch devices is also described in more detail in connection with the operation of system 92.
A Server 114, also located at casino 94 in the present implementation, is connected to the Internet 62 and to network 50, which is shown in
In an alternative embodiment, dedicated devices are installed within each gaming machine to communicate with the machine's data ports, or the lamp illumination signal, and transfer that information, through wired or wireless networks, to a central event list maintained on the network, such as database server 98.
In still another embodiment, casino agents manually enter information about incident occurrence that is stored on the network, e.g., on database server 98. This information may be gathered from the machine signal light, from manual inspection of the machine, or both.
Regardless of the embodiment, all detectable events on network 50 may be collected and used to generate a call as described herein. For example, some player tracking systems permit player help requests to which responses could be made according to the present system. Many gaming machines include Help, Change, and Drink Request buttons, which may also generate a detected event.
Turning now to
Another table, not shown herein, is stored on database server 98 along with Table 1. The additional table includes a list of each of the floor areas, A1, A2, A3, A4, B1, . . . etc. Associated with each floor area is a unique machine number that identifies each machine within each area. As will be seen, this enables system 92 to dispatch assistance to the location and machine that requires service.
Table 2, shown below shows adjoining areas that are associated with each of sections, like section A, which includes A1, A2, A3, and A4. Each of the other sections is listed with its respective associated adjoining areas. As will be seen, when a service provider is not available or one is but requires assistance in his or her section, service providers may be drawn from adjoining areas. This table defines the areas from which sections may draw support if needed. As with other data stored on the network implemented via router 61, it may be entered via an iPad computer by a user who has sufficient permissions to do so.
The following Table 3 is a list of job positions and associated departments. Persons holding these jobs are qualified and eligible to respond to defined service requests, as will be further described. This table is also entered in database 98 and may be entered and altered in the same fashion as described above.
The casino may set goal times within which it is desirable to resolve different kinds of service needs. Table 4 depicts some exemplary goal times, which may be varied by casino personnel, via one of the iPad computers, with sufficient permissions to do so. Also included is a commute goal time, which is the time necessary for a service provider to travel to the gaming machine in need of service after accepting a call. This too may be set or changed by the casino.
Some types of responses require further categorization of employees who may respond, even for the same type of event. For example, some jackpots are so large that the machine does not pay them out. Different casinos may have different policies regarding what jackpot amounts must be hand paid, how many people need to be present, and the job position(s) of the person or persons who are required to be present, depending on the jackpot size. The following Table 5 provides an example of one casino's requirements. The information in this table is also stored on database 98. As is known in the art when a call code for a jackpot appears on the event list, the amount of the jackpot and the machine number are both associated therewith. This call code is the fourth row in Table 1.
Additional consideration will now be given to the manner in which system 92 operates. When an employee arrives for a shift, he or she logs in. As mentioned above, supervisors and managers typically use an iPad computer, which provides additional functionality over the iPod touch, device which the front line employees, such as floor attendant, slot technician, or beverage server typically use. Any employee, however, could use either device.
When a user arrives for work and logs in, he or she is first brought to an assignment screen where they indicate whether they are reporting to work under the primary or secondary positions. Each employee has a record that may entered via a supervisor iPad computer as described above. Employees are often trained and capable of performing more than one role. For example, a Floor Attendant might also be qualified to serve as a Slot Supervisor. In any event, employees whose record indicates both a primary and secondary position are required to indicate in which of those capacities they are reporting at the start of a shift. An employee with only one role is automatically assigned to that role.
Next, the employee indicates in which section, e.g., A, B, C. etc. of the casino floor they are assigned to work. Their screen then shows their position, the section, and the supervisor to whom they will be reporting for the shift. Turning now to
Because the number of workers logged in is known to the system, the system can review historical data and make determinations about the number of employees and their qualifications that should be logged in and on duty for a particular shift. For example, the numbers and qualifications can vary significantly from a Sunday morning, to Monday evening, to Saturday night, etc. As a result, the system can automatically create and publish via the Internet or otherwise, work schedules, showing total employees, by area, by job type, by supervisor, etc. And it can notify each individual about the times for which they have been scheduled to work. Of course, each employee will be associated with historical data showing hours and times worked as well as shifts or times that the employee is not eligible to work. As a result, the system will not overschedule or schedule during times when the employee has not agreed to work.
There are 5 call status screens that may be presented to a user who is logged in on one of the iPod touch device. First, is a No Call screen (not shown). This screen indicates that there are no calls waiting, and presents a “Give me a Task” button to the user. Tasks are different types of service, such as routine maintenance, that can be performed at any time. The manner of accepting, performing and completing a Task is described in more detail below.
When a call is received by a person who is logged in to his or her iPod touch device, the Pending Call screen is presented as shown in
First, it will be recalled that a table showing the area (as shown in
If a person qualified to take the task is logged in, assigned to the section in question, and not on break, that call is automatically directed via the wireless network to his or her iPod touch device thus generating the Pending Call screen in
Once that person receives the audible notification and is presented with the
Also appearing on the screen is a description of the service that will be provided, in this case hand pay of a jackpot in the amount of $2000, shown in field 128. In this case, because multiple employees have been notified about this service requirement, the names of the other employees who have accepted the call appear in field 130.
Although not visible in the drawings, a bar 132 on which break touch-screen slider button 120 is located, can appear as one of three colors: green, yellow, or red, which provides an indication of the call level. The colors are based on a calculation made by system 92. Every 15 minutes the system looks for the number of dispatched users, i.e., those who have accepted a call. It will then compare the total number of users logged in, for each department shown in
Doing so informs the employee of the speed at which commuting and service work should be conducted and the level of attention the employee can give to a player who may be at the machine where service is requested. If the floor is relatively slow, it is desirable for the employee to talk with the player and interact as much as the player might want. If more busy, such interaction needs to be more limited and if in the red zone, such interaction might need to be minimal to keep up with the service calls.
When button 122 is moved up and Accept button 125 is depressed, the next screen appears as shown in
Alternatively, at any time prior to pressing Arrive button 134, the employee can move switch 122 down and press Quit button 136. This removes the employee from the job, and the system initiates the process for locating and dispatching another employee as described above.
But if the employee presses Arrive button 134, the screen shown in
But if Escalate button 140 is depressed, the screen in
Once the employee selects one or more of the service providers in
Considering first the 911 screen in
If in
Of course, there are times in a casino that are slow or where there may be more employees than required to handle calls as described above. During these times, an employee who does not have any pending calls, as in
Tasks can be scheduled automatically by examining the frequency with which calls are generated on specific machines or for specific issues on a machine. Because the system stores and analyzes data from all calls and other communications, it can be reviewed to spot a particular issues. For example, if bills jam frequently on the same machine, that bill acceptor can automatically be scheduled for preventative maintenance to determine if it needs servicing beyond clearing the jam.
Turning now to
A navigation bar 164 appears along the lower portion of screen 162. The icons in the bar permit the user to select different screens as labeled beneath each icon. A rectangle 165 indicates that the Dashboard screen is currently selected.
As with the iPod touches, a bar 166 changes between green, yellow, and red to indicate how busy the floor is by department. In other words, bar 166 reflects how busy the user's area of responsibility is. If logged in as a floor attendant, the bar will reflect the volume in the slot department; if logged in as a beverage, server, it will reflect the volume there.
A plurality of gages, like gages 168, 170, 172 are each color coded green, yellow, and red. For example, gage 168 has a green arc 174, a yellow arc 176, and a red arc 178. Gage 168 indicates the average commute time to a call, and gage 172 indicates the average completion time for a call. The gages in between gages 168, 172 indicate the average time to complete each of the 5 categories of calls in Table 1. The casino can set goal completion times within the system, e.g., jackpots in 15 minutes. If the average is, e.g., 11 minutes, the needle is in the green zone; if 12-15 minutes, in the yellow zone; and above 15 minutes in the red zone. At a glance, the supervisor can tell how well the staff is responding to calls by type relative to the casino goals.
An alerts section 180 displays notices including supervised staff who have exceeded break times, calls dispatched where no one has accepted the call after a predefined time, and changes in a staff status screen 182.
Staff status screen 182 can show only the supervisor's staff, in response to touching the “My Staff” tab on screen 182 or all staff logged in at the casino, in response to touching the “Active Users” tab on screen 182. The supervisor can touch a name on the “My Staff” page, which causes a dialog box to appear that permits the user to edit the employee profile, send a text message to the employee, or force a logout (which would be desired if the employee lost his or her iPod touch device). When an employee name is selected under the “Active Users” tab, the user of screen 162 may send text messages to that employee.
In
In
In
Next down in the left hand column is “Tasks.” The supervisor may accept tasks that are appropriate for his or her level and deal with them in the same manner as described above for tasks on the iPod touch device. The Give Me a Task panel is not selected in
The next section in the left hand column displays “All Calls.” In this section, a user can view all calls within the system in one of these categories: Unserviced Calls, All Calls, and Calls by Type. In
In
In
In
Turning now to
In addition to the structure described in
Games may be implemented on any of these devices via a dedicated application. Alternatively, game software may be provided on server 100, which executes and runs the software thereon. In such cases, the software generates a game interface on the computing devices with which a player interacts, typically via a web browser. Wagering may be effected via deposit accounts opened using the computing device and interacting with application server 100.
Obviously many of the events in Table 1 would not require or trigger a response from a casino agent for computing devices 190, 129, 194. But some kinds of gaming activity on these gaming devices could trigger a response from the operator of system 188. For example, deviations in wagering patterns on the gaming device might trigger a text message, automated or otherwise, from system 188 that could appear in a dialog box on the computing device or be provided to the player's cell phone if that number is known.
The duration of play or deviations from duration of play could trigger such a communication. Awards won or a sequence of losses could be used to initiate a message. Essentially any event or series of events on computing devices 190, 129, 194 that can be tracked by system 188 could be used to trigger messages from the operator of system 188.
As another alternative embodiment, system 188 could be implemented without that portion in casino 94, i.e., it could be operating only computing devices connected via Internet 62 from wherever they might be.
Another aspect that can be incorporated into either system 92 or system 188 relates to assimilating personal data for the players. As mentioned above, network 50 may include a player tracking system. Such systems often maintain a modest set of demographic information about each player. This information may be used directly to personalize a message (for example, to identify the player's name for use in conversation during the event resolution). Player tracking information may also contain a photo of the player, which is useful for identification. When an identified player is playing at a machine that triggers a call as a result of an event, such as one of those in Table 1 or a beverage order, any such demographic data may be routed via the system to the responder's iPod computer or iTouch device, thus enabling the responder to quickly identify the patron who may be affected by the event that produced the call and to address him or her by name.
In addition, the player can be directly notified that help is on the way when he or she has summoned assistance or when a call is generated as a result of an issue with the player's gaming device. This message could be sent immediately after a problem is detected using information in the player's player-tracking record (or another source), such as a mobile phone number, for text or voice communication, instant message, an email address, an address on a social media network, etc. This communication might read or be heard as follows: “Hi Diane. We've detected a bill jam on your game and apologize for the interruption in your play. A slot technician, Dan Stevens, has been dispatched to resolve the problem and should arrive within the next 3 minutes.” As a result, the dispatched employee may know the name of the patron, among other information, and the patron knows the name of the person who is on their way to help or otherwise provide service.
The message could be displayed on the player tracking screen, on the game screen, or both. This could be instead of or in addition to communication to the player's cell phone or other mobile device.
The demographic information is also useful as a key with which to obtain additional information about the player. For example, if the player's address is within her player tracking record, that address could be compared to property records to determine whether the property is owned or rented and its approximate value, which is then useful in gauging the player's potential worth as a customer. By accessing other external databases, such as those for credit cards, shopping habits, magazine subscriptions, automobile records, etc., a player's likely personality, affinities, likes and dislikes can be discerned.
This information may be gathered during the response to the call or when the player first signs up for a player tracking membership. In a preferred embodiment, the information is gathered at time of signup and updated regularly thereafter.
The player tracking system also holds records on the player's historical activities within the casino, including game preferences, wagering habits, whether the player is winning or losing, how long they have been visiting the casino, how long they have been at the casino on this visit, and a wide range of other data.
In another embodiment, the player is asked to respond to a survey indicating the level of satisfaction with respect to how the call was resolved. This could be as basic as asking a short yes/no question inquiring whether they would want the responder to provide the same service another time if it was again required. The survey could be delivered via the player tracking system, the player's cell phone—via text, email, or call—or manually.
In a preferred embodiment, an additional database is created to store every event involving each player, how the event was resolved, who the agents were that handled the event and the survey results of the player after each event to determine satisfaction.
It is important to strive to provide every customer with a satisfying experience but casino resources are finite and, in busy times, it is impossible to provide the maximum level of service to all consumers.
When more events occur than a casino's resources can handle, it is commercially important to satisfy the most important customers first. Players who frequently visit the casino and wager in high volumes, of course, are important. These players are identifiable through the player tracking database.
Also important are consumers who do not currently wager at high volume but who have the capacity to do so in the future. The likelihood of a given consumer to become a valuable player is predictable to an important degree. Predictions of potential worth may be made by agent evaluations, recommendations by other players or by application or commitment of the consumer.
Another important means of predicting importance is by comparing personal attributes of the unknown consumer against attributes of known valuable players. For example, a consumer without a history of wagering at a casino provides personal data showing he is a 48-year-old male living at zip code 89135.
Through the personal data assimilation described earlier, it is learned the consumer also belongs to a private country club, drives a luxury car and is a frequent flier. From its database on known players, the casino determines many high-value players share these characteristics. Therefore, this new player is accorded a high level of importance.
Alternatively, any player newly signed to the player's club may be considered of extra importance, regardless of whether any information about him or her is known. Studies have shown that a player's initial experience in a casino will weigh heavily on whether that player returns and the extent to which the player gambles there. As a result, any new player may be granted a higher priority.
Furthermore, even a player that is not enrolled in a player tracking system may warrant higher priority attention. For example, an uncarded player who has been wagering $4 per game for 4 hours would warrant a higher level of attention than a player who had been playing penny games for 10 minutes. The system can note the frequency of play and amounts of wagers and infer that the same, albeit unidentified, player is playing a game.
Another embodiment of this invention utilizes standard geo-location services, such as GPS, cellular triangulation, and WiFi access point mapping to determine location of casino agents. Interior location services based upon WiFi and other methods are available from a variety of vendors, such as Google's “Google Maps 6.0,” Apple's mobile location service, or products from Meridian, http://www.meridianapps.com/, of Portland Oreg. Any of these could be used to locate casino agents. In such a case, the section associations shown in Table 2 and described above may not be necessary, i.e., dispatch of employees is based on location (and of course qualification to do the job) as determined by the geo-location service instead of Table 2.
While agent selection based upon the agent's technical qualifications and physical location is technically efficient, it does not significantly improve the likelihood of consumer satisfaction or even the long-term efficiency of casino operations. As discussed above, when an agent arrives to work, she logs into the system through her iPod device, iPad computer or other equivalent communication device, which tells the system that she is available to handle events. At the end of the shift, the agent logs off, telling the system she is no longer available.
From login until logoff, when not on break, the system monitors and records the Agent's movements and actions. Many casinos are so large, multiple supervisors control a single agent, each overseeing an area of the casino. In such cases, the system is configured with each supervisor's identity, areas of responsibility and agents assigned to the supervisor.
When the agent logs in, the communicator informs her of which supervisor she reports to, her area of assignment and other details the supervisor wishes her to know. As also discussed above, she is also given an indication of how busy the casino is at any given time. All such information is constantly updated throughout the shift.
At this point, the system has a list of events within the casino that require service and a list of all available agents and their qualifications. It also possesses knowledge of priorities and the area and tasks to which each agent is assigned.
When a new event occurs, the system prioritizes it based upon player identity and how busy agents currently are at serving other events. The first priority is consumer satisfaction. If there are multiple agents qualified to handle the event and the player has had favorable interactions with one of the available agents in the past, that agent is assigned the task. The system includes a database of all casino employees, their qualifications, training, and history of performance in resolving prior events. This database can be consulted to determine priority by seeing how well the employee has resolved such calls in general, whether the employee has resolved a call for this player in the past, and, if so, how well he or she resolved the call and what, if any, survey response was made.
The communication device informs the agent of where the problem is and, optionally, the player's identity. The agent may also be reminded of the date and circumstances of her last interaction with the player and be given information about that player's preferences and desires.
If the player's importance is very high, an agent favored by the player may be called off of a current assignment to serve the new event. In that case, the system will dispatch a substitute agent to finish the task the diverted agent was working on.
If the event involves a lower-priority player, or if the player has no prior relationship with another agent, and if the casino is not busy with too many other events, the new event may be assigned to the agent with the least experience at that particular kind of event, in order to improve the agent's competence.
For example, Mary is a new agent, with little experience clearing bill acceptor jams. A bill jam event comes in from the EGM at location B-47, which is in Mary's area of responsibility. The system determines the player at that EGM has no need or desire for service from a specific agent and so assigns the event to Mary, so she can become more proficient. If the supervisor desires and personnel are available, an additional agent, or supervisor, might be dispatched to the same location in order to provide additional training for Mary or to evaluate her performance.
If the casino is busy, or the player is sensitive to delays but has no preferred agent, the task is assigned to the most experienced available agent.
Every agent's activities are monitored, recorded and evaluated. For example, Tim is a moderately experienced agent assigned to a technical malfunction event that is historically tricky to remedy. The customer at the involved EGM is a very high-value player, who is known to be demanding.
The system initiates a timer when the event occurs, as described above. In this example, presume the system is configured to allow a maximum of five minutes to resolve the problem within the player's expectations. The event is assigned to Tim, and accepted by him 30 seconds after event occurrence. Tim's supervisor is informed that a critical event service is in progress. From Tim's current location, it should take a maximum of two minutes to reach the location.
If Tim does not reach the location within two minutes, his supervisor is alerted, so that another agent may be sent to help. In this case though, Tim does arrive within the allowed time. The system knows that Tim has arrived when either (a) Tim so informs system through his communication device and/or (b) the door to the game is opened (most systems report EGM door openings and the door must be opened to fix the problem).
Tim should be able to fix the problem within three minutes after opening the door. If Tim does not declare the job finished within the allotted time, and/or the door is not properly closed within that time, the supervisor is again so informed.
In this way, the system evaluates agent performance in comparison to player worth, demands, and expectations in light of how busy the casino is at that time. The system works to preemptively inform supervisors of problems so additional resources can be dispatched. Alternatively, the system can dispatch additional agents automatically, instead of simply informing the supervisor.
These are simply two examples of event situations and not an exhaustive description of the system's full capabilities. One of skill in the art of casino management will recognize there are many ways to improve customer satisfaction within a finite budget by comparing agent qualifications, experience and availability, against customer importance, personality, history, and desires, while factoring in the nature of the event and the business of the casino to the time of the new event.
While the above examples describe the dispatch of a single agent to handle an event, it is anticipated that multiple agents may be dispatched simultaneously while other services are also provided. For example, when a player wins a jackpot of $1,200 or more the player is required to complete tax forms before payment is issued. For security reasons, witnesses are required to verify the player was given the money, security is needed to transport the money safely cross the casino floor, and paperwork is required for the cage to provide the cash.
The system can simultaneously, or in staged timing, issue notifications to the cage that cash is required, alert security to transport the funds, cause a casino host to greet the player, explain the process and get tax form signatures, and send witnesses to verify the transaction.
As set forth in applicant's co-pending '355 application, any of the messages described herein may be delivered by a virtual persona, as can any other communication that may occur on this system. The virtual persona messages may be via phone calls, text messages, e-mails, dialog boxes generated on screens, or any via any other telecommunications method. Further, such messages may be automatically generated or otherwise.
Illustrated in
Each call listed in panel 204 includes at least one icon of a human figure, each of which correspond to a user who has been offered or accepted a call generated by the system—or to a role in the system for which there is currently no user. The color of each icon indicates whether the user has completed the call; whether the user has been offered or accepted the call, or has arrived at the location specified in the call; and whether there is no user associated with the role needed on the call.
The supervisor device 200 can view any category of the calls by touching the name in panel 202. For example, All calls is selected in panel 202 of
As can be seen in
Before describing further functionality, it should be noted that the drawings are populated with simulated data, including calls, machine locations, users, comments, etc., which depict how the system actually works on a gaming floor. There may be inconsistencies in the data from one drawing to another. Regardless, the drawings illustrate the views, panels, buttons, various user inputs, and device responses that produce the decreased call times, increased user satisfaction, report generation, and other benefits associated with these systems and methods.
Turning now to
In
The Assign User button might be used when a user of device 200 selects the Unserviced Calls in panel 202 and sees a particularly old unserviced call. Alternatively, the Assign User button may be used to assign a user to any active call, even if another user has accepted it. The Unserviced calls include a color-coded stripe, like stripes 212, 214 at the left side of each call in panel 204. Each color provides the supervisor device 200 with a quick indication of how long the call has been open. For example, a green stripe would indicate a recently opened call, e.g., less than 3 minutes, a yellow stripe 3-5 minutes, and a red stripe, over 6 minutes. For unserviced calls, yellow and red stripes might inform the user of device 200 that the call needs to be assigned using the Assign User button as described. Different types of calls might require different times for their respective stripe colors to appear. And these could be different at different casinos, depending upon the targets for responding to calls.
In each call detail of panel 206, which can be better seen in
If the user of device 200 presses the defer button, the call is offered to another person on his or her device, panel 215 disappears, and the screen reverts back to its condition before panel 215 appeared. If the Accept button is depressed, panel 215 also disappears, and the call becomes the user's call on device 200. Because device 200 lists many calls in panel 204, including the call to which the user is assigned, an exclamation point appears over the Calls button in the navigation bar to remind the user that he or she is on a call that has been offered, accepted, or not yet complete.
Each employee has a Machine Access Card that must be inserted into a slot in a card reader associated with each machine to obtain access to the machine. This is the same type of card and is inserted into the same slot as a player-tracking card. When the employee touches the Link Employee Card item on menu 216, he or she can insert the card into any card reader. The system then presents on a pop-up screen (not shown) the machine number associated with the card reader into which the card was inserted. When the employee touches the machine number the Machine Access Card and employee user profile are linked in the system. As will be seen, this facilitates automatic creation of a machine entry log and enables rapid supervisor response to an illegal entry.
The next menu item is Create Self Speed Call, which produces a scrollable pop-up panel 218 as shown in
Panel 218 permits the user of device 200 to manually generate a call that he or she is assigned to. Various reasons for such a call appear on panel 218 but different reasons could be used, or reasons that are entered manually via a keypad. This is the same panel that appears if the Create a New Call button is pressed on panel 208 in
In
As can be seen in
In
In
After the screen in
Menu 222 includes two portions, an upper Alerts panel 226 and a lower Radio panel 228. Radio panel may operate independently of menu 222. When panels 202, 204, 206 are in the position shown in
The controls in Radio panel 228 facilitate voice communication among all the current system users via their respective iPad or iPod touch devices. The Radio panel includes a Scan Mode switch 230, which is toggled on and off when it is touched. When on, a scrollable list of channels may be viewed, only three of which, Security, Beverage, and Marketing are visible in
When a user of device 200 wishes to send a message over their current channel, he or she presses the Start Recording switch. After a short audible signal, the device begins recording a message spoken by the user, which can be a maximum of 12 seconds. The message is sent in one of two ways. First, the user can hit the send button as soon as the message is complete. Second, if the user has not hit the send button within 12 seconds after the message begins recording, the message is automatically sent. In addition, the message may be canceled at any time before sending by hitting the Cancel button. A recording bar 232 provides a visible indication of the 12-second maximum message recording time. It starts filling from left to right beginning with the start of message recording and ending at the end on the right just as the 12-second recording time elapses. The bar is part way between the beginning and ending of a message that is being recorded in
Each of the devices includes audio compression software that is helpful in two respects. First, the audio signal is digitized and compressed, thus reducing system bandwidth on the wireless network. Second, noise suppression is applied to remove the ambient casino noise that may be picked up by the device microphone when a voice message is recorded. Because the calls are recorded, they can be stored, either on the device or retrieved from the server, and then replayed on the device.
The microphone to used to record a user's verbal message is that built in to the device. And the speaker for replaying may be that built into the device—or the device may be paired with a Bluetooth earpiece and microphone, to enable hands-free use of the device.
When a message is sent, it goes first to the system server, which determines the current users on the channel to which the message should be sent. The server then sends the messages to all users on that channel. Next, an audible alert occurs at each device that is set to the channel of the message sender. Thereafter, the message plays. But if another message is currently being transmitted to or played on the channel, an audible alert informs the sender that the message was not sent and that he or she must create and send the message again. Alternatively, because the message is recorded at the device, it may be stored, either at the device or on the server, and thereafter sent in response to the user again touching the Send button. In a still further version, the server can stack all incoming messages in the order received and send them in sequence. In the present embodiment, each channel's message traffic is independent of the others. Put differently, messages may be sent and received on each channel as described without regard to traffic on other channels.
In
Concluding now the description of the Radio feature,
One of the channels is the Emergency channel. Unlike the other channels, when a user broadcasts on this channel, all users who are logged in receive the message. The Auxiliary channel is available by subscription only. Users who are not subscribed on the system do not see the Auxiliary channel on the list of channels presented on their device screen. This provides a private channel for authorized users, typically higher-level supervisors, on which to communicate.
Implementing the radio feature in this manner provides several advantages. First, the messages may be stored, either on the devices or on the server, for later replay—by either the users or a supervisor of a user. In addition, because the messages are stored, a supervisor can create a message to one employee or to a group of employees in advance of its delivery. For example, a supervisor can create a message at the evening before a shift begins, and store it—either on the server or on is or her device. When the employee or employees to whom the message is directed logs in the next day, the radio message is delivered and heard by the employee.
Before moving on, a brief description will be provided of the functions served by the other icons on the navigation bar of device 234. The status screen (not shown) presents information to the user of device 234 indicating the section and role that is currently associated with the user, typically those selected when the user logged in. In addition, there is a break switch that presents the same 15-minute/30-minute option described above. This switch starts a break clock running for the user of the device. Finally, there is a logout button and an edit button, the latter permitting the device user to change his or her section or role. The Calls icon presents the screen on which service calls are offered to the user and which also indicates the current status of a call the user has been offered or is on. This feature will be described more fully with reference to additional drawings that detail call functionality. The Text icon presents a screen (not shown for this embodiment) of text conversations and is the screen from which a user sends and receives texts and reviews stored texts, essentially as previously described. Finally, the About icon can be used to present a screen (not shown) that presents system or device information, such as the version of the software operating the device, the site where the device is authorized to operate, etc. There are also buttons to Re-Link the Employee Card, in case the linking process described above needs to be repeated and a button to change the employee's PIN, which is used to log on.
In
These averages may be used to set a goal time. For example a current goal time for an event could be set to be 80% of the most recently calculated average for that event. Each event displayed in
The average event time can also be used to expand the pool of responders. As will be recalled, if a primary responder does not accept a call within a first predefined time, the pool of responders is expanded to include secondary responders. If there is no response from the expanded pool within a second predefined time, the pool can again be expanded to include tertiary responders, and so forth. The time elapsed from the start of the event (and without acceptance) until the call is offered to a secondary responder could be 80% of goal time, and if the call is still not accepted, by one of the primary or secondary responders, within 100% of goal time, the call is now also offered to the tertiary responders.
These averages and goal times may also be used for the color coding, previously described, which visually indicates whether a call is currently being handled within time (green), approaching its goal time (yellow), or overtime (red).
In the view of
In
In
When a maximum call time is exceeded, the alert appears in the Alerts list, and the supervisor may choose to act by texting or otherwise contacting the responder, by assigning another responder (as described above), or by taking some other action. The supervisor may also choose to assign or shift users to an unsupervised section. And of course an illegal machine entry requires immediate attention. Machine entry is addressed in detail later on. Briefly, an illegal machine entry alert is generated by the system when a machine door sensor, each of which is monitored on the network and by the system, indicates a door opened, and one of the following is true: a) no current user is linked to machine access card that is inserted into the card slot; b) there is no call at the machine; c) no entry reason was generated (by the system) or provided (by the responder); or d) the employee is on a call but at a different machine.
In
In
Although exemplary lists are not shown for either, icon 244 generates a scrollable early out list, i.e., those employees who would like to leave early, if possible, and icon 246 displays a scrollable list of all current users who are associated with more than one section on the gaming floor.
Next,
Conversely, looking now at
Note that in in
Next,
Turning now to
In
Turning now to
In
After the user arrives at the machine, he or she can either depress the Arrive button on the screen or insert his or her user card into the card reader associated with the machine. Either way notifies the system that the user is at the machine, after which the display of
Once the call is complete, whether the user elects to add a comment or not, the user withdraws his or her card from the card reader, and touches the Complete button. The screen thereafter presents the display shown in
Sometimes the door sensor on a gaming device has failed or otherwise does not provide a signal to the system to indicate that a door has been opened. As a result, the comment button does not appear on screen 260, even when the door is opened. If this happens on a call, such as a General Tilt, that requires a door open event, when the user touches the complete button in
Before recording this call in the MEAL log, the system first checks to confirm: a) the request from the user's device must give a call identifier, b) the call so identified must exist and be found by the system, c) the call is one that requires machine entry, and d) the call must be associated with a gaming machine that stored by the system.
The present implementation also permits a user to enter a machine and create a corresponding MEAL entry on his or her initiative. In other words, this can happen even when the system has not generated any call at all. To do so, the user touches the Create a Call button in
In
When the door is opened, the sensor causes the system to present the screen depicted in
Consideration will now be given to how a user is presented with a system-generated call that normally does not require entry into a machine, but during the course of the call, the door is opened. In
During the course of the call, the user determines that he or she must enter the machine. This may happen, for instance, when the customer asks the user to check the game history. When the door is opened, the sensor signals the system, which presents a scrollable menu as shown in
After the call is created, it proceeds as any other call. For the system to create the MEAL log entry, several conditions must be satisfied: a) the user must be carded in to the machine, b) there must be a call at the machine, c) the card in at the machine is associated with the user who accepted the call, and d) the user has selected a MEAL reason via their device.
There is also a call that can be created when, for whatever reason, the user's iOS device is not communicating with the server. Such a condition may occur when, e.g., the wireless network is down or the server is not functioning properly. It is of course desirable to continue service to machines and to log data regarding such service—especially machine entry events, which are closely monitored by casino operators and regulators.
When the connection to the server is restored, the entry is automatically transmitted to be stored as a system record. Once transmitted, the entry is first checked for validity. The location entered must correspond to a valid machine, the record for which is stored in the system. And the employee identified in the login name must exist and be in the Slots department.
In
Each of the types of MEAL entries discussed above include the following data: date, time, Reason for entry/Duties performed, Comments (if any), User's name, and Badge number. In addition, each entry is associated with data related to the machine that the entry documents. Information about each machine is stored on or accessible by the system and includes: Machine number, Serial number, Location, Program name, Program number, Certification number, Purchase date, On floor date, Off floor date, Sale date, and Model type. As a result, reports may be generated in a variety of ways to review information related to machine entries, e.g., by machine, by employee, by section, etc.
The system creates a potential MEAL record each time a call is dispatched because, as described above, a machine may be entered during any call—even one that was not initiated as a call that requires machine entry. The potential record, which includes the employee identification and call data is not stored in a MEAL entry unless and until either the sensor indicates an open door on the machine that is associated with the call (whether system or user initiated), or when the user responds with Yes when presented with a panel asking if the machine was opened, like that shown in
It can therefore be seen that this system constrains users by requiring MEAL entries under certain conditions, and by automatically collecting and entering the required information. Finishing now the MEAL description with reference to the flow charts in
Finally, one aspect of machine entry relates to system-defined illegal entries. If no user is linked to the server, either via employee card or by a successfully completed call creation or joined call, and a door opens, an illegal alert is generated on a supervisor's iOS device. If there is no call at the machine or if there is a call but no MEAL reason is provided and a door opens, an alert is also generated. An alert is also generated if the user is on a call but it is a different machine from where the machine entry occurred.
Another feature of the present system relates to fair distribution of offers to accept jackpot calls. Some casinos pool their tips and split the pooled tips based on the amount of hours worked. Others permit employees to keep all of their tips. In the latter operations, it is important to give everyone equal opportunity to be dispatched on calls to complete jackpots, which is where the majority of tips is earned.
The present implementation maintains a sequential jackpot eligibility list for each section in
When the first jackpot hits, the system starts at the top of the list and works down until an available user is located. Available here means not on a pending or active call and not on break. When the available user is located, the jackpot call is offered to the user. Regardless of whether the user accepts, defers, quits, or completes the call, that user is moved to the bottom of the list as a result of having been offered the jackpot call. If the user defers or otherwise does not complete the call, the system again starts at the top of the list and moves down in sequence to offer the call to the next available user, and so on.
When the next jackpot hits, the system again starts at the top of the list and works down until an available user is located, who is offered the call and moved to the bottom of the list. If the user defers or otherwise does not complete the call, the system again starts at the top of the list and moves down in sequence to offer the call to the next available user, and so on.
There is another routing feature that a casino will likely use when implementing the present system, namely giving priority to certain types of calls. First, on a floor that is adequately staffed during a time when slot machines are not particularly busy, all calls may be offered as soon as the system receives them. In other words, there are available users who are neither on a pending or active call nor on break. But often, especially when the floor gets busy, the calls are coming in faster than they can be serviced. As a result, a queue of calls is formed. In the past, because it is desirable to quickly respond to jackpot calls, those calls were always placed at the top of the queue rather than at the bottom. But the remaining non-jackpot calls were all serviced in first-in-first-out time order.
The present implementation permits calls to be prioritized based on a variety of factors. Each call is assigned a priority level ranging from 1 to 9, with 9 being the lowest priority call and 1, the highest. In addition to assigning a priority level when the call first enters the queue, the priority may change after the call is initially queued as a result of events that occur after the call first enters the queue. The following Table 7 illustrates one way in which calls are initially ordered in the queue.
When an event from a machine comes in, it is tentatively assigned either a 9, if a regular call, or a 7, if a jackpot call. If there is a carded player playing the machine that generated the event, the player ID is attached to the event message. This permits the system to look up the player and determine the player ranking, with one example of ranking being shown in Table 7. The priorities are then assigned according to Table 7 and the call is placed in the queue in chronological order of the time it came in with each call having an assigned priority value. This queue may be displayed on a supervisor's device as Unserviced Calls, as shown in
Several different parameters can escalate any call to a higher priority value. For every 30 seconds that passes between initial generation of the call and before the call is accepted, the priority level increases by one, e.g., a 9 goes to an 8, a 6 to a 5, and so forth. As a result, older calls steadily increase in priority.
As responders complete calls, go of break, log in, or otherwise become available to take a call, the system offers calls based on priority value, i.e., all with 1 values are first offered, all with 2 values are next offered, etc. And within each rank, e.g., all with 1 values, calls are offered in first-in-first-out order.
In addition, calls may be manually deferred by a user, automatically deferred by the system if the user does not respond to the offer in a timely fashion, and reassigned by a supervisor. Any one of these events also results in an increase (toward higher priority) of one in priority value. As a result, when the call is returned to the queue after deferral or reassignment, it is assigned to a higher priority group and is more likely to be serviced sooner.
With this system, highly ranked players may receive more prompt service, which is consistent with the operator's goal of paying special attention to the top players. But even an uncarded player who has had to wait for a long time for service may ultimately receive service before a highly ranked player as a result of the priority assignment. These priority values and adjustments to them, may be modified to satisfy a casino's service goals. For example, the 30-second time to increase priority value could be modified. Or newly carded players could be granted a higher priority. Or the highest rank could always go to the top priority.
The various embodiments of the system described above, improve the experience of a consumer within a commercial environment. As is obvious, customer satisfaction is essential to gaining repeat business.
Although this discussion describes consumers in the role of gamblers or potential gamblers within a casino, this system is equally beneficial in any gambling environment including within a traditional casino, via mobile communication device, such as a phone, pad or laptop computer and when the consumer is at home via the same devices along with a more traditional fixed personal computer or game device such a Microsoft's Xbox.
The system is also applicable to non-gambling businesses where consumer gratification—leaving the consumer with a positive memory of an experience—is important. In sum, this system may be equally well implemented in any commercial enterprise, both gambling and non-gambling and with physical or virtual presence.
In casino operations, consumer satisfaction is presumed to exist when services are delivered within defined parameters. For example, if a consumer experiences a problem and an agent provides assistance within a prescribed time, it is presumed the consumer is satisfied.
In practice, satisfaction is determined more by the respect, consideration, recognition, empathy, and kindness with which the service is delivered rather than with than the actual service itself or the speed with which it is delivered.
Modern casinos lack the tools with which to personalize services for individual consumers, motivate user agents to deliver satisfying experiences or to measure the performance of users or actual satisfaction of consumers.
The systems described above make it possible to personalize services for consumers, motivate user agents to deliver respectful and gratifying services, and measure the level of consumer satisfaction with each service delivered.
It is known in connection with such systems to include a feature that prevents an employee from being dispatched in response to a service light button at a gaming device that was inadvertently depressed. In the normal course of business, a player presses the button, which lights a light on the gaming device. Before computer-implemented dispatch systems, attendants walked the floor looking for lights that were on to see what service the player might need, e.g., to order a beverage or get some change. Once the attendant arrives, the light is switched off and the service is provided. In this system if a player, housecleaner, or attendant accidentally pressed the button, which happens on a regular basis, he or she simply switches the light off.
When computerized dispatch systems came into use, the systems detected a light-on network packet, also referred to as a light-on event, which was generated in response to actuating a service-light button at an identified slot machine. As a result, simply turning the light off—even if done immediately—in and of itself would not prevent the original event from generating a call. The prior art did, however, also detect light-off packets (events) that are generated whenever a service-light button was turned off. The light-off events also carried information that identified the machine where the light was turned off. To prevent at least some unnecessary calls from being generated, each light-on event is stored in a queue for a predetermined length of time, e.g., 15 seconds. In addition, every light-off event that comes in is checked against each event in the queue to see if they are associated with the same machine. If so, the light-on event is removed from the queue and the call is never generated. But if the light-on event remains in the queue for the full 15 seconds, a call for that machine is generated.
In this prior art system, once a call is generated it is not cleared, i.e., canceled, even if the light is turned off after the 15-second delay.
The present development provides for clearing calls that no longer require a response as a result of a detected network signal. It also addresses calls that should not be generated or should be cleared after generation in response to an earlier-received network signal (as opposed to a later-received network signal as is the case with the service light) that indicates the call is not necessary. And it facilitates use of several different events to suppress or cancel a call, use of one event to suppress or cancel several different calls, and use of several different events that would each suppress or cancel several different calls.
The present system can deal with virtually any type of event or call that is generated. One example, discussed above, is the change light, which is the only event that the prior art dealt with. And once a call was generated, there was no clearing it. In this system, however, a change light call can be cleared at any time when the change light is turned off, which generates a corresponding light-off event, so long as the attendant has not arrived at the machine, i.e., swiped the arrived slider on his or her device. This is an example of a subsequent event clearing a prior event.
Another example relates to a proprietary slot management system that generates both a machine-paid jackpot packet/event and a jackpot packet/event for the same player award. These events are used by the system for accounting purposes. The jackpot event is used by the dispatch system to dispatch attendants to hand pay and verify jackpots over a certain amount. But if the jackpot has been machine paid, there is no need to dispatch attendants for a hand pay. Put differently, if there is a jackpot event that is not preceded by a hand-pay event, the attendants should be dispatched for a hand pay.
Still another example relates to bill-acceptor jams. Such jams generate a jam event on the network that is used to create a call. Each time a bill acceptor accepts a different denomination of currency, a different event is generated, e.g., $10 accepted, $20 accepted, etc. If a jam event is followed by an event of any bill being accepted it is desirable to clear the call, assuming it has not been accepted. This scenario, a jam followed by an accepted bill, could occur if an attendant cleared the jam because he or she was nearby and cleared the jam without being on a system generated call.
The table in the co-pending application refers only to calls, but each of these calls was triggered by a corresponding event. Any of these events could be used to clear any other event, multiple events could be used to clear one event, multiple events could be cleared by one event, and each of multiple events could be cleared by each of other multiple events.
At the network level, a database table is created that incorporates the rules. An exemplary format, and including a single exemplary entry, for such a table is below. The actual table has many rows, each of which comprises a separate rule.
The first two columns are event codes, some of which are used to trigger calls in the table in the co-pending application. Because different manufactures of slot systems each use proprietary codes to designate an event, it is necessary to map each of those into a corresponding code in the present system. For example, the above table depicts code 200 in the first column, which corresponds to a service-light on event regardless of which slot management system the slot machines are connected to. And Event Code B in the second column corresponds to a service-light off event.
The Event Type column is an entry that indicates which of two ways the rule will be applied. One way is: If event A occurs before event B within the configured duration (Hold Time=30 seconds), ignore event B. This is the example given above relating to a machine-paid jackpot event and a jackpot event, which is hand paid. The other way is: If event B occurs after event A, ignore event A. This corresponds to the service light and bill acceptor examples. In this nomenclature, event A always occurs before event B, but depending upon which of two types of processing is applied either event A will be ignored or event B will. The service light rule shown in the first row is the second event type, i.e., if event A occurs before event B within the configured duration (Hold Time=30 seconds), ignore event B.
The on/off column indicates whether the rule is currently in effect. The last column is a time stamp indicating when the rule was last updated. In the present embodiment the only columns that can be updated are Hold Time and On/Off, and casino personnel can configure each of these as desired.
In operation, all of the events collected from the network stream into the system. Each event comprises a packet that identifies the nature of the event (the event code) and the machine from which it originated. Each event is checked against the table to see if it has a code that corresponds to one in the table, either event A or B. If so, it is stored in a memory location that corresponds to the particular machine associated with that event.
And as each new event is stored in memory, it is compared with each of the events previously stored to see if one of the rules in the table above applies. Put differently, each stored item is checked against each new item to see if the stored item includes an Event Code A from one of the rows and the new event includes an Event Code B from the same row. For example, if a stored event associated with a particular machine includes Event Code 200 (service light on) each event is checked to see if it includes an Event Code 190 (service light off). If so the rule in the first row shown above is applied, i.e., the stored event having Event Code 200 is cleared from memory. As a result, a service light call is not created.
The Hold Time is the amount of time each event is stored in memory before it is cleared. If the event sits in memory for the entire hold time without the rule being applied, it is consequently removed from memory and used to create a call. In the case of an event coded 200, which is in the rule in the first row, a service light call is created.
Once any call is created, it is also stored in memory at the location associated with the machine that generated the event from which the call was produced up until the time the attendant swipes the arrived slider on his or her device, which clears the call from memory. Each stored call in memory is checked against the rule table and each incoming event, just like each of the stored events are checked. If the event code that was used to create the stored call corresponds to an Event Code A from one of the rules and the incoming event comprise an Event Code B from the same rule (row), the rule is applied.
For example, one sequence could be that an event having code 200 (light on) for a particular machine arrives and is stored in memory at the location associated with the machine where the light was turned on. Additional arriving events are checked against the stored light-on event, but the hold time lapses without a code 190 event (light off) arriving for that machine. As a result, the rule in the first row is not applied to this light-on event and it is cleared from memory and used to generate a light-on call, which sends the call to an attendant's device. As this call is generated it is stored in the memory location associated with the machine, i.e., the same location from which the event that was used to create the call was just cleared.
Each new incoming event and call is checked against each stored event and call to see if one of the rules applies. In the present case if an event code 190 comes in before the attendant swipes the arrived slider on his or her device in response to the call based on event code 200, the call is cleared from the memory. If the employee has accepted the call but not yet arrived, the call is cleared and the employee is notified via the device that the call is no longer active.
A prior event may clear a subsequent call and a call may be cleared by a subsequent event. In other words, the two event type rules apply equally well when Event Codes A and B are both events or when one is a call and the other is an event. In addition, as when rules are applied only to events, a single call may be cleared by multiple events.
It should be noted that when multiple events clear a single event or call, or vice versa, or when each of multiple events clears each of different multiple events or calls, each possible combination of events and calls require a separate rule (row) in the table.
Here is an exemplary list of events and corresponding events (labeled anti-events) that could be used to cancel the event:
One to many in the list above refers to a plurality of anti-events, in this case any denomination of bill or any value of ticket, which could be used to cancel a single corresponding event.
Consideration will now be given to how a sports betting system can be implemented on a system like the one described above. Sports betting, i.e., betting on sporting events, is popular with sports fans. Bets can be made online in some jurisdictions, as well as at casino sports books, which offer bets on specified terms. The entity or person offering and accepting bets is referred to as a bookmaker or book for short. According to the Nevada Gaming Commission, $3.2 billion was wagered in sports bets in the state's casinos in 2011.
Some commonly offered sports bets are betting on a point spread, proposition betting, over/under totals, and money line betting. First, a point spread is the difference in points scored by each team. An offer to bet on a point spread such as a football game between, e.g., the Dallas Cowboys and the New York Giants, is usually offered as:
The plus sign after Giants indicates the underdog, and the minus sign after Cowboys indicate that they are the favorite. This means the Cowboys are expected to win by 4.5 points and the Giants are expected to lose by 4.5 points. Of course, half points aren't scored in football but setting spreads on the half point is a way to avoid a tie when the spread is taken into consideration. Based on this point spread, a bettor would bet on the Cowboys if she thought the Cowboys would win by 5 points or more and on the Giants if the thinking was that the Giants would lose by less than 5 points.
The −110 figures in parentheses beside each team is the amount that must be wagered to win $100. Bets may be placed in other amounts but this ratio holds true for all bets. This difference goes to the bookmaker as a fee for offering and placing the bet. Bookmakers set the spread to attract an equal amount of money on both sides of the bet. Over time, this maximizes a bookmaker's profit. If the betting becomes too heavy on one side, e.g., $125,000 bet on the Cowboys and $60,000 bet on the Giants, the bookmaker typically changes the spread as the game approaches to attract more money bet on the Giants.
Another type of common sports betting is a money line bet. In this bet, a bet on a baseball game between, e.g., the Chicago Cubs and the Los Angeles Dodgers, is usually offered as:
The plus sign by the Cubs indicate the underdog, as determined by the bookmaker. The minus sign by the Dodgers indicates the favorite. In this case, a bet of $100 on the cubs will win $120. And a bet on the Dodgers of $130 returns $100. Here there is no point spread. The only concern is identifying a winner and a loser after the game. Money line betting is better suited for low scoring games such as soccer, hockey, and baseball as the score of the winner and loser are often very close to one another, e.g., 1-0, 3-2, 4-1, etc. These small point spreads are much harder for a bookmaker to predict. In the case of a tie, the rules of the bet may require that the bet be returned to the bettor or that either the bookmaker or the bettor wins.
Proposition betting is betting on an outcome in a game such as whether a player will score either more or less than 15 points, have either more or less than 5 receptions, or score the first touchdown in a game. Proposition bets are offered as money line bets. For example, which player will have the must runs in a game. This bet is offered as:
Frank Thomas (Toronto)−105
Joe Johnson (San Francisco)−125
If the bettor believes Frank Thomas will have more runs, the bettor must wager $105 to win $100. If, on the other hand, the bet is placed on Joe Johnson, the bettor must wager $125 to win $100.
An over/under bet is a bet on whether the combined score of both teams will be over or under a set number of points. It is also a money line bet and is offered as:
55.5 o −110
55.5 u +105
To win this over bet the scores of both teams added together must be 56 or greater. And to win the under bet, the scores must be 55 or less. Here the over bet requires the player to bet $110 for a return of $100 if he or she wins, and the under bet returns $105 for a bet of $100 if the under bet is a winner.
As with all gaming, there is a house advantage—in this case for the bookmaker. If the bookmaker is doing a good job of setting the money lines, there is an equal amount of money bet on each side of the bet. With that assumption, for money line betting, the bookmaker will pay all winning bets and will collect all losing bets. This can be expressed in the following equation (1) as an expected bookmaker share of each bet made:
Theoretical profit=[0.5×(−$100)]+[0.5×(+$110)]=$5 (1)
As a result, the percentage of each dollar bet that the bookmaker can expect to collect, at least theoretically, is $5/$110=0.045=4.5%.
Some sports books track the amount of wagers placed by an identified bettor and offer him or her rewards for accumulating loyalty points that are related to the amount bet. For example, each dollar wagered at a sports book may accrue one loyalty point. These loyalty points may be redeemed for rewards such as cash back, gift cards, airline miles, etc. Some sports books permit redeeming loyalty points for a free or reduced-price bet. But redeeming loyalty points for a bet or bet-price reduction typically includes many restrictions such as limitations on the amount and timing of redemption, requiring multiple wagers of funds won before permitting the bettor to take cash, limiting the award for bets placed with loyalty points, etc.
Players of casino games also accrue loyalty points for wagers made on the games. This can engender loyalty and may result in a player concentrating their play at a casino to accrue as many loyalty points as possible. But sports bettors are very sensitive to price differences in bets as well as the point spreads offered. For example, one sports book might offer a money line bet at −110, which means the bettor must put at risk $110 to win $100. But another might offer the same bet at −105, meaning the player must risk only $105 to win $100. The latter bet reduces the revenue to the sports book for each bet placed but may result in much more money bet due to the value perceived by the bettors, or simply may maintain the long-term loyalty of a customer whose business would have otherwise been lost. Similarly, different sports books offer different spreads. Bettors can consult websites listing the spreads offered by different sports books to see where they can bet with the greatest advantage. Sports bettors are often willing to bet wherever the best terms are offered and don't place much value on loyalty points accrued at any one sports book.
The present system contemplates altering the terms of bets offered by a sports book. In some embodiments, the terms are changed in response to a request initiated by a player; in others, the sports book offers bets with altered terms to selected bettors. The terms may be altered to favor the sports book, in some embodiments, or the bettor. There are several ways in which the sports book can alter the terms of a bet:
In one aspect of the present system, players may earn more loyalty points by making disadvantaged wagers. Many people will always bet on their favorite team. A bettor who always bets on the Chargers is likely to do so whether the point spread is −3.5 or −3.0. For example, if a sports book is awarding 1 point per $1.00 wagered, a bettor who bets $100 on the Chargers at the published line of −3 will get 100 loyalty points. If the bettor is willing to take a larger spread, e.g., −3.5 points, which is harder to cover, the bettor can earn loyalty points at a faster pace, e.g., 1.5 points per $1.00 wagered.
The present system also contemplates both online and sports book betting that permits bettors to redeem loyalty points not only for reduced-price bets but to also use loyalty points to change the point spread instead of requiring payment for altering the spread as some bookmakers do.
In addition, in one embodiment, bettors are evaluated in terms of value to the bookmaker, which may be measured by the historical record of the bettor and by her perceived future worth. The historical record may include how many bets have been placed to date and may include sports betting as well as gambling on gaming devices in a casino where the sports book is located. Perceived future worth may be based on such things as the price paid by the bettor for a room at the resort where the bookmaker is located, the bettor's zip code, association with a VIP, annual personal income and other commercially available information that can be obtained from third party vendors that accumulate and index information relating to individuals, e.g., credit worthiness. In this embodiment, bettors are periodically offered reduced price bets, reduced point spreads, or increased awards without necessarily offering loyalty points to the bettor. In short, these offers come as a pleasant surprise to the bettor.
First, considering an embodiment in which bettors may use loyalty points to change the point spread or the price of the bet or to increase an award, the bookmaker need not necessarily accumulate any information about the bettor other than the amount of accrued loyalty points. For example, a player might redeem10 loyalty points to reduce the point spread from 3.5 points to 2.5 points thus giving the bettor an advantage when betting on the favorite. Conversely, the bettor might use loyalty points to increase the point spread when betting on the underdog. Or the player might redeem loyalty points on any type of bet to gain an increase of 5%, for example, in the award offered to all other bettors. Also, loyalty points might be used to reduce the cost of the bet by, e.g., 3%. This appeals to bettors who are price sensitive to other bookmakers' terms and results in increased loyalty to the bookmaker. In this scenario, the bookmaker tracks the cost of the loyalty redemptions, including bets paid on reduced point spreads that would not have been paid but for the reduction, decreased bet costs, or increased awards. This enables the bookmaker to evaluate the cost of the loyalty redemptions and adjust future redemption terms accordingly to maintain the cost within a budget. The total volume of all bets placed is compared to the cost of the redemption program. The bookmaker can use this comparison to alter the redemption terms, either raising or decreasing redemption value, in accordance with how much of the total volume could be attributed to the increased loyalty created by the loyalty redemptions. These modifications can be made manually at a computer by the bookmaker or may be done by an algorithm stored in a computer memory that automatically adjusts redemption terms. Consideration will now be given to how a bookmaker tracks the theoretical cost of using loyalty points to alter bet terms. Suppose each $110 bet is awarded 1 loyalty point. A player with 10 loyalty points can be redeemed by the player for the right to reduce the price of the line by $10 (−110 becomes −100), or reduce the point spread by a half point (a 3.5-point spread becomes 3 points or 4 points depending on which way the player desires to move the line).
Since $110 earns 1 loyalty point, 1 point is awarded for each $5 in theoretical profit a player contributes to the casino. A player with 10 loyalty points has therefore contributed $50 of profitability to the casino. The casino can now reward the player by offering him the chance to reduce the betting line from −110 to −100 (even money), completely removing any casino advantage from the wager.
This loyalty bonus costs the casino $5 in lost theoretical revenue, assuming the player would have made the bet at the −110 line. But it's offset against $50 in previous revenues, resulting in a 10% reinvestment rate. The reinvestment rate is the percentage of a player's theoretical profit to the bookmaker that is returned to the player in some manner, e.g., in the form of improved bet terms for the player. This calculation may be used to calculate the theoretical cost of lowering the bet price for bets on point spreads as well as money line bets.
Players might also be offered the chance to reduce the point spread in half-point increments. In the case of, e.g., a Los Angeles Lakers −3.5 spread, a player wagering on the Lakers may opt to redeem 50 loyalty points to reduce the line to −3.0 points. Upon setting the line at 3.5, the bookmaker estimated that there was a 50% chance the game would end with the Lakers winning by 4 or more and a 50% chance that the Lakers would win by 3 or less or lose. To account for this adjusted line, the casino just needs to assign a new probability to each half point movement. If each half-point move adjusted the probability by 5%, the Lakers would have a 55% chance of covering the spread if it were reduced to 3.0. The following equation (2) expresses the resulting shift in the theoretical profit:
(Amount to be won×probability of winning)−(Amount to be lost×probability of losing) (2)
The Lakers have a 55% chance of covering the spread and a 45% chance of not covering the spread, and the player is wagering $110 to win $100. Therefore:
($110×0.45)−(100×0.55)=−$5.50
The player holds a $5.50 advantage over the bookmaker in this example, which is a $10.50 difference from the original $5 casino advantage. Since the player is redeeming loyalty points for the right to make this bet, the bookmaker can offset this cost against previous revenues. If the bookmaker wanted to maintain a 10% reinvestment rate, moving the line a half-point would cost 20 loyalty points.
The same equation can be used to calculate the theoretical cost of increasing an award. For example, a parlay bet is a bet that links together two or more individual bets and results in an award only if each of the outcomes of the individual bets are correctly selected. When there is a wager only on one game or outcome, each side has a 50% chance to win. Each game or outcome added to a parlay reduces the bettor's chance to win by 50%, so a 2-team parlay results in a 25% chance, a 3-team parlay in a 12.5% chance, and so on.
Here is another way to view how a sports book can offer an improved point spread to a bettor and how the cost of doing so is accounted for. The sports book can offer Jack the opportunity to change the spread of the game with his loyalty points. Suppose Jack wants to bet the Warriors but isn't sure that they'll cover the −2.5-point spread. He would like the bet a lot more at −2.0. The sports book can offer Jack the chance to redeem his loyalty credits for a custom movement in the line to his desired −2.0.
One way to calculate the theoretical cost of moving the point spread by half a point is to assign it the same cost as changing the cost of the bet by $5.00. This is a fair assumption because some sports books attract business by improving the spread by a half point and others do so by reducing the cost of the bet by $5.00, i.e., changing the terms from −110 or −105. In sum, the sports book market considers each of these altered terms to be roughly equivalent. As will be recalled, the theoretical profit is calculated by using equation (1) above. When the cost of a bet on a point spread is −110, the theoretical profit on all bets made is 4.5%. When that cost drops to −105, the theoretical profit is:
Theoretical profit=[0.5×(−$105)]+[0.5×(+$110)]=$2.50
As a percentage of bets placed, the theoretical profit at −105 is $2.50/$105=2.4%. At the original line, the theoretical profit for the sports book, as calculated above, was 4.5%. If we allow Jack to adjust the spread in his favor by a half point, the win rate is reduced by 2.1% to just 2.4%. To determine how much to allow Jack to bet at his modified point spread, divide 2.1% (the cost of each half point change) by $15 (the dollar value of his loyalty credits). These relationships can be expressed in the following equations:
Player's Theo Win Balance×Desired Reinvestment %=Player's Loyalty Credit $ Value
Net Cost of Line Movements (2.1% for each half point)/Player's Loyalty Credit $ Value=Amount player can wager at adjusted point spread
Any amount the player does not wager could be left in a balance on the player's account to be applied to future wagers with altered terms.
Consideration will now be given to altering the terms of a parlay bet. A 6-team parlay gives the bettor approximately 1.6% odds of winning and the bookmaker 98.4% odds of winning. To calculate the bookmaker's theoretical revenue from a 6-team parlay, the probability of the bettor losing is multiplied by the bet and subtracted from the probability of the bettor losing (the bookmaker winning). For example, a 6-team parlay that pays $4,000 for a $100 bet results in $36 theoretical profit to the bookmaker, as follows:
($100×0.984)−($4000×0.156)=$36
The bookmaker can redeem loyalty points from a bettor for the chance to win an increased award if the parlay bet is successful. For example, a bettor on a 6-team parlay bet may redeem 10 loyalty points for the chance to win the award for a 7-team parlay bet, which is $7500. The value of this offer can be calculated by substituting the new potential award, $7500, for $4000 in the above equation, as follows:
($100×0.984)−($7500×0.156)=−$18.75
Even though the player will lose over 98% of these bets, the player has an advantage over the bookmaker. But the bookmaker is willing to offer this bet to engender loyalty. Because a 6-team parlay has a $36 theoretical value to the bookmaker, a player with 10 such previous bets will have contributed $360 in theoretical value to the bookmaker's gross income. As a result, the bookmaker has only invested $18.75/360=5.2% of the player's past theoretical contribution to the bookmaker to gain the player's loyalty.
In another embodiment, player points can be used to both change the point spread and pay the cost of the wager. For example, assume the bettor has 300 loyalty points in his or her account and the point spread offered on a bet is Chargers −3. The bettor would like to move the point spread in her favor and use the loyalty points to pay for the bet. The following exemplary options are available to the player:
In options (1), the bettor can bet $300 in exchange for all 300 of her loyalty points. For option (4), however, the 300 points results in a wager of only $37.50.
Turning now to the embodiment that considers bettor value, an algorithm evaluates the bettor's history of loyalty with the bookmaker, based on, e.g., accumulated bets placed, and projects the bettor's potential future loyalty, as described above. In addition, the system, via computer code stored on a server, reviews the bets that this bettor has historically made. There might be a pattern of over/under bets that always includes the same team or a consistent bet on the same team, or a proposition bet that involves performance of the same player. The algorithm calculates a modified point spread, a reduced-price bet, or an increased award that is offered to the bettor. It also calculates the decrease in theoretical income to the casino, using the equations above, and thereby associates a cost with the offer. This may be debited from what might be thought of as the bettor's goodwill account, which as described above corresponds to the bettor's historical and predicted future value. In this manner, the system accumulates player value, i.e., goodwill, while debits from the account are made based on decreased theoretical or actual income to the bookmaker. Decreased actual income results from bets won that would have otherwise been lost because of the bet modification. Decreased theoretical income is calculated using the equations above. As a result, advantageous bets are offered to the player until the credits in the goodwill account are used up. This embodiment can be considered a loyalty program that is hidden from the bettor. It offers customized bet advantages, based on each bettor's value, that result in enhanced bettor loyalty to the bookmaker.
If the bettor does not accept a bet, an alternative bet is offered, either immediately or later. For example, the spread on a first bet that was not accepted may be further reduced or a different team is offered. The server may automatically handle all this, but a human handicapper may also enter information regarding cost of modifying the spread or may even override the system and offer an even more advantageous bet, within limits.
The algorithm tracks which customized bets are accepted and which are not. It also tracks the teams and players on which bets are placed. This information, combined with the calculation of player value, is used to select the terms, teams, and players for customized bets offered to each player.
Sports books use systems that track the history of bets placed by enrolled bettors. The history may indicate, for example, that the player prefers the home team, the over, favors a certain team or always bets the favorite or underdog. The present system can rank or prioritize bets to offer based on the following:
Here is an example of customizing bets offered based on a bettor's record, and what may most benefit the bookmaker. The bettor has made 7 bets this year on the Los Angeles Chargers. It is now Sunday an hour from kickoff, and the Chargers are −3 today. No wager has been received from this bettor. The system can send an automated message to the bettor, e.g., via electronic communications such as text or email, and offer a bet on the Chargers for −2.5 up to a specific dollar amount.
But the system may determine that the Chargers are likely to cover the spread even at 3 points, and there are more profitable games that it can offer (for instance, the Broncos are +4, but the system believes they're unlikely to cover even a +6-point spread). Because it is more profitable to offer the bettor the Broncos bet at +6, the system sends an electronic message, or otherwise offers, the Bronco bet rather than the Chargers bet. When the bettor declines a bet, the system can continue to offer different bets or simply stop making offers. In another embodiment, the goodwill account is never reduced. Suppose a regular bettor is known to have significant resources that makes him able to bet often but this bettor tends to make his wagers at another book. Giving him a personal advantage on a betting line, may result in the bettor shifting his loyalty to where he receives a betting advantage.
If the personal advantage given to him cuts the bookmaker's theoretical margin from 5% to 2%, the 3% difference for each wager he makes need not be deducted from the player's loyalty account. Rather, the player can make unlimited wagers on future personal lines, in which the bookmaker's goal is to get as much additional profit as possible. After all, if at 5% margin the bookmaker gets zero business and at 2% margin gets $5,000,000 of bets per year from this bettor, the betting at 2% should not be limited.
In other words, the bookmaker analyzes the personal line from a theoretical point of view to ensure some positive margin is available. In this manner, the lines are set for each bettor to gain the highest yield from each bettor (wager volume×theoretical hold) that is possible. If a bettor has limited means, with projected total wagers of $50,000 per year, the benefit offered will be less than that offered to a player with a capacity to wager $10 million annually.
The present system can be implemented in a variety of ways, including using the hardware and system disclosed in U.S. Pat. No. 9,087,431, which is incorporated herein by reference. For example, the data collected on bets and bettors can be stored on servers on a network, either wireless or wired, and provided to computers where an employee of the bookmaker places the bet and collects the wager for each bettor. Or the bettors may have mobile computing devices in communication with the network servers. This allows bettors to place their own bets on their devices. Such a system may also include geofencing, which restricts the use to within the physical bounds of the bookmaker and/or an associated casino.
In jurisdictions that permit sports betting online, a bet may be placed via the Internet through a computer, either using a browser or a program. An online bookmaker may use known Internet techniques to limit betting to a jurisdiction, e.g., a state, where online sports betting is permitted and to prevent attempted bets made from beyond the jurisdiction.
Another sports betting innovation relates to providing the opportunity for a bettor to create a bet, which is offered by the bettor on a sports book system at which the bettor is registered. These bettor-created bets may be accepted by the sports book or by another bettor registered with the sports book.
For example, a bettor may wish to place a proposition bet based on how many 3-point shots a player will make in an upcoming game. But the bettor is unable to find a that bet at the sports book—and possibly may not be able to find it at any sports book.
A user interface allows a better to define a bet, including, e.g., setting the line and a dollar-range of bets the better is willing to offer. In the case of the 3-point proposition bet, the better can set the number of 3-point shots made at 11.5 and indicate he or she is willing to wager any amount between $20 and $500. This bet can be accepted by either the sports book or another bettor by specifying the amount wagered within the range and whether they are betting on over or under 11.5 3-point baskets. Of course, any type of bet that the sports book supports may be created by the bettor.
The creator of the bet may have the option to take one side before offering the bet, leaving only the other side of the bet for whoever accepts it. For example, in the case of the proposition bet, the bettor may bet on either over or under 11.5 3-point shots made during the game. As a result, anyone accepting the bet may only take the side not chosen by the creator of the bet. The creator could try to set the line as accurately as possible. In other words, based on all available information, setting it as equally likely that either the over or under side of the proposition bet would pay. In such cases, the creator of the bet might choose to take one side and offer only the other side of the bet or leave the bet open so that the whoever accepts may take either side with the bet creator taking the other side.
On the other hand, the creator could try to set an inaccurate line that favored one side more than the other. For example, if 11.5 3-point shots is the most accurate line in view of all available information about the player and the game, the bet creator might choose to set the line at 10, or even lower, take the over side of the bet, and offer the bet with only the under side available thus giving an edge to the creator of the bet. Of course, savvy bettors won't take such a bet, but someone might.
When another bettor registered at the sports book accepts a bet, the sports book holds or withdraws funds in the account of both the bet creator and the person accepting the bet, essentially escrowing both wagered amounts. The funds are in the amount to cover paying the bet for each side. When the game is concluded, the winning side receives all the money from the escrow account. Alternatively, the sports book may charge a fee for providing this service, which may be deducted from the escrowed funds prior to dispersing the remainder to the winner. In such a case, the bets are set in a manner that includes the fee, like the example for proposition betting above. The bet amounts might be set so that each side of the bet provides a portion of the fee or one side or the other provides all the fee. And this could be mandated by the sports book or under control of the bet creator.
Placing a wager related to an event while the event is in progress is known as in-game wagering or live betting. A live betting opportunity exists from the time an event starts until it ends. This type of wagering is offered by many sports book and is becoming increasingly popular. The wagers are offered by a sports book only during the event. For example, at the start of a football game, one team is a 12.5-point favorite. But at the end of the second quarter, the score is tied. As a result, the live betting odds are reduced to making the favorite team only a 2-point favorite. Live betting spreads and lines are volatile and can vary substantially from those set just prior to the start of the event. As a result, bettors must act quickly to place bets at their desired terms.
Sports books typically take bets via a proprietary computer program installed on the bettor's computer or device. This is typically an app on a smartphone. To place a bet, the bettor must:
When a bettor is attempting to bet, the sports book must verify, via the program, the following:
In addition, web pages are subject to connectivity problems that may slow or block an attempt to place an online bet. What is more, the sports book must receive the bet before it becomes unavailable. Otherwise, the sports book won't accept the bet. As a result, latency between the time the bettor submits the bet via an input to the app or browser and the time the sports book receives the bet may result in the sports book rejecting the bet.
All of these problems can be overcome if the sports book can text bet proposals to a bettor in real time during an event. These texts may be sent via a messaging system such as Facebook Messenger, iMessage, SMS service, etc. The messaging system could be separate from the app or built into it. The bettor can reply by simply confirming the bet or specifying an amount to bet.
The location, identity and bet availability must still be confirmed. First, considering confirmation of location. Mobile computing devices, such as smartphones, typically include location-based services that can generate the coordinates of the smartphone using GPS, GSM, multilateration of radio signals, etc. The sports book app may be programmed to take advantage of this built-in feature so that the bettor's response to the bet is stamped with the current location of the smartphone. The location is consequently immediately verified when the bettor responds.
The app can also be easily programmed to time-stamp each response using a built-in clock on the smartphone. As a result, the time stamp on the response can be compared to the time of the event on which the bettor submitted the bet. Assume, for example, the bettor is offered a bet on whether a 2-point conversion will be successful. The window for placing such a bet is very short: between the time a touchdown is scored and the start of the next play, namely the conversion attempt. The bet is offered to the bettor via text, the bettor responds with $100 bet that the conversion will be made. This response is time stamped (and stamped with the location), and the time is compared with the time the play started. As discussed above, latency may slow down transmission of the response, which may not be received until after the play is over. But if the time stamp indicates the bet was submitted before the start of play, it can still be accepted.
Identity can be confirmed in several different ways. First, the player could log in and opt to be remembered, via controls in the app, based on IP address or something similar. Many smartphones now include facial and fingerprint recognition. Either of these could be used in the app to confirm identity when each response is sent. These types of offers to bettors may also be sent prior to the start of an event, as described above.
The volatility of live betting presents another opportunity for bettors. In this novel feature, a bettor could place a bid on a bet at a specified money line or point spread. For example, the bettor could see a team with a −7 favorite, but he or she would only like to bet on the team if the line changes to −3. Via the app, the player can put a bid on a bet on the team at −3 for the specified amount. Once the game starts, if the odds shift to −3, the bet is automatically placed and the bettor's account debited in the specified amount. This feature could also be used to bid on bets before the event begins but the shifting odds in advance of the event are typically less substantial and less volatile.
In still another feature, bettors could offer to sell an already-made bet during the event on which the bet is placed. For example, assume a bettor was holding a $100 bet on a football team that was +200 before the contest began. With 5 minutes left in the contest, the team is up by 11 points. The odds are good that the full $200 value of the bet will be collected. But that is not certain until the event is over, and the team has won. At 5 minutes left in the game, the bettor might be willing to sell the wager for 90% of the value, $180, to remove all risk and lock up most of the profit. This bet could be offered for sale via the sports book app in a manner similar to how bets are offered from one bettor to another, described above.
In another example, if the bettor had bet on the other team in the contest at −200, the ticket would appear to be nearly worthless with 5 minutes left to go in the game. Here, the bettor might offer it for sale to other bettors at 5% of what he or she paid just to salvage something out of it. In either of these examples, the purchaser of the bet might be another bettor or the sports book.
There exist third party brokers that sell tickets issued by bookmakers. In this system, a seller takes a picture of her ticket, opens an account on a website operated by the ticket broker, and posts the picture. Those interested in buying posted tickets review the website for tickets of interest. When one is found, the buyer opens an account (if not already open) and buys the ticket with, e.g., a credit card. When a ticket is sold, the seller must mail it to the broker who in turn mails it to the buyer via certified mail after taking a percentage of the selling price as a commission. The seller is credited with the balance of the sales price.
This approach is cumbersome for several reasons. The ticket needs to be posted for a long enough time for interested sellers to peruse the offerings and select one. And the escrow process further slows down the speed at which bets can be sold and bought. As a result, it is suitable only for tickets that reflect bets that won't be resolved for many after the ticket is issued. The present system overcomes these disadvantages. Further, the broker must validate the ticket with the issuing bookmaker to be sure that counterfeit tickets are not offered. And one broker requires the seller to provide credit card information so that a hold can be placed on the card pending delivery and verification of the ticket. The present system operates must more effectively and avoids these problems.
This application claims priority to U.S. Provisional Application No. 62/544,067 filed Aug. 11, 2017, which is hereby incorporated by reference, and to U.S. Provisional Application No. 62/652,699 filed on Apr. 4, 2018, which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62544067 | Aug 2017 | US | |
| 62652699 | Apr 2018 | US |
