JP2022117512A - システム - Google Patents

Abstract

【課題】ベットへの参加意欲が増すことに寄与できる配当分配システムを提供する。【解決手段】ベット端末６の操作判定手段６７２は、プレイヤのゲームプレイに対して、ギャラリーがベットするベット操作を受け付ける。サーバ装置２の配当倍率決定手段２３７は、ゲームプレイに対応する配当倍率を、プレイヤの人気度に基づいて決定する。サーバ装置２の配当付与手段２３８は、ゲームプレイの結果および配当倍率に基づいて、ゲームプレイへのベット操作に対する配当をギャラリーに付与する。【選択図】図１

Description

本開示は、システムに関する。

特許文献１に示すように、プレイヤが行うゲームプレイに対して、ギャラリーがベットできるゲームが知られている。ゲームプレイ終了後、ギャラリーには、そのプレイにおける勝敗結果に応じて配当が付与される。

国際公開２０１６／０９２６３４号

特許文献１におけるギャラリーへの配当額は、ゲームプレイの勝敗結果と、予め定められた配当倍率とに応じて定められる。一般的に、配当倍率の値は、ゲームプレイの運営者側の都合で決定されるが、ベットする側であるギャラリーにとって親しみやすい情報を反映させた値であれば、ベットへの参加意欲を増すきっかけとなり得る。

本開示の目的は、ベットへの参加意欲が増すことに寄与することである。

本開示にかかる第１の態様は、
第１ユーザのゲームプレイに対して、第２ユーザがベットするベット操作を受け付けるベット受付部と、
前記ゲームプレイに対応する配当倍率を、前記第１ユーザの人気度に基づいて決定する配当倍率決定部と、
前記ゲームプレイの結果および前記配当倍率に基づいて、前記ゲームプレイへの前記ベット操作に対する配当を前記第２ユーザに付与する配当付与部と
を備える配当分配システムである。

また、第１の態様において、
前記配当倍率の決定にて用いられる前記人気度は、前記第１ユーザの現在までの行動に基づく軌跡によって設定された情報である、
ことができる。

また、第１の態様において、
前記配当倍率決定部は、更に前記ベット操作に応じたベット状況に基づいて、前記配当倍率を決定する
ことができる。

また、第１の態様において、
第３ユーザによる作成操作に基づいて、前記ゲームプレイにて利用可能な利用媒体を作成する媒体作成部、
を更に備えることができる。

また、第１の態様において、
前記第１ユーザの操作に基づいて、前記ゲームプレイにて使用する前記利用媒体を選択する媒体選択部、
を更に備えることができる。

また、第１の態様において、
前記第３ユーザの識別情報に前記第１ユーザの識別情報を対応付けることにより、前記第３ユーザを記第１ユーザのフレンドとして登録する処理を行うことが可能なフレンド登録部、
を更に備え、
前記媒体選択部による選択候補には、前記フレンドに登録されている前記第３ユーザの作成した前記利用媒体、が含まれる
ことができる。

また、第１の態様において、
前記第２ユーザの識別情報に、前記第１ユーザの識別情報および前記第３ユーザの識別情報の少なくとも一方を関連付けることより、前記第２ユーザを、前記第１ユーザおよび前記第３ユーザの少なくとも一方を支援する支援者として登録するとともに、前記第１ユーザおよび前記第３ユーザそれぞれに対して前記支援者が支援を行った支援情報を、前記第１ユーザおよび前記第３ユーザごとに管理する支援者登録部と、
前記支援情報に応じて、前記第１ユーザおよび前記第３ユーザの少なくとも一方に、前記ゲームプレイに関するプレイ報酬を付与する報酬付与部と
を更に備えることができる。

また、第１の態様において、
前記支援者は複数存在し、
前記支援情報に応じて複数の前記支援者の識別情報それぞれを分類する分類部、
を更に備え、
前記報酬付与部は、前記分類結果と、前記支援者の支援対象である前記第１ユーザおよび前記第３ユーザそれぞれの前記ゲームプレイに関する活躍に応じた評価値と、に応じた支援報酬を、前記支援者に付与する
とすることができる。

また、第１の態様において、
前記支援情報に応じて、前記第１ユーザおよび前記第３ユーザの少なくとも一方に、前記ゲームプレイに関するプレイ報酬を付与する報酬付与部、
を更に備え、
前記報酬付与部は、前記プレイ報酬を、前記ゲームプレイの結果、前記ベット操作に応じたベット状況、前記第１ユーザの人気度、および、前記第３ユーザの人気度、少なくとも１つに基づいて決定する
ことができる。

また、第１の態様において、
前記第３ユーザの人気度を、前記第３ユーザが作成した前記利用媒体を使用して行われた前記ゲームプレイである所定プレイの結果、前記所定プレイにおける前記第１ユーザへのベット状況、前記第３ユーザを支援する支援者の数、前記第３ユーザが支援を受けた支援数、の少なくとも１つに基づいて算出する人気度算出部、
を更に備えることができる。

また、第１の態様において、
前記支援者の支援対象である前記第１ユーザおよび前記第３ユーザ、の少なくとも一方が関与する前記ゲームプレイを、前記支援者によるベット対象候補に決定するベット対象決定部、
を更に備え、
前記ベット対象候補には、複数の前記ゲームプレイが含まれ、
前記ベット受付部は、前記ベット対象候補のうち所定のゲームプレイへの、前記ベット操作を受け付ける、
ことができる。

また、第１の態様において、
前記第１ユーザの人気度を、前記第１ユーザが関与した前記ゲームプレイの結果、前記第１ユーザへのベット状況、前記第１ユーザを支援する支援者の数、前記第１ユーザが支援を受けた支援数、の少なくとも１つに基づいて算出する人気度算出部、
を更に備えることができる。

配当倍率は、プレイヤの人気度に基づいて決定される。そのため、ギャラリーは、ベットへの参加意欲が増し、ゲームへの興味心が向上する。

配当分配システムの概要を説明するための図である。 配当分配システム全体の構成図である。 サーバ装置の構成の模式図である。 ユーザＤＢの概念図である。 ゲーム端末の構成の模式図である。 ベット端末の構成の模式図である。 予定されているゲームプレイに関する情報を一覧表示する画面例である。 ビルダー端末の構成の模式図である。 キャラクタの作成時に表示される編集画面例である。 配当分配システムの動作を表すフローチャートである。 配当分配システムの動作を表すフローチャートである。

本実施形態にかかる配当分配システム１について、図面を参照して説明する。

＜配当分配システム１の概要＞
図１に示すように、配当分配システム１は、第１ユーザがプレイヤとなってゲームプレイを行う傍ら、第２ユーザがギャラリーとなって、そのゲームプレイに対して遊戯媒体をベットすることを実現したシステムである。更に、第３ユーザがビルダーとなって、ゲームプレイにて使用可能なゲーム媒体を一から作成したり育成したりすることができる。

以下では、ビルダーがゲーム媒体を一から作成したり育成したりする行動を、まとめて「作成」という。

本実施形態では、ゲームプレイの対象となるゲームが、プレイヤの操作するプレイヤキャラクタを、他のプレイヤキャラクタまたはノンプレイヤキャラクタとゲーム空間で対戦させる対戦型アクションゲームである場合を例示する。プレイヤは、複数のキャラクタの中から１のキャラクタをプレイヤキャラクタとして選択し、そのプレイヤキャラクタを操作して、対戦相手となる他のプレイヤキャラクタまたはノンプレイヤキャラクタと１対１にて格闘試合を行う。すなわち、本実施形態では、対戦型アクションゲームが格闘ゲームである場合を例示する。

１回のゲームプレイ（１試合）は、複数回の対戦で構成され、先に３勝したキャラクタが決定した時点で終了する。各対戦では、いずれかのキャラクタの体力値がゼロとなった時点で、体力値がゼロとなった方のキャラクタが「負け」、体力値がゼロになっていない方のキャラクタが「勝ち」となる。従って、１試合の結果では、勝ったキャラクタを操作したプレイヤが「勝者」、負けたキャラクタを操作したプレイヤが「敗者」となる。

ギャラリーがゲームプレイへのベットに用いる「遊戯媒体」とは、格闘ゲーム内で使用できる仮想的なゲーム内通貨、メダルなどの非有価証券、紙幣などの現金貨幣、トークンなどの私製貨幣を含む仮想通貨、電子マネーなどが挙げられる。本実施形態では、遊戯媒体がゲーム内通貨である場合を例示する。

なお、遊戯媒体は、様々なゲームで共通して使用できるものであってもよい。そのため、遊戯媒体の使用は、本システム１内に限らず、他のゲームシステムにおいても共通して使用できてもよい。また、遊戯媒体は、本システム１内において、ベット以外にも利用できる。例えば、ギャラリーがプレイヤとなってゲームをプレイするにあたり、新たな技をプレイヤキャラクタが放てるようにするために遊戯媒体を使用したり、プレイヤキャラクタのパラメータを一時的に上昇させて試合を有利に運ぶために遊戯媒体を使用したりすることができる。また、ギャラリーは、遊戯媒体を使って、複数のゲームプレイにベットすることもできる。

ビルダーが作成する「ゲーム媒体」としては、プレイヤの操作に従ってゲーム空間内で動作をする「プレイヤキャラクタ」、プレイヤキャラクタの対戦相手がノンプレイヤキャラクタである場合には「ノンプレイヤキャラクタ」、これらのキャラクタが装備する武器、防具、コスチューム、試合のリングや乗り物のようなゲームプレイにて登場するオブジェクト、などが挙げられる。

本実施形態では、ビルダーは、ベット対象のゲームプレイで使用される可能性のある「プレイヤキャラクタ」や「ノンプレイヤキャラクタ」を、ゲーム媒体として作成（具体的には一から作成および／または育成）する。ビルダーは、自身が作成したキャラクタが試合で使用されている様子を見ることで、自身がゲームに介入していると実感することができ、ゲームへの関心がより深まる。

そして、ゲームプレイにベットしたギャラリーには、そのプレイの勝敗に応じて配当が付与される。配当は、ゲームプレイに対応する配当倍率に応じた分の遊戯媒体にて、ギャラリーに付与される。

ゲームプレイの勝敗は、プレイヤのゲームテクニックだけでなく、ビルダーが作成したキャラクタや、ギャラリーによるベット状況を受けてプレイヤにのしかかる心理的圧迫、などによって左右される場合もある。従って、プレイヤ、ギャラリーおよびビルダーを含むゲームへの参加者それぞれの行動が、ゲームを盛り上げるきっかけともなり得る。

特に、本実施形態の配当倍率は、ゲームプレイを行うプレイヤの人気度に基づいて決定される。プレイヤの人気度は、これまでの様々なゲーム大会を含んだ数々のゲームプレイの勝敗や、ゲームプレイの視聴者に対して好印象を与えるようなプレイスタイル、ゲームに関するか否かに関係なくプレイヤがこれまで発してきた発言および行動、プレイヤの容姿など、様々な要因に応じて上下する。従って、プレイヤの人気度は、時間の経過と共に変動する可能性がある。このプレイヤの人気度が配当倍率に作用することにより、ギャラリーによっては、例えばプレイヤがどのような人物かを日ごろから観察するなどの、プレイヤへの興味を持つきっかけにもなり得る。この興味は、更に、今後のゲームプレイへのベット操作を促進することにもつながり、ゲームの活気が更に増すことに期待できる。

なお、配当倍率は、人気度に基づいて一旦決定されるが、例えば実際のベットの偏りなどを軽減させるために、実際のベット状況によって調整される場合がある。この実際のベット状況（実施にベットされた数など）が、人気度そのものを意味するものではない。

