WO2007118300A1

WO2007118300A1 - Offering bets on events during a live event while the live event is in progress

Info

Publication number: WO2007118300A1
Application number: PCT/CA2006/000633
Authority: WO
Inventors: Jean Paul Dupuis; David Bullock; Jean-Pierre Bhavnani; Robert Riopelle
Original assignee: Jean Paul Dupuis; David Bullock; Jean-Pierre Bhavnani; Robert Riopelle
Priority date: 2006-04-19
Filing date: 2006-04-19
Publication date: 2007-10-25

Abstract

Wagering on the outcome of discrete events in a sporting event via a network such as the Internet is made possible. Multiple components work together to provide odds on each event and deliver the odds to users via a network in real time. In determining odds both statistical and heuristics based methods are used with the results being combined and then subjected to transformation based on a number of models. Upon receiving the odds a user may then place one or more bets which are resolved upon the outcome of the event. Multiple sources of event status are reviewed. A reconciliation process to deal with conflicting event status is provided. The results of an event are stored and utilized in a feedback process to aid in predicting odds for similar events in the future. Multiple forms of wagering are supported, including variants of the standard pari-mutuel model.

Description

Offering Bets on Events During a Live Event while the Live Event is in Progress

BACKGROUND

[0001] A large number of Internet portals currently exist, allowing consumers to wager on sporting events. Despite the use of the Internet to offer these gaming services, the wagers available for selection are virtually identical to those of conventional bookmakers. Wagers may be placed to bet on the winner of a contest, or which player will score the winning goal, but these fail to embrace the real-time interactive capabilities of the Internet.

[0002] Entertainment systems exist which allow viewers of sporting events to predict a play, such as NTN Communications' 'QBl' game offered in sports bars and restaurants. However, these systems require specialized hardware, require the consumer to play the game at participating establishments, and do not allow any form of legal wagering to occur. Consequently, the options available for internet-based sports wagering currently lag behind both the available technology, and the consumer demand for more interactive and comprehensive wagering options. [0003] The present invention allows consumers to wager small amounts on real-time "nano-events" from any Internet equipped device. Wagers against nano-events might take the form of questions such as: a) Hockey: "Will the Boston Bruins score on this power-play?" b) Basketball: "Will Vince Carter hit this next free-throw?" c) Football: "Will the Green Bay Packers issue a run play or a pass play next?" d) Golf: "Will Tiger Woods sink his next putt?" e) NASCAR: "Will Jeff Gordon pass the race leader on this lap?"

[0004] The inventors refer to this new field as NanoGaming. NanoGaming brings to consumers a highly entertaining gaming mechanism, which has not existed before. It allows consumers to play armchair quarterback while watching a live event, and place small nano- wagers on the outcome, which is typically known in under a minute. This creates an impulse wagering mentality for sports wagering. SUMMARY

[0005] The present invention is directed to a method for permitting a user to wager on the outcome of an event while said event is in progress, said method comprising the steps of: presenting to said user said event, as well as odds and projected payouts of said event based upon combining heuristics and statistics; accepting a wager from said user on said outcome; updating odds and projected payouts on said event while said event is in progress and providing the results of said updating to said user; and upon the completion of said event informing said user of said outcome and reconciling the account of said user based upon said outcome.

[0006] The present invention is also directed to a system for permitting a user to wager on the outcome of an event while said event is in progress, said system comprising: means for presenting to said user said event, as well as odds and project payouts of said event based upon combing heuristics and statistics; means for accepting a wager from said user on said outcome; means for updating said odds and projected payouts on said event while said event is in progress and providing the results of said updating to said user; and means for upon the completion of said event informing said user of said outcome and means for reconciling the account of said user based upon said outcome. [0007] The present invention is further directed to a computer readable medium comprising instructions for executing the method for permitting a user to wager on the outcome of an event while said event is in progress.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] For a better understanding of the present invention, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the accompanying drawings which aid in understanding an embodiment of the present invention and in which:

[0009] Figure 1 is an block diagram of a system implementing NanoGaming; [0010] Figure 2 is a block diagram of the components of the SIE Module;

[0011] Figure 3 is a flowchart illustrating the loading of information into the statistical database; [0012] Figure 4 is a logical flow diagram of a likelihood model;

[0013] Figure 5 is a deterministic decision tree of the logical steps of a play call model for a inn;

[0014] Figure 6 is a block diagram of the logical functions of a fusion module;

[0015] Figure 7 a block diagram illustrating an example of the utilization of a compensation module;

[0016] Figure 8 is a block diagram illustrating the components utilized by an operations module;

[0017] Figure 9 is a block diagram of the logical functions of a game state auto-advance module; [0018] Figure 10 is an example of flowchart for updating the game state;

[0019] Figure 11 is a block diagram of the logical functions of a conflict resolution module;

[0020] Figure 12 is a block diagram illustrating the components used by the integration module; [0021] Figure 13 is a block diagram illustrating the steps of a betting pool lifecycle;

[0022] Figure 14 is a block diagram illustrating the components used by the portal module; [0023] Figure 15 is a block diagram of the structure of the portal database;

[0024] Figure 16 is an example of a graphical user interface for a user;

[0025] Figure 17 is a block diagram illustrating the steps of raked pari-mutuel wagering;

[0026] Figure 18 is diagram illustrating an example of a cascaded pari-mutuel betting model; and

[0027] Figure 19 is a block diagram illustrating the steps of cascaded pari-mutuel wagering.

DETAILED DESCRIPTION

[0028] Referring now to Figure 1 a block diagram of a system implementing NanoGaming is shown generally as 10. System 10 comprises four main modules, namely Situational Intelligence Engine (SIE) module 12, operations module 14, integration module 16 and portal module 18. Integration module 16 and portal module 18 are connected via a network 20a. Portal module 18 is connected to a plurality of users 22 by network 20b. Networks 20a and 20b may take any form that allows communication between their appropriate modules, one such example being the Internet.

