US20110053681A1

US20110053681A1 - System and Method for Fantasy Sports Gambling

Info

Publication number: US20110053681A1
Application number: US12/870,287
Authority: US
Inventors: Justin Edward Goldman; Robert Daniel Shedd, JR.; Alan David deLevie
Original assignee: Paddy Power PLC
Current assignee: Paddy Power PLC
Priority date: 2009-08-28
Filing date: 2010-08-27
Publication date: 2011-03-03

Abstract

A method and system provides an interactive gaming system for a plurality of users connected via a communication network. At least one community is created for the interactive gaming system including rules defining parameters for the gaming system, the community including a plurality of players. An initial bankroll is allocated to each of the plurality of players and each of the plurality of players is enabled to wager at least a portion of their allocated bankroll in accordance with the rules. Information is provided to a requesting one of the plurality of players for assisting the requesting player in making a wager and each of the plurality of players is ranked based on success in wagering by each of the plurality of players.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from U.S. Provisional Application Ser. No. 61/275,395 filed on Aug. 28, 2009 by Justin E. Goldman, Robert Daniel Shedd, Jr. and Alan David Delevie.

FIELD OF THE INVENTION

The invention concerns a type of game that allows users to establish a competitive league related to various contests and activities and the management of the league.

BACKGROUND OF THE INVENTION

Interactive electronic and online games are well known and widely implemented and played by users all over the world. The types of games vary in nature, setup, design and implementation. A common type of game is called a Fantasy game and is associated with a particular type of sport or event. An example of this type of game is a Fantasy Football game which may be operated online by a service provider that allows users to log in and access their servers to play the game entirely online and in a remote manner. These games allow individuals to gather together and form a league whereby each league member selects players in the National Football League to create a team and utilize in-game statistics for the selected players to create a score. The individuals are then able to use these scores to compete against other individuals to determine who has selected a better team of players. These types of games have been extended to every different type of professional sports league including baseball, basketball, hockey, golf, soccer and car racing. These games have also been extended into the arena of amateur sporting leagues and association such as college football and basketball. However, a drawback associated with these types of games is that typically, the leagues only allow players to operate within a single sport and the players are limited to using the statistics of the players selected as a basis for competition.
Wagering on sporting events is thought by some to be an activity that enhances the fun for sports fans during the actual games because the wagers represent an interest for the individual in the outcome of the game. However, many sports fans do not participate in this activity due to the strict restrictions placed on sports wagering and for fear of losing a substantial amount of money. Therefore, there is a desire to create and implement a game whereby the users are able to wager on sporting events in the setting of an online social game that enables sports fans to enjoy the thrill of sports betting in a low risk and fun environment. There are currently no games that allow users to create a league that allows the league members to wager on outcomes of particular events across a number of different sporting leagues without using actual money and create a community of these individuals that enables a game provider to derive a stream of revenue from the community of users. A system and method according to invention principles remedies the drawbacks associated noted above.

SUMMARY OF THE INVENTION

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is a flow diagram detailing an algorithm for implementing and operating a fantasy sports gaming system according to invention principles;

FIG. 2 is a flow diagram detailing an algorithm enabling a system operator to derive a revenue source from the fantasy sports gaming system according to invention principles;

FIG. 3 is a block diagram of an embodiment of a system for implementing a fantasy sports gaming system according to invention principles; and

FIGS. 4-19 are exemplary screen shots of display images generated by the fantasy sports gambling system enabling users to engage in game play.

DETAILED DESCRIPTION

