(81)【指定国】
AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US
ユーザの間の直接対決の挑戦を構築するための直接挑戦アプリケーションを含むゲームおよびゲーム的アプリケーションを作成する対話式システムおよび方法が、提示される。複数の直接の挑戦を構築し、管理するためのシステムは、アプリケーション・サービス・インタフェース、複数のユーザ・インタフェース、挑戦アプリケーション、ならびにスポーツ・イベントなどの現実の世界のイベント中の進展およびプレイヤーの成績を追跡するための複数の外部データ・サービスを含む。ユーザが生のアクション・スポーツ・イベントの進行中に彼らのファンタジー・プレイヤー・ライン・アップを変更しまたは修正することを可能にするシステムおよび方法も開示される。
ファンタジー・プレイは、プロフェッショナル・スポーツ、大学スポーツ、株、必需品、天気、ニュース、政治、法的成果、音楽力、賞、テレビジョン番組結果、およびNASCAR(登録商標)からなる群から選択された1つの要素からなる、請求項1に記載のシステム。
前記ゲーム内交代ソフトウェア・モジュールは、コンピュータ・プロセッサと非一時的メモリ上に記憶されたソフトウェア・コードとを備え、該ソフトウェア・コードは該コンピュータ・プロセッサによって実行され、前記ゲーム内交代ソフトウェア・モジュールは、前記グラフィカル・ユーザ・インタフェースからリモートに配置され、前記ゲーム内交代ソフトウェア・モジュールは、インターネットを介して前記グラフィカル・ユーザ・インタフェースに通信可能に結合される、請求項1に記載のシステム。
前記ゲーム内交代ソフトウェア・モジュールは、前記ユーザがファンタジー・マッチアップ中に前記アクティブ・プレイヤー・データ・セットに交代させることを望む前記ファンタジー・マッチアップでプレイしないために前記ユーザによって指定された前記複数のプレイヤーの前記1または複数を追加するために前記アクティブ・プレイヤー・データ・セットの更新の前に受諾されなければならない前記グラフィカル・ユーザ・インタフェース上の金銭的追加料金表示を前記ユーザに提示するようにさらに構成される、請求項1に記載のシステム。
非アクティブ・プレイヤーになるアクティブ・プレイヤーおよびアクティブ・プレイヤーになる非アクティブ・プレイヤーの前記ユーザによる選択に応答する前記工程は、非アクティブ・プレイヤーになるために選択された前記アクティブ・プレイヤーのうちの少なくとも1人が競い合っている生のイベント中に実行される、請求項8に記載の方法。
非アクティブ・プレイヤーになるアクティブ・プレイヤーおよびアクティブ・プレイヤーになる非アクティブ・プレイヤーの前記ユーザによる選択に応答する前記工程は、前記ユーザが前記グラフィカル・ユーザ・インタフェースを介して所望のプレイヤー交替の一致を示す時に即座に実行される、請求項8に記載の方法。
プレイヤー交替が望まれることをユーザが示すことに応答して、前記グラフィカル・ユーザ・インタフェースを介して金銭的料金を前記ユーザに提示する工程をさらに備える、請求項8に記載の方法。
前記ファンタジー競技は、プロフェッショナル・スポーツ、大学スポーツ、株、必需品、天気、ニュース、政治、法的成果、音楽力、賞、テレビジョン番組結果、およびNASCAR(登録商標)からなる群から選択された1つの要素からなる、請求項8に記載の方法。
【発明を実施するための形態】
【0021】
以下の説明では、本発明は、各種例示的な実施形態を参照して説明される。それでも、これらの実施形態は、本明細書において説明されるどの特定の例、環境、応用例、または特定の実施態様にも本発明を限定するものではない。したがって、これらの例の実施形態の説明は、本発明を限定するためではなく、例示のみのために提供される。
【0022】
本システムおよび装置および方法は、後続の詳細な記述、例、図面、および特許請求の範囲、ならびにそれらの前後の記述を参照することによって、より容易に理解される。しかし、本デバイス、システム、および/または方法が開示および記述される前に理解されたいが、開示される特定のデバイス、システム、および/または方法は当然ながら様々である可能性があるので、別段の指定がない限り本発明はこれらの特定のデバイス、システム、および/または方法に限定されない。また、本明細書で使用される用語は、特定の態様を記述するためのものにすぎず、限定するものではないことも理解されたい。
【0023】
後続の記述および図面の全体を通して、同じ部分には、同じ参照番号が付けられている。図面は正確な縮尺でない場合があり、いくつかの特徴は、明確さや簡潔さのためおよび情報伝達のために、強調された縮尺でまたはいくらか概略的なフォーマットで示される場合がある。
【0024】
本発明に関する後続の記述は、本発明の現在知られている最良の実施形態における、本発明の実施可能な教示として提供される。このために、本明細書に記載の本発明の様々な態様に多くの変更が加えられ得るとともになお本発明の有益な結果を得ることができることを、当業者は認識および理解するであろう。また、本発明の望ましい利益のいくつかは、他の特徴を利用することなく本発明の特徴のいくつかを選択することによって得られることも明らかであろう。したがって、本発明に対する多くの修正および適応が可能であり、状況によってはそれらが望ましい可能性すらあり、それらが本発明の一部であることを、当業者は認識するであろう。よって、後続の記述は、本発明の原理の例示として提供されるものであり、本発明の限定において提供されるものではない。
【0025】
全体を通して、単数形は、コンテキストが別段明確に指定されない限り、複数の指示対象を含む。よって、例えば、あるコンポーネントへの言及は、コンテキストが別段明確に指定されない限り、2つまたはそれ以上のそのようなコンポーネントも含み得る。
【0026】
本明細書では、範囲は、「約」ある特定の値から、および/または「約」別の特定の値まで、として表現される可能性がある。そのような範囲が表現されるとき、別の態様は、ある特定の値から、および/または別の特定の値まで、を含む。同様に、値が、「約」という先行語を使用して近似値として表現されるとき、この特定の値は別の態様を形成することが理解されるであろう。さらに、各範囲の終点は、他方の終点に対する関係において有意である場合もあり、他方の終点から独立して有意である場合もあることも理解される。
【0027】
本明細書において、用語「任意選択の」または「任意選択で」は、それに続いて記述されるイベントまたは状況が発生することもあり発生しないこともあり、そのイベントまたは状況が発生する場合とそうでない場合とをその記述が含むことを意味する。
ゲーム
本明細書において、ゲームという用語は、遊びまたは楽しみのために実行されるアクティビティ、ならびに、特定の目標または目的の追求を可能とするのに使用されるゲーム的な対話式アクティビティを指す。広い意味では、本明細書で記述されるゲームは、ユーザがゲーム・コンテンツ自体と、ゲームに関係する挿入(インサーション)または要求(コール・トゥ・アクション(call to action)と呼ばれることもある)との両方と対話するのを可能にする。記述されるように、ゲームのスーパーセットを作成するためのゲーム・システムを含めた、本明細書におけるゲームおよびゲーム的な対話式システムは、ユーザとゲームとの間のより深いエンゲージメントをもたらす。本明細書において、ユーザ・エンゲージメントは、プレイの頻度、プレイの継続時間、ならびに、ゲーム・コンテンツおよび/またはコール・トゥ・アクションとの対話の深さを指す。商業コンテキストでは特に、ユーザ・エンゲージメントが深いほどゲームの価値は高まる。本明細書に記載のゲーム・システムによって作成および管理されるゲームは、既存のゲーム・システムによって生み出されるゲームよりも、コストが低く、速く展開され、管理しやすい。
【0028】
ファンタジー・スポーツ・ゲーム。ファンタジー・スポーツは、各ユーザが特定のスポーツの現実のプレイヤーからなる想像上のまたはファンタジー・チームを選択し、管理する競技である。各ユーザは、各プレイヤーの現実の世界の成績に従ってポイントをためる。通常、ユーザは、チーム・マネージャまたはコーチの役割を引き受け、各特定のリーグの規則および規制の組に従って、ドラフト手続きでプレイヤーを選択し、プレイヤーをトレードし、アクティブ登録簿および非アクティブ(ベンチ)登録簿を確立し、登録簿を変更するなどを行う。
【0029】
現在利用可能なファンタジー・スポーツ・システムは、ゲーム内・プレイヤー交代を禁止し、これが、ユーザの享楽を制限し、ユーザが現実のスポーツ・チームのコーチおよびオーナのように振るまうことを妨げている。この制限が現在実施されているのは、少なくとも部分的に、プレイヤー交代のより高度に対話式のシステムの設計および管理が、各種技術的問題および記号論理学的問題を提示するからである。それでも、多くのファンタジー・ユーザは、特に彼らのプレイヤーが現実の世界のスポーツ・イベントに参加している時のファンタジー・マッチアップ中に、より多くの対話および柔軟性を強く望んでいる。
【0030】
非スポーツ・ゲーム。本明細書において説明されるシステムおよび方法の多くは、ファンタジー・フットボールの文脈で議論されるが、本明細書において開示される技術は、各種スポーツおよび他の定量化できる成績にも有用であり、適用可能である。例えば、
図32は、会社の株価の動き、プロフェッショナル・ホッケー、NASCAR(登録商標)、およびNCAAバスケットボールに関するゲームプレイの例を示す。
図33は、リアリティ・テレビジョン番組結果のゲームプレイの例を示す。
図34は、プロフェッショナル・フットボール・チームのラッシング・ヤードおよび音楽レコード売上のゲームプレイの例を示す。
図35は、政治およびニュース結果のゲームプレイの例を示す。
図36は、天気予報と、米国、世界、政治、および司法などのカテゴリのニュース・イベントの選択のゲームプレイの例を示す。
システム
図1は、特定の実施形態による、ゲーム作成および管理のためのシステム100の概略図である。示されるように、システム100は、コンテンツ管理システム200、アプリケーション・サービス300、ユーザ・インタフェース400、およびソーシャル報告エンジン500を含む、互いに通信する各種要素を含む可能性がある。システム100は、ゲーム・コンテンツ・データベース220、アクティブ・ゲームプレイ・データベース320、ユーザ・データベース520、および外部データ・ソース380も含む可能性がある。外部データ・ソース380は、外部コンテンツ・ソース382および外部アプリケーション388を含む可能性がある。
【0031】
図1は、例のシステム・プラットフォーム・アーキテクチャをも示す。本明細書において説明されるゲーム・システムおよび方法は、使いやすい1組のユーザ・インタフェース400を通じてゲームの作成および管理を容易にするセルフサービス・プラットフォームを使用して提供され得る。各種実施形態によるシステム・アーキテクチャは、
図1に示された構成要素およびモジュールを含み得る。
【0032】
アプリケーション・サービス・インタフェース300は、示されるように、独立したモジュールの呼び出しを行うためのREST API370を含む可能性がある。REST(表現可能な状態の転送(Representational State Transfer))は、インターネットなどの分散型システムのためのソフトウェア・アーキテクチャの様式である。REST API370は、改善されたスケーラビリティ、構成要素および関わりのある規則の制御、インタフェースの開発、および追加構成要素の展開を可能にする。
【0033】
特定の実施形態によるイベント・ハンドラ460は、未熟なユーザまたは管理者が、技術的なプログラミング支援を全くともなわずに各種アクション−イベント組合せを作成し、編集し、修正し、更新することを可能にするユーザ・インタフェースを含む。このユーザ・インタフェースは、ユーザがそこから選択するための、クリック可能リンクを有するソーシャルメディア・ロゴのストック写真イメージなどのライブラリ内に記憶された各種資産へのアクセスを含む。このユーザ・インタフェースは、ユーザまたは管理者が、ユーザが使いやすいフォーマットで一連のイベント−アクション関係全体を投入することをも可能にする。例えば、ユーザ・インタフェースは、それぞれに関連付けられたアクション、イベント、および規則のオプションを有する一連のドロップダウン・メニューを含むことができる(例えば、使用量カウンタ、時間/クロック・カウンタ、などを含む)。イベント・ハンドラ460は、ユーザ入力をとり、ゲームによる使用のための、決定木などの一連のコンピュータ命令を構築する。
【0034】
ゲーム・エンジンまたはシステムおよびユーザのコンピュータ・デバイスは、プロセッサと、非一時的メモリと、それぞれのゲーム・エンジン、システム、およびユーザ・コンピュータ・デバイスのそれぞれの特定の機能および特徴を実行するためにメモリ内に記憶されたソフトウェア・コードとを備えるコンピュータ・デバイスとすることができる。
【0035】
ソーシャル報告エンジン。別の態様では、ゲーム・システム100は、特定の実施形態によれば、ゲーム・タイプおよびカテゴリの選択の幅を提供することによって、かつ、ソーシャル報告エンジン500と呼ばれるモジュールを使用してゲームのスーパーセット全体にわたりユーザ・データを能動的に収集することによって、ゲームのスーパーセットの作成およびプレイを可能とするように構成される。ソーシャル報告エンジン500は、特定の実施形態によれば、長期間にわたり複数のゲームにまたがってユーザ・データを集めるが、このユーザ・データは、ゲーム・システムの登録および使用中、ゲームプレイ中、関係する対話(アンケートへの回答、および他のタイプのコール・トゥ・アクションへの応答など)中、ならびにソーシャル・メディア・アクション(「いいね」の入力、コンテンツの共有など)中の、ユーザ挙動を含む。この結果、何百万個もある可能性のあるユーザ・データ・プロフィールがポピュレートおよび更新され、これらはユーザ・データベース520に記憶され得る。
【0036】
ユーザ・データは、ユーザによって自発的に提供された初期プロフィール・データを含み、これは通常、Facebook(登録商標)プロフィール、Twitter(登録商標)アカウント、Foursquare履歴、または他の統合サードパーティ・アプリケーションにすでに含まれる情報を共有することで始まる。ゲーム・システム・プロバイダはまた、メンバシップである間はいつでも、クエリまたは他の方法でユーザ・データを集めることができる。ユーザ・データはまた、プレイされた特定のゲームごとのゲーム成績を含む。これは例えば、ユーザが特定のスポーツで正確な予測を立てるかどうか、および、ユーザがある製品、サービス、または会社に対して一貫して「いいね」の表明またはお気に入りの指定をするかどうかを含む。好ましい一実施形態では、ユーザ・データは、個人特定可能な情報を販売または開示しないようにしてビジネス・インテリジェンスおよび他の有用な情報を導出するために、集約されることになる。ユーザ・データは、集約または匿名化されたフォーマットで提供されることがある。しかし、このようなユーザ・データは価値がある。というのは、本発明のゲーム・システムによって収集され記憶されたユーザ・データは、本明細書に記載のように、ゲーム・システム内でのユーザ挙動および関係するアクティビティの履歴と組み合わせられた、様々な有用な人口統計情報を含むからである。この、人口統計情報と実際のユーザ挙動との組合せは、ゲーム・システムによって収集され記憶されたユーザ・データの価値に貢献する。
直接対決の挑戦
本明細書において説明されるシステムおよび方法は、本明細書において時々「マーノ・エ・マーノ」と呼ばれる直接対決または直接挑戦のアプリケーションおよびシステムを含む。本明細書において使用される直接対決または直接の挑戦は、ゲームまたはファンタジー・スポーツ・アプリケーションなどのアプリケーションの2人の個々のユーザの間の直接の挑戦を指す。
【0037】
特定の実施形態による挑戦アプリケーションは、第1のユーザが、マッチアップを作成し、挑戦を第2のユーザに送信し、マッチアップの結果を監視し、挑戦を処理し、勝者を識別し、スコアを計算し、投稿し、リーダボードを更新することを可能にするように構成され得る。賭け代は、適用可能である場合に/時に処理され得る。
【0038】
挑戦者(第1のユーザ)および第2のユーザは、挑戦が送信され、受諾される時または挑戦の主題であるアクティビティが行われる時に、お互いのチームをプレイするようにスケジューリングされる必要がない。例えば、挑戦が送信される時に、挑戦者が、第2のユーザとは異なるリーグに属する可能性があり、リーグが全くなくてもよい。よって、挑戦は、ファンタジー・マッチアップ・ゲームの正常なスケジュールの外部の「副挑戦(side challenge)」とすることができる。第1のユーザと第2のユーザとの間の挑戦は、スポーツ、政治、エンターテインメント、現在のイベントなどを含む努力のすべての分野に関係するものとされ得る。
【0039】
挑戦は、以下の大まかな形式、すなわち、「Aが、[このイベントまたは期間]中に[努力の分野]で[所与の成績]においてBを[しのぐまたは負かす]」で構築される可能性がある。マッチアップの成果は、場合に応じて現実の世界のゲームまたは競技での各競争相手の統計的成績によって決定され得る。
【0040】
本明細書において説明される挑戦アプリケーションは、挑戦の主題または競争相手(「A」および「B」)を選択し、「バリー・サンダース(Barry Sanders)が、今週日曜日のフットボール・ゲーム中にマーカス・アレン(Marcus Allen)より多くのトータル・ヤードだけラッシュする」などの挑戦を作成するのに使用され得る。成果は、選択された期間(日曜日のフットボール・ゲーム)中の現実の世界の成績(ラッシュしたトータル・ヤード)に基づいて決定されまたはスコアを記録され得る。
【0041】
特定の実施形態によるマーノ・エ・マーノ挑戦アプリケーションは、ユーザが、リスト、データベース、またはコンテンツの外部ソースからプレイヤーまたは競争相手を選択することによってマッチアップを作成することを可能にするように構成され得る。
【0042】
特定の実施形態によれば、
図2は、ゲーム・アプリケーションのユーザの間の複数の直接の挑戦を生成し、管理するための挑戦システム1100の概略図である。示されるように、挑戦システム1100は、アプリケーション・サービス・インタフェース1300、複数のユーザ・インタフェース1400、およびソーシャル報告エンジン1500を含む、互いに通信する各種要素を含む可能性がある。挑戦システム1100は、データベース1220、ユーザ・データベース1520、および1または複数の外部データ・サービス1280も含む可能性がある。外部データ・サービス1280は、例えば、スポーツ・フィードA1282、コンテンツAPI B1284、およびスポーツ・フィードB1286を含む可能性がある。
【0043】
代替的な実施形態において、挑戦システム1100は、
図1に示されたコンテンツ管理システムと同様のコンテンツ管理システムを含み得る。
アプリケーション・サービス・インタフェース1300は、示されるように、独立したモジュールの呼び出しを行うためのREST API1370を含む可能性がある。REST(表現可能な状態の転送(Representational State Transfer))は、インターネットなどの分散型システムのためのソフトウェア・アーキテクチャの様式である。REST API1370は、改善されたスケーラビリティ、構成要素および関わりのある規則の制御、インタフェースの開発、および追加構成要素の展開を可能にする。
【0044】
ロジック・レベルで、特定の実施形態のアプリケーション・サービス・インタフェース1300は、示されるように、スコアリングおよびリーダボード、ユーザ・マネージャ、ピック・エンジン1340、マッチアップ・ロジック1310、ならびにイベント・データ・ハンドラ1360に関するモジュールを含む。データ・レベルで、特定の実施形態のアプリケーション・サービス・インタフェース1300は、示されるように、永続性マネージャ(Persistence Manager)、設定マネージャ、マニュアル・データ・インタフェース、および1または複数の外部データ・リーダ1380を含む。
【0045】
特定の実施形態による挑戦アプリケーションは、プログラミングされたコンピュータを使用して実装され得る。直接の挑戦は、スポーツ、政治、またはエンターテインメントなどのさまざまな利用分野のいずれかにおける競争者または競争相手(もしくは気付かれた競争相手)の間のコンテストである可能性がある。挑戦は、以下の大まかな形式、すなわち、「[第1の競争者]が[このイベントまたは期間]中に[第2の競争者]を[この成績パラメータによればしのぐ]」で構築される可能性がある。挑戦の成果またはスコアは、例えば、現実の世界のゲームまたは競技において各競争者の実際の成績を比較することによって決定され得る。挑戦アプリケーションは、動的であり、ユーザが使いやすいインタフェースを使用してユーザが直接の挑戦の各要素を構築することを許す。挑戦アプリケーションは、本明細書において説明されるゲーム・システムの特徴および機能のいずれかまたはすべてを含む可能性がある。例えば、挑戦アプリケーションは、システムによってアクセス可能なゲーム・コンテンツまたはその他のデータ、例えば、片方または両方の競争者の写真へのアクセスを含む可能性がある。
【0046】
ブラケット・ゲームの文脈で、第1の競技者および/または第2の競技者は、ブラケットで競い合うチームのいずれかから選択されたプレイヤーである可能性がある。成績パラメータは、「より多くのポイントを決める」である可能性がある。期間は、「トーナメントのそれぞれの各競技者の第1のゲームにおけるプレイの第2の期間中」である可能性がある。概略的に
図2に示されるように、アプリケーション・サービス・インタフェース1300は、マッチアップ・ロジック1310を含む。特定の実施形態によるマッチアップ・ロジック1310は、マッチアップ・データに関する規則、ロジック、制限、および標準的な表現を含む可能性がある。上記の例に関するマッチアップ・データは、このサンプルの挑戦のフレーズ、すなわち、「第1の競技者」が「トーナメントのそれぞれの各競技者の第1のゲームにおけるプレイの第2の期間」中に「第2の競技者」「より多くの得点を決める」を完成するためのデータまたは属性を含む可能性がある。
【0047】
特定の実施形態によるピック・エンジン1340は、画面上にオプションを提示し、ユーザが選び出すための選択を可能にするように構成される。別の態様において、ピック・エンジン340は、ユーザによって成される選択に関する規則、ロジック、制限、および標準的なデータ表現を含む可能性もある。例えば、特定のゲームのためのピック・エンジン340は、規則および関わりのある条件(例えば、このユーザが期間を選択したか否か)に従ってユーザに対してオプションを表示する可能性があり、ユーザの選択を制限する(例えば、一度送出されるとピックが変更されることを認めない)可能性がある。ピック・エンジン1340は、マッチアップ・ロジック1310によって定義された、それぞれの挑戦に関するデータ表現および特定のプロセスを含む。
【0048】
特定の実施形態によるイベント・データ・ハンドラ1360は、外部データ・サービス1280のそれぞれからの入力されるデータを管理するように構成される。それぞれの外部データ・サービス1280は、その他の外部データ・サービスとは異なるデータの独自の構成を有する可能性がある。イベント・データ・ハンドラ1360は、外部データ・サービス1280のそれぞれからの入力されるデータをマッチアップ・ロジック1310に従って対応するデータ・ロケーションにマッピングするための特定の1組のセマンティックスを含む。
この態様において、イベント・データ・ハンドラ1360は、マッチアップ・ロジック1310に従って処理される入力されるマッチアップ・データを解析し、ソートし、命名し、マッピングし、それ以外の方法で調整する。
【0049】
例えば、イベント・データ・ハンドラ1360は、スポーツ・イベントまたは競技のような現実の世界のイベントに関する「先発登録選手」などのパラメータについての入力されるデータをマッピングするためのセマンティックスを含む可能性がある。直接の挑戦の2人の競技者は異なる日に異なるゲームでプレイしている可能性があるので、イベント・データ・ハンドラ1360は、直接の挑戦の構築を可能とするために「先発登録選手」などのデータを受信し、分析するように構成される可能性がある。
【0050】
例えば、イベント・データ・ハンドラ1360は、スポーツ・ゲーム的な現実の世界のイベントに関する「開始時間」などのパラメータについての入力されるデータをマッピングするためのセマンティックスを含む可能性がある。直接の挑戦の2人の競技者は現実の世界のゲームで互いに競い合っていない可能性があり、それらの競技者のそれぞれのゲームが異なる時間に行われる可能性があるので、イベント・データ・ハンドラ1360は、直接の挑戦のそれぞれの各競技者についてのデータを正確に集めること−およびスコアに記録すること−を可能とするために開始時間およびその他のパラメータを扱う。
【0051】
特定の実施形態によるマッチアップ・データは、直接の挑戦を説明し、処理するために以下の属性を有する可能性がある。例えば、それぞれの挑戦は、これらの属性、すなわち、イベント・データ、ステータス(保留、進行中、完了、処理済み)、ならびにソース(挑戦を構築し、その後、挑戦をスコアに記録するために使用されるデータ・フィードまたはコンテンツ・サービス)を有する可能性がある。それぞれの挑戦は、これらの属性、すなわち、タイトル、マッピング・パターン(成績パラメータおよび期間などのスコアを計算するための規則)、正しい答え(挑戦に勝つ競技者に対する参照を含む)、ならびにスコア(挑戦に勝つことに関して定義されたスコア)をともなう質問を含む可能性がある。
【0052】
特定の実施形態によるマーノ・エ・マーノ挑戦アプリケーションは、リスト、データベース、またはコンテンツの外部ソースから競技者を選択することによってユーザが直接の挑戦を構築することを許すように構成され得る。来たる競技およびゲームについての情報は、各種外部データ・ソース1280から得られ、ドロップダウン・リストまたはその他のユーザが使いやすいインタフェースでオプションとしてユーザに提示される可能性がある。挑戦アプリケーションは、マニュアル・データ・インタフェースを使用して、挑戦が外部データの参照なしにユーザによって構築されることを許す可能性がある。
【0053】
別の態様において、挑戦アプリケーションは、さまざまな競技者の間および中でいくつかの直接の挑戦を自動的に選択し、作成し、それから、仲間のユーザに対する直接の挑戦で使用するためにユーザにそのような挑戦を提案するように構成される可能性がある。
【0054】
特定の実施形態においては、それぞれの外部データ・ソースが、独自の対応する外部データ・リーダを有する可能性があり、そしてさらに、その外部データ・リーダが、独自の対応するイベント・データ・ハンドラを使用する。この態様において、システムは、複数の外部データ・リーダ1380を含む可能性があり、イベント・データ・ハンドラ1360は、データを収集し、編成するために一緒に働く複数のデータ・ハンドラを含む可能性がある。
直接対決の挑戦のゲームプレイ
以下の説明および図は、直接の、または直接対決の挑戦を構築するプロセスの一例を説明する。直接の挑戦は、以下の大まかな形式、すなわち、「[第1の競争者]が[このイベントまたは期間]中に[第2の競争者]を[この成績パラメータによればしのぐ]」で構築される可能性がある。以下の例においては、第1のユーザ(ケホエサベ(Kehoesabe)チーム)が第2のユーザ(ドラゴン・アーミー(Dragon Army)チーム)に直接の挑戦を送信し、丸一日中に第1の競技者(ノーショーン・モレノ(Knowshon Moreno))が第2の競技者(マット・フォルテ(Matt Forte))よりも多いトータル・ヤードを達成すると主張し、500ファンタジー・ドルの額の非通貨の賭け代を賭け、両方のプレイヤーを賄うために99セントの料金を支払う。
【0055】
代替的な実施形態においては、第1のユーザが、そのユーザのすべての友達に、特定のグループもしくはカテゴリのすべてのユーザに、またはシステム全体のすべてのユーザに直接の挑戦を送信する可能性がある。この態様においては、直接の挑戦が構築され、競い合うための招待としてユーザの選択グループに発せられる可能性がある。
【0056】
図3は、画面10を示し、直接の挑戦を構築するプロセスを開始するための開始ボタン20(マーノ(Mano)開始とラベル付けされる)を含む。次に、ボタン20が選択される時に、特定の実施形態による挑戦アプリケーションは、
図4に示されているように、チームまたは相手(あるいは、グループ、リーグ、またはユーザの連絡先内の他のユーザ)のリスト30を示すディスプレイを開く可能性がある。この例において、各チームは、特定のユーザによって選択されたプレイヤーの集合であるファンタジー・スポーツ・チームを表す。この態様において、チームのリスト30は、実際上、ユーザのリストを表す。
【0057】
この例において、第1のユーザは、ケホエサベ・チームを所有するユーザである。第1のユーザは、相手を選択する可能性があり−ここでは、第1のユーザは、ドラゴン・アーミー・チームを選択する−その後、特定の実施形態によれば、挑戦アプリケーションが、
図5に示されるように、挑戦の属性40を列挙する画面を開く。属性40は、私のプレイヤー41(または第1の競技者)、あなたのプレイヤー42(第2の競技者)、スタッツ43(成績パラメータ)、時間枠44(期間)、ファンタジー・ドル45(結果に対する任意選択の非通貨の賭け代)または現実世界の金銭の賭け代、(直接の挑戦の特徴の提供者またはその他の参加するエンティティに支払いを行うための)オプション46、および(すべての属性が選択された後に直接の挑戦を送信するための)挑戦送信47に関する選択可能なアイコンを含む。
【0058】
図6に示されるように、特定の実施形態に従って私のプレイヤー41を選択することに応じて、挑戦アプリケーションは、直接の挑戦のための第1の競技者として選択され得る(第1のユーザ自身のチームの)競技者の画面を開く。この例において、第1のユーザは、ノーショーン・モレノと名付けられたプレイヤーを選択する。競技者のリストは、そのユーザのチームにすでに含まれる競技者に制限され得、あるいは、このリストは、全プレイヤーを含むプレイヤーの全般的なプールを含んでもよい。ユーザは、利用可能なプレイヤーのリストの各メンバーに対して調査を実行する能力を与えられてもよい。調査スクリーンの例が、
図39に示されている。
【0059】
図7に示されるように、特定の実施形態に従ってあなたのプレイヤー41を選択することに応じて、挑戦アプリケーションは、直接の挑戦のための第2の競技者として選択され得る(第2のユーザのチームの)競技者の画面を開く。この例において、第1のユーザは、マット・フォルテと名付けられたプレイヤーを選択する。
【0060】
図8に示されるように、特定の実施形態に従ってスタッツ43を選択することに応じて、挑戦アプリケーションは、この特定の競技のために利用可能である統計またはその他の成績測定基準の画面を開く。この例において、利用可能な測定基準は、タッチダウン、レシーブ、およびヤードを含む。この例において、第1のユーザは、ヤードを選択する。バスケットボールの競技に関しては、例えば、利用可能な測定基準は、リバウンド、フリー・スロー、スリー・ポイント・ゴールを含む可能性がある。
【0061】
図9に示されるように、特定の実施形態に従って時間枠44を選択することに応じて、挑戦アプリケーションは、この特定の競技のために利用可能である期間、継続時間、またはその他の時間的に制限されたパラメータの画面を開く。この例において、利用可能な時間枠は、クォータ、ハーフ、日、および週を含む。この例において、第1のユーザは、日を選択する。
【0062】
図10に示されるように、特定の実施形態に従ってファンタジー・ドル45を選択することに応じて、挑戦アプリケーションは、非通貨の賭け代の額の画面を開く。この例において、利用可能な賭け代は、$100、$500、$1000、および手持ちのすべての$を含む。この例において、第1のユーザは、$500を選択する。
【0063】
図11に示されるように、特定の実施形態に従ってオプション46を選択することに応じて、挑戦アプリケーションは、支払いオプションの画面を開く。この例において、利用可能な支払いオプションは、「$0.59プレイヤー毎」または「$0.99両方のプレイヤーを賄う」を含む。この例において、第1のユーザは、「$0.99両方のプレイヤーを賄う」を選択する。
【0064】
図12に示されるように、特定の実施形態に従って挑戦送信47を選択することに応じて、挑戦アプリケーションは、直接の挑戦が第2のユーザ(ドラゴン・アーミー・チームの所有者)に送信されたことを確認する通知50を表示する。いかなる第2のユーザも選択されなかった場合、挑戦は、競い合うための招待としてユーザの選択されたサブセットまたはすべてのユーザに対して公表されるかまたは表示される可能性がある。
【0065】
図13は、挑戦アプリケーションの特定の実施形態による第2のユーザへの直接の挑戦の提示を示す。示されるように、挑戦アプリケーションは、2人の競技者(関わりのある情報をともなう)、挑戦の測定基準(「トータル・ヤード」)、期間(日付)、および架空の賭け代を表示する可能性がある。画面は、ユーザが料金を支払ったメッセージも含む可能性がある。
【0066】
図13に示されるように、特定の実施形態による挑戦アプリケーションは、直接の挑戦を受信すると第2のユーザによって使用されるための返答属性60の画面を含む。返答属性60は、受諾61、拒否62、および逆挑戦63に関する選択可能なアイコンを含む。受諾61を選択することに応じて、挑戦アプリケーションは、挑戦が変更なしに受諾されたという通知を第1のユーザに送信する。拒否62を選択することに応じて、挑戦アプリケーションは、挑戦が拒否されたという通知を第1のユーザに送信する。逆挑戦63を選択することに応じて、挑戦アプリケーションは、直接の挑戦の属性に変更を行うための選択可能なアイコンと共に一連の画面を第2のユーザに提供する。完了されるとき、挑戦アプリケーションは、考慮してもらうために第1のユーザに改正された挑戦(逆挑戦)を送り返すために第2のユーザに「挑戦送信」アイコンを提供する。
【0067】
図14は、画面上の挑戦のリスト70を示す。挑戦22とラベル付けされたアイコンを選択することに応じて、挑戦アプリケーションは、挑戦のリスト70を1または複数のフィルタまたはカテゴリと共に表示する。この例において、リスト70は、対戦相手のユーザ(第2のユーザ)の名前、挑戦のタイトル、スコア、日付、ステータス(勝ちまたは負け)、およびもしあれば賭け代の額を含む。直接対決レコード・ポップ・アップも、
図40に示されているようにユーザに提供され得、
図40は、特定の相手からの関連するヒストリカル・データを示す。ユーザは、
図41に示されているように、全ライン・アップ挑戦を送出することもできる。
2対2の直接の挑戦など
特定の実施形態による挑戦アプリケーションは、2対2の挑戦、すなわち、2人の第1の競技者と2人の第2の競技者との間のコンテストをユーザが構築することを許すように構成され得る。この態様において、第1の競技者は2人以上のグループである可能性があり、第2の競技者は2人以上のグループである可能性があり、両方のグループは同じ数の参加者を有する。この実施形態において、対戦相手の競技者の各対は、独自の成績パラメータ(例えば、ラッシング・ヤードまたはトータル・ヤード)を有する可能性があり、独自の賭け代および/または料金を有する可能性があり、期間は、いくつかの現実の世界のゲームを含むのに十分なだけ長い可能性がある。この態様において、挑戦アプリケーションは、それぞれの対戦相手側の3人以上の競技者−またはチーム全体−との挑戦の構築を可能とするように構成される可能性がある。
挑戦のためのソーシャル報告エンジン
別の態様において、特定の実施形態による挑戦システム1100は、複数の直接の挑戦の作成およびプレイを可能とし、
図2に示されるように、ソーシャル報告エンジン1500と呼ばれるモジュールを使用してユーザの間の挑戦のスーパーセット全体でユーザ・データを積極的に収集するように設計される。特定の実施形態によるソーシャル報告エンジン1500は、長い期間、複数のゲームにわたって−ゲーム・システムの登録および使用中、ゲームのプレイ中、対話中、ソーシャル・メディア・アクション中、ならびに挑戦中のユーザ挙動を含む−ユーザ・データを集め、ユーザ・データベース1520に記憶され得る潜在的に数百万のユーザ・データ・プロファイルのデータ投入および更新を結果としてもたらす。
【0068】
ユーザ・データは、ユーザによって自発的に提供されたプロファイル・データを含む。挑戦システムおよび/またはゲーム・システムの提供者が、随時問い合わせまたはその他の方法によってユーザ・データを集める可能性もある。ユーザ・データは、例えば、ユーザが特定のスポーツの正確な予測を行うかどうか、およびユーザが特定の製品、サービス、または会社を一貫して好きであるかまたは好むかどうかを含む、プレイされた特定のゲームによるゲームの成績も含む。好ましい実施形態において、ユーザ・データは、個人を特定可能な情報を販売または開示しないようにしてビジネス・インテリジェンスおよびその他の有用な情報を導出するために集約される。ユーザ・データは、集約されたまたは匿名化された形式で提供され得るが、そのようなユーザ・データは、本明細書において説明されるように、本発明のゲーム・システムによって収集され、記憶されたユーザ・データがゲーム・システム内のユーザ挙動および関わりのあるアクティビティの履歴と組み合わされたさまざまな有用な人口統計情報を含むので価値がある。人口統計情報と実際のユーザの振るまいとのこの組み合わせは、ゲーム・システムによって収集され、記憶されたユーザ・データの価値に寄与する。
挑戦からの群衆知
別の態様において、特定の実施形態によるソーシャル報告エンジン1500は、特定の対象についての群衆知を特定するために所定の期間にわたって対象毎にいくつかの直接対決の挑戦を分析し、ランク付けするための群衆知モジュールを含む。使用中、モジュールは、特定の対象について最も多くの場合に正しい挑戦のサブセットを特定し、顧客のためにその対象についての報告を構築し得る。
【0069】
この態様において、群衆知モジュールは、特定の対象(スポーツ、映画の賞など)を調査し、対象について最も多くの場合に正しい挑戦を特定し、一貫性および正確性に関してある期間にわたってそれらの予測を分析するタスクを与えられる。挑戦システム1100は、長い期間にわたって複数の直接対決の挑戦に参加する多数のプレイヤーを含むので、最も多くの場合に正しい挑戦は、挑戦システムを使用するすべてのプレイヤーの群衆知を表す。商業の文脈で、群衆知は、さまざまな文脈で有用であるすぐに使用可能なビジネス・インテリジェンスを表すので価値を有する。
【0070】
挑戦に関する群衆グル
関わりのある態様において、特定の実施形態によるソーシャル報告エンジン1500は、特定の対象についての挑戦に勝つことが最も多いユーザの達人のサブセット(すなわち、群衆グル)を特定するために、所定の期間にわたってユーザ毎および対象毎にいくつかの直接対決の挑戦を分析し、ランク付けするための群衆グル・モジュールを含む。使用中、群衆グル・モジュールは、対象についての挑戦に勝つことが最も多いユーザを特定する可能性があり、識別情報またはそれらのグルを顧客に報告する可能性がある。
【0071】
この態様において、群衆グル・モジュールは、特定の対象(スポーツ、映画の賞など)についての挑戦に勝つことが最も多いユーザを見つけ、それぞれのそのようなユーザを群衆グルとして特定する。特定の実施形態によれば、それぞれのユーザの挑戦が、挑戦に勝つことが最も多い1または複数のユーザを決定するために対象毎に経時的に分析される。ゲーム・システムは、長い期間にわたって複数の直接対決の挑戦に参加する多数のプレイヤーを含むので、挑戦に勝つことが最も多いユーザが、その特定の対象についての群衆グルとして特定され得る。商業の文脈で、群衆グルまたは群衆グルのサブセットによってなされるゲームの挑戦は、さまざまな文脈で有用であるすぐに使用可能なビジネス・インテリジェンスを表すので価値を有する。群衆グル・モジュールは、特定のバーティカルで挑戦の勝利の数に関してユーザをスコアに記録し、最高の達人(最近の結果に基づくロール・リストのメンバーである群衆グル・パフォーマー)によってなされた挑戦を集約し、ソーシャル報告エンジン1500およびその他のツールを使用してデータを分析し、そのデータを使用して、例えば、本明細書に記載のビジネス・インテリジェンス報告コンソールで提示される販売するための群衆グル・データを生成する。
【0072】
特定の実施形態によれば群衆グル・モジュールは、挑戦のスコアおよび勝ちをカテゴリ毎にまたはその他の選択された測定基準によって経時的に集約することによってそれぞれのゲーム・カテゴリにおける最良の成績のユーザを特定し、上位パフォーマーのローリング・サブセットを維持するように構成される。例えば、マンデー・ナイト・フットボール・チャレンジの上位5%の勝者、マーチ・マッドネス中のチャレンジの上位10%の勝者など。
【0073】
この態様において、挑戦システム1100およびソーシャル報告エンジン1500は、トピックについての直接対決の挑戦のサブセットでの群衆グルの実際の勝ち/負けの成績に基づいて、(a)特定のトピックに関連する群衆知、および/または(b)群衆グルのパフォーマーを特定するために使用され得る。予測エンジンと呼ばれることがある既存のツールとは異なり、群衆知モジュールおよび群衆グル・モジュールは、直接対決の挑戦における実際の成績に基づく。
【0074】
ゲーム内登録簿移動
現在利用可能なファンタジー・スポーツ・システムは、チーム登録簿(トレード、ウェーバー、およびフリー・エージェント・ピックアップを含む、ユーザの登録簿を確立しまたは変更するのに使用される正式なドラフト手順または他の手順中にユーザによって選択される)を含む。来たるゲームまたはゲームのサブセットの前に、ユーザは、締切期限の前にアクティブ登録簿のプレイヤーの組をチーム登録簿から選択する。残りの選択されなかったプレイヤーは、ユーザのベンチ登録簿に残される。来たるゲームのサブセット中に、ファンタジー・スポーツ・システムは、各プレイヤーが参加する生ゲームのそれぞれの間に、アクティブ登録簿のプレイヤーの成績をフォローし、評価し、プレイヤー達成に関係するポイントに署名する。
【0075】
アクティブ補欠。本明細書で説明される登録簿管理システムは、アクティブ補欠を含む。特定の実施形態によれば、アクティブ補欠リストは、生の現実の世界のスポーツ・イベントまたはゲーム中に交代に利用可能な、ユーザのチーム登録簿から選択されたプレイヤーのリストを記述する。
【0076】
一実施形態では、アクティブ補欠は、ゲームのサブセットの開始の前にベンチ登録簿からユーザによって選択された1または複数のプレイヤーのサブセットを含む。代替案では、アクティブ補欠リストは、ベンチ登録簿のすべてのプレイヤーを含むことができ、ユーザによる事前選択を要求しない。アクティブ補欠リストの提供は、ユーザが、現実のゲーム中にコーチまたはマネージャが働くように振るまうことを可能にする。
【0077】
動作中に、登録簿管理システムは、ファンタジー・マッチアップが進行中である間に、ユーザがアクティブ・プレイヤー、複数のアクティブ・プレイヤー、プレイヤーの選択されたグループ、またはチーム全体を、アクティブ補欠から選択された1または複数の交代プレイヤーまたはチームと置換することを許すように構成されたゲーム内交代モジュールを含むことができる。
【0078】
アクティブ登録簿からのアクティブ・プレイヤーが、異なる時に異なる生のゲームに参加している可能性があるので、ゲーム内交代モジュールは、現在進行中のファンタジー・マッチアップ、言い換えると、アクティブ登録簿に載っているユーザのプレイヤーのうちの1人が、現在生のゲームでプレイしているマッチアップをまず識別し、選択するように構成され得る。例えば、NFLのファンタジー・リーグにおいて、ゲームのサブセットは、特定の週末の間すなわち木曜日と次の月曜の夜との間にプレイされるフットボール・ゲームを含むことができる。ファンタジー・アクティブ登録簿からのアクティブ・プレイヤーは、この期間中の異なる時に異なるフットボール・ゲームに参加している可能性がある。ゲーム内交代モジュールは、各アクティブ・プレイヤーの生のゲームへの参加と一致するように、交代のタイミングを監視し、制御するように構成され得る。各種実施形態では、このモジュールは、本明細書においてフィード・データ25と呼ばれ、下で説明される、情報の1または複数のアクティブ・フィードを受信することができる。
【0079】
システム・アーキテクチャは、ファンタジー・リーグ運営者が、Yahoo!(登録商標)、CBS、ESPN、NFLなどによって提供されるものなどの、彼らの既存のファンタジー・スポーツ・アプリケーションに登録簿管理システム(ゲーム内交代を含む)を簡単に統合することを可能にするサービス・インタフェース400を含む。サービス・インタフェース400を使用する登録簿管理システムは、別々のまたは独立型のファンタジー・スポーツ・システムの一部として操作されることも可能である。
【0080】
交代を行うためのアクティブ登録簿は、株、必需品、俳優/賞、現在のイベント、政治、映画、ならびに人および物による他の定量化できるタイプの成績など、非スポーツ・イベントに同等に適用され得る。
【0081】
アクティブ登録簿機能は、交代が、確立された休憩時間、事前定義の休憩時間、または他の定義された時間のウィンドウにではなく、いつでも発生することを可能にすることができる。アクティブ登録簿機能は、ある種の実施形態では、通常のゲームプレイおよび直接の挑戦にも適用され得る。
【0082】
図37および
図38は、直接挑戦ゲームでプレイヤーを交替させるためのユーザ・インタフェースを示す。
図37は、ユーザが、挑戦のリストにアクセスするためにボタンを選択することを示す。その後、
図38の上側部分で、ユーザは、挑戦に参加するプレイヤーを交替させるために「交替」ボタンを選択する。その後、選択スクリーンが現れて、代替プレイヤーのオプションを提供する。交替特徴は、無料でまたは
図38に示されているように追加のコストをともなって提供され得る。その後、ユーザは、選択を確認する。このシステムは、
図38の下側のスクリーンなどの交替結果メッセージを提供することができる。交替は、通常のリーグ支払いでも実行され得る。
【0083】
図15は、それを用いてユーザが情報を受け取り、プレイヤーを識別し、選択し、交代を実行することのできる、対話式デバイス上のグラフィカル・ユーザ・インタフェースおよびディスプレイのスクリーン・ショットである。ディスプレイ10は、スコアのリスト、ゲームおよびプレイヤーに関するニュース・フィードなど、1または複数のファンタジー・スポーツ・アクティビティに関する各種ソースからのさまざまな有用な情報のいずれかと、本明細書で説明される登録簿管理システムの各種要素にアクセスし、実行するための複数のメニューおよびサブメニューとを含むことができる。
【0084】
図15は、私のチーム40を含むオプションのメニューを示す。
図15に示された私のチーム40のディスプレイは、例えば、ゲームの来たるサブセットのためにユーザによって選択されたアクティブ登録簿のリストを含むことができる。この例に示されているように、アクティブ登録簿は、クォーターバックとしてドリュー・ブリーズ(Drew Brees)、ランニング・バックとしてマッコイ(McCoy)およびチャールズ(Charles)などを含む場合がある。
図16のディスプレイは、アクティブ補欠アイコン50(この例では星と文字「AR」を使用して図示)をも含むことができる。アイコン50は、選択された時に、ユーザが本明細書で説明されるアクティブ補欠特徴にアクセスすることを可能にする。
【0085】
特定の実施形態による、アクティブ補欠リストのプレイヤーを選択する工程は、例えば指のタッチまたはマウス・クリックによって、ARアイコン50を選択する工程100を含むことができる。
図16は、単一のプレイヤーまたはベンチ登録簿全員を選択し、アクティブ化し(工程110)、その後に選択を確認する(工程115)ようにユーザに促す、より小さいウィンドウ60を示す。
図17は、この実施形態で提示されるオプションを示す。このスクリーンが、交替を実行するために料金が課されることを示すことに留意されたい。しかし、交替料金は任意選択である。代替案では、所与のリーグのユーザは、料金が課される前に所与の回数の無料交替を受け取ることができる。
【0086】
特定の実施形態による交代モジュールが、
図18から始まる図面に示されている。図示されているように、私のチームのディスプレイは、選択された時に、本明細書で説明されるシステムのゲーム内交代特徴にユーザがアクセスすることを可能にするボタンまたはアイコンを含むことができる。
図18に示された例では、ボタン70は、「ライン・アップを編集する」というラベルが付けられ、指のタッチ、マウス・クリック、または他のポインティングおよび選択デバイスを使用することによって選択され得る。
【0087】
図18に示されているように、対話式デバイス上の次のスクリーン・ディスプレイは、個々のユーザによって選択されるファンタジー・リーグ名20および/またはチーム名のリスト30のディスプレイを含むことができる。特定の実施形態によれば、リーグ名20の1つを選択することは、システムに、
図19に示されているようにユーザのアクティブ登録簿のリストを含む、他者との1または複数のアクティブ・コンテストの状況を表示させることができる。ディスプレイに示されているように、リーグ名は「インターステート・フットボール・リーグ」であり、ユーザの間のコンテストは、「キッチンズ・クルー」および「ケホーセイブ」と呼ばれる。この例では、ケホーセイブと呼ばれるユーザは、主ユーザと呼ばれる可能性がある。というのは、ユーザが、この図に示された対話式デバイスにアクセスし、これを操作する権限を有するからである。主ユーザのチーム名(ケホーセイブ)は、強調表示される。キッチンズ・クルーのアクティブ登録簿または「先発メンバー」は、左列にリストされ、ケホーセイブのアクティブ登録簿は、右列にリストされる。特定の実施形態によれば、現在生ゲームに参加している主ユーザのアクティブ登録簿のプレイヤーは、強調表示され得る。
図18に示されているように、強調表示されるプレイヤーは、右列の「D.ブリーズ QB」および「J.チャールズ RB」を含む。図示されているように、このディスプレイは、プレイヤーに関する統計または成績情報を含んでもよい。強調表示されるプレイヤーは、現在生ゲームに参加しているので、ゲーム内交代特徴は、ユーザが交代を行うすなわち、選択されたアクティブ・プレイヤーをアクティブ補欠から選択されたプレイヤーに置換することを可能にするように構成され得る。
【0088】
特定の実施形態によれば、
図19の強調表示されたプレイヤーの1人を選択すること(工程210)は、このシステムに、選択されたプレイヤーに関する各種情報を表示させることができる(
図19に示されているように)。このディスプレイは、全般的な情報、統計、ニュース、他者によるコメント、進行中のゲームに関する情報、および選択されたプレイヤーに関するさまざまな他のタイプの情報のいずれかを含むことができる。この例では、
図19は、ドリュー・ブリーズに関する情報を表示する。
【0089】
このディスプレイは、
図20に示されているように、交替アイコン72(この例では矢じりの付いた円形のシンボルと単語「交替」とを使用して図示)を含む一連のアイコンまたはボタンを含むことができる。交替アイコン72をクリックするか他の形で選択することは、主ユーザが生ゲームでの置換のためにこのプレイヤーを選択することを望むことを示す。
【0090】
図20に示されているように、ゲーム内交代モジュールは、その後、選択ウィンドウ74を表示することができ、この選択ウィンドウ74は、特定の実施形態によれば、選択されたプレイヤーを置換することができ、その置換に利用可能でもあるアクティブ補欠リストからのプレイヤーのリストを含む。可能な交代とは、スポーツの同一のポジションまたは役割をプレイする人である。例えば、ランニング・バックだけが、ランニング・バックを置換するための可能な交代になり得る。
図20に示されているように、置換される選択されるプレイヤーは、ドリュー・ブリーズ(クォーターバック)であり、したがって、ゲーム内交代モジュールは、ユーザのアクティブ補欠リスト上で利用可能なクォーターバックのリストを選択ウィンドウ74内に表示するように構成される(ここでは、クォーターバックのアンドリュー・ラック(Andrew Luck)およびジェイ・カトラー(Jay Cutler)が利用可能である)。特定の実施形態によれば、プレイヤー利用可能性は、下でより詳細に議論される条件の所定の組に従って判定される。
【0091】
図20および
図21に示されているように、ユーザは、プレイヤーの1人を選択し、アクティブ化し(工程230)、その後、選択を確認する(工程235)ことができる。この例では、主ユーザは、ジェイ・カトラーを選択する。交代が行われた後に、このシステムは、
図21に示されているように、主ユーザの更新されたアクティブ登録簿または「先発メンバー」を表示することができる(
図21では、「J.カトラー QB」が右列に現れている)。ランニング・バックの選択および置換を示す同様の例が、
図23および
図24に示されている。
【0092】
報告は、特定の実施形態によるゲーム内交代モジュールの別の態様である。
図22に示されているように、ユーザは、交代イベントに関するデータを表示するメッセージ・ウィンドウ76を見るために、交代プレイヤー、この例ではJ.カトラー QBによって達成されるスコアをクリックする(工程300)ことができる。図示されているように、メッセージ・ウィンドウ76は、交代の結果に関するメッセージ(例えば、交代がよいコールであったか否か)と一緒に、交代に関わるプレイヤーに関する達成されたスコアまたは他のデータを含むことができる。メッセージ・ウィンドウ76は、統計、スコアに記録された現実のポイント、スコアに記録されたファンタジー・ポイント、交代に関係するタイム・スタンプ、および他の情報を含むさまざまな他の情報をも含むことができる。ランニング・バックの交代の結果の報告を示す同様の例が、
図25に示されている。
【0093】
利用可能性条件。特定の実施形態による登録簿管理システムは、あるプレイヤーがゲーム内交代に利用可能であるかどうかを、所定の条件の組に従って判定する。
ほとんどのスポーツ・イベントは、オーバータイム・プレイの可能な期間をともなう複数の期間に従って進展する。交代は、利用可能性条件の組に従って、アクティブ・プレイヤーが交代プレイヤーによって置換される時に行われる。
【0094】
アクティブ・プレイヤーは、有資格になるために、(1)ユーザのアクティブ登録簿に現在含まれ、(2)プレイの最終期間にまだ入っていない現実の世界のゲーム内で現在プレイしていなければならない。言い換えると、アクティブ・プレイヤーは、ファンタジー・マッチアップ(2つのファンタジー・チームの間のゲーム)内で現在「プレイしている」必要がある。上で説明された例では、クォーターバックのドリュー・ブリーズが、利用可能なアクティブ・プレイヤーとしてディスプレイ10内で強調表示された。というのは、彼が、ユーザのアクティブ登録簿に含まれ、最終期間にまだ入っていないフットボール・ゲームで現在プレイしているからである。
【0095】
交代プレイヤーは、有資格になるために、ある種の実施形態で、(1)アクティブ・プレイヤーと同一のポジションをプレイし、(2)締切期限の前にアクティブ補欠リストに載せられ、(3)プレイの最終期間にまだ入っていない現実の世界のゲームで現在プレイしているか、まだ開始されていない現実の世界のゲームでプレイするようにスケジューリングされているプレイヤーに制限され得る。上で説明した例では、2人のクォーターバックすなわちアンドリュー・ラックおよびジェイ・カトラーが、交代プレイヤー選択ウィンドウ74内に表示された。というのは、各プレイヤーが、(1)クォーターバックをプレイし、(2)ユーザのアクティブ補欠リストに載っており、(3)最終期間にまだ入っていないフットボール・ゲームで現在プレイしていたか、まだ開始されていない来たるフットボール・ゲームでプレイするようにスケジューリングされたかのいずれかであったからである。潜在的な交代プレイヤーのプールは、利用可能なフリー・エージェントをも含むように拡張され得る。
【0096】
最終期間条件は、下でより詳細に説明するように、交代がプレイ期間の終りにのみ行われることを要求する可能性がある制限された交代機会に従うために課せられる可能性がある。これに関して、アクティブ・プレイヤーが、最終プレイ期間にすでに入ったゲーム内で現在プレイしている場合に、さらなる交代の機会はないはずである。
【0097】
本明細書で使用される最終期間は、フットボールおよび他のスポーツのオーバータイム、野球の延長イニング、ホッケーのペナルティ・シュートアウト、およびサッカーの「ロスタイム」の期間など、通常のまたはレギュレーション・プレイ期間に続く余分なプレイ期間とすることができる。交代が、通常のプレイの最終期間中に要求される場合に、このシステムは、次の機会の間にすなわち、通常のプレイの終りとオーバータイム・プレイの始まりとの後に、交代が発生することを可能にするように構成され得る。交代が要求され、オーバータイムがない場合には、このシステムは、その要求に関してユーザにクレジットを発行することができる。
【0098】
継続時間。アクティブ補欠リストは、さまざまな期間のいずれかの間に使用され得る。例えば、ファンタジー・シーズンでは、関係する期間は、(a)プレイオフ期間を含む、複数の週にわたるシーズン全体、(b)プレイオフ・ゲームを含まない、シーズン内の通常のゲームの組全体、(c)シーズン内のゲームのサブセット(例えば、ある日に、ある週末の間に、単一の週または週のグループの間にプレイされるすべてのゲーム)、(d)単一のゲーム中の時間のサブセット(1つの期間、例えば、フットボール・ゲームの1クォータ、または野球ゲームの1/2イニング)を含む。登録簿管理システムは、その間にアクティブ補欠特徴がユーザから利用可能である継続時間または期間を管理し、調整するように構成され得る。
【0099】
料金は、登録簿管理システムの別の態様である。例えば、アクティブ補欠およびゲーム内交代特徴は、特定のリーグ運営者または他のマネージャによって、無料で、期間あたり単一の料金で、またはなんらかの他のユーザ関連の料金で提供され得る。リーグ運営者は、例えば、アクティブ補欠およびゲーム内交代特徴の無制限の使用に対して、期間(例えば、シーズン全体、ゲームのサブセット、単一のゲーム、単一の期間)あたり単一の料金を請求することができる。リーグ運営者は、例えば、所定の回数の交代Xについて第1の料金を請求し、後続の交代Yごとに第2の料金を請求してもよい。リーグ運営者は、例えばエリート・プレイヤーまたはクリティカルなポジションに関してより高い料金を請求することを選択することもできる。この態様では、本明細書で説明される登録簿管理システムは、リーグ運営者が、本明細書で説明される特徴および機能の使用に関して各種料金システムのいずれかを確立することを許すように構成され得る。
【0100】
許可される交代イベントの回数は、リーグ運営者または他のマネージャに従って構成され、カスタマイズされ得る登録簿管理システムの別の態様である。例えば、このシステムは、無制限の回数の交代イベントを許可するように構成され得る。例えば8人のプレイヤーを含むアクティブ補欠リストに関して、ユーザは、生のゲーム中に利用可能な各機会に8人までの交代を実行することができる。アクティブ・プレイヤーが置換される時に、彼は、アクティブ補欠リストの一部になり、よって、次の機会の交代に利用可能である。同様に、アクティブ補欠プレイヤーが、アクティブ化され、その後にベンチに戻される場合に、そのプレイヤーは、次の機会の交代にもう一度利用可能である。この態様では、アクティブ補欠リストの8人のプレイヤーの選択は、任意のアクティブ・プレイヤーおよび/または任意のアクティブ補欠プレイヤーを含む、各交代機会の8つの交代イベントの組を作成する。
【0101】
異なる例では、登録簿管理システムは、制限された回数の交代イベントを許可するように構成され得る。例えば8人のプレイヤーを含むアクティブ補欠リストに関して、ユーザは、単一の生のゲーム中に合計8つの交代イベントに制限され、それ以上はできないものとされ得る。このシステムは、プレイヤーの繰り返される使用を制限することもでき、例えば、アクティブ・プレイヤーが置換される場合に、このシステムは、彼をアクティブ補欠リストではなくベンチ登録簿に載せ、よって、彼を交代に利用可能ではなくすることができる。同様に、アクティブ補欠プレイヤーが、アクティブ化され、その後に置換される場合に、そのプレイヤーは、ベンチ登録簿に載せられ、もはや交代に利用可能ではなくなる。
【0102】
交代の機会。交代の機会の回数は、登録簿管理システムの特定の実施形態に従って、所定のリストに制限され得る。言い換えると、登録簿管理システムは、1または複数の所定の時間中に限って交代イベントが発生することを可能にするように構成され得る。例えば、このシステムは、交代イベントがプレイの期間の終り(もちろん、ゲームが終了しているので最終期間を除く)に発生することを可能にすることができる。交代機会時間ウィンドウは、プレイ期間の終りに始まり、次のプレイ期間の始めに停止する。交代を実行する要求は、下で説明されるように、特定の実施形態に従っていつでも行うことができる。
【0103】
例えば、NFLフットボールでは、このシステムは、各クォータの終りに交代が発生することを可能にするように構成され得る。交代機会時間ウィンドウは、クォータの終りに始まり、後続クォータの始めに停止する。
【0104】
本明細書で使用される最終期間は、フットボールおよび他のスポーツのオーバータイムなど、通常のまたはレギュレーション・プレイ期間に続く余分なプレイ期間とすることができる。オーバータイムの場合に、時間ウィンドウは、最後の通常のプレイ期間の終りに始まり、ユーザが別の交代を行わない限り、始めに対してオーバータイム期間の終りに終わる。交代は、彼らのゲームの終りまで、または彼らが別のプレイヤーに交替されるまで、存続する。
【0105】
代替実施形態では、登録簿管理システムは、リアル・タイム交代イベントすなわち、生のゲームでアクティブ・プレイ中にプレイヤーを置換すること、例えば、スナップの後だがパスを投げる前にクォーターバックを置換すること、および/またはフットボールが空中にある間にワイド・レシーバを置換することを可能にするように構成され得る。
【0106】
この態様は、
図31に示されたユーザ・インタフェース内のブラケット・スタイル・プレイに関して示される。左のスクリーンはフットボールに関係し、右のスクリーンはNCAAバスケットボールに関係するが、基礎になる概念は、主題のスポーツまたはイベントに無関係に同一である。ユーザは、変更するプレイヤーを選択し、
図38に関して議論されるものに似た交替スクリーンを提示される。ユーザは、彼らの代替の選択を行い、交替を確認する。余分な料金が、交替を行うために課される場合がある。
【0107】
このシステムは、代替案では、ゲーム中の1つの所定の時間またはイベントの発生時または発生中に(例えば、ハーフタイムに)1つの交替イベントだけを許すように構成され得る。
【0108】
このシステムは、ゲーム中に、例えば、タイムアウト中、公式時計が停止される期間中、ポゼションの変更の後、コマーシャル時間中、または有限のもしくは別個の時間ウィンドウとして登録簿管理システムによって認識される任意の期間に、多数の交代機会を提供するようにも構成され得る。この態様では、登録簿管理システムは、ある程度まで、入力されるデータ・フィード(現実の世界のスポーツ・イベントからの)の利用可能性と、各そのようなデータ・フィード内に含まれる詳細のレベルとに頼る。別の実施形態では、このシステムは、ゲーム内の2つの別個のイベントの間に交替イベントが発生することを許すように構成され得る。例えば、NFLフットボールでは、このシステムは、オフェンス・ドライブの始めとオフェンス・ドライブの終りとの間などにディフェンス・プレイヤーの交替が行われることを許すことができる。
【0109】
特定の実施形態による交替の要求は、将来の交替の機会の前の任意の時に、本明細書で説明される登録簿管理システムによって受信され、処理され得る。言い換えると、登録簿管理システムは、ユーザがいつでも要求を送出し、将来の交替の機会に特定の交替を実行するようにシステムに指示することができるようにするために構成され得、この将来の交替の機会は、次の利用可能な機会(例えば、次のプレイ期間の終り)またはある将来の機会(例えば、ハーフタイム中またはレギュレーション・プレイの最終期間の終り(この場合に、要求は、オーバータイム期間がある場合に限って実行されるはずである))とすることができる。
【0110】
例えば、NFLゲームでのプレイの最初の2〜3分の間に、ユーザは、第1のクォータの終りになる可能性がある次の利用可能な機会にシステムがクォーターバック交替を実行する要求を送出することができる。現在のクォーターバックは、プレイの第1のクォータを完了し、このシステムは、第2のクォータが始まる時に置換クォーターバックがプレイを開始するようにするために、交替を実行するはずである。この態様では、登録簿管理システムは、プレイのすべての期間中にユーザのアクティブ・コーチング経験を提供し、所定の交代機会時間中に限って交替を実行する。
【0111】
交替の要求を送出するための時間ウィンドウは、適当に構成される場合に登録簿管理システムによって制限されるはずである。例えば、このシステムは、プレイ期間の終りより1分以上前にユーザが要求を送出することを要求するように構成され得る。この締切期限に、このシステムは、その期間の終りに交替を行う要求の受信を停止するはずである。「遅い」要求は、将来の機会にすなわち、次の利用可能な機会またはユーザの選択する将来の機会のいずれかに実行されるはずである。
【0112】
通知。登録簿管理システムは、現実の世界のイベントを監視し、ユーザに通知を送信するように構成され得る。
図26に示されているように、サービス・インタフェース400は、ユーザの登録簿データにアクセスし、フィード・データ25から入力される現実の世界の情報を受信し、解析し、他の形で処理し、関心を持たれている情報を含む各種通知を準備し、ユーザに送信するように構成された通知エンジン420を含むことができる。通知は、プレイヤーの成績または現在の統計など、ユーザのアクティブ登録簿、ベンチ登録簿、またはアクティブ補欠リストのプレイヤーに関する(または別のユーザのプレイヤーに関する)情報を含むことができる。
【0113】
通知エンジン420は、データを処理し、関連するプレイヤーまたはゲームに関する現在の情報を報告し、交替を提案する、ユーザへの通知を生成するようにも構成され得る。この態様では、そのような通知は、プレイヤー交代を行うことを考えるようにユーザに促すことを意図された、登録簿管理システムによって準備される先を見越した提案として働くことができる。通知エンジン420は、例えば、プレイヤーの怪我(ユーザのプレイヤーおよび相手のプレイヤー)、ゲーム・スコア、プレイヤー成績傾向、天気、プレイヤー・ペナルティ、ベンチに戻されまたは退場とされたプレイヤー、プレイヤー状況(経過したプレイ時間、ピッチ・カウント、放ったショットなど)を含む、さまざまな現実の世界のイベントのいずれかに基づいてそのような通知を作成するように構成され得る。
【0114】
NFLフットボール・ゲームを例として使用すると、コーチング判断は、通常、あるチームが他のチームに対して大きいポイント・リードを達成するかどうかおよびその時を変化させる。負けている方のチームは、通常、ボールをよりしばしばパスし、より低頻度でラッシュし、パスするレシーバが、ファンタジー・ポイントをスコアするより多くの機会を有し、ランニング・バックが、ファンタジー・ポイントのスコアを得るより少ない機会を有するシナリオを作る。このシナリオでは、ファンタジー・ユーザ(負けているチームのコーチなど)は、交代を行うことを選択することができ、例えば、彼の最強のパスするレシーバをアクティブ・プレイヤーにすることができる。
【0115】
大きいポイント差は、勝っているチームのコーチに、1または複数の先発プレイヤーをベンチに戻させることもできる。ベンチに戻っている間に、これらのプレイヤーは、ファンタジー・ポイントのスコアを記録することができず、したがって、ユーザは、彼のファンタジー・チームがポイントをスコアに記録する能力を有することを確かにするために、彼のアクティブ補欠から交代を行うことを望む可能性がある。
【0116】
プレイヤーの怪我は、時々劇的に、コーチング判断にも影響する。プレイヤーが怪我をしている間に、そのプレイヤーは、ファンタジー・ポイントをスコアに記録することができず、したがって、ユーザは、交代を行うことを望む可能性がある。また、プレイヤーの怪我は、対戦相手のプレイヤーに関する通知を生成することもできる。例えば、ワイド・レシーバがパスをキャッチするのを防ぐ第1の責任を負う主要な守備プレイヤーが怪我をする場合に、より能力の低い守備プレイヤーが、その代わりにプレイする可能性が最も高い。この変化は、1または複数のワイド・レシーバの交代を行うためのファンタジー・ユーザの判断に影響する可能性があり、このワイド・レシーバは、おそらくは、ゲームの残りの間にポイントをスコアに記録することができる可能性がより高い。この態様では、単一のプレイヤーまたはイベントに関する通知を受信することは、そのプレイヤーに関するユーザの判断に影響するだけではなく、対戦相手のプレイヤーに関する判断にも影響する可能性がある。
【0117】
通知エンジン420は、ファンタジー・ユーザが追加のポイントをスコアに記録する特定の機会を有する可能性がある状況を含むがこれに限定はされない、さまざまなファンタジー関係イベントのいずれかに基づいて通知を作成するようにも構成され得る。例えば、ファンタジー・マッチアップで、ファンタジー・ユーザの相手が、彼のすべてのプレイヤーをプレイし、その週の彼のゲームが完了すると仮定する。ファンタジー・ユーザは、まだプレイしていない1または複数のプレイヤーを有する可能性がある。通知エンジン420は、勝つために必要なポイントを計算し、「サンダーゾン(SanderZon)のチームは136ポイントをスコアに記録し、彼の今週のゲームは完了しました。サンダーゾンとのマッチアップに勝つためには、残りのプレイヤーAおよびBから(または、交代を行う場合にはその置換から)少なくとも34ポイントが必要です。」のような通知をファンタジー・ユーザに送信することができる。この態様では、システムは通知を提供し、その結果、参加するファンタジー・ユーザは、ファンタジー・マッチアップに勝つ可能性を改善するために、1または複数の現実の世界のイベントに関連する、交代を含むアクティブ・コーチング判断を行う機会を有するようになる。
【0118】
ユーザを選択するために通知を生成し、送信するように通知エンジン420に促す、さまざまな潜在的なシナリオのいずれもが、現実のゲーム内で発展する可能性がある。特定の実施形態によれば、通知エンジン420は、現実の世界のゲームまたはファンタジー・マッチアップ内のアクティブ・コーチによって行われる判断に対して通常は影響を有するすべてのイベントに応答して通知を生成するように構成され得る。この態様では、システムは通知を生成し、その結果、参加するファンタジー・ユーザは、アクティブ・ゲーム中に発生する現実の世界のイベントに応答して、交代を含むアクティブ・コーチング判断を行う機会を有するようになる。
【0119】
スコアへの記録。登録簿管理システムは、ファンタジー・マッチアップに参加しているさまざまなすべてのプレイヤーによってスコアに記録されるファンタジー・ポイントを監視し、記録するように構成され得る。
図26に示されているように、サービス・インタフェース400は、規則の組に従ってスコアに記録する機能を実行するように構成されたファンタジー・スコア・ハンドラ440を含むことができる。
【0120】
交代の文脈では、一般に、アクティブ・プレイヤーは、交代が実行される前の任意の期間中に彼の成績に関するファンタジー・ポイントを稼ぐ。その後、交代プレイヤーは、残りのプレイ期間の間に(または、そのプレイヤーが別の交代によって置換されるまで)、彼の成績に基づいてポイントを稼ぐ。しかし、異なる時に発生するゲームに関して、ファンタジー・スコア・ハンドラ440は、ある種のイベントが発生する正確な時刻を含む各種要因に従ってスコアへの記録を調整するように構成され得る。
【0121】
ファンタジー・マッチアップでゲーム内交代を許す特徴は、プレイヤーが通常は同一時刻にまたは同一の現実の世界のゲーム内でプレイしていない時に、プレイヤー利用可能性条件(現実のゲームが最終プレイ期間に入ったかどうかを含む、上で説明されたもの)、交代の機会および時間ウィンドウ(例えば、上で説明された、プレイ期間の間)、ならびにファンタジー・ポイントのスコアへの記録を含む、複数のデータ処理の難題をもたらす。
【0122】
上で説明された利用可能性条件のタイミング要件要素に従って、アクティブ・プレイヤーは、通常、まだ最終プレイ期間に入っていない現実の世界のゲームで現在プレイしている時に限って有資格である。しかし、プレイヤーは、交代されるために現在プレイしている必要はない。このシステムは、ゲームが同時であれ、一方が他方の前であれ、その逆であれ、フリーズ、ニュートラル、およびクロスオーバ交替に対処することができる。また、それと同時に、ゲーム・クロックが問題ではない場合に、このシステムは、期間/クォータの終りに交替を行う。主な一般的な規則は、ユーザが、クォータ/期間に関して時間的に戻って交替することができず、将来のクォータ/期間の間に限って交替できること、すなわち、ユーザが、その間にプレイヤーを交替させたい期間をまだ開始していないプレイヤーだけを交代させることができることである。
【0123】
交代プレイヤーは、(a)まだ最終プレイ期間に入っていない現実の世界のゲームで現在プレイしているか、(b)まだ開始されていない現実の世界のゲームでプレイするようにスケジューリングされているかのいずれかである時に限って有資格である。条件のこの組は、3つの可能なシナリオをもたらす。
【0124】
第1のシナリオが発生するのは、交代プレイヤーが、まだ開始されていない、ゲーム2と呼ばれる現実の世界のゲームでプレイするようにスケジューリングされている時である。ユーザは、ゲーム1のアクティブ・プレイヤーを交代させる要求を発行する。ファンタジー・スコア・ハンドラ440は、現実の万国標準時とゲーム1クロックに対する相対的との両方で要求時刻を記録する。例えば、要求は、ゲーム1の期間2中にクロック上で2分30秒が経過した時に行われる。この例のゲーム1クロックは、2:02:30(期間2:02分:30秒)として記録され得る。
【0125】
期間の終りにのみ交代を実行する登録簿管理システムでは、アクティブ・プレイヤーの交代は、ゲーム1の期間3の開始まで有効にならないはずである。アクティブ・プレイヤーは、期間2の終りまでファンタジー・ポイントをスコアに記録し続けるはずである。ゲーム2(まだ開始されていない)に関して、スコアへの記録のために、ファンタジー・スコア・ハンドラ440によって制御されて、交代プレイヤーは、ゲーム2の期間3の第1の新しいプレイまで、プレイおよびファンタジー・ポイントのスコアへの記録を「開始」しないはずである。
【0126】
要求時に交代を実行する登録簿管理システムでは、アクティブ・プレイヤーの交代は、ゲーム1クロックが2:02:30を過ぎた後の次の新しいプレイの開始にともなって「即座に」有効になるはずである。スコアへの記録のために、ファンタジー・スコア・ハンドラ440によって制御されて、交代プレイヤーは、ゲーム2クロックが2:02:30を過ぎた後の第1の新しいプレイの開始まで、プレイを「開始」しないはずである。この態様では、交代が要求され実行される時にゲーム2がまだリアル・タイムで開始されていないが、交代は、それぞれのゲーム・クロックに従って時間調整される。
【0127】
第2のシナリオが発生するのは、交代プレイヤーが現在ゲーム2でプレイしており、(a)ゲーム2がまだその最終プレイ期間に入っておらず、(b)ゲーム2がゲーム1より後に開始され、かつ/またはゲーム2クロック上でゲーム1クロックより短い時間が経過している時である。ユーザは、ゲーム1のアクティブ・プレイヤーを交代させる要求を発行する。ファンタジー・スコア・ハンドラ440は、現実の万国標準時とゲーム1クロックに対する相対的との両方で要求時刻を記録し、この要求時刻は、2:02:30(期間2:02分:30秒)として記録され得る。このシナリオでは、第1のシナリオと同一のスコアへの記録の規則が適用されるはずである。
【0128】
期間の終りにのみ交代を実行する登録簿管理システムでは、アクティブ・プレイヤーの交代は、ゲーム1の期間3の開始まで有効にならない。アクティブ・プレイヤーは、期間2の終りまでファンタジー・ポイントをスコアに記録し続けるはずである。ゲーム2(より後に開始され、まだ進行中である)に関して、スコアへの記録のために、ファンタジー・スコア・ハンドラ440によって制御されて、交代プレイヤーは、ゲーム2の期間3の第1の新しいプレイまで、プレイおよびファンタジー・ポイントのスコアへの記録を「開始」しないはずである。要求時に交代を実行する登録簿管理システムでは、アクティブ・プレイヤーの交代は、ゲーム1クロックが2:02:30を過ぎた後の次の新しいプレイの開始にともなって「即座に」有効になるはずである。スコアへの記録のために、ファンタジー・スコア・ハンドラ440によって制御されて、交代プレイヤーは、ゲーム2クロックが2:02:30を過ぎた後の第1の新しいプレイまで、プレイを「開始」しないはずである。この態様では、交代が要求され実行される時にゲーム2がまだリアル・タイムで開始されていないが、交代は、それぞれのゲーム・クロックに従って時間調整される。
【0129】
第3のシナリオが発生するのは、交代プレイヤーが現在ゲーム2でプレイしており、(a)ゲーム2がまだその最終プレイ期間に入っておらず、(b)ゲーム2がゲーム1より前に開始され、かつ/またはゲーム2クロック上でゲーム1クロックより長い時間が経過している時である。言い換えると、ゲーム2は、最初に開始し、かつ/またはさらに進んでおり、おそらくはより早く終了する。一般に、ファンタジー・スコア・ハンドラ440は、ユーザが、「時間をさかのぼり」、交代プレイヤーの過去の成績からポイントを取り込むことを防ぐように構成され得る。
【0130】
ユーザは、ゲーム1クロックによる2:02:30に、ゲーム1のアクティブ・プレイヤーを交代させる要求を発行する。例えば、交代が、ゲーム2の期間3中にクロック上で4分50秒が経過した時に実行されると仮定する。ゲーム2クロックは、3:04:50(期間3:04分:50秒)として記録され得る。
【0131】
期間の終りにのみ交代を実行する登録簿管理システムでは、アクティブ・プレイヤーの交代は、ゲーム1の期間4の開始まで有効にならない。アクティブ・プレイヤーは、期間3の終りまでファンタジー・ポイントをスコアに記録し続けるはずである。ゲーム2(期間3の途中である)に関して、スコアへの記録のために、ファンタジー・スコア・ハンドラ440によって制御されて、交代プレイヤーは、ゲーム2の期間4の第1の新しいプレイまで、プレイおよびファンタジー・ポイントのスコアへの記録を「開始」しないはずである。
【0132】
要求時に交代を実行する登録簿管理システムでは、アクティブ・プレイヤーの交代は、即座に有効にはならないはずである。アクティブ・プレイヤーは、ゲーム1クロックが3:04:50に達する時に発生するアクティブ・プレイの終りまで、ファンタジー・ポイントをスコアに記録し続けるはずである。交代プレイヤーは、ゲーム2クロックが3:04:50を過ぎた後の第1の新しいプレイまで、プレイを「開始」しないはずである。この態様では、交代は、それぞれのゲーム・クロックに従って時間調整される。
【0133】
報告は、本明細書で説明される登録簿管理システムの別の態様である。サービス・インタフェース400は、柔軟な使い易い報告インタフェースを含む報告エンジン450を含むことができる。報告エンジン450は、交代が成功である(より多くのポイントまたは別の有利な結果をもたらす)時および/または交代が失敗である時にユーザに報告を表示するように構成され得る。報告エンジン450は、単一の交代イベントまたはその代わりに、ある期間(上で説明したように、シーズン全体、シーズンのサブセット、1ゲーム、1日、1週間または週末、ゲームの特定のサブセットなど)中に発生する交代イベントの組の結果を監視し、報告することができる。同一の期間(同一のゲーム、同一の期間など)中に他人によって行われた交代に対する相対的なユーザの交代の結果を示す、他のユーザとの比較が、監視され、報告され得る。
【0134】
さらに、報告エンジン450は、例えば、(a)任意選択で特定の対戦相手のユーザの交代の正味の効果を含む、その特定の対戦相手のユーザの交代に対する相対的な、(b)選択されたグループまたはリーグ内の対戦相手のユーザのサブセットに対する相対的な、(c)グループとしてのリーグ内のすべてのユーザの交代に対する相対的な、および/あるいは(d)地理的位置、学校もしくは職場への所属、チームまたはファン・グループへの所属、アクティブ補欠リスト上に同一のプレイヤーを有するユーザ、特定の時間ウィンドウ中に交代のために同一のプレイヤーを使用したユーザ、または判断基準の任意の他の組など、判断基準の特定の組を満足する他のユーザのサブセットに対する相対的な、ユーザの交代の報告を含む、ある人またはサブセットに対する相対的な、ユーザによって行われた1または複数の交代イベントの結果を監視し、報告するように構成され得る。
【0135】
報告エンジン450は、データベース500などのログまたはデータ・ストア内で過去の報告のレコードを維持するようにさらに構成され得る。この態様では、登録簿管理システムは、ユーザによって行われた複数の交代イベントのヒストリカル・レコードを提供することができる。このシステムは、他のユーザに関してまたはなんらかの他の期間もしくはメトリックに対して、経時的なユーザの交代の分析をさらに含むことができる。このシステムは、ユーザに仮想「コーチング・ヒストリ」を提供することができ、例えば、ある週またはシーズン全体の間に行われた交代の回数を示し、改善されたファンタジー・スコアをもたらした交代のパーセンテージおよび回数を表示し、これによってユーザのスキルの表示を提供する。このシステムは、どの交代がより多くのファンタジー・ポイントを生み出したかの表示と一緒に、要求された可能性がある他の利用可能な交代の組に対するユーザの実際の交代の比較をも含むことができる。
【0136】
開発プレイヤー・シート。初心者は、ファンタジー・スポーツにおける最大のリスクの1つを表す。多くの初心者は、多くの初心者は、うまくプレイしないか、彼らの最初のシーズンの多くをベンチで過ごし、ファンタジー・ポイントをほとんどまたは全く稼がず、登録簿のシートを占めるかのいずれかである。次のシーズンに関して、ユーザは、ドラフトでもう一度初心者を選択するか、その代わりに異なるプレイヤーを選択するかどうかを判断しなければならない。
【0137】
現在利用可能なファンタジー・スポーツ・システムは、ユーザが、初心者をすべての他のプレイヤーと全く同様に扱うことを要求する。しかし、多くのユーザは、異なるより現実的な形で初心者を扱うファンタジー・システムを強く望んでいる。
【0138】
キーパースタイル・ファンタジー・スポーツ・リーグは、ユーザが、あるシーズンから次のシーズンへ、彼らのファンタジー・チームに1または複数のプレイヤーをキープすることを可能にする。リーグ規則は、キープされ得るプレイヤーの人数ならびにチームにプレイヤーをキープする選択をユーザが行うためのコストまたはペナルティを決定する。例えば、規則は、プレイヤーが、次のシーズンに6人までのプレイヤーをキープすることを許す場合がある。
【0139】
別の態様では、登録簿管理システムは、1人の開発プレイヤーのためのベンチ登録簿上の指定されたシートを含むことができる。開発プレイヤー・シートは、特定の実施形態によれば、キーパースタイル・リーグの初心者プレイヤーに特によく適する可能性がある。運営中に、ユーザは、ドラフトで初心者を選択し、その初心者をベンチ登録簿の開発プレイヤーに割り当て、ここで、初心者は、第1のシーズン全体の間、留まらなければならない。第1のシーズンの終りに、キーパースタイル・リーグでは、ユーザは、初心者を「キープする」オプションを有し、初心者の第2のシーズンの間に初心者をアクティブ登録簿に移動する。
【0140】
一実施形態では、登録簿管理システムは、開発プレイヤー(初心者)を彼の第2のシーズンの間に捕まえるために、1つの追加のキーパー・スロットを使用するオプションをユーザに提供する。例えば、規則が、次のシーズンに6人までのプレイヤーをユーザがキープすることを許すリーグでは、規則は、ユーザが、次のシーズンの第7のキーパーとして開発プレイヤー(初心者)をもキープすることを許す。この態様では、ユーザは、シーズンの終りに「1人の追加のキープ」として開発プレイヤーを使用するオプションと引き換えに、開発プレイヤーが、第1のシーズン全体の間、ベンチ登録簿に留まるという規則を受諾する。
【0141】
システム・アーキテクチャ
ここで
図26を参照すると、サービス・インタフェース400は、APIとすることができ、このAPIは、一般に、各種ソフトウェア構成要素の間およびその中での動作を指定し、制御する。データベースおよびコンピュータ・ハードウェアへのアクセスに加えて、APIは、システム全体がどのようにしてルーチンを実行し、データ構造を構築し、アクセスし、サービスを実行し、他の要素に対する「API呼び出し」を行う(例えば、データを提供しまたはデータを探すために)のかを制御するのに使用され得る。
【0142】
サービス・インタフェース(API)400は、図示されているように、データベース500およびフィード・データ25に接続された各種構成要素を含むことができる。データベース500は、単一のデータベース、ルックアップ・テーブルの組、リレーショナル・データベースの組、または情報を記憶し、アクセスするための任意の他の構造を含むことができる。フィード・データ25は、スポーツのすべての態様に関する各種情報を含む複数の入力されるデータ・フィードを含むことができる。例えば、フィード・データ25は、各種統計および成績情報と一緒に、現在進行中のゲームのリスト、各ゲームにアクティブに参加しているプレイヤーのリスト、プレイヤー状況(アクティブ、ベンチ入り、怪我、除去、退場など)、ゲーム・スコア、チーム・フィールド・ポジション、プレイヤー怪我報告、天気、ペナルティを含むことができる。
【0143】
サービス・インタフェース(API)400は、1または複数の中央サーバ・マシンの一部とされ得、この中央サーバ・マシンは、デスクトップ・コンピュータ、ラップトップ、タブレット、およびハンドヘルド・デバイスなどのリモート・クライアントと相互作用する。
【0144】
登録簿マネージャ410は、登録簿データを処理し、ユーザ(クライアント)から要求を受信し、処理するように構成され得る。登録簿マネージャ410は、リアル・タイム統計にアクセスし、評価するために、例えばフィード統計データ・ハンドラ470を含む他の構成要素にアクセスすることができる。登録簿マネージャ410は、交代の要求を処理し(下で説明する)、規則と登録簿管理システムの特定の実施形態によって課せられる条件とに従ってプレイヤー交代を実行するように構成され得る。
【0145】
通知エンジン420は、登録簿データおよびフィード・データ25からの現実の世界のイベントを分析し、その分析に基づいて、1または複数の通知を構成し、ユーザに送信するように構成され得る。通知は、プレイヤーの成績または現在の統計など、ユーザのチーム・メンバーに関する情報を含むことができる。また、下でより詳細に説明するように、通知は、関連するプレイヤーまたはゲームに関する現在の情報を報告し、交代を提案する、ユーザへの1または複数のプロンプトを含むことができる。
【0146】
ユーザ・マネージャ430は、各ファンタジー・スポーツ・プロバイダがそれ自体の規則の組を管理できるようにするために、APIセッティングをセットし、維持するように構成され得る。ファンタジー・スコア・ハンドラ440は、各運動家のプレイおよび成績に関する受信されたデータに基づいて、スコアへの記録機能を実行し、任意選択で、ファンタジー・ポイントを授与するように構成され得る。
【0147】
報告エンジン450は、ユーザが、彼らのコーチング判断(すなわち、プレイヤー交代)が彼らのファンタジー・マッチアップの結果にどのように影響したのかを見るための柔軟な報告インタフェースを提供する。報告インタフェースは、ユーザが、交代のタイプによって、ポジションによって、期間によって、ある相手に対して相対的になど、ビューをフィルタリングすることを可能にすることができる。
【0148】
登録簿データ・ハンドラ460は、データベース500への登録簿データおよび交代工程の記憶を含めて、登録簿管理システムの特定の要素のための論理を収容するように構成され得る。
【0149】
フィード統計データ・ハンドラ470は、フィード・データ25の一部である1または複数のスポーツ・フィード・サービスと一体化され得る。ハンドラ470は、フィード・データ25から特定の統計を取り出し、解析し、関連するデータをデータベース500に記憶することができる。ハンドラ470は、相対的に高い頻度および回数のデータ要求を管理すると同時に、登録簿管理システムを使用して行われるイベントの正確なヒストリカル・ログを維持するようにも構成され得る。
【0150】
直接対決挑戦システム・アーキテクチャ。
図27〜
図30を参照して、直接の挑戦または「マーノ・エ・マーノ」に関するシステム・アーキテクチャを議論する。
図27は、各種実施形態による、サービス・インタフェース600と直接挑戦アプリケーションのさまざまな関係する要素とを示す。
【0151】
直接挑戦アプリケーションは、1または複数のスポーツ情報フィードなど、外部ソース602からの入力されるデータ・フィードと通信しているものとされ得る。データ・ソース(内部または外部)ごとに、データ・ソース、競技者、ユーザによって作成されたマッチアップ、現実の世界のイベントの時刻および結果、ならびに競技者の量的統計および成績を管理するように構成されたイベント・データ・ハンドラ604があってもよい。
【0152】
サービス・インタフェース600は、モバイル・アプリ(例えば、スマートフォンおよびタブレット・コンピュータ上)、ウェブ・アプリ、スマートTVアプリ、およびゲーム機を含む各種ユーザ・インタフェース606を介してユーザによって対話される。ユーザがゲーム・システムと対話することを可能にするためにサービス・インタフェースと共にネットワーク化されたコンピュータ・キオスクも、提供され得る。
【0153】
図28を参照すると、直接の挑戦システムは、スポーツ・フィードA、B、その他などの1または複数の外部データ・リーダ608およびコンテンツAPIを利用して、スポーツ・フィードおよび他のコンテンツ・プロバイダなどの外部データ・サービスから利用可能な挑戦データを収集することができる。挑戦のデータは、統計データベースに手作業で供給されることも可能である。
【0154】
図29を参照すると、外部データ・リーダ608から挑戦システムに到着するデータは、挑戦システムによって必要とされる、イベント日付、競技者、量的統計などのデータの特定のフォーマッティングを有する場合がある。イベント・データ・ハンドラ610トランスレータは、そのような外部ソースからのデータを、挑戦システムによって使用される共通のマッチアップ・データ612フォーマットに変換するために提供され得る。これは、例えば、XMLデータ・フォームの使用を介して達成され得る。
【0155】
データ・ソースごとに、データ・ソースを管理し、競技者、イベント時刻、および量的統計を組み合わせる一連の可能なおよび実際のマッチアップを作成する、イベント・データ・ハンドラがある。マッチアップは、システム・ビジネス・ロジックに基づいて挑戦システムによって自動的に作成され、そのようなマッチアップをユーザに提案することができる。
【0156】
図30を参照すると、挑戦アプリケーションは、ユーザAが競技者を選択し(例えば、手作業でまたは選択エンジンを使用して)、競技者の競争相手の1人を選択し、これによってマッチアップを識別する出発点620から進行するように構成され得る。挑戦アプリケーションは、ユーザAが挑戦622を作成するのに必要なパラメータ、例えば、「[競技者]が[このイベントまたは期間]中に[努力のこの分野]で[競技者の競争相手]を[しのぐ]」を選択することを可能にするようにさらに構成され得る。挑戦が作成された後に、ユーザAは、挑戦アプリケーションを使用して仲間のユーザすなわちユーザBを選択し、その後、挑戦をユーザBに対して発行することができる。
【0157】
ユーザBは、挑戦624を受諾しまたは拒絶することができる。挑戦が受諾される場合に、挑戦は、公式に作成される626。挑戦アプリケーションは、競技者および競争相手の成績を監視し、マッチアップの勝者を識別し628、挑戦を処理し630、リーダボードにスコアを投稿する632。このシステムは、現実の金銭の賭け代が挑戦に含まれる場合に、現実の金銭の賭け代の記録、収集、および調停を実行することもできる。
【0158】
別の態様では、挑戦アプリケーションは、さまざまな競技者の間およびその中で複数のマッチアップを自動的に選択し、作成し、その後、挑戦での使用のためにそのようなマッチアップをユーザに提案するように構成され得る。
【0159】
本明細書ではいくつかの実施形態が記述されたが、本開示の教示の利益を有する当業者は、この技術に関する他の多くの実施形態および修正を理解および認識するであろう。したがって、本発明は、本明細書で開示されまたは議論される特定の実施形態に限定されず、他の実施形態および修正は、添付の特許請求の範囲または発明的概念の範囲に含まれることが意図されている。さらに、本明細書ならびに後続の特許請求の範囲または概念では特定の用語が使用されることが時としてあるが、そのような用語は、包括的および説明的な意味で使用されるにすぎず、記述された発明または後続の特許請求の範囲もしくは概念を限定するものと解釈されるべきではない。