[0029] SIE module 12 determines nominal odds for the various betting interests being offered by system 10. SIE module 12 combines statistical knowledge and expert strategy (heuristics-based) knowledge to produce context appropriate initial odds, which account for the game situation, involved personnel, and surrounding environment. These odds are stored in a SIE Database (not shown) which is accessed by operations module 14 when a new betting inierest is about to be offered to users 22. [0030] Operations module 14 handles the tasks of (i) upkeeping the current game state, (ii) selecting betting interests to be offered to users 22, (iii) resolving previously issued betting inierests, and (iv) issuing timing labels to control the betting window lifecycle. Operations Module 14 makes use of trained operators watching event broadcasts, automatic sensing modules, and third-party event loggers to determine what events are relevant for wagering, what the situational parameters are for that event, and what the ultimate result of that event was.

[0031] Integration module 16 handles the tasks of (i) issuing available betting interests to one or more portal modules 18, (ii) controlling the lifecycle of all betting interests, and (iii) auditing and reporting on betting activity for each portal module 18. [0032] Multiple instances of a portal module 18 may exist and each handles the tasks of (i) issuing multiple betting interests to participating users 22, (ii) updating users 22 with changing odds on the outstanding betting interests, (iii) storing and resolving all individual betting interests, and (iv) providing a multi-device remote interface for wager placement and account viewing, such as via mobile devices, a personal computer, or a Personal Digital Assistant (PDA) capable of accessing network 20b. [0033] As can be appreciated by one skilled in the art, Figure 1 shows only one embodiment of how communication between users and modules may occur. Due to legal requirements in various jurisdictions regarding gambling, networks 20a and 20b may not be permitted in a specific jurisdiction. Similarly the same issue occurs regarding where the modules of the invention reside. Thus, modules and networks reside in jurisdictions that provide for legal gambling through the use of the present invention.

[0034] Referring now to Figure 2 a block diagram of the components of SIE module 12 is shown. Statistical database 30 provides statistical data, such as play outcomes and performance statistics for previous sporting events, to statistics module 34. An expert 32, who may be a person or an expert system, provides information to predict the outcome of an event to heuristics module 36. Fusion module 38 combines the results of statistics module 34 and heuristics module 36. In one embodiment fusion module 38 would be an expert system such as a neural network. Compensation module 40 may adjust the outcome of an event provided by fusion module 38. In doing so, compensation module may consider such factors as (i) team strategy, (ii) on field personnel, (iii) weather conditions, (iv) stadium conditions, (v) player performance and (vi) external factors. Many other factors may be incorporated into the model; this list is intended as an example only, in particular for an American football game.

[0035] In describing how the present invention may be utilized we will continue to use the example of American football. It is not the intent of the inventors to restrict the present invention to a single type of sport but rather to provide clear examples of how the invention may be implemented with regard to one event. It is not the intent of the inventors to restrict the event to a sporting event, the present invention may be utilized with any real time event, for example: poker tournaments, reality television episodes, awards presentations, a weather forecast, in essence any real time event where wagers may be made while the real time event is in progress. In another embodiment, wagers may include the use of token bets in the form of simulated currency that do not involve the payment of actual funds by the bettor or payments to a winner. In this embodiment the game is essentially "wager for free" and may be used in skill-gaming tournaments or competitions.

[0036] Compensation module 40 stores the odds for an event in SIE database 42. SIE database 42 is accessed by operations module 14 whenever a new event is offered to users. SIE database 42 further provides feedback to fusion module 38 so that fusion module 38 may learn from the results of its prediction of an event outcome.

[0037] We will now describe each of the components of an embodiment of the present invention as shown in Figure 2. Referring now to Figure 3, a flow chart illustrating the loading of information into statistical database 30 is shown. Beginning at step 50 detailed game logs are provided. These game logs are typically provided by a third party in a format of their choice. Each game log will contain information on each event during a game. For example in the case of American football examples of events would include the team in control of the ball, the time of the event, the play executed and the result of the play. In essence a game log is a play by play description of the game. A game log is then parsed by parser 52 based upon knowledge of the format of a game log and a parsed event listing 54 is created which is then stored in statistical database 30.

[0038] In order to create odds for given situations based on how similar situations resolved historically, the statistical database 30 is discretized. This involves the creation of a number of "bins" within each parameter space. For instance, the following discretized parameter space shown as Table 1 may be used to represent historical performance in American football.

Table 1.

[0039] The information stored in bins can be converted into odds by looking at the percentage of the occurrence. For example in bin 2 shown in Table 1 there may be two hundred times that a run happened and fifty times a pass happened. These can be turned into percentage likelihood's, the reciprocals of which are the odds.

[0040] Performance statistics 56 contain information on how each team in the game has historically performed for a number of events. Performance statistics 56 are provided by a third party source and stored in statistical database 30. The performance statistics 56 are typically not placed in a bin, but may be. An example of performance statistics would be "average yards per run at Giant's stadium".

[0041] Statistics module 34 utilizes the data stored in statistical database 30 to provide odds for each wagering option. These odds are then provided to fusion module 38. The information stored in a bin is utilized to determine the odds of an outcome

[0042] Referring now to Figure 4 a logical flow diagram of a likelihood model is shown. Within heuristics module 36 there reside multiple likelihood models. Likelihood models calculate a likelihood value for the next event based upon the current game factors. A likelihood model is not based upon statistical data in statistical database 30 but rather on an expert system embodied within heuristics module 36. In the case of American football, factors to be considered may include the current down, the number of yards to go, position of the ball and current game time. Here we show a "Play Call" model. Other models may include "Play Result", "Next Penalty", "Coin-toss", "Next Score", "Player" or any other models that apply to wagering scenarios. [0043] Pass likelihood model 60 calculates a likelihood value of the next play being a pass. Models 62, 64 and 66 calculate likelihood values for a run, field goal attempt and punt respectively. The likelihood values 68, 70, 72, and 74 are the outputs from each model. Based upon the current game situation, the highest likelihood value is from model 62 as a run play is expected and the lowest likelihood value is from model 66, as a punt is not expected. Trie likelihood values are then normalized by feature 76 and output as probabilities 78, 80, 82, and 84. The normalization process is straightforward: normalized value = likelihood value / sum of likelihood values