An executable application, as used herein, comprises code or machine readable instructions for conditioning a processor to implement predetermined functions, such as those of an operating system, a context acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters. A processor as used herein is a device for executing machine-readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or a combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a controller or microprocessor, for example, and is conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may be coupled (electrically and/or as comprising executable components) with any other processor enabling interaction and/or communication there-between.
A user interface (UI), as used herein, comprises one or more display images, generated by a display processor and enabling user interaction with a processor or other device and associated data acquisition and processing functions. Data representing a UI design may be pre-stored in a repository or database in advance of execution and display thereof. The UI is caused to be displayed by combining the dynamic output processing code or executable applications (based on the information retrieved from the database) into the UI at runtime. The UI may also include an executable procedure or executable application. The executable procedure or executable application conditions the display processor to generate signals representing the UI display images. These signals are supplied to a display device which displays the image for viewing by the user. The executable procedure or executable application further receives signals from user input devices, such as a keyboard, mouse, light pen, touch screen or any other means allowing a user to provide data to a processor. The processor, under control of an executable procedure or executable application manipulates the UI display images in response to the signals received from the input devices, for example via a user's browser. In this way, the user interacts with the display image using the input devices, enabling user interaction with the processor or other device. The functions and process steps herein may be performed automatically or wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to executable instruction or device operation without user direct initiation of the activity.
FIG. 1 details an algorithm for creating and operating a fantasy sports betting system. In step 102, a system and method provides and implements a game enabling a plurality of individuals to gather for the purpose wagering on the outcome of a plurality of different types of sporting events without risking actual money. A community of users is advantageously created and allows the individuals (users) to determine how to organize themselves into individual leagues having a predetermined number of individuals in order to participate in and the system determines which of the users has the greatest amount of success selecting the winner or outcome of various contests as well as events occurring during a particular contest. A contest may include a sporting event such as a football or baseball game. However, a contest as used herein may refer to a live or pre-recorded television show that is outcome based and includes at least one event or occurrence that a person may wager on. For example, a reality television show may be the contest and a challenge between participants could be an event. The game may include a system comprising a server having executable instructions that implement game features stored thereon. Users can selectively access this server via any computing device including, but not limited to, a desktop computer, a laptop computer, a tablet computing device, a cellular phone, a smart phone or any other hardware device that enables a user to remotely connect with a server over any type of communication network.
The system enables users to create a password protected user account that grants access to the various features of the game system. As used herein, the terms user and player may be used interchangeably. One aspect of the system and method enables a registered user to become a commissioner and selectively create and define a targeted user community whereby each user within the community will be a player in a respective game. The community design feature of the game advantageously enables the commissioner to selectively determine the game rules applied to the community and the particular game or games being played by the community. The game may be a fantasy sports betting game whereby the users in the community compete against one another in monetary wagering contests without actually wagering or paying legal tender using the rules selected by the commissioner. The community of users may be a network or group of friends or acquaintances that decide to establish their own league and play the game amongst the members of their network or league. The winner of the game is determined at the end of the gaming period by identifying the user that has accumulated the greatest amount of money/points representing an overall success rate on the wagers placed by that user.
In step 104, the system enables the creation and definition of rules for a game period during which the players in the community have opportunities to make bets on actual sporting contests and events within individual sporting contests. In creating a game, the commissioner may select from a predetermined set of rules stored in a rules repository on a server or other storage device. Alternatively, the commissioner may create rules different from the predetermined set of rules. The rules available to the commissioner advantageously enable the commissioner to selectively determine every aspect of the game to be played. The commissioner may choose a starting bankroll value that is available for each player. This initial bankroll value represents an amount of money that the player can use during the course of the game. The initial bankroll amount is what each player seeks to improve on during the course of the game by successfully betting on the outcome of at least one of a sporting contest or an event within a sporting contest. For example, in one embodiment the initial bankroll is $100,000.00 per player.
The commissioner can select the duration of the game as well as the duration of individual betting periods within the context of the game. In one embodiment, the user may determine that the game will be played for 30 days and at the end of the 30 day period a winner will be determined by the player having the largest amount of money in their bankroll. In the present exemplary embodiment, the user may divide up the initially selected 30 day period into 4 weekly betting periods and bets by each user are placed during the respective betting periods. In this embodiment, a winner may be determined both at the end of each betting period as well as a cumulative winner at the end of the game period which, in this example, is 30 days. Alternatively, the commissioner may define the gaming period to cover specifically identified weeks such as those corresponding to weeks 1-17 of a National Football League schedule. The use of the National Football League schedule to outline a gaming period is merely exemplary and the game duration may be based on the duration of any season of any sport or other type of competition. The flexibility provided in allowing users to determine the duration of the gaming period allows users to play in multiple leagues without having to wait for subsequent season to begin for the sport on which they are betting. It advantageously allows for shorter commitments to be made by players. Additionally, from a system operator and revenue source point of view, the flexible gaming periods advantageously enable gaming periods to begin and end at any time throughout the calendar year or season/competition which allows for increased revenue generation.
In a further embodiment, a user may selectively determine that the duration of a game should correspond to a particular sporting event or other competition such as a single game of a particular sport. In this embodiment, the commissioner is able to selectively identify types of events within the particular sport event on which wagers may be placed. The types of events available for use by the commissioner may be presented in a categorized list according to the type of sporting event that is selected. For example, there will be different in-game events to bet on in football games as compared to baseball and basketball games. In this type of game, the betting period is event-based and may be selectively defined as opening and closing at predetermined times prior to the identified event. The winner of this type of game is determined at the end of the sporting event by the user having the most money in their bankroll. An exemplary single contest game period may comprise a live betting environment whereby the players of the game will access a community game screen that shows, in real-time, a representation of every event occurring during a sporting contest. In this embodiment, a group of individuals would start out with an initial bankroll value at the beginning of a single contest. Using a system that enables live betting, the players would be presented with a plurality of different events occurring within the contest including the potential available outcomes associated with the event. The player would be further presented with odds of the listed outcome occurring and would be able to place bets in real time via a play-by-play method. The user with the highest bankroll after bets are settled would be the winner. An example of how this operates can be seen in the context of a baseball game wherein, before each at-bat by the player playing in the actual baseball game, the fantasy game player will be presented with a set of outcomes (i.e. single, strikeout, homerun, walk) and odds associated with each of the outcomes presented. The fantasy player can bet an amount in accordance with the betting rules on that at-bat. Should the player in the actual game get on base, the system may present the player in the fantasy game with two different types of bets corresponding to the player on base as well as the player up at bat. The fantasy bettor may be simultaneously presented with multiple other events to wager on. Additionally, the commissioner may define certain additional events in the game on which bets can be placed. For example, prior to the game starting one exemplary wager may include the odds associated with a particular player on a particular team hitting the first homerun of the game. Alternatively, the user defined bets may be straight bets whereby, for a particular event within the sporting contest, the player can enter a name of a player and an amount of a wager and if the event occurs (i.e. hitting the first homerun) then the player wins the bet.
The commissioner may also selectively determine the number of bets available to each player for a particular betting period. In one embodiment the number of bets is fixed for each betting period. In another embodiment, the number of bets may be variable wherein, based on the success rate of a player in the previous betting period, the player may be awarded with at least one additional bet that may be placed during the subsequent betting period(s) thereby giving the successful player an advantage in subsequent betting periods by providing them additional opportunities to win money. Alternatively, the number of available bets per player may be reduced for the next scoring period. For example in an effort to handicap a match between players, a really successful player may have a predetermined number of bets less than another player against which he is directly competing. The number of bets may also be tied to the type of sporting contest or events within a sporting contest as determined by the commissioner.
The commissioner may also selectively determine the type of sporting contests that will be available to each player for purposes of betting. For example, the commissioner may determine that a particular league should only bet on the outcome of football games played in the National Football League. In this embodiment, for each betting period, all the games being played during that betting period are available to be bet on by the players. The system enables the commissioner to select from a plurality of different types of sporting contests that are available during the gaming period thus allowing players to bet on various sporting events in different sport leagues during the betting periods and the gaming periods. A commissioner may also determine a subset of contests selected from a plurality of different type of sporting contests for use during a particular betting period.
The commissioner may also selectively determine the type and nature of bets able to be placed by the user during the betting period. There are a number of known types of bets including but not limited to parlays, teasers, run line bets, over/under, progressive parlays, and head-to-head bets. The respective type of bets available and associated with a particular sporting contest are displayed to a player in the game and the player is able to select the type of bet they want to place from the group of bet types presented. The parameters of each of the types of bets presented to the user may be selectively determined by the system operator in a known manner. The parameters include but are not limited to the spread, the over/under, number of teams able to be used in at least one of a parlay and a teaser, etc. Alternatively, the server implementing the game may connect, via a communication network to a remote source whereby these parameters can be acquired for presentation to a user.
In addition to the number and types of bets available to the players, the commissioner may enable rules that control an amount of money a player can bet on a particular sporting contest or event within a sporting contest in a particular circumstance. To enable this feature, the commissioner activates and sets parameters for a Maximum Bet Amount. The parameters associated with the Maximum Bet Amount include but are not limited to:

- a. an actual dollar amount maximum on a specific bet or a per day/week/month and based on a total risk amount, for example, a maximum percent of the players bankroll that may be risked on any given bet, or a per day/week/month total risk amount.
- b. progression/regression whereby the maximum amount able to be bet by a player increases or decreases over a defined period of time. Alternatively this may be implemented based on another circumstance that is user-defined.
- c. elimination of the maximum bet amount at a predetermined time during the game which enables no-limit betting by the players on any of the contests or events during that betting period.

In addition to the Max Bet feature, the system enables a commissioner to implement a Max Bet Breaker which, if selected by a player for a particular Max Bet, would allow the player to bet an amount greater than the predetermined Max Bet value. In one embodiment, the Max Bet Breaker feature enables a player to wager a certain amount over the max bet value such as 5 times (5×) the current max bet. Therefore, if the Max Bet was $1000, then the user selecting and applying the Max Bet Breaker option to a particular bet could bet $5000. The number of Max Bet breakers may be selected by the commissioner when establishing the community, or, may automatically be available to users based on performance in previous weeks or based on another circumstance or event during the season such as particular week or beginning of a playoff period, etc. Alternatively, users/players may pay sum certain to at least one of the league commissioner or system operator to buy a Max Bet Breaker. The circumstances may be selected from a list of potential circumstances that commonly arise during gaming periods or may be any user defined circumstance that could arise during the course of the game.
A further type of betting feature available to the commissioner is Lock Bet feature that allows players to make a bet a “lock bet” and multiply the amount able to be won on a particular bet without increasing the amount risked. A 2× Lock Bet multiplies the winning amount by 2 and a 4× Lock Bet multiplies the winning amount by 4. The commissioner may select the number and types of lock bets available to the players of the game and when these types of bets can and cannot be used. Lock bets may be multipliers for the amount to be won or may be fixed dollar amounts able to be wagered. For example, a player is able to risk $100 to win $90 on Team A wherein the point spread is +4.5 points. If applying a 2× Lock Bet, the player would be risking $100 to win $180. If applying a 3× Lock Bet, the player would be risking $100 to win $270. The number of Lock Bets, once determined, may be allocated in a plurality of ways. For example, the amount of lock bets available may vary on a daily, weekly, monthly or even on a full season basis. The amount of lock bets may change by sport and game. In some cases players can even earn more lock bets through successful performance. Players may also “buy” lock bets by paying a predetermined purchase price in accordance with rules to the league commissioner or the system operator. In the event sums are paid to the league commissioner, the system operator may take a predetermined cut of the transaction fee. The commissioner can set the cost amount for each of the lock bets able to be purchased by players. Combinations of these possibilities may also be configured. Lock bets may broken into different levels and each player may be assigned a number of allowable lock bets at each level. These lock bets may or may not have to be used during a particular betting period or game period. The commissioner may determine that lock bets that are not used by players during a given betting period are to expire or carry over to future betting periods. Alternatively, the system may enable players who do not want to use their lock bets to offer then for sale to other users for an set amount of money which would be paid to at least one of the league commissioner and the system operator. If paid to the league commissioner, the system operator may elect to take a cut of the transaction fee paid by the user acquiring the lock bet. Alternatively, the players may be allocated a certain number of lock bets having predetermined monetary values at each level based on the total number of bets the player is placing during a given time period. In an exemplary embodiment there are four levels of lock bets. A level 1 lock bet may be valued at $2,500. A level 2 lock bet may be valued at $5,000. A level 3 lock bet may be valued at $7,500 and a level 4 lock bet may be valued at $10,000. These numbers are used for purposes of example only and each level can be assigned any number. In this example, for every 10 bets placed, players received one level 4 $10,000 bet, two level 3 $7,500 bets, three level 2 $5,000 bets and 4 level 1 $2,500 bet. The level bets are intended to be bonus bets that allow a player to bet more money on contests or events that they are more certain of the outcome.
A further type of bet that may be enabled for use during game allows the user to choose a game and if the spread was within 3.5 points in either direction, you win 2× your money. For example, if Team A is +4 and they lose the game by no more than 7, then the spread was within 3.5 points and thus you win the fantasy wager. The number of these types of bets available to players during any particular betting or gaming period may be selectively configured. Alternatively, the availability of these bets may be provided to players at a predetermined time period or based on the success of the player in previous betting periods.
In a further embodiment, the system enables a commissioner to enable a free bet whereby a player could bet a specified dollar amount on a particular contest or event within a contest without penalty to the player's current bankroll. For example, a player could place a free bet to win the corresponding amount of money without having that amount of money removed from their bankroll should the bet be unsuccessful. If the bet is $10,000 to win $9000.00, and the player loses the bet, no amount of money is subtracted from the bankroll. The value of a free bet enabled by the system may be of a predetermined monetary value or may be automatically determined based on a characteristic such as a percent of total bankroll or percent of total amount of money wagered during at least one of a current betting period and a previous betting period.
Once the rules of the game have been created and defined as discussed above, step 106 provides the ability of players to join at least one community and engage in game play during the specified betting periods in order to try to increase the amount of fictitious money allocated to the player. An exemplary rule set and operation of a game as stated in step 106 is described with respect to the following example.