このようなシステム１は、コンピュータゲームが競技として催されるｅスポーツ（Electronics Sports）大会にて利用されることができる。これにより、ｅスポーツのプレイヤとしてのみならず、ギャラリーやビルダーなどの他の立場としての参加も促進される。

＜配当分配システム１の構成＞
図２に示すように、配当分配システム１は、１台のサーバ装置２、複数台のゲーム端末４、複数台のベット端末６、および複数台のビルダー端末８を備える。サーバ装置２および各端末４，６，８は、インターネットおよびＬＡＮなどの通信ネットワークＮＷを介して互いに通信可能に接続されている。

サーバ装置２は、本システム１の運営者側によって管理されている装置であって、各端末４，６，８の統括管理および制御を行う。サーバ装置２は、ゲームプログラムおよびゲームデータを記憶しており、ゲームプログラムの提供、ゲーム端末４の（下記のアカウント情報毎の）ゲームデータの管理を行う。また、サーバ装置２は、対戦のマッチング、ベット状況の把握、配当倍率の管理、プレイヤやビルダーへの報酬付与、ギャラリーへの配当付与などを行う。

なお、プレイヤやビルダーへの報酬付与、ギャラリーへの配当付与とは、各個人を特定するための識別情報に、報酬や配当を関連付ける関連付け処理を行うことで、その個人に報酬や配当が付与されることを意味する。

ゲーム端末４は、プレイヤが使用する端末である。ゲーム端末４は、プレイステーション（登録商標）などの家庭用ゲーム機、ニンテンドースイッチ（登録商標）などの携帯用ゲーム機、もしくは、パーソナルコンピュータ、スマートフォン、タブレットなどの電子機器などである。ゲーム端末４は、ゲームセンターやｅスポーツ施設などのアミューズメント施設に設置されることができる。ゲーム端末４は、通信ネットワークＮＷを介して、サーバ装置２からゲームプログラムおよびゲームデータを受信する。また、ゲーム端末４は、マッチング結果の表示、ゲームプレイについてのプレイヤによる操作の受け付け、プレイヤに付与された報酬の表示などを行う。

ベット端末６は、ギャラリーが使用する端末である。ベット端末６は、スマートフォン、タブレット、パーソナルコンピュータなどの電子機器である。ベット端末６は、ゲームセンター、カジノ、ｅスポーツ施設などのアミューズメント施設の他、自宅に設置されることができる。ベット端末６は、配当倍率の表示、ギャラリーによるベット操作の受け付け、ギャラリーに付与された配当の表示などを行う。

ビルダー端末８は、ビルダーが使用する端末である。ビルダー端末８は、スマートフォン、タブレット、パーソナルコンピュータなどの電子機器である。ビルダー端末８は、ベット端末６と同様、ゲームセンター、カジノ、ｅスポーツ施設などのアミューズメント施設の他、自宅に設置されることができる。ビルダー端末８は、ゲーム媒体の作成操作の受け付け、ビルダーに付与された報酬の表示などを行う。

ゲーム端末４、ベット端末６、ビルダー端末８それぞれは、互いに異なる場所に設置されることができる。例えば、プレイヤは、ｅスポーツ施設のゲーム端末４を介してゲームプレイを行い、そのプレイの配当に応じた報酬を得ることができる。一方、ギャラリーは、カジノのベット端末６を介してベットすることができる。このように、「ゲーム施設」「カジノ」という、一見すると何ら関係のない別々の施設で行われる遊興が、相互に関連し、その結果、お互いの活動を活性化させることができる。

ギャラリー、ビルダー、プレイヤとしてゲームに参加するユーザそれぞれには、自身の操作する端末４，６，８それぞれに対応づけて、識別情報およびパスワードを含むアカウント情報が予め割り当てられている。このアカウント情報は、ログイン時、各端末４，６，８からサーバ装置２に送信され、サーバ装置２におけるユーザ認証に利用される。

ユーザ認証の後、ユーザ認証がなされた端末４，６，８とサーバ装置２との相互通信が可能となる。ログイン後、各端末４，６，８は、上述した各種処理を行うのに必要なデータをサーバ装置２から受信すると、ユーザの操作に基づいて各種画面および音声をディスプレイおよびスピーカに適宜出力していく。これにより、各端末４，６，８は、それぞれの端末４，６，８が有する役割に応じた処理を行うことができる。

＜ハードウェア構成＞
以下、図３～図９を参照して、サーバ装置２、ゲーム端末４、ベット端末６、およびビルダー端末８の各ハードウェア構成について説明する。

＜サーバ装置２＞
図３に示すように、サーバ装置２は、ネットワークインターフェース２１、記憶部２２および制御部２３を有する。ネットワークインターフェース２１および記憶部２２は、バス２９を介して制御部２３と電気的に接続されている。

ネットワークインターフェース２１は、通信ネットワークＮＷを介して各端末４，６，８と通信可能に接続されている。

記憶部２２は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）およびＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などで構成される。記憶部２２には、各種プログラムの他、ユーザＤＢ２２ａ、配当倍率に関するデータなどが記憶されている。

図４に示すように、ユーザＤＢ２２ａには、ゲームに参加するユーザの名称、識別番号、ゲーム内通貨の所持量、ゲームプレイのこれまでの勝敗結果、人気度、これまでのゲームプレイにて使用したキャラクタに関する情報、これまでのベットの勝敗結果、作成したキャラクタに関する情報、フレンド登録されているユーザ名、支援者登録されているユーザ名、などが１レコードとして記憶されている。

ゲーム内通貨の所持量は、ユーザが使用できるゲーム内通貨の量を示す情報である。ゲーム内通貨の所持量は、プレイヤとしてゲームプレイを行った場合には当該プレイに対する報酬、ギャラリーとしてゲームプレイにベットした場合には当該ベットに対する配当、ビルダーとしてキャラクタの作成を行いそのキャラクタがゲームプレイにて使用された場合には当該使用されたことに対する報酬、支援者（パトロン）として他ユーザに投資するなどの支援を行った場合には当該支援に対する報酬、などによって増加する。逆に、ゲーム内通貨の所持量は、プレイヤとしてゲームプレイにエントリーした場合にはエントリー料の分、ギャラリーとしてベットした場合には当該ベットした分、支援者（パトロン）として他ユーザに出資などの支援を行った場合は出資分が減算される。従って、ゲーム内通貨の所持量は、ユーザがゲームに参加することによって経時的に変化する。

ゲームプレイのこれまでの勝敗結果、人気度、使用したキャラクタに関する情報は、該当レコードのユーザがプレイヤとして参加した場合に関係する情報である。勝敗結果は、総プレイ数のうちの、勝った総数および負けた総数を含む。プレイヤとしてゲームプレイを行うと、当該ユーザの総プレイ数がインクリメントされるとともに、勝った総数または負けた総数がインクリメントされる。人気度は、既に説明したように、該当ユーザが、現時点にてどの程度注目され他人からどの程度好印象を持たれているかを、数値で表した情報である。勝敗結果および人気度は、配当倍率の決定に際し利用される。

使用したキャラクタに関する情報には、キャラクタ名、キャラクタのレベルや繰り出すことのできる技名などのパラメータ、個々のキャラクタの使用回数などが含まれる。これまでに使用したことのあるキャラクタが複数の場合、使用したキャラクタに関する情報には、各キャラクタについての情報が含まれる。また、同じキャラクタを複数回使用した際、キャラクタのパラメータが使用の都度異なる場合もある。使用前後において、ビルダーがキャラクタを育成（改良）することがあるからである。その場合、使用したキャラクタに関する情報は、使用した都度のパラメータが、履歴として含まれる。

これまでのベットの勝敗結果は、該当レコードのユーザがギャラリーとして参加した場合に関連する情報である。当該勝敗結果は、これまでの総ベット回数と、勝った回数および負けた回数を含む。該当ユーザがギャラリーとしてベットを行うと、総ベット数がインクリメントされ、勝った回数または負けた回数がインクリメントされる。

作成したキャラクタに関する情報は、該当レコードのユーザがビルダーとして参加した場合に関連する情報である。作成したキャラクタに関する情報には、キャラクタ名、レベルや技名などのパラメータ、作成日時、パラメータを更新した日時（育成日時）、などが含まれる。該当レコードのユーザがビルダーとしてこれまでに作成した（育成途中のものを含む）キャラクタが複数ある場合、作成したキャラクタに関する情報には、個々のキャラクタについての情報が含まれる。同じキャラクタを複数回にわけて段階的に育成した場合、育成した都度のパラメータと更新日時とが、履歴として含まれる。

フレンド登録されているユーザ名は、該当レコードのユーザとフレンド関係にある他ユーザを識別するための情報である。例えば、プレイヤとして参加するユーザがいる一方で、ビルダーとして参加した他ユーザがいるとする。プレイヤがビルダーにフレンド登録申請を行った場合、その申請に応じて、プレイヤのレコード上に、ビルダーであるユーザ名などが書き込まれる。これにより、プレイヤの識別情報にビルダーの識別情報が対応づけられる。

支援者登録されているユーザ名は、該当レコードのユーザを支援者（パトロン）として支援する関係にある他ユーザを識別するための情報である。例えば、ギャラリーとして参加するユーザがいる一方で、ビルダーとして参加した他ユーザがいるとする。ギャラリーがビルダーを支援する支援申請を行った場合、その申請に応じて、ギャラリーのレコード上に、ビルダーであるユーザ名などが書き込まれる。これにより、ギャラリーの識別情報にビルダーの識別情報が対応づけられる。

「支援」には、ゲーム内通貨を用いた出資、投資、融資、寄付、賛助などが挙げられる。ユーザを支援するということは、支援される側のユーザに力添えを行って更なる活躍に期待すること、と言える。この支援行動に対する恩恵が、支援する側のユーザには付与されることがある。

なお、図４では、ユーザ名「Ｕ０１」は、プレイヤとしてのみゲームに参加し、ユーザ名「Ｕ０２」は、プレイヤに加えギャラリーとしてもゲームに参加していることが分かる。ユーザ名「Ｕ０３」は、ギャラリーまたはビルダーとしてゲームに参加し、ユーザ名「Ｕ０４」はビルダーとしてのみゲームに参加していることが分かる。

このように、個々のユーザは、プレイヤ、ギャラリーまたはビルダーのうちの１つの役割に限定されるのではなく、いずれかの役割を自由なタイミングで選択して、ゲームに参加することができる。従って、時にはプレイヤ、また時にはギャラリーのように、役割を変えることは自由にできる。但し、以下では、説明の便宜上、各端末４，６，８は役割ごとに異なる端末が用いられるものとして説明する。

制御部２３は、ＣＰＵおよび半導体メモリを含むマイクロコンピュータで構成され、自装置２の動作を制御する。

再び図３に戻る。制御部２３は、各種プログラムを実行することにより、通信制御手段２３１、照合手段２３２、ＤＢ管理手段２３３、マッチング手段２３４、ベット管理手段２３５、人気度算出手段２３６、配当倍率決定手段２３７、配当付与手段２３８、報酬付与手段２３９、として機能する。

―通信制御手段―
通信制御手段２３１は、ネットワークインターフェース２１を介した他端末４，６，８とのデータの送受信を制御する。