[0044] Thus we see that the probability of the play call being a run is .61. These normalized values are then sent to fusion module 38 to combine them with the results provided by statistics module 34. At this stage the probabilities calculated are for average players in an average game situation. Compensation module 40 may modify the probabilities. Further the probabilities will eventually be modified to provide for a commission to the house.

[0045] To further explain how a heuristics-based likelihood model may be enabled we refer now to Figure 5. Figure 5 is a deterministic decision tree of the logical steps of a play call model for a run. The tree shown in Figure 5 contains a record of expert knowledge. Figure 5 is a simplification of how the likelihood of a run play may be determined and serves simply as an example of how the logic for a likelihood model may be implemented. For simplicity we will refer only to the nodes in Figure 5 that result in the likelihood value shown as feature 70 of Figure 4, i.e. the next play will be a run. For this example the current game situation is: third down, nine yards to go, third quarter, tie game, on the fifty yard line. Beginning at node 90 the game time is determined, as it is in the third quarter processing moves to node 92. A test is made at node 94 to determine that the current down is the third and processing moves to node 96. At node 98 a test is made to determining how many yards are required to make the next down. Since there are nine yards to go, processing moves to node 100 and the likelihood value for the next play being a run is shown as feature 70.

[0046] We now refer to Figure 6, a block diagram of the logical functions of a fusion module. Fusion module 38 utilizes the results from statistics module 34 and heuristics module 36 and fuses them using a neural network 114 to provide odds on the outcome of a game event. As one skilled in the art will appreciate the use of neural network 114 is only one embodiment, any expert system that meets the needs required may be utilized in place of neural network 114.

[0047] Both statistics module 34 and heuristics module 36 provide odds on an event and have their own advantages. Statistics module 34 uses actual historical evidence and as such is strong when there is a presence of significant statistical evidence in a particular bin. However, when odds are required for a situation that rarely occurs, the statistical evidence in a discrete bin is often sparse or non-existent. As well, even in moderately populated bins, the bin's historical contents may not adequately describe all possible outcomes, as such, the probability of certain betting interests might incorrectly be calculated as zero. For both of these reasons, complementary data is provided from the heuristics module 36. The heuristics module 36 works well in that it applies general rules, which can cover all game situations using "expert knowledge". However, the odds provided are only as good as the expert writing the model. As such, it is always desirable to use the results of the statistics module 34 as much as possible when the historical evidence in that situation is available.

[0048] The fusion strategy described in Figure 6 calculates F_H (shown as feature 110) which is a heuristics model fusion factor and has a value between zero and one. The higher the F_H value, the more heuristics are relied upon in the overall calculation of hybrid odds and vice versa. Hybrid odds are calculated by summation module 112 and sent to compensation module 40. An expert system such as neural network 114 is used to calculate F_H.. In general, the more statistical evidence that is available, the lower the value of FH.

[0049] In calculating F_H, NN inputs module 120 accepts data from operations module 14, historical database 116 and transfer function module 124. Operations module 14 provides the current game state. Historical database 116 provides information on which of the statistics module 34 or heuristics module 36 has done a better job in predicting correct odds for the current game state.

[0050] To allow the neural network 114 to improve over time, the SIE database 42 produces a feedback loop to the neural network 114 via historical database 116. This allows the fusion module 36 to know how successfully the neural network 114 predicted the actual outcome in reality, and whether heuristics or statistics would have been better for predicting the outcome. In neural networks weights are assigned to each of the nodes. There are many algorithms for doing this; a common one is called the back propagation algorithm. The algorithm cycles through the collection of known inputs and desired outputs, and creates an optimal set of node weights. Periodically, after new historical data arrives in historical database 116 this algorithm will be run. Over time, the neural network 114 will become increasingly accurate at determining the correct value of F_H.

[0051] Transfer function 124 provides input to NN inputs module 120 on the number of statistics in a particular bin.

[0052] A neural network such as neural network 114 is a computing technique, which attempts to solve complex tasks in a way similar to the human brain. They are often used for tasks where there occur a large number of sample input values coupled with the desired output values, but there's no clear way of constructing a formula to translate future input values into the correct output values. There are a large variety of neural networks, but in general, they take in a set of inputs, which are then cross multiplied through a network of weighted nodes. The inputs provided by NN inputs 120 are accepted by multi-layer NN 122. The more sophisticated the problem, the more layers of nodes may be required to build a robust model. Nodes are weighted such that they multiply and sum to produce numerical values in each of the output nodes, which correspond to the likelihood of each output. In the present invention, the input nodes would represent information such as the game state, how many statistical samples are available for the game situation, and how well the model has historically predicted event results in this game situation. The input nodes then multiply through the network to produce a single output node, the F_H value shown as feature 110. This value represents how heavily the system should use heuristics versus the statistics. [0053] By way of example on how the components of Figure 6 interact we provide the following. The game state provided by operations module 14 indicates: (i) third down, (ii) nine yards to go, (iii) third quarter, (iv) tie game, and (v) on the fifty yard line. The information provided by transfer function 124 indicates there are eight hundred and forty samples in the bin corresponding to this game state. Historical database 116 indicates that the deviation from the actual outcome results for statistics module 34 was 11%, while heuristics module 36 had a deviation of 26%. After sum and multiply operations calculated by neural net 114 the value of F_H is determined to be 0.15, thus the system suggests to rely heavily on the values provided by statistics module 34. If the statistics module 34 indicated that the play call odds for a run are 0.39 and the heuristics module 36 had odds of 0.48, then summation module 112 calculates the odds for a run as: (0.85) x (0.39) + (0.15) x (0.48) for a total of 0.4035 as shown by features 126 and 128 respectively.

[0054] Referring now to Figure 7 a block diagram illustrating an example of the utilization of the compensation module 40 is shown. Compensation module 40 comprises a plurality of compensation models. One example is shown as wind compensation model 140. Fusion module 38 provides a number of odds for each wagering event. In the example shown, the odds are based on a "play call" event. Examples of other events may include "play result", "next penalty" or "next score".