Example 1

Start Date: Game begins when a league is formed and the game ends at the conclusion of week 17 of the NFL season. The start and end dates are flexible though.

Starting Bankroll and How To Win:

Each player starts with a bankroll of virtual cash. For this season we are allocating $25,000. The objective for each player is to increase their bankroll by placing and winning bets. The player with the largest bankroll at the end of the tournament wins! Once a player has $0 left in their bankroll, they are eliminated from the tournament.

Tie Breaker:

If two players are tied after the season ends, the tiebreaker is the player with the actual highest dollar amount down to the last cent. Full bankroll data is hidden from the users until the final standings. Should two or more players be tied after reviewing the full bankroll amount including the decimal places, then system will crown all participants that are tied as Co-Champions.
Bet Types: Straight Bets, Parlays and Teasers
Maximum Bet: The Maximum Bet is the maximum amount of money that can be wagered on any specific bet. Each week, the Max Bet amount increases by $100. The Max Bet starts at $400 on August 31^stand increases by $100 a week. Players may risk the Max Bet on many different bets at one time. However, the Max Bet cannot be changed on any one specific bet. A player can even use the same team in multiple bets as long as each bet is different. For example, if the Max Bet was $500, a player could place $500 on the Philadelphia Eagles −7 and you could also place a parlay bet with the Eagles −7 and the Falcons +9. Additionally, there is a bet minimum of $100.

This game allows a player to place a Lock Bet that may multiply the potential winnings by either double (2-for-1), triple (3-for-1) or quadruple (4-for-1). The lock bet advantageously enables the player to win more however the player can only lose the initial amount wagered. In this game, players may use each of the three types of lock bets (2-for-1, 3-for-1 and 4-for-1) once per week which is the betting period which runs Tuesday through Monday. Lock Bets may only be used on straight bets and teasers, they cannot be used on parlays. An exemplary bet available to player may be:

Philadelphia Eagles at −7 risking $100 to win $90.
By using a lock bet on the above wager, it would look like this:
Philadelphia Eagles at −7 risking $100 to win $180 using 2-for-1 Lock Bet
Philadelphia Eagles at −7 risking $100 to win $270 using 3-for-1 Lock Bet
Philadelphia Eagles at −7 risking $100 to win $360 using 4-for-1 Lock Bet
Depending on the outcome of the actual game in which the Eagles are playing, the players bankroll is automatically adjusted accordingly by the system. The system checks the results of the games that players bet on, compared against the selected handicaps/odds of the bet, and determines whether the player has won or lost the bet. Then the system calculates the amount won or lost and deposits or debits this amount from the bankroll, respectively.