ゲーム端末４からの主な受信データとしては、ゲームプログラムおよび／またはゲームデータのダウンロード要求、マッチング要求、アカウント情報、ゲームプレイ結果、ゲームプレイにて使用されたキャラクタの情報、フレンド登録申請、などが挙げられる。ゲーム端末４への主な送信データとしては、ゲームプログラムおよび／またはゲームデータ、マッチング結果、後述するプレイ報酬付与の連絡、予定されているゲームプレイの内容と最新のベット状況などを含むゲームプレイに関する情報、ビルダーが作成したキャラクタに関する情報、フレンドに関する情報、支援者に関する情報（支援者名、出資額）、などが挙げられる。

ベット端末６からの主な受信データとしては、アカウント情報、ベット操作に関する情報、支援申請、などが挙げられる。ベット端末６への主な送信データとしては、予定されているゲームプレイに関する情報、プレイ終了後の勝敗と配当に関する連絡、支援対象についての情報などが挙げられる。予定されているゲームプレイに関する情報には、プレイヤの名称、使用予定のキャラクタ、配当倍率、最新のベット状況などが含まれる。配当に関する連絡には、配当の有無、配当ありの場合にはゲーム内通貨の配当量、などが含まれる。支援対象についての情報には、支援対象者であるプレイヤ名やビルダー名、支援対象者のプロフィール情報、などが含まれる。

ビルダー端末８からの主な受信データとしては、アカウント情報、作成されたキャラクタについての情報（容姿、パラメータ）、フレンド登録申請、などが挙げられる。ビルダー端末８への主な送信データとしては、予定されているゲームプレイに関する情報、作成されたキャラクタがゲームプレイにて使用された場合にはその旨の連絡、キャラクタが利用されたことに対する報酬、フレンドに関する情報、支援者に関する情報（支援者名、出資額）、などが挙げられる。

－照合手段―
照合手段２３２は、各端末４，６，８から受信したアカウント情報を用いて、ユーザアカウントの認証を行う。認証結果は、通信制御手段２３１によって、アカウント情報を送信してきた端末４，６，８に向けて、ネットワークインターフェース２１を介して送信される。

―ＤＢ管理手段―
ＤＢ管理手段２３３は、各端末４，６，８から受信した各種データに基づいて、ユーザＤＢ２２ａを更新する。例えば、ＤＢ管理手段２３３は、ゲームプレイ結果やプレイヤの人気度、作成されたキャラクタについての情報に基づいて、ユーザＤＢ２２ａの該当レコードを更新する。ゲームプレイに対してベットが行われた場合、ＤＢ管理手段２３３は、該当レコードに対して、ベットされた分および配当分に応じてゲーム内通過の所持量を更新し、ベットの結果に応じてこれまでのベット勝敗も更新する。

また、ＤＢ管理手段２３３は、フレンド登録部として機能する。ＤＢ管理手段２３３は、フレンド登録申請に基づいて、フレンドの対象となるユーザ名などを該当レコードに書き込む。この書き込み処理により、フレンド対象者となるビルダーの識別情報（ビルダー名など）とプレイヤの識別情報（プレイヤ名など）とが互いに対応付けられることとなり、そのビルダーとプレイヤのフレンド同士が、フレンドとして登録される。

また、ＤＢ管理手段２３３は、支援者登録部として機能する。ＤＢ管理手段２３３は、支援申請に基づいて、支援対象となるユーザ名などを該当レコードに書き込む。この書き込み処理により、該当するギャラリーの識別情報（ギャラリー名など）と、該当するプレイヤの識別情報（プレイヤ名など）およびビルダーの識別情報（ビルダー名など）の少なくとも１つとが関連付けられることとなり、ギャラリーが、プレイヤおよびビルダーの少なくとも一方を支援する支援者として登録される。

更に、ＤＢ管理手段２３３は、支援者が支援を行った場合に、「いつ」「誰に」「どのような」支援を行ったのかを少なくとも１つを含む支援情報を、支援される側であるプレイヤおよびビルダーごとに管理する。また、ＤＢ管理部２３３は、この支援情報を、支援する側であるビルダーに関連付けて管理してもよい。

なお、一のプレイヤやビルダーに対し、支援者が複数人存在することもできる。この場合、ＤＢ管理部２３３は、各支援者が支援を行うごとに、支援情報をユーザＤＢ２２ａに追加することができる。

―マッチング手段―
マッチング手段２３４は、ゲーム端末４からのマッチング要求に基づいて、対戦相手を設定するマッチング処理を行う。対戦相手の設定方法としては、所定時間内にマッチング要求を送信してきた送信先同士を対戦者として設定したり、マッチング要求の送信先ユーザがこれまでに対戦したことのないユーザを選択して対戦者として設定したり、ユーザＤＢ２２ａの中から任意のユーザを抽選で選択して設定したりすること、などが挙げられる。

マッチングにより対戦相手が設定された場合、対戦相手には、対戦相手に選ばれたこと、マッチング要求の送信先ユーザが誰か、その送信先ユーザのこれまでのゲームプレイ勝敗、ゲームプレイを行う日時などが送信される。対戦相手に、対戦を承諾するか否かを打診するためである。その対戦相手が対戦を承諾した場合、マッチング要求の送信先ユーザに、対戦相手は誰かや、当該対戦相手のこれまでのゲームプレイ勝敗、ゲームプレイを行う日時などが、送信される。

対戦相手が対戦を承諾しなかった場合、その旨がサーバ装置２に送られてくるため、マッチング手段２３４は再度マッチング処理をし直す。つまり、ゲームプレイは、マッチング要求の送信先ユーザと対戦を承諾した相手との間で行われる。相手が対戦を望まないのにゲームプレイが行われてしまうと、ゲームプレイの盛り上がりは欠けてしまい、プレイヤの人気に影響が生じ、結果としてギャラリーによるベットにも影響が及ぶ虞があるためである。

―ベット管理手段―
ベット管理手段２３５は、個々のギャラリーによるベット管理、ゲームプレイごとのベット情報の集計、などを行う。

ベット管理については、ベット管理手段２３５は、ベット端末６からのベット操作に関する情報に基づいて、ベット操作を行ったギャラリー名、ベットされたゲームプレイとプレイヤ、そのベットにて賭けられたゲーム内通貨の量、を特定する。ベット操作に関する情報には、ベット操作を行ったギャラリーのユーザＩＤ、ベット対象となったゲームプレイを識別する情報、どのプレイヤにベットしたかの情報、ゲーム内通貨の量を表す情報、が含まれているため、ベット管理手段２３５は、上記の特定処理が可能となる。特定された各種情報を基に、ＤＢ管理手段２３３は、ユーザＤＢ２２ａ内のゲーム内通過の所持量を更新することができる。

ベット情報の集計については、ベット管理手段２３５は、個々のゲームプレイごとに、ベット操作を行ったギャラリーの人数、プレイヤごとのベット数、ゲームプレイごとのベット総量、プレイヤごとのベット総量、を算出する。この算出結果のうち少なくとも１つが、ベット操作に応じたベット状況として、配当量の決定、プレイヤへの報酬決定、プレイヤの人気度算出、ビルダーへの報酬決定、ビルダーの人気度算出、などに利用される。なお、ベット情報の集計については、直近の各種情報が集計対象となってもよいし、過去における一定期間内の各種情報が集計対象となってもよい。

また、ベット管理手段２３５は、ベット対象決定部に相当する。ベット管理手段２３５は、今後対戦が予定されているゲームプレイを、ベット対象候補として抽出する。特に、ベット管理手段２３５は、支援者による支援対象すなわち支援される側（支援対象者）であるプレイヤおよびビルダーが関与しているゲームプレイについては、そのプレイヤおよびビルダーの“支援者”に登録されているユーザをギャラリーと見立てて賭けの対象とするため、当該支援者によるベット対象候補に決定する。これにより、支援中のプレイヤが対戦者となる試合や、支援中のビルダーが作成したキャラクタが使用される予定の試合に対し、支援者は積極的に賭けを行うことができる。従って、支援者は、賭けを通じて、支援中のプレイヤやビルダーを更に応援することができる。

なお、このベット対象候補の抽出処理は、例えばリアルタイムごとに行われる。抽出される都度、ベット対象候補は、通信制御手段２３１によって、該当する支援者のベット端末６に送信される。ベット端末６側ではベット対象候補が報知され、支援者は、そのベット対象候補の中から、ベットするべき所定ゲームプレイを選択してベット操作を行うことができる。

―人気度算出手段―
人気度算出手段２３６は、プレイヤおよびビルダーそれぞれの人気度を算出する。既に述べたように、人気度は、これまでのゲームプレイの勝敗や、プレイヤやビルダー個人がこれまでに発した発言や行動などにより左右される。そのため、人気度の算出は、一日単位のように、所定期間が経過するごとに行われる。

プレイヤの人気度算出に用いられるパラメータとしては、そのプレイヤについてのゲームプレイ結果、そのプレイヤに対してこれまでにベットされたベット状況、プレイヤを支援する支援者の数、プレイヤが支援を受けた支援数、の少なくとも１つが挙げられる。つまり、現在のベット数そのものが現在の「人気度」と算出されるのではなく、人気度は、プレイヤのこれまでの行動などが反映された当該プレイヤの軌跡、によって算出（設定）された情報、といえる。

プレイヤについてのゲームプレイ結果には、プレイ回数、ゲームプレイで勝った総数、これまでに盛り上がる試合を繰り広げた回数、などが含まれる。プレイ回数が多かったり、勝った回数が多かったりするほど、人気が上昇し易いためである。勝敗にかかわらず、ゲームプレイをリアルタイムで観戦した人（ビジター）の歓声の音量が大きかったり、ゲームプレイの動画を視聴した人が「いいね」を押した回数が多かったりするほど、そのゲームプレイが盛り上がったことを意味し、人気が上昇し易い傾向にある。

これまでのベット状況には、該当するプレイヤにギャラリーが賭けた総回数、そのプレイヤにこれまでにベットされたゲーム内通貨の総量、が含まれる。この総回数やベットされたゲーム内通貨の総量が多いほどそのプレイヤの人気は高い、と言うことができる。

プレイヤを支援する支援者の数は、ユーザＤＢ２２ａの「支援者」に登録されている人数、すなわち現時点での支援者の数であることが好ましい。現時点の支援者の数は、現時点でのプレイヤの人気を最も反映している指標と言えるためである。また、プレイヤを支援する支援者の数には、現時点での支援者の数ではなく、現時点での支援者および過去の支援者を含んだこれまでの支援者の総数であってもよい。

プレイヤが支援を受けた支援数には、一の支援者がプレイヤに出資した場合を１とカウントした場合のこれまでの出資総回数、支援者の人数に関係なくこれまでに出資された額の合計値、などが含まれる。支援数が多いほど、そのプレイヤについての関心が高いと推測できる。

また、プレイヤの人気度算出には、本システム１とは別途、プレイヤの活躍の様子を記したコンテンツ上から、他ユーザが「いいね」を押した合計値がパラメータとして用いられることもできる。他ユーザとは、他のプレイヤ、ビルダー、ギャラリー、運営者といった、ゲームプレイの関係者の他、ゲームプレイを観戦のみする人などが挙げられる。この場合、人気度は、プレイヤ以外の他ユーザの入力操作に基づく指標よって設定された情報、ということができる。

ビルダーの人気度算出に用いられるパラメータとしては、ビルダーが作成したキャラクタを使用して行われたゲームプレイ（以下、所定プレイ）の結果、所定プレイにおいてキャラクタを使用したプレイヤへのベット状況、ビルダーを支援する支援者の数、ビルダーが支援を受けた支援数、の少なくとも１つが挙げられる。