[0055] As previously discussed with the example shown in Figure 4, the probabilities of a specific play call are provided. For example feature 84 indicates that the probability of a play call being a punt is shown as .02. In this example a test is first made at step 142 to determine if there is wind on the playing field. Should wind be in the range of 5-20 kilometres per hour as shown by feature 144 processing moves to step 146. At step 146 the probability of a play being a pass is multiplied by 1.10 and the probability of a play being a run is multiplied by 0.90. The output from compensation model 140 is then combined with additional compensation models 148. Ate step 148 the new odds are calculated and stored in SIE database 42. We will now briefly discuss other examples of compensation models 148. 1. A team tendencies model may use an analysis of the deviation of a team's play calling or play success from the league averages. This will provide a set of odds with bias toward a particular team's game play and strategic tendencies.

2. A player tendencies model may use an analysis of the deviation of a player's skill or tendencies from the league average. This will provide a set of odds with bias toward a particular player's game play and strategic tendencies. Making multiple transformations to account for several key players on the field (both offense and defense) will create a set of odds tailored to the on field personnel.

3. A weather factor model may be utilized to alter the odds based upon the on field conditions.

4. A stadium factor model may be utilized to alter the odds based upon an analysis of the stadium conditions. Examples of stadium conditions may include artificial turf versus grassy, field size (in the case of baseball), or prevailing winds.

[0056] Referring now to Figure 8 a block diagram illustrating the components utilized by an operations module is shown. In the embodiment shown, operations module 14 comprises game state consolidation module 180, conflict resolution module 182, current game state 184, wager module 186, result reporting module 188 and game state auto-advance module 190. Game state consolidation module 180 receives input from multiple sources as shown.

[0057] Event location 192 is the site where the event is being played and broadcast to operator station 194 and third party event logger 196. This broadcast would typically be in the form of a television broadcast 198. Game info 200 represents the source of the broadcast information for the event, which is sent to broadcast facility 198. Game state sensors 202 are sensors that may sense some aspect to the game state automatically. For instance they could be tied to an electronic line judge in a tennis match or a goal light in a hockey game. Game state sensors 202 allow for means to sense events without requiring an operator 206 to enter the information. Event results and situation details are sent by game state sensors 202 via network 204 such as the Internet to game state consolidation module 180. The same information is also sent to third party event logger 196 from broadcast facility 198 which in turn forwards the information in the form of event results and situation details via network 204 to game state consolidation module 180. Third party event logger 196 is an external source, which provides game state information, for example a fan website, a weather reporting website, or a sports cast. In some cases the information provided by third party event logger 196 will be very similar to that provided by operator 206. In other instances third party event logger 196 would not provide information as complete as that provided by operator 206 but rather partial real time information such as score changes, injury updates and weather information.

[0058] Operator station 194 also receives information from broadcast facility 198. Operator station 194 is managed by an operator 206 who views the broadcast on television 208 (or other electronic device) and through the use of rapid entry console 210 inputs event data for use by game state consolidation module 160. Operator 206 utilizes an interface on rapid entry console 202 to provide the results of each game event.

[0059] Game state consolidation module accepts information such as event results to create a current game state 184. A game state as its name implies, indicates the current state of the game. In the case of American football this would include information such as (i) which teams are playing, (ii) players are on the field, (iii) who has the ball, (iv) the current time, (v) the current down, (vi) yards to next down, (vii) position of the ball on the field, (viii) weather conditions, (ix) stadium in which the game is being played and other relevant information to aid in determining the odds and betting opportunities of the next game event.

[0060] Game state consolidation module 180 takes the game states provided by game state sensors 202, operator station 194 and third party event logger 196 to create a current game state 184. Current game state 184 may be modified by conflict resolution module 182. In the case of conflicting information on a current game state, a supervisor 212 will utilize a supervisory console 214 to provide input to conflict resolution module 182 to resolve conflicting game states, hi addition game state auto-advance module 190 may automatically provide input to game state consolidation module based on the last play. If for example the football was advanced five yards for a first down, it will automatically provide this information to game state consolidation module 180, thus providing another source of information in creating a game state 184.

[0061] Wager module 186 examines the current game state and determines what the relevant wagering opportunities are. For instance if the current game state is first down, ten yards to go on the fifty yard line it knows to offer a play call run or pass bet, or a play result being a touchdown or a first down, but not a punt return as a punt is not a relevant option for the current game state.

[0062] Result reporting module 188 provides information to SIE database 42 and integration module 16 on the outcome of an event which is inferred from the current game state 184 and used by integration module 16 to resolve wagers.

[0063] Referring now to Figure 9 a block diagram of the logical functions of the game state auto-advance module is shown. Game state auto-advance module 190 is used to update the game state based on the input from rapid entry console 210. Game state auto-advance module 190 reduces errors and reduces input time for operator 206. By way of example, say that the current game status is first down, with ten yards to go to the next down, on the twenty yard line. Further if the operator 206 enters that there was a five yard pass, then game auto- advance module 190 can determine that the game state should be updated to indicate the current down is the second, the ball is on the twenty five yard line and the yards to go is five. A decision tree can be utilized to update the game state automatically and provide suggested relevant wagering pools for betting.

[0064] Beginning at step 220 a game event is created. At step 222 the event commences. Al step 224 module 190 waits for the event to be resolved. This resolution is provided by game state consolidation module 180. At step 226 a test is made to determine if the event was indeed resolved by the play being completed or if the event is cancelled by for example time running out to complete the event.

[0065] If the event was resolved processing moves to step 228 and then to step 230. At step 230 an explicit update is made to updated game state 232 based upon the event result, for example a first down was made. At step 234 an inferred update is made to updated game state 232 based upon the event result, for example the current yard line. At step 236 natural next bets are calculated based upon the event result, for example for the point after attempt after a touchdown is scored. This information is then passed to step 238 where suggested wagers are then provided to rapid entry console 210.

