WO2009086466A2

WO2009086466A2 - Interactive scenario exploration for tournament-style gaming

Info

Publication number: WO2009086466A2
Application number: PCT/US2008/088335
Authority: WO
Inventors: Desney S. Tan; Gregory R. Smith; Yuval Peres; Joseph Yossi Azar; Eyal Lubetzky
Original assignee: Microsoft Corporation
Priority date: 2007-12-28
Filing date: 2008-12-24
Publication date: 2009-07-09
Also published as: WO2009086466A3; US20090170584A1

Abstract

A tournament-style gaming scenario exploration system and method for interactively exploring current and future scenarios of a tournament and associated pick'em pool. The system and method include a prediction module (including a game constraint sub-module), and a key event detection module. Embodiments of the prediction module include a binary integer that represents tournament outcomes. The prediction module generates predictions of tournament outcomes using an exhaustive or a sampling technique. The sampling technique includes random sampling, where the tournament bracket is randomly sampled, and a weighted sampling technique, which sample portions of the tournament bracket more densely than others areas. Embodiments of the game constraint sub-module allow real-world results constraints and user-supplied constraints to be imposed on the tournament outcomes. Embodiments of the key event detection module identify key games in the tournament that affect a user's placement in the pick'em pool, a competitor's placement in the tournament standings, or both.

Description

INTERACTIVE SCENARIO EXPLORATION FOR TOURNAMENT-STYLE GAMING

BACKGROUND

[0001] Fantasy games, in which groups of people compete to predict outcomes in various types of competitions, is a large and rapidly growing industry. A leading trade association reported that in 2006 that there were 15 to 18 million fantasy sports players within the U.S. alone, with an expected growth rate of 7-10% per year. Moreover, some reports estimate that, on average, each fantasy sport player spends about $500 annually on magazines, online information, contests, and leagues.

[0002] In general, fantasy sports games can be divided into two basic genres. A first genre is manager leagues in which users select, trade, and manage virtual teams of real-world players drawn from a variety of real-world sports teams. Users compete against each other based on points generated by the real-world statistics of their team members. A second genre is pick'em pools, also known as tournament or office pools. In pick'em pools, users predict outcomes (or make picks) of real-world contests in tournament-style competitions. By way of example, these tournament-style competitions or games include the NCAA March Madness basketball tournament, the Wimbledon tennis tournament, the NFL football playoffs, and in some cases even television reality shows and political races. Typically, users score some number of fantasy points for each correct pick (or prediction) and the winner is the user with the highest total score at the end of the tournament.

[0003] There are many different types of online systems or portals that automate traditional paper-based versions of fantasy games. In general, these systems automate the processes whereby a user assembles, manages, and tracks games and teams. These systems make it easy for a user to set up competitions, make picks online, and track progress as real-world games unfold. As games are in progress users are able to obtain real-time scoring results and statistics. Moreover, some systems allow inter-user interactions such as instant messenger (IM) or e- mail. These systems automate most of the things that have to be done for the game but are tedious for a human to do. Since these systems free users from the tedious tasks of calculating, updating, and disseminating fantasy scores as real- world outcomes are decided, they have lowered the barrier to entry and led to growing participation.

[0004] One problem with current tournament-style gaming systems is that they lack the ability to calculate and provide future projections. For example, if there is a league of ten users in a pick'em pool, at any given point in the tournament a user may want to know what his odds are of winning. Current systems give the current score of the pool, but they do not project into the future and tell a user what the likely outcome will be after three more games have been played in the tournament. A user also may want to know what game outcomes need to happen in the tournament in order for that user to win, or finish the tournament in a certain position. This allows the user to know which teams to root for. For example, if Tennessee beats New Orleans a user's odds of winning may go way up, such that the user would want to root for Tennessee. Or, in more complex scenarios, if Tennessee beats New Orleans and Seattle beats Pittsburgh then the user's odds of winning go way up, but if Tennessee loses then the user really wants Seattle to lose as well. These are fairly complex interactions that current systems lack the ability to analyze.

[0005] Making future projections is not trivial. Many users try to do this manually, only to be frustrated with the amazing complexity of the problem. In fact, these projections are often nearly impossible to do manually because of the combinatorial nature of the problem. Even if the simplest case is assumed that each team has equal odds for beating any other team (i.e., each team has a 50-50 chance of winning), users typically do not start with an equal probability of winning because of the way each of their picks may overlap other users' picks. This is unintuitive and gets vastly more complicated with more teams and players, and if the simple assumptions are changed such that each team does not have a 50-50 chance of winning. Even with a computer and the ability to do many calculations quickly, making exact future projections can be lengthy or even intractable.

SUMMARY

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0007] Embodiments of the tournament-style gaming scenario exploration system and method provide users with an estimate of their projected odds of finishing at each place within the pool, given other users' picks as well as real-world results. This can be done either within an entire league or alternatively, between a subset (e.g. two) users. Other embodiments automatically detect interesting key events that users may be notified of, such as particular games that may drastically affect their odds of winning. Additionally, users can interactively explore complex 'what-if scenarios by setting various constraints in the system, to examine how various tournament outcomes will affect their odds or the odds of other players.

[0008] It is crucial to note that because of the way picks overlap with one another, the odds of various users winning often are not simply derivable from the current state of the pool. For instance, even before any real-world contests have been decided, users' chances of winning the pool are typically not equal (even assuming random real-world outcomes). As a further example, it is sometimes the case that the current "leader" of the pool is not most likely to be the winner at the end (and, in fact, in some cases may have absolutely no chance of winning). The projection capability offered by embodiments of the tournament-style gaming scenario exploration system and method can provide users with their odds within the pool as well as information on how each game affects overall pool results. The user is not only informed about which games to monitor, but also is provided with new common ground for social interaction or "trash talk". In certain types of pools, having this information at hand also could be helpful with making picks in the first place. [0009] At a high level, embodiments of the tournament-style gaming scenario exploration system and method use various methods of generating potential tournament outcomes, scoring player picks and ranking players based on each of these possible outcomes, and repeating this many times to get probabilistic statistics on the likely outcomes. In some embodiments, constraints may be applied at various phases of the computation to explore various key scenarios. After these computations are done, embodiments of the system and method also can automatically detect key scenarios and events that may be of interest to users.

[0010] More concretely, embodiments of the tournament-style gaming scenario exploration system and method include: (1 ) a tournament setup module, which allows basic tournament properties such as teams, structure, and scoring schemes to be set. This is usually done once at the beginning of each tournament; (2) a prediction module, which computes predictions of various tournament outcomes. The prediction module can be broken down into: (2a) a bracket generation sub- module, which generates a multitude of brackets for scoring; (2b) a game constraint sub-module, which applies game constraints to the generated brackets; (2c) a scoring sub-module, which takes each generated bracket, scores each players' picks according to the generated bracket, and then rank orders the players by final score to determine final placements; (2d) a player placement constraint sub-module, which checks for and applies specific user-specified constraints after scoring is performed; and (2e) an accumulator sub-module, which keeps running totals of the various calculations. Various embodiments also include: (3) a key event detection module, which identifies events, for example, that have a significant impact on a user's or competitor's placement in the pick'em pool.

[0011] Embodiments of the tournament setup module take input that form the core characteristics of the tournament, including, but not limited to: the tournament structure and rules, scoring system, teams playing, prior probabilities of each match, player picks, and so on. This is usually done only once per tournament because most pick'em games do not permit changes after the tournament has started, but nothing stops this information from being changed at any point within the tournament.

[0012] Embodiments of the bracket generation sub-module include a unique /V-bit bracket representation that represents a tournament outcome in a compact and efficient format. The /V-bit bracket representation is an integer where at least some bits of the integer represent games in the tournament. In some embodiments, each bit in the bitwise representation identifies who was the winner of the game represented by that bit. A bracket is used to visualize the game. If the bit value is a "1 ", the upper competitor of the bracket won the game, while if the bit value is a "0" the lower competitor of the bracket won the game.