ゲームプレイ（所定プレイ）の結果には、これまでの所定プレイの回数、所定プレイにおいてビルダーが作成したキャラクタを使用してプレイヤが勝った回数、当該プレイヤが盛り上がる試合を繰り広げた所定プレイの回数、などが含まれる。所定プレイの回数が多かったり、ビルダーが作成したキャラクタを用いての勝利回数が多かったりするほど、そのキャラクタへの注目が増し、更にはそのキャラクタを作成したビルダー自身への人気が上昇し易いためである。所定プレイをリアルタイムで観戦した人の歓声の音量が大きかったり、所定プレイの動画を視聴した人が「いいね」を押した回数が多かったりするほど、その所定プレイが盛り上がったことを意味し、結果として使用されたキャラクタの作成者（ビルダー）への人気が上昇し易い傾向にある。

キャラクタを使用したプレイヤへのベット状況には、所定プレイにおいて当該プレイヤにベットされた総回数、所定プレイにおいて当該プレイヤにベットされたゲーム内通貨の総量、が含まれる。ベットされた総回数やゲーム内通貨の総量が多いほど、そのプレイヤへの注目が増し、更にはそのプレイヤが使用するキャラクタのビルダーへの人気が上昇し易くなる。

ビルダーを支援する支援者の数は、ユーザＤＢ２２ａの「支援者」に登録されている人数、すなわち現時点での支援者の数であることが好ましい。現時点の支援者の数は、現時点でのビルダーの人気を最も反映している指標と言えるためである。また、ビルダーを支援する支援者の総数には、現時点での支援者の数ではなく、現時点での支援者および過去の支援者を含んだこれまでの支援者の総数であってもよい。

ビルダーが支援を受けた支援数には、一の支援者がビルダーに出資した場合を１とカウントした場合のこれまでの出資総回数、支援者の人数に関係なくこれまでに出資された額の合計値、などが含まれる。支援総数が多いほど、そのビルダーについての関心が高いと推測できる。

また、ビルダーの人気度算出には、本システム１とは別途、ビルダーの活躍の様子を記したコンテンツ上から、他ユーザが「いいね」を押した合計値がパラメータとして用いられることもできる。他ユーザとは、プレイヤ、他のビルダー、ギャラリー、運営者といった、ゲームプレイの関係者の他、ゲームプレイを観戦のみする人などが挙げられる。この場合、人気度は、ビルダー以外の他ユーザの入力操作に基づく指標よって設定された情報、ということができる。

―配当倍率決定手段―
配当倍率決定手段２３７は、ゲームプレイが実行される前に、ゲームプレイに対応する配当倍率を決定する。特に、配当倍率決定手段２３７は、ゲームプレイにて対戦予定のプレイヤの人気度に基づいて、配当倍率を決定する。プレイヤの人気度は、上述した人気度算出手段２３６によって算出されたものである。

具体的に、配当倍率決定手段２３７は、プレイヤの人気度が高いほど、配当倍率を低くするように算出する。人気度が高いプレイヤについては、多くのギャラリーがベットすることが想定されるからである。

一般的に、配当倍率は、ゲームプレイの運営者側の都合で、運営者側が損しないように、または、運営者側が有利となるように決定される。これに対し、本実施形態では、人気度に応じて配当倍率が決定するため、ギャラリーは、「ゲームプレイが盛り上がるのではないか」「面白いプレイが見られるのではないか」のように、ゲームプレイに期待してベットすることができる。

しかし、人気度に基づいて決定された配当倍率を参照してベットが行われた結果、ベット総数が一方のプレイヤ側に偏ったり、実際のベット総数が伸び悩んだりする場合もある。その場合、配当倍率決定手段２３７は、ベット期間が半分ほど過ぎたなどの所定タイミングにて、実際のベット状況（各プレイヤへのベット数など）に基づいて、配当倍率を調整（決定）することができる。

例えば、一方のプレイヤ側へのベット数と他方へのベット数との差が所定差以上となった場合、配当倍率決定手段２３７は、一方のプレイヤ側の配当倍率を、それまでよりも下げるように調整する。配当倍率が下げられる分、以降にベット操作を行ったギャラリーへの配当は、それまでにベット操作を行ったギャラリーへの配当よりも低くなるため、ベットを検討しているギャラリーは、配当も考慮しながらどちらのプレイヤにベットするかを決めることができる。また、１つのゲームプレイにおけるベット総数（双方のプレイヤそれぞれへのベット数を足した値）が所定値以下の場合、配当倍率決定手段２３７は、双方のプレイヤへの以降の配当倍率を、それまでよりも上昇させる調整を行ってもよい。

また、人気度に応じて決定された配当倍率は、人気度および／または実際のベット状況によって調整されてもよいし、運営者側が損しないような配当となるように調整されてもよい。

このように、配当倍率が実際のベット状況に応じて変化することにより、ギャラリーには、ベット操作をいつ行うかなどを、戦略的に考える楽しみが生まれる。

―配当付与手段―
配当付与手段２３８は、ゲームプレイが終了した後、ギャラリーに付与する配当の額を決定し、配当を付与する処理を行う。この処理では、配当付与手段２３８は、どのプレイヤが勝利したかを表すゲームプレイの結果と、勝利したプレイヤに対応する配当倍率とに基づいて、個々のベット操作に対する配当を決定する。その際、勝利したプレイヤ側にベットされたゲーム内通貨の量も用いて、配当が決定されることが好ましい。例えば、配当額は、個々のギャラリーがベットしたゲーム内通貨の量に、勝利したプレイヤ側の配当倍率を乗算することで決定される。

配当付与手段２３８は、決定された配当を、その配当を付与するべきギャラリーのユーザＩＤに関連付けることで、その配当をギャラリーに付与する。

―報酬付与手段―
報酬付与手段２３９は、ゲームプレイに関するプレイ報酬を、プレイヤおよびビルダーの少なくとも1人に付与する処理を行う。プレイ報酬とは、実際に行われたゲームプレイに関与したことに対する報酬であって、ゲームプレイを実際に行ったことに対するプレイヤへの報酬、ゲームプレイにてプレイヤが使用したキャラクタを作成したことに対するビルダーへの報酬、が挙げられる。

プレイ報酬は、報酬のきっかけとなったゲームプレイの結果、そのゲームプレイにおけるベット操作に応じたベット状況、プレイヤの人気度、ビルダーの人気度、の少なくとも１つに基づいて決定される。

ゲームプレイの結果には、どちらのプレイヤが何のキャラクタを使って勝ったか（負けたか）、が含まれる。勝ったプレイヤには負けたプレイヤによりも多くの報酬が付与されるように、報酬付与手段２３９は、各プレイヤへの報酬を決定する。勝ったプレイヤが使用していたキャラクタの作成者（ビルダー）には、負けたプレイヤが使用していたキャラクタの作成者（ビルダー）よりも多くの報酬が付与されるように、報酬付与手段２３９は、各ビルダーへの報酬を決定する。

ここでのベット状況には、行われたゲームプレイにおけるベット総数、当該ゲームプレイにベットされたゲーム内通貨の総量、各プレイヤに対するベット総数、各プレイヤにベットされたゲーム内通貨の総量、の少なくとも１つが含まれる。ベット状況に基づいて、報酬付与手段２３９は、例えばベット数や額が多いプレイヤおよびそのプレイヤが使用したキャラクタのビルダーに、より多くの報酬が付与されるように、各プレイヤおよび各ビルダーへの報酬を決定（調整）する。

このように、本実施形態では、ベット対象として「プレイヤ」「ビルダー」が存在する。そのため、賭けが複雑化し、全体としての興趣性が増す。

プレイヤおよびビルダーそれぞれの人気度としては、人気度算出手段２３６が算出した結果が利用される。人気度に応じて、人気度の高い側のプレイヤおよびビルダーに多くの報酬が付与されるように、報酬付与手段２３９は、各プレイヤおよび各ビルダーへの報酬を決定（調整）する。

なお、このプレイ報酬は、更に、支援者による支援状況に基づいて調整される。支援状況には、プレイ報酬の付与対象者であるプレイヤおよびビルダーが所定期間の間にどの程度支援を受けたか（出資額）や、支援者の人数など、が含まれる。報酬付与手段２３９は、一旦決定したプレイ報酬に、支援状況に応じた分の報酬額を上乗せし、上乗せ後の報酬額を、該当するプレイヤおよびビルダーへの実際のプレイ報酬として決定することができる。

なお、報酬付与手段２３９は、決定したプレイ報酬を、そのプレイ報酬を付与するべきプレイヤおよびビルダーそれぞれのユーザＩＤに関連付けることで、そのプレイ報酬をプレイヤおよびビルダーに付与する。プレイ報酬が付与されると、ＤＢ管理手段２３３によって、ユーザＤＢ２２ａが更新される。

また、報酬付与手段２３９は、プレイヤやビルダーの支援者に対し、支援報酬を付与する。支援報酬を決定するにあたり、報酬付与手段２３９は、分類部に相当する。報酬付与手段２３９は、既に述べた支援情報に応じて、複数の支援者の識別情報それぞれをランク分けする。報酬付与手段２３９は、この分類結果と、支援対象となるプレイヤおよびビルダーそれぞれの活躍に応じた評価値と、に応じて、個々の支援者に対する支援報酬を決定する。

具体的に、これまでに行った支援回数に応じて、複数のランクが予め定められる。例えば、支援回数が０回～１０回の場合は「ランクＡ」、支援回数が１１回～２０回の場合は「ランクＢ」、支援回数が２１回以上の場合は「ランクＣ」と、支援回数に応じて段階的に複数のランクＡ～Ｃが決められているとする。報酬付与手段２３９は、例えば１か月が経過するごとに、各支援者の直近１か月間の支援回数を算出し、その支援回数から、当該支援者がどのランクＡ～Ｃに当てはまるかを判定する。判定されたランクは、ＤＢ管理手段２３３によってユーザＤＢ２２ａに書き込まれる。

そして、報酬付与手段２３９は、上述した各支援者のランクと、この１か月の間に各支援者から出資を受けたプレイヤおよびビルダーそれぞれの評価値とから、各支援者への支援報酬を決定する。具体的に、支報酬付与手段２３９は、支援者が支援回数の多いランクに該当し、且つ評価値が多いほど、支援報酬が多くなるように決定する。また、予めランクごとに支援報酬のベースが決められていることで、報酬付与手段２３９は、判定したランクに基づいて支援報酬のベースを決定し、最新の評価値に応じた分の支援報酬をベースに上乗せすることで、支援者への支援報酬を決定することができる。

評価値は、プレイヤおよびビルダーが活躍する様子に対し、他ユーザが支持（承認）した数を表した指標であって、例えば、プレイヤやビルダーの活躍する様子を記したコンテンツ上で他ユーザが「いいね」を押した合計値を用いることができる。従って、この評価値を用いて決定される支援者への支援報酬は、その支援者の出資によってプレイヤやビルダーが活躍をしたことに対する、支援者への見返り（恩恵）、と言える。

なお、評価値については、本システム１とは直接的には関係のない一般的なソーシャルネットワーク上の「いいね」の押下回数が用いられてもよい。

報酬付与手段２３９は、決定した支援報酬を、その支援報酬を付与するべき支援者のユーザＩＤに関連付けることで、その支援報酬をギャラリーに付与する。支援報酬が付与されると、ＤＢ管理手段２３３によって、ユーザＤＢ２２ａが更新される。

＜ゲーム端末４の構成＞
図５に示すように、ゲーム端末４には、ディスプレイ５２、スピーカ５３、コントローラ５４およびウェブカメラ５５が外部接続または内蔵される。ゲーム端末４は、ネットワークインターフェース４１、グラフィック処理部４２、オーディオ処理部４３、操作処理部４４、撮像音声処理部４５、記憶部４６および制御部４７を有する。ネットワークインターフェース４１、グラフィック処理部４２、オーディオ処理部４３、操作処理部４４、撮像音声処理部４５および記憶部４６は、バス４９を介して制御部４７と電気的に接続されている。

