WO2007118300A1 - Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct - Google Patents

Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct Download PDF

Info

Publication number
WO2007118300A1
WO2007118300A1 PCT/CA2006/000633 CA2006000633W WO2007118300A1 WO 2007118300 A1 WO2007118300 A1 WO 2007118300A1 CA 2006000633 W CA2006000633 W CA 2006000633W WO 2007118300 A1 WO2007118300 A1 WO 2007118300A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
odds
user
outcome
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CA2006/000633
Other languages
English (en)
Inventor
Jean Paul Dupuis
David Bullock
Jean-Pierre Bhavnani
Robert Riopelle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to PCT/CA2006/000633 priority Critical patent/WO2007118300A1/fr
Publication of WO2007118300A1 publication Critical patent/WO2007118300A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/34—Betting or bookmaking, e.g. Internet betting
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/32—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for games, toys, sports, or amusements
    • G07F17/3286—Type of games
    • G07F17/3288—Betting, e.g. on live events, bookmaking

Definitions

  • 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?"
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 1 is an block diagram of a system implementing NanoGaming
  • Figure 2 is a block diagram of the components of the SIE Module
  • Figure 3 is a flowchart illustrating the loading of information into the statistical database
  • Figure 4 is a logical flow diagram of a likelihood model
  • Figure 5 is a deterministic decision tree of the logical steps of a play call model for a inn
  • Figure 6 is a block diagram of the logical functions of a fusion module
  • Figure 7 a block diagram illustrating an example of the utilization of a compensation module
  • Figure 8 is a block diagram illustrating the components utilized by an operations module
  • Figure 9 is a block diagram of the logical functions of a game state auto-advance module;
  • Figure 10 is an example of flowchart for updating the game state;
  • Figure 11 is a block diagram of the logical functions of a conflict resolution module
  • Figure 12 is a block diagram illustrating the components used by the integration module;
  • Figure 13 is a block diagram illustrating the steps of a betting pool lifecycle;
  • Figure 14 is a block diagram illustrating the components used by the portal module;
  • Figure 15 is a block diagram of the structure of the portal database;
  • Figure 16 is an example of a graphical user interface for a user
  • Figure 17 is a block diagram illustrating the steps of raked pari-mutuel wagering
  • Figure 18 is diagram illustrating an example of a cascaded pari-mutuel betting model
  • Figure 19 is a block diagram illustrating the steps of cascaded pari-mutuel wagering.
  • 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.
  • SIE Situational Intelligence Engine
  • operations module 14 operations module 14
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PDA Personal Digital Assistant
  • 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.
  • 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.
  • 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.
  • 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.
  • the game is essentially "wager for free" and may be used in skill-gaming tournaments or competitions.
  • 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.
  • FIG. 3 a flow chart illustrating the loading of information into statistical database 30 is shown.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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”.
  • 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
  • FIG. 4 a logical flow diagram of a likelihood model is shown.
  • 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.
  • factors to be considered may include the current down, the number of yards to go, position of the ball and current game time.
  • 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.
  • 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.
  • 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.
  • the current game situation is: third down, nine yards to go, third quarter, tie game, on the fifty yard line.
  • 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.
  • 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.
  • 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.
  • neural network 114 is only one embodiment, any expert system that meets the needs required may be utilized in place of neural network 114.
  • 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.
  • 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.
  • 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.
  • F H shown as feature 110
  • 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.
  • 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.
  • the SIE database 42 produces a feedback loop to the neural network 114 via historical database 116.
  • 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 .
  • Transfer function 124 provides input to NN inputs module 120 on the number of statistics in a particular bin.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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”.
  • the probabilities of a specific play call are provided.
  • feature 84 indicates that the probability of a play call being a punt is shown as .02.
  • 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.
  • 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.
  • the new odds are calculated and stored in SIE database 42.
  • 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.
  • 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.
  • a weather factor model may be utilized to alter the odds based upon the on field conditions.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a game event is created.
  • 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.
  • 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.
  • step 230 If the event was resolved processing moves to step 228 and then to step 230.
  • step 230 an explicit update is made to updated game state 232 based upon the event result, for example a first down was made.
  • step 234 an inferred update is made to updated game state 232 based upon the event result, for example the current yard line.
  • 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.
  • 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.
  • Step 224 waits for an update of event status.
  • 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.
  • 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.
  • 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 256
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • Integration module 16 comprises three main components, fact server 290, fact database 292 and audit server 294.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • Stored procedures interface table 420 contains context lifecycle operations 422, pool lifecycle operations 424, bet lifecycle operations 426 and user management information 428.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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
  • a 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.
  • users 22 are provided with odds and place bets. Stakes ⁇ s ⁇ , S 2 , ..., 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
  • payout rates are calculated once the betting pool has closed.
  • step 492 the pool is closed and processing moves to step 494 where the payouts are distributed to the users 22.
  • Total house retained rake K T S T - flr-
  • a record of the payouts made is provided to audit server 294.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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 /
  • 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 -
  • S b , n X b , n + Y b , n + Zb, n
  • 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.
  • 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).
  • 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.
  • 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.
  • 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-
  • 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.
  • Static fixed odds simply uses the initial nominal odds and maintains those throughout the betting window.
  • the system uses any number of the well known rebalancing algorithms which attempt to look at book imbalance periodically through out the betting window.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention offre la possibilité de parier, par l'intermédiaire d'un réseau tel que l'Internet, sur le résultat d'événements discrets se déroulant dans le cadre d'une compétition sportive. Plusieurs modules se combinent pour produire des cotes pour chaque événement et fournir en temps réel les cotes à des utilisateurs par l'intermédiaire d'un réseau. Pour la détermination des cotes, des procédés à la fois statistiques et heuristiques sont utilisés, les résultats étant combinés et ensuite soumis à une transformation basée sur un certain nombre de modèles. Après réception des cotes, un utilisateur peut alors placer un ou plusieurs paris qui sont départagés à la fin de l'événement. De multiples sources d'états d'événement sont analysées. Un processus de réconciliation est utilisé en cas d'états d'événements conflictuels. Les résultats d'un événement sont stockés et utilisés dans un processus de rétroaction pour aider à prévoir les cotes pour des événements similaires futurs. De multiples formes de paris sont prises en charge, notamment des variantes du modèle de pari mutuel standard.