[0066] Returning to step 226 if the event was cancelled, processing moves to step 240 and then directly to step 236. [0067] Rapid entry console 210 receives game status information from the updated game state 232 and suggested wagers 238 to provide input to operator 206 so that new events 220 may be created and the process continues.

[0068] Referring now to Figure 10 an example of flowchart for updating the game state is shown. Step 224 waits for an update of event status. When an update occurs, step 250 determines if a play was executed. If not control returns to step 224. If a play was executed a test is made at step 252 to determine if there was a turnover (i.e. the other team received the ball). If this is the case processing moves to step 254 where a flag is set to indicate that the other team now has the ball. Both steps 252 and 254 converge at step 256 where a test is made to determine if there was a score. If there was a score, the type of score is determined. We discuss only the example of a safety 258 which adds two points to the score of the team scoring the safety, this is done at step 260 and this information is provided to create updated game state 232.

[0069] Returning to step 256, if there was not a score a test is made at step 262 to determine if enough yards were gained to obtain a first down. If so, processing moves to step

264 where the down is set to one and the information provided to updated game state 232. If at step 262 a first down was not obtained, processing moves to step 266 where the current down is incremented by one. Processing then moves to step 268 where a test is made of the current down. In American football rules the team holding the ball has four downs to advance ten yards. If the current down is equal to five they have failed and team possession is switched at step 270. Both steps 268 and 270 convey the results of the event to updated game state 232.

[0070] Referring now to Figure 11 a block diagram of the logical functions of the conflict resolution module is shown. Conflict resolution module 182 resolves discrepancies that may exist between input sources such as rapid entry consoles 210, third party event loggers 196 or game state sensors 202. Discrepancies could be one of two types.

[0071] Type 1 are timing conflicts, and these are easy to deal with. For instance, if and operator 206 enters into rapid entry console 210 that the event lock out (the time after which no new bets are allowed) was 12:00:00, and a third party event logger 196 said it was 12:00:01, then to error on the side of caution the earlier time is chosen. Simple rules may be used to determine in each type of scenario whether to choose the earliest of the time stamps, the later of the time stamps, or to select an average of them. This update is handled by timing conflict resolution module 286, which updates the current game state 184 through conflict identification module 282.

[0072] Type 2 conflicts are game state conflicts, and are a little more difficult to deal with. For instance, if an operator 206 says it was a first down, but a game sensor 202 said it was a next down, then there is no simple or automated way to determine which is right. In this case supervisor 212 through the use of supervisory console 214 relies on logged video evidence to determine what the actual event result was. The logged video is stored in broadcast database 280. This process is partially automated as follows:

1) Conflict identification module 282 determines that the game state 184 is showing a discrepancy of type 2.

2) The time window of the relevant event is determined.

3) Game state conflict resolution module 284 requests a video stream from the broadcast database 280 for the time period around the event plus or minus x seconds. The Broadcast database 280 maintains a sliding buffer of the last several minutes of broadcast data for all events being supported.

3) Supervisory console 214 alerts the supervisor 212 that a conflict requires investigation and presents the supervisor 212 with the video stream and the discrepancy information. Upon investigation, the supervisor 212 determines the correct game state and updates current game state 184 via the conflict identification module 202. [0073] Referring now to Figure 12 a block diagram illustrating the components used by the integration module 16 is shown. Integration module 16 comprises three main components, fact server 290, fact database 292 and audit server 294.

[0074] Wager options/odds are received from operations module 14 and stored into fact database 292 by fact server 290. Module 296 receives the wager options/odds from operations module 14 and passes them to module 298, which updates the fact database 292.

[0075] The fact database 292 controls the pool lifecycle when appropriate timing signals are received from the fact server 290 of integration module 16. A number of tables are stored in fact database 292 and we will discuss each in turn. Stored procedures interface table 310 contains context lifecycle operations 312 and pool lifecycle operations 314. [0076] The fact database 292 stores facts such as game state information, time stamps and event outcomes. Context lifecycle operations 312 is a virtual container in which betting events and the amounts placed on those betting events is grouped. A context lifecycle consists of three steps, (i) creation, (ii) activation and (iii) deactivation. If a context is active a user may bet on an event. Once deactivation occurs no bets are permitted. This information is used to determine the change in odds based upon betting activity.

[0077] Pool lifecycle operations 314 are methods controlling among other features: betting windows, performing lockouts, and rolling back retroactive lockouts. Progression of a pool from one state to another is controlled by these methods. [0078] One or more Context tables 316 each comprise one or more pool tables 318. A pool table 318 contains information on a specific betting pool. Betting interest 320 tracks a specific pool such as "play call run - initial odds 1.49". Pool lifecycle history 322 tracks the status of a pool from creation to closure such as timing information as the state of a pool changes. [0079] The active betting pools 318, which include information on initial odds, results and timing signals are then broadcast by module 300 via network 20a to portal module 18. Although only one portal module 18 is shown there may be multiple instances. Each participating portal module 18 is then responsible for rebalancing the odds within their own pools and implementing the actual wager lock out processes indicated by the pool lifecycle (see Figure 13). The audit server 294 receives aggregate betting activity from each portal module 18 via network 20c. The audit server 294 audits and monitors the aggregate activity of each portal module 18 to ensure they are properly billed. The aggregate betting activity is received by the transaction logging module 302. Reconciliation module 304 then reconciles the records by user for the purpose of auditing and invoicing, and stores them in the audit database 306. Reporting module accesses audit database 306 so that reports may be prepared for the administrators of operations module 14.

[0080] Referring now to Figure 13 a block diagram illustrating the steps of a betting pool lifecycle is shown. Figure 13 shows the transition of a betting pool from time of creation to time of closeout and payout to winners. The operations module 14 identifies the appropriate timing signals for each transition in the lifecycle; the fact server 290 of integration module 16 stores records of these. [0081] A pool is created at step 350 to support betting on a particular event. Pool creation includes creation of at least two betting interests 352, corresponding to the possible outcomes of the event. Nominal payout rates for each betting interest 352 are set by the SIE module 12. The nominal payout rates are also the starting rates with fixed payout calculation; in pari- mutuel payout calculation, nominal payout rates are only used as a guide to the end user and as a seed to the pari-mutuel process.