ネットワークインターフェース４１は、サーバ装置２などとの間で各種データを送受信するために、通信ネットワークＮＷに通信可能に接続される。

グラフィック処理部４２は、制御部４７から出力されるゲーム画像情報に従って、キャラクタおよび仮想ゲーム空間に関する各種オブジェクトを含むゲーム画像を、動画形式で描画する。グラフィック処理部４２は、例えば液晶型であるディスプレイ５２と接続されており、動画形式に描画されたゲーム画像は、ゲーム画面としてディスプレイ５２上に表示される。

オーディオ処理部４３は、スピーカ５３と接続されている。オーディオ処理部４３は、制御部４７の指示に従ってゲーム音声を再生および合成すると、これをスピーカ５３から出力させる。

操作処理部４４は、コントローラ５４と接続されている。プレイヤによるキー入力がコントローラ５４を介してなされると、操作処理部４４は、これを操作入力に関するデータとして受け付ける。

撮像音声処理部４５は、ウェブカメラ５５と接続されている。ウェブカメラ５５は、動画の撮像機能と音声を拾う機能とを備えたものである。撮像音声処理部４５は、ウェブカメラ５５が撮像した動画データに対して画像処理を施し、ウェブカメラ５５が拾った音声に対して音声処理を施す。

記憶部４６は、ＨＤＤ、ＳＳＤ、ＲＡＭおよびＲＯＭなどで構成される。記憶部４６には、サーバ装置２からダウンロードしたゲームデータ、ゲームプログラムを含む各種プログラム、自端末４のアカウント情報などが格納されている。

制御部４７は、ＣＰＵおよび半導体メモリを含むマイクロコンピュータで構成され、自端末４７の動作を制御する。

制御部４７は、各種プログラムを実行することにより、通信制御手段４７１、ゲーム設定手段４７２、ゲーム実行手段４７３、報知制御手段４７４および動画データ生成手段４７５として機能する。

―通信制御手段―
通信制御手段４７１は、ネットワークインターフェース４１を介して、主にサーバ装置２との送受信を制御する。

サーバ装置２からの主な受信データとしては、ゲームプログラムおよび／またはゲームデータ、マッチング結果、プレイ報酬付与の連絡、ベット状況、ビルダーが作成したキャラクタに関する情報、フレンドに関する情報、支援者に関する情報（支援者名、出資額）、などが挙げられる。サーバ装置２への主な送信データとしては、アカウント情報、各種ダウンロード要求情報、マッチング要求、ゲームプレイ結果、ゲームプレイにて使用したキャラクタの情報、フレンド登録申請などが挙げられる。

―ゲーム設定手段―
ゲーム設定手段４７２は、プレイヤによるコントローラ５４への操作入力に基づいて、ゲームプレイに関する設定を行う。ゲームプレイに関する設定としては、ゲームプレイにて使用するキャラクタの選択、コントローラ５４のボタンの割り当て設定（キーコンフィグ）、勝敗をどのようにして決めるかのルール設定、などが挙げられる。

キャラクタの選択を行うゲーム設定手段４７２は、媒体選択部に相当する。

キャラクタ選択の際、ゲーム端末４のディスプレイ５２には、選択候補となるキャラクタの一覧が表示される。プレイヤは、その一覧の中から、使用したいキャラクタの選択操作を行うことができ、ゲーム設定手段４７２は、その操作に従ってキャラクタを選択する。キャラクタの一覧には、デフォルトで用意されているキャラクタの他に、これまでにビルダーが作成したキャラクタも含まれている。また、キャラクタの一覧には、キャラクタごとに、キャラクタの容姿、キャラクタ設定などのプロフィール、繰り出すことのできる技、体力値やレベルなどのステータス、作成したビルダー名、これらの情報の最終更新日、などが列挙されている。キャラクタの選択操作の際、プレイヤは、この一覧の情報を参考にすることができる。

また、キャラクタの一覧には、プレイヤのフレンドとして登録されているビルダーが作成したキャラクタ、すなわちビルダーの作成操作対象であるキャラクタが含まれている。このキャラクタは、一覧表示の際、冒頭の方に登場したり、フレンド以外のキャラクタと区別可能な色や印で表示されたりすることが好ましい。これにより、プレイヤは、フレンドの作成したキャラクタを一覧の中から見つけ易くなり、結果として当該キャラクタを選択する機会が増える。

選択されたキャラクタの情報はサーバ装置２に送られ、ユーザＤＢ２２ａの更新に利用される。

―ゲーム実行手段－
ゲーム実行手段４７３は、ゲームプレイ中、自端末４のプレイヤによるコントローラ５４の操作に従って、ゲームデータに含まれる仮想ゲーム空間オブジェクトおよびテクスチャなどのデータを記憶部４６から読み出すかまたはサーバ装置２から受信したデータを用いて、ゲームプログラムを実行しつつ、２次元または３次元のゲーム画像情報を生成する。ゲーム画像情報がグラフィック処理部４２によって処理されることにより、ディスプレイ５２には処理後のゲーム画像が逐次表示される。

そして、ゲーム実行手段４７３は、自端末４のプレイヤの操作およびゲームの進行状況に応じて、仮想ゲーム空間におけるプレイヤキャラクタの行動を制御することにより、対戦を実行させる。例えば、ゲーム実行手段４７３は、プレイヤのコントローラ５４を介した操作入力に応じて、プレイヤキャラクタを移動させたり技を繰り出させたりする。

ゲームプレイが終了した後、そのプレイの結果はサーバ装置２に送られ、ユーザＤＢ２２ａの更新に利用される。

―報知制御手段－
報知制御手段４７４は、ゲームの実行にあたり、自端末４のプレイヤの操作などに応じてディスプレイ５２の表示制御およびスピーカ５３の音声出力制御を行う。報知制御手段４７４は、ゲームプレイの開始前には、キャラクタの一覧などのゲームプレイに関する設定画面を表示させ、ゲームプレイ中にはゲーム画像を表示させる。ゲームプレイが終了した場合、報知制御手段４７４は、プレイ終了の旨および勝敗結果を表す画面を表示させる。

また、報知制御手段４７４は、プレイヤにプレイ報酬が付与された場合、その旨の情報を報知させる。

ー動画データ生成手段―
動画データ生成手段４７５は、ゲームプレイ動画およびウェブカメラ５５によって撮像された映像データを用いて、視聴用の動画データを生成する。例えば、動画データ生成部４７４は、ゲームプレイ動画を大画面として表示させながら、ゲームプレイ中のプレイヤの表情をその大画面に重畳させ前面に表示させるように、ゲームプレイ動画および動画データを編集して、動画データを生成する。この動画データは、プレイヤや観戦者の音声が各場面に応じて出力されるように、音声データを含んだものとなっていてもよい。

動画データ生成手段４７５による動画データの生成処理は、ゲームプレイ中にリアルタイムで行われる。

生成された動画データは、サーバ装置２にて管理されるとともに、リアルタイムやゲームプレイ終了後に、通信ネットワークＮＷにブロードキャストされる。これにより、ギャラリーやビルダーなどの様々なユーザは、いつ何時でもゲームプレイを視聴することができる。

なお、本実施形態では、この動画データに対応付けて、上述した評価値が閲覧可能かつ入力可能となっている。

＜ベット端末６の構成＞
図６に示すように、ベット端末６には、ディスプレイ７２、スピーカ７３およびコントローラ７４が外部接続または内蔵される。ベット端末６は、ネットワークインターフェース６１、画像処理部６２、オーディオ処理部６３、操作処理部６４、記憶部６６および制御部６７を有する。ネットワークインターフェース６１、画像処理部６２、オーディオ処理部６３、操作処理部６４および記憶部６６は、バス６９を介して制御部６７と電気的に接続されている。

ネットワークインターフェース６１は、サーバ装置２などとの間で各種データを送受信するために、通信ネットワークＮＷに通信可能に接続される。

画像処理部６２は、制御部６７から出力される各種画像情報に画像処理を施す。画像処理部６２は、例えば液晶型であるディスプレイ７２と接続されており、画像処理後の画像をディスプレイ７２上に表示させる。

オーディオ処理部６３は、スピーカ７３と接続されている。オーディオ処理部６３は、制御部６７の指示に従って音声をスピーカ７３から出力させる。

操作処理部６４は、コントローラ７４と接続されている。ギャラリーによる様々な操作入力がコントローラ７４を介してなされると、操作処理部６４は、これを操作入力に関するデータとして受け付ける。

図６では図示していないが、ベット端末６には、更に、ギャラリーの音声を拾うマイク、マイクが拾った音声に対して音声処理を施す音声処理部、ギャラリーの様子を撮像するウェブカメラが、外部接続または内蔵されることができる。この場合、ギャラリーがゲームプレイを視聴する様子を撮像したり音声を拾ったりすることができる。

記憶部６６は、ＨＤＤ、ＳＳＤ、ＲＡＭおよびＲＯＭなどで構成される。記憶部６６には、ギャラリーによるベット操作を有効にするためのプログラムやデータ、自端末６のアカウント情報などが格納されている。

制御部６７は、ＣＰＵおよび半導体メモリを含むマイクロコンピュータで構成され、自端末６の動作を制御する。

制御部６７は、各種プログラムを実行することにより、通信制御手段６７１、操作判定手段６７２および報知制御手段６７３として機能する。

―通信制御手段―
通信制御手段６７１は、ネットワークインターフェース６１を介して、主にサーバ装置２との送受信を制御する。

サーバ装置２からの主な受信データとしては、予定されているゲームプレイに関する情報、プレイ終了後の勝敗と配当に関する連絡、支援対象者についての情報（支援対象者の名称）、今後予定されているベット対象候補、などが挙げられる。サーバ装置２への主な送信データとしては、アカウント情報、ベット操作に関する情報、支援申請、などが挙げられる。

－操作判定手段－
操作判定手段６７２は、コントローラ７４を介して行われた操作入力が、どのような内容の操作であるかを判定する。ベット端末６で行われる操作入力としては、ゲームプレイへのベット操作、支援対象者としたいプレイヤやビルダーを選択する操作、選択したプレイヤやビルダーへの支援者としての登録要請操作、実際の支援（出資）のための操作、などが挙げられる。

このように、操作判定手段６７２は、ゲームプレイに対するベット操作を受け付けることができるため、ベット受付部に相当する。

また、支援者として登録されているギャラリーのベット端末６には、支援対象者が関与している開催予定のゲームプレイの一覧が、ベット対象候補の情報として、サーバ装置２から送られてくる。当該ギャラリーは、コントローラ７４を介して、ベットを希望するゲームプレイ（所定ゲームプレイ）の選択と、ベットする操作とを行うことができる。この操作も、ベット端末６で行われる操作入力に含まれる。操作判定手段６７２は、これらの操作が行われた場合には、所定ゲームプレイへのベット操作を受け付けることができる。

－報知制御手段―
報知制御手段６７３は、サーバ装置２から送られてきた各種情報を基に、ゲームプレイへのベット、支援者登録、実際の支援などに関する各種画面を、ディスプレイ７２およびスピーカ７３を介して報知させる。

