(57)【特許請求の範囲】
【請求項１】
所定の対価と関連付けられる対価対象を含むゲームを各ユーザに提供するゲームシステムであって、
各ユーザの過去のプレイ状況を示すプレイ情報と各ユーザを識別するためのユーザ識別情報とが関連付けられるように記述されたプレイデータを記憶するデータ記憶装置と、
グループ条件を満たす複数のユーザのうちの一のユーザ及び当該一のユーザとは別のユーザを特定するユーザ特定手段と、
前記一のユーザが前記別のユーザのための前記所定の対価の支払いを許容することを示す許容条件を満たす場合に、前記別のユーザに前記対価対象を付与する対価付与手段と、
を備え、
前記ゲームを各ユーザに提供する少なくとも一つのゲーム端末を含み、
前記所定の対価の支払いは、前記一のユーザによって前記許容条件が満たされた場合には、前記複数のユーザのうち前記一のユーザ以外の全ユーザを対象に制限され、
前記グループ条件は、前記プレイデータに関連する関連条件を含み、前記ユーザ識別情報を介して各ユーザに関連付けられる前記プレイデータが前記関連条件を満たす場合に少なくとも満たされ、
前記プレイデータは、前記プレイ情報が前記ゲーム端末を特定するための端末特定情報と更に関連付けられるように構成され、
前記関連条件は、前記プレイデータが前記端末特定情報を介して同じゲーム端末に関連付けられる場合に満たされる、ゲームシステム。
【請求項２】
前記別のユーザのための前記所定の対価の支払いを許容するか否か選択するための許容機会を前記一のユーザに付与する機会付与手段を更に備え、
前記許容条件は、前記許容機会を通じた前記一のユーザによる前記所定の対価の支払いを許容する選択を要件に含んでいる、請求項１に記載のゲームシステム。
【請求項３】
前記機会付与手段は、前記別のユーザによって前記対価対象の付与が要求された場合に前記一のユーザに前記許容機会を付与し、
前記許容条件は、前記許容機会を通じて前記一のユーザによって前記別のユーザの要求に対応する前記所定の対価の支払いを許容する選択が実行された場合に少なくとも満たされる、請求項２に記載のゲームシステム。
【請求項４】
前記許容機会は、前記所定の対価の支払いを予め所定量許容する許容量の設定を通じて前記別のユーザのための前記所定の対価の支払いを許容する選択が実行されるように構成され、
前記許容条件は、前記許容量が設定された場合に満たされる設定条件及び前記別のユーザの要求が前記許容量の範囲内の場合に満たされる範囲条件を要件に含み、前記設定条件及び範囲条件の両方が満たされた場合に少なくとも満たされる、請求項２又は３に記載のゲームシステム。
【請求項５】
前記端末特定情報は、前記ゲームを提供する複数のゲーム端末をそれぞれ識別可能に構成され、
前記関連条件は、前記同じゲーム端末に対応する前記端末特定情報を含む前記プレイデータによって満たされる、請求項１〜４のいずれか一項に記載のゲームシステム。
【請求項６】
前記関連条件は、ユーザによって設定された要件を更に含み、前記ユーザによって関連が設定された各ユーザの前記プレイデータによって満たされる、請求項１〜５のいずれか一項に記載のゲームシステム。
【請求項７】
前記データ記憶装置に接続されるコンピュータを、請求項１〜６のいずれか一項に記載のゲームシステムの各手段として機能させるように構成されたコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、所定の対価と関連付けられる対価対象を含むゲームを各ユーザに提供するゲームシステム等に関する。
【背景技術】
【０００２】
所定の対価と関連付けられる対価対象を含むゲームを各ユーザに提供するが存在する。例えば、このような対価対象として複数のゲーム媒体を利用し、所定の対価の支払いと引き換えに各デッキに含まれるゲーム媒体を抽選で提供するサーバ装置が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第５３３５９６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１のようなサーバ装置では、例えば、ポイント等の所定の対価が消費（徴収）される限り、無制限にゲーム媒体が提供される場合が多い。一方で、近年は携帯電話等のユーザ端末がゲーム端末として使用される場合も多い。このため、万人がゲーム端末を使用する可能性がある。結果として、無制限の対価の消費は好ましくなく、制限が必要な場合もある。また、ゲーム端末を他のユーザと共用する場合もあり、そもそも対価対象の付与を要求する本人に対価の支払いを決定する権限がない可能性もある。具体的には、一台のゲーム端末が共用されるときには、その一台のゲーム端末を所有するユーザ以外のユーザはそのゲーム端末の使用時間や使用機能が制限される場合が多い。少なくとも、対価の支払いに関連する支払い機能に関してはユーザ認証が必要等、所有者以外の使用が制限される場合は多い。つまり、一台のゲーム端末が共用されるときには、不便或いは困難等の理由により所有者以外のユーザには支払いを決定する権限がない（或いはないに等しい）場合もある。例えば、このような場合、対価の支払いが必要な際に決定権を有する者の許可が必要になる。そして、このような許可等はユーザに委任され、現実のコミュニケーションに依存する場合が多い。結果として、対価の支払い、対価対象の付与といった一連の流れに支障が生じてしまう可能性がある。
【０００５】
そこで、本発明は、対価対象が付与されるユーザとは異なるユーザにその対価対象の付与に対応する所定の対価の支払いを請求することができるゲームシステム等を提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明のゲームシステムは、所定の対価と関連付けられる対価対象を含むゲームを各ユーザに提供するゲームシステムであって、グループ条件を満たす複数のユーザのうちの一のユーザ及び当該一のユーザとは別のユーザを特定するユーザ特定手段と、前記一のユーザが前記別のユーザのための前記所定の対価の支払いを許容することを示す許容条件を満たす場合に、前記別のユーザに前記対価対象を付与する対価付与手段と、を備えている。
【０００７】
一方、本発明のコンピュータプログラムは、前記ゲームを提供するための出力装置を備えたコンピュータを、上述のゲームシステムの各手段として機能させるように構成されたものである。
【０００８】
また、本発明のサーバ装置は、上述のゲームシステムにネットワークを介して接続されるサーバ装置であって、前記許容条件が満たされる場合に、当該許容条件が満たされることを示す許容情報を取得する結果取得手段と、前記許容条件が満たされる場合に、前記別のユーザに前記対価対象が付与されるように、前記許容情報を前記ゲームシステムに提供する結果提供手段と、を備えている。
【図面の簡単な説明】
【０００９】
【図１】本発明の一形態に係るゲームシステムの全体構成の概要を示す図。
【図２】ゲームシステムの制御系の要部の構成を示す図。
【図３】グループ単位で対価対象の対価が負担される場合の一例を説明するための説明図。
【図４】事後的に付与される許容機会の一例を説明するための説明図。
【図５】事前に付与される許容機会の一例を説明するための説明図。
【図６】各ユーザによって形成されるグループの一例を説明するための説明図。
【図７】データ選択画面に一例を模式的に示す図。
【図８】プレイデータの内容の一例を説明するための説明図。
【図９】負担管理データの内容の一例を説明するための説明図。
【図１０】機会提供処理ルーチンのフローチャートの一例を示す図。
【図１１】対象付与処理ルーチンのフローチャートの一例を示す図。
【図１２】結果送信処理ルーチンのフローチャートの一例を示す図。
【発明を実施するための形態】
【００１０】
以下、本発明の一形態に係るゲームシステムについて説明する。図１は、本発明の一形態に係るゲームシステムの全体構成の概要を示す図である。図１に示すように、ゲームシステム１は、サーバ装置としてのセンターサーバ２を含んでいる。センターサーバ２は、一台の物理的装置によって構成される例に限らない。例えば、複数の物理的装置としてのサーバ群によって一台の論理的なセンターサーバ２が構成されてもよい。また、クラウドコンピューティングを利用して論理的にセンターサーバ２が構成されてもよい。
【００１１】
センターサーバ２には、ネットワーク３を介して、ゲーム端末５が接続される。ゲーム端末５は、ユーザにゲームをプレイさせる機能（ゲーム機能）を備えたネットワーク端末装置の一種である。図１の例では、ゲーム端末５の一例として、携帯電話（スマートフォンを含む）が利用されている。携帯電話は、ユーザの個人用途に供されるユーザ端末の一種である。例えば、携帯電話は、センターサーバ２から配信されるソフトウェアを実行することにより、ゲーム機能を発揮してよい。ゲーム端末５として、例えば、その他にもパーソナルコンピュータ、携帯型ゲーム機、携帯型タブレット端末装置といった、ネットワーク接続が可能でかつユーザの個人用途に供される各種のネットワーク端末装置が利用されてよい。或いは、有料或いは無料で所定範囲のゲームをプレイさせる業務用（商業用）のゲーム機がゲーム端末５として使用されてもよい。
【００１２】
ネットワーク３は、一例として、ＴＣＰ／ＩＰプロトコルを利用してネットワーク通信を実現するように構成される。典型的には、ＷＡＮとしてのインターネットと、ＬＡＮとしてのイントラネットと、を組み合わせてネットワーク３が構成される。図１の例では、センターサーバ２はルータ３ａを介して、ゲーム端末５はアクセスポイント３ｂを介して、それぞれネットワーク３に接続されている。
【００１３】
なお、ネットワーク３は、ＴＣＰ／ＩＰプロトコルを利用する形態に限定されない。ネットワーク３として、通信用の有線回線、或いは無線回線（赤外線通信、近距離無線通信等を含む）等を利用する各種の形態が利用されてよい。
【００１４】
センターサーバ２は、ネットワーク３を介してゲーム端末５のユーザに各種のＷｅｂサービスを提供する。Ｗｅｂサービスには、例えば、ゲーム端末５が提供するゲームに関する各種の情報を提供するゲーム用情報サービスが含まれてよい。また、例えば、Ｗｅｂサービスには、各ゲーム端末５に各種データ（ゲームで使用するアイテム、背景画像、音楽といったゲーム用のコンテンツを含む）或いはソフトウェアを配信（データ等のアップデートを含む）する配信サービスが含まれてもよい。さらに、Ｗｅｂサービスには、その他にもユーザによる情報発信、交換、共有といった交流の場を提供するコミュニティサービス、各ユーザを識別するためのユーザＩＤを付与するサービス、ネットワーク３を介して複数のユーザが共通のゲームをプレイする際にユーザ同士をマッチングするマッチングサービス等のサービスが含まれてよい。
【００１５】
次に、ゲームを提供するためのゲームシステム１の制御系の要部について説明する。図２は、ゲームシステム１の制御系の要部の構成を示す図である。図２に示すように、センターサーバ２は、制御ユニット１０と、記憶ユニット１１と、を備えている。制御ユニット１０は、マイクロプロセッサと、そのマイクロプロセッサの動作に必要な内部記憶装置（一例としてＲＯＭ及びＲＡＭ）等の各種周辺装置とを組み合わせたコンピュータユニットとして構成されている。なお、制御ユニット１０には、キーボード等の入力装置、モニタ等の出力装置等が接続され得る。しかし、それらの図示は省略した。
【００１６】
記憶ユニット１１は、制御ユニット１０に接続されている。記憶ユニット１１は、電源の供給がなくても記憶を保持可能なように、例えば、磁気テープ等の大容量記憶媒体により構成されている。記憶ユニット１１には、サーバ用データ１４及びサーバ用プログラム１５が記憶されている。サーバ用プログラム１５は、センターサーバ２がゲーム端末５に各種のサービスを提供するために必要なコンピュータプログラムである。制御ユニット１０がサーバ用プログラム１５を読み取って実行することにより、制御ユニット１０の内部には、Ｗｅｂサービス管理部１７が設けられる。
【００１７】
Ｗｅｂサービス管理部１７は、上述のＷｅｂサービスを提供するために必要な処理を実行する。Ｗｅｂサービス管理部１７は、コンピュータハードウェアとコンピュータプログラムとの組み合わせにより実現される論理的装置である。なお、制御ユニット１０の内部には、その他にも各種の論理的装置が設けられ得る。しかし、それらの図示は省略した。
【００１８】
サーバ用データ１４は、サーバ用プログラム１５の実行に伴って参照されるデータである。例えば、サーバ用データ１４は、口座データ１８、プレイデータ１９及び負担管理データ２０を含んでいてよい。プレイデータ１９は、各ユーザの過去のプレイ実績に関する情報が記述されたデータである。そして、プレイデータ１９は、例えば、前回までのプレイ結果（過去のプレイ状況）を次回以降に引き継ぐため、或いは各ユーザに固有の設定内容を引き継ぐために使用される。負担管理データ２０は、後述の対価対象の支払を負担するユーザを管理するためのデータである。プレイデータ１９及び負担管理データ２０の詳細は後述する。
【００１９】
また、口座データ１８は、各ユーザが保持する電子通貨の額（量）を管理するためのデータである。口座データ１８は、一例として、ユーザの認証（例えば、支払用のカードが存在する場合には、そのカードのカードＩＤ等、そのカードを特定するための情報の提供を含む）等を通じてプレイ料金の支払いに使用されてよい。また、口座データ１８によって管理される電子通貨の額、つまり各ユーザが保持する電子通貨の額は、例えば、システム運営者が運営するウェブサイト等を介してユーザによって増額（預入）されてよい。電子通貨の預入に対応したユーザへの課金は、例えば、クレジットカード等による決算手段を通じて別途行われてよい。或いは、このような預入のための専用の端末が用意されてもよい。この場合、現金等の各種の支払方法で預入が実行されてよい。なお、口座データ１８に対する電子通貨の預入及びその決済は、例えば、プリペイド型の電子通貨システムと同様でよく、その詳細の説明を省略する。
【００２０】
また、サーバ用データ１４は、その他にもゲームを実現するための各種のデータを含み得る。例えば、そのようなデータにはＩＤ管理データが含まれていてもよい。ＩＤ管理データは、ユーザＩＤ等の各種ＩＤを管理するためのデータである。しかし、それらの図示は省略した。
【００２１】
一方、ゲーム端末５には、コンピュータとしての制御ユニット３０と、記憶ユニット３１と、出力装置としてのモニタＭＯと、入力装置としてのタッチパネル７と、スピーカ８と、が設けられている。記憶ユニット３１、モニタＭＯ、タッチパネル７及びスピーカ８は、いずれも制御ユニット３０に接続されている。制御ユニット３０は、マイクロプロセッサと、そのマイクロプロセッサの動作に必要な内部記憶装置（一例としてＲＯＭ及びＲＡＭ）等の各種周辺装置とを組み合わせたコンピュータユニットとして構成されている。なお、制御ユニット３０には、例えば、その他にもゲームを提供するための各種の装置が接続され得る。しかし、それらの図示は省略した。
【００２２】
モニタＭＯは、制御ユニット３０からの出力信号に基づいて各種の画像等を表示するための周知の表示装置である。一例として、モニタＭＯは、制御ユニット３０からの出力信号に応じて、ゲームをプレイするためのゲーム画面を表示する。タッチパネル７は、ユーザが指等で触れると、その接触位置に応じた信号を出力する公知の入力装置である。タッチパネル７は、例えば、透明に構成され、モニタＭＯの表面に重ね合わされるように配置されてよい。例えば、タッチパネル７は、ユーザのタッチ操作に基づいてそのタッチ位置に対応する信号を制御ユニット３０に出力する。同様に、スピーカ８は、制御ユニット３０からの出力信号に基づいて各種の音声を再生するための周知の出力装置（音声再生装置）である。スピーカ８は、例えば、制御ユニット３０からの出力信号に応じて、ＢＧＭ等のゲームで使用される各種の音声を再生する。
【００２３】
一方、記憶ユニット３１は、電源の供給がなくても記憶を保持可能なように、例えば、磁気記録媒体や光記録媒体、フラッシュＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）などにより構成されてよい。記憶ユニット３１には、ゲームプログラム３４及びゲームデータ３５が記憶されている。ゲームプログラム３４は、ゲーム端末５がゲームを提供するために必要なコンピュータプログラムである。ゲームプログラム３４の実行に伴って、制御ユニット３０の内部には、ゲーム提供部３７が設けられる。ゲーム提供部３７は、ゲームを提供するために必要な各種処理を実行する。ゲーム提供部３７は、コンピュータハードウェアとコンピュータプログラムとの組み合わせにより実現される論理的装置である。なお、制御ユニット３０の内部には、その他にも各種の論理的装置が設けられ得る。しかし、それらの図示は省略した。
【００２４】
ゲームデータ３５は、ゲームプログラム３４の実行に伴って参照されるデータである。ゲームデータ３５は、例えば、プレイデータ１９及び負担管理データ２０を含んでいてよい。同様に、ゲームデータ３５は、例えば、上述のＩＤ管理データを含んでいてもよい。プレイデータ１９、負担管理データ２０、及びＩＤ管理データは、一例として、必要な部分が含まれるように、少なくとも一部がセンターサーバ２から提供されてよい。また、ゲームデータ３５は、その他にもゲームを実行するための各種のデータを含んでいてよい。例えば、そのようなデータには、画像データ及び効果音データが含まれてよい。画像データは、ゲームに必要な各種画像を表示するためのデータである。効果音データは、ＢＧＭ等、ゲームに必要な各種の音声を再生するためのデータである。しかし、それらの図示は省略した。
【００２５】
次に、ゲーム端末５が提供するゲームについて説明する。ゲーム端末５は、例えば、各種のゲームを提供してよい。また、それらの各種のゲームは、プレイデータ１９を使用して過去のプレイ実績を引き継ぐように次回のプレイが提供されてよい。つまり、ゲーム端末５は、前回までのプレイ状況を反映したゲーム範囲がプレイされるように次回のゲームを提供してよい。また、ゲーム範囲は、対価対象を含んでいてよい。対価対象は、例えば、所定の対価と関連付けられ、その所定の対価の徴収と引き換えに提供されてよい。つまり、ゲーム範囲は、所定の対価が徴収された場合に提供される部分（全体、つまりゲーム範囲自体を含む）を含んでいてよい。所定の対価は、例えば、上述の口座データ１８を通じて徴収されてよい。或いは、所定の対価の徴収には、クレジットカード等が使用されてもよい。つまり、事前或いは事後等、時期に関わらず対価対象の付与には対価の支払いが必要であってよい。例えば、所定の対価の徴収（支払）は、支払の意思表示によって実現され、実際の徴収は事後的に実行されてもよい。そして、そのような対価は、グループ単位で各ユーザから徴収されてよい。つまり、対価対象に対応する対価は、グループ単位で負担されてよい。
【００２６】
図３は、グループ単位で対価対象の対価が負担される場合の一例を説明するための説明図である。図３に示すように、例えば、ゲーム端末５は、グループ条件を満たす各ユーザＵを第１グループＵＧ１、第２グループＵＧ２といったグループＵＧに分類してよい。そして、そのグループＵＧの単位で対価対象の付与（提供）及びその対価対象に対応する対価の負担が実行されてよい。
【００２７】
具体的には、例えば、第１グループＵＧ１が第１ユーザＵ１及び第２ユーザＵ２を含む場合に、第１ユーザＵ１が所定の対価を負担する（支払う）一方で、その所定の対価に対応する対価対象は第２ユーザＵ２に付与されてもよい。つまり、グループＵＧ内において所定の対価を負担するユーザＵと、その所定の対価に対応する利益（対価対象）を受け取るユーザＵとは相違していてもよい。また、この場合、第１ユーザＵ１及び第２ユーザＵ２が本発明の複数のユーザとして機能してよい。より具体的には、第１ユーザＵ１及び第２ユーザＵ２が、それぞれ本発明の一のユーザ及び別のユーザとして機能してよい。
【００２８】
例えば、対価対象は、特定範囲のプレイ及びアイテムを含んでいてよい。特定範囲（ゲーム範囲全体を含む）は、所定の対価が徴収された場合に限定して提供されるゲーム範囲である。つまり、ゲーム範囲は、所定の対価が徴収されない限りプレイできない範囲を含んでいてよい。そして、このような特定範囲のプレイが対価対象として機能してよい。一方、アイテムは、ゲームを進行させるために選択的に使用されるゲーム要素である。アイテムは、例えば、ゲームのプレイ状況に応じて付与されてよい。そして、このようなアイテムが対価対象として機能してもよい。なお、対価対象には、例えば、ポイント（例えば、ゲーム内の仮想通貨的な機能を有する価値等のゲーム状況に応じて増減する価値）等、その他の各種のゲーム要素が含まれてよい。
【００２９】
また、対価対象は、例えば、第２ユーザＵ２から付与の要求があった場合に付与されてよい。つまり、第２ユーザＵ２からの付与の要求に伴い、第１ユーザＵ１はその要求に対応する対価対象を負担してよい。さらに、第１ユーザＵ１は、例えば、許容条件を満した（具備した）場合に限り、第２ユーザＵ２に付与される対価対象の対価を負担してよい。許容条件は、第２ユーザＵ２に付与される対価対象の対価の支払いを許容することを示す条件である。つまり、許容条件の具備は、例えば、同じグループＵＧに属する他のユーザＵ（例えば、第２ユーザＵ２）のための対価の支払いの許容として機能してよい。
【００３０】
許容条件は、例えば、第１ユーザＵ１の意思表示によって満たされてよい。また、意思表示は、意思表示の機会の付与によって実現されてよい。つまり、許容条件は、例えば、第１ユーザＵ１に付与された意思表示の機会（以下、許容機会と呼ぶことがある）において対価の支払い（負担）を許容する意思表示がされた場合に満たされてよい。また、許容機会は、対価対象の付与を要求する機会が第２ユーザＵ２に提供される前（事前）に付与されてもよいし、そのような機会が第２ユーザＵ２に提供された後（事後）に付与されてもよい。
【００３１】
図４及び図５を参照して、許容機会について更に説明する。図４は、事後的に付与される許容機会の一例を説明するための説明図である。図４に示すように、例えば、許容機会は、第２ユーザＵ２から対価対象の付与が要求された後に付与されてもよい。より具体的には、ゲーム端末５は、例えば、まず第２ユーザＵ２に対価対象の付与を要求する要求機会を付与してよい。続いて、ゲーム端末５は、その機会において第２ユーザＵ２から実際に対価対象の付与が要求された場合に第１ユーザＵ１にそれを通知してよい。また、ゲーム端末５は、その通知、つまり第２ユーザＵ２による対価対象の付与要求の通知の後に、或いはその通知と合わせて許容機会を提供してよい。
【００３２】
許容機会は、例えば、その要求を承認するか否か、つまりその要求を許容するか否か選択するための機会として構成されてよい。換言すれば、許容機会では、第２ユーザＵ２のための対価の支払いを許容するか否かの選択が実行されてよい。そして、第１ユーザＵ１が、その許容機会において第２ユーザＵ２のための対価の支払いを許容する選択をした場合にその対価を負担（支払い）してよい。つまり、一例として、許容機会において対価の支払いを許容する選択（意思表示）が実行された場合に許容条件が満たされ（具備され）、第２ユーザＵ２が付与を要求した対価対象に対応する対価を第１ユーザＵ１が負担（支払い）してよい。そして、第１ユーザＵ１による対価の負担（許容条件の具備）に伴い、第２ユーザＵ２に要求に対応する対価対象が付与されてよい（換言すれば、許容条件は、第１ユーザＵ１によって実際の支払いが実行された場合に満たされる支払条件を含み、この支払い条件が満たされたときに満たされてよい）。この場合、結果として対価対象の付与が要求される時期と実際にその対価対象が付与される時期との間には間隔（待ち期間）が生じてもよい。また、ゲーム端末５は、例えば、この待ち期間を保留期間として第２ユーザＵ２に通知してもよい。一例として、このように事後的に許容機会は付与されてよい。なお、許容機会における許容は、要求の全部に対して実行されてもよいし、一部に対して実行されてもよい。つまり、第２ユーザＵ２の要求はその全てがそのまま許容されてもよいし、その一部が適宜（例えば、第１ユーザＵ１の認定や要求の順番等）に許容されてもよい。
【００３３】
一方、図５は、事前に付与される許容機会の一例を説明するための説明図である。図５に示すように、例えば、第２ユーザＵ２によって対価対象の付与が要求される前、つまり事前に第１ユーザＵ１に許容範囲を設定する機会が提供されてよい。許容範囲は、第１ユーザＵ１が第２ユーザＵ２のために対価を負担できる範囲（負担範囲）である。つまり、許容範囲の設定を通じて第１ユーザＵ１によって予め負担可能な許容範囲が設定され、第２ユーザＵ２にはその許容範囲内において対価対象が付与されてよい。そして、その許容範囲を設定する機会が許容機会として機能してよい。
【００３４】
具体的には、ゲーム端末５は、例えば、まず第１ユーザＵ１に許容範囲を設定するための設定機会を提供してよい。この設定機会は、例えば、第１ユーザＵ１からの要求に応じて提供されてよい。また、この設定機会は、例えば、所定の対価の支払いを所定量許容する許容量を設定するように構成されてよい。つまり、ゲーム端末５は、まず許容範囲として許容量を設定するための設定機会を第１ユーザＵ１に提供してよい。そして、ゲーム端末５は、許容量が設定された場合には、その設定結果を反映するようにゲーム範囲に許容範囲を設定してよい。そして、第２ユーザＵ２から対価対象の付与が要求された場合には、ゲーム端末５はその許容量の範囲で対価対象を付与してよい。つまり、ゲーム端末５は、許容範囲に限定して第２ユーザＵ２の要求に応え、対価対象を付与してよい。また、これらの場合、第１ユーザＵ１は、第２ユーザＵ２から対価付与の要求がある毎にその対価を負担（支払い）してもよいし、許容量の設定に伴いその許容量に対応する対価を事前（対価付与の要求前）に負担（支払い）しておいてもよい。
【００３５】
一方、ゲーム端末５は、例えば、第２ユーザＵ２から許容範囲、つまり設定された許容量を超える要求があった場合には、対価対象の付与の要求を拒否してよい。つまり、ゲーム端末５は、許容範囲を超えて対価対象の付与が要求された場合には、超えた部分の対価の対象を付与しなくてよい。或いは、第２ユーザＵ２の要求が許容範囲を超えている場合には、修正可能な対象であれば許容範囲内への修正によりその第２ユーザＵ２の要求が許容されてもよい。つまり、第２ユーザＵ２の要求が許容範囲を超えている場合でも、許容範囲に限り認められ、付与されてもよい。このようにゲーム端末５は、設定機会の設定結果を反映するように、第２ユーザＵ２に対価対象が付与される範囲を対価が許容量を超えない範囲に制限してよい。
【００３６】
また、ゲーム端末５は、許容範囲が設定されていない場合にも、第２ユーザＵ２への対価対象の付与を拒否してよい。つまり、許容条件は許容範囲の設定の有無に関する設定条件及び許容範囲に関連する範囲条件を含み、設定条件及び範囲条件の両方が満たされた場合に満たされてもよい。具体的には、例えば、設定条件は許容範囲（許容量）が設定されている場合に満たされてよい。換言すれば、許容範囲が設定されていない場合には設定条件は満たされなくてよい。この場合、設定機会の許容量の設定が対価の支払いを許容する選択として機能してよい。つまり、許容量の設定を通じて対価の支払いを許容する選択（意思表示）が実現されてよい。そして、この設定機会が許容機会として機能してよい。
【００３７】
また、範囲条件は、例えば、第２ユーザＵ２の対価対象の付与の要求が許容範囲（許容量の範囲）内の場合に満たされてよい。換言すれば、第２ユーザＵ２の対価対象の付与の要求が許容範囲を超えている場合には満たされなくてよい。つまり、許容条件は、例えば、許容範囲が設定され、かつその範囲内で対価対象の付与が要求された場合に満たされてよい。一例として、このような設定機会を通じて事前に許容機会が付与されてよい。そして、そのような設定機会の設定結果及びその設定結果を反映する許容範囲を通じて許容条件の具備、不具備が判別されてよい。
【００３８】
なお、許容機会は、上述の形態に限定されない。例えば、事前の許容機会（設定機会等）及び事後の許容機会（承認の機会）が併用されてもよい。或いは、単に第１ユーザＵ１が第２ユーザＵ２のために対価対象を購入してもよい。つまり、第１ユーザＵ１が自己の意思で対価対象を選択し、かつその支払を負担してよい。一方で、その対価対象は第１ユーザＵ１ではなく第２ユーザＵ２に付与されてよい。つまり、対価対象の付与の要求及び負担が第１ユーザＵ１によって実行される一方で、実際の対価対象の付与は第２ユーザＵ２に実行されてもよい。
【００３９】
次に、ゲーム端末５が分類するグループＵＧの一例について説明する。上述の通り、ゲーム端末５は、例えば、グループ条件に基づいて各ユーザＵをグループＵＧに分類する。グループ条件は、例えば、プレイデータ１９に関連する関連条件を含んでいてよい。そして、グループ条件は、例えば、関連条件が満たされる場合に満たされてよい。
【００４０】
図６は、各ユーザＵによって形成されるグループＵＧの一例を説明するための説明図である。図６に示すように、例えば、ゲーム端末５は第１ゲーム端末５１〜第Ｎゲーム端末５Ｎを含み、ゲーム端末５毎にプレイデータ１９を生成してよい。そして、同じゲーム端末５に対応するプレイデータ１９が関連条件を満たしてよい。つまり、同じゲーム端末５に対応するプレイデータ１９を持つ各ユーザＵによってグループ条件が満たされ、これらのユーザＵによって各グループＵＧが形成されてよい。
【００４１】
具体的には、例えば、第１ユーザＵ１及び第２ユーザＵ２が第１ゲーム端末５１を通じてゲームをプレイした場合、第１ユーザＵ１に対応する第１Ａプレイデータ１９１Ａ及び第１Ｂプレイデータ１９１Ｂが生成される。また、これらの第１Ａプレイデータ１９１Ａ及び第１Ｂプレイデータ１９１Ｂは、いずれも同じ第１ゲーム端末５１に関連付けられる。そして、例えば、同じ第１ゲーム端末５１に関連付けられるプレイデータ１９が同じグループとして管理され、同じグループＵＧを形成してよい。つまり、同じ第１ゲーム端末５１に関連付けられる第１Ａプレイデータ１９１Ａ及び第１Ｂプレイデータ１９１Ｂによってグループ条件が満たされ、これらに対応する第１ユーザＵ１及び第２ユーザＵ２が第１グループＵＧ１を形成してよい。
【００４２】
第Ｎゲーム端末５Ｎに関しても同様である。つまり、第Ｎゲーム端末５Ｎを通じて第ＮＡユーザＵＮＡ及び第ＮＢユーザＵＮＢがゲームをプレイした場合には、同じ第Ｎゲーム端末５Ｎに関連付けられる第ＮＡプレイデータ１９ＮＡ及び第ＮＢプレイデータ１９ＮＢが生成されてよい。そして、例えば、同じ第Ｎゲーム端末５Ｎに関連付けられる第ＮＡプレイデータ１９ＮＡ及び第ＮＢプレイデータ１９ＮＢが同じ第Ｎグループとして管理され、これらに対応する第ＮＡユーザＵＮＡ及び第ＮＢユーザＵＮＢが第ＮグループＵＧＮを形成してよい。一例として、各ゲーム端末５は、このようなグループ条件に基づいて各ユーザＵをグループＵＧに分類してよい。
【００４３】
なお、グループ条件は、上述の形態に限定されない。グループ条件は、例えば、同じゲーム端末５を使用するユーザＵによって満たされてもよい。つまり、プレイデータ１９が作成されたゲーム端末５（過去にプレイしたゲーム端末５）に関わらず、現在ゲームをプレイするゲーム端末５が共通のユーザＵによってグループ条件が満たされてもよい。また、例えば、ＰＩＮコード等、各ゲーム端末５を特定するためのグループ情報がタッチパネル７を介してユーザＵから提供されるときには、このような情報がグループ条件の判別に使用されてよい。具体的には、例えば、共通のＰＩＮコードによってグループ条件が満たされる場合には、共通のＰＩＮコードを入力した各ユーザＵが共通のグループＵＧにグループ化されるように、このようなユーザＵがグループ条件を満たしてよい。或いは、例えば、ユーザＩＤ等により各グループＵＧに属する各ユーザＵが別途管理されている場合は、ユーザＩＤがグループ情報として機能してもよい。
【００４４】
また、グループ条件は、例えば、共通のアクセスポイント３ｂを使用するゲーム端末５、或いは共通のイントラネットを使用するゲーム端末５等の同一のローカルネットワーク（ネットワーク３の一部）内に存在する各ゲーム端末５によって満たされてもよい。若しくは、例えば、各ゲーム端末５がＧＰＳ情報を提供可能な場合には、各ゲーム端末５が所定の位置関係を形成する場合にそれらのゲーム端末５によってグループ条件が満たされてもよい。つまり、グループ条件は、各ゲーム端末５（或いは各ユーザＵ）の位置に関連する位置条件を含み、ＧＰＳ情報等の各ユーザＵの位置に関連する位置関連情報が各ゲーム端末５を介して取得された場合には、例えば、所定範囲内や近距離通信域内等、その位置関連情報に基づいて各ユーザＵが位置条件を満たす場合に満たされてもよい。
【００４５】
次に、プレイデータ１９を選択するためのデータ選択画面の一例について説明する。上述の通り、複数のユーザＵによって同じゲーム端末５が使用される場合がある。このため、ゲーム端末５は、例えば、モニタＭＯを通じて各ユーザＵに対応するプレイデータ１９を選択するためのデータ選択画面を表示してよい。
【００４６】
図７は、データ選択画面に一例を模式的に示す図である。図７に示すように、データ選択画面６０は、例えば、データ選択領域６１を含んでいてよい。データ選択領域６１は、ユーザＵ毎のプレイデータ１９を示す領域である。例えば、第１ゲーム端末５１に対応するデータ選択画面６０は、データ選択領域６１として、第１ユーザＵ１用の第１Ａプレイデータ１９１Ａに対応する第１データ選択領域６１Ａと、第２ユーザＵ２用の第１Ｂプレイデータ１９１Ｂに対応する第２データ選択領域６１Ｂと、を含んでいる。そして、第１データ選択領域６１Ａが選択された場合には第１Ａプレイデータ１９１Ａを使用するゲーム範囲が、第２データ選択領域６１Ｂが選択された場合には第１Ｂプレイデータ１９１Ｂを使用するゲーム範囲が、それぞれプレイ対象として提供される。さらに、このようなデータ選択画面６０を通じて選択され得る第１Ａプレイデータ１９１Ａ及び第１Ｂプレイデータ１９１Ｂによって関連条件が満たされてよい。
【００４７】
また、データ選択領域６１は、未使用データ選択領域６１Ｓを更に含んでいてもよい。未使用データ選択領域６１Ｓは、初回にゲームをプレイする場合に選択されるデータ選択領域６１である。つまり、未使用データ選択領域６１Ｓは、未だプレイデータ１９が存在しておらず、過去のプレイ状況（プレイ実績）が反映されないゲーム範囲をプレイする場合に選択されてよい。一例として、このようなデータ選択画面６０を通じて各ユーザＵ用のプレイデータ１９が選択されてよい。
【００４８】
次に、プレイデータ１９及び負担管理データ２０の詳細について説明する。プレイデータ１９は、上述の通り、過去の実績の引き継ぎ等を実現するためのデータである。図８は、プレイデータ１９の内容の一例を説明するための説明図である。図８に示すように、プレイデータ１９は、例えば、ユーザ識別情報としての“ユーザＩＤ”、プレイ情報としての“実績データ”、“属性データ”及び端末特定情報としての“端末ＩＤ”の情報を含んでいてよい。
【００４９】
“ユーザＩＤ”は、上述のユーザＩＤ（各ユーザを識別するためのＩＤ）の情報である。“属性データ”は、各ユーザＵの属性を示す情報である。“属性データ”は、例えば、“性別”、“年齢”等の情報を含んでいる。“性別”は各ユーザＵの性別を、“年齢”は各ユーザＵの年齢を、それぞれ示す情報である。“属性データ”は、例えば、その他にもユーザＵの名前や住所を示す情報（各種の個別情報等）を含んでいてよい。
【００５０】
“実績データ”は、過去のプレイ状況（プレイ実績）を示す情報である。“実績データ”は、例えば、過去の実績を次回以降のプレイにおいて引き継ぐために使用される。また、“実績データ”は、例えば、“ゲームＩＤ”、“アイテム”、“ポイント”、“成績”、“イベント”、“進行状況”、及び“プレイ日時”の情報を含んでいてよい。
【００５１】
“ゲームＩＤ”は、ゲーム毎にユニークなゲームＩＤを示す情報である。“ゲームＩＤ”の情報は、例えば、ゲーム端末５を通じて複数種類のゲームが提供される場合に、各ゲームを識別するために使用される。“アイテム”は、ゲームにおいて付与されたアイテムを示す情報である。“アイテム”として、アイテム毎にユニークなアイテムＩＤを示す情報が使用されてよい。つまり、“アイテム”として、各アイテムを識別するための情報が使用されてよい。具体的には、例えば、各ユーザＵが所有するアイテムに対応するアイテムＩＤの情報が“アイテム”の情報として記述されてよい。“ポイント”は、ポイントの残量を示す情報である。“成績”は、過去のゲームの成績を示す情報である。
【００５２】
また、“イベント”は、ゲームに含まれる各イベントを示す情報である。イベントは、達成に伴い特典が付与されるゲーム要素である。イベントは、例えば、達成条件が満たされた場合に達成されてよい。また、達成条件は、例えば、各種のミッション等の達成要件を含み、達成要件が実行された場合に満たされてよい。そして“イベント”として、例えば、イベント毎にユニークなイベントＩＤを示す情報が使用されてよい。つまり、“イベント”として、各イベントを識別するための情報が使用されてよい。より具体的には、例えば、“イベント”の情報として、現在実行中のイベントに対応するイベントＩＤの情報が記述されてよい。
【００５３】
“プレイ日時”はゲームをプレイした日時を示す情報である。また、“進行状況”は、ゲームの進行状況を示す情報である。“進行状況”は、イベントの進行状況（例えば、各達成要件の実行状況を含む）の情報を含んでいてよい。また、“進行状況”の情報は、例えば、前回までの進行状況の続きから次回のプレイを開始されるために使用されてよい。つまり、例えば、プレイデータ１９は“進行状況”の情報を含むことにより、いわゆるセーブデータとして機能してよい。
【００５４】
一方、“端末ＩＤ”は、ゲーム端末５毎にユニークな端末ＩＤを示す情報である。つまり、“端末ＩＤ”は、プレイデータ１９が関連付けられるゲーム端末５を識別するための情報である。“端末ＩＤ”の情報は、例えば、各ゲーム端末５を特定するために使用される。また、例えば、“端末ＩＤ”として、プレイデータ１９を初回に作成したゲーム端末５に対応する端末ＩＤの情報が記述されてよい。プレイデータ１９は、一例として、これらの情報が互いに関連付けられるように記述されたレコードの集合として構成されている。
【００５５】
一方、負担管理データ２０は、上述の通り、対価対象の支払を負担するユーザを管理するためのデータである。より具体的には、負担管理データ２０は、グループＵＧ内において対価対象の支払を負担するユーザＵ（例えば、第１ユーザＵ１）及びその負担により対価対象が付与されるユーザＵ（例えば、第２ユーザＵ２）を管理するためのデータである。負担管理データ２０は、例えば、グループＵＧが形成される場合、つまりグループＵＧに対応するグループ条件が満たされた場合（例えば、同じゲーム端末５に対応する異なるユーザＵのプレイデータ１９が生成された場合）に、そのグループＵＧの情報を含むように生成（更新）されてよい。
【００５６】
図９は、負担管理データ２０の内容の一例を説明するための説明図である。図９に示すように、負担管理データ２０は、例えば、“負担ユーザ”、“被負担ユーザ”、“許容量”、“要求対象”、“許容結果”及び“付与結果”の情報を含んでいてよい。“負担ユーザ”及び“被負担ユーザ”は、それぞれグループＵＧ内において対価対象の支払を負担するユーザＵ及びその負担により対価対象が付与されるユーザＵを示す情報である。例えば、“負担ユーザ”及び“被負担ユーザ”の情報として、ユーザＩＤの情報が使用されてよい。つまり、“負担ユーザ”及び“被負担ユーザ”として、例えば、対価対象の支払を負担するユーザＵのユーザＩＤを示す情報及びその負担により対価対象が付与されるユーザＵのユーザＩＤを示す情報がそれぞれ使用されてよい。
【００５７】
“許容量”は、設定機会において設定される許容量を示す情報である。“許容量”は、例えば、事前に許容機会が提供される場合に負担管理データ２０に含まれていてよい。また、“要求対象”は、“被負担ユーザ”から付与が要求された対価対象を示す情報である。“要求対象”として、例えば、対価対象毎にユニークなＩＤの情報が使用されてよい。例えば、対価対象がアイテムの場合には“要求対象”の情報としてアイテムＩＤが使用されてよい。或いは、対価対象が特定範囲のプレイの場合には、範囲毎にユニークなＩＤ等、特定範囲を特定するための情報が使用されてよい。同様に、“許容結果”は、“要求対象”に対応する対価の支払いを“負担ユーザ”が許容するか否かの結果を示す情報である。例えば、“許容結果”の情報として、許容の可（例えば、許容機会で負担が承認された場合）或いは不可（例えば、許容機会で負担が承認されなかった場合）をそれぞれ示すフラグが使用されてもよい。そして、“要求対象”及び“許容結果”は、例えば、事後的に許容機会が提供される場合に負担管理データ２０に含まれていてよい。
【００５８】
“付与結果”は、対価対象が“被負担ユーザ”に付与されたか否かを判別するための情報である。例えば、“付与結果”の情報として、付与の有無に対応するフラグの情報が使用されてよい。或いは、負担管理データ２０が“許容量”の情報を含む場合には、“付与結果”の情報として“要求対象”と同様に各対価対象を特定するための情報が使用されてもよい。そして、“付与結果”は、対価対象の付与に伴う残りの許容量を取得するために使用されてもよい。具体的には、例えば、“許容量”の情報を基準に“付与結果”の情報から残りの許容量が算出されてもよい。つまり、“許容量”及び“付与結果”は、範囲条件の判別に使用されてもよい。また、この場合、“付与結果”の情報は、各対価対象に関連付けられる対価の情報を含んでいてよい。若しくは、負担管理データ２０は、残りの許容量を示す情報を含んでいてもよい。負担管理データ２０は、一例として、これらの情報が互いに関連付けられるように記述されたレコードの集合として構成されている。なお、負担管理データ２０は、例えば、“許容量”、“要求対象”、“許容結果”及び“付与結果”の情報を含む場合には、設定機会、要求機会、及び許容機会がそれぞれ付与される毎にそれらの機会の結果を反映するように更新されてよい。
【００５９】
次に、機会提供処理及び対象付与処理について説明する。機会提供処理は、許容機会を提供するための処理である。また、対象付与処理は、負担ユーザＵ（例えば、第１ユーザＵ１）が所定の対価を負担する場合に、被負担ユーザＵ（例えば、第２ユーザＵ２）に対価対象を付与するための処理である。機会提供処理は図１０のルーチンを通じて、対価付与処理は図１１のルーチンを通じて、それぞれゲーム端末５の制御ユニット３０によって実現される。より具体的には、図１０及び図１１のルーチンは、一例として、制御ユニット３０のゲーム提供部３７を通じて実行されてよい。なお、ゲーム端末５の制御ユニット３０及びセンターサーバ２の制御ユニット１０は、この処理の他にも各種の周知な処理等を、それぞれ単独で或いは互いに協働して実行する。しかし、それらの詳細な説明は省略する。
【００６０】
図１０は、機会提供処理を実現するための機会提供処理ルーチンのフローチャートの一例を示す図である。図１０のルーチンは、例えば、機会条件が満たされる場合に実行されてよい。機会条件は、例えば、事前に負担ユーザＵから許容機会の提供の要求があった場合に満たされてよい。つまり、事前に許容機会を提供するために図１０のルーチンが実行されてもよい。或いは、機会条件は、被負担ユーザＵから対価対象の付与の要求があった場合に満たされてもよい。つまり、事後的に許容機会を提供するために図１０のルーチンが実行されてもよい。
【００６１】
図１０のルーチンが開始されると、ゲーム提供部３７は、まずステップＳ１１において対象のユーザＵ、つまり許容機会を提供すべき負担ユーザＵを特定する。例えば、負担ユーザＵから要求により機会条件が満たされた場合には、ゲーム提供部３７は、負担ユーザＵにユーザＩＤの提供（入力）を要求してもよい。そして、負担ユーザＵから提供されたユーザＩＤにより今回の対象のユーザＵを特定してもよい。或いは、被負担ユーザＵからの要求により機会条件が満たされた場合には、ゲーム提供部３７は、その要求内容に基づいてまず被負担ユーザＵのユーザＩＤを特定してよい。そして、その特定したユーザＩＤに基づいて負担管理データ２０を参照しつつ、そのユーザＩＤ（被負担ユーザＵ）に対応する負担ユーザＵを特定してよい。ゲーム提供部３７は、例えば、このようにステップＳ１１において対象のユーザＵを特定してよい。
【００６２】
続くステップＳ１２において、ゲーム提供部３７は、ステップＳ１１で特定したユーザＵに許容機会を提供して、今回のルーチンを終了する。これにより、被負担ユーザＵから対価対象の付与が要求される前（事前）、或いは要求された後（事後）に被負担ユーザＵのための対価の負担を許容するか否か選択する機会（許容機会）が負担ユーザＵに付与される。
【００６３】
一方、図１１は、対象付与処理を実現するための対象付与処理ルーチンのフローチャートの一例を示す図である。図１１のルーチンは、例えば、被負担ユーザＵから対価対象の付与が要求される毎に実行されてよい。
【００６４】
図１１のルーチンが開始されると、ゲーム提供部３７は、まずステップＳ２１において今回の対象のユーザＵを特定する。この特定は、例えば、ゲームのプレイに使用されたプレイデータ１９に基づいて実行されてもよい。或いは、プレイデータ１９の取得のために提供されたユーザＩＤに基づいて実行されてもよい。
【００６５】
続くステップＳ２２において、ゲーム提供部３７は、ステップＳ２１で特定したユーザＵに対応する負担ユーザＵを特定する。つまり、ゲーム提供部３７は、今回の対象のユーザＵが属するグループＵＧの各ユーザＵのうち、所定の対価の支払いを依頼すべきユーザＵを特定する。この特定は、例えば、負担管理データ２０に基づいて実現されてよい。
【００６６】
次のステップＳ２３において、ゲーム提供部３７は、ステップＳ２２で特定した負担ユーザＵに提供された許容機会の結果を取得する。具体的には、ゲーム提供部３７は、例えば、許容機会が事前に提供されている場合には、許容機会の結果として許容量の設定結果を取得してよい。或いは、ゲーム提供部３７は、例えば、許容機会が事後的に提供される場合には、許容機会の結果として許容機会において負担を許容するか否かの選択結果を取得してよい。
【００６７】
続くステップＳ２４において、ゲーム提供部３７は、ステップＳ２３の取得結果に基づいて許容条件が満たされるか否か判別する。許容条件は、例えば、上述の通りに満たされる。具体的には、例えば、許容機会が事前に提供されている場合には、許容条件は、許容量が設定されており、かつ今回の対価対象の要求がその許容量の残量の範囲内の場合に満たされてよい。つまり、許容条件は、設定条件及び範囲条件の両方が満たされる場合に満たされてよい。或いは、許容機会が事後的に提供される場合には、許容条件は、今回の対価対象の要求を許容（承認）する選択が実行された場合に満たされてよい。また、許容条件が支払条件を含む場合には、許容機会は対象の対価を支払う機会を含んでいてよい。この場合、ゲーム提供部３７は、そのような許容機会において支払いが実行されている場合に許容条件が満たされたと判別してよい。そして、この判別結果が否定的結果の場合、つまり許容条件が満たされない場合、ゲーム提供部３７は、以降の処理をスキップして、今回のルーチンを終了する。つまり、ゲーム提供部３７は、今回の要求を拒否する。この場合、ゲーム提供部３７は、今回の対象のユーザＵに付与の拒否を通知してもよい。
【００６８】
一方、ステップＳ２４の判別結果が肯定的結果の場合、つまり許容条件が満たされる場合、ゲーム提供部３７は、ステップＳ２５に進む。ステップＳ２５において、ゲーム提供部３７は、今回の要求対象の対価対象を対象のユーザＵ、つまり被負担ユーザＵに付与する。この場合、ゲーム提供部３７は、負担管理データ２０の“付与結果”の情報を更新してもよい。そして、ゲーム提供部３７はステップＳ２５の処理を終えると、今回のルーチンを終了する。これにより、許容条件を介して負担ユーザＵによって対価の負担が許容された場合に被負担ユーザＵに要求の対価対象が付与される。
【００６９】
以上に説明したように、この形態によれば、同じグループＵＧ内の負担ユーザＵが許容条件を介して被負担ユーザＵのための対価の支払いを許容した場合に、その被負担ユーザＵに対価に対応する対価対象が付与される。つまり、被負担ユーザＵへの対価対象の付与の前に許容条件を介して負担ユーザＵの支払許可が得られた場合に、被負担ユーザＵに対価対象が付与される。このため、被負担ユーザＵに対価対象が付与される場合でも、この対価対象が付与される被負担ユーザＵとは異なる負担ユーザＵにその対価対象の付与に対応する対価の支払いを請求することができる。結果として、例えば、対価対象の支払を行う権限がない被負担ユーザＵから対価対象の付与が要求された場合でも、対価対象の付与までの一連の流れをスムーズに実行することができる。
【００７０】
また、例えば、被負担ユーザＵから対価対象の付与が要求される毎に事後的に許容機会が提供される場合には、その要求毎に被負担ユーザＵの要求に対応する対価の支払いを許容するか否か判断する機会を与えることができる。一方で、例えば、許容量の設定を通じて事前に許容機会が提供される場合には、被負担ユーザＵのために支払を許容する範囲を設定する機会を被負担ユーザＵからの要求前に提供することができる。これにより、被負担ユーザＵから対価対象の付与が要求される毎に支払を許容するか否か判断するための負担ユーザＵの手間を省略することができる。
【００７１】
さらに、グループ条件が関連条件を含み、関連条件が同じゲーム端末５に対応するプレイデータ１９によって満たされる場合には、一台のゲーム端末５を共用する各ユーザＵをグループ化することができる。一台のゲーム端末５を物理的に共用する関係の各ユーザＵは、そもそも親しい間柄である可能性が高く、ゲーム以外においても情報交換がされる等、親密な関係を持つ可能性が高い。このため、このような親密な関係を持つ各ユーザＵをグループ化し、そのような各ユーザＵ間に負担ユーザＵ及び被負担ユーザＵの関係を構築させることができる。特に、親密な関係を持つ各ユーザＵ間においては、現実のコミュニケーションを通じて支払関係の問題も解消され易く、支払関係が問題にならない可能性も高い。同じゲーム端末５に対応する各ユーザＵをグループ化することにより、このような現実の親密な関係を対価対象の支払及び付与に反映することができる。
【００７２】
以上の形態において、ゲーム端末５の制御ユニット３０が、図１０のルーチンを実行することにより本発明の機会付与手段として機能する。同様に、ゲーム端末５の制御ユニット３０が、図１１のルーチンを実行することにより本発明のユーザ特定手段及び対価付与手段として機能する。一方、ゲーム端末５の記憶ユニット３１が、プレイデータ１９を記憶することにより本発明のデータ記憶装置として機能する。
【００７３】
本発明は上述の形態に限定されず、適宜の形態にて実施することができる。例えば、上述の形態では、一人の第１ユーザＵ１が負担ユーザＵとして機能している。しかし、本発明は、このような形態に限定されない。例えば、グループＵＧ内の複数のユーザＵが負担ユーザＵとして機能してもよい。同様に、グループＵＧ内の複数のユーザＵが被負担ユーザＵとして機能してもよい。
【００７４】
また、上述の形態では、負担ユーザＵが被負担ユーザＵのための対価を全て負担している。しかし、本発明は、このような形態に限定されない。例えば、負担ユーザＵが被負担ユーザＵのための対価の一部を負担してもよい。また、この負担部分は、例えば、負担ユーザＵ等の特定のユーザＵによって設定されてもよい。さらに、このような負担ユーザＵは、例えば、固定条件に基づいて固定的に設定されてもよい。つまり、負担ユーザＵは固定条件に基づいて固定されてもよい。例えば、固定条件は、関連条件が利用される場合には最初にプレイデータ１９を生成したユーザＵによって満たされてよい。つまり、同じゲーム端末５に関連付けられる複数のユーザＵが存在する場合に、それらのユーザＵのうちそのゲーム端末５に最初にプレイデータ１９を生成したユーザＵが固定条件を満たし、そのユーザＵが固定的に負担ユーザＵとして機能してもよい。或いは、固定条件は、特定のユーザＵ等、各ユーザＵによる設定（自己申請を含む）を要件に含んでよい。つまり、このような設定によって設定されたユーザＵが負担ユーザＵとして固定されてもよい。また、例えば、このような場合、負担ユーザＵ以外のユーザＵによる支払いは一切許可されなくてもよい。つまり、負担ユーザＵ以外のユーザＵによる支払い機能は完全に制限されてもよい。
【００７５】
上述の形態では、関連条件は同じゲーム端末５に関連付けられるプレイデータ１９によって満たされている。しかし、本発明は、このような形態に限定されない。例えば、同じゲーム端末５のうち、特定の関連が設定された各ユーザＵのプレイデータ１９によって関連条件が満たされてもよい。また、このような特定の関連は、特定のユーザＵ（例えば、負担ユーザＵ）によって予め設定されてもよい。つまり、関連条件は、更に特定のユーザＵによる設定結果を要件に含み、グループＵＧ内の関連が設定された限定的ユーザＵによって満たされてもよい。この場合、同じグループＵＧにグループ化される各ユーザＵを特定のユーザＵの設定に委ねることができる。これにより。特定のユーザＵの意思をグループ化に反映することができる。
【００７６】
また、上述の形態では、制御ユニット３０及び記憶ユニット３１がゲーム端末５に設けられている。しかし、本発明のゲーム端末５は、このような形態に限定されない。例えば、クラウドコンピューティングを利用してネットワーク上に論理的に制御ユニット３０及び記憶ユニット３１が設けられてもよい。つまり、ゲーム端末５は、ネットワーク３を通じて制御ユニット３０の処理結果を表示して提供する端末として構成されていてもよい。或いは、反対にゲーム端末５がセンターサーバ２として機能してもよい。
【００７７】
同様に、上述の形態では、機会提供処理及び対象付与処理はゲーム端末５の制御ユニット３０により単独で実行されている。したがって、センターサーバ２は省略され、一台のゲーム端末５だけによってゲームシステムが実現されてもよい。この場合、例えば、ゲーム端末５は事前にプレイデータ１９や負担管理データ２０をセンターサーバ２から取得していてもよい。一方で、本発明は、このような形態にも限定されない。例えば、上述の形態とは反対に、機会提供処理及び対象付与処理はゲーム端末５とセンターサーバ２との協働により実現されてもよい。
【００７８】
図１２は、結果送信処理を実現するための結果送信処理ルーチンのフローチャートの一例を示す図である。結果送信処理は、ゲーム端末５の機会提供処理及び対象付与処理と協働するためにセンターサーバ２が実行する処理である。図１２の例では、ゲーム提供部３７によって主として実行される処理がゲーム端末５として、Ｗｅｂサービス管理部１７によって主として実行される処理がセンターサーバ２として、それぞれ記述されている。また、図１０及び図１１のルーチンと共通する処理については共通の符号を付して説明を省略する。
【００７９】
図１２に示すように、図１０の処理と比較して図１２のルーチンでは、機会提供処理ルーチンにステップＳ１３が追加されている。具体的には、ゲーム端末５は、機会提供処理として、ステップＳ１２の処理に続くステップＳ１３において、ステップＳ１２で提供した許容機会の結果をセンターサーバ２に送信して、今回のルーチンを終了する。
【００８０】
そして、センターサーバ２は、ゲーム端末５から許容機会の結果を取得すると、図１２のルーチンを開始する。具体的には、図１２のルーチンを開始すると、センターサーバ２は、まずステップＳ３１においてゲーム端末５から許容機会の結果を取得する。続くステップＳ３２において、センターサーバ２は送信条件を満たすか否か判別する。送信条件は、例えば、被負担ユーザＵが使用するゲーム端末５がネットワーク３を介して接続された場合に満たされてよい。この判別結果が否定的結果の場合、つまり送信条件が満たされない場合には、センターサーバ２はステップＳ３２に再度戻り、送信条件が満たされるまで繰り返しステップＳ３２の処理を実行する。なお、センターサーバ２は、送信条件が所定期間内に満たされない場合は、以降の処理をスキップして、今回のルーチンを終了してもよい。また、この場合、許容機会の結果の提供が失敗したことを負担ユーザＵに通知してもよい。
【００８１】
一方、ステップＳ３２の判別結果が肯定的結果の場合、つまり送信条件が満たされる場合、センターサーバ２は許容機会の結果をゲーム端末５に提供して、今回のルーチンを終了する。そして、許容機会の結果を取得したゲーム端末５は、図１１と同様に対象付与処理を実行してよい。これにより、ゲーム端末５及びセンターサーバ２の協働により機会提供処理及び対象付与処理を実現することができる。結果として、例えば、同じゲーム端末５だけでなく異なるゲーム端末５を利用する各ユーザＵをグループ化することもできる。この場合、ステップＳ３１において取得される許容機会の結果が本発明の許容情報として機能してよい。そして、センターサーバ２の制御ユニット１０が、図１２のルーチンを実行することにより本発明の結果取得手段及び結果提供手段として機能してよい。
【００８２】
以下に、上述の内容から得られる本発明の一例を記載する。なお、以下の説明では本発明の理解を容易にするために添付図面の参照符号を括弧書きにて付記したが、それにより本発明が図示の形態に限定されるものではない。
【００８３】
本発明のゲームシステムは、所定の対価と関連付けられる対価対象を含むゲームを各ユーザ（Ｕ）に提供するゲームシステム（１）であって、グループ条件を満たす複数のユーザのうちの一のユーザ（Ｕ１）及び当該一のユーザとは別のユーザ（Ｕ２）を特定するユーザ特定手段（３０）と、前記一のユーザが前記別のユーザのための前記所定の対価の支払いを許容することを示す許容条件を満たす場合に、前記別のユーザに前記対価対象を付与する対価付与手段（３０）と、を備えている。
【００８４】
本発明によれば、グループ内の一のユーザが別のユーザのための対価の支払いを許容した場合に、その別のユーザに対価に対応する対価対象が付与される。つまり、別のユーザへの対価対象の付与の前に許容条件を介して一のユーザの支払許可が得られた場合に、別のユーザに対価対象が付与される。このため、別のユーザに対価対象が付与される場合でも、この対価対象が付与される別のユーザとは異なる一のユーザにその対価対象の付与に対応する所定の対価の支払いを請求することができる。結果として、対価対象の付与までの一連の流れをスムーズに実行することができる。
【００８５】
許容条件として、各種の態様が採用されてよい。例えば、本発明のゲームシステムの一態様として、前記別のユーザのための前記所定の対価の支払いを許容するか否か選択するための許容機会を前記一のユーザに付与する機会付与手段（３０）を更に備え、前記許容条件は、前記許容機会を通じた前記一のユーザによる前記所定の対価の支払いを許容する選択を要件に含んでいる態様が採用されてもよい。
【００８６】
また、許容機会が付与される態様において、前記機会付与手段は、前記別のユーザによって前記対価対象の付与が要求された場合に前記一のユーザに前記許容機会を付与し、前記許容条件は、前記許容機会を通じて前記一のユーザによって前記別のユーザの要求に対応する前記所定の対価の支払いを許容する選択が実行された場合に少なくとも満たされてもよい。この場合、別のユーザから対価対象の付与が要求される毎に、それに対応する対価の支払いを許容するか否か判断する機会を一のユーザに与えることができる。
【００８７】
或いは、許容機会が付与される態様において、前記許容機会は、前記所定の対価の支払いを予め所定量許容する許容量の設定を通じて前記別のユーザのための前記所定の対価の支払いを許容する選択が実行されるように構成され、前記許容条件は、前記許容量が設定された場合に満たされる設定条件及び前記別のユーザの要求が前記許容量の範囲内の場合に満たされる範囲条件を要件に含み、前記設定条件及び範囲条件の両方が満たされた場合に少なくとも満たされてもよい。この場合、別のユーザのために支払を許容する範囲を設定する機会を事前に一のユーザに提供することができる。これにより、別のユーザから対価対象の付与が要求される毎に支払を許容するか否か判断するための一のユーザの手間を省略することができる。
【００８８】
また、グループ条件として、各種の態様が採用されてよい。例えば、本発明のゲームシステムの一態様として、各ユーザの過去のプレイ状況を示すプレイ情報と各ユーザを識別するためのユーザ識別情報とが関連付けられるように記述されたプレイデータ（１９）を記憶するデータ記憶装置（３１）を更に備え、前記グループ条件は、前記プレイデータに関連する関連条件を含み、前記ユーザ識別情報を介して各ユーザに関連付けられる前記プレイデータが前記関連条件を満たす場合に少なくとも満たされる態様が採用されてもよい。或いは、前記グループ条件は、各ユーザの位置に関連する位置条件を含み、各ユーザが使用するユーザ端末（５）を介して各ユーザの位置に関連する位置関連情報が取得された場合に、当該位置関連情報に基づいて各ユーザが前記位置条件を満たす場合に少なくとも満たされてもよい。また、前記グループ条件は、グループを特定するためのグループ情報を入力するための入力装置（７）を介して各ユーザから前記グループ情報が提供された場合に、当該グループ情報に基づいて共通のグループに対応する前記グループ情報を入力した各ユーザによって満たされてもよい。
【００８９】
グループ条件が関連条件を含む態様において、前記ゲームを各ユーザに提供する少なくとも一つのゲーム端末（５）を含み、前記プレイデータは、前記プレイ情報が前記ゲーム端末を特定するための端末特定情報と更に関連付けられるように構成され、前記関連条件は、前記プレイデータが前記端末特定情報を介して同じゲーム端末に関連付けられる場合に満たされてもよい。或いは、前記端末特定情報は、前記ゲームを提供する複数のゲーム端末をそれぞれ識別可能に構成され、前記関連条件は、前記同じゲーム端末に対応する前記端末特定情報を含む前記プレイデータによって満たされてもよい。これらの場合、一つのゲーム端末を共用する各ユーザをグループ化することができる。特に、一つのゲーム端末を物理的に共用する関係の各ユーザは、そもそも親しい間柄である可能性が高く、ゲーム以外においても情報交換がされる等、親密な関係を持つ可能性が高い。このため、このような親密な関係を持つ各ユーザをグループ化することができる。結果として、現実の親密な関係を対価対象の支払及び付与の関係に反映することができる。
【００９０】
また、グループ条件が関連条件を含む態様において、前記関連条件は、特定のユーザ（Ｕ１）によって設定される設定結果を更に要件に含み、前記特定のユーザによって関連が設定された各ユーザの前記プレイデータによって満たされてもよい。この場合、グループ化される各ユーザを特定のユーザの設定に委ねることができる。これにより、特定のユーザの意思をグループ化に反映することができる。
【００９１】
一方、本発明のコンピュータプログラムは、前記ゲームを提供するための出力装置（ＭＯ）を備えたコンピュータ（３０）を、上述のゲームシステムの各手段として機能させるように構成されたものである。
【００９２】
また、本発明のサーバ装置は、上述のゲームシステムにネットワーク（３）を介して接続されるサーバ装置（２）であって、前記許容条件が満たされる場合に、当該許容条件が満たされることを示す許容情報を取得する結果取得手段（１０）と、前記許容条件が満たされる場合に、前記別のユーザに前記対価対象が付与されるように、前記許容情報を前記ゲームシステムに提供する結果提供手段（１０）と、を備えている。本発明のコンピュータプログラム或いはサーバ装置が実行されることにより、本発明のゲームシステムを実現することができる。
【符号の説明】
【００９３】
１  ゲームシステム
２  センターサーバ（サーバ装置）
３  ネットワーク
５  ゲーム端末（ユーザ端末）
１０  制御ユニット（結果取得手段、結果提供手段）
１９  プレイデータ
３０  制御ユニット（コンピュータ、ユーザ特定手段、対価付与手段、機会付与手段）
３１  記憶ユニット（データ記憶装置）
Ｕ  ユーザ
Ｕ１  第１ユーザ（一のユーザ）
Ｕ２  第２ユーザ（別のユーザ）
ＭＯ  モニタ（出力装置）
【図１】
0006565049.tif 000002
【図２】
0006565049.tif 000003
【図３】
0006565049.tif 000004
【図４】
0006565049.tif 000005
【図５】
0006565049.tif 000006
【図６】
0006565049.tif 000007
【図７】
0006565049.tif 000008
【図８】
0006565049.tif 000009
【図９】
0006565049.tif 000010
【図１０】
0006565049.tif 000011
【図１１】
0006565049.tif 000012
【図１２】
0006565049.tif 000013