[0082] Pools are unavailable for betting (invisible) until opened. Once opened as shown at step 354, a pool and its betting interests are presented to users and bets may be placed as shown at step 356. The payout rate for each outcome may remain fixed over the lifecycle of the pool (pool-fixed payout); the rates may remain fixed over the lifecycle of each particular placed bet, but change from bet to bet over time (bet-fixed payout); or the rate for each bet may remain completely undecided until after the pool closes (pure pari-mutuel).

[0083] Pools remain open indefinitely, until locked by the operations module 14. Bets may be placed until the instant the pool is locked, but any late bets 360 made within the configurable blackout period 358 prior to lock time are rejected.

[0084] No further bets may be placed once the pool has been locked as shown at step 362. Because lock time occurs at an unpredictable time, based on real world events unfolding, bets falling within the blackout period 358 are only conclusively determined and rejected after the pool has been locked. [0085] Sometime after the pool has been locked at step 362, the event will conclude and the actual outcome will become known. When the winning betting interest is specified, the pool is closed at step 366 and all bets in the pool are resolved at step 368. Bet resolution depends on whether a pari-mutuel or fixed-payout methodology is used.

[0086] Users are granted a fixed period of time (e.g. 24 hours) to dispute the outcome of the pool, during which the pool remains closed. Gains and losses are reported, but gains are unavailable for cash out during this period. Gains may be used to participate in further betting during this period.

[0087] After the reasonable period for protesting the pool outcome has elapsed, the pool is finally frozen at step 370 and all wins and losses are made final. All gains from the pool are made available for cash out. [0088] Referring now to Figure 14 a block diagram illustrating the components used by the portal module 18 is shown. Portal module 18 comprises two main components, portal wεiger processing server 380 and web server 382. Portal wager processing server 380 accepts real time wager information from fact server 290 of integration module 16 via network 20a. Portal wagering server 380 also reports the results of bets to integration module 16 via network 20c. Web server 382 interacts with one or more users 22 through the use of user interface 384 and network 20b.

[0089] A user 22 places a bet through the use of user interface 384 and the bet is stored in portal database 386 by module 392. The bet is also passed to module 394 where payout rates are adjusted as necessary to maintain a balanced betting pool. Any adjustments are provided to module 396, which maintains a dynamic cache on the current odds and payout rates for each pool. This dynamic information is provided to user interface 384 via webservice interface 390 by module 396. Module 398 tracks information on betting events provided by fact server 290 of integration module 16 and in turn propagates this information to module 396 and portal database 386. Once a pool has closed module 400 resolves the payouts for each bet and communicates this information to both integration module 16 and portal database 386. In addition bet payouts are communicated to module 396 which in turn informs users 22 via webs service interface 390 of the outcome. Module 402 sends audit information on closed pools to integration module 16 via network 20c from information it extracts from portal database 386. This information may include (i) number of bets placed in each pool, (ii) amounts of bets, (iii) payouts made, (iv) the number of users, and other relevant data for auditing purposes.

[0090] Web server 382 comprises two interfaces, dynamically generated HTML interface 388 and web service interface 390, either of which may interact with a user interface 384. User interface 384 can take on many forms depending upon the type of device being used by user 22. For example, if the user interface 384 makes use of a web browser or a mobile browser then it will connect to interface 388. In another embodiment user interface 384 may make use of a standalone client such as a program that runs on the computing device of the user that does not make use of web based languages that generate HTML. In this case a connection would be made to interface 390. [0091] Referring now to Figure 15, a block diagram of the structure of the portal database 386 is shown. Portal database 386 controls the pool lifecycle when appropriate timing signals are received from the fact server 290 of integration module 16. A number of tables are stored in portal database 386 and we will discuss each in turn. Stored procedures interface table 420 contains context lifecycle operations 422, pool lifecycle operations 424, bet lifecycle operations 426 and user management information 428. [0092] Context lifecycle operations 422 is a virtual container in which betting events and the amounts placed on those betting events is grouped. A context lifecycle consists of three steps, (i) creation, (ii) activation and (iii) deactivation. If a context is active a user may bet on an event. Once deactivation occurs no bets are permitted. This information is used to determine the change in odds based upon betting activity. [0093] Pool lifecycle operations 424 are methods controlling among other features: betting windows, performing lockouts, and rolling back retroactive lockouts. Progression of a pool from one state to another is controlled by these methods. Bet lifecycle operations 426 are methods that control the betting records. These methods handle the submission of a bet from a user and track the consequences of a bet until the event has been resolved. For example the progression of an individual bet from one state to another such as a pending request to bet, an approved or rejected bet, a confirmed bet and a resolved bet is handled by bet lifecycle operations 426.

[0094] User management 428 provides methods to allow information stored in user table 438 to be updated. User table 438 contains information on each user who has placed a bet. [0095] One or more Context tables 430 each comprise one or more pool tables 432. A pool table 432 contains information on a specific betting pool. Betting interest 434 tracks a specific pool such as "play call run - odds 1.49". Pool lifecycle history 436 tracks the status of a pool from creation to closure such as timing information as the state of a pool changes.

[0096] Bet table 440 contains information on each type of bet placed such as (i) the user, (ii) the event they bet on, (iii) the time of the bet, and (iv) the amount wagered. Bet history table 442 contains the betting history for all bets in portal database 386.

[0097] Referring now to Figure 16 an example of a graphical user interface for a user is shown. Any number of styles of user interfaces may be utilized by the present invention, the example shown in Figure 16 is merely meant to illustrate the types of information that may be displayed. Feature 450 indicates the current account balance for the user. Feature 452 indicates available wager categories such as play call, play result, next score and feature player. Feature 454 indicates the available odds and wagers for the play category chosen. Feature 456 indicates pending wagers and feature 458 indicates resolved wagers. Feature 460 indicates game details in a Scoreboard like format. Feature 462 indicates other games that may be bet on. Feature 464 indicates the amount of the current wager, in this case five dollars. Feature 466 indicates a tournament view, i.e. how the user is doing relative to other bettors. Feature 468 indicates a head to head view, i.e. how the user is doing relative to a single bettor in a head to head competition.