In step 108, a player is presented the option to join another league and/or community that may have similar or different rule set that is created in accordance with steps 102 and 104 discussed above. If the player does want to join another league, the player may do so and once game play begins, the player, in step 109, may advantageously apply any or all of the bets made in one league to any other league in which he is a member. Applying bets across different leagues and communities is subject to the rules of the respective communities and games. Thus, if a common bet is available in two of the three leagues, the player may select an option to have the same bet be active in those leagues. Thus the system advantageously enables a user to control multiple leagues from a single interface presented to the player. Once the common bets are applied across the various leagues, the player engages in game play until the end of the game period to determine a winner as in step 110. Alternatively, referring back to step 108, if the player does not want to join another league, then the player proceeds to step 110 and engages in game play until the end of the game period to determine a winner.
The above described game and rules comprise an algorithm including the steps for implementing and operating a fantasy gambling game system. The algorithm may be encoded as computer executable instructions that is embodied on a computer readable medium and which, when acted on by a computer device, transforms the instructions into a tangible user interface image that may be selectively displayed to a user using either the same or a different computing device. The above rules and operations may be embodied in computer code and be hard coded on a particular processing device that is able to execute the instructions encoded thereon. In one embodiment, the computer readable instructions are stored on a fixed storage medium that is acted upon by a server that conditions a processor to generate a user interface display presented to a remote user accessing the server. The rules may be packaged may be into “rulesets” in a database stored on a computer readable medium. Any league may play under any one ruleset, and the system pulls the league's ruleset from the database and the code applies the rules as needed in order to perform game functions.
After establishment of various fantasy betting communities each including a plurality of different players that have wagered on different sporting contests and/or events within particular sporting contests, the system is able to selectively query and mine the data associated with the players across all communities in order to produce a revenue source for the system operators. The system provides for selling user collective data intelligence whereby the system automatically monitors selections of the most successful players within the community, aggregate this information whenever trends are identified and sell this aggregated data back to one or more of the players. The monitoring may be done automatically at predetermined intervals by the system or may be performed manually by a system operator. The monitoring is continual and, as more players are entered into the system, the database being queried is refreshed to ensure the most current information is available.
Additionally, while the above description with respect to FIG. 1 references creation of a league by a commissioner who sets the rules and parameters for the game being played in a respective community, it should be appreciated that the same functionality and operation may be performed by a system operator. This advantageously enables the creation of public leagues and communities, each potentially being governed by different rule sets, that players may join without being specifically invited. Thus, if a player enjoys fantasy sports betting but friends of the player do not, the player can still participate in the game. Furthermore, the inclusion of these public leagues enables the system to mine and derive additional data that may be used as a source of revenue as will be described below.
FIG. 2 is an exemplary algorithm implemented by the system that generates revenue for the system operator. In step 202, at least one community including a plurality of players is created and the players engage in at least one cycle of betting on sporting contests and/or events taking place during a particular sporting contest or any other type of competition that has a definable outcome. In step 204, the system automatically derives data associated with the individual players in at least one community. The derived data is automatically analyzed to determine if the success rate of each player in the community meets a success criteria in step 206. The success criteria may include but is not limited to, (a) data identifying the number of successful bets, (b) data indicating a trend of success over a specified time period, and (c) data identifying success of bets based on the type of bet and/or the frequency of the bet. This data may be collated and packaged in a manner than can be used by other players in the same or different communities to help improve their success rate as in step 208. Once this data is collated and packaged, the system may offer the packaged data for sale to players as shown in step 210.
An example of how the data may be presented to the user is in the form of a leader board which that will showcase a rank for each player in the game thereby making it easy for the other players in any community who are the best and most successful players. The leader board may be categorized to show the best players based on the type of bet selected from all available types of bets. Another user control or feature comprises being able to place a single bet and applying it to multiple leagues. The leader board may also provide for compiling and providing to a user a comprehensive view of a particular user's betting statistics such as winning percentage on specific bet types, total earnings year-to-date and being able to track this information year over year and across multiple leagues.
Additionally, the leader board may be organized to display trend data indicating which players have been most successful over a predetermined time period thereby providing users with knowledge of bettors that are “hot” and have consistently been making successful winning bets. For example, if Player X has been really hot the past few months and is the #1 ranked player (determined by percentage of correct bets) across all of the leagues on our site. The system advantageously provides Player X a forum to input predictions for future sporting contests and events can be presented for view by other players. The full set of prediction data in this forum would be protected from general access via a log-in screen, for example. The system would generate a teaser message that provided a subset of the protected data to all of the players. The teaser message would enable the other players to pay an access fee thereby enabling them to access the full set of protected data in order to improve their performance. The player would pay an access fee to the system operator in exchange for data representing credentials for accessing the protected data.
Alternatively, if Player Z wanted targeted information on a particular sporting contest or event within the sporting contest, the system provides Player Z with the ability to contact Player X to inquire about a particular pick. The system allows Player X to charge a predetermined fee, for example, a micro fee for example, $0.25 to $0.50 per targeted prediction. Upon payment by Player Z, to Player X, the system would automatically take a percentage of the micro fee and derive revenue therefrom. The system may also allow players to group a set of targeted transactions and charge a fee for obtaining predictions on a set of contests or events. For example, Player X might post 10 or more predictions per week if he's a top player and the players buying the picks may buy multiple picks per week.
In a further embodiment, data representing how “hot” a player is at any given time is shown in conjunction with the name of the player. Sports bettors are always interested in getting advice from the hot hand and if a player is ranked 30^thall time in the game but over the past 6 weeks he's been the hottest player as indicated by winning the highest number or percentage of bets, the system enables the hot player to sell predictions either via micro fee transaction or in a forum that requires payment for access.
An additional mechanism by which the system can generate a revenue stream for the operators is to enable management of betting restrictions. For example, betting may be disabled for games under one or more particular conditions (e.g., at a defined time before the start of the game). If betting is restricted, a user may request to bypass the betting restriction in order to, for example, be able to place a bet past that defined time but before the start of the game. By requesting the bypass, the player must pay a bypass transaction fee which is collected by the system operator and provides a source of revenue. Once the fee is paid by the player, the player is provided access to the previously restricted content which allows the player to overcome the condition. For example, a user will have the ability to purchase a bypass to bet up until the last minute before the start of the game.
Another aspect for generating revenue from the system is collecting fees for league management. For each community and/or league created by a user, a fee for facilitating and/or managing may be assessed and collected. For example, a group of people or entities may wish to form a league based on each individual or entity providing input of a fantasy amount or stake for the season with the winner collecting the sum total of all of the stakes at the end of the season and an operator collects fees for managing the league formation, collection of participant stakes, and distribution of winnings As a specific example, if 10 individuals wish to form a league with each putting in a fantasy amount of $50, then the winner at the end of the season will collect the fantasy pool of $500 at the end. The operator will collect a fee for one or more of each fantasy amount contribution by a participant, holding the fantasy pool, and distributing the pool to the winner at the end.
FIG. 3 is a block diagram of the fantasy sports gaming system according to invention principles. The hardware shown and described herein is able implement the instructions described above with respect to FIGS. 1 and 2 which represents an algorithm for creating and operating the system. The system includes a server 302 that is connected via a communication network 304 to a plurality of user devices 306. While only three user devices are described herein, it is apparent that any number of user devices may connect to the server 302 via communication network 304. The user devices 306 allow users to transmit and receive data associated with the fantasy gaming system in order to engage in game play as discussed above. User devices 306 include at least one of a computer, a tablet computing device, a cellular phone, a smartphone, a conventional telephone and any other device able to receive input from a user and transmit data corresponding to the user input for receipt by the server 302 as well as receive requested data from the server 302. In one embodiment the user device is a cell phone. The cell phone is able to place a bet on a contest by inputting a text message and sending that text message via the communication network 304 for receipt by the server.
The server 302 includes a processor 308, a repository 310 and a user interface generator 312. The repository 310 includes a plurality of instructions stored therein that direct the operation of the fantasy sports gaming system. The instructions may be in the form of machine executable code that are able to perform the functions described hereinabove with respect to FIGS. 1 and 2. When an activation of a particular feature is requested, the processor 308 executes the instruction corresponding to the particular feature that is stored in the repository. Upon execution and activation of the feature, the processor conditions the user interface generator 312 to generate a display image for display to at least one user that allows the user to make use of the particular feature. The system is also in communication with an external source of betting data 314 from which category of bets, types of bets and parameters of bets may be obtained for use during game play. Alternatively, betting data may be stored locally in the repository 310 or acquired from external source 314 and cached in the repository 310. Examples of data retrieved from external sources includes sports event data (teams, schedules/fixtures, game times, game results) and betting odds (for a given game, what odds were being set) and contest results data that provides the ability to score/settle bets.
The processor 308 executes an initial instruction which conditions the user interface generator 312 to generate a home page for presentation to at least one user upon the user accessing the system at an address on the communication network. An example is a home page encoded in a particular data format (e.g. HTML, with JavaScript and CSS) that is selectively accessible by users via a web address using a communication protocols such as TCP/IP and HTTP. FIG. 4 is an exemplary screenshot of a home page generated by the system for display to at least one user. The home page provides a gateway for users of the system to access their accounts and initiate additional system functions. The display image includes a league creation of user selectable image element 402 that, when selected, initiates execution of a league creation algorithm by the processor 308. The league creation algorithm includes a set of instructions as described above with respect to FIG. 1 that allows a user to create a league or community in which the fantasy sports game is played. The home page further includes a field 404 that receives data corresponding to a unique league identifier access code input by a user using user device 306. Upon entering information by the user in field 404, a league join image element 406 is selected by the user using an input device such as a mouse or touch screen. Upon selection of image element 406, the processor initiates an algorithm that enables the user to join the league or community that is associated with the unique league identifier access code.
Once the user has either created or joined a league including setting up a personal username and password, the home page provides a username field 408 and a password field 410 that allows the user to securely access the system. Once the username and password are entered in the respective fields, the processor receives the user credential data and authenticates the entered data with user profile data stored on repository 310. Once authenticated, the user can access all areas of the system that are deemed public, for example, general leader board information as well as restricted access to the leagues and communities to which the user belongs.
FIG. 5 is an exemplary screen shot of a user interface display image 500 that is generated by generator 312 in response to initiation of the league creation algorithm. Display image 500 includes a window 502 having a user-fillable field for receiving data representing a league/community name. A creation image element 504 is selected after league name data is entered and the league is created. Data associated with the league is stored in the repository 310.
The league is created and designed by a user by interacting with a plurality of different user interface display images that allow for selection of all the rules for the league. These image elements may include a candidate list of rules from which the user can select. Additionally, the image elements may be able to receive user input allowing the user to define a specific rule to be implemented in the game being created.
Upon creation of the league by the user, a display image 600 as shown in FIG. 6 is presented to the creating user that includes the unique league access identifier 602. The identifier may be for example, a universal resource locator or other link that enables a user to access the league on the server 302 of the system. The identifier 602 can be copied and pasted, in a known manner, into an electronic message. Alternatively, the display image may include a selectable image element that executes instructions for an electronic mail application that enables the user who created the league to message other people to suggest that they join the league. In this embodiment, the identifier is automatically embedded in the message being sent by the system. When a user receives and selects the identifier 602, the processor 302 conditions the User Interface Display Generator to generate a display image 700 shown in FIG. 7 that enables the user who selected the identifier to join the league. The display image 700 in FIG. 7 includes an input field 702 for receiving a code or other data from the user that notifies the system as to which league the player wants to join. Once entered, the player can select image element 704 which causes the code entered in field 702 to be sent to the processor 302. The processor 302 queries the repository for league data that matches the code entered in field 702 and conditions the user interface display generator 312 to generate a display image including the league data and formatted in particular format. The format may be for example, a standard format determined by at least one of the user who created the league, the system operator and the individual user.
Now that the user has joined a league to play a game, the system generates a plurality of display images as shown in FIGS. 8-11 that enable the player to engage in game activities. The system generates the display image 800 as shown in FIG. 8 which includes a first window 802 including information representing the category of bets available to the player for the game. A selection box 803 is positioned proximate the betting category information and allows the player to select the category of bet to make for the current betting period. The display image 800 also includes a second window 804 including data representing an amount of fictitious money/player bankroll that may be bet on the selected bet category. Upon selecting the category, the user selects the next button 805. Data representing the betting category selected by the user is provided to the processor 308 which queries a source of betting information in order to aggregate all of the available bets and types of bets for the selected betting category. This query may be performed on the repository 310 which may include a source of betting information as well as on an external source of betting information 314 (FIG. 3). The results of the query are presented in the display image 900 in FIG. 9.
FIG. 9 includes a window 902 that presents the results of the query and organizes the results. The results are presented in column and row format with the row including the information associated with a respective contest and the columns 903 containing information about the respective contest including the date, sport, teams involved, etc. Additionally, there are columns 904 associated with types of bets available for the respective contest. This format is described for purposes of example only and the data may be formatted in any manner as determined by the system operator or the league creator. In this embodiment, the user is presented with a column for a money bet, a spread bet and an over/under bet. The bet type columns include at least one user-selection box enabling the user to select a bet type to be placed along with the parameters of the bet being placed. The format shown in FIG. 9 is described for purposes of example only and the information described herein may be presented in any format or design. FIG. 9 also includes a reverse navigation button 905 that, when selected, allows a user to return the display image of FIG. 8. A forward navigation button 906 is also included and, when selected, causes data representing the betting selection and parameters to be used by the processor 308 to condition the user interface display generator 312 to generate the display image in FIG. 10.
FIGS. 10A-C include a display images that lists all of the bet types and bet parameters that were selected in FIG. 9 and enables the user, in column 1002 to enter an amount of money from the players bankroll to be wagered on each respective bet. FIG. 10A also includes a column 1004 that enables a user to apply a bet enhancement, such as a lock bet or a max bet described above with respect to FIG. 1. Whether or not these enhancements are available depend on the rules of the league and game established by the user that created the league. FIGS. 10A-10C include image elements 107 corresponding to the type of available bet enhancement will be presented to the user in column 1004. In FIG. 10A, there image elements 1007 remain unselected and thus no bet enhancement is applied to any wager listed. In FIG. 10B, a respective image element 1007 a from the set of image elements 1007 representing a type of bet enhancement is highlighted thus indicating that the corresponding bet enhancement is only applied to one of the listed bets placed by the user. FIG. 10C includes shows the one of the respective image elements corresponding to a type of bet enhancement for each bet placed by the user and that the system will execute the rules to apply the selected enhancement to the bet when the bet is settled by the system. FIG. 10 also includes a reverse navigation button 1005 enabling the user to return to the display image in FIG. 9 and a forward navigation button 1006 which, when selected, transmits the information entered in at least one of columns 1002 and 1004 for use in generating the display image shown in FIG. 11.
FIG. 11 includes a display image that presents a window 1101 including summary of the different contests the player has selected to place bets on as well as all associated information about the bet including the bet type, bet parameter, amount risked, whether or not any bet enhancements have been selected and the amount to be won if the bet is successful. A confirmation image element 1102 is included that enables the user to confirm and place the bets listed in the window 1101. By selecting image element 1102, data representing the contest, bet category, bet type, bet parameters, amount risked and amount to be won is transmitted for storage in the repository 310 such that, after completion of the contest, the stored bet selections for the respective player can be compared with the outcome to determine how many of the placed bets were successful for the given betting period. This comparison is performed by the processor 308 which executes a reconciliation algorithm that determines whether or not the bets were successful.
At any point, a player may selectively access a history of betting activity as shown in FIG. 12 by, for example, selecting a link on the league home page. By selecting this link, the processor queries the repository for bets placed by the player and produces a report such as the ones shown in FIG. 12. These reports may include a standard set of information such as the league name, the type of bet, the date the bet was placed, the type of contest, information about the actual contest, the parameter of the bet, the result of the bet, the amount risked, whether or not an enhancer was applied, and an amount won. These categories as shown herein represent the respective columns in the display images of FIG. 12. Alternative image displays of betting history and statistics are shown in FIGS. 13 and 14.
FIGS. 15A and B and 16 are alternative display images presented to the user that enables the user to apply a bet enhancer to a particular bet. FIG. 15 presents the user with the Max Bet option for the particular league. Upon selecting the Max Bet image element, the system automatically displays the image shown in FIG. 15B listing the schedule of available Max Bet values by betting period as determined by the rules. FIG. 16 represents an exemplary screen shot that includes a column entitled lock bets. For each contest, image elements representing the available lock bets are presented for selection by a user. Once selected, the image elements changes color to notify the user that the particular type of lock bet has been selected for a respective contest.
FIG. 17-19 are additional exemplary screen shots of player and league information that are selectively presented to the user and enhance the community gaming experience. FIG. 17 is an exemplary display image that includes a plurality of individual display windows including different types of information associated with the league. A first window 1702 includes a tab activated system whereby a user can select a tab and display a respective type of data. The exemplary tabs shown enable display of the league standings, the existence of any live bets and the league history. A second window 1704 displays information identifying league or community members that had the best and worst performances. Additionally, window 1706 provides an interface for users to post messages to other league members that advantageously encourages the social aspect of the league. FIG. 18 is a display image that includes the betting statistics associated with a respective player.
FIG. 19 is an exemplary display image of a leader board that provides a plurality of information to a user of the system. In window 1902, the standings for a respective betting period for the respective league are presented. In window 1904, a list of data representing the most successful players across all leagues are shown and in window 1906, data representing past overall weekly winners is displayed. The types and organization of information shown in FIG. 19 are described for purpose of example only and the user or league creator may determine what information is shown as well as how the information is formatted thereby providing a more customized experience for each player and/or league. Additionally, the leader board information may also include user selectable icons associated with a particular element of data that enables a player to access additional information about the data. For example, in window 1904, if an icon appears next a players name, the current user may select the icon and be presented with a display image including data representing the selected players future predictions. Additionally, the future prediction data may be incomplete and provide the current user the ability to access a full set of predictions by paying a fee thereby generating revenue for at least one of the system operator and the player who makes the predictions. In an alternate embodiment, the leader board may provide an indicator associated with a particular player that identifies a characteristic about the player. The characteristics may include but are not limited to how successful the player has been over a predetermined time period, how unsuccessful the player has been over a predetermined time period, a status identifying the players standing in their respective league, availability of the player to make predictions, data identifying the number of additional players have used information from the particular player, data identifying total amount of monies won using information provided by the player, etc. These characteristic indicators are presented to players across the entire system and allow the players to determine if at least one particular player may be able to provide helpful information for future betting periods. A user selectable icon may be associated with the players having a particular characteristic indicator showing that allows players to contact the particular player to obtain information therefrom. By selecting the icon, the player is required to pay a fee to at least one of the particular player and the system operator to have access to the particular player's information.
Although the invention has been described in terms of exemplary embodiments, it is not limited thereto. Rather, the appended claims should be construed broadly to include other variants and embodiments of the invention which may be made by those skilled in the art without departing from the scope and range of equivalents of the invention. This disclosure is intended to cover any adaptations or variations of the embodiments discussed herein.

