US20110028206A1

US20110028206A1 - Fantasy league payment and administration

Info

Publication number: US20110028206A1
Application number: US12/844,825
Authority: US
Inventors: Paul W. Charchian
Original assignee: LeagueSafe LLC
Current assignee: LeagueSafe LLC
Priority date: 2009-07-28
Filing date: 2010-07-28
Publication date: 2011-02-03

Abstract

A fantasy league administration system is described herein that simplifies responsibilities of league administrators and improves the experience of managing a league for both commissioners and league participants. During the pre-season phase, the system helps commissioners setup a league to start the new season by copying information from a previous league season. Also during the pre-season, the system allows the commissioner to set deadlines for one or more events, such as payment of league participation fees. As the season begins, the system allows administrators to receive fees late based on previously configured late payment options, and to make payments to vendors or others from a league account managed by the commissioner and/or the league participants. As payments arise, the commissioner may submit a payment request to the league and the league may vote to approve or deny the payment.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 61/229,268 (Attorney Docket No. LEAGUESAFE003) entitled “ADVANCED TRANSACTION AND DECISION MANAGEMENT,” and filed on Jul. 28, 2009, which is hereby incorporated by reference.
This application is related to U.S. application Ser. No. 12/038,427 (Attorney Docket No. LEAGUESAFE002) entitled “TRANSACTION AND DECISION MANAGEMENT SYSTEM, SUCH AS FOR FANTASY SPORTS,” and filed on Feb. 27, 2008, which is hereby incorporated by reference.

BACKGROUND