[0098] Referring now to Figure 17 a block diagram illustrating the steps of raked pari- mutuel wagering is shown. The following terms will be used in describing the example of raked pari-mutuel wagering flow.

1) All accounting is done in integer quantities of the minimum currency increment ι_c. By definition, i_c is always normalized to 1 and one increment of /_c is one credit.

2) Stakes are placed in integer quantities of the stake increment i_s. 3) Payouts are made in integer quantities of the payout increment i_p.

4) is ≥ ip ≥ ic For example: i_c: $0.01 (= 1), i_p: $0.10 (= 10), ι_s: $1.00 (= 100)

5) Pool X consists of N offered betting interests {xi, X2, .», X_N)- A single betting interest X_n is identified as the winner when the pool is closed.

[0099] Beginning at step 480 a rake rate k is assigned by portal supervisor 482 through the used of supervisory console 484. The rake rate k determines what portion of the total sums bet in a pool will be retained by the house. The supervisor 482 monitors suggested wagers via supervisory console 484 and may override them. In essence the supervisor 482 monitors all suggested wagers before they are sent to integration module 16. For example the supervisor

482 may determine that the outcome of a play is obvious to one knowledgeable of the game given the current game state and may delete the option to wager. A supervisor 482 may provide other input such as manually overriding the odds to be offered.

[00100] At step 486 nominal probabilities {pi, />2, »., PN) of a given betting interest being the exclusive winner in a wager category are calculated by fact server 290. From this nominal payout rates /#^•/, 1*2, ..., rrf are calculated as r_n = 1 1 p_n. [00101] At step 488 users 22 are provided with odds and place bets. Stakes {s_\, S₂, ..., s^j are placed on available betting interests (s_n is the total of all individual bets 6, placed on X_n). Total of stakes in a pool are S_T — s i + Si + ... + S_N. Users are provided with odds and pay out rates continuously by step 488 while the betting pool is open

[00102] At step 490 payout rates are calculated once the betting pool has closed. A number of different actual payout rates may be calculated for example: 1 ) Actual payout rate (continuous-simple) a_n = sτl S_n.

2) Actual payout rate (continuous-raked) a_n = (1 - k) ^• S_T I S_n.

3) Actual payout rate (discrete-raked) a_n = max(l, floor[(l - k) ^• (i_s I i_p) ^• S_T I S_n])

[00103] This expresses the discrete-raked actual payout rate as an integer number of payout increments i_p paid per stake increment i_s to the winners of the pool. The actual payout is not permitted to be less than one. Further, the payout rate is undefined where S_n = 0.

[00104] At step 492 the pool is closed and processing moves to step 494 where the payouts are distributed to the users 22. The total actual payout is aγ = a_n ^• S_n. Payout to a given winning bet b_t is M>,- = b_t ^• a_n. Total house retained rake K_T = S_T - flr- A record of the payouts made is provided to audit server 294. [00105] Referring now to Figure 18 a diagram illustrating an example of a cascaded pari- mutuel betting model is shown. Figure 18 illustrates how a cascaded pari-mutuel model works by dividing a joint wager into multiple fractional base pool wagers. The formula is explained more completely in Figure 19. Basically, cascaded pari-mutuel allows bettors to wager at any level of resolution, i.e.any level of detail in their bet. However, at high levels of details (e.g. "a pass to the running back for 20+ yards") there may not be a densely populated base pool. As such, the payout may not be appropriate for the significant risk being taken. To handle this, cascaded pari-mutuel allows sparsely populated joint wager pools to be broken into their parent base pools via fractional wagers. To ensure the bettor is given an incentive to make it a joint wager instead of two independent base pool wagers, the joint wager is given credit for more than was actually wagered. This is a portal customizable setting called the joint factor. A joint factor of 1.3 means for every fractional wager of $1, the bettor will be given credit in the pool of $1.30. The non-existent credit dollars are in essence taken from the base pool.

[00106] There are two types of pools shown in Figure 18, a play call pool 500 and a feature plaiyer pool 502. Groups of users 22a to 22e may make bets in these pools. Feature 504 indicates that users 22a have bet a total of $6,000 that the next play will be a run and a total of $9,000 that the next pay will be a pass. Feature 506 indicates that users 22e have bet a total of $4,000 that the next player will be a running back (RB), $8,000 that the next player will be a wide receiver (WR), and $1 ,500 that the next player will be a tight end (TE).

[00107] An additional set of users 22b to 22d have placed joint wagers. Feature 508 indicates that $400 was bet on the next play being a pass to a running back. Feature 510 indicates that $500 was bet on the next play being a pass to a wide receiver. Feature 510 indicates that $500 was bet on the next play being a run by a running back. Each of the bets placed as shown by features 508, 510 and 512 is split in half. Thus the bets indicated in feature 508 are split into the bets shown in features 514 and 516. The same is shown for bets indicated by features 510 and 512.

[00108] The results of these betting patterns are shown within the features play call pool 500 and feature player pool 502. In the case of pool 500 a total of $6,050 has been bet on a run and a total of $9,450 has been bet on a pass. In the case of pool 502, bets on the running back total $4,250, bets on the wide receiver total $8,250 and bets on the tight end total $1,500. Both pools 500 and 502 have a rake of 0.15 and a joint factor of 1.30.

[00109] Referring now to Figure 19 a block diagram illustrating the steps of cascaded pari- mutuel wagering is shown.

[00110] Beginning at step 510 pool is assigned a rake rate k, joint factor /, and Joint threshold t, by portal supervisor 482 through the used of supervisory console 484. [00111] At step 512 nominal base pool probabilities {pb,_b />b,2_> —* Pbjι} of a given betting interest 'n' being the exclusive winner in a pool 'b' are calculated by fact server 290 for each of the betting base pools. Nominal payout rates /rb,i, /tø, ..., /tyv/ are calculated as T_b,_n — 1 /

Pb,n-