Claims

1. A method for providing an interactive gaming system for a plurality of users connected via a communication network comprising the activities of:

creating at least one community for the interactive gaming system including rules defining parameters for the gaming system, the community including a plurality of players;

allocating an initial bankroll to each of the plurality of players;

enabling each of the plurality of players to wager at least a portion of their allocated bankroll in accordance with the rules;

providing information to a requesting one of the plurality of players for assisting the requesting player in making a wager;

ranking each of the plurality of players based on success in wagering by each of the plurality of players.

2. The method of claim 1, wherein said activity of creating comprises

setting the rules, wherein the rules identify at least one type of contest able to be wagered on by the plurality of players;

at least one type of wager to be associated with the selected contest.

3. The method of claim 2, wherein

said at least one type of contest includes at least one of a sporting event and non-sporting event that includes competition between competitors in at least one task and having a definitive outcome.

4. The method of claim 2, wherein the at least one type of wager includes

selecting the outcome of the contest and selecting an outcome of an event within the contest.

5. The method of claim 2, wherein the rules include an allotment of wager types including at least one of

a max bet representing a maximum amount of the players bankroll able to be wagered on particular contest, and

a lock bet enabling a player to multiple an amount able to be won on a particular wager without risking an additional amount of the bankroll.

6. The method of claim 5, further comprising the activity of