図７は、ディスプレイ７２に報知される画面の一例である。図７の画面ｓｃ１は、開催予定のゲームプレイに関する情報と、各ゲームプレイへのベットに関する情報とを、対応付けて一覧表示したものである。ゲームプレイに関する情報には、対戦するプレイヤのユーザ名などが含まれる。ベットに関する情報には、各ゲームプレイにおけるプレイヤごとの配当倍率、現在のベット状況（現時点におけるゲームプレイごとのベット数、プレイヤごとのベット数）、が含まれる。このうち、配当倍率は、既に述べたように、プレイヤの人気度に基づいて決定されたものである。

画面ｓｃ１を確認することで、ギャラリーは、どのゲームプレイにベットをするか、ベットするのであればどちらのプレイヤにベットするか、ゲーム内通貨をどの程度ベットするか、などを検討して、ベット操作を行うことができる。また、表示された配当倍率を参考にして、ギャラリーは、各プレイヤの人気度を推測し、今後の支援者としての活動などについても検討することができる。

また、報知制御手段６７３は、ギャラリーがベット操作を行う場合には、その操作に準じた画面を遂次報知させていく。ギャラリーがベット操作を行った後、サーバ装置２にてベット操作が受付られると、報知制御手段６７３は、ベット操作が無事受け付けられた旨の画面を報知させる。

報知制御手段６７３は、ギャラリーの操作に応じて、プレイ中のゲームプレイの映像をリアルタイムで報知させることができる。また、ゲームプレイ終了後、報知制御手段６７３は、ゲームプレイの結果と、そのゲームプレイにて配当が得られ得たか否かと、得られた場合にはその額とを含む画面を報知させる。

また、報知制御手段６７３は、ギャラリーが支援者登録を望む場合には登録画面を、ギャラリーが支援対象者に出資する場合には出資申請画面を、出資に対する報酬が付与された場合にはその旨と報酬の額との表示画面を、それぞれ報知させる。

＜ビルダー端末８の構成＞
図８に示すように、ビルダー端末８には、ディスプレイ９２、スピーカ９３およびタッチパネル９４が外部接続または内蔵される。ビルダー端末８は、ネットワークインターフェース８１、画像処理部８２、オーディオ処理部８３、操作処理部８４、記憶部８６および制御部８７を有する。ネットワークインターフェース８１、画像処理部８２、オーディオ処理部８３、操作処理部８４および記憶部８６は、バス８９を介して制御部８７と電気的に接続されている。

ネットワークインターフェース８１は、サーバ装置２などとの間で各種データを送受信するために、通信ネットワークＮＷに通信可能に接続される。

画像処理部８２は、制御部８７から出力される各種画像情報に画像処理を施す。画像処理部８２は、例えば液晶型であるディスプレイ９２と接続されており、画像処理後の画像をディスプレイ９２上に表示させる。

オーディオ処理部８３は、スピーカ９３と接続されている。オーディオ処理部８３は、制御部８７の指示に従って音声をスピーカ９３から出力させる。

操作処理部８４は、タッチパネル９４と接続されている。ビルダーによる様々な操作入力がタッチパネル９４を介してなされると、操作処理部８４は、これを操作入力に関するデータとして受け付ける。操作入力には、フレンド申請入力、各種情報確認入力などが挙げられる。

特に、ビルダーは、タッチパネル９４を介して、キャラクタを作成するための操作入力を行うことができ、操作処理部８４は、これを操作入力に関するデータとして受け付けることができる。

図８では図示していないが、ビルダー端末８には、更に、ビルダーの音声を拾うマイク、マイクが拾った音声に対して音声処理を施す音声処理部、ビルダーの様子を撮像するウェブカメラが、外部接続または内蔵されることができる。この場合、ビルダーがゲームプレイを視聴する様子や、ビルダーがキャラクタを作成する様子における、映像および音声を拾うことができる。

記憶部８６は、ＨＤＤ、ＳＳＤ、ＲＡＭおよびＲＯＭなどで構成される。記憶部８６には、ビルダーによるキャラクタの作成操作を有効にするためのプログラムやデータ、自端末８のアカウント情報などが格納されている。

制御部８７は、ＣＰＵおよび半導体メモリを含むマイクロコンピュータで構成され、自端末８の動作を制御する。

制御部８７は、各種プログラムを実行することにより、通信制御手段８７１、キャラクタ作成手段８７２および報知制御手段８７３として機能する。

―通信制御手段―
通信制御手段８７１は、ネットワークインターフェース８１を介して、主にサーバ装置２との送受信を制御する。

サーバ装置２からの主な受信データとしては、作成したキャラクタが使用されたこととそれに対する報酬付与の連絡、フレンドに関する情報、支援者に関する情報（支援者名、出資額）、などが挙げられる。サーバ装置２への主な送信データとしては、アカウント情報、作成したキャラクタについての情報（容姿、パラメータなど）、フレンド登録申請、などが挙げられる。また、サーバ装置２への主な送信データには、キャラクタを育成した際にはどのような素材を使用して育成したかの情報（即ち、育成素材についての情報）が更に含まれてもよい。

－キャラクタ作成手段－
キャラクタ作成手段８７２は、媒体作成部に相当する。タッチパネル９４を介してビルダーがキャラクタの作成操作を行った場合、キャラクタ作成手段８７２は、その操作入力に関するデータに基づいて、キャラクタの作成処理を行う。

キャラクタの作成処理には、キャラクタを一から作成する処理、一旦作成されているキャラクタやデフォルトで用意されているキャラクタに対して、体力値や技などのキャラクタのパラメータを強化したり、容姿を変更したりする処理、が含まれる

なお、キャラクタを一から作成する処理には、キャラクタのコンセプトを設定する処理、キャラクタの名称、容姿、ボイス、パラメータ、技、装備パーツ、改良パーツなどを決定する処理、が含まれる。

－報知制御手段－
報知制御手段８７３は、サーバ装置２から送られてきた各種情報を基に、各種画面を、ディスプレイ９２およびスピーカ９３を介して報知させる。

例えば、ビルダーが作成したキャラクタがゲームプレイにて使用された場合、報知制御手段８７３は、その旨の画面を報知したり、使用されたことによる報酬が付与された旨と報酬額とを含む画面を報知させたりする。また、報知制御手段８７３は、プレイヤからのフレンド申請によってビルダーがフレンド登録された場合にはその旨、支援者による出資があった場合にはその旨、をそれぞれ示す画面を報知させる。

ビルダーがキャラクタの作成を行う場合、報知制御手段８７３は、図９に示す画面ｓｃ２をディスプレイ９２に表示させる。図９の画面ｓｃ２は、キャラクタを一から作成したりブラッシュアップしたりする際の編集画面例である。
＜配当分配システム１の動作の流れ＞

図１０および図１１は、配当分配システム１の全体的な動作の流れを表す図である。

ビルダー端末８において、ビルダーによるタッチパネル９４の入力操作に伴い、キャラクタ作成手段８７２は、キャラクタの作成処理を行ったとする（ステップｓｔ１）。通信制御手段８７１は、そのキャラクタに関する情報を、サーバ装置２に送信する制御を行う。

サーバ装置２において、前記キャラクタに関する情報を受信すると、ＤＢ管理手段２３３は、この情報に基づいてユーザＤＢ２２ａの該当箇所を更新する（ステップｓｔ２）。通信制御手段２３１は、最新のキャラクタに関する情報全てを、各端末４，６，８に送信する（ステップｓｔ３）。端末４，６の報知制御手段４７４，６７３は、最新のキャラクタに関する情報を例えば一覧の態様にて報知させる（ステップｓｔ４，ステップｓｔ５）。ビルダー端末８の報知制御手段８７３は、自端末８にて作成したキャラクタに関する情報が、サーバ装置２にて受信され管理対象となった旨を画面表示させる（ステップｓｔ６）。

ゲーム端末４において、最新のキャラクタに関する情報を基に、プレイヤが任意のビルダーをフレンドとして登録することを希望する場合がある。ゲーム端末４のコントローラ５４を介して、任意のビルダーをフレンドとして選択し登録する操作がなされた場合、通信制御手段４７１は、任意のビルダーをフレンド対象者とした状態で、フレンド登録申請をサーバ装置２に送信する（ステップｓｔ７）。

このフレンド登録申請を受信したことを受けて、サーバ装置２の通信制御手段２３１は、フレンド登録申請をしたプレイヤについての情報を、フレンド対象者となったビルダーのビルダー端末８に送信する。ビルダー端末８では、フレンド登録申請したプレイヤについての情報が報知される。ビルダー端末８側にてフレンド登録の承認操作がなされたことを受けて、サーバ装置２のＤＢ管理手段２３３は、ユーザＤＢ２２ａにおける該当箇所を更新する（ステップｓｔ８）。更新後、通信制御手段２３１は、フレンド登録が完了した旨をゲーム端末４に送信する。これにより、ゲーム端末４では、フレンド登録が完了した旨が報知される。また、サーバ装置２の通信制御手段２３１は、フレンド登録された旨をフレンド対象者となったビルダーのビルダー端末８に送信する。これにより、ビルダー端末８では、フレンド対象者として登録された旨が報知される（ステップｓｔ９）。

また、ギャラリーがプレイヤやビルダーへの支援を希望する場合がある。ベット端末６のコントローラ７４を介して、支援対象候補となるプレイヤおよびビルダーの中から、任意のプレイヤおよびビルダーを選択する操作がなされた場合、通信制御手段６７１は、選択されたプレイヤおよびビルダーを支援対象者とした状態で、支援者申請をサーバ装置２に送信する（ステップｓｔ１０）。

この支援者申請を受信したことを受けて、サーバ装置２の通信制御手段２３１は、支援者申請をしたギャラリーについての情報を、支援対象者となったプレイヤおよびビルダーそれぞれのゲーム端末４およびビルダー端末８に送信する。ゲーム端末４およびビルダー端末８では、支援者申請したギャラリーについての情報が報知される。これらの端末４，８側にて支援者申請の承認操作がなされたことを受けて、サーバ装置２のＤＢ管理手段２３３は、ユーザＤＢ２２ａにおける該当箇所を更新する（ステップｓｔ１１）。更新後、通信制御手段２３１は、支援者登録が完了した旨をベット端末６に送信する。また、通信制御手段２３１は、支援者の情報を、該当するプレイヤのゲーム端末４およびビルダーのビルダー端末８に送信する。これにより、ゲーム端末４およびビルダー端末８では、支援対象となった旨および支援者名などの情報が報知される（ステップｓｔ１２，ｓｔ１３）。

ところで、プレイヤがゲームプレイへの参加を希望する場合がある。ゲーム端末４のコントローラ５４を介して、対戦相手の決定を要求する操作がなされた場合、通信制御手段４７１は、マッチング申請をサーバ装置２に送信する（ステップｓｔ１４）。

このマッチング申請を受信したことを受けて、サーバ装置２のマッチング手段２３４は、マッチング処理を行う（ステップｓｔ１５）。マッチング処理により対戦相手が設定されると、通信制御手段２３１は、対戦相手先に、対戦を承諾するか否かの打診情報を送信する。その対戦相手から対戦への承諾を受信した場合、通信制御手段２３１は、対戦相手を含むマッチング結果と、ゲームプレイを行う日時などを、マッチング申請先のゲーム端末４に送信する（ステップｓｔ１６）。

次いで、サーバ装置２の人気度算出手段２３６は、マッチングした対戦者（プレイヤ）それぞれについての最新の人気度を算出し（ステップｓｔ１７）、配当倍率決定手段２３７は、その対戦者（プレイヤ）それぞれに対応する配当倍率を、最新の人気度に基づいて決定する（ステップｓｔ１８）。配当倍率の決定後、通信制御手段２３１は、ゲームイプレイの内容、配当倍率および最新のベット状況などを、各端末４，６，８に送信する（ステップｓｔ１９）。これにより、各端末４，６，８では、当該情報の受信および報知がなされる（ステップｓｔ２０，ｓｔ２１，ｓｔ２２）。