A fantasy sport is a game where fantasy owners build a team that competes against the teams of other fantasy owners based on the statistics generated by individual players or teams of a real professional sport. Fantasy team owners can trade, cut, and sign players just like a real sports owner. One common variant converts statistical performance into points that are compiled and totaled according to a roster of a fantasy team's players. These point systems are typically simple enough to be manually calculated by a “league commissioner” that oversees a group of fantasy teams. Variants make complex use of computer modeling of actual games based on statistical input generated by professional sports.
A seminal moment for the growth of fantasy sports was the rise of the Internet in the mid-1990s. The new technology lowered the barrier to entry to the hobby as web sites could quickly compile statistics online, and news and information became readily available. A trade group for the industry, the Fantasy Sports Trade Association was formed in 1998. The Fantasy Sports Trade Association estimates that 30.1 million people age 12 and above in the U.S. and Canada play fantasy sports. A 2006 study showed 22 percent of U.S. adult males 18 to 49 years old, with Internet access, play fantasy sports. Fantasy sports are estimated to have a $3-$4 Billion annual economic impact across the sports industry. Fantasy sports are also popular throughout the world with leagues for football (known as soccer in the United States), cricket, and other non-U.S. based sports.
LeagueSafe provides an online finance management system (e.g., http://www.leaguesafe.com/) designed to meet the needs of fantasy sports players. The online finance management system includes an on-line escrow service that secures and manages fantasy leagues' finances. In the preseason, participants deposit league fees in an insured bank account, where the fees stay throughout the sport season. At the end of the season, the online finance management system returns the league fees to the league's team owners at the direction of the commissioner. The online finance management system is described in further detail in U.S. application Ser. No. 12/038,427 referenced above.
The online finance management system greatly simplifies and streamlines finance management, deposits, and payments. The system offers multiple methods for deposit and withdrawals of entry fees. For example, participants can fund their league balance via electronic funds transfer (EFT) or credit card, and participants can withdraw funds via preloaded debit card, paper check, and EFT. The system allows leagues to automate and track entry fee distribution, and offers online 24/7 access to all financial record keeping. In addition, the system provides self-governing mechanisms for managing fund allocation to participants.
While online league finance management systems have greatly improved the experience for players and participants in general, there are still a number of administrative tasks that are difficult for league commissioners and other league administrators (e.g., nominated participants). The league commissioner often has many responsibilities, including setting up and starting a league season, requesting entry and other fees for league participants, purchasing items for the league (e.g., league trophies, t-shirts or other items), gathering and sifting through various league-related information (e.g., rules for payment, duration of the season, and so forth), managing relationships with vendors, overseeing league finances, and managing payments at the end of the season or upon occurrence of special events (e.g., early withdrawal of the league, mid-season payouts, and so on). The league commissioner often manually performs these tasks, resulting in reduced accountability and increased potential for errors.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram that illustrates components of the league administration system, in one embodiment.

FIG. 2 is a flow diagram that illustrates processing of the league administration system to allow a commissioner to setup a league, in one embodiment.

FIG. 3 is a flow diagram that illustrates processing of the league administration system to allow a commissioner to set league financial options, in one embodiment.

FIG. 4 is a flow diagram that illustrates processing of the league administration system to notify participants of a commissioner reimbursement, in one embodiment.

FIG. 5 is a flow diagram that illustrates processing of the league administration system to transfer funds from a participant to a league, in one embodiment.

DETAILED DESCRIPTION

A league administration system is described herein that simplifies responsibilities of league administrators and improves the experience of managing a league for both commissioners and league participants. A league typically involves financial and other activities that can be logically divided into three phases: 1) the pre-season phase, 2) the mid-season phase, and the end-of-season phase. During the pre-season phase, the system helps commissioners setup a league to start the new season by copying information from a previous league season, a process referred to as league rollover. For example, the system may copy information such as league participants, team composition, financial management rules, league management fees, and so forth. This greatly simplifies the process of setting up a new league. Also during the pre-season, the system allows the commissioner to set deadlines for one or more events, such as payment of league participation fees, so that the commissioner will have funds available to purchase pre-season items, such as products or services from an external vendor. As the season begins, the system allows administrators to receive fees late based on previously configured late payment options, and to make payments to vendors or others from a league account managed by the commissioner and/or the league participants. As payments arise, the commissioner may submit a payment request (or reimbursement request for payments already made by the commissioner) to the league and the league may vote to approve or deny the payment.
The league administration system manages one or more accounts on behalf of leagues, participants, commissioners, and vendors. As events occur that give rise to financial obligations from one entity to another (e.g., from league to vendor, from participant to league, from league to commissioner, and so forth), the system manages transfers between accounts to satisfy the financial obligations. For example, to pay a season initiation fee, a participant may direct the system to transfer money from the participant's account to the league account. The commissioner may then purchase goods for the league from a vendor by directing the system to transfer funds from the league account to a vendor account. By managing these transactions, the system keeps flows of money out in the open, where league participants may audit and review payments. The commissioner also is not responsible for storing funds in the commissioner's own personal, external account over which participants have no authority or control. Thus, the league administration system simplifies league management and payments for commissioners, participants, and vendors associated with fantasy sports leagues.
FIG. 1 is a block diagram that illustrates components of the league administration system, in one embodiment. The system 100 includes a league management component 110, league data store 120, account management component 130, commissioner reimbursement component 140, vendor payback component 150, league rollover component 160, payment deadline component 170, notification component 180, and user interface component 190. Each of these components is described in further detail herein.
The league management component 110 manages non-financial league information, such as which owners are associated with each league, an identity of a commissioner of each league, contact information for participants, configuration preferences, and so forth. The league management component 110 collects and stores league information in the league data store 120.
The league data store 120 is a data store that persistently stores league information between participant sessions with the system. The league data store 120 may include one or more files, file systems, hard drives, databases, cloud-based storage services, and other facilities for storing user data. The league data store is used by the league management component 110 to storage non-financial information, and the account management component 130 to store financial information. The league data store 120 is the central repository for storing various information about leagues. The league data store 120 may be distributed for scalability or other reasons into multiple data stores.
The account management component 130 manages accounts for one or more league participants, commissioners, leagues, and vendors. The system 100 may provide each user of the system with an individual account. The account may correspond to a physical account, such as a bank deposit account, or a virtual account, such as a shared bank account where the account management component 130 performs accounting to track one or more balances for each user. A user's account contains funds associated with that user and under that user's control. For example, a participant account may contain funds earned by a team owner from past seasons' winnings, while a league account may contain funds paid by team owners to join the league. While a participant account may be controlled by a single participant (e.g., for purposes of withdrawing funds, purchasing items with the funds, and so forth), a league account may be controlled by all of the members of the league or by the league commissioner, based on how the participants and/or commissioner set up the league.
When the commissioner directs league winnings based on owner performance at the end of the season, the system transfers funds from the league account to one or more participant accounts. The balance of the participant account (and league account) is visible from a home page provided by the system for each participant. Participants with a positive balance can withdraw all or part of the funds, make deposits to future leagues from the balance, or leave the funds in their account. The participant account may span multiple leagues and provides a single depository entity for all accumulated winnings, regardless of sport or season.
When a new season begins, in lieu of paying by other means a participant with a positive balance in his/her participant account can make league deposits from funds held in the participant's account. When this occurs, the account management component 130 transfers a requested balance from the participant's account and applies the balance as a deposit to the appropriate league account.
The league data store 120 includes entries for each account that include the balance of each account. For example, the system may include a database with an accounts table that stores a row for each account, whether for participants or leagues. The system may or may not actually create separate physical accounts for each purpose. For example, the system may utilize a single physical bank account to hold funds for all leagues and members and track which funds in the physical bank account are associated with each league or participant. Vendors and other entities associated with the system 100 may also have accounts for making and receiving payments managed by the system.
The commissioner reimbursement component 140 manages costs incurred by a league commissioner on behalf of the league. Commissioners often incur costs before a season ends, and in many cases before a season begins related to setup of the league. Sports seasons using the league administration system 100 work in three phases: 1) before the deposit deadline, 2) after the deposit deadline, but before the end of the sport's regular season, and 3) at the end of the sport's regular season. Each phase offers different feature sets appropriate for that phase.
The commissioner reimbursement component 140 provides for payments to the commissioner before the end of the season. League participants may opt to enable the component 140 so that the commissioner can be reimbursed for funds spent on behalf of the league without waiting for the usual end-of-season withdrawal timeframe. For example, such funds may include funds used to pay for third-party administrative tools, and a commissioner may be reimbursed by the system any time after the league's deposit deadline. In some embodiments, the commissioner activates the feature by indicating the reimbursement amount that the commissioner intends to withdraw from the league balance. After the league account balance reaches the reimbursement amount, the component 140 transfers the indicated amount to an account associated with the commissioner that is managed by the system 100. The commissioner may then withdraw funds up to the reimbursement amount.
In some embodiments, the league administration system 100 notifies participants who join a league in which the commissioner reimbursement component 140 is enabled that the commissioner has opted to use commissioner reimbursement. Participants who disagree with the commissioner's intention to use commissioner reimbursement can discuss the matter with the commissioner through the system 100 (e.g., via electronic messaging), and may withhold any payments into the league's balance until a resolution is reached. In some embodiments, the commissioner reimbursement component 140 may provide approval mechanisms for commissioner reimbursement. For example, the component 140 may allow the commissioner to submit a proposed expense that league participants can vote to approve. Upon approval, the commissioner can spend the money and seek reimbursement. The component 140 will reimburse the commissioner automatically for previously approved expenses. Alternatively or additionally, the commissioner may submit an amount for reimbursement after spending funds and risk that participants of the league may or may not approve the expense. If the expense is approved, then the component 140 transfers the reimbursement amount to the commissioner's account. In this way, the system 100 makes management of an additional common occurrence in the management of league finances well-defined and reduces worry and risk by participants about how money is used and disbursed.
The commissioner reimbursement component 140 may add one or more fields to the league configuration information stored in the league data store 120 to indicate whether the component 140 is enabled as well as other parameters, such as a threshold allowed reimbursement that a commissioner can receive. The stored data may also include additional fields in the participant account information to track how much a particular commissioner has received in reimbursements, and other statistics used for tracking and reporting information to other participants. The system 100 may also maintain an audit trail (e.g., in a database table) of each transaction, including reimbursements, handled by the system 100 for later review by participants or others.
The vendor payment component 150 manages payments associated with leagues to external vendors. An operator of the league administration system 100 may partner with select third-party vendors that offer services to fantasy leagues. For example, a vendor may provide t-shirts, statistical reporting, or trophies that each of the league participants will receive. In some embodiments, the system 100 allows any fees associated with these services to be paid from a league balance through the vendor payback component 150. When a participant's league is enrolled in vendor payback, the vendor will receive funds from the league's balance once the league's balance meets the amount owed to the vendor or is approved by the league.
In some embodiments, the vendor payback component 150 provides a voting procedure for league participants to approve the use of league funds for vendor expenses. For example, in the previous example, league participants may vote to have t-shirts made that relate to the league and to spend a certain amount of league funds to obtain the t-shirts from a vendor. The component 150 may allow participants or the commissioner to set up such voting to occur by unanimous consent, majority rule, or other voting process. Alternatively or additionally, participants may configure a league to authorize the commissioner to approve vendor payments with or without restrictions (e.g., up to a certain amount or percentage of the league balance.
When a vendor payback occurs, the vendor payback component 150 deducts the payback amount from the league balance. The system may also send an electronic notification (e.g., an electronic mail message or short message service (SMS) text message) to the vendor indicating that a payment has been made. The system may also send the payment to the vendor electronically, such as in the form of an Automated Clearing House (ACH) payment. Alternatively or additionally, the system may provide vendors with vendor accounts from which the vendor can withdraw a balance using any of the same forms in which a participant can withdraw funds (e.g., prepaid debit card, EFT/ACH, paper check, and so forth). Vendor payback is an optional feature that further simplifies cash management for league participants.
Similar to commissioner reimbursement, the vendor payback component 150 may include modifications to the league configuration to indicate whether the feature is enabled for a particular league, as well as information identifying which participants can approve vendor payments. The system may also store auditing information about vendor payments made through the system 100 for later tracking and reporting to participants or others.
The league rollover component 160 handles setup of new league seasons using at least some prior season information as a template. A commissioner or other participant can create a current-season league by copying data from a prior season league, called league rollover. For example, a commissioner could create a 2009 NFL league based on a 2008 NFL league using league rollover. The system may copy information such as the participants associated with the league, makeup of teams, an owner name, owner email address, team name, entry fee, and so forth. In some embodiments, the system restricts league rollover to users with commissioner-level rights.
Upon receiving a request to rollover league information, the league rollover component 160 may copy data from one row of a league database table to a new row in the league data store 120. The component 160 may also reset certain fields to default values, such as those that reflect activity that has transpired within the league (e.g., entry fee payments), in preparation for the new season. League rollover saves the commissioner and other participants valuable time by using already known values to pre-populate aspects of a league that are not likely to change from season to season.
The payment deadline component 170 allows commissioners to alter a league's default deposit deadline to better accommodate the needs of the league. Deposit deadlines may be set up by the league commissioner to reflect a timetable needed for initiation fees, reimbursement fees, or other amounts that the commissioner needs to pay by a particular time. The commissioner may also instruct the component 170 to allow late payments with potential additional fees for the late payment.
In some embodiments, the payment deadline component permits a commissioner to allow deposits (e.g., late payments) from league participants after the normal pre-season deposit deadline. The deposit process works as it would prior to the deposit deadline, with two potential additional fees. First, the system may impose a late fee on all late transactions. The late fee may be a flat amount, a percentage of the deposit amount, or calculated based on another formula (e.g., how late the payment is). Second, the league may choose to impose a fee on all late transactions. This fee may be a flat amount designated by the league commissioner, or calculated according to some other formula and/or voting procedure. The system 100 deposits late fees into the league's account or other appropriate accounts. In some cases, the system 100 may extend credit to late paying participants and may charge interest or a fee to compensate the operator for the extension of credit. In some embodiments, the system 100 provides a notification to league participants when late payments are allowed and/or are received.
A participant that owes a late payment, such as an entry fee, may have a negative balance or other accounting in the league data store 120 to track late payments. The league information stored by the system 100 may include information about when payments were made and the due date for payments to determine whether a payment is timely or late. The payment deadline component 170 may invoke the notification component 180 to notify participants and/or commissioners when payments are late.
In some embodiments, the payment deadline component 170 allows commissioners to reassign a deposit deadline to an alternate date. The new deadline then acts as the league's standard deposit deadline. For example, the league commissioner may want money up front to make a purchase on behalf of the league (e.g., for t-shirts or other items). Participants may make payments any time before the deadline. Those that wait until after the deadline cannot make deposits unless the league commissioner opts to allow deposits beyond the deadline by invoking the late payment option described further herein.
The notification component 180 notifies users of actions related to the users or one or more leagues. The notification component 180 may provide a variety of notification types, such as web page pop-ups, email messages, text messages, push notifications to a smartphone, and so on. The notification component 180 may provide notifications when money is transferred to or from a participant, when a commissioner makes changes to league settings for a league to which the participant belongs, when a commissioner sets deadlines or uses league funds, and so forth. The notification component 180 keeps users up to date on relevant occurrences that happen in between users' sessions with the system (e.g., though the user interface component 190). The notification component 180 may provide configuration settings that a participant or commissioner can modify to increase or decrease notifications or select particular events that generate a notification.
The user interface component 190 provides a user interface to league participants, commissioners, and vendors. The user interface may include a displayed user interface, such as a web page that a web browser can render or a mobile application for rendering on a smartphone. The user interface component 190 may also provide one or more programmatic or standardized data interfaces, such as application-programming interfaces (APIs), data feeds (e.g., using Really Simple Syndication (RSS)), and so on. A user may access the system 100 to perform various actions, such as withdrawing or depositing funds, and the user interface component 190 displays an appropriate interface to gather information from the user and allow the user to perform the particular action. The user interface component 190 may provide a league home page displayed to league participants by default when the visit and login to a site associated with the system 100. The component 190 may also provide separate commissioner and/or vendor interfaces to provide timely and relevant information to commissioners and vendors, respectively (e.g., pending reimbursements, vendor paybacks waiting to be processed, and so forth).
The computing device on which the league administration system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives or other non-volatile storage media). The memory and storage devices are computer-readable storage media that may be encoded with computer-executable instructions (e.g., software) that implement or enable the system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, set top boxes, systems on a chip (SOCs), and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
FIG. 2 is a flow diagram that illustrates processing of the league administration system to allow a commissioner to setup a league, in one embodiment. Beginning in block 210, the system identifies a league commissioner. For example, the commissioner may login to the system by providing a user name and password or league information. Continuing in block 220, the system receives a request to create a league. For example, the commissioner may navigate to a league setup web page or other user interface provided by the system and may select an option for creating a league. The commissioner may setup one or more leagues before a season begins.
Continuing in block 230, the system receives prior season rollover information. For example, the system may provide the commissioner with an option to rollover league information from a prior season and the commissioner may select a season from which to copy information. The system copies the selected prior leagues information to the new league. For example, the information may include team owners, team rosters, financial options, other league options, and so forth. Continuing in block 240, the system stores at least some of the received prior season rollover information in association with the new league. For example, the system may copy non-season specific information from the prior season (e.g., the team owners, rules, and so forth), and reset season-specific information (e.g., entry fees received, disbursement amounts, and so on). The system stores the new league information in the league data store.
Continuing in block 250, the system optionally receives one or more financial management options for the new league. For example, the options may include a deposit deadline for submitting league entry fees, a deadline for providing funds to the commissioner for a vendor purchase, commissioner reimbursement options, vendor payback options, and so forth. The commissioner may setup the league based on previously agreed upon settings or based on his or her own preferences. Continuing in block 260, the system notifies league participants of the new league and the received financial management options. For example, the system may notify team owners that the new league is setup and that the commissioner has turned on commissioner reimbursement. In response, team owners may login to the system and deposit league fees from a participant account or external account (e.g., using a credit card). After block 260, these steps conclude.
FIG. 3 is a flow diagram that illustrates processing of the league administration system to allow a commissioner to set league financial options, in one embodiment. Beginning in block 310, the system receives a league initiation fee deadline from a league commissioner. The deadline may be set by the commissioner based on a season start date of a physical sport related to the fantasy league and may also consider other deadlines faced by the commissioner, such as a deadline for paying a vendor that will provide goods or services to the league. For example, the commissioner may request that fees be submitted one month prior to the start of the real season so that the commissioner will have available funds to purchase goods or services for the league before the season starts. The system stores the received deadline for use to remind participants to pay fees and to calculate late fees.
Continuing in block 320, the system receives one or more late payment rules from the league commissioner. For example, the commissioner may set a particular surcharge fee to be added to a normal fee after a certain number of days beyond the received league initiation fee deadline. Late fees encourage league participants to provide timely payments that the commissioner may rely upon for setup of the league. The system stores the late payment rules for use if payments are received after a deadline or if payments are not received by a deadline.
Continuing in block 330, the system receives one or more commissioner reimbursement rules. For example, the commissioner may request an ability to reimburse league expenses from the league account up to a predefined threshold without additional approval of league participants. As another example, the commissioner may set reimbursement options to allow reimbursement for expenses based on a majority vote of team owners in a league. The system stores the received rules and uses the rules to process any commissioner reimbursement requests received.
Continuing in block 340, the system identifies one or more vendors for payment from a league account. For example, the commissioner may specify one or more vendors that provide goods or services that the commissioner would like to purchase for the league. The vendor may provide items such as an ESPN league account, t-shirts or other merchandise, statistical or other services, and so on. The commissioner may set one or more pre-approved vendors for participants to view when joining the league, so that the commissioner can pay these vendors from received fees without further approval from the league members.
Continuing in block 350, the system stores received financial management options for subsequent retrieval during management of the league. For example, the system may store the league options in a league data store and access the options at scheduled deadlines to take one or more actions related to the league. As an example, the system may send notifications to league participants that have not paid a league setup fee a certain number of days before or on the day of the deadline. After block 350, these steps conclude.
FIG. 4 is a flow diagram that illustrates processing of the league administration system to notify participants of a commissioner reimbursement, in one embodiment. Beginning in block 410, the system receives a commissioner reimbursement request. For leagues that have commissioner reimbursement enabled, the system may allow some requests to be approved automatically without following the following procedure. However, for leagues setup to request participant approval for commissioner reimbursements or reimbursements above a threshold amount, the following steps provide a voting procedure through which league participants control how the commissioner can use league funds (e.g., stored in a league account).
Continuing in block 420, the system selects a first participant associated with a league identified by the received request. For example, the system may access a list of league members and perform the following steps for each identified member. During subsequent rounds, the system selects the next participant. Continuing in block 430, the system notifies the selected participant of the received commissioner reimbursement request. The notification may include league identifying information (e.g., a league name), a link to a league website for responding to the request, an amount of the request, a purpose of the request (e.g., items the commissioner wants to purchase), and so forth. The notification may take the form of an email, text message, voicemail, push notification, or any other alert or notification.
Continuing in block 440, the system receives a response from the selected participant. Although shown serially, the system may notify a block of participants and receive participant responses at different times and in different order. The participant may respond by selecting a link provided with the notification or by navigating a web browser to a user interface associated with the system. The participant may approve or deny the commissioner's request, submit questions or comments about the request on a league message board, provide money related to the request, and so forth. Continuing in decision block 450, if there are more participants associated with the league, then the system loops to block 420 to select the next participant, else the system continues at block 460. Participant voting is not necessarily synchronous or asynchronous; participant can be notified in bulk, and can respond in any order, or simultaneouly.
Continuing in block 460, the system tallies responses received from each league participant and determines whether to allow or deny the commissioner reimbursement request. For example, the system may add up yes and no votes received in response to the request after a predetermined time period for responding to the request (or after each vote is received to determine whether the request can be granted without receiving further responses). Continuing in decision block 470, if one or more reimbursement conditions associated with the league are satisfied, then the system continues in block 480, else the system continues in block 490.
Continuing in block 480, the system denies the commissioner reimbursement request. The system may prevent the commissioner from transferring funds for the league account. After block 480, the system continues in block 495. Continuing in block 490, the system grants the reimbursement request. Continuing in block 495, the system notifies the commissioner of the outcome of the reimbursement request. If the system granted the request, then the system may transfer the funds to a previously identified recipient or may authorize the commissioner to transfer the funds manually (e.g., when the commissioner next logs in to the system). After block 495, these steps conclude.
FIG. 5 is a flow diagram that illustrates processing of the league administration system to transfer funds from a participant to a league, in one embodiment. Although transfers from participants to a league are illustrated, those of ordinary skill in the art will recognize that the system can perform similar steps to transfer funds from a league to a participant, from a league to a commissioner, from a league to a vendor, and so on. Beginning in block 510, the system identifies a participant financial obligation to a fantasy sports league with which the participant is associated. For example, the system may identify an obligation for the participant to pay a league entry fee to join the league for a new season. The financial obligation may include a particular amount and a deadline by which the obligation is to be satisfied (e.g., to avoid incurring late fees or withdrawal from the league).
Continuing in block 520, the system receives from the participant a request to satisfy the financial obligation with funds from a participant account associated with the participant. The participant may have previously funded the participant account using external funds (e.g., from a credit card or checking account), prior season dispersed funds, payments for services rendered to other leagues, and so forth. Prior systems do not include individual accounts for participants, but rather provide a single league account into which each participant's payments go directly. By allowing a participant to store funds under the participant's own control, the system allows the participant to separate funding of his account from that of the league, and to hold funds in the account over time (e.g., across seasons).
Continuing in block 530, the system identifies a league account associated with the league for receiving funds related to the identified financial obligation. The league account stores funds that are not under the control of any one participant, but rather are shared and/or managed by all of the participants in a league or by the league commissioner. The participant may identify the league account by providing information about the league (e.g., a league name or identifier). The participant may also specify a nature of the financial obligation (e.g., entry fee), in the event that a league has multiple accounts for different purposes.
Continuing in block 540, the system transfers funds from the identified participant account to the identified league account to satisfy the financial obligation. For example, the system may decrease an amount stored in a record in a league data store associated with the participant account and increase an amount stored in a record associated with the league account. The system may also store an audit record that identifies information about the transfer, such as where the payment came from, who the payment went to, who authorized the payment, a date/time of the payment, a transferred amount, and so on.
Continuing in block 550, the system notifies one or more parties that the transfer completed. For example, the system may notify the participant, league, and/or commissioner that the system transferred the funds. Upon receiving the notification, a commissioner, for example, may note that the league funds are adequate for a pre-season purchase and proceed to purchase pre-season items. After block 550, these steps conclude.
From the foregoing, it will be appreciated that specific embodiments of the league administration system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