providing additional wager types to a player upon receipt of payment from a requesting player, wherein the amount of payment necessary to purchase additional wager types is defined by the rules.

7. The method of claim 1, wherein the information requested by players includes at least (a) projections made by other players within the community and between a plurality of communities, (b) results wagers made by other players within the community and between a plurality of communities, (c) trend data representing the success of a player over given time period, (d) lists of the most successful players over a defined periods and (e) data representing the success of a player based a the type of contest and type of wager.

8. The method of claim 7, further comprising the activity of

providing the requested information to a player upon receipt of payment from a requesting player, wherein the amount of payment necessary to purchase the information is defined by the rules.

9. The method of claim 7, further comprising the activity of

providing the requested information to a requesting player upon receipt of payment from the requesting player, wherein the amount of payment necessary to purchase the information is defined by the player providing information.

10. The method of claim 7, wherein the information is provided by at least one of the system operator and another player upon receipt of payment from the requesting player by the system operator.

11. A interactive gaming system comprising:

a processor that

creates at least one community in accordance with a set of rules defining parameters for the system, the at least one community being accessible by a plurality players,

allocates an initial bankroll to each of the plurality of players,

enables each of the plurality of players to wager at least a portion of their allocated bankroll in accordance with the rules,

provides information to requesting players of the plurality of players for assisting in making a wager, and