ベット端末６では、ステップｓｔ２１で報知された情報を確認したギャラリーが、そのゲームプレイへのベットを希望する場合がある。ベット端末６のコントローラ７４を介して、ベット操作がなされた場合（ステップｓｔ２３）、通信制御手段６７１は、ベット操作に関する情報をサーバ装置２に送信する。

ベット操作に関する情報を受信したことを受けて、サーバ装置２のベット管理手段２３５は、ベットされたゲームプレイおよびプレイヤ、ベットされたゲーム内通貨の量などを特定してベット状況を更新する（ステップｓｔ２４）。ＤＢ管理手段２３３は、ユーザＤＢ２２ａ内の該当箇所を更新する。ユーザＤＢ２２ａの更新後、通信制御手段２３１は、更新されたベット状況を各端末４，６，８に送信する。これにより、各端末４，６，８では、当該ベット状況の受信および報知がなされる（ステップｓｔ２５，ｓｔ２６，ｓｔ２７）。

予定されていたゲームプレイの日時に至るとベット操作の受け付けは締め切られ、ゲーム端末４では、ゲームプレイ（対戦）が実行される（ステップｓｔ２８）。ゲームプレイが実行されている間、動画データ生成手段４７５は、ゲームプレイ動画と映像データとを用いて動画データを生成する。この動画データは、通信ネットワークＮＷにリアルタイムでブロードキャストされる。そのため、各端末４，６，８は、ゲームプレイの様子を視聴することができる。

ゲームプレイが終了すると（ステップｓｔ２９）、ゲーム端末４の通信制御手段４７１は、プレイヤの勝敗を含むゲームプレイの結果をサーバ装置２に送信する。

このゲームプレイの結果を受信したことを受けて（ステップｓｔ３０）、サーバ装置２の配当付与手段２３８は、ベット操作に対する配当を決定してギャラリーに付与する処理を行い、報酬付与手段２３９は、ゲームプレイに関与したことに対するプレイ報酬を決定してプレイヤおよびビルダーに付与する処理を行う。ギャラリーが支援者として支援を行っていた場合、報酬付与手段２３９は、その支援に対する支援報酬の額を決定して当該ギャラリーに付与する処理を行う（ステップｓｔ３１）。

サーバ装置２の通信制御手段２３１は、ゲームプレイの結果、配当が付与された場合にはその旨と配当の額の情報、プレイ報酬が付与された場合にはその旨とプレイ報酬の額の情報、支援報酬が付与された場合にはその旨と支援報酬の額の情報を、該当する端末４，６，８に送信する。これにより、ゲーム端末４では、ゲームプレイの結果、プレイ報酬が付与された旨、プレイ報酬の額が報知される（ステップｓｔ３２）。ベット端末６では、ゲームプレイの結果、配当が付与された旨、配当の額、支援報酬が付与された旨、支援報酬の額が報知される（ステップｓｔ３３）。ビルダー端末８では、ゲームプレイの結果、プレイ報酬が付与された旨、プレイ報酬の額が報知される（ステップｓｔ３４）。

以上をまとめると、本実施形態の配当分配システム１は、プレイヤ（第１ユーザ）のゲームプレイに対して、ギャラリー（第２ユーザ）がベットするベット操作を受け付けるベット端末６の操作判定手段６７２（ベット受付部）と、ゲームプレイに対応する配当倍率を、プレイヤ（第１ユーザ）の人気度に基づいて決定するサーバ装置２の配当倍率決定手段２３７（配当倍率決定部）と、ゲームプレイの結果および配当倍率に基づいて、ゲームプレイへのベット操作に対する配当をギャラリー（第２ユーザ）に付与する配当付与手段２３８（配当付与部）とを備えるものである。

＜効果＞
本実施形態によれば、配当倍率は、プレイヤの人気度に基づいて決定される。つまり、配当倍率は、運営者側の都合で決定された値というよりも、むしろギャラリーなど参加ユーザにとって親しみやすい情報が反映した値となっている。従って、ギャラリーは、ベットへの参加意欲が増し、ゲームへの興味心が向上する。

更に、配当倍率は、ベット操作に応じたベット状況に基づいて決定されることができる。例えば一方のプレイヤにベットが集中した場合などに、配当倍率をベット状況に基づいて決定（調整）すれば、ベット状況の偏りを緩和できる可能性がある。

また、ビルダー端末８では、ビルダー（第３ユーザ）による操作に基づいて、ゲームプレイにて利用可能なキャラクタ（利用媒体）を作成することができる。ビルダーは、プレイヤとしてではないが、キャラクタの作成を通じてゲームプレイへ参加することで、ゲームプレイへの親しみを感じることができる。

また、ゲーム端末４では、プレイヤの操作に基づいて、ゲームプレイにて使用するキャラクタを選択することができる。キャラクタとして、ビルダーが作成したものを選択することで、プレイヤとビルダーとの繋がりができ、ビルダーは、プレイヤに親しみを感じることができる。また、ビルダーにとっては、キャラクタの作成への意欲が更に増すことができる。

プレイヤがゲームプレイにて使用するキャラクタを選択する際、選択候補には、そのプレイヤとの間でフレンド登録されているビルダーが作成したキャラクタ、が含まれることができる。これにより、プレイヤは、フレンド登録されているビルダーのキャラクタを、積極的に選択することが可能となる。

ギャラリーは、プレイヤおよび／またはビルダーを支援する支援者として登録されることもできる。支援者として登録されれば、支援対象者であるプレイヤおよびビルダーごとに、どの程度出資を受けたかなどの支援情報が管理される。この支援情報に応じて、プレイヤおよび／ビルダーには、ゲームプレイに関するプレイ報酬が付与されることができる。つまり、プレイヤやビルダーが得られる、ゲームプレイに関与したことによるプレイ報酬は、どの程度の出資を受けたかによっても異なってくる。

また、支援者となったギャラリーには、支援をしたことに対する支援報酬が付与される。支援報酬は、支援情報に応じてランク分けされた結果（分類結果）と、支援対象者であるプレイヤおよびビルダーそれぞれのゲームプレイに関する活躍に応じた評価値と、に応じて決定されることができる。つまり、支援者となったギャラリーには、出資などの支援をどの程度行ったかを表すランクと、その支援を受けたプレイヤやビルダーがどの程度活躍したかと、に応じた支援報酬が付与されることができる。これにより、支援者であるギャラリーは、支援対象者であるプレイヤやビルダーとのつながりを、パトロンの立場として意識するようになるため、更なる支援の呼び水ともなり得る。

プレイヤやビルダーの支援者の有無に関係なく、ゲームプレイを行ったことに対するプレイ報酬は、プレイヤやビルダーに与えられる。このプレイ報酬は、ゲームプレイの結果、ベット操作に応じたベット状況、プレイヤの人気度、および、ビルダーの人気度、少なくとも１つに基づいて決定されることができる。従って、プレイ報酬は、変動する場合があると言える。

ビルダーの人気度は、ビルダーが作成したキャラクタを使用して行われたゲームプレイ（所定プレイ）の結果、このプレイにて当該キャラクタを使用したプレイヤへのベット状況、ビルダーを支援する支援者の数、ビルダーが支援を受けた支援数、の少なくとも１つに基づいて算出されることができる。つまり、ビルダーの人気度は変動することがあるため、このビルダーの人気度に基づいて決定されたプレイヤ報酬も、変動する場合があると言える。

また、支援対象者であるプレイヤおよびビルダーの少なくとも一方が関与するゲームプレイがギャラリーによるベット対象候補となり、ギャラリーは、このベット対象候補のうち所定のゲームプレイにベットすることができる。ギャラリーは、自身が支援を行っていることから、支援対象者であるプレイヤやビルダーを応援する意味でもベットを行いたくなる。一方で、支援対象者であるプレイヤやビルダーは、支援者の期待に応えるためにも、ゲームプレイに勝利できるように取り組む意欲が増す。

プレイヤの人気度は、そのプレイヤが関与したゲームプレイの結果、プレイヤへのこれまでのベット状況、プレイヤを支援する支援者の数、プレイヤが支援を受けた支援数、の少なくとも１つに基づいて算出されることができる。つまり、プレイヤの人気度は変動することがあるため、このプレイヤの人気度に基づいて決定された配当倍率も、その時々で変動することがあると言える。

［他の実施形態］
前記実施形態において説明した各種制御手段および処理手順は一例であり、本開示、その適用物、またはその用途の範囲を制限することを意図するものではない。各種制御手段および処理手順は、本開示の要旨を変更しない範囲で適宜設計変更が可能である。

前記ゲームは、格闘ゲームなどの対戦型ゲームに限定されず、ゲームプレイによってベット対象となる事象が生じるものであればどのようなゲームであってもよい。ゲームは、アクションゲームやカードゲームなどにも適用できる。例えば、ゲームは、複数人のプレイヤが協力してプレイを行うことで課題を解決したりノンプレイヤキャラクタの敵を倒したりするゲームであってもよいし、複数人のプレイヤ同士が対戦するゲームであってもよい。

前記実施形態では、ゲームプレイの動画データがリアルタイムまたはプレイ後にブロードキャストされると説明したが、これは必須ではない。

前記実施形態では、ビルダーが作成する育成対象がゲーム媒体であって、一体の「キャラクタ」である場合を例示した。しかし、育成対象は、複数のキャラクタからなるチームであってもよい。

ビルダーが作成したキャラクタは、一人のプレイヤが使用してもよいし、複数人が使用してもよい。また、ビルダーが複数のキャラクタからなるチームを作成した場合、そのチームを一人のプレイヤが使用してもよいし、複数人のプレイヤが使用してもよい。

前記実施形態におけるプレイ報酬は、プレイヤとしてのみ、またはビルダーとしてのみ使用できるものであってもよい。例えば、プレイヤに対するプレイ報酬は、ゲームプレイを無料でできる所定回数分の参加権利、キャラクタのステータスを強化するためのアイテム、キャラクタに付与できるスキルなどであってもよい。ビルダーに対するプレイ報酬は、キャラクタの専用パーツ、キャラクタの育成処理の際に使用できる改造パーツや材料などであってもよい。

また、プレイ報酬は、プレイヤおよびビルダー共通して利用できるものであってもよい。例えば、プレイ報酬は、ゲームセンターやカジノなどで実際に利用できるメダル、紙幣などの現金貨幣、トークンなどの私製貨幣を含む仮想通貨、電子マネーであってもよい。プレイ報酬は、キャラクタの経験値、キャラクタの行動時間や行動回数を規制するスタミナ値、抽選でゲームオブジェクトを選択するガチャ実行と引き換えに消費される消費媒体や抽選権利、トーナメント戦などの特別なゲームイベントへの参加権利であってもよい。

一人のビルダーは、複数体のキャラクタ（利用媒体）を作成することができてもよい。この場合、「個々のキャラクタごとの人気度」が、そのキャラクタごとのビルダーに対する人気度として紐づけられていてもよい。また、全てのキャラクタを作成したことに対する総合評価が、ビルダーに対する人気度として紐づけられていてもよい。