Claims

1. A computer-implemented method for handling commissioner reimbursements for a fantasy sports league, the method comprising:

receiving a commissioner reimbursement request, wherein the request identifies an amount of an expense incurred or to be incurred by the commissioner on behalf of the league;

notifying each participant associated with the league of the received commissioner reimbursement request;

receiving one or more participant responses to the notification, wherein the response indicates a vote from the participant to approve or deny the request;

tallying responses received from each league participant and determining whether to allow or deny the commissioner reimbursement request;

if one or more reimbursement conditions associated with the league are satisfied, granting the reimbursement request; and

notifying the commissioner of the outcome of the reimbursement request,

wherein the preceding steps are performed by at least one processor.

2. The method of claim 1 wherein receiving the commissioner reimbursement request comprises displaying a web page accessible by the commissioner and receiving a request from the commissioner for reimbursement of the expense.

3. The method of claim 1 wherein receiving the commissioner reimbursement request comprises determining that the expense amount exceeds a threshold for automatic approval.

4. The method of claim 1 wherein receiving the commissioner reimbursement request comprises determining that a commissioner reimbursement option is enabled for the league.

5. The method of claim 1 wherein notifying each participant of the reimbursement request comprises sending information to the participant that identifies the request amount and a reason for the expense.

6. The method of claim 1 wherein receiving a participant response comprises determining that automatic commissioner reimbursement was enabled during an initial setup of the league, and automatically indicating the participant's assent if the reimbursement request satisfies one or more configured reimbursement conditions.