ranks each of the plurality of players based on success in wagering;

a repository storing data representing

the rules for creating the at least one community,

wagers made by the plurality of players in each of the at least one community,

information for assisting players in making said wagers;

an image generator connected to said processor that generates display images in response to a control signal from said processor and enables the plurality of players to access said system; and

an interface connects said processor to the plurality of players through a communication network and provides said display images from said image generator to said plurality of players.

12. The system of claim 11, wherein

the rules identify at least one type of contest able to be wagered on by the plurality of players;

at least one type of wager to be associated with the selected contest.

13. The system of claim 12, wherein

the at least one type of contest includes at least one of a sporting event and non-sporting event that includes competition between competitors in at least one task and having a definitive outcome, and

the at least one type of wager includes an outcome of the contest and an outcome of an event within the contest.

14. The system of claim 11, wherein

said processor accesses an external source of data not stored in said repository through said interface.

15. The system of claim 12, wherein

the rules include an allotment of wager types including at least one of

a max bet representing a maximum amount of the players bankroll

able to be wagered on particular contest and

16. The system of claim 15, wherein said processor

supports providing additional wager types to a player upon receipt of payment from a requesting player, wherein the amount of payment necessary to purchase additional wager types is defined by the rules.

17. The system of claim 11, wherein the information requested by players is stored in said repository and includes at least (a) projections made by other players within the community and between a plurality of communities, (b) results wagers made by other players within the community and between a plurality of communities, (c) trend data representing the success of a player over given time period, (d) lists of the most successful players over a defined periods and (e) data representing the success of a player based a the type of contest and type of wager.

18. The system of claim 17, wherein the processor

provides the requested information from said repository to a player upon receipt of payment from a requesting player, wherein the amount of payment necessary to purchase the information is defined by the rules.

19. The method of claim 17, wherein the processor

provides the requested information from said repository to a requesting player upon receipt of payment from the requesting player, wherein the amount of payment necessary to purchase the information is defined by the player providing information.

20. The system of claim 17, wherein the information is provided automatically by the processor and another player upon receipt of payment from the requesting player by the system operator.