[0013] Embodiments of the bracket generation sub-module generate possible tournament outcomes. At least two types of generation techniques are used by the bracket generation sub-module. One type is an exhaustive prediction technique, which computes all possible tournament outcomes. This can be done, for example, by using the /V-bit bracket representation and just incrementing the integer through all possible combinations. However, when the tournament includes a large number of competitors, the exhaustive prediction technique quickly becomes intractable. In this situation, a sampling prediction technique can be used. The sampling prediction calculates only a sample of all possible tournament outcomes to arrive at an estimate of a future projection. Generally, there are two ways in which a sampling prediction can be performed: (1 ) random sampling; and (2) weighted sampling. The random sampling technique uses a random number generator to generate random integer numbers for the /V-bit bracket representation, each corresponding to a random tournament outcome. A much more efficient technique, the weighted sampling technique is biased towards certain tournament outcomes and samples these areas of the bracket more densely than other areas. For example, if no users picked a certain team to win then no tournament outcomes are generated whereby that team is a winner. A different scheme generates tournament outcomes based on the distribution of prior probabilities of each game. This requires that each game outcome be generated as a function of the prior probability of that match-up, which makes it slightly more involved than the purely random sampling scheme. However, this ensures that the final tournament outcomes are generated in proportion to their overall likelihood of occurring, which has useful statistical properties, namely that it drastically reduces the number of sample brackets that have to be generated and scored for a given level of desired accuracy.