PCT/CA2006/000633 2006-04-19 2006-04-19 Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct Ceased WO2007118300A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CA2006/000633 WO2007118300A1 (fr) 2006-04-19 2006-04-19 Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CA2006/000633 WO2007118300A1 (fr) 2006-04-19 2006-04-19 Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct

Publications (1)

Publication Number Publication Date
WO2007118300A1 true WO2007118300A1 (fr) 2007-10-25

Family

ID=38608988

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CA2006/000633 Ceased WO2007118300A1 (fr) 2006-04-19 2006-04-19 Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct

Country Status (1)

Country Link
WO (1) WO2007118300A1 (fr)

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2459938A (en) * 2008-05-16 2009-11-18 Inspired Gaming Gaming terminal with display areas relating to wagers
WO2012088540A1 (fr) * 2010-12-23 2012-06-28 Hopf Patrick Système et procédé pour un divertissement interactif en temps réel
WO2014071496A1 (fr) * 2012-11-06 2014-05-15 Garden City Software Corp. Procédé et système permettant de réaliser des paris interactifs hors-table sur des jeux
WO2014121208A1 (fr) * 2013-02-01 2014-08-07 Contagious Sports Ltd. Systèmes et procédés de jeu de pari pour des événements sportifs en direct
US20150339794A1 (en) * 2008-02-11 2015-11-26 Popular Metrics, Inc. Internet based system and method for wagering on an artist
US9881042B2 (en) 2008-02-11 2018-01-30 Popular Metrics, Inc. Internet based method and system for ranking individuals using a popularity profile
US9888361B2 (en) 2008-02-11 2018-02-06 Popular Metrics, Inc. System and method for determining characteristics of a plurality of people at an event based on mobile phone tracking and mobile data transmission
US20190251794A1 (en) * 2017-06-13 2019-08-15 Burton Simon Live-Event Betting System Having Strategic Bets Placed by the House
US10580259B2 (en) 2017-12-13 2020-03-03 Novomatic Ag Systems, methods and gaming machines having logic based on sporting events
WO2020076657A1 (fr) 2018-10-08 2020-04-16 Winview, Inc. Procédé et systèmes pour réduire le risque de de fixer une cote pour des propositions en cours de jeu fixes uniques au moyen d'une entrée en temps réel
US20210217126A1 (en) * 2018-06-18 2021-07-15 Tal Hayon Smart-venue wagering system and method for live events
US11183010B2 (en) 2019-04-10 2021-11-23 The Action Network, Inc. Secure bet synchronization and betting analytics
WO2022115771A1 (fr) * 2020-11-30 2022-06-02 Adrenalineip Procédé pour des changements basés sur l'intelligence artificielle reposant sur des écarts par rapport à des prédictions
WO2022119889A1 (fr) * 2020-12-01 2022-06-09 Adrenaline Ip Procédés, systèmes et appareils pour générer et permettre des opportunités de jeu
US11361627B1 (en) 2020-12-01 2022-06-14 Adrenalineip Method of verifying that a wager was placed before market close
CN115280385A (zh) * 2019-06-14 2022-11-01 阿顿艾林艾普 用于互动体育游戏的方法，系统及计算机程序
US11615676B2 (en) 2017-12-22 2023-03-28 Adrenalineip Method, system, and computer program product for interactive sports game
CN115867952A (zh) * 2020-01-09 2023-03-28 阿德伦纳林Ip公司 人工智能和机器学习增强的概率预测方法、系统和设备
US11625980B2 (en) 2017-12-22 2023-04-11 Adrenalineip Method, system, and computer program product for interactive sports game
US12017130B2 (en) 2006-01-10 2024-06-25 Winview Ip Holdings, Llc Method of and system for conducting multiple contests of skill with a single performance
US12183165B2 (en) 2017-12-22 2024-12-31 Adrenalineip Method, system, and computer program product for interactive sports game
US12267566B2 (en) 2005-06-20 2025-04-01 Winview Ip Holdings, Llc Method of and system for managing client resources and assets for activities on computing devices
US12342048B2 (en) 2006-04-12 2025-06-24 Winview Ip Holdings, Llc Methodology for equalizing systemic latencies in television reception in connection with games of skill played in connection with live television programming
EP4505390A4 (fr) * 2022-04-08 2026-04-08 Adrenalineip Appareil, système et procédé d'affichage d'informations d'événement en direct

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5795226A (en) * 1996-08-05 1998-08-18 Yi; Chen Betting race game
US5823872A (en) * 1996-09-18 1998-10-20 Chicago Casino Systems, Inc. Simulated racing game
US6126543A (en) * 1998-01-08 2000-10-03 Innovative Gaming Systems Ltd Method for wagering on combined point spreads from multiple contests
WO2002024675A1 (fr) * 2000-09-13 2002-03-28 Biocon India Limited Procede de fabrication de simvastatine et nouveaux intermediaires
US20050227757A1 (en) * 2001-01-23 2005-10-13 Burt Simon Multi-person games for parimutuel betting on live events

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5795226A (en) * 1996-08-05 1998-08-18 Yi; Chen Betting race game
US5823872A (en) * 1996-09-18 1998-10-20 Chicago Casino Systems, Inc. Simulated racing game
US6126543A (en) * 1998-01-08 2000-10-03 Innovative Gaming Systems Ltd Method for wagering on combined point spreads from multiple contests
WO2002024675A1 (fr) * 2000-09-13 2002-03-28 Biocon India Limited Procede de fabrication de simvastatine et nouveaux intermediaires
US20050227757A1 (en) * 2001-01-23 2005-10-13 Burt Simon Multi-person games for parimutuel betting on live events

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12549827B2 (en) 2005-06-20 2026-02-10 Winview Ip Holdings, Llc Method of and system for managing client resources and assets for activities on computing devices
US12267566B2 (en) 2005-06-20 2025-04-01 Winview Ip Holdings, Llc Method of and system for managing client resources and assets for activities on computing devices
US12017130B2 (en) 2006-01-10 2024-06-25 Winview Ip Holdings, Llc Method of and system for conducting multiple contests of skill with a single performance
US12342048B2 (en) 2006-04-12 2025-06-24 Winview Ip Holdings, Llc Methodology for equalizing systemic latencies in television reception in connection with games of skill played in connection with live television programming
US20150339794A1 (en) * 2008-02-11 2015-11-26 Popular Metrics, Inc. Internet based system and method for wagering on an artist
US9760963B2 (en) * 2008-02-11 2017-09-12 Popular Metrics, Inc. Internet based system and method for wagering on an artist
US9881042B2 (en) 2008-02-11 2018-01-30 Popular Metrics, Inc. Internet based method and system for ranking individuals using a popularity profile
US9888361B2 (en) 2008-02-11 2018-02-06 Popular Metrics, Inc. System and method for determining characteristics of a plurality of people at an event based on mobile phone tracking and mobile data transmission
GB2459938A (en) * 2008-05-16 2009-11-18 Inspired Gaming Gaming terminal with display areas relating to wagers
WO2012088540A1 (fr) * 2010-12-23 2012-06-28 Hopf Patrick Système et procédé pour un divertissement interactif en temps réel
WO2014071496A1 (fr) * 2012-11-06 2014-05-15 Garden City Software Corp. Procédé et système permettant de réaliser des paris interactifs hors-table sur des jeux
WO2014121208A1 (fr) * 2013-02-01 2014-08-07 Contagious Sports Ltd. Systèmes et procédés de jeu de pari pour des événements sportifs en direct
US20190251794A1 (en) * 2017-06-13 2019-08-15 Burton Simon Live-Event Betting System Having Strategic Bets Placed by the House
US10580259B2 (en) 2017-12-13 2020-03-03 Novomatic Ag Systems, methods and gaming machines having logic based on sporting events
US11373484B2 (en) 2017-12-13 2022-06-28 Novomatic Ag Systems, methods and gaming machines having logic based on sporting events
US12223807B2 (en) 2017-12-22 2025-02-11 Adrenalineip Method, system, and computer program product for interactive sports game
US12230102B2 (en) 2017-12-22 2025-02-18 Adrenalineip Method, system, and computer program product for interactive sports game
US11615676B2 (en) 2017-12-22 2023-03-28 Adrenalineip Method, system, and computer program product for interactive sports game
US11625980B2 (en) 2017-12-22 2023-04-11 Adrenalineip Method, system, and computer program product for interactive sports game
US12183165B2 (en) 2017-12-22 2024-12-31 Adrenalineip Method, system, and computer program product for interactive sports game
US20210217126A1 (en) * 2018-06-18 2021-07-15 Tal Hayon Smart-venue wagering system and method for live events
EP3864635A4 (fr) * 2018-10-08 2022-07-06 Winview, Inc. Procédé et systèmes pour réduire le risque de de fixer une cote pour des propositions en cours de jeu fixes uniques au moyen d'une entrée en temps réel
WO2020076657A1 (fr) 2018-10-08 2020-04-16 Winview, Inc. Procédé et systèmes pour réduire le risque de de fixer une cote pour des propositions en cours de jeu fixes uniques au moyen d'une entrée en temps réel
US11183010B2 (en) 2019-04-10 2021-11-23 The Action Network, Inc. Secure bet synchronization and betting analytics
US11734999B2 (en) 2019-04-10 2023-08-22 The Action Network, Inc. Secure bet synchronization and betting analytics
US11823528B2 (en) 2019-04-10 2023-11-21 The Action Network, Inc. Secure bet synchronization and betting analytics
CN115280385A (zh) * 2019-06-14 2022-11-01 阿顿艾林艾普 用于互动体育游戏的方法，系统及计算机程序
CN115280385B (zh) * 2019-06-14 2023-12-22 阿顿艾林艾普 一种在计算机上实现的提供游戏程序的方法及系统
EP3966792A4 (fr) * 2019-06-14 2022-12-28 Adrenalineip Procédé, système et produit programme d'ordinateur pour jeu de sport interactif
EP4088265A4 (fr) * 2020-01-09 2023-12-27 Adrenalineip Procédé, système et appareil de cotes de pari améliorées par intelligence artificielle et apprentissage automatique
CN115867952A (zh) * 2020-01-09 2023-03-28 阿德伦纳林Ip公司 人工智能和机器学习增强的概率预测方法、系统和设备
US12080123B2 (en) 2020-11-30 2024-09-03 Adrenalineip Method for artificial intelligence-based changes based on deviations from predictions
WO2022115771A1 (fr) * 2020-11-30 2022-06-02 Adrenalineip Procédé pour des changements basés sur l'intelligence artificielle reposant sur des écarts par rapport à des prédictions
US12118857B2 (en) 2020-12-01 2024-10-15 Adrenalineip Method of verifying that a wager was placed before market close
US11727762B2 (en) 2020-12-01 2023-08-15 Adrenalineip Method of verifying that a wager was placed before market close
US11361627B1 (en) 2020-12-01 2022-06-14 Adrenalineip Method of verifying that a wager was placed before market close
WO2022119889A1 (fr) * 2020-12-01 2022-06-09 Adrenaline Ip Procédés, systèmes et appareils pour générer et permettre des opportunités de jeu
EP4505390A4 (fr) * 2022-04-08 2026-04-08 Adrenalineip Appareil, système et procédé d'affichage d'informations d'événement en direct

Similar Documents

Publication Publication Date Title
WO2007118300A1 (fr) Offre de paris sur des événements se déroulant lors d'une manifestation vécue en direct
US20230005323A1 (en) Real time parlay
US12333910B2 (en) Tiered gaming
AU2025205530A1 (en) Digital computing and processing systems involving interprogram or interprocess communication regarding risk in amusement devices
US8545311B2 (en) Systems and methods for enabling remote device users to wager on micro events of games in a data network accessible gaming environment
US7094151B2 (en) Pari-mutuel sports wagering system
US20180158286A1 (en) Virtual world of sports competition events with integrated betting system
TWI593450B (zh) 包括客制化遊戲參數的娛樂裝置
US20140342811A1 (en) Systems and methods for enabling remote device users to wager on micro events of games in a data network accessible gaming environment
US20230394930A1 (en) Location-based wagering via remote devices
US11783679B2 (en) Location-based wagering via remote devices
US12293630B2 (en) Head-to-head jai alai wagering system and method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 06721844

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06721844

Country of ref document: EP

Kind code of ref document: A1