7. The method of claim 1 wherein determining whether to approve the request comprises determining whether the tallied votes satisfy a reimbursement rule configured for the league.

8. The method of claim 1 further comprising, if one or more reimbursement conditions associated with the league are not satisfied, denying the commissioner reimbursement request.

9. The method of claim 1 wherein granting the reimbursement request comprises transferring funds in the requested amount to a previously identified recipient.

10. The method of claim 1 wherein granting the reimbursement request comprises authorizing the commissioner to transfer funds form a league account to pay the expense.

11. A computer system for administering fantasy sports leagues, the system comprising:

a processor and memory configured to execute software instructions, the instructions embodied in the following software components;

a league management component configured to manage non-financial league information;

a league data store configured to persistently store league information between participant sessions with the system;

an account management component configured to manage accounts for one or more league participants, commissioners, leagues, and vendors;

a commissioner reimbursement component configured to manage costs incurred by a league commissioner on behalf of the league;

a vendor payment component configured to manage one or more payments associated with one or more leagues to an external vendor;

a league rollover component configured to setup a new league season by copying at least some prior season information;

a payment deadline component configured to manage one or more deadlines for payment associated with a league;

a notification component configured to notify one or more users of actions related to the users or one or more leagues; and

a user interface component configured to provide a user interface to league participants, commissioners, and vendors that access the system.

