以下、本発明の一形態に係るゲームシステムについて説明する。図1は、本発明の一形態に係るゲームシステムの全体構成の概要を示す図である。図1に示すように、ゲームシステム1は、サーバ装置としてのセンターサーバ2を含んでいる。センターサーバ2は、一台の物理的装置によって構成される例に限らない。例えば、複数の物理的装置としてのサーバ群によって一台の論理的なセンターサーバ2が構成されてもよい。また、クラウドコンピューティングを利用して論理的にセンターサーバ2が構成されてもよい。
センターサーバ2には、ネットワーク3を介して、ゲーム端末5が接続される。ゲーム端末5は、ユーザにゲームをプレイさせる機能(ゲーム機能)を備えたネットワーク端末装置の一種である。図1の例では、ゲーム端末5の一例として、携帯電話(スマートフォンを含む)が利用されている。携帯電話は、ユーザの個人用途に供されるユーザ端末の一種である。例えば、携帯電話は、センターサーバ2から配信されるソフトウェアを実行することにより、ゲーム機能を発揮してよい。ゲーム端末5として、例えば、その他にもパーソナルコンピュータ、携帯型ゲーム機、携帯型タブレット端末装置といった、ネットワーク接続が可能でかつユーザの個人用途に供される各種のネットワーク端末装置が利用されてよい。或いは、有料或いは無料で所定範囲のゲームをプレイさせる業務用(商業用)のゲーム機がゲーム端末5として使用されてもよい。
ネットワーク3は、一例として、TCP/IPプロトコルを利用してネットワーク通信を実現するように構成される。典型的には、WANとしてのインターネットと、LANとしてのイントラネットと、を組み合わせてネットワーク3が構成される。図1の例では、センターサーバ2はルータ3aを介して、ゲーム端末5はアクセスポイント3bを介して、それぞれネットワーク3に接続されている。
なお、ネットワーク3は、TCP/IPプロトコルを利用する形態に限定されない。ネットワーク3として、通信用の有線回線、或いは無線回線(赤外線通信、近距離無線通信等を含む)等を利用する各種の形態が利用されてよい。
センターサーバ2は、ネットワーク3を介してゲーム端末5のユーザに各種のWebサービスを提供する。Webサービスには、例えば、ゲーム端末5が提供するゲームに関する各種の情報を提供するゲーム用情報サービスが含まれてよい。また、例えば、Webサービスには、各ゲーム端末5に各種データ(ゲームで使用するアイテム、背景画像、音楽といったゲーム用のコンテンツを含む)或いはソフトウェアを配信(データ等のアップデートを含む)する配信サービスが含まれてもよい。さらに、Webサービスには、その他にもユーザによる情報発信、交換、共有といった交流の場を提供するコミュニティサービス、各ユーザを識別するためのユーザIDを付与するサービス、ネットワーク3を介して複数のユーザが共通のゲームをプレイする際にユーザ同士をマッチングするマッチングサービス等のサービスが含まれてよい。
次に、ゲームを提供するためのゲームシステム1の制御系の要部について説明する。図2は、ゲームシステム1の制御系の要部の構成を示す図である。図2に示すように、センターサーバ2は、制御ユニット10と、記憶ユニット11と、を備えている。制御ユニット10は、マイクロプロセッサと、そのマイクロプロセッサの動作に必要な内部記憶装置(一例としてROM及びRAM)等の各種周辺装置とを組み合わせたコンピュータユニットとして構成されている。なお、制御ユニット10には、キーボード等の入力装置、モニタ等の出力装置等が接続され得る。しかし、それらの図示は省略した。
記憶ユニット11は、制御ユニット10に接続されている。記憶ユニット11は、電源の供給がなくても記憶を保持可能なように、例えば、磁気テープ等の大容量記憶媒体により構成されている。記憶ユニット11には、サーバ用データ14及びサーバ用プログラム15が記憶されている。サーバ用プログラム15は、センターサーバ2がゲーム端末5に各種のサービスを提供するために必要なコンピュータプログラムである。制御ユニット10がサーバ用プログラム15を読み取って実行することにより、制御ユニット10の内部には、Webサービス管理部17が設けられる。
Webサービス管理部17は、上述のWebサービスを提供するために必要な処理を実行する。Webサービス管理部17は、コンピュータハードウェアとコンピュータプログラムとの組み合わせにより実現される論理的装置である。なお、制御ユニット10の内部には、その他にも各種の論理的装置が設けられ得る。しかし、それらの図示は省略した。
サーバ用データ14は、サーバ用プログラム15の実行に伴って参照されるデータである。例えば、サーバ用データ14は、口座データ18、プレイデータ19及び負担管理データ20を含んでいてよい。プレイデータ19は、各ユーザの過去のプレイ実績に関する情報が記述されたデータである。そして、プレイデータ19は、例えば、前回までのプレイ結果(過去のプレイ状況)を次回以降に引き継ぐため、或いは各ユーザに固有の設定内容を引き継ぐために使用される。負担管理データ20は、後述の対価対象の支払を負担するユーザを管理するためのデータである。プレイデータ19及び負担管理データ20の詳細は後述する。
また、口座データ18は、各ユーザが保持する電子通貨の額(量)を管理するためのデータである。口座データ18は、一例として、ユーザの認証(例えば、支払用のカードが存在する場合には、そのカードのカードID等、そのカードを特定するための情報の提供を含む)等を通じてプレイ料金の支払いに使用されてよい。また、口座データ18によって管理される電子通貨の額、つまり各ユーザが保持する電子通貨の額は、例えば、システム運営者が運営するウェブサイト等を介してユーザによって増額(預入)されてよい。電子通貨の預入に対応したユーザへの課金は、例えば、クレジットカード等による決算手段を通じて別途行われてよい。或いは、このような預入のための専用の端末が用意されてもよい。この場合、現金等の各種の支払方法で預入が実行されてよい。なお、口座データ18に対する電子通貨の預入及びその決済は、例えば、プリペイド型の電子通貨システムと同様でよく、その詳細の説明を省略する。
また、サーバ用データ14は、その他にもゲームを実現するための各種のデータを含み得る。例えば、そのようなデータにはID管理データが含まれていてもよい。ID管理データは、ユーザID等の各種IDを管理するためのデータである。しかし、それらの図示は省略した。
一方、ゲーム端末5には、コンピュータとしての制御ユニット30と、記憶ユニット31と、出力装置としてのモニタMOと、入力装置としてのタッチパネル7と、スピーカ8と、が設けられている。記憶ユニット31、モニタMO、タッチパネル7及びスピーカ8は、いずれも制御ユニット30に接続されている。制御ユニット30は、マイクロプロセッサと、そのマイクロプロセッサの動作に必要な内部記憶装置(一例としてROM及びRAM)等の各種周辺装置とを組み合わせたコンピュータユニットとして構成されている。なお、制御ユニット30には、例えば、その他にもゲームを提供するための各種の装置が接続され得る。しかし、それらの図示は省略した。
モニタMOは、制御ユニット30からの出力信号に基づいて各種の画像等を表示するための周知の表示装置である。一例として、モニタMOは、制御ユニット30からの出力信号に応じて、ゲームをプレイするためのゲーム画面を表示する。タッチパネル7は、ユーザが指等で触れると、その接触位置に応じた信号を出力する公知の入力装置である。タッチパネル7は、例えば、透明に構成され、モニタMOの表面に重ね合わされるように配置されてよい。例えば、タッチパネル7は、ユーザのタッチ操作に基づいてそのタッチ位置に対応する信号を制御ユニット30に出力する。同様に、スピーカ8は、制御ユニット30からの出力信号に基づいて各種の音声を再生するための周知の出力装置(音声再生装置)である。スピーカ8は、例えば、制御ユニット30からの出力信号に応じて、BGM等のゲームで使用される各種の音声を再生する。
一方、記憶ユニット31は、電源の供給がなくても記憶を保持可能なように、例えば、磁気記録媒体や光記録媒体、フラッシュSSD(Solid State Drive)などにより構成されてよい。記憶ユニット31には、ゲームプログラム34及びゲームデータ35が記憶されている。ゲームプログラム34は、ゲーム端末5がゲームを提供するために必要なコンピュータプログラムである。ゲームプログラム34の実行に伴って、制御ユニット30の内部には、ゲーム提供部37が設けられる。ゲーム提供部37は、ゲームを提供するために必要な各種処理を実行する。ゲーム提供部37は、コンピュータハードウェアとコンピュータプログラムとの組み合わせにより実現される論理的装置である。なお、制御ユニット30の内部には、その他にも各種の論理的装置が設けられ得る。しかし、それらの図示は省略した。
ゲームデータ35は、ゲームプログラム34の実行に伴って参照されるデータである。ゲームデータ35は、例えば、プレイデータ19及び負担管理データ20を含んでいてよい。同様に、ゲームデータ35は、例えば、上述のID管理データを含んでいてもよい。プレイデータ19、負担管理データ20、及びID管理データは、一例として、必要な部分が含まれるように、少なくとも一部がセンターサーバ2から提供されてよい。また、ゲームデータ35は、その他にもゲームを実行するための各種のデータを含んでいてよい。例えば、そのようなデータには、画像データ及び効果音データが含まれてよい。画像データは、ゲームに必要な各種画像を表示するためのデータである。効果音データは、BGM等、ゲームに必要な各種の音声を再生するためのデータである。しかし、それらの図示は省略した。
次に、ゲーム端末5が提供するゲームについて説明する。ゲーム端末5は、例えば、各種のゲームを提供してよい。また、それらの各種のゲームは、プレイデータ19を使用して過去のプレイ実績を引き継ぐように次回のプレイが提供されてよい。つまり、ゲーム端末5は、前回までのプレイ状況を反映したゲーム範囲がプレイされるように次回のゲームを提供してよい。また、ゲーム範囲は、対価対象を含んでいてよい。対価対象は、例えば、所定の対価と関連付けられ、その所定の対価の徴収と引き換えに提供されてよい。つまり、ゲーム範囲は、所定の対価が徴収された場合に提供される部分(全体、つまりゲーム範囲自体を含む)を含んでいてよい。所定の対価は、例えば、上述の口座データ18を通じて徴収されてよい。或いは、所定の対価の徴収には、クレジットカード等が使用されてもよい。つまり、事前或いは事後等、時期に関わらず対価対象の付与には対価の支払いが必要であってよい。例えば、所定の対価の徴収(支払)は、支払の意思表示によって実現され、実際の徴収は事後的に実行されてもよい。そして、そのような対価は、グループ単位で各ユーザから徴収されてよい。つまり、対価対象に対応する対価は、グループ単位で負担されてよい。
図3は、グループ単位で対価対象の対価が負担される場合の一例を説明するための説明図である。図3に示すように、例えば、ゲーム端末5は、グループ条件を満たす各ユーザUを第1グループUG1、第2グループUG2といったグループUGに分類してよい。そして、そのグループUGの単位で対価対象の付与(提供)及びその対価対象に対応する対価の負担が実行されてよい。
具体的には、例えば、第1グループUG1が第1ユーザU1及び第2ユーザU2を含む場合に、第1ユーザU1が所定の対価を負担する(支払う)一方で、その所定の対価に対応する対価対象は第2ユーザU2に付与されてもよい。つまり、グループUG内において所定の対価を負担するユーザUと、その所定の対価に対応する利益(対価対象)を受け取るユーザUとは相違していてもよい。また、この場合、第1ユーザU1及び第2ユーザU2が本発明の複数のユーザとして機能してよい。より具体的には、第1ユーザU1及び第2ユーザU2が、それぞれ本発明の一のユーザ及び別のユーザとして機能してよい。
例えば、対価対象は、特定範囲のプレイ及びアイテムを含んでいてよい。特定範囲(ゲーム範囲全体を含む)は、所定の対価が徴収された場合に限定して提供されるゲーム範囲である。つまり、ゲーム範囲は、所定の対価が徴収されない限りプレイできない範囲を含んでいてよい。そして、このような特定範囲のプレイが対価対象として機能してよい。一方、アイテムは、ゲームを進行させるために選択的に使用されるゲーム要素である。アイテムは、例えば、ゲームのプレイ状況に応じて付与されてよい。そして、このようなアイテムが対価対象として機能してもよい。なお、対価対象には、例えば、ポイント(例えば、ゲーム内の仮想通貨的な機能を有する価値等のゲーム状況に応じて増減する価値)等、その他の各種のゲーム要素が含まれてよい。
また、対価対象は、例えば、第2ユーザU2から付与の要求があった場合に付与されてよい。つまり、第2ユーザU2からの付与の要求に伴い、第1ユーザU1はその要求に対応する対価対象を負担してよい。さらに、第1ユーザU1は、例えば、許容条件を満した(具備した)場合に限り、第2ユーザU2に付与される対価対象の対価を負担してよい。許容条件は、第2ユーザU2に付与される対価対象の対価の支払いを許容することを示す条件である。つまり、許容条件の具備は、例えば、同じグループUGに属する他のユーザU(例えば、第2ユーザU2)のための対価の支払いの許容として機能してよい。
許容条件は、例えば、第1ユーザU1の意思表示によって満たされてよい。また、意思表示は、意思表示の機会の付与によって実現されてよい。つまり、許容条件は、例えば、第1ユーザU1に付与された意思表示の機会(以下、許容機会と呼ぶことがある)において対価の支払い(負担)を許容する意思表示がされた場合に満たされてよい。また、許容機会は、対価対象の付与を要求する機会が第2ユーザU2に提供される前(事前)に付与されてもよいし、そのような機会が第2ユーザU2に提供された後(事後)に付与されてもよい。
図4及び図5を参照して、許容機会について更に説明する。図4は、事後的に付与される許容機会の一例を説明するための説明図である。図4に示すように、例えば、許容機会は、第2ユーザU2から対価対象の付与が要求された後に付与されてもよい。より具体的には、ゲーム端末5は、例えば、まず第2ユーザU2に対価対象の付与を要求する要求機会を付与してよい。続いて、ゲーム端末5は、その機会において第2ユーザU2から実際に対価対象の付与が要求された場合に第1ユーザU1にそれを通知してよい。また、ゲーム端末5は、その通知、つまり第2ユーザU2による対価対象の付与要求の通知の後に、或いはその通知と合わせて許容機会を提供してよい。
許容機会は、例えば、その要求を承認するか否か、つまりその要求を許容するか否か選択するための機会として構成されてよい。換言すれば、許容機会では、第2ユーザU2のための対価の支払いを許容するか否かの選択が実行されてよい。そして、第1ユーザU1が、その許容機会において第2ユーザU2のための対価の支払いを許容する選択をした場合にその対価を負担(支払い)してよい。つまり、一例として、許容機会において対価の支払いを許容する選択(意思表示)が実行された場合に許容条件が満たされ(具備され)、第2ユーザU2が付与を要求した対価対象に対応する対価を第1ユーザU1が負担(支払い)してよい。そして、第1ユーザU1による対価の負担(許容条件の具備)に伴い、第2ユーザU2に要求に対応する対価対象が付与されてよい(換言すれば、許容条件は、第1ユーザU1によって実際の支払いが実行された場合に満たされる支払条件を含み、この支払い条件が満たされたときに満たされてよい)。この場合、結果として対価対象の付与が要求される時期と実際にその対価対象が付与される時期との間には間隔(待ち期間)が生じてもよい。また、ゲーム端末5は、例えば、この待ち期間を保留期間として第2ユーザU2に通知してもよい。一例として、このように事後的に許容機会は付与されてよい。なお、許容機会における許容は、要求の全部に対して実行されてもよいし、一部に対して実行されてもよい。つまり、第2ユーザU2の要求はその全てがそのまま許容されてもよいし、その一部が適宜(例えば、第1ユーザU1の認定や要求の順番等)に許容されてもよい。
一方、図5は、事前に付与される許容機会の一例を説明するための説明図である。図5に示すように、例えば、第2ユーザU2によって対価対象の付与が要求される前、つまり事前に第1ユーザU1に許容範囲を設定する機会が提供されてよい。許容範囲は、第1ユーザU1が第2ユーザU2のために対価を負担できる範囲(負担範囲)である。つまり、許容範囲の設定を通じて第1ユーザU1によって予め負担可能な許容範囲が設定され、第2ユーザU2にはその許容範囲内において対価対象が付与されてよい。そして、その許容範囲を設定する機会が許容機会として機能してよい。
具体的には、ゲーム端末5は、例えば、まず第1ユーザU1に許容範囲を設定するための設定機会を提供してよい。この設定機会は、例えば、第1ユーザU1からの要求に応じて提供されてよい。また、この設定機会は、例えば、所定の対価の支払いを所定量許容する許容量を設定するように構成されてよい。つまり、ゲーム端末5は、まず許容範囲として許容量を設定するための設定機会を第1ユーザU1に提供してよい。そして、ゲーム端末5は、許容量が設定された場合には、その設定結果を反映するようにゲーム範囲に許容範囲を設定してよい。そして、第2ユーザU2から対価対象の付与が要求された場合には、ゲーム端末5はその許容量の範囲で対価対象を付与してよい。つまり、ゲーム端末5は、許容範囲に限定して第2ユーザU2の要求に応え、対価対象を付与してよい。また、これらの場合、第1ユーザU1は、第2ユーザU2から対価付与の要求がある毎にその対価を負担(支払い)してもよいし、許容量の設定に伴いその許容量に対応する対価を事前(対価付与の要求前)に負担(支払い)しておいてもよい。
一方、ゲーム端末5は、例えば、第2ユーザU2から許容範囲、つまり設定された許容量を超える要求があった場合には、対価対象の付与の要求を拒否してよい。つまり、ゲーム端末5は、許容範囲を超えて対価対象の付与が要求された場合には、超えた部分の対価の対象を付与しなくてよい。或いは、第2ユーザU2の要求が許容範囲を超えている場合には、修正可能な対象であれば許容範囲内への修正によりその第2ユーザU2の要求が許容されてもよい。つまり、第2ユーザU2の要求が許容範囲を超えている場合でも、許容範囲に限り認められ、付与されてもよい。このようにゲーム端末5は、設定機会の設定結果を反映するように、第2ユーザU2に対価対象が付与される範囲を対価が許容量を超えない範囲に制限してよい。
また、ゲーム端末5は、許容範囲が設定されていない場合にも、第2ユーザU2への対価対象の付与を拒否してよい。つまり、許容条件は許容範囲の設定の有無に関する設定条件及び許容範囲に関連する範囲条件を含み、設定条件及び範囲条件の両方が満たされた場合に満たされてもよい。具体的には、例えば、設定条件は許容範囲(許容量)が設定されている場合に満たされてよい。換言すれば、許容範囲が設定されていない場合には設定条件は満たされなくてよい。この場合、設定機会の許容量の設定が対価の支払いを許容する選択として機能してよい。つまり、許容量の設定を通じて対価の支払いを許容する選択(意思表示)が実現されてよい。そして、この設定機会が許容機会として機能してよい。
また、範囲条件は、例えば、第2ユーザU2の対価対象の付与の要求が許容範囲(許容量の範囲)内の場合に満たされてよい。換言すれば、第2ユーザU2の対価対象の付与の要求が許容範囲を超えている場合には満たされなくてよい。つまり、許容条件は、例えば、許容範囲が設定され、かつその範囲内で対価対象の付与が要求された場合に満たされてよい。一例として、このような設定機会を通じて事前に許容機会が付与されてよい。そして、そのような設定機会の設定結果及びその設定結果を反映する許容範囲を通じて許容条件の具備、不具備が判別されてよい。
なお、許容機会は、上述の形態に限定されない。例えば、事前の許容機会(設定機会等)及び事後の許容機会(承認の機会)が併用されてもよい。或いは、単に第1ユーザU1が第2ユーザU2のために対価対象を購入してもよい。つまり、第1ユーザU1が自己の意思で対価対象を選択し、かつその支払を負担してよい。一方で、その対価対象は第1ユーザU1ではなく第2ユーザU2に付与されてよい。つまり、対価対象の付与の要求及び負担が第1ユーザU1によって実行される一方で、実際の対価対象の付与は第2ユーザU2に実行されてもよい。
次に、ゲーム端末5が分類するグループUGの一例について説明する。上述の通り、ゲーム端末5は、例えば、グループ条件に基づいて各ユーザUをグループUGに分類する。グループ条件は、例えば、プレイデータ19に関連する関連条件を含んでいてよい。そして、グループ条件は、例えば、関連条件が満たされる場合に満たされてよい。
図6は、各ユーザUによって形成されるグループUGの一例を説明するための説明図である。図6に示すように、例えば、ゲーム端末5は第1ゲーム端末51〜第Nゲーム端末5Nを含み、ゲーム端末5毎にプレイデータ19を生成してよい。そして、同じゲーム端末5に対応するプレイデータ19が関連条件を満たしてよい。つまり、同じゲーム端末5に対応するプレイデータ19を持つ各ユーザUによってグループ条件が満たされ、これらのユーザUによって各グループUGが形成されてよい。
具体的には、例えば、第1ユーザU1及び第2ユーザU2が第1ゲーム端末51を通じてゲームをプレイした場合、第1ユーザU1に対応する第1Aプレイデータ191A及び第1Bプレイデータ191Bが生成される。また、これらの第1Aプレイデータ191A及び第1Bプレイデータ191Bは、いずれも同じ第1ゲーム端末51に関連付けられる。そして、例えば、同じ第1ゲーム端末51に関連付けられるプレイデータ19が同じグループとして管理され、同じグループUGを形成してよい。つまり、同じ第1ゲーム端末51に関連付けられる第1Aプレイデータ191A及び第1Bプレイデータ191Bによってグループ条件が満たされ、これらに対応する第1ユーザU1及び第2ユーザU2が第1グループUG1を形成してよい。
第Nゲーム端末5Nに関しても同様である。つまり、第Nゲーム端末5Nを通じて第NAユーザUNA及び第NBユーザUNBがゲームをプレイした場合には、同じ第Nゲーム端末5Nに関連付けられる第NAプレイデータ19NA及び第NBプレイデータ19NBが生成されてよい。そして、例えば、同じ第Nゲーム端末5Nに関連付けられる第NAプレイデータ19NA及び第NBプレイデータ19NBが同じ第Nグループとして管理され、これらに対応する第NAユーザUNA及び第NBユーザUNBが第NグループUGNを形成してよい。一例として、各ゲーム端末5は、このようなグループ条件に基づいて各ユーザUをグループUGに分類してよい。
なお、グループ条件は、上述の形態に限定されない。グループ条件は、例えば、同じゲーム端末5を使用するユーザUによって満たされてもよい。つまり、プレイデータ19が作成されたゲーム端末5(過去にプレイしたゲーム端末5)に関わらず、現在ゲームをプレイするゲーム端末5が共通のユーザUによってグループ条件が満たされてもよい。また、例えば、PINコード等、各ゲーム端末5を特定するためのグループ情報がタッチパネル7を介してユーザUから提供されるときには、このような情報がグループ条件の判別に使用されてよい。具体的には、例えば、共通のPINコードによってグループ条件が満たされる場合には、共通のPINコードを入力した各ユーザUが共通のグループUGにグループ化されるように、このようなユーザUがグループ条件を満たしてよい。或いは、例えば、ユーザID等により各グループUGに属する各ユーザUが別途管理されている場合は、ユーザIDがグループ情報として機能してもよい。
また、グループ条件は、例えば、共通のアクセスポイント3bを使用するゲーム端末5、或いは共通のイントラネットを使用するゲーム端末5等の同一のローカルネットワーク(ネットワーク3の一部)内に存在する各ゲーム端末5によって満たされてもよい。若しくは、例えば、各ゲーム端末5がGPS情報を提供可能な場合には、各ゲーム端末5が所定の位置関係を形成する場合にそれらのゲーム端末5によってグループ条件が満たされてもよい。つまり、グループ条件は、各ゲーム端末5(或いは各ユーザU)の位置に関連する位置条件を含み、GPS情報等の各ユーザUの位置に関連する位置関連情報が各ゲーム端末5を介して取得された場合には、例えば、所定範囲内や近距離通信域内等、その位置関連情報に基づいて各ユーザUが位置条件を満たす場合に満たされてもよい。
次に、プレイデータ19を選択するためのデータ選択画面の一例について説明する。上述の通り、複数のユーザUによって同じゲーム端末5が使用される場合がある。このため、ゲーム端末5は、例えば、モニタMOを通じて各ユーザUに対応するプレイデータ19を選択するためのデータ選択画面を表示してよい。
図7は、データ選択画面に一例を模式的に示す図である。図7に示すように、データ選択画面60は、例えば、データ選択領域61を含んでいてよい。データ選択領域61は、ユーザU毎のプレイデータ19を示す領域である。例えば、第1ゲーム端末51に対応するデータ選択画面60は、データ選択領域61として、第1ユーザU1用の第1Aプレイデータ191Aに対応する第1データ選択領域61Aと、第2ユーザU2用の第1Bプレイデータ191Bに対応する第2データ選択領域61Bと、を含んでいる。そして、第1データ選択領域61Aが選択された場合には第1Aプレイデータ191Aを使用するゲーム範囲が、第2データ選択領域61Bが選択された場合には第1Bプレイデータ191Bを使用するゲーム範囲が、それぞれプレイ対象として提供される。さらに、このようなデータ選択画面60を通じて選択され得る第1Aプレイデータ191A及び第1Bプレイデータ191Bによって関連条件が満たされてよい。
また、データ選択領域61は、未使用データ選択領域61Sを更に含んでいてもよい。未使用データ選択領域61Sは、初回にゲームをプレイする場合に選択されるデータ選択領域61である。つまり、未使用データ選択領域61Sは、未だプレイデータ19が存在しておらず、過去のプレイ状況(プレイ実績)が反映されないゲーム範囲をプレイする場合に選択されてよい。一例として、このようなデータ選択画面60を通じて各ユーザU用のプレイデータ19が選択されてよい。
次に、プレイデータ19及び負担管理データ20の詳細について説明する。プレイデータ19は、上述の通り、過去の実績の引き継ぎ等を実現するためのデータである。図8は、プレイデータ19の内容の一例を説明するための説明図である。図8に示すように、プレイデータ19は、例えば、ユーザ識別情報としての“ユーザID”、プレイ情報としての“実績データ”、“属性データ”及び端末特定情報としての“端末ID”の情報を含んでいてよい。
“ユーザID”は、上述のユーザID(各ユーザを識別するためのID)の情報である。“属性データ”は、各ユーザUの属性を示す情報である。“属性データ”は、例えば、“性別”、“年齢”等の情報を含んでいる。“性別”は各ユーザUの性別を、“年齢”は各ユーザUの年齢を、それぞれ示す情報である。“属性データ”は、例えば、その他にもユーザUの名前や住所を示す情報(各種の個別情報等)を含んでいてよい。
“実績データ”は、過去のプレイ状況(プレイ実績)を示す情報である。“実績データ”は、例えば、過去の実績を次回以降のプレイにおいて引き継ぐために使用される。また、“実績データ”は、例えば、“ゲームID”、“アイテム”、“ポイント”、“成績”、“イベント”、“進行状況”、及び“プレイ日時”の情報を含んでいてよい。
“ゲームID”は、ゲーム毎にユニークなゲームIDを示す情報である。“ゲームID”の情報は、例えば、ゲーム端末5を通じて複数種類のゲームが提供される場合に、各ゲームを識別するために使用される。“アイテム”は、ゲームにおいて付与されたアイテムを示す情報である。“アイテム”として、アイテム毎にユニークなアイテムIDを示す情報が使用されてよい。つまり、“アイテム”として、各アイテムを識別するための情報が使用されてよい。具体的には、例えば、各ユーザUが所有するアイテムに対応するアイテムIDの情報が“アイテム”の情報として記述されてよい。“ポイント”は、ポイントの残量を示す情報である。“成績”は、過去のゲームの成績を示す情報である。
また、“イベント”は、ゲームに含まれる各イベントを示す情報である。イベントは、達成に伴い特典が付与されるゲーム要素である。イベントは、例えば、達成条件が満たされた場合に達成されてよい。また、達成条件は、例えば、各種のミッション等の達成要件を含み、達成要件が実行された場合に満たされてよい。そして“イベント”として、例えば、イベント毎にユニークなイベントIDを示す情報が使用されてよい。つまり、“イベント”として、各イベントを識別するための情報が使用されてよい。より具体的には、例えば、“イベント”の情報として、現在実行中のイベントに対応するイベントIDの情報が記述されてよい。
“プレイ日時”はゲームをプレイした日時を示す情報である。また、“進行状況”は、ゲームの進行状況を示す情報である。“進行状況”は、イベントの進行状況(例えば、各達成要件の実行状況を含む)の情報を含んでいてよい。また、“進行状況”の情報は、例えば、前回までの進行状況の続きから次回のプレイを開始されるために使用されてよい。つまり、例えば、プレイデータ19は“進行状況”の情報を含むことにより、いわゆるセーブデータとして機能してよい。
一方、“端末ID”は、ゲーム端末5毎にユニークな端末IDを示す情報である。つまり、“端末ID”は、プレイデータ19が関連付けられるゲーム端末5を識別するための情報である。“端末ID”の情報は、例えば、各ゲーム端末5を特定するために使用される。また、例えば、“端末ID”として、プレイデータ19を初回に作成したゲーム端末5に対応する端末IDの情報が記述されてよい。プレイデータ19は、一例として、これらの情報が互いに関連付けられるように記述されたレコードの集合として構成されている。
一方、負担管理データ20は、上述の通り、対価対象の支払を負担するユーザを管理するためのデータである。より具体的には、負担管理データ20は、グループUG内において対価対象の支払を負担するユーザU(例えば、第1ユーザU1)及びその負担により対価対象が付与されるユーザU(例えば、第2ユーザU2)を管理するためのデータである。負担管理データ20は、例えば、グループUGが形成される場合、つまりグループUGに対応するグループ条件が満たされた場合(例えば、同じゲーム端末5に対応する異なるユーザUのプレイデータ19が生成された場合)に、そのグループUGの情報を含むように生成(更新)されてよい。
図9は、負担管理データ20の内容の一例を説明するための説明図である。図9に示すように、負担管理データ20は、例えば、“負担ユーザ”、“被負担ユーザ”、“許容量”、“要求対象”、“許容結果”及び“付与結果”の情報を含んでいてよい。“負担ユーザ”及び“被負担ユーザ”は、それぞれグループUG内において対価対象の支払を負担するユーザU及びその負担により対価対象が付与されるユーザUを示す情報である。例えば、“負担ユーザ”及び“被負担ユーザ”の情報として、ユーザIDの情報が使用されてよい。つまり、“負担ユーザ”及び“被負担ユーザ”として、例えば、対価対象の支払を負担するユーザUのユーザIDを示す情報及びその負担により対価対象が付与されるユーザUのユーザIDを示す情報がそれぞれ使用されてよい。
“許容量”は、設定機会において設定される許容量を示す情報である。“許容量”は、例えば、事前に許容機会が提供される場合に負担管理データ20に含まれていてよい。また、“要求対象”は、“被負担ユーザ”から付与が要求された対価対象を示す情報である。“要求対象”として、例えば、対価対象毎にユニークなIDの情報が使用されてよい。例えば、対価対象がアイテムの場合には“要求対象”の情報としてアイテムIDが使用されてよい。或いは、対価対象が特定範囲のプレイの場合には、範囲毎にユニークなID等、特定範囲を特定するための情報が使用されてよい。同様に、“許容結果”は、“要求対象”に対応する対価の支払いを“負担ユーザ”が許容するか否かの結果を示す情報である。例えば、“許容結果”の情報として、許容の可(例えば、許容機会で負担が承認された場合)或いは不可(例えば、許容機会で負担が承認されなかった場合)をそれぞれ示すフラグが使用されてもよい。そして、“要求対象”及び“許容結果”は、例えば、事後的に許容機会が提供される場合に負担管理データ20に含まれていてよい。
“付与結果”は、対価対象が“被負担ユーザ”に付与されたか否かを判別するための情報である。例えば、“付与結果”の情報として、付与の有無に対応するフラグの情報が使用されてよい。或いは、負担管理データ20が“許容量”の情報を含む場合には、“付与結果”の情報として“要求対象”と同様に各対価対象を特定するための情報が使用されてもよい。そして、“付与結果”は、対価対象の付与に伴う残りの許容量を取得するために使用されてもよい。具体的には、例えば、“許容量”の情報を基準に“付与結果”の情報から残りの許容量が算出されてもよい。つまり、“許容量”及び“付与結果”は、範囲条件の判別に使用されてもよい。また、この場合、“付与結果”の情報は、各対価対象に関連付けられる対価の情報を含んでいてよい。若しくは、負担管理データ20は、残りの許容量を示す情報を含んでいてもよい。負担管理データ20は、一例として、これらの情報が互いに関連付けられるように記述されたレコードの集合として構成されている。なお、負担管理データ20は、例えば、“許容量”、“要求対象”、“許容結果”及び“付与結果”の情報を含む場合には、設定機会、要求機会、及び許容機会がそれぞれ付与される毎にそれらの機会の結果を反映するように更新されてよい。
次に、機会提供処理及び対象付与処理について説明する。機会提供処理は、許容機会を提供するための処理である。また、対象付与処理は、負担ユーザU(例えば、第1ユーザU1)が所定の対価を負担する場合に、被負担ユーザU(例えば、第2ユーザU2)に対価対象を付与するための処理である。機会提供処理は図10のルーチンを通じて、対価付与処理は図11のルーチンを通じて、それぞれゲーム端末5の制御ユニット30によって実現される。より具体的には、図10及び図11のルーチンは、一例として、制御ユニット30のゲーム提供部37を通じて実行されてよい。なお、ゲーム端末5の制御ユニット30及びセンターサーバ2の制御ユニット10は、この処理の他にも各種の周知な処理等を、それぞれ単独で或いは互いに協働して実行する。しかし、それらの詳細な説明は省略する。
図10は、機会提供処理を実現するための機会提供処理ルーチンのフローチャートの一例を示す図である。図10のルーチンは、例えば、機会条件が満たされる場合に実行されてよい。機会条件は、例えば、事前に負担ユーザUから許容機会の提供の要求があった場合に満たされてよい。つまり、事前に許容機会を提供するために図10のルーチンが実行されてもよい。或いは、機会条件は、被負担ユーザUから対価対象の付与の要求があった場合に満たされてもよい。つまり、事後的に許容機会を提供するために図10のルーチンが実行されてもよい。
図10のルーチンが開始されると、ゲーム提供部37は、まずステップS11において対象のユーザU、つまり許容機会を提供すべき負担ユーザUを特定する。例えば、負担ユーザUから要求により機会条件が満たされた場合には、ゲーム提供部37は、負担ユーザUにユーザIDの提供(入力)を要求してもよい。そして、負担ユーザUから提供されたユーザIDにより今回の対象のユーザUを特定してもよい。或いは、被負担ユーザUからの要求により機会条件が満たされた場合には、ゲーム提供部37は、その要求内容に基づいてまず被負担ユーザUのユーザIDを特定してよい。そして、その特定したユーザIDに基づいて負担管理データ20を参照しつつ、そのユーザID(被負担ユーザU)に対応する負担ユーザUを特定してよい。ゲーム提供部37は、例えば、このようにステップS11において対象のユーザUを特定してよい。
続くステップS12において、ゲーム提供部37は、ステップS11で特定したユーザUに許容機会を提供して、今回のルーチンを終了する。これにより、被負担ユーザUから対価対象の付与が要求される前(事前)、或いは要求された後(事後)に被負担ユーザUのための対価の負担を許容するか否か選択する機会(許容機会)が負担ユーザUに付与される。
一方、図11は、対象付与処理を実現するための対象付与処理ルーチンのフローチャートの一例を示す図である。図11のルーチンは、例えば、被負担ユーザUから対価対象の付与が要求される毎に実行されてよい。
図11のルーチンが開始されると、ゲーム提供部37は、まずステップS21において今回の対象のユーザUを特定する。この特定は、例えば、ゲームのプレイに使用されたプレイデータ19に基づいて実行されてもよい。或いは、プレイデータ19の取得のために提供されたユーザIDに基づいて実行されてもよい。
続くステップS22において、ゲーム提供部37は、ステップS21で特定したユーザUに対応する負担ユーザUを特定する。つまり、ゲーム提供部37は、今回の対象のユーザUが属するグループUGの各ユーザUのうち、所定の対価の支払いを依頼すべきユーザUを特定する。この特定は、例えば、負担管理データ20に基づいて実現されてよい。
次のステップS23において、ゲーム提供部37は、ステップS22で特定した負担ユーザUに提供された許容機会の結果を取得する。具体的には、ゲーム提供部37は、例えば、許容機会が事前に提供されている場合には、許容機会の結果として許容量の設定結果を取得してよい。或いは、ゲーム提供部37は、例えば、許容機会が事後的に提供される場合には、許容機会の結果として許容機会において負担を許容するか否かの選択結果を取得してよい。
続くステップS24において、ゲーム提供部37は、ステップS23の取得結果に基づいて許容条件が満たされるか否か判別する。許容条件は、例えば、上述の通りに満たされる。具体的には、例えば、許容機会が事前に提供されている場合には、許容条件は、許容量が設定されており、かつ今回の対価対象の要求がその許容量の残量の範囲内の場合に満たされてよい。つまり、許容条件は、設定条件及び範囲条件の両方が満たされる場合に満たされてよい。或いは、許容機会が事後的に提供される場合には、許容条件は、今回の対価対象の要求を許容(承認)する選択が実行された場合に満たされてよい。また、許容条件が支払条件を含む場合には、許容機会は対象の対価を支払う機会を含んでいてよい。この場合、ゲーム提供部37は、そのような許容機会において支払いが実行されている場合に許容条件が満たされたと判別してよい。そして、この判別結果が否定的結果の場合、つまり許容条件が満たされない場合、ゲーム提供部37は、以降の処理をスキップして、今回のルーチンを終了する。つまり、ゲーム提供部37は、今回の要求を拒否する。この場合、ゲーム提供部37は、今回の対象のユーザUに付与の拒否を通知してもよい。
一方、ステップS24の判別結果が肯定的結果の場合、つまり許容条件が満たされる場合、ゲーム提供部37は、ステップS25に進む。ステップS25において、ゲーム提供部37は、今回の要求対象の対価対象を対象のユーザU、つまり被負担ユーザUに付与する。この場合、ゲーム提供部37は、負担管理データ20の“付与結果”の情報を更新してもよい。そして、ゲーム提供部37はステップS25の処理を終えると、今回のルーチンを終了する。これにより、許容条件を介して負担ユーザUによって対価の負担が許容された場合に被負担ユーザUに要求の対価対象が付与される。
以上に説明したように、この形態によれば、同じグループUG内の負担ユーザUが許容条件を介して被負担ユーザUのための対価の支払いを許容した場合に、その被負担ユーザUに対価に対応する対価対象が付与される。つまり、被負担ユーザUへの対価対象の付与の前に許容条件を介して負担ユーザUの支払許可が得られた場合に、被負担ユーザUに対価対象が付与される。このため、被負担ユーザUに対価対象が付与される場合でも、この対価対象が付与される被負担ユーザUとは異なる負担ユーザUにその対価対象の付与に対応する対価の支払いを請求することができる。結果として、例えば、対価対象の支払を行う権限がない被負担ユーザUから対価対象の付与が要求された場合でも、対価対象の付与までの一連の流れをスムーズに実行することができる。
また、例えば、被負担ユーザUから対価対象の付与が要求される毎に事後的に許容機会が提供される場合には、その要求毎に被負担ユーザUの要求に対応する対価の支払いを許容するか否か判断する機会を与えることができる。一方で、例えば、許容量の設定を通じて事前に許容機会が提供される場合には、被負担ユーザUのために支払を許容する範囲を設定する機会を被負担ユーザUからの要求前に提供することができる。これにより、被負担ユーザUから対価対象の付与が要求される毎に支払を許容するか否か判断するための負担ユーザUの手間を省略することができる。
さらに、グループ条件が関連条件を含み、関連条件が同じゲーム端末5に対応するプレイデータ19によって満たされる場合には、一台のゲーム端末5を共用する各ユーザUをグループ化することができる。一台のゲーム端末5を物理的に共用する関係の各ユーザUは、そもそも親しい間柄である可能性が高く、ゲーム以外においても情報交換がされる等、親密な関係を持つ可能性が高い。このため、このような親密な関係を持つ各ユーザUをグループ化し、そのような各ユーザU間に負担ユーザU及び被負担ユーザUの関係を構築させることができる。特に、親密な関係を持つ各ユーザU間においては、現実のコミュニケーションを通じて支払関係の問題も解消され易く、支払関係が問題にならない可能性も高い。同じゲーム端末5に対応する各ユーザUをグループ化することにより、このような現実の親密な関係を対価対象の支払及び付与に反映することができる。
以上の形態において、ゲーム端末5の制御ユニット30が、図10のルーチンを実行することにより本発明の機会付与手段として機能する。同様に、ゲーム端末5の制御ユニット30が、図11のルーチンを実行することにより本発明のユーザ特定手段及び対価付与手段として機能する。一方、ゲーム端末5の記憶ユニット31が、プレイデータ19を記憶することにより本発明のデータ記憶装置として機能する。
本発明は上述の形態に限定されず、適宜の形態にて実施することができる。例えば、上述の形態では、一人の第1ユーザU1が負担ユーザUとして機能している。しかし、本発明は、このような形態に限定されない。例えば、グループUG内の複数のユーザUが負担ユーザUとして機能してもよい。同様に、グループUG内の複数のユーザUが被負担ユーザUとして機能してもよい。
また、上述の形態では、負担ユーザUが被負担ユーザUのための対価を全て負担している。しかし、本発明は、このような形態に限定されない。例えば、負担ユーザUが被負担ユーザUのための対価の一部を負担してもよい。また、この負担部分は、例えば、負担ユーザU等の特定のユーザUによって設定されてもよい。さらに、このような負担ユーザUは、例えば、固定条件に基づいて固定的に設定されてもよい。つまり、負担ユーザUは固定条件に基づいて固定されてもよい。例えば、固定条件は、関連条件が利用される場合には最初にプレイデータ19を生成したユーザUによって満たされてよい。つまり、同じゲーム端末5に関連付けられる複数のユーザUが存在する場合に、それらのユーザUのうちそのゲーム端末5に最初にプレイデータ19を生成したユーザUが固定条件を満たし、そのユーザUが固定的に負担ユーザUとして機能してもよい。或いは、固定条件は、特定のユーザU等、各ユーザUによる設定(自己申請を含む)を要件に含んでよい。つまり、このような設定によって設定されたユーザUが負担ユーザUとして固定されてもよい。また、例えば、このような場合、負担ユーザU以外のユーザUによる支払いは一切許可されなくてもよい。つまり、負担ユーザU以外のユーザUによる支払い機能は完全に制限されてもよい。
上述の形態では、関連条件は同じゲーム端末5に関連付けられるプレイデータ19によって満たされている。しかし、本発明は、このような形態に限定されない。例えば、同じゲーム端末5のうち、特定の関連が設定された各ユーザUのプレイデータ19によって関連条件が満たされてもよい。また、このような特定の関連は、特定のユーザU(例えば、負担ユーザU)によって予め設定されてもよい。つまり、関連条件は、更に特定のユーザUによる設定結果を要件に含み、グループUG内の関連が設定された限定的ユーザUによって満たされてもよい。この場合、同じグループUGにグループ化される各ユーザUを特定のユーザUの設定に委ねることができる。これにより。特定のユーザUの意思をグループ化に反映することができる。
また、上述の形態では、制御ユニット30及び記憶ユニット31がゲーム端末5に設けられている。しかし、本発明のゲーム端末5は、このような形態に限定されない。例えば、クラウドコンピューティングを利用してネットワーク上に論理的に制御ユニット30及び記憶ユニット31が設けられてもよい。つまり、ゲーム端末5は、ネットワーク3を通じて制御ユニット30の処理結果を表示して提供する端末として構成されていてもよい。或いは、反対にゲーム端末5がセンターサーバ2として機能してもよい。
同様に、上述の形態では、機会提供処理及び対象付与処理はゲーム端末5の制御ユニット30により単独で実行されている。したがって、センターサーバ2は省略され、一台のゲーム端末5だけによってゲームシステムが実現されてもよい。この場合、例えば、ゲーム端末5は事前にプレイデータ19や負担管理データ20をセンターサーバ2から取得していてもよい。一方で、本発明は、このような形態にも限定されない。例えば、上述の形態とは反対に、機会提供処理及び対象付与処理はゲーム端末5とセンターサーバ2との協働により実現されてもよい。
図12は、結果送信処理を実現するための結果送信処理ルーチンのフローチャートの一例を示す図である。結果送信処理は、ゲーム端末5の機会提供処理及び対象付与処理と協働するためにセンターサーバ2が実行する処理である。図12の例では、ゲーム提供部37によって主として実行される処理がゲーム端末5として、Webサービス管理部17によって主として実行される処理がセンターサーバ2として、それぞれ記述されている。また、図10及び図11のルーチンと共通する処理については共通の符号を付して説明を省略する。
図12に示すように、図10の処理と比較して図12のルーチンでは、機会提供処理ルーチンにステップS13が追加されている。具体的には、ゲーム端末5は、機会提供処理として、ステップS12の処理に続くステップS13において、ステップS12で提供した許容機会の結果をセンターサーバ2に送信して、今回のルーチンを終了する。
そして、センターサーバ2は、ゲーム端末5から許容機会の結果を取得すると、図12のルーチンを開始する。具体的には、図12のルーチンを開始すると、センターサーバ2は、まずステップS31においてゲーム端末5から許容機会の結果を取得する。続くステップS32において、センターサーバ2は送信条件を満たすか否か判別する。送信条件は、例えば、被負担ユーザUが使用するゲーム端末5がネットワーク3を介して接続された場合に満たされてよい。この判別結果が否定的結果の場合、つまり送信条件が満たされない場合には、センターサーバ2はステップS32に再度戻り、送信条件が満たされるまで繰り返しステップS32の処理を実行する。なお、センターサーバ2は、送信条件が所定期間内に満たされない場合は、以降の処理をスキップして、今回のルーチンを終了してもよい。また、この場合、許容機会の結果の提供が失敗したことを負担ユーザUに通知してもよい。
一方、ステップS32の判別結果が肯定的結果の場合、つまり送信条件が満たされる場合、センターサーバ2は許容機会の結果をゲーム端末5に提供して、今回のルーチンを終了する。そして、許容機会の結果を取得したゲーム端末5は、図11と同様に対象付与処理を実行してよい。これにより、ゲーム端末5及びセンターサーバ2の協働により機会提供処理及び対象付与処理を実現することができる。結果として、例えば、同じゲーム端末5だけでなく異なるゲーム端末5を利用する各ユーザUをグループ化することもできる。この場合、ステップS31において取得される許容機会の結果が本発明の許容情報として機能してよい。そして、センターサーバ2の制御ユニット10が、図12のルーチンを実行することにより本発明の結果取得手段及び結果提供手段として機能してよい。
以下に、上述の内容から得られる本発明の一例を記載する。なお、以下の説明では本発明の理解を容易にするために添付図面の参照符号を括弧書きにて付記したが、それにより本発明が図示の形態に限定されるものではない。
本発明のゲームシステムは、所定の対価と関連付けられる対価対象を含むゲームを各ユーザ(U)に提供するゲームシステム(1)であって、グループ条件を満たす複数のユーザのうちの一のユーザ(U1)及び当該一のユーザとは別のユーザ(U2)を特定するユーザ特定手段(30)と、前記一のユーザが前記別のユーザのための前記所定の対価の支払いを許容することを示す許容条件を満たす場合に、前記別のユーザに前記対価対象を付与する対価付与手段(30)と、を備えている。
本発明によれば、グループ内の一のユーザが別のユーザのための対価の支払いを許容した場合に、その別のユーザに対価に対応する対価対象が付与される。つまり、別のユーザへの対価対象の付与の前に許容条件を介して一のユーザの支払許可が得られた場合に、別のユーザに対価対象が付与される。このため、別のユーザに対価対象が付与される場合でも、この対価対象が付与される別のユーザとは異なる一のユーザにその対価対象の付与に対応する所定の対価の支払いを請求することができる。結果として、対価対象の付与までの一連の流れをスムーズに実行することができる。
許容条件として、各種の態様が採用されてよい。例えば、本発明のゲームシステムの一態様として、前記別のユーザのための前記所定の対価の支払いを許容するか否か選択するための許容機会を前記一のユーザに付与する機会付与手段(30)を更に備え、前記許容条件は、前記許容機会を通じた前記一のユーザによる前記所定の対価の支払いを許容する選択を要件に含んでいる態様が採用されてもよい。
また、許容機会が付与される態様において、前記機会付与手段は、前記別のユーザによって前記対価対象の付与が要求された場合に前記一のユーザに前記許容機会を付与し、前記許容条件は、前記許容機会を通じて前記一のユーザによって前記別のユーザの要求に対応する前記所定の対価の支払いを許容する選択が実行された場合に少なくとも満たされてもよい。この場合、別のユーザから対価対象の付与が要求される毎に、それに対応する対価の支払いを許容するか否か判断する機会を一のユーザに与えることができる。
或いは、許容機会が付与される態様において、前記許容機会は、前記所定の対価の支払いを予め所定量許容する許容量の設定を通じて前記別のユーザのための前記所定の対価の支払いを許容する選択が実行されるように構成され、前記許容条件は、前記許容量が設定された場合に満たされる設定条件及び前記別のユーザの要求が前記許容量の範囲内の場合に満たされる範囲条件を要件に含み、前記設定条件及び範囲条件の両方が満たされた場合に少なくとも満たされてもよい。この場合、別のユーザのために支払を許容する範囲を設定する機会を事前に一のユーザに提供することができる。これにより、別のユーザから対価対象の付与が要求される毎に支払を許容するか否か判断するための一のユーザの手間を省略することができる。
また、グループ条件として、各種の態様が採用されてよい。例えば、本発明のゲームシステムの一態様として、各ユーザの過去のプレイ状況を示すプレイ情報と各ユーザを識別するためのユーザ識別情報とが関連付けられるように記述されたプレイデータ(19)を記憶するデータ記憶装置(31)を更に備え、前記グループ条件は、前記プレイデータに関連する関連条件を含み、前記ユーザ識別情報を介して各ユーザに関連付けられる前記プレイデータが前記関連条件を満たす場合に少なくとも満たされる態様が採用されてもよい。或いは、前記グループ条件は、各ユーザの位置に関連する位置条件を含み、各ユーザが使用するユーザ端末(5)を介して各ユーザの位置に関連する位置関連情報が取得された場合に、当該位置関連情報に基づいて各ユーザが前記位置条件を満たす場合に少なくとも満たされてもよい。また、前記グループ条件は、グループを特定するためのグループ情報を入力するための入力装置(7)を介して各ユーザから前記グループ情報が提供された場合に、当該グループ情報に基づいて共通のグループに対応する前記グループ情報を入力した各ユーザによって満たされてもよい。
グループ条件が関連条件を含む態様において、前記ゲームを各ユーザに提供する少なくとも一つのゲーム端末(5)を含み、前記プレイデータは、前記プレイ情報が前記ゲーム端末を特定するための端末特定情報と更に関連付けられるように構成され、前記関連条件は、前記プレイデータが前記端末特定情報を介して同じゲーム端末に関連付けられる場合に満たされてもよい。或いは、前記端末特定情報は、前記ゲームを提供する複数のゲーム端末をそれぞれ識別可能に構成され、前記関連条件は、前記同じゲーム端末に対応する前記端末特定情報を含む前記プレイデータによって満たされてもよい。これらの場合、一つのゲーム端末を共用する各ユーザをグループ化することができる。特に、一つのゲーム端末を物理的に共用する関係の各ユーザは、そもそも親しい間柄である可能性が高く、ゲーム以外においても情報交換がされる等、親密な関係を持つ可能性が高い。このため、このような親密な関係を持つ各ユーザをグループ化することができる。結果として、現実の親密な関係を対価対象の支払及び付与の関係に反映することができる。
また、グループ条件が関連条件を含む態様において、前記関連条件は、特定のユーザ(U1)によって設定される設定結果を更に要件に含み、前記特定のユーザによって関連が設定された各ユーザの前記プレイデータによって満たされてもよい。この場合、グループ化される各ユーザを特定のユーザの設定に委ねることができる。これにより、特定のユーザの意思をグループ化に反映することができる。
一方、本発明のコンピュータプログラムは、前記ゲームを提供するための出力装置(MO)を備えたコンピュータ(30)を、上述のゲームシステムの各手段として機能させるように構成されたものである。
また、本発明のサーバ装置は、上述のゲームシステムにネットワーク(3)を介して接続されるサーバ装置(2)であって、前記許容条件が満たされる場合に、当該許容条件が満たされることを示す許容情報を取得する結果取得手段(10)と、前記許容条件が満たされる場合に、前記別のユーザに前記対価対象が付与されるように、前記許容情報を前記ゲームシステムに提供する結果提供手段(10)と、を備えている。本発明のコンピュータプログラム或いはサーバ装置が実行されることにより、本発明のゲームシステムを実現することができる。