[0014] Embodiments of the game constraint sub-module allow constraints to be imposed on the tournament outcomes generated. There are at least two types of game constraints, (1 ) real-world results, and (2) user-input constraints ("what if scenarios). Real-world results constraints are imposed on the tournament outcome if some of the games in the tournament have already been played. The game constraint sub-module makes these tournament outcomes valid by imposing the real-world results on each generated tournament outcome. Embodiments of the game constraint sub-module achieve this by generating a constraint mask, where some bits have a bit set ("constrained" bits) and some bits are undecided, and applying this constraint mask to the /V-bit bracket representation of the tournament outcomes. There are situations where a user would like to impose constraints on the tournament outcomes to see "what would happen if?". This "what-if" scenario is achieved by generating a user-supplied constraint mask and applying this mask to every tournament outcome such that it is forced to match those constraints. Alternatively, in the weighted sampling scheme, these constraints are applied as a weighting of 1 (always happens) or 0 (never happens) as each game outcome is chosen during the course of generating a bracket. Regardless, game constraints are always met in the brackets that are then used in the scoring sub-module.

[0015] Embodiments of the scoring sub-module take each of the brackets generated by the bracket generation sub-module and scores each player's picks according to the outcome in the bracket. It then rank orders the players according to what their scores would be if that bracket were to happen. This scoring is based on the scoring scheme specified in the tournament setup, which can vary widely.

[0016] The player placement constraint sub-module is applied when a user specifies that they would like to explore only scenarios in which certain player placements have been specified and applies filters to the above results. For example, a user may specify that they would like to explore outcomes that would have to happen in order for them to place 1^st in the league, or for some other player to place 3^rd, or combinations of such placements. The player-constraint sub-module compares the rankings generated by the scoring sub-module to see if the player placement constraints are satisfied. If they are, the ranks are kept and sent to the accumulator sub-module, if not, they are discarded, and the process returns to bracket generation sub-module.

[0017] Embodiments of the accumulator sub-module keep a running total of the statistics from all different possible outcome brackets generated. When the generator is in exhaustive or random sampling mode, the accumulator sub-module populates a table of all players and all positions with a sum of normalized (by the probability of the occurrence of each outcome bracket) placements. For embodiments that use the weighted generation schemes, the accumulator sub- module often only has to keep integer counts of the occurrences (e.g. how many brackets in which player A placed 1^st, etc).

[0018] At some point, either based on processing time, or number of brackets generated, the prediction module stops and one more normalization is performed, either dividing by an accumulated normalizer to bring the overall percentages back down to 100%, or by number of brackets explored. This normalization is easier in the weighted sampling because brackets were already generated in proportion to their expected occurrence in the first place.

[0019] Embodiments of the key event detection module can identify potentially interesting games or events in the tournament. These games may be interesting to a user because they affect the user's placement in the pick'em pool. In some embodiments of the key event detection module, the module examines any correlation between tournament outcomes and user placements. In other embodiments, the key event detection module can identify key games affecting user placement in the tournament given the schedule of upcoming tournament games. Embodiments of the key event detection module also can examine tournament outcomes and counters to identify key events or games that will affect a competitor's placement in the final tournament standing. Any key games found then can be reported to the user.

[0020] Some embodiments of the system and method also calculate pairwise player statistics as a subset of calculations within large leagues. This allows closed-form (non-sampling) calculations in order to determine how one specific player is doing against another player. In one such embodiment, the system and method can determine if one player is completely dominated by another player. The way this is determined is by picking a point in the tournament that we would like to query (e.g. the final outcome), and setting all the picks that Player A can get correct still to be correct, thus optimizing Player A's score. For all other picks, the system and method sets Player B's picks to be incorrect, thus minimizing their score. If Player A's maximum score is less than Player B's minimum score, then Player A is said to be locked out, and cannot possibly place higher than Player B at that particular point in the tournament. If the system and method were to calculate all pairs of such lock out statistics for a given player and finds that the player is locked out by all other players, then it can be concluded that they are definitely locked out of first place. If they lock all other players out, then they are guaranteed to win. However, the inverse conclusions cannot be drawn. In other words, if a player locks some out and not others, nothing concrete can be said about their odds of first place and other techniques will have to be used.

[0021] In alternative embodiments, by using dynamic programming techniques, the system can compute the probabilities of each possible difference in final score between any two players. The system begins by computing a matrix for each upcoming game containing the probabilities of each difference in score between Player A and Player B caused by the two possible outcomes of the game and the two players' picks for that game. For example, if the two players have the same pick for that game the score difference will be zero no matter the outcome, whereas if the player's picks are not the same the difference will be a positive or negative constant (which depends on the scoring system). At each game of the tournament after this first round, a new matrix can be calculated by calculating the probability of the differences in score produced by the new game, and then accumulating them with the weighted values of the matrices for each lead-in game. If this algorithm is performed for each game in the tournament, the matrix for the final game contains the probabilities for each possible difference in final score between Player A and Player B. By then summing all the probabilities for positive score differences, for example, the system can report the probability of Player A beating Player B (i.e., having a larger final score).

[0022] It should be noted that alternative embodiments are possible, and that steps and elements discussed herein may be changed, added, or eliminated, depending on the particular embodiment. These alternative embodiments include alternative steps and alternative elements that may be used, and structural changes that may be made, without departing from the scope of the invention.

DRAWINGS DESCRIPTION

[0023] Referring now to the drawings in which like reference numbers represent corresponding parts throughout:

[0024] FIG. 1 illustrates a simplified traditional tournament bracket used to represent games in a tournament.

[0025] FIG. 2 is a block diagram illustrating an embodiment of the tournament-style gaming scenario exploration system and method disclosed herein implemented in a tournament-style gaming environment.

[0026] FIG. 3 is a flow diagram illustrating the general operation of the method used in the tournament-style gaming scenario exploration system shown in FIG. 2. [0027] FIG. 4 is a flow diagram illustrating the detailed operation of the tournament setup module shown in FIG. 2.

[0028] FIG. 5 is a detailed flow diagram illustrating the generation of an /V-bit bracket representation.

[0029] FIG. 6 illustrates an exemplary example of the /V-bit bracket representation for the bracket shown in FIG. 1.

[0030] FIG. 7 is a flow diagram illustrating the detailed operation of the bracket generation sub-module shown in FIG. 2. [0031 ] FIG. 8 is a flow diagram illustrating the detailed operation of the game constraint sub-module shown in FIG. 2.

[0032] FIG. 9 is a block diagram illustrating an example of a real-world result constraint applied to a predicted tournament outcome.

[0033] FIG. 10 is a flow diagram illustrating the detailed operation of the scoring sub-module shown in FIG. 2.

[0034] FIG. 11 is a flow diagram illustrating the detailed operation of the accumulator sub-module shown in FIG. 2.

[0035] FIG. 12 is a flow diagram illustrating the detailed operation of the key event detection module shown in FIG. 2.

[0036] FIG. 13 illustrates an example of a suitable computing system environment in which the tournament-style gaming scenario exploration system and method shown in FIGS. 2-12 may be implemented.

DETAILED DESCRIPTION

[0037] In the following description of embodiments of the tournament-style gaming scenario exploration system and method reference is made to the accompanying drawings, which form a part thereof, and in which is shown by way of illustration a specific example whereby embodiments of the tournament-style gaming scenario exploration system and method may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the claimed subject matter.

I. Basic Terminology

[0038] A few basic terms that will be used in this document will now be defined. A "tournament", a "tournament-style game", or "tournament-style gaming" refers to a number of competitors from some domain of competition (such as sports) vying to be the overall champion. Depending on the tournament, a competitor can refer to a single person (an athlete), or a group of people (a team). Each tournament consists of a sequence of head-to-head contests or games (sometimes called matches, ties, fixtures, or heats) between competitors that lead to some result. In most tournaments, this means that one competitor is the winner of the tournament. [0039] The basic goal of a tournament is to winnow multiple competitors down to a single champion. This often makes a tree (or hierarchy) a useful visual representation. In a single elimination tournament (also known as a knockout or sudden-death tournament), competitors who lose a match are immediately eliminated from the tournament (or at least from winning the tournament), and only winning competitors move on and vie to be the champion. For the purpose of simplifying discussion, the document uses the term "tournament" as if the tournament is a single elimination tournament. However, it should be noted that there exist other types of tournaments, including double elimination tournaments (in which competitors can lose a single game and still vie for the championship), or round robin tournaments (in which all competitors play all other teams). Adapting embodiments of the tournament-style gaming scenario exploration system and method to handle these types of tournaments is a straightforward extension that will not be explicitly discussed.

[0040] A bracket is the common term for a tree-based tournament visualization. The structure of the bracket defines how and when competitors will play each other as they progress through the tournament towards the championship. FIG. 1 illustrates a simplified traditional tournament bracket 100. This bracket structure 100 contains a series of match-ups, which, as shown in FIG. 1 , has competitors (in this case, teams) playing each other connected by a vertical line. Each team is matched up against another team and the structure of the bracket 100 is well defined such that there is a fixed progression of teams throughout the bracket 100. As shown in FIG. 1 , the bracket 100 includes 3 rounds starting with "Round 1 " and progressing to the "Winner."

[0041] The winner of each match-up progresses to the next round and their name is filled in on a result line, which comes out of the match-up. This forms a new matchup with another team, and this process continues until there is only one team left (the tournament winner). By way of example and not limitation, the bracket 100 shown in FIG. 1 illustrates that Seattle has played and beat Carolina in Game 0 of Round 1. This means that Seattle's name is placed on the result line of the Finals round. In addition, Denver has played and beat Pittsburgh in Game 1 of Round 1 , so that Pittsburgh's name is placed on the result line of the Finals round. This creates a match-up between Seattle and Pittsburgh in Game 2 of the Finals round. This process continues until a winner is determined. As can be seen from FIG. 1 , in this particular example, Seattle has won the tournament and this result is illustrated in the "Winner" round on the far right of FIG. 1. It should be appreciated that there exist many variants of the bracket visualizations, but in general these basic properties hold.

[0042] The following terms are used in this document to refer to elements of the fantasy games themselves. In particular, the term "user" or "player" refers to a person who is taking part in the fantasy competition. In other words, the user is a person who has completed a set of contest predictions. These tournament contest predictions are called picks. Most pick'em pools require that users pick all outcomes within the entire bracket. Alternatively, it is a straightforward extension for embodiments of the tournament-style gaming scenario exploration system and method to be applied to tournaments in which users only make a subset of picks. Multiple users who are competing against each other in the pick'em game form a pool or league. While pools can comprise just two users, or thousands, most typically include less than 50 users. For the purpose of simplifying discussion in this document, it is assumed that users only fill out a single bracket for a single pool. However, it should be noted that nothing precludes a user from using multiple instantiations of embodiments of the tournament-style gaming scenario exploration system and method to track multiple brackets in multiple pools.

II. System and Operational Overview

[0043] FIG. 2 is a block diagram illustrating an embodiment of the tournament-style gaming scenario exploration system and method disclosed herein implemented in a tournament-style gaming environment. It should be noted that the implementation shown in FIG. 2 is only one of many implementations that are possible. Referring to FIG. 2, tournament-style gaming scenario exploration system 200 is shown in a tournament-style gaming environment 210. The tournament-style gaming scenario exploration system 200 resides on a computing device 220. It should be noted that the computing device 220 may include a single processor (such as a desktop or laptop computer) or several processors and computers connected to each other.

[0044] The tournament-style gaming scenario exploration system 200 includes a tournament setup module 230, a prediction module 240, and a key event detection module 250. The prediction module 240 includes a number of sub-modules, including a bracket generation sub-module 255, a game constraint sub-module 258, a scoring sub-module 260, a player placement constraint sub-module 265, and an accumulator sub-module 270. The tournament setup module 230 inputs core information about the tournament into the system 200. The prediction module 240 is a key component in the system 200 and calculates predictions for different scenarios of a tournament. As explained below, in some embodiments of the bracket generation sub-module 255, these predictions use a novel /V-bit bracket representation and compute predictions using a random sampling technique, a weighted sampling technique, or both. The game constraint sub-module 258 applies game constraints to the predictions or generated brackets. These game constraints include real-world results and "what-if" scenarios proposed by a user. The scoring sub-module 260 scores each player's picks according to a bracket outcome. The player placement constraint sub-module 265 is an optional sub- module, as denoted by the dashed line in FIG. 2. The player placement constraint sub-module 265 imposes player placement constraints on the predictions calculated by the bracket generation module 255. The accumulator sub-module 270 keeps a running tally of statistics from different possible outcome brackets generated by the bracket generation sub-module 255. The key event detection module 250 identifies events that are of interest to a user because the events have a major impact on a user's final ranking.

[0045] A user 275 interacts with the tournament-style gaming scenario exploration system 200 through a display device 280 and an input device 290 that are connected to the computing device 220. Information from the tournament-style gaming scenario exploration system 200 is displayed to the user 275 on the display device 280. The user 275 is able to input information and requests to the tournament-style gaming scenario exploration system 200 through the input device 290 (such as a keyboard or pointing device). It should be noted there may be one or more display devices and one or more input devices connected to the computing device 220. In addition, the computing device 220, display device 280, and input device 290 may be integrated into a single device.

[0046] FIG. 3 is a flow diagram illustrating the general operation of the method used in the tournament-style gaming scenario exploration system shown in FIG. 2. In general, the tournament-style gaming scenario exploration method inputs a bracket containing games for a tournament and allows exploration of various scenarios as to the outcome of the tournament. In addition, the tournament-style gaming scenario exploration method allows a user to examine the user's picks to explore various outcomes of picks in relation to other users' picks.

[0047] As shown in FIG. 3, the tournament-style gaming scenario exploration method begins by inputting the game schedule of the tournament, any real-world results of games in the tournament that have already been played, user picks for the tournament, and tournament odds for the tournament competitors (box 300). The game schedule governs what player or team is matched up against another player or teams during the tournament. Of course, if the tournament has not yet started then the outcome of the games is unknown, and only the first round games will be input. On the other hand, if games of the tournament have been played, then the current game schedule as well as game results will be input. As explained in detail below, in some embodiments the game constraint sub-module 258 uses the real-world game results to impose constraints on the predictions.

[0048] Some embodiments of the tournament-style gaming scenario exploration method represent each game in the tournament in an /V-bit bracket representation (box 310). This representation, which is discussed in detail below, represents each game in the tournament as a binary integer. The method then computes predictions of a plurality of outcomes of the games of the tournament using the internal representation to obtain prediction results (box 320). In some embodiments of the tournament-style gaming scenario exploration method, constraints are applied to the prediction results to obtain constrained prediction results (box 330). These constraints may be game constraints imposed on the results such as real-world constraints, which include the outcomes of games that have already been played, or user-supplied constraints, such as what will happen if this team wins the game and where the user will rank based on his picks. These constraints may also include player placement constraints.

[0049] In some embodiments the tournament-style gaming scenario exploration method identifies key events or games in the tournament that will impact a final ranking of one or more users (box 340). For example, there may key games that will affect a user's ranking in the pick'em pool, while other games may have less of an impact. The method uses the predictions to identify these key games. Finally, the method displayed the constrained prediction results, the key games, and corresponding information to the user (box 350).

III. Tournament-Style Gaming Scenario Exploration Details

[0050] Embodiments of the tournament-style gaming scenario exploration system and method include several components, modules, and sub-modules. The details of each of these items now will be discussed.

III.A. Tournament Setup Module

[0051] The tournament setup module 230 allows basic tournament properties such as teams, structure, scoring schemes, and so forth, to be input to the system 200. Typically, this is performed once at the beginning of each tournament. However, the tournament setup module 230 does allow changes to be made to this information.

[0052] FIG. 4 is a flow diagram illustrating the detailed operation of the tournament setup module 230 shown in FIG. 2. The operation begins by inputting initial core characteristics of the tournament (box 400). By way of example and not limitation, these initial core characteristics include the tournament structure, tournament rules, scoring system, teams playing, prior probabilities of each match, player picks, and so forth [0053] The module then determines whether any information needs to change (box 410). This change may come from a user. The initial core characteristics usually do not change during the tournament because most pick'em games do not permit changes after the tournament has started. However, nothing stops this information from being changed at any point within the tournament. If the initial core characteristics are to be changed, then the module 230 updates the core characteristics of the tournament that have changed (box 420). Otherwise, the module 230 outputs the initial core characteristics and any updated core characteristics of the tournament (box 430).

[0054] As stated above, the core characteristics of the tournament can include various types of information. For example, in order to statistically calculate the future standings within the pick'em pool, it is necessary to know not only the current score, the number of potential points a user can score, and the likelihood that they will score these, but also the overlap that their picks have with other users' picks. As a trivial example, if everyone has picked exactly the same results for some competitor throughout the tournament, then the performance of this competitor is of little importance in future projections as it has no differential impact on the users' scores relative to one another. Embodiments of the tournament setup module 230 include using several core pieces of information to project future standings: (1 ) the basic tournament bracket including the games in the tournament; (2) results of any contests that have already been played (real-life game outcomes); (3) all users' picks (of contests decided and yet to be decided) that each user has made for the contests; and (4) prior probabilities for the outcomes of each possible match-up in the tournament. This is the odds of a tournament outcome actually occurring.

[0055] Some embodiments of the tournament setup module 230 input information that specifies how likely it is for any given competitor to beat any other competitor. This is known as a prior probability table, which specifies how likely it is that each competitor will beat each other competitor. For example, if there are K competitors in a tournament, a prior probability table consists of K x (K- 1) entries. There are many ways in which the prediction module can estimate prior probabilities and populate this prior probability table. [0056] In some embodiments, the tournament setup module 230 can use prior probabilities that infer nothing about the competitors and assume that the likelihood of any competitor beating another is chance (e.g., each team has a 50-50 chance of winning). Although this may be the simplest case, it may not be the most accurate. In another embodiment, the tournament setup module 230 uses information about the competitors, such as tournament rankings, previous performance, statistics, or popular opinion, in order to derive prior probabilities. In some of these embodiments, the tournament setup module 230 uses a linear mapping from rankings to probabilities (e.g. a number one-ranked competitor is much more likely to beat a number sixteen-ranked competitor than they are a number two-ranked competitor). In another embodiment, the tournament setup module can use popular opinion, either attained through some explicit voting mechanism or through other users' picks, in order to derive the probabilities (e.g. competitors that are more often picked to win are more likely to win). In yet another embodiment, the tournament setup module 230 can use odds set by experts (or betting odds) to derive probabilities. In still other embodiments, the tournament setup module 230 can start with any of these probability schemes and allow the user to specify new probabilities, either by using mathematical equations or computer programs to combine statistics. These statistics can then be collected from multiple sources or by manually changing individual entries within the table.

[0057] Using the prior probability table and an assumption of independence between contests the tournament setup module 230 then can calculate the likelihood of any given set of contest outcomes occurring. For example, if A plays B and C plays D, and if A has a 75% probability of beating B and C has a 30% of beating D, then the probability of the particular set of brackets in which A beats B and C beats D is 75% times 30% or 22.5%. By multiplying together individual contest outcomes in this way, the tournament setup module 230 can arrive at a single prior probability value for the set of contest outcomes representing an entire bracket. Such a fully specified set of outcomes is referred to as a tournament outcome and the prior probability of this happening as the outcome probability. III. B. Prediction Module

[0058] The prediction module 240 calculates predictions for different scenarios of a tournament to produce possible tournament outcomes. The predicted outcomes are made using a /V-bit bracket or other internal representation and an exhaustive prediction technique, a sampling prediction technique, or both. Details of the sub- modules of the prediction module 240 now will be discussed.

a, Bracket Generation Sub-Module

[0059] Embodiments of the bracket generation sub-module 255 include a unique N- bit bracket representation that allows every possible outcome of the tournament to be represented in a compact and efficient format by a single integer. FIG. 5 is a detailed flow diagram illustrating the generation of an /V-bit bracket representation. In this representation, N is the number of games, which for fully populated single elimination tournaments equals the number of teams that start the tournament minus one. In addition, each game is represented by a bracket having an upper competitor versus a lower competitor on the bracket (box 500). This concept is discussed in more detail below.

N-Bit Bracket Representation

[0060] The /V-bit bracket representation is a Y-bit integer, where V is greater than or equal to N ( Y>/V) (box 510). Typically, the Y-bit integer will be some power of 2 in order to simply processing and random number generation. For example, the Y-bit integer may be a 16-bit integer or a 64-bit integer. This is true even if N is less than Y. For the case where N<Y, there will be some unused bits in the Y-bit integer. Each used bit in the Y-bit integer represents a game in the tournament (box 520). For example, in some embodiments a single 64-bit integer is used to represent possible outcomes of a tournament having up to 64 teams. A 64-bit integer is used because it is a common primitive used in computer programs. In theory, for a 64- team tournament only 63 bits are necessary (/V=63). However, a 64-bit integer is used because it is a nice power of 2 binary number and is an easy number for which to generate random numbers. Thus, for a 64-team tournament one bit goes unused, while the other 63 bits are used bits. In alternate embodiments, a 32-bit integer or a 16-bit integer may be used. In some embodiments of the prediction module, an entire 64-bit integer is used for a tournament even if it is a 16 team tournament because using a 64-bit integer simplifies the computation.

[0061] Before any games in the tournament have been played, random brackets are generated within the tournament space. By way of example, refer to the brackets for the 4-team tournament shown in FIG. 1. In order to simply the discussion, only a 4-team tournament will be discussed to illustrate the principle behind the /V-bit bracket representation. Each used bit in the Y-bit integer is defined as a "1 " if the upper competitor in the bracket wins the game (box 530). Conversely, each used bit is defined as a "0" if the lower competitor in the bracket wins the game (box 540). The output is the Y-bit integer representing an outcome of the tournament (box 550)

[0062] In order to better illustrate the N-bit bracket representation, FIG. 6 is an exemplary example of the /V-bit bracket representation for the bracket shown in FIG. 1. As shown in FIG. 6, a 4-bit integer 600 is used to represent the possible outcomes of the tournament shown by the bracket of FIG. 1. Each bit in the 4-bit integer 600 represents one of the 3 games in total that will be played. Referring to FIGS. 1 and 6, and looking from left to right, a first bit 610 represents an outcome of Game 0 (between Seattle and Carolina), a second bit 620 represents an outcome of Game 1 (between Denver and Pittsburgh), and a third bit 630 represents an outcome of Game 2 (between Seattle and Pittsburgh). Note that because only 3 games are played in this tournament and there are 4 bits, a fourth bit 640 is not needed and is not used. Nevertheless, the 4-bit integer 600 is used because it is a power of 2 and it is convenient to use.

[0063] Referring to FIG. 1 , note that each bracket contains a top team and a bottom team for the match-up, such that the top team plays the bottom team. Specifically, for Game 0 the top team on the bracket is Seattle and the bottom team is Carolina. Similarly, for Game 1 the top team is Denver and the bottom team is Pittsburgh, and for Game 2 the top team is Seattle and the bottom team is Pittsburgh. For a specific game number, if the corresponding bit is a "1 " that means that the top team on the bracket won, whereas if the corresponding bit is a "0" means that the bottom team on the bracket won. In other words, for bit "B" representing a game being played, if that bit is a "1 " it means that the upper team (from the upper half of the bracket) won the game. On the other hand, if that bit is a "0", it means that the lower team (from the lower half of the bracket) won the game.

[0064] Referring again to FIGS. 1 and 6, the 4-bit integer 600 has a value of 1011". The first bit 610 representing Game 0 has a value of "1", meaning that the top team in the bracket (i.e. Seattle) won Game 0. The second bit 620 representing Game 1 has a value of "0", meaning that the bottom team in the bracket (i.e. Pittsburgh) won Game 1. The third bit 630 representing Game 2 has a value of "1 ", meaning that the top team in the bracket (i.e. Seattle) won Game 2. Note once again that the value of the unused fourth bit is of no consequence, since there are only 3 games in the tournament.

[0065] The /V-bit representation can be used to represent every possible outcome of a tournament. In the 3-game example used above, there are 8 possible outcomes (0-7) of the tournament (2³), since the fourth bit 640 is not used. Specifically, the outcomes of the 3-team tournament are as follows (again, the fourth bit 640 is denoted as an "Z" since it is unused):

"000Z" Carolina won Game 0, Pittsburgh won Game 1 , Pittsburgh won Game 2

"100Z" Seattle won Game 0, Pittsburgh won Game 1 , Pittsburgh won Game 2

"010Z" Carolina won Game 0, Denver won Game 1 , Denver won Game 2

"110Z" Seattle won Game 0, Denver won Game 1 , Denver won Game 2

"001 Z" Carolina won Game 0, Pittsburgh won Game 1 , Carolina won Game 2

"101 Z" Seattle won Game 0, Pittsburgh won Game 1 , Seattle won Game 2

"011 Z" Carolina won Game 0, Denver won Game 1 , Carolina won Game 2

"111Z" Seattle won Game 0, Denver won Game 1 , Seattle won Game 2

[0066] A random number generator can be used to generate random 4-bit integers, as discussed below. This yields random outcomes of the tournament that are compactly represented with a single V-bit integer that can be used to specify any given outcome. Each of the integers that the Y-bit integer can represent enumerates the entire space of possible outcomes for an (N+1)-team tournament.

[0067] One advantage of the /V-bit bracket representation is that each Y-bit integer that is generated is a valid bracket. Many current systems give each competitor in a tournament a unique identification. This means it is sometimes quite difficult to ensure that invalid brackets to not arise. For example, if Seattle plays Carolina in the first round and Carolina loses, with some current systems caution must be used to ensure that Carolina does not show up in brackets after the first round, as these are invalid brackets. However, with /V-bit bracket representation, because only position is used (top team vs. bottom team), then it follows that every bit field is a valid bracket.

[0068] In addition, the /V-bit bracket representation is a compact representation. In other words, for an (N+1)-team tournament only N bits are needed. There are at least two advantages to this representation. First, it is a very compact representation of brackets. Second, it is easily generated and implemented, since any computer language has built-in primitives for generating random numbers. This makes the /V-bit bracket representation an efficient generation scheme.

Prediction Calculation

[0069] In general, the approach used by embodiments of the bracket generation sub-module 255 in statistically predicting future standings is to generate as many possible tournament outcomes as it can (e.g. based on some fixed amount of time it is provided to perform the processing) and then to calculate how each user will do in each of these outcomes. User performance in the pick'em pool for each of these outcomes is weighted by the outcome probability. These weighted scores are summed to create a prediction of the probability of each user finishing in a certain place within the pool. Embodiments of the bracket generation sub-module 255 can use two types of prediction techniques. Namely, an exhaustive prediction technique and a sampling prediction technique can be used. Each of these techniques is discussed in detail in the following discussion. [0070] FIG. 7 is a flow diagram illustrating the detailed operation of the bracket generation sub-module 255 shown in FIG. 2. In general, the module 255 uses the /V-bit bracket representation to compute various tournament outcomes. The operation begins by inputting a /V-bit bracket representation of the tournament (box 700). A determination then is made whether to use an exhaustive prediction technique (box 710).

Exhaustive Prediction

[0071] The most basic way of predicting outcomes of a tournament is to perform an exhaustive prediction. The exhaustive prediction exhaustively generates and scores all possible tournament outcomes (box 720). This is done using the /V-bit bracket representation discussed above. The 4-team tournament example discussed above was an example of an exhaustive prediction, where each of 8 possible outcomes of the tournament was found.

[0072] There are limits, however, to the exhaustive prediction. In particular, the number of possible tournament outcomes is 2^X, where X is the number of games or contests remaining in the tournament. Given the current processing capability of modern PCs (e.g. a 3.3 GHz machine with 1 GB of RAM), it is feasible to perform an exhaustive prediction for brackets of up to about 16 remaining contests (where there are roughly 64,000 outcomes) if interactive performance is desired. However, since the outcome space is exponential with the number of contests, exploring all outcomes for a larger bracket by performing an exhaustive prediction is not feasible. For example, at the beginning of a 64 team tournament (which has 63 games), there are 2⁶³ (or about 9 million trillion) possible outcomes, which would take roughly 4.5 million processing years to generate fully at the above-mentioned rate. Thus, it is an intractable problem to perform an exhaustive prediction of this magnitude.

Sampling Prediction

[0073] When an exhaustive prediction is intractable, embodiments of the bracket generation sub-module 255 can use sampling prediction. The sampling prediction calculates only a sample of all possible tournament outcomes to arrive at an estimate of a future projection. Generally, there are two ways in which a sampling prediction can be performed: (1 ) random sampling; and (2) weighted sampling. Referring to FIG. 7, the operation of the bracket generation sub-module 255 makes a determination whether random sampling will be used (box 730).

[0074] If so, random sampling is performed by selecting results at random from within the tournament space by using a random number generator (box 740). Next, the module 255 generates valid brackets from within the space and then re- normalizes these results after generation of a bracket, given how likely that bracket would be to come out.

[0075] Embodiments of the bracket generation sub-module 255 also can use weighted sampling. Weighted sampling performs sampling more densely in certain areas of the outcome space and less densely in other areas. The module 255 obtains weighting information (box 750). The module 255 then samples more densely at certain areas of the tournament bracket based on the weighting information (box 760).

[0076] One example of weighting information is user picks. In this situation, the bracket generation sub-module 255 can sample more densely around areas of the tournament bracket based on users' picks. For example, in some embodiments overlapping points of users' picks are identified and sampling occurs more densely around those points. By way of further example, referring to FIG. 1 , assume that no user picked Seattle to win in the first round game (Game 0). In this case, then the module 255 would not generate any brackets in which Seattle won the first round game. And if most users picked one of the teams to win a round and only one user picked another team to win in that round, the module 255 could sample that space less densely as it would be less differentiating between the brackets.

[0077] In some embodiments, the weighting information is game odds (i.e. prior prediction probabilities). In this case, the areas of the tournament bracket in which to sample more or less densely can be driven by the prior odds of a team beating another team. For example, using the example of FIG. 1 , if going into a tournament Seattle was a great team and had a 90% chance of beating Carolina in the Round 1 , the bracket generation module 255 may sample more brackets with Seattle in the Finals than with Carolina in Finals. In fact, in one embodiment, the module 255 would sample at exactly the probability of the outcome (i.e. about 90% of brackets generated would be expected to have Seattle win that game).

[0078] For tournaments with a large number of games, once a sufficient number of games have been played, the predictions can be performed using the exhaustive prediction. For example, in a 64-team tournament, the weighed sampling can be used until there are about 16 games remaining, which corresponds to about 65,000 outcomes. At this stage of the tournament outcomes can be computed using the exhaustive prediction technique. The Y-bit binary integer representing a tournament outcome then is output from the prediction module (box 770).

b, Game Constraint Sub-Module

[0079] There will be situations when the tournament outcomes computed by the bracket generation sub-module 255 may not be valid (because some games in the tournament have already been played) or when a user may want to impose certain constraints on predictions (such as what happens if Competitor A wins Game 2?). The game constraint sub-module 258 allows these game constraints to be imposed on the tournament outcomes calculated by the bracket generation sub-module 255. There are at least two types of game constraints, (1 ) real-world results, and (2) user-input constraints (or "what if scenarios).

[0080] FIG. 8 is a flow diagram illustrating the detailed operation of the game constraint sub-module 258 shown in FIG. 2. In general, the game constraint sub- module 258 applies to a tournament outcome either real-world result constraints, "what-if" constraints, or both. In particular, the operation of the game constraint sub-module 258 begins by inputting a predicted tournament outcome represented by a /V-bit bracket or other suitable representation (box 800). Next, a determination is made as to whether any games of the tournament have been played (box 810). If so, the real-world results constraints are used. Real-World Result Constraints

[0081] After some games of the tournament have been played, the tournament outcomes may be partially incorrect for the games that have already been played. The game constraint sub-module 258 makes these tournament outcomes valid by imposing the real-world results on each generated tournament outcome. Referring to FIG. 8, the sub-module 258 inputs the real-world results from the tournament (box 820).

[0082] Embodiments of the game constraint sub-module 258 express a set of pre- decided outcomes as a bitmask (or a "constraint mask") where some bits have a bit set ("constrained" bits) and some bits are undecided. The sub-module 258 applies a constraint mask based on the real-world results constraints to the /V-bit bracket representation (box 830). In the case where games have already been played, the sub-module 258 keeps a partial bit field representing the current state of the tournament. This means that some of the games are meaningless, since they represent games that have not been played. But some of the bits will have O's and 1 's in them. In other words, the sub-module 258 generates a random bracket and then replaces in that random bracket each of the bits that have already been specified by games that have already been played. Each of the bits representing games that have not yet been played is left unchanged.

[0083] Using the example given above, if contests 1 , 2, and 4 had already been played, the corresponding constraint mask would be 00X0XXX, where X represents contests yet to be decided. After a full random tournament outcome number is generated, it is modified by replacing some of its bits with the corresponding constrained bits in the constraint mask.

[0084] FIG. 9 is a block diagram illustrating an example of a real-world result constraint applied to a predicted tournament outcome. This example uses the 4- team tournament example given above. In this example, if Seattle has already played Carolina and Seattle has won, then generating equally random 3-bit fields makes no sense because one of the games has already been played. This is shown at the top of FIG. 9, where in Game 0 Seattle has beaten Carolina in Round 1 and has advanced to the Finals. A corresponding constraint mask would be 1XXZ, where X represents games yet to be decided and Z is an unused bit. However, in FIG. 9 the bracket generation sub-module 255 generated a random full 4-bit number, "001 Z", which is the predicted tournament outcome. In this case, the predicted tournament outcome is invalid, since Game 0 has already been decided. Instead, the game constraint sub-module 258 applies the constraint mask to the predicted tournament outcome by replacing the first bit (representing the game between Seattle and Carolina) with a "1 ", since the top team in the bracket (Seattle) won. This produces a valid constrained tournament outcome, "100Z". Another way of looking at this is that after a predicted tournament outcome binary integer has been generated it is modified by replacing some of its bits with the corresponding constrained bits in the constraint mask. In the example of FIG. 9, the random integer generated would have its first bit changed to a "1 ", and the remainder of the bits would be left unchanged. This produces a valid possible outcome taking into consideration that Game 0 has already been decided.

"What-if" Scenario Constraints

[0085] Referring back to FIG. 8, a determination then is made as to whether a user has supplied any "what-if constraints (box 840). If so, then the game constraint sub-module 258 inputs the user-supplied "what-if constraints (box 850). There are situations where a user would like to impose constraints on the tournament outcomes to see "what would happen if?". This "what-if scenario is handled similar to imposing real-world results on the tournament outcomes. In particular, the sub- module 258 applies the "what-if constraints to the /V-bit bracket representation (box 860). User constraints are used to set certain bits within the /V-bit bracket representation to a specific value, and every tournament outcome that is generated by the bracket generation sub-module 255 is forced to match those constraints. The output of the game constraint sub-module 258 is constrained tournament outcomes, or tournament (box 870).

[0086] The game constraint sub-module 258 allows users to specify an "alternate reality", typically by interacting with the bracket visualization. In doing this, the user can either change real-world events that have already happened, or, more likely, add real-world events that have not yet happened. For example, a user might be interested to see what would happen to standing probabilities if a specific competitor (or set of competitors) won the next round, or if they continued to win several more rounds. When the user does this, the game constraint sub-module 258 augments its calculations to include only brackets that satisfy the imposed constraints in order to obtain its estimates.

c. Scoring Sub-Module

[0087] Embodiments of the scoring sub-module 260 include scoring each players' picks according to each generated bracket, and then ranking the players based on the scores as if the generated bracket actually occurred. FIG. 10 is a flow diagram illustrating the detailed operation of the scoring sub-module 260 shown in FIG. 2. The operation begins by inputting the scoring scheme for the tournament, the brackets generated by the bracket generation sub-module 255, and the players' picks (box 1000). It should be noted that the scoring scheme can vary widely between tournament pools.

[0088] Once a tournament outcome has been generated, it is compared to the user's picks and a score is produced. The scoring sub-module 260 scores each player's picks according the scoring scheme and based on the outcome of the generated brackets (box 1010). A typical scoring scheme involves a certain number of points for each correct prediction, with correct predictions, for example, in later stages being more valuable than those in earlier stages. The tournament outcome and an individual user's outcome are each mapped into a representation that makes for efficient scoring calculations. The sub-module 260 then ranks players according to what their score would be if the generated bracket actually occurred (box 1020). One example would be to map an outcome into an ordered list of winning competitors at each stage. The tournament list and the user's list are compared to count the number of matching entries, and this count is multiplied by the appropriate point factor to get the total user score for each stage. The users are all scored and their scores are sorted, resulting in a list of standings. The sub- module 260 outputs the players rankings based on the generated bracket (box 1030). d. Player Placement Constraint Sub-Module

[0089] Embodiments of the optional player placement constraint sub-module 265 are applied when a user specifies that they would like to explore only scenarios in which certain player placements have been specified and applies filters to the above results. The player placement constraint sub-module 265 allows users to specify a "desired placement outcome", typically by interacting with the standing probabilities visualization. In doing this, the user specifies that they care about exploring the scenarios in which certain standings are attained by certain users. For example, a user might be interested in seeing what game outcomes have to happen in order for them to place first in the pick'em pool, or for them to place second while another user places fourth. When the user does this, the player placement constraint sub-module 265 looks through the set of generated tournament outcomes in order to match these constraints and sums the individual contest outcomes that satisfy this standing constraint. In some embodiments of the player placement constraint sub-module 255, this is displayed as weighted counts of each competitor reaching a certain round. By looking at these counts, the user can derive the contest outcomes that will most likely lead to the specified standing constraints. Perhaps more importantly, the user will be able to see what outcomes cannot possibly satisfy these constraints. They would, for example, be able to tell that if a certain competitor goes past a certain round, they will not be able to win the pick'em pool.

[0090] In some embodiments of the game constraint sub-module 258 and the player placement constraint sub-module 265, the user interface is a dialog box that presents any constraints that the user has imposed so that they can explore scenarios of interest. The user interface must be crafted correctly such that only one constraint at a time, so as to make sure that the constraints never collide. In some embodiments, the constraint can be formulated as a simple English sentence (such as "what if Competitor A were to beat Competitor B" or "what if Competitor A were to make it to the third round of the tournament" or "what would have to happen if I wanted to finish as pool champion"). This interface allows the user not only to see the constraints they have placed on the system, but also to toggle them on and off, or to remove them from the calculations completely. The constraints are also available on the main visualizations (such as the interactive bracket or standings probability) in a distinct fashion, such as a red outline, or presented with dimmed out and faded colors.

e. Accumulator Sub-Module

[0091] Embodiments of the accumulator sub-module 270 compute and keep a running total of statistics relating to the generated brackets. FIG. 11 is a flow diagram illustrating the detailed operation of the accumulator sub-module 270 shown in FIG. 2. The operation of the accumulator sub-module 270 begins by inputting player rankings computed by the scoring sub-module 260 (box 1100). Next, a running total is kept of statistics from all possible outcomes of the generated brackets (box 1110).

[0092] One use for the accumulated statistics is to predict what order the users will place in their tournament picks. For example, if every tournament outcome generated by the bracket generation sub-module 255 has User 3 coming in first, then the total probability for User 3 placing first in the pick'em pool is 100%. Moreover, if the module 255 never generates a tournament outcome in which User 4 comes in first, then that counter stays at zero, and everything else is in between. Note that while 100% and 0% mean that the prediction is a certainty (either to happen or not) in the exhaustive scheme, this is not true with sampling schemes, which can only present estimations and not certainties.

[0093] These counters for user placements are a PxP table, where P is the number of users. So, User 1 has a counter for coming in 1^st, 2^nd, 3^rd, etc., and User 2 has similar counters. Each time the bracket generation sub-module 255 computes an outcome probability for a given tournament outcome, the module 255 examines the corresponding counters and adds to them as dictated by the outcome. These counters are basically accumulators for the probabilities that these users are coming in these placements. [0094] Other accumulators are maintained in a similar manner for other features of the explored bracket space that might be run through the key event detection module and found to be interesting to the user. For example, accumulators for certain teams reaching certain rounds of the tournament, or accumulators for player placements when a certain team wins or loses.

[0095] A determination is made as to whether the bracket generation technique is a weighted generation scheme (box 1120). If not, this implies that the generation technique is an exhaustive scheme or a random sampling scheme. In this case, the accumulator sub-module 270 populates its tables with a sum of normalized placements (box 1130). The normalization is performed using the probability of the occurrence of each outcome bracket. For embodiments that use the weighted generation schemes, the accumulator sub-module 270 keeps integer counts of the occurrences of each player in a certain ranking (box 1140). In other words, how many brackets in which player A placed first, how many brackets in which player B placed third, and so forth. The operation of the sub-module 270 then outputs the accumulated statistics (box 1150). The process works identically for other accumulation tables.

III. C. Key Event Detection Module

[0096] For users that do not wish to interact with the optional player placement constraint sub-module 265, the above "what-if" scenario generation can be performed in an automated fashion to select a small set of potentially interesting games. These key events then are displayed to the user, such as in a bracket visualization. In some embodiments of the key event detection module 250, heuristics are used to determine if the outcome of a particular contest drastically affects the standing probabilities of the user. For example, regardless of what a user picked, if their probability of a given standing rises or drops by a significant amount with the outcome of a certain upcoming contest, the key event detection module 250 will call this out in the bracket visualization.

[0097] It should be noted that there are unintuitive instances in which users would like to explicitly root against competitors that they have picked because of how this affects other users within the pick'em pool. The user then may wish to pay more attention to the particular contest, or to discuss this further with pool-mates. Similarly, a contest outcome that leads to the user being locked out of certain standing positions (such as if Competitor A wins their next contest, the user cannot place higher than 3^rd in the pool) is an interesting piece of information and one which the key event detection module 250 also points out. Using this, the key event detection module 250 is also able to provide interesting information about outcomes that do not affect the current user (such as drastically changes the rankings of other users independently or in relation to one another).

[0098] FIG. 12 is a flow diagram illustrating the detailed operation of the key event detection module 250 shown in FIG. 2. In general, the key event detection module 250 identifies events that are of interest to a user because the events have a major impact on a user's placement or on a competitor's placement at the end of the tournament. In particular, operation of the key event detection module 250 begins by inputting tournament outcomes, counters, and a schedule of upcoming games in the tournament (box 1200).

[0099] In some embodiments of the key event detection module 250, the module 250 examines the counters and tries to find correlation between tournament outcomes and user placements (box 1210). For example, assume that the key event detection module 250 finds that several tournament outcomes have User 1 coming in first in the pool. Assume further that the module 250 examines these tournament outcomes further and discovers that in all the outcomes where User 1 comes in first, Florida never wins its 2^nd round game. The key event detection module 250 then reports this information to the user as an interesting thing to know. In this example, the module 250 would tell User 1 that in all the cases where you come in first Florida loses by the 2^nd round.

[0100] In other embodiments, the key event detection module 250 can identify key games affecting user placement in the tournament user correlation and the schedule of upcoming tournament games (box 1220). This is done by tracking piecewise probabilities and knowing the set of upcoming games. The module 250 then can look at those games and report to the user important games. For example, assume that in instances where Illinois wins a Round 1 game a User 1 's chance of coming in first is 52%, while in all the ones where Illinois loses this game User 1 's chances are 26%. This is an important game for User 1 , and the key event detection module 250 reports this to User 1. In certain situations, the module 250 may find that whether a team wins or loses the game does not affect a user's odds of finishing at a certain position. But sometimes a particular game is important and does make a difference to a user's placement in the pool. In these situations the games are reported to the user as key games.

[0101] The key event detection module 250 can examine tournament outcomes and counters to identify key events or games that will affect a competitor's placement in the final tournament standing (box 1230). Using the same set of calculations, the module 250 accumulates the probabilities for competitors in rounds the exact way the module 250 does for user placements on the pool. Thus, for any given tournament outcome there is a final ranking or placement of the competitors. The key event detection module 250 uses counters to accumulate the probabilities that the competitors will finish at a certain placement when the tournament is finished. Key games then are reported to the user (box 1240).

III. D. Other Embodiments

[0102] There are several core pieces of information that have to be exchanged between users and updated throughout the course of the tournament. For example, user picks have to be shared. This usually only has to occur once at the beginning of each tournament, since most pick'em games do not allow users to change the picks once the tournament has started. However, some embodiments of the tournament-style gaming scenario exploration system 200 and method allow users to spend some number of their current fantasy points in order to change a certain number of picks, and this data would have to be exchanged again each time a change is made. Also, users may wish to save and exchange scenarios that they have constructed using the what-if scenario explorer so that other users may quickly replicate and explore outcomes around this scenario. Furthermore, the calculations and visualizations have to be updated with new real-world information as data becomes available.

[0103] In some embodiments of the tournament-style gaming scenario exploration system 200 and method, the system 200 and method are entirely a server end application, with all calculations performed on a server and visualization and interaction taking place in a "thin-client" (such as in a web-browser). While this is a convenient model, since the user does not have to download or install any additional software, the load that is placed on the server to perform calculations for many users (up to hundreds of thousands) can be very high. This is especially true since users tend to check and explore their brackets at quite well-defined times, such as before and after real-world contests are played.

[0104] In other embodiments of the tournament-style gaming scenario exploration system 200 and method, a peer-to-peer arrangement is used. In these embodiments, users download and run software that perform all calculations locally and are able to communicate directly with each other. While this mitigates the server-side problems, it creates the potential for clients to be out of sync with each other since it is difficult to guarantee that a client has all available information at all times.

[0105] Other embodiments of the tournament-style gaming scenario exploration system 200 and method are a hybrid of the above-mentioned embodiments. In particular, in these embodiments a "rich client" is used that has to be downloaded and installed in some manner. A server is used to hold the data that needs to be exchanged and updated. This client-server model offloads the processing to the local machine, where processing cycles are usually abundant, while keeping the data assessable to all clients on a server. This server could be infrastructure from or similar to one of the existing fantasy sports sites, augmented to send the data that our client needs when it authenticates. It could also be a more generic data exchange server. One example of this is for a client to programmatically set up and connect to an existing blog page (such as spaces.live.com) and send or receive information from looking at this page. This scheme has the added benefit that the data is human readable and users can insert other content on the site to augment their social interaction. In some embodiments of the tournament-style gaming scenario exploration system 200 and method, well-formed English text is inserted that provides commentary of the state of the tournament as well as interesting future scenarios. Real-world tournament updates can either be automatically updated with data feeds from various data sources, or they can be manually inserted by tournament organizers or even individual users.

IV. Exemplary Operating Environment

[0106] Embodiments of the tournament-style gaming scenario exploration system 200 and method is designed to operate in a computing environment. The following discussion is intended to provide a brief, general description of a suitable computing environment in which the tournament-style gaming scenario exploration system 200 and method may be implemented.

[0107] FIG. 13 illustrates an example of a suitable computing system environment in which the tournament-style gaming scenario exploration system 200 and method shown in FIGS. 2-12 may be implemented. The computing system environment 1300 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 1300 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment.

[0108] The tournament-style gaming scenario exploration system 200 and method is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the tournament-style gaming scenario exploration system 200 and method include, but are not limited to, personal computers, server computers, hand-held (including smartphones), laptop or mobile computer or communications devices such as cell phones and PDA's, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

[0109] The tournament-style gaming scenario exploration system 200 and method may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The tournament-style gaming scenario exploration system 200 and method may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices. With reference to FIG. 13, an exemplary system for the tournament-style gaming scenario exploration system 200 and method includes a general-purpose computing device in the form of a computer 1310.

[0110] Components of the computer 1310 may include, but are not limited to, a processing unit 1320 (such as a central processing unit, CPU), a system memory 1330, and a system bus 1321 that couples various system components including the system memory to the processing unit 1320. The system bus 1321 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

[0111] The computer 1310 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by the computer 1310 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile removable and nonremovable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.

[0112] Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 1310. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

[0113] The system memory 1340 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 1331 and random access memory (RAM) 1332. A basic input/output system 1333 (BIOS), containing the basic routines that help to transfer information between elements within the computer 1310, such as during start-up, is typically stored in ROM 1331. RAM 1332 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 1320. By way of example, and not limitation, FIG. 13 illustrates operating system 1334, application programs 1335, other program modules 1336, and program data 1337.

[0114] The computer 1310 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 13 illustrates a hard disk drive 1341 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 1351 that reads from or writes to a removable, nonvolatile magnetic disk 1352, and an optical disk drive 1355 that reads from or writes to a removable, nonvolatile optical disk 1356 such as a CD ROM or other optical media. [0115] Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 1341 is typically connected to the system bus 1321 through a non-removable memory interface such as interface 1340, and magnetic disk drive 1351 and optical disk drive 1355 are typically connected to the system bus 1321 by a removable memory interface, such as interface 1350.

[0116] The drives and their associated computer storage media discussed above and illustrated in FIG. 13, provide storage of computer readable instructions, data structures, program modules and other data for the computer 1310. In FIG. 13, for example, hard disk drive 1341 is illustrated as storing operating system 1344, application programs 1345, other program modules 1346, and program data 1347. Note that these components can either be the same as or different from operating system 1334, application programs 1335, other program modules 1336, and program data 1337. Operating system 1344, application programs 1345, other program modules 1346, and program data 1347 are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information (or data) into the computer 1310 through input devices such as a keyboard 1362, pointing device 1361 , commonly referred to as a mouse, trackball or touch pad, and a touch panel or touch screen (not shown).

[0117] Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, radio receiver, or a television or broadcast video receiver, or the like. These and other input devices are often connected to the processing unit 1320 through a user input interface 1360 that is coupled to the system bus 1321 , but may be connected by other interface and bus structures, such as, for example, a parallel port, game port or a universal serial bus (USB). A monitor 1391 or other type of display device is also connected to the system bus 1321 via an interface, such as a video interface 1390. In addition to the monitor, computers may also include other peripheral output devices such as speakers 1397 and printer 1396, which may be connected through an output peripheral interface 1395.

[0118] The computer 1310 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 1380. The remote computer 1380 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 1310, although only a memory storage device 1381 has been illustrated in FIG. 13. The logical connections depicted in FIG. 13 include a local area network (LAN) 1371 and a wide area network (WAN) 1373, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

[0119] When used in a LAN networking environment, the computer 1310 is connected to the LAN 1371 through a network interface or adapter 1370. When used in a WAN networking environment, the computer 1310 typically includes a modem 1372 or other means for establishing communications over the WAN 1373, such as the Internet. The modem 1372, which may be internal or external, may be connected to the system bus 1321 via the user input interface 1360, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 1310, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 13 illustrates remote application programs 1385 as residing on memory device 1381. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0120] The foregoing Detailed Description has been presented for the purposes of illustration and description. Many modifications and variations are possible in light of the above teaching. It is not intended to be exhaustive or to limit the subject matter described herein to the precise form disclosed. 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 appended hereto.

Claims

WHAT IS CLAIMED IS:

1. A method for projecting, predicting, and interactively exploring a user's expected performance in a pick'em pool based on a tournament having a plurality of games, comprising: inputting the plurality of tournament games, real-world results, and tournament odds for competitors in the tournament (300); generating brackets of a plurality of outcomes of the tournament games to obtain a plurality of possible results (255); scoring a user's picks based on the generated brackets (1010); and accumulating the scores in a manner that permits statistical inferences to be made about expected player and game outcomes (1230).

2. The method of claim 1 , further comprising generating brackets by exhaustively generating and scoring each possible outcome of the plurality of tournament games (720).

3. The method of claim 1 , further comprising generating brackets by calculating and scoring a sample of possible outcomes of the plurality of tournament games (740).

4. The method of claim 3, further comprising selecting random samples of possible outcomes of the plurality of tournament games using a random number generator (740).

5. The method of claim 3, further comprising performing weighted sampling of possible outcomes of the plurality of tournament games by sampling some outcomes of the plurality of tournament games more densely and sampling other outcomes of the plurality of tournament games less densely (760).

6. The method of claim 1 , further comprising: obtaining a scoring scheme for the tournament, the generated brackets, and the user's picks (1000); and scoring the user's picks according to the scoring scheme and prediction results of the generated brackets (1010).

7. The method of claim 6, further comprising ranking the user relative to other users according to what the user's score would be if the generated bracket actually occurred (1020).

8. The method of claim 1 , further comprising: accumulating a running total of statistics from the plurality of possible outcomes of the generated brackets (1110); if the prediction technique is a weighted technique, then keeping an integer count of occurrences of each user in a certain ranking (1140); and otherwise, populating a table of users and user positions with a sum of normalized placements (1130).

9. The method of claim 1 , further comprising applying constraints to the generated brackets to obtain constrained prediction results (330).

10. The method of claim 9, further comprising: inputting real-world results of the tournament (800); and applying a constraint mask to the prediction results based on the real- world results to obtain the constrained prediction results (830).

11. The method of claim 9, further comprising: inputting a "desired game outcome" constraint supplied by the user (850); and applying the "desired game outcome" constraint to the generated brackets to obtain the constrained prediction results (860).

12. The method of claim 9, further comprising: inputting a "desired placement outcome" supplied by the user that specifies certain standings that are attained by certain users (850); and applying the "desired placement outcome" constraint to the prediction results to obtain the constrained prediction results (860).

13. The method of claim 1 , further comprising: inputting tournament outcomes, counters, and a schedule of upcoming tournament games (1200); examining the counters to find correlation between tournament outcomes and user placements (1210); identifying key games affecting user placement using the correlation and the schedule of upcoming tournament games (1220); identifying key games that affect a user's placement in final tournament standing by examining the tournament outcomes and the counters (1230); and notifying user of the key games (1240).

14. The method of claim 1 , further comprising representing each tournament game by a /V-bit bracket representation (310), where N is a number of games in the tournament (500) and /V-bit bracket representation is a Y-bit integer, where Y>N (510) and at least some bits of the Y-bit integer represent an outcome of a game in the tournament (550).

15. A tournament-style gaming scenario exploration system having computer-readable instructions encoded on computer-readable media for interactively exploring current and future scenarios of a tournament-style gaming pool corresponding to a tournament, comprising: a tournament set-up module that inputs core information about the tournament (230); a prediction module that calculates predictions for different scenarios of the tournament (240), the prediction module further comprising: a bracket generation sub-module that computes the predictions using an exhaustive search technique, a random sampling technique, or a weighted sampling technique (255); a game constraint sub-module that applies game constraints to the predictions (258); a scoring sub-module that scores each user's picks according to a bracket outcome (260); a player placement constraint sub-module that checks for and imposes user-specified constraints on the predictions generated by the bracket generation sub-module after scoring is performed (265); an accumulator sub-module that keeps a running tally of statistics from different possible brackets generated by the bracket generation sub- module (270); and a key event detection module that identifies events in the tournament that may be of interest to a user because the events have an impact on the user's final ranking in pick'em pool of the tournament (250).