12. The system of claim 11 wherein the account management component is further configured to provide each user of the system with an individual account that tracks funds associated with a particular user.

13. The system of claim 11 wherein the account management component is further configured to manage one or more participant accounts that contain funds earned by a team owner from a past season of a league.

14. The system of claim 11 wherein the account management component is further configured to manage one or more league accounts that contain funds paid by team owners to join the league, wherein the funds can be applied by the commissioner to pay league related expenses.

15. The system of claim 11 wherein the account management component is further configured to reconcile a financial obligation between users of the system by transferring funds between the accounts of the obligated users to settle the obligation.

16. The system of claim 11 wherein the commissioner reimbursement component is further configured to allow one or more payments to the commissioner from a league account before the end of a league season.

17. The system of claim 11 wherein the commissioner reimbursement component is further configured to provide the commissioner with an option for enabling or disabling the component for a particular league and to notify participants who join the league whether the commissioner reimbursement component is enabled.

18. The system of claim 11 wherein the vendor payback component is further configured to transfer funds from a league account to a vendor account to satisfy a league's financial obligation to the vendor.

19. The system of claim 11 wherein the payment deadline component is further configured to allow a commissioner to reassign a previously set deposit deadline to an earlier date to ensure funds are available to make a pre-season purchase on behalf of the league.

20. A computer-readable storage medium comprising instructions for controlling a computer system to transfer funds from a fantasy sports individual participant account to a fantasy sports league account, wherein the instructions, upon execution, cause a processor to perform actions comprising:

identifying a participant financial obligation to a fantasy sports league with which the participant is associated;

receiving from the participant a request to satisfy the financial obligation with funds from a participant account associated with the participant;

identifying a league account associated with the league for receiving funds related to the identified financial obligation;

transferring funds from the identified participant account to the identified league account to satisfy the financial obligation; and

notifying one or more parties associated with the financial obligation that the transfer completed.