プレイヤの人気度はビルダーに報知され、ビルダーの人気度はプレイヤに報知されてもよい。この場合、プレイヤは、人気度の比較的低いビルダーが作成したキャラクタまたは人気度の比較的低いキャラクタをあえて選択することができるようになる。このようなキャラクタをあえて使用した状態で勝利することで、サーバ装置２の人気度算出手段２３６は、そのキャラクタにおけるビルダーの人気度を通常よりも大幅に上昇させるように演算を行ってもよい。また、プレイヤは、人気度の比較的低いキャラクタをあえて使用した状態で勝利することができれば、プレイヤ自身の人気度が上昇するきっかけともなり得る。

前記実施形態では、プレイヤは、フレンド登録されたビルダーのキャラクタを、ゲームプレイにて使用するキャラクタとして選択できると説明した。しかし、ゲーム大会のイベントによっては、「フレンド登録されたビルダーのキャラクタは使用不可」「使用するキャラクタがランダム抽選により強制的に割り当てられる」などの規制が課せられていてもよい。これらの場合、配当分配システム１では、フレンド登録されたビルダーのキャラクタは選択できないがそれ以外は選択できる仕様や、ビルダーが誰かに関係なくキャラクタの選択自体ができない仕様、となることができる。

ゲームプレイの際、プレイヤの人気度に応じて、人気度の高いプレイヤ側に対し、ハンディキャップが課されてもよい。これにより、どちらのプレイヤが勝利するかの予想が付きにくくなるため、一層のゲームプレイの盛り上がりが期待される。

前記実施形態では、図７の画面ｓｃ１に示すように、ゲームプレイの開始前、ベット端末６は、予定されているゲームプレイにおけるベット状況や配当倍率を報知すると説明した。しかし、この報知タイミングは、ゲームプレイの終了後であってもよい。つまり、ベット状況や配当倍率の報知は、ゲームプレイの終了までされなくてもよい。ゲームプレイ開始前にギャラリー同士、またはギャラリーとプレイヤ同士で、自分達に有利な結果となるように談合がなされるなどの不正の誘発を防ぐためである。

ベット端末６は、ベット操作および配当付与の連絡を受けることが可能な端末であればよく、基本的には他端末４，８とは独立制御される端末であってもよい。

支援者となるギャラリーは、プレイヤまたはビルダーを単体で支援対象者としてもよいし、プレイヤとビルダーとの組み合わせを支援対象としてもよい。

プレイヤやビルダーにはレベルが存在してもよいし、キャラクタにレベルが存在していてもよい。レベルが高いほどゲームプレイが有利になる仕様であってもよい。例えば、プレイヤまたはキャラクタは、レベルが高いほど、プレイ中にプレイを有利に運ぶことのできるスキルが使用できる。ビルダーのレベルが高いほど、育成対象作成時に特殊なスキルが付与されるなどの恩恵が付与されることができる。

キャラクタには、そのキャラクタを作成したビルダーが配当分配システム１にログインしている場合に限り使用可能であるなどの、使用制限が課せられていてもよい。また、プレイヤがキャラクタのビルダーとフレンド登録している場合、当該プレイヤは、そのビルダーのログイン状態に関係なく（つまり、ビルダーがたとえログインしていない状態であっても）そのキャラクタを使用できてもよい。

ビルダーが配当分配システム１にログインしている状態か否かに応じて、キャラクタのステータス（スキルや性能）が変化してもよい。この場合、ゲームプレイを行う際のビルダーのログイン状況に応じてキャラクタのステータスが変化するため、ゲームプレイの結果にも影響が及ぶ。

なお、ゲームイプレイの途中でビルダーのログイン状態が、ログオフからログオンまたはログオンからログオフへと変更することも想定される。そこで、ゲームプレイ開始時のビルダーのログイン状態に応じたステータスが、ゲームプレイ中は維持されることが好ましい。

前記実施形態では、支援者は、どの程度支援したかに応じてランク分けされると説明した。このランクに応じた称号が、支援者に与えられてもよい。この称号は、本システム１に参加する他のユーザに向けて報知されてもよい。称号の報知タイミングは、称号が付与されたタイミング、ゲームプレイ開始前の配当倍率などが報知されるタイミングなど、どのようなタイミングであってもよい。これにより、支援者が有名な人物であれば、その人物に支援されているプレイヤやビルダーである旨が、本システム１に参加する他のユーザに知れ渡るため、そのプレイヤやビルダーの人気度も上昇する可能性がある。

前記実施形態では、説明の便宜上、本システム１に参加するユーザの役割を、「プレイヤ」「ギャラリー」「ビルダー」と称して説明した。しかし、１つのゲーム大会においてユーザが２つ以上の役割を兼ねることが可能であったり、逆に特定のゲーム大会ではユーザが２以上の役割を兼ねることを禁止されていたりしてもよい。

前記実施形態では、プレイヤとビルダーとのフレンド登録は、フレンドとなる相手を指定したフレンド申請をきっかけに行われると説明した。しかし、フレンド申請は、相手を指定せず、フレンド申請をきっかけとして、マッチングによりフレンドとなる相手が自動で決定および登録されてもよい。

前記実施形態では、ギャラリーが、ゲームプレイの勝敗に対してベットする場合を例示した。しかし、ベットする対象は、ゲームプレイに関するものであればよく、ゲームプレイの「勝敗」以外であってもよい。例えば、「プレイヤの勝敗が何戦目で決定するか」「ゲームプレイ中に繰り出される技に所定技が含まれるか否か」「１試合の間に、所定の技を合計で何発繰り出すか」などが、ベットする対象であってもよい。

前記実施形態では、マッチングにより対戦相手が設定される場合を例示した。しかし、マッチングは行われなくてもよい。トーナメント戦やリーグ戦などにおいて、対戦カード（対戦者）が予め組まれていてもよい。この場合、プレイヤは、予定時刻通りにログインして、既に決定されている対戦相手と対戦することができる。この場合、ギャラリーは、対戦予定を確認してベットすることができる。

前記実施形態では、そのプレイヤおよびビルダーの“支援者”をギャラリーと見立て、その支援者が支援対象者であるプレイヤおよびビルダーの関与するゲームプレイにベットできる場合を例示した。しかし、支援者は、ベットせずに、純粋にゲームプレイの観戦を楽しんだり、支援対象者の活躍の様子を見て楽しんたりするのみであってもよい。

前記実施形態では、ベット対象候補の抽出処理が、リアルタイムで行われる場合を例示した。しかし、ベット対象候補の抽出処理は、リアルタイムではなく、１時間ごとなどの所定時間ごとに行われてもよい。

ベット操作は、ゲームプレイ開始前までではなく、ゲームプレイ開始後から所定時間経過するまでは、行うことが可能であってもよい。この場合、ゲームプレイ開始後にベット操作を行ったギャラリーへの配当は、開始前に行った場合よりも配当が減少してもよい。

報酬付与手段２３９は、ベットされた額および／または配当額の一部を、プレイヤやビルダーに報酬として付与する処理を行ってもよい。この場合の報酬は、仮想ゲーム空間内で有効となる有償のゲーム内通貨または無償のゲーム内通貨の形で、プレイヤやビルダーに付与されてもよい。また、報酬付与手段２３９は、ベットされた額および／または配当額の一部を、本システム１に登録している全プレイヤに対して付与する処理を行ってもよい。この場合の報酬は、全てのプレイヤに対して、ゲームプレイへの積極的な参加を促すための呼び水となり得る。

ギャラリーは、プレイヤのみをベット対象とし、ビルダーについての情報が非公開の状態にて、ベット操作を行ってもよい。この場合、報酬は、プレイヤだけでなくビルダーにも付与する処理が行われてもよい。ギャラリーは、ビルダーに関する知識があれば、どのプレイヤがどのビルダーのキャラクタを利用しているかを予想することができる。このようなギャラリーにとっては、ビルダーについての情報が非公開であることで、賭けをより楽しむことができる。また、プレイヤにのみベットした状態でゲームプレイが開始された後、ビルダーについての情報が公開されてもよい。この場合、ギャラリーはベットし直すことができてもよい。

図１０のステップｓｔ１６において、対戦相手から対戦への承認を受信した場合、サーバ装置２の通信制御手段２３１は、ベットの締め切り時間を設定し、ベットの締め切り時間を、マッチング申請先のゲーム端末４などに送信してもよい。

前記実施形態では、配当分配システム１は、サーバ装置２、ゲーム端末４、ベット端末６、およびビルダー端末８によって構成され、サーバ装置２および各端末４，６，８は、図３～図８に示すように各機能を有する場合を例示した。しかし、システム構成、どの装置または端末がどの機能を有するかは、前記実施形態に限定されることなく、適宜変更が可能である。

１ 配当分配システム
２３３ ＤＢ管理手段（フレンド登録部）
２３５ ベット管理手段（ベット対象決定部）
２３６ 人気度算出手段（人気度算出部）
２３７ 配当倍率決定手段（配当倍率決定部）
２３８ 配当付与手段（配当付与部）
２３９ 報酬付与手段（報酬付与部、分類部）
４７２ ゲーム設定手段（媒体選択部）
６７２ 操作判定手段（ベット受付部）
８７２ キャラクタ作成手段（媒体作成部）

Claims (10)

1. 第１ユーザのゲームプレイに対応する配当倍率を、前記第１ユーザの現在までのゲームプレイの結果を含む履歴データに基づいて決定する配当倍率決定部と、
   決定された前記配当倍率を含む前記第１ユーザのゲームプレイについての情報を報知部に報知させる報知制御部と、
   前記第１ユーザのゲームプレイに対して、第２ユーザがベットするベット操作を受け付け可能なベット受付部と、
   を備えるシステム。
2. 前記履歴データは、前記第１ユーザの現在までのゲームプレイにかかわる行動に応じたデータである
   請求項１に記載のシステム。
3. 前記履歴データには、前記第１ユーザのプレイ回数、前記第１ユーザが前記ゲームプレイで勝った総数、および、これまでに前記第１ユーザが所定基準を満たす試合を実行した回数、の少なくともいずれか１つが含まれる
   請求項１または２に記載のシステム。
4. 前記所定基準が満たされているか否かは、ゲームプレイの観戦者の歓声の音量、および／または、ゲームプレイの視聴者が所定行動をとった回数、によって判断される
   請求項３に記載のシステム。
5. 前記報知制御部は、前記第１ユーザのゲームプレイ終了後に前記ベットの結果を報知する
   請求項１から請求項４のいずれか１項に記載のシステム。
6. 一以上のコンピュータに、次の各ステップを実行させる方法であって、
   配当倍率決定ステップでは、第１ユーザのゲームプレイに対応する配当倍率を、前記第１ユーザの現在までのゲームプレイの結果を含む履歴データに基づいて決定し、
   報知制御ステップでは、決定された前記配当倍率を含む前記第１ユーザのゲームプレイについての情報を報知部に報知させ、
   ベット受付ステップでは、前記第１ユーザのゲームプレイに対して、第２ユーザがベットするベット操作を受け付ける、
   方法。
7. 前記履歴データは、前記第１ユーザの現在までのゲームプレイにかかわる行動に応じたデータである
   請求項６に記載の方法。
8. 前記履歴データには、前記第１ユーザのプレイ回数、前記第１ユーザが前記ゲームプレイで勝った総数、および、これまでに前記第１ユーザが所定基準を満たす試合を実行した回数、の少なくともいずれか１つが含まれる
   請求項６または７に記載の方法。
9. 前記所定基準が満たされているか否かは、ゲームプレイの観戦者の歓声の音量、および／または、ゲームプレイの視聴者が所定行動をとった回数、によって判断される
   請求項８に記載の方法。
10. 前記報知制御ステップでは、前記第１ユーザのゲームプレイ終了後に前記ベットの結果を報知する
    請求項６から請求項９のいずれか１項に記載の方法。
    
    

Images