[00112] At step 514 stakes on betting interest 'n' in base pool 'b' are represented as S_b,_n which is the total of all individual bets b_t placed on interest Xb,_n- The value of S_b,_n =X_b,_{n +} Y_b,_{n +} Zb,_n where X, Y, Z represent the three sources for stakes on a particular interest in a base pool. The value X^_Λ represents wagers entered directly into a base pool. The value Y^_n represents fractional joint wagers placed into the base pool and resolve to be incorrect across all tied joint interests. The total of stakes in the pool is represented by S_b,τ = *_b,i ⁺ Sba + •» + S_b,_N' [00113] At step 516, odds zj,_« for the correct joint wagers Z_b,_n are calculated, applying the joint factor/ to give them additional credit to correspond to the increased risk of their wager. Next, odds XM for the direct base pool wagers are calculated. This is done by calculating the odds normally, after first removing the payouts to the correct joint wagers from the pool of winnings to be paid out. The following formulas are utilized:

ZM = (Sb, T I s_b,_n ) ^• (1-k) ^• /

XM = ((s_b,τ ' [1-k] ) - (z_M -Z_M )) / (XM)

[00114] This method is implemented to accommodate sparsely populated joint- wager spaces. A threshold calculation should be made in which if (st_>,τ - Xb,τ)>t, then the joint- wagers are broken into a separate base pool. If no joint wagers are correct across all dependant joins, then all winnings in the base pool are divided up solely amongst the direct base pool winners (as indicated by the formula). As shown above, the true payout odds for direct base pool bettors is not possible to calculate until all outcomes are resolved and it can be determined if any joint wagers were correct. As such, prior to event resolution, the minimum of all possible X_b,_n values should be displayed to the users. As such, after resolution the odds X_b,_n displayed to those users will either remain constant, or increase slightly.

[00115] At step 518 the pool is closed and processing moves to step 520 where the payouts are distributed to the users 22. The total actual payout is (ZM^ (Zb,n) + (Kb,n)(x_b,η)- The winning direct pool bet wi = bι' Xb,n- The wining joint pool bet is wi = bf Z_b,_n- Where A,- is the fractional portion of the total bet that was placed in the joint pool.

[00116] The above disclosure has provided examples of pari-mutuel and cascaded pari- mutuel betting pools.. The term cascaded wagering refers to a general method that can be applied to any odds calculation scheme, for example pari-mutuel, fixed odds, or rebalanced fixed odds. Cascaded wagering allows betting to be parlayed across multiple pools and for a bettor to wager to an arbitrary level of detail.

[00117] Static fixed odds simply uses the initial nominal odds and maintains those throughout the betting window. In balanced fixed odds, the system uses any number of the well known rebalancing algorithms which attempt to look at book imbalance periodically through out the betting window. Typically the odds are given to a user and kept stable for 'X' seconds. After 'X' seconds if the user has not placed a bet, then the odds are updated via the rebalancing algorithm. This ensures that the house's exposure can be limited when betting distribution is not in match with the initial odds.

[00118] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

WE CLAIM:

1. A method for permitting a user to wager on the outcome of an event while said event is in progress, said method comprising the steps of: presenting to said user said event, as well as odds and projected payouts of said event based upon combining heuristics and statistics; accepting a wager from said user on said outcome; updating said odds and projected payouts on said event while said event is in progress and providing the results of said updating to said user; and upon the completion of said event informing said user of said outcome and reconciling the account of said user based upon said outcome.

2. The method of claim 1 further comprising the step of in addition to said combining, utilizing compensation to adjust said odds and projected payouts.

3. The method of claim 2 wherein said utilizing compensation utilizes environmental conditions.

4. The method of claim 2 wherein said utilizing compensation utilizes information on players in the event.

5. The method of claim 1 wherein prior to presenting to said user, said event is approved by a supervisor.

6. The method of claim 1 wherein said combining utilizes an expert system for calculating said odds, said expert system utilizing feedback from the outcome of previous events to aid in calculating said odds.

7. The method of claim 1 further comprising the step of determining a game state based upon information received from a plurality of sources.

8. The method of claim 7 further comprising the step of providing conflict resolution to resolve said game state.

9. The method of claim 7 further comprising the step of automatically advancing a game støte.

5 10. The method of claim 1 further comprising the step of permitting said user to wager upon said event in a cascaded wagering pool.

11. The method of claim 1 further comprising the step of communicating with said user via an Internet equipped device.

10

12. The method of claim 1 further comprising the step of allowing a supervisor to modify the odds for the outcome of an event.

13. A system for permitting a user to wager on the outcome of an event while said event is 15 in progress, said system comprising: means for presenting to said user said event, as well as odds and project payouts of said event based upon combing heuristics and statistics; means for accepting a wager from said user on said outcome; means for updating said odds and projected payouts on said event while said event is in 20 progress and providing the results of said updating to said user; and means for upon the completion of said event informing said user of said outcome and means for reconciling the account of said user based upon said outcome.

14. The system of claim 13 further comprising means for utilizing compensation to adjust 25 said odds and projected payouts.

15. The system of claim 14 wherein said means for utilizing compensation utilizes environmental conditions.

30 16. The system of claim 14 wherein said means for utilization compensation utilizes information on players in the event.

17. The system of claim 13 further comprising means for a supervisor to approve said event for presentation to said user..

18. The system of claim 13 wherein said combining comprises an expert system for 5 calculating said odds, said expert system utilizing feedback from the outcome of previous events to aid in calculating said odds.

19. The system of claim 13 further comprising means for determining a game state based upon information received from a plurality of sources.

10

20. The system of claim 19 further comprising means for providing conflict resolution to resolve said game state.

21. The system of claim 19 further comprising means for automatically advancing a game 15 state.

22. The system of claim 13 further comprising means for permitting said user to wager upon said event in a cascaded wagering pool.

20 23. The system of claim 13 further comprising means for communicating with said user via an Internet equipped device.

24. The system of claim 13 further comprising means for allowing a supervisor to modify the odds for the outcome of an event.

25

25. A computer readable medium comprising instructions for the execution of the steps of claim 1.