JP6694028B2 - ゲームシステム及び管理装置 - Google Patents

Description

本発明は、ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもあるゲーム端末、或いは、ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成されたゲームシステム等に関する。

従来、ゲームセンターなどの店舗施設で運営されるいわゆる業務用ゲーム装置では、硬貨投入によるプレイ対価の支払いを基本としてきた。しかし近年は、業務用ゲーム装置でプレイする際に、硬貨投入の代わりに予め登録していたユーザＩＤを入力することで、ユーザＩＤに紐付けされたユーザ（プレーヤ）の仮想通貨（電子マネー）の口座からプレイ対価を引き落とす電子決済を行う電子決済方式も利用されるようになってきた（例えば、特許文献１，特許文献２を参照）。

電子決済方式では、ゲーム参加登録（ゲームへのエントリー）のプロセスで、ユーザＩＤまたはユーザＩＤと紐付けされた媒体ＩＤを記憶したＩＣカード（いわゆるユーザカード）を業務用ゲーム装置に読み取らせれば、プレイ対価の支払いが自動的に行われる。重たい硬貨を持ち歩く必要も無く、エントリーの都度硬貨を投入する必要が無い。

特開２０１０−２６２３８９号公報 特開２０１０−２６２３９０号公報

さて、業務行ゲーム装置のユーザの動向を観察すると、友人同士で連れだってゲームセンター等に訪れるケースが少なからず存在し、更にそのうち友人同士でマルチプレイを楽しむケースは比較的多く見受けられる。
そうしたユーザ達から体験談を聞くと、皆でゲームにエントリーする段階になって、一緒に行った友人の一人がユーザカードを所持していなことや、所持していても仮想通貨の口座の残高がプレイ対価分に満たないといった事態が判明し、あえなくゲームプレイを諦めるはめになった経験が有るという。
ユーザにしてみれば楽しみにしていたことが叶わずとても残念なことであり、業務用ゲーム装置の運営者からすればせっかくの収入の機会を逃すことであり、対策が望まれるところである。

本発明は、こうした事情を鑑みてなされたものであって、友人同士が一緒にゲームにエントリーするときになって、一部の友人が自身でプレイ対価を支払えない事態が判明したとしても、ゲームプレイを諦めずに済む技術を提供することを目的とする。

上述した課題を解決するための第１の発明は、
ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもある前記ゲーム端末、或いは、前記ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成されたゲームシステムであって、
前記対価支払設定装置（例えば、図１のゲーム端末１３００）は、
ゲームをプレイする操作ユーザのプレイ対価を当該操作ユーザ自身の財貨情報から支払う自己支払と、所与の代行支払ユーザに支払を代行してもらう代行支払とを少なくとも含む複数の支払方法の中から、支払方法を選択する支払方法選択手段（例えば、図２のジョイスティック１３０２、ボタンスイッチ１３０４、タッチパネル１３０６、制御基板１３５０、図６の操作入力部１００、端末処理部２００、エントリー準備部２０２、支払方法選択受付制御部２０７、図１１のステップＳ２０）と、
前記代行支払が選択された場合に、前記代行支払ユーザとするユーザを設定する代行支払ユーザ設定手段（例えば、図２のジョイスティック１３０２、ボタンスイッチ１３０４、タッチパネル１３０６、媒体読取装置１３４２、制御基板１３５０、図６の端末処理部２００、代行支払設定部２１０、支払ユーザＩＤ５１８、図１２のステップＳ５０〜Ｓ１１２）と、を備え、
前記管理装置は、前記支払方法選択手段において、前記自己支払が選択された場合には前記操作ユーザの財貨情報から前記操作ユーザのプレイ対価を消費し、前記代行支払が選択された場合には前記代行支払ユーザの財貨情報から前記操作ユーザのプレイ対価を消費するプレイ対価支払手段（例えば、図１の制御基板１１５０、図７のサーバ処理部２００ｓ、ユーザ登録管理部２４０、プレイ対価支払制御部２４２、図８のユーザ登録データ６００、口座残高６０４、図１４のステップＳ３６〜Ｓ４０）、を備えた、ゲームシステムである。

第１の発明によれば、ゲームエントリーのプロセスで、プレイ対価の支払方法として他者に支払を代行してもらう「代行支払」が選択可能になる。そして、代行支払が選択された場合には代行支払ユーザを別途設定し、当該代行支払ユーザの口座からプレイ対価を支払うことができる。つまり、ゲームにエントリーする段階になって一緒に行った一部の友人が自身でプレイ対価を支払えない事態が判明したとしても、誰かがその支払を代行することでそのままエントリーを行い、ゲームプレイに興じることが可能となる。

代行支払ユーザの設定に関しては、ゲームの形態に応じて適宜条件を設けることが出来る。
例えば、第２の発明として、前記ゲームがマルチプレイゲームであり、前記代行支払ユーザ設定手段は、前記マルチプレイゲームにおいて前記操作ユーザとともにプレイするユーザの中から前記代行支払ユーザとするユーザを設定する、第１の発明のゲームシステムを構成することができる。
つまり、同時プレイするユーザの中からのみ、代行支払ユーザを設定可能とする制限を設けることができる。

また、第３の発明として、前記代行支払ユーザ設定手段は、前記操作ユーザと所与の関係が予め設定されたユーザの中から前記代行支払ユーザとするユーザを設定する、第１又は第２の発明のゲームシステムを構成することもできる。
つまり、いわゆるフレンド登録されているユーザや、過去に対戦や共闘したことのあるユーザ、ゲーム中での会話履歴やアイテムの交換履歴等の交流があったユーザ、などの中から、代行支払ユーザを設定可能とする制限を設けることができる。

第２の発明や第３の発明のような適度な制限は、代行支払の悪用を抑制し、健全な遊戯を実現する助けとなる。

第４の発明は、前記管理装置が、前記代行支払ユーザとされたユーザに、所与の特典を付与する第１の特典付与処理を実行する第１の特典付与手段（例えば、図７のサーバ処理部２００ｓ、特典管理部２８０、図１４のステップＳ１６０）、を更に備えた第１〜第３の何れかの発明のゲームシステムである。

第４の発明によれば、代行支払に応じたユーザに対してご褒美を与えることで、代行支払に対する心理的な抵抗感を低減し、少しでも気持ちよく代行支払を利用してもらえるようにできる。

また、同じく特典付与の観点からすると、第５の発明として、前記管理装置が、各ユーザの代行支払の履歴を記憶する代行支払履歴記憶手段（例えば、図１のストレージ１１４０、図７の代行支払履歴管理部２６６、図８のサーバ記憶部５００ｓ、代行支払履歴データ６６０）と、
前記代行支払履歴記憶手段の記憶内容に基づいて、相互に代行支払ユーザとなって相手のプレイ対価を支払ったことのあるユーザの組み合わせを抽出する抽出手段（例えば、図７の特典管理部２８０、特典付与対象抽出部２８２、図１６のステップＳ２５２、図１７のステップＳ２６４）と、
前記組み合わせの一方のユーザ或いは両方のユーザに、所与の特典を付与する第２の特典付与処理を実行する第２の特典付与手段（例えば、図７の特典管理部２８０、特典付与制御部２８４、図１６のステップＳ２５２、図１７のステップＳ２６６）と、
を更に備えた第１〜第４の何れかの発明のゲームシステムを構成することもできる。

第５の発明によれば、代行支払をしてもらったユーザがそのお返しにあたる代行支払を行うと、相互に代行支払ユーザとなって相手のプレイ対価を支払ったことのあるユーザの組み合わせとして抽出される。代行支払を一種の返済とみなせば、返済が完了したと考えることもできる。これは道徳的に称賛されるべきことであり、本発明によれば、抽出された組み合わせの一方のユーザ或いは両方のユーザにご褒美を付与することができる。
また、プレーヤ間での信頼関係を向上させるだけでなく、ゲーム運営者にとってみればゲームを実行してもらえる機会を増加させる効果が期待できる。

勿論、代行支払に対するお返しが必ずしも行われるとは限らないので、
第６の発明として、前記管理装置が、各ユーザの代行支払の履歴を記憶する代行支払履歴記憶手段と、前記代行支払履歴記憶手段の記憶内容に基づいて、第１ユーザが代行支払ユーザとなって第２ユーザのプレイ対価を支払った履歴があり、且つ、所与の期間内に前記第２ユーザが代行支払ユーザとなって前記第１ユーザのプレイ対価を支払った履歴がない前記第１ユーザを抽出する抽出手段（例えば、図７の特典管理部２８０、特典付与対象抽出部２８２、図１６のステップＳ２５２、図１７のステップＳ２７０）と、
前記抽出手段により抽出された前記第１ユーザに所与の特典を付与する第３の特典付与処理を実行する第３の特典付与手段（例えば、図７の特典管理部２８０、特典付与制御部２８４、図１７のステップＳ２７２）と、を更に備えた第１〜第４の何れかの発明のゲームシステムを構成することもできる。

第６の発明によれば、代行支払に対するお返しが行われなかった場合、代行支払したユーザへある種の補填や慰めとしての特典を付与することができる。

また、同様の想定に基づけば、第７の発明として、前記管理装置が、各ユーザの代行支払の履歴を記憶する代行支払履歴記憶手段と、前記代行支払履歴記憶手段の記憶内容に基づいて、第１ユーザが代行支払ユーザとなって第２ユーザのプレイ対価を支払った履歴があり、且つ、所与の期間内に前記第２ユーザが代行支払ユーザとなって前記第１ユーザのプレイ対価を支払った履歴がない前記第２ユーザを抽出する抽出手段（例えば、図７の特典管理部２８０、特典付与対象抽出部２８２、図１６のステップＳ２５２、図１７のステップＳ２７０）と、
前記抽出手段により抽出された前記第２ユーザに、お返しの代行支払が行われていないことによる所与のお返し未実施時処理を実行するお返し未実施時処理手段（例えば、図７の特典管理部２８０、特典付与制御部２８４、図１７のステップＳ２７４）と、を更に備えた第１〜第４の何れかの発明のゲームシステムを構成することができる。

第７の発明によれば、代行支払のお返しをしなかった第２ユーザに対する処理、例えば、その旨を通知する処理や、ある種の罰を負わせる処理（負の特典を付与する処理ともいえる）などを行うことができる。これにより、他人から受けた恩を返さない行為の横行を抑制し、健全に代行支払が利用されるように促す仕組みを実現できる。また、プレーヤ間での背信感を増加させるだけでなく、ゲーム運営者にとってみればゲームを実行してもらえる機会を増加させる効果が期待できる。

第８の発明は、前記代行支払ユーザ設定手段が、前記代行支払ユーザとするユーザの承認手続（例えば、図１２のステップＳ５０〜Ｓ１０６）に基づいて前記代行支払ユーザを設定する、第１〜第７の何れかの発明のゲームシステムである。

第８の発明によれば、承認手続きを経ることで、代行支払の誤用を防止することができる。

第９の発明は、前記管理装置が、各ユーザの代行支払の履歴を記憶する代行支払履歴記憶手段（例えば、図７の代行支払履歴管理部２６６、図１０の代行支払履歴データ６６０、図１４のステップＳ１５８）を更に備え、前記代行支払ユーザ設定手段は、所与の期間の代行支払の合計が所与の上限に達していないユーザを代行支払ユーザとして設定する（例えば、図１５のステップＳ５４→通信Ｅ→図１２のステップＳ５６〜ステップＳ７２）、第１〜第８の何れかの発明のゲームシステムである。

第９の発明によれば、代行支払に適度な制限を設け、乱用を抑制し健全な代行支払の運用を実現できる。

第１０の発明は、ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもある前記ゲーム端末、或いは、前記ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成されたゲームシステムの前記対価支払設定装置であって、
ゲームをプレイする操作ユーザのプレイ対価を当該操作ユーザ自身の財貨情報から支払う自己支払と、所与の代行支払ユーザに支払を代行してもらう代行支払とを少なくとも含む複数の支払方法の中から、支払方法を選択する支払方法選択手段（例えば、図２５のタッチパネル１２０６、制御基板１２５２、図２６の操作入力部１００ｔ、ターミナル処理部２００ｔ、ゲーム管理部２５０Ｃ、支払方法選択受付制御部２０７、図２８のステップＳ３〜Ｓ３３）と、前記代行支払が選択された場合に、前記代行支払ユーザとするユーザを設定する代行支払ユーザ設定手段（例えば、図２５のタッチパネル１２０６、制御基板１２５２、図２６の操作入力部１００ｔ、ターミナル処理部２００ｔ、ゲーム管理部２５０Ｃ、支払方法選択受付制御部２０７、図２８のステップＳ３〜Ｓ３３）と、を備えた対価支払設定装置である。

第１０の発明によれば、第１の発明と同様の効果が得られる。

ゲームシステムの構成の一例を示す図。 ゲーム端末の構成例を示す斜視外観図 第１実施形態における代行支払の実現方法を説明するための図。 代行支払にともなう特典付与の仕様について説明するための図。 所定期間内に返済が成立しない場合の特典付与について説明する図。 第１実施形態におけるゲーム端末の機能構成の一例を示す機能ブロック図。 第１実施形態におけるサーバシステムの機能構成例を示す機能ブロック図。 第１実施形態におけるサーバ記憶部が記憶するプログラムやデータの例を示す図。 エントリー登録データのデータ構成例を示す図。 代行支払履歴データのデータ構成例を示す図。 第１実施形態のゲーム端末における処理の流れについて説明するためのフローチャート。 図１１より続くフローチャート。 図１２より続くフローチャート。 第１実施形態のサーバシステムにおける処理の流れについて説明するためのフローチャート。 図１４より続くフローチャート。 図１５より続くフローチャート。 返済判定および特典付与処理の流れを説明するためのフローチャート。 第２実施形態における代行支払の実現方法を説明するための図である。 第２実施形態におけるゲーム端末の機能構成の一例を示す機能ブロック図。 第２実施形態におけるサーバシステムの機能構成例を示す機能ブロック図。 第２実施形態のゲーム端末における処理の流れについて説明するためのフローチャート。 図２１より続くフローチャート。 第２実施形態のサーバシステムにおける処理の流れを説明するためのフローチャート。 図２３より続くフローチャート。 第３実施形態における代行支払の実現方法を説明するための図。 ターミナル装置の機能構成例を示す機能ブロック図。 第３実施形態におけるサーバシステムの機能構成例を示す機能ブロック図。 ターミナル装置における処理の流れを説明するためのフローチャート。 図２８より続くフローチャート。 第３実施形態のサーバシステムにおける処理の流れを説明するためのフローチャート。 図３０より続くフローチャート。

〔第１実施形態〕
本発明を適用した第１実施形態として、ゲームのプレイ対価の支払をゲーム端末で行ってオンラインマルチプレイゲームをプレイする例について説明する。

図１は、本実施形態におけるゲームシステムの構成の一例を示す図である。本実施形態のゲームシステムは、通信回線９に接続することのできるサーバシステム１１００と、プレーヤ２（２ａ，２ｂ，・・・）が電子決済用媒体６を用いてプレーヤ登録とプレイ対価の支払いができるゲーム端末１３００（１３００ａ，１３００ｂ，・・・）と、を備えて構成される。

電子決済用媒体６は、当該オンラインマルチプレイゲームの運営者が提供する電子マネー（仮想通貨）による電子決済システムを利用するためのキーデータを記憶し、当該データをコンピュータに接続された専用の読取装置を用いることで読み取り可能な媒体である。例えば、ＩＣカードや、所定の電子決済アプリケーションを起動するスマートフォンなどにより実現される。本実施形態では、ゲーム端末１３００で電子決済が可能な構成である。つまり、ゲーム端末１３００が対価支払設定装置として機能する。

キーデータとしては、例えば、ユーザ登録時に設定される固有のユーザＩＤや、固有の媒体ＩＤ（例えば、ＩＣカードならばカードＩＤ、スマートフォンなどの情報機器ならばＭＡＣアドレス）などを適宜設定することができる。ちなみに、本実施形態の電子決済用媒体６には、媒体ＩＤは記憶されているが金銭価値に対応するデータは記憶されていない。

本実施形態では、各プレーヤ２（２ａ，２ｂ）は、予め所定の手続きを経てユーザ登録しユーザＩＤを取得すると、自身の口座へ電子マネーを購入して入金し、更に別途入手した電子決済用媒体６の固有の媒体ＩＤを自身のユーザＩＤと関連付けて登録することができる。詳細は後述するが、ユーザＩＤと対応づけて電子決済用媒体６を登録することで、あたかもプリペイドカードの如く電子決済用媒体６をプレイ対価の支払いに使用する事ができるようになる。電子マネーは財貨情報の一例であり、口座には電子マネーの残高の情報が対応づけられているため、口座に係る情報が、当該ユーザの財貨情報とも言える。

通信回線９は、データ通信が可能な通信路を意味する。すなわち、通信回線９とは、直接接続のための専用線（専用ケーブル）やイーサネット（登録商標）等によるＬＡＮ（Local Area Network）の他、電話通信網やケーブル網、インターネット等の通信網を含む意味であり、また、通信方法については有線／無線を問わない。

サーバシステム１１００は、本実施形態における、ユーザがゲーム端末１３００を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置の一例である。サーバシステム１１００は、例えば、本体装置１１０１と、キーボード１１０６と、タッチパネル１１０８と、ストレージ１１４０とを備える。

本体装置１１０１には制御基板１１５０が搭載されている。この制御基板１１５０には、ＣＰＵ（Central Processing Unit）１１５１やＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などの各種マイクロプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＶＲＡＭやＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１１５２、通信装置１１５３が搭載されている。

そして、サーバシステム１１００は、制御基板１１５０で所定のプログラム及びデータに基づいて演算処理することにより、１）ユーザの登録処理および仮想通貨の口座を含む登録情報を管理しゲームコンテンツに係る課金要求に対して口座からの決済を実行する「ユーザ登録管理機能」と、２）ゲーム端末１３００にてオンラインマルチプレイゲームをプレイする為に必要なデータを逐次送受信する「ゲーム管理機能」と、を実現する。

なお、図１の例では、サーバシステム１１００は単体として記しているが、ユーザ登録管理機能とゲーム管理機能とを分担する複数のブレードサーバを搭載して、相互に内部バスを介してデータ通信可能に接続した構成であっても良い。或いは、離れた場所に設置された独立した複数のサーバを、通信回線９を介してデータ通信させることで、全体としてサーバシステム１１００として機能させる構成であっても良い。

図２は、ゲーム端末１３００の構成例を示す斜視外観図である。
ゲーム端末１３００は、通信回線９に接続してサーバシステム１１００にアクセスすることができるコンピュータであり電子装置（電子機器）である。
本実施形態のゲーム端末１３００は業務用ゲーム装置として分類される装置であるが、携帯型ゲーム装置、据置型家庭用ゲーム装置、据置型家庭用ゲーム装置のゲームコントローラに分類される装置でもよい。また、ゲーム端末としての機能を実現するためのアプリケーションプログラムを実行できるスマートフォンや、パソコン、タブレット型コンピュータ、ウェアラブルコンピュータなどに分類される装置でもよい。

本実施形態におけるゲーム端末１３００は、ジョイスティック１３０２と、ボタンスイッチ１３０４と、画像表示デバイス兼接触位置入力デバイスとして機能するタッチパネル１３０６と、スピーカ１３１０と、制御基板１３５０と、電子決済用媒体６からデータを読み取りできる媒体読取装置１３４２と、を備える。

制御基板１３５０は、ＣＰＵ１３５１やＧＰＵ，ＤＳＰなどの各種マイクロプロセッサと、ＡＳＩＣ，ＶＲＡＭ，ＲＡＭ，ＲＯＭ等の各種ＩＣメモリ１３５２と、通信回線９に通信接続するための無線通信モジュール１３５３とが搭載されている。その他、タッチパネル１３０６のドライバ回路、ジョイスティック１３０２及びボタンスイッチ１３０４からの信号を受信する回路、スピーカ１３１０へ音声信号を出力する出力アンプ回路、媒体読取装置１３４２への信号入出力回路といった所謂Ｉ／ＦコントロールＩＣ１３５４（インターフェース回路）等が搭載されている。これら制御基板１３５０に搭載されている各要素は、それぞれバス回路などを介して電気的に接続され、データの読み書きや信号の送受信が可能に接続されている。

制御基板１３５０は、ゲームプログラムを実行して演算処理を実行し、ジョイスティック１３０２やボタンスイッチ１３０４，タッチパネル１３０６からの操作入力に応じてゲーム端末１３００の各部を制御してゲームプレイを可能にする。本実施形態のゲーム端末１３００は、必要なプログラムや各種設定データを予めＩＣメモリ１３５２に記憶しているものとするが、起動の都度、サーバシステム１１００からダウンロードする構成としても良い。
制御基板１３５０の制御により、ゲーム端末１３００は、ジョイスティック１３０２やタッチパネル１３０６などを介した操作入力の結果をサーバシステム１１００へ逐次送信する一方で、サーバシステム１１００からオンラインマルチプレイゲームを実行するための各種データを受信し、ゲーム画面の画像を生成してタッチパネル１３０６に表示させ、効果音や操作音の音信号を生成してスピーカ１３１０から放音することができる。つまり、プレーヤ２はタッチパネル１３０６に表示されるゲーム画面を見て、スピーカ１３１０から流れるゲーム音を聞きながら、ジョイスティック１３０２を操作してゲームを楽しむことができる。

［代行支払の仕様について］
さて、オンラインマルチプレイゲームを好むプレーヤにとっては、友人と連れだってゲームセンターに赴き、一緒にゲームを楽しむことは良くあることである。そして、友人同士であれば、手持ちのお金が不足している友人に対して、支払を代行・肩代わりする行為も良くあることである（俗に言う“おごり”行為：以降、「代行支払」と呼ぶ）。本実施形態では、プレーヤ別に登録された電子決済用媒体６を用いて、この「代行支払」を実現することができる。

図３は、本実施形態における代行支払の実現方法を説明するための図である。
例として、友人同士の二人のプレーヤ２ａ，２ｂが一緒にゲームセンターに行ったとする（図１参照）。一方のプレーヤ２ａは、登録済みの電子決済用媒体６ａを所持し、電子マネーの口座に複数回のプレイが可能なだけの残高があるとする。ところが、他方のプレーヤ２ｂは電子決済用媒体６を忘れてきた、あるいは所持しているが口座に１プレイ分の残高も残っていないとする。

本実施形態では、他方のプレーヤ２ｂが、ゲーム端末１３００でのプレーヤ登録と支払方法の選択の過程を通じて友人（この場合、プレーヤ２ａ）に“おごり”のお願いをし、これが承認されたならば、プレーヤ２ａの口座からプレーヤ２ｂの分のプレイ対価の消費を行うことで「代行支払」を実現する。

具体的には、先ず電子決済用媒体６を所持しているプレーヤ２ａが、使用するゲーム端末１３００ａの媒体読取装置１３４２に電子決済用媒体６をかざして、媒体ＩＤを読み取らせてプレーヤ登録（今回のプレイを行うプレーヤとしてのユーザの登録）とプレイ対価の支払いとを一度に済ませる。つまり、ゲームへのエントリーを済ませる（図中の実線矢印）。

次いで、他方のプレーヤ２ｂが、使用するゲーム端末１３００ｂの媒体読取装置１３４２に電子決済用媒体６をかざすかタッチパネル１３０６に表示されるソフトウェアキーボードにてプレーヤ登録を済ませた後に、支払方法の選択で「代行支払」を選択する（図中の［１］）。

ゲーム端末１３００ｂは、支払方法に「代行支払」が選択されると、サーバシステム１１００からエントリー済みのユーザのユーザＩＤのリストを取得し、それらを代行支払の請願先候補として提示する（図中の［２］）。

プレーヤ２ｂがそれら請願先候補から何れか（この場合、プレーヤ２ａ）を選択操作すると（図中の［３］）、選択された請願先のユーザＩＤがサーバシステム１１００へ送信され、サーバシステム１１００を介して代行支払の要請が請願先のユーザのゲーム端末１３００ａへ送信される（図中の［４］）。
そして、要請を受けたゲーム端末１３００ａにてプレーヤ２ａが承認操作を入力すると（図中の［５］）、一方のプレーヤ２ｂの口座から他方のプレーヤ２ｂの分のプレイ対価の支払いが行われる（図中の［６］）。

よって、連れだってゲームをしにでかけた友人同士の内、誰かが自分の支払が出来ない状態であっても、何れか一人がその支払を肩代わりできる電子決済用媒体６を所持していれば、いわば、その場で“おごってもらったり”“おごってあげたり”といった行為が可能となる。つまり、自分の支払が出来ないメンバーがいるからといって、出直したり、一緒のプレイをやむなく中止するといったことなくそのままゲームを楽しむことが可能となる。また、この“おごってもらったり”“おごってあげたり”といった行為により彼らの友好関係がより高まり、副次的に一緒にゲームをしに行く機会を増やす効果も期待できる。

そして、本実施形態では、この副次的な効果をより高めるためにプレーヤに特典を付与する仕様が盛り込まれている。

図４は、代行支払にともなう特典付与の仕様について説明するための図である。
代行支払が行われるとサーバシステム１１００にて履歴が残される。履歴には、代行支払を行ったプレーヤ２ａ（代行支払ユーザ）のユーザＩＤと、代行支払をお願いしたプレーヤ２ｂ（代行請願ユーザ）のユーザＩＤと、支払日時とが含まれる。

代行支払はある種の恩義や債務と捉えることができる。つまり、プレーヤ２ｂはプレーヤ２ａに対してできるだけ早くその恩を返すべく、プレーヤ２ａに対してお返しの代行支払をするのが望ましい。

そこで、本実施形態では代行支払プレーヤと代行請願プレーヤとのユーザＩＤの関係が逆転する二つの履歴が、所定の返済判定期間内（例えば、登録の古い方の該当履歴の支払日時から２週間以内）に存在する場合に「返済成立」と見なし、関係する２名のプレーヤそれぞれに特典を付与する。

すなわち、該当する二つの履歴のうち最初の履歴における代行支払を行ったプレーヤ２ａには、友情の証としての代行支払を行ったご褒美として第１の特典を付与し、代行支払を請願したプレーヤ２ｂには、ちゃんと期限内に恩を返したご褒美として第２の特典を付与する。

なお、代行支払者のプレーヤ２ａへの第１の特典付与のタイミングは、履歴登録時点としてもよい。また、第２の特典は、代行支払者のプレーヤ２ａにも付与する構成としてもよい。

第１及び第２の特典の内容は、ゲームの内容等を考慮して適宜設定可能である。
例えば、電子マネーのキャッシュバック、ゲーム内で利用できるアイテムやスキルの付与、ＨＰ（ヒットポイント）などの能力パラメータ値の加算、経験値の加算、ゲームで利用できるクーポン、イベント等への参加権、プレイ対価の割引などが可能である。また、プレーヤ間の友好度合を示す友好ポイントをユーザＩＤ毎に管理するならば、この友好ポイントを加算するとしてもよい。そして、付与される特典の価値は、返済成立の回数や友好ポイントが大きいほど、より価値を高くすると好適である。こうした返済成立に伴って特典を付与する仕様は、一緒にプレイすることのあるプレーヤ達をよりゲームプレイに誘う効果をもたらすだろう。

勿論、きちんと期間内に返済が成立する場合とは限らず、本実施形態では意図的に代行支払のお返しがされないケースへの対処も考慮されている。

図５は、その期間内に返済が成立しない場合の特典付与について説明する図である。
ある履歴について着目して、代行支払をしたプレーヤ２ａと代行請願をしたプレーヤ２ｂとの関係が逆転するもう一つの履歴が所定の返済判定期間内に存在しない場合、当該着目した履歴については「返済不成立」「お返し無し」と見なす。そして、返済不成立の場合、この着目した履歴における代行支払したプレーヤ２ａへは第３の特典を付与する。この場合の第３の特典は返済されなかったことへのユーザ救済の意味をもつ。第３の特典については、第１の特典と同様に設定することができる。

一方、着目した履歴における代行請願したプレーヤ２ｂへは、お返しをしなかったことへの罰として、当該プレーヤにとって不利に作用する特典（いわば負の特典）を付与する。
負の特典は、ゲーム内容等を考慮の上、適宜設定可能である。例えば、口座残高から所定懲罰金分を消費する、アイテムの没収や一時的な使用停止処分、能力パラメータ値の減算、スキルの没収や低下、ゲーム内イベントへの参加停止処分、ランキングやクラスなどのダウン、一定期間強制的にプレーヤキャラクタに恥ずかしいオブジェクトを付属させたりカラー彩度を下げるなど外観上のデチューン、などが考えられる。
なお、負の特典の付与処理の代わりに、お返しをしていない旨を通知する処理を行うこととしてもよい。

このように、代行支払に伴う特典に「アメとムチ」の側面を備えることで、代行支払を行う環境・考え方を健全に醸成する仕組みを実現することができる。

［機能構成の説明］
次に、本実施形態を実現するための機能構成例について説明する。
図６は、本実施形態におけるゲーム端末１３００の機能構成の一例を示す機能ブロック図である。本実施形態のゲーム端末１３００は、操作入力部１００と、媒体読取部１０２と、端末処理部２００と、音出力部３９０と、画像表示部３９２と、通信部３９４と、端末記憶部５００とを備える。

操作入力部１００は、当該ゲーム端末を操作するプレーヤ（操作ユーザ）によって為された各種の操作入力に応じて操作入力信号を端末処理部２００に出力する。例えば、プッシュスイッチや、ジョイスティック、タッチパッド、トラックボール、加速度センサ、ジャイロ、ジェスチャーコントローラ、などによって実現できる。図２の例では、ジョイスティック１３０２や、ボタンスイッチ１３０４、タッチパネル１３０６がこれに該当する。

媒体読取部１０２は、電子決済用媒体６で採用される技術方式に準じた公知の読取装置により実現され、電子決済用媒体６に記憶されているデータを読み出して端末処理部２００へ出力する。例えば、電子決済用媒体６に非接触型ＩＣチップを用いるのであれば、そのカードの仕様に準じた非接触型リーダーライターにより実現される。

端末処理部２００は、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ、ＩＣメモリなどの電子部品によって実現され、操作入力部１００や端末記憶部５００を含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００からの操作入力信号、媒体読取部１０２で読み出したデータ、サーバシステム１１００から受信したデータ等に基づいて各種の演算処理を実行して、ゲーム端末１３００の動作を制御する。図２の例では制御基板１３５０がこれに該当する。
そして、本実施形態における端末処理部２００は、エントリー準備部２０２と、ゲーム演算部２２０と、音生成部２９０と、画像生成部２９２と、通信制御部２９４とを備える。

エントリー準備部２０２は、自機および自機を使用するユーザを、オンラインマルチプレイゲームへ参加登録するいわゆるゲームエントリーに係る制御を行う。
より具体的には、エントリー準備部２０２は、ユーザＩＤ取得制御部２０４と、操作ユーザ設定部２０５と、支払ユーザ設定部２０６と、支払方法選択受付制御部２０７と、代行支払設定部２１０と、を含む。

ユーザＩＤ取得制御部２０４は、媒体読取部１０２で電子決済用媒体６から読み出した媒体ＩＤに対応づけられるユーザＩＤを取得するための制御をする。本実施形態では、所定の照合リクエストとともに読み出した媒体ＩＤをサーバシステム１１００へ送信する。サーバシステム１１００がこれに応じてユーザ登録情報を参照してこの媒体ＩＤに紐付けられているユーザＩＤを抽出・返信してくるのを受信して、ユーザＩＤの取得を実現する。これを「照合済ユーザＩＤ」と呼ぶ。

操作ユーザ設定部２０５は、当該ゲーム端末１３００を使用するユーザを設定する。換言すると自機のプレーヤ登録を行う。具体的には、媒体ＩＤを元に取得された照合済ユーザＩＤを、自機を使用するプレーヤのユーザＩＤ、すなわち「操作ユーザＩＤ」として設定する。

支払ユーザ設定部２０６は、自機でのゲームプレイの対価を支払うユーザを設定する。具体的には、照合済ユーザＩＤを、自機でのゲームプレイの対価支払いをするユーザＩＤ、すなわち「支払ユーザＩＤ」の初期設定とする。

支払方法選択受付制御部２０７は、自機でのプレイ対価の支払方法を自機のプレーヤに選択させるための制御をする。本実施形態では、タッチパネル１３０６に、プレーヤ自身の電子マネーの口座から支払う「自己支払」と、友人にお願いして友人に支払を肩代わりしてもらう「代行支払」との何れかを選択させる。

代行支払設定部２１０は、代行支払を実現するための各種処理を行う。本実施形態では支払方法の選択結果が「代行支払」の場合に、友人にお願いして友人に支払を肩代わりしてもらう請願を行って、請願が承認された場合に支払ユーザをこの友人のユーザＩＤに変更する。そのために、本実施形態の代行支払設定部２１０は、請願先候補取得制御部２１２と、請願リクエスト部２１４と、請願応答制御部２１６と、支払ユーザ設定変更部２１８とを含む。

請願先候補取得制御部２１２は、サーバシステム１１００から請願先の候補に関するデータを取得する。具体的には、既にゲームエントリーされているプレーヤのうち、自機のプレーヤが登録しているユーザＩＤを使用しているプレーヤのリストを取得する。この請願先候補のリストを「エントリー済ユーザＩＤリスト」と呼ぶ。

請願リクエスト部２１４は、エントリー済ユーザＩＤリストに含まれるユーザＩＤを請願先候補としてプレーヤに選択可能に提示制御する。そして、選択操作がなされたならば、所定の請願リクエストとともに選択された何れかのユーザＩＤ（請願先ユーザＩＤ）と、自機の操作ユーザＩＤとをサーバシステム１１００へ送信する。

本実施形態のサーバシステム１１００は、この請願リクエストを受信すると、請願先ユーザＩＤに対応するエントリー済みのゲーム端末１３００へ、受信した操作ユーザＩＤが示すユーザ（代行請願ユーザ）への代行支払に応じるか否かの「承認リクエスト」を送信する。

請願応答制御部２１６は、この承認リクエストを受信した場合に、代行支払の承認に係る選択操作を受け付け、承認可否の結果を返信する制御を行う。

請願応答制御部２１６による返信は、サーバシステム１１００を介して請願リクエスト元のゲーム端末１３００への返信とされる。

支払ユーザ設定変更部２１８は、この返信に基づいて支払ユーザの設定を変更する。具体的には、代行支払が承認された場合に請願先のユーザＩＤで支払ユーザＩＤを更新することで実質的に代行支払ユーザを設定する。

ゲーム演算部２２０は、公知のオンラインマルチプレイゲームにおけるクライアント装置に係る技術を適宜利用することで実現され、サーバシステム１１００と通信してオンラインマルチプレイゲームを実行するための処理を行う。

音生成部２９０は、例えばデジタルシグナルプロセッサ（ＤＳＰ）や、音声合成ＩＣなどのプロセッサ、音声ファイル再生可能なオーディオコーデック等によって実現され、ゲーム演算部２２０による処理結果に基づいてゲームに係る効果音やＢＧＭ、各種操作音の音信号を生成し、音出力部３９０に出力する。

音出力部３９０は、音生成部２９０から入力される音信号に基づいて効果音やＢＧＭ等を音出力する装置によって実現される。図２のスピーカ１３１０がこれに該当する。

画像生成部２９２は、例えば、ＧＰＵ、デジタルシグナルプロセッサ（ＤＳＰ）などのプロセッサ、ビデオ信号ＩＣ、ビデオコーデックなどのプログラム、フレームバッファ等の描画フレーム用ＩＣメモリ等によって実現される。そして、画像生成部２９２は、ゲーム演算部２２０による処理結果に基づいて１フレーム時間（例えば１／６０秒）で１枚のゲーム画面の画像を生成し、生成したゲーム画面の画像信号を画像表示部３９２に出力する。

画像表示部３９２は、画像生成部２９２から入力される画像信号に基づいて各種ゲーム画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。本実施形態では、図２のタッチパネル１３０６がこれに該当する。

通信制御部２９４は、データ通信に係るデータ処理を実行し、通信部３９４を介して外部装置とのデータのやりとりを実現する。通信部３９４は、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現され、図２の無線通信モジュール１３５３がこれに該当する。

端末記憶部５００は、ゲーム端末１３００を統合的に制御するための諸機能を端末処理部２００に実現させるためのシステムプログラムや、ゲームプレイに必要なプログラム、各種データ等を記憶する。また、端末処理部２００の作業領域として用いられ、端末処理部２００が各種プログラムに従って実行した演算結果や操作入力部１００から入力される入力データ等を一時的に記憶する。こうした機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図２の制御基板１３５０が搭載するＩＣメモリ１３５２がこれに該当する。

本実施形態の端末記憶部５００には、端末システムプログラム５０２と、ゲームプログラム５０４と、ゲーム初期設定データ５０６と、端末ＩＤ５１１と、媒体ＩＤ５１２と、照合済ユーザＩＤ５１４と、操作ユーザＩＤ５１６と、支払ユーザＩＤ５１８と、課金額５２０と、エントリー済ユーザＩＤリスト５２２と、請願先ユーザＩＤ５２４と、プレイデータ５２６とが記憶される。その他、計時用のタイマやカウンタ、各種フラグなどの情報が記憶される。

端末システムプログラム５０２は、ゲーム端末１３００のコンピュータとしての入出力の基本機能を実現するためのプログラムである。

ゲームプログラム５０４は、端末処理部２００が読み出して実行することによってエントリー準備部２０２およびゲーム演算部２２０としての機能を実現させるためのアプリケーションソフトである。端末システムプログラム５０２の一部として組み込まれた構成であっても良い。オンラインゲームを実現する技術手法に応じて専用のクライアントプログラムであっても良いし、ウェブブラウザプログラム及びインタラクティブな画像表示を実現するプラグインなどにより構成するとしても良い。

ゲーム初期設定データ５０６は、本実施形態のオンラインマルチプレイゲームを実行するために必要な初期設定データである。例えば、仮想３次元空間にゲーム空間を構成するためのデータ、各種キャラクタのモデルデータやテクスチャデータ、モーションデータなどである。その内容は、オンラインマルチプレイゲームの実行に必要な処理をサーバシステム１１００とゲーム端末１３００とでどのように分担するかの仕様により適宜設定される。

なお、ゲームプログラム５０４およびゲーム初期設定データ５０６は、端末記憶部５００に予め記憶されている構成でも良いし、起動時にサーバシステム１１００からのダウンロードなどにより取得・記憶されるとしてもよい。

端末ＩＤ５１１は、当該ゲーム端末１３００に固有の識別情報である。ＭＡＣアドレスなどを利用するとしてもよい。

媒体ＩＤ５１２は、媒体読取部１０２により電子決済用媒体６から読み出した媒体ＩＤである。

照合済ユーザＩＤ５１４は、サーバシステム１１００が管理するユーザ登録にて媒体ＩＤ５１２に対応づけられているユーザＩＤであって、サーバシステム１１００へ照合リクエストとともに媒体ＩＤ５１２を送信するとその返信に含まれてくるユーザＩＤとして取得できる。

操作ユーザＩＤ５１６は、当該ゲーム端末１３００を利用するユーザ、すなわちプレーヤを示すユーザＩＤである。本実施形態では、照合済ユーザＩＤ５１４が複製されるか、操作入力部１００からの操作入力（例えば、タッチパネル１３０６に表示されるソフトウェアキーボードを用いた入力など）で設定される。

支払ユーザＩＤ５１８は、当該ゲーム端末１３００におけるプレイ対価の支払いを受け持つユーザを示すユーザＩＤである。本実施形態では、支払方法が自己支払の初期状態では照合済ユーザＩＤ５１４が複製設定されるが、支払方法の選択において代行支払が選択され、且つ、代行支払が他プレーヤにより承認された場合に当該他プレーヤのユーザＩＤに変更される。

課金額５２０は、１プレイの対価として消費される電子マネーの額を示す。本実施形態では、プレイ対価の支払を電子決済でのみ行う構成なので所定の固定値とするが、ゲーム端末１３００が硬貨等の現金による支払も受付可能な構成であれば、投入された硬貨の額に応じてその都度変更されることになる。

エントリー済フレンドユーザＩＤリスト５２２は、支払方法の選択において代行支払が選択された場合に、サーバシステム１１００へ問い合わせて得られた代行支払の請願先の候補とされるユーザＩＤのリストである。

請願先ユーザＩＤ５２４は、エントリー済フレンドユーザＩＤリスト５２２に含まれるユーザＩＤの中から代行支払の請願先としてプレーヤが選択したユーザＩＤを格納する。

プレイデータ５２６は、当該ゲーム端末１３００にて、自機のプレーヤキャラクタを主体としたオンラインマルチプレイゲームをプレイさせるために必要なゲーム進行状況を記述するデータ等を格納する。公知のオンラインマルチプレイゲームと同様に実現できる。

図７は、本実施形態におけるサーバシステム１１００の機能構成例を示す機能ブロック図である。本実施形態におけるサーバシステム１１００は、操作入力部１００ｓと、サーバ処理部２００ｓと、画像表示部３９２ｓと、通信部３９４ｓと、サーバ記憶部５００ｓとを備える。

操作入力部１００ｓは、サーバの管理のための各種操作を入力するための手段である。図１の例ではキーボード１１０６が該当する。

サーバ処理部２００ｓは、例えばＣＰＵやＧＰＵ等のマイクロプロセッサや、ＡＳＩＣ（特定用途向け集積回路）、ＩＣメモリなどの電子部品によって実現され、操作入力部１００ｓやサーバ記憶部５００ｓを含む各機能部との間でデータの入出力制御を行う。そして、所定のプログラムやデータ、操作入力部１００ｓからの操作入力信号、ゲーム端末１３００から受信したデータに基づいて各種の演算処理を実行して、サーバシステム１１００の動作を統合的に制御する。図１の例では制御基板１１５０が該当する。

そして、本実施形態のサーバ処理部２００ｓは、ユーザ登録管理部２４０と、ゲーム管理部２５０と、画像生成部２９２ｓと、通信制御部２９４ｓとを含む。

ユーザ登録管理部２４０は、ユーザ登録手続きに係る処理と、登録情報の管理に関する処理とを行う。
本実施形態では、１）所定の登録手続きを経たユーザすなわちプレーヤ２への固有のユーザＩＤの発給、２）電子決済用の口座の設定、３）口座への入金／出金処理、すなわち財貨情報の管理処理、４）電子決済に使用する電子決済用媒体６の紐付け処理、５）セーブデータの管理、６）フレンド登録管理処理、などを行うことができる。
なお、フレンド登録管理処理とは、プレーヤが指定したユーザＩＤ（すなわち他プレーヤ）を友人（過去に対戦した他ユーザ、過去に共闘した他ユーザを含む意味）としてフレンドリストに登録／抹消する交遊関係の設定処理である。フレンドリストに登録した他プレーヤ別の友好度パラメータをゲームプレイ結果に応じて可変する処理を更に含むとしてもよい。

また、本実施形態のユーザ登録管理部２４０は、プレイ対価支払制御部２４２を含む。
プレイ対価支払制御部２４２は、オンラインマルチプレイゲームへ参加するにあたりプレイ対価の徴収すなわち課金を行う。具体的には、エントリーされたゲーム端末１３００について、エントリーリクエストに対応づけて受信した支払ユーザＩＤ５１８及び課金額５２０（図６参照）をもとにして、支払ユーザＩＤ５１８が示すユーザＩＤに対応づけられている電子決済用の口座を特定し、特定した口座から受信した課金額５２０の電子マネーを消費（出金）させる。

ゲーム管理部２５０は、オンラインマルチプレイゲームの実行に関する各種処理を実行する。本実施形態では、ユーザＩＤ照合部２５２と、エントリー受付制御部２５４と、代行支払支援制御部２６０と、ゲーム進行制御部２７０と、特典管理部２８０と、を含む。

ユーザＩＤ照合部２５２は、ゲーム端末１３００で読み取られた電子決済用媒体６の媒体ＩＤ５１２（図６参照）に対応するユーザＩＤを提供するための制御をする。本実施形態では、ゲーム端末１３００から受信した媒体ＩＤ５１２をユーザ登録に係る情報と照合して、当該媒体ＩＤに対応付けられているユーザＩＤを抽出して返信する制御を行う。

エントリー受付制御部２５４は、オンラインマルチプレイゲームへ参加するゲーム端末１３００の受付に関する処理をする。本実施形態では、ゲーム端末１３００からエントリーリクエストと対応づけて受信した端末ＩＤ５１１と操作ユーザＩＤ５１６とを対応づけて１つのエントリーとして登録する。

代行支払支援制御部２６０は、プレーヤ間での代行支払に係る処理をする。本実施形態では、請願先候補提供部２６２と、請願仲介制御部２６４と、代行支払履歴管理部２６６と、を有する。

請願先候補提供部２６２は、ゲーム端末１３００から請願先候補の提供リクエストを受信すると、当該ゲーム端末の操作ユーザＩＤ５１６に対応するプレーヤがフレンド登録している他ユーザのユーザＩＤのリストを提供する制御を行う。本実施形態では、フレンド登録している他ユーザのユーザＩＤであって、且つ、既にエントリー済の操作ユーザＩＤに該当するユーザＩＤを抽出して「エントリー済フレンドユーザＩＤリスト」を作成してゲーム端末１３００へ返信する。

請願仲介制御部２６４は、代行支払を希望するプレーヤから代行支払をお願いするプレーヤへの代行支援の請願とその応答とを仲介する。本実施形態では、所定の請願リクエストとともに受信した請願先ユーザＩＤ５２４に対応するエントリー済のゲーム端末１３００へ承認リクエストを送信する。承認リクエストは、請願リクエストに対応づけられて受信した操作プレーヤＩＤ５１６のユーザ（代行請願ユーザ）からの代行支払の請願に対する可否を問い合わせるリクエストである。そして、対応するエントリー済のゲーム端末１３００からの返信（承認可否）を受信した場合に、その返信（承認可否）を請願リクエスト元のゲーム端末１３００へ送信（返信）する。

代行支払履歴管理部２６６は、代行支払に関する履歴を管理する。本実施形態では、代行支払が実施された支払日時と、代行支払を希望したプレーヤを示す操作プレーヤＩＤと、代行支払を請け負ったプレーヤを示す支払プレーヤＩＤと、を対応づけて１つの履歴として管理する。

ゲーム進行制御部２７０は、エントリー済の操作プレーヤＩＤが示すプレーヤのプレーヤキャラクタを登場させたオンラインマルチプレイゲームの進行制御を行う。

特典管理部２８０は、代行支払の履歴に基づいてプレーヤに特典（図４の第１の特典および第２の特典、図５の第３の特典および負の特典）を付与するための制御を行う。本実施形態では、特典付与対象抽出部２８２と、特典付与制御部２８４とを有する。

特典付与対象抽出部２８２は、
１）第２の特典に関連して、代行支払履歴の内容に基づいて、相互に代行支払ユーザとなって相手のプレイ対価を支払ったことのあるユーザの組み合わせを抽出する。換言すると、返済が成立したと判定されたユーザの組み合わせ（図４のプレーヤ２ａとプレーヤ２ｂ）を抽出する機能と、
２）第３の特典に関連して、代行支払履歴の内容に基づいて、第１ユーザ（図５のプレーヤ２ａ）が代行支払ユーザとなって第２ユーザ（図５のプレーヤ２ｂ）のプレイ対価を支払った履歴があり、且つ、所与の期間内に第２ユーザが代行支払ユーザとなって第１ユーザのプレイ対価を支払った履歴がない第１ユーザを抽出する機能と、
３）負の特典に関連して、代行支払履歴の内容に基づいて、第１ユーザ（図５のプレーヤ２ａ）が代行支払ユーザとなって第２ユーザ（図５のプレーヤ２ｂ）のプレイ対価を支払った履歴があり、且つ、所与の期間内に第２ユーザが代行支払ユーザとなって第１ユーザのプレイ対価を支払った履歴がない第２ユーザを抽出する機能と、
を有する。

特典付与制御部２８４は、
１）第１の特典に関連して、代行支払ユーザとされたユーザ（図４のプレーヤ２ａ）に、所与の特典を付与する第１の特典付与処理と、
２）第２の特典に関連して抽出されたユーザの組み合わせの一方のユーザ或いは両方のユーザに、所与の特典を付与する第２の特典付与処理と、
３）第３の特典に関連して抽出された第１ユーザに所与の特典を付与する第３の特典付与処理と、
４）負の特典に関連して抽出された第２ユーザに所与の負の特典を付与するお返し未実施時処理と、を実行する。

画像生成部２９２ｓは、サーバシステム１１００の保守に関する画像等を生成し、画像表示部３９２ｓへ出力することができる。

画像表示部３９２ｓは、画像生成部２９２ｓから入力される画像信号に基づいてシステム管理のための各種画像を表示する。例えば、フラットパネルディスプレイ、ブラウン管（ＣＲＴ）、プロジェクター、ヘッドマウントディスプレイといった画像表示装置によって実現できる。図１の例ではタッチパネル１１０８が該当する。

通信制御部２９４ｓは、データ通信に係るデータ処理を実行し、通信部３９４ｓを介して外部装置とのデータのやりとりを実現する。

通信部３９４ｓは、通信回線９と接続して通信を実現する。例えば、無線通信機、モデム、ＴＡ（ターミナルアダプタ）、有線用の通信ケーブルのジャックや制御回路等によって実現される。図１の例では通信装置１１５３が該当する。

サーバ記憶部５００ｓは、サーバ処理部２００ｓにサーバシステム１１００を統合的に制御させるための諸機能を実現するためのシステムプログラムや、ゲームを管理するために必要なプログラム、各種データ等を記憶する。また、サーバ処理部２００ｓの作業領域として用いられ、サーバ処理部２００ｓが各種プログラムに従って実行した演算結果などを一時的に記憶する。この機能は、例えばＲＡＭやＲＯＭなどのＩＣメモリ、ハードディスク等の磁気ディスク、ＣＤ−ＲＯＭやＤＶＤなどの光学ディスクなどによって実現される。図１の例では本体装置１１０１が搭載するＩＣメモリ１１５２やハードディスクなどの記憶媒体、及びストレージ１１４０がこれに該当する。

図８は、本実施形態におけるサーバ記憶部５００ｓが記憶するプログラムやデータの例を示す図である。
サーバ記憶部５００ｓは、サーバシステムプログラム５０１と、ユーザ登録管理プログラム５０３と、ゲーム管理プログラム５０５と、ゲーム端末１３００へ配信するための配信用ゲームプログラム５０７と、ゲーム端末１３００へ配信するための配信用も兼ねるゲーム初期設定データ５４０と、特典設定データ５４２と、を予め記憶する。
また、逐次生成・更新されるデータとして、ユーザ登録データ６００と、エントリー登録データ６５０と、代行支払履歴データ６６０と、オンラインマルチプレイゲームの進行状況を記述する各種データを格納するゲーム進行制御データ６７０とを記憶する。更には、その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

サーバシステムプログラム５０１は、サーバ処理部２００ｓが読み出して実行することでサーバシステム１１００にコンピュータとして必要な基本的な入出力機能を実現するためのシステムプログラムである。

ユーザ登録管理プログラム５０３は、サーバ処理部２００ｓが読み出して実行することで、ユーザ登録管理部２４０としての機能を実現させるためのプログラムである。

ゲーム管理プログラム５０５は、サーバ処理部２００ｓが読み出して実行することで、ゲーム管理部２５０としての機能を実現させるためのプログラムである。

配信用ゲームプログラム５０７は、ゲーム端末１３００へ複製して提供されるゲームプログラム５０４（図６参照）のオリジナルである。

配信用ゲームプログラム５０７は、例えば、専用のプログラムとして実現してもよい。あるいは、本実施形態のゲームをウェブゲームとして実現するならば、ウェブブラウザをベースとしてＨＴＭＬとともにＪａｖａ（登録商標）やＣＳＳ（Cascading Style Sheets）等を利用して能動的に画面表示を制御するウェブ技術や、Adobe（登録商標） Flashなどのプラグインを用いて実現できる。勿論、その他の方法でもかまわない。

ゲーム初期設定データ５４０は、オンラインマルチプレイゲームを実行するための各種初期設定データを格納し、ゲーム端末１３００への配信にも用いられる。
例えば、ゲームに登場するキャラクタのオブジェクト毎の初期状態を定義するデータを含む。より具体的には、キャラクタＩＤと対応付けて、キャラクタ属性、初期能力パラメータ値リスト、当該キャラクタを画面に表示させ、動作させるためのモデルデータやテクスチャデータ、モーションデータなどが適宜含まれているものとする。また、ゲームに登場するアイテムを定義するデータも含まれる。より具体的には、アイテムＩＤと対応づけて、当該アイテムをゲーム中に表示させるためのデータと、当該アイテムの作用効果を定義する各種パラメータ値とを格納する。勿論、これら以外のデータも適宜格納することができる。

特典設定データ５４２は、返済判定の結果にともなう第１〜第３の特典および負の特典それぞれについて、付与条件と付与される特典内容とを対応づけて定義するデータ群である。

ユーザ登録データ６００は、ユーザ登録されたプレーヤ毎に用意される。
１つのユーザ登録データ６００は、例えば図８に示すように、１）ユーザＩＤ６０２と、２）本実施形態における当該ユーザの財貨情報にあたる電子決済用口座の口座残高６０４と、３）認証登録済みの電子決済用媒体６を示す登録済媒体ＩＤ６０６と、４）フレンド登録された他ユーザＩＤを格納するフレンドリスト６０８と、５）プレーヤキャラクタセーブデータ６１０と、６）セーブされているプレーヤキャラクタのデータが当該ユーザのオリジナルか否かを示すキャラクタコピーフラグ６１２と、７）所有アイテムリスト６１４と、を含む。勿論、これら以外のデータも適宜格納することができる。

エントリー登録データ６５０は、オンラインマルチプレイゲームの参加者を示すデータを格納する。例えば、図９に示すように、エントリー日時６５１と、端末ＩＤ６５２と、操作ユーザＩＤ６５３と、支払ユーザＩＤ６５４と、を含む。勿論、これら以外のデータも適宜対応づけて含めることができる。これらに対しては、ゲーム端末１３００から所定のエントリーリクエストとともに受信した端末ＩＤ５１１、操作ユーザＩＤ５１６、支払ユーザＩＤ５１７がそれぞれ設定される。

代行支払履歴データ６６０は、代行支払が実行される毎に登録される。
例えば、図１０に示すように、支払日時６６１と、代行支払ユーザＩＤ６６２と、代行請願ユーザＩＤ６６３と、返済フラグ６６４と、を対応づけて一つの履歴とする。具体的には、エントリーリクエストとともに受信した操作ユーザＩＤ５１６と支払ユーザＩＤ５１８とが異なる場合に、受信した操作ユーザＩＤ５１６が代行請願ユーザＩＤ６６３に設定され、受信した支払ユーザＩＤ５１８が代行支払ユーザＩＤ６６２に設定される。返済フラグ６６４は、初期状態は「０（未返済）」とされ、返済判定されると「１（返済済）」に変更される（図４参照）。

［処理の流れの説明］
図１１〜図１３は、本実施形態のゲーム端末１３００における処理の流れについて説明するためのフローチャートであって、ゲーム端末１３００が端末システムプログラム５０２を実行した状態でゲームプログラム５０４を実行することにより実装される処理の流れである。

また、図１４〜図１６は、本実施形態のサーバシステム１１００における処理の流れについて説明するためのフローチャートであって、サーバシステム１１００がサーバシステムプログラム５０１を実行した状態でユーザ登録管理プログラム５０３及びゲーム管理プログラム５０５を実行することにより実装される処理の流れである。

図１１に示すように、ゲーム端末１３００ではプレーヤ登録を促す画面を表示している（ステップＳ２）。例えば、タッチパネル１３０６にソフトウェアキーボードを表示させるとともに、当該ソフトウェアキーボードでプレーヤのユーザＩＤを設定するか、所持する電子決済用媒体６を媒体読取装置１３４２にかざして設定するかを促す表示をする。

電子決済用媒体６が媒体読取装置１３４２にかざされ、これを検知すると（ステップＳ４のＹＥＳ）、ゲーム端末１３００は電子決済用媒体６から媒体ＩＤを読み出して、媒体ＩＤ５１２として一旦記憶し（ステップＳ６）、サーバシステム１１００へ所定の照合リクエストとともに端末ＩＤ５１１および媒体ＩＤ５１２を送信する（ステップＳ８）。当該送信を「通信Ａ」とする。

図１４に示すように、サーバシステム１１００は、通信Ａすなわち照合リクエストを受信すると（ステップＳ１０のＹＥＳ）、受信した媒体ＩＤ５１２に対応づけられているユーザＩＤ６０２をユーザ登録データ６００から検索し、照合結果として照合リクエスト元へ返信する（ステップＳ１２）。当該送信を「通信Ｂ」とする。

図１１に戻って、ゲーム端末１３００は通信Ｂを受信すると、受信したユーザＩＤを照合済ユーザＩＤ５１４として記憶するとともに、操作ユーザＩＤ５１６へ設定する（ステップＳ１４）。

一方、ソフトウェアキーボードへの入力が検知された場合には、その入力結果を操作ユーザＩＤ５１６に設定する（ステップＳ１６）。
ステップＳ１４またはＳ１６にてゲーム端末１３００へのプレーヤ（操作ユーザ）の登録が完了したことになる。

次に、ゲーム端末１３００は支払方法の選択受付画面を表示する（ステップＳ２０）。例えば、自身でプレイ対価を支払う「自己支払」と、他のプレーヤに代わりに支払ってもらう「代行支払」とを選択肢として含むように表示する。
そして、自己支払が選択入力された場合には（ステップＳ２２の自己支払）、ゲーム端末１３００は支払ユーザＩＤ５１８を操作ユーザＩＤ５１６と同じに設定し（ステップＳ３０：図６参照）、所定のエントリーリクエストとともに端末ＩＤ５１１と、操作ユーザＩＤ５１６と、支払ユーザＩＤ５１８と、課金額５２０とをサーバシステム１１００へ送信する（ステップＳ３２）。当該送信を「通信Ｃ」とする。

図１４に移って、サーバシステム１１００は、通信Ｃすなわちエントリーリクエストを受信すると（ステップＳ３６のＹＥＳ）、エントリーリクエスト元のゲーム端末１３００をエントリー登録データ６５０に登録する（ステップＳ３８：図９参照）。具体的には、現在日時をエントリー日時６５１に設定し、端末ＩＤ６５２に受信した端末ＩＤ５１１を設定し、操作ユーザＩＤ６５３に受信した操作ユーザＩＤ５１６を設定し、支払ユーザＩＤ６５４に受信した支払ユーザＩＤ５１８を設定する。

そして、受信した支払ユーザＩＤ５１８に一致するユーザＩＤ６０２のユーザ登録データ６００を検索し、その口座残高６０４から受信した課金額を消費制御する（ステップＳ４０）。すなわち、自己支払を選択すると操作ユーザＩＤが示すプレーヤ自信の口座でプレイ対価の支払が行われる。なお、第２特典として、「プレイ対価の支払いの割引」を採用する構成では、操作ユーザＩＤ６５３と支払ユーザＩＤ６５４とが同一である場合には割引を適用せずに課金処理し、異なる場合には割引を適用して課金処理すればよい。

図１１に戻って、支払方法として「代行支払」を選択した場合には（ステップＳ２２の代行支払）、図１２に移って、ゲーム端末１３００は請願先候補の提供リクエストとともに、端末ＩＤ５１１と操作ユーザＩＤ５１６（代行請願ユーザのＩＤ）をサーバシステム１１００へ送信する（ステップＳ５０）。当該通信を「通信Ｄ」とする。

図１５に移って、サーバシステム１１００は通信Ｄすなわち請願先候補の提供リクエストを受信すると（ステップＳ５２のＹＥＳ）、エントリー済フレンドユーザリストを生成して、リクエスト元へ返信する（ステップＳ５４）。当該通信を「通信Ｅ」とする。
具体的には、エントリー登録データ６５０および受信した操作ユーザＩＤ５１６に対応するユーザ登録データ６００を参照して、既にエントリー済の操作ユーザＩＤ６５３の中から、フレンドリスト６０８に登録されているユーザＩＤ（フレンドユーザのユーザＩＤ）を抽出する。次いで、代行支払履歴データ６６０を参照して、抽出したユーザＩＤ別に、過去所定期間（例えば、当日、３日、１週間など）における代行支払額の合計を算出する。そして、算出した合計が、所定の上限値（例えば１０回分のプレイ額）に達していないユーザＩＤでもって「エントリー済フレンドユーザＩＤリスト」を生成し返信する。なお、フレンドユーザのユーザＩＤの抽出の結果、該当するユーザＩＤが無い場合でも、該当無しの状態で「エントリー済フレンドユーザＩＤリスト」は送信される。

図１２に戻って、ゲーム端末１３００は当該通信Ｅを受信すると、エントリー済フレンドユーザＩＤリスト５２２としてこれを記憶する（図６参照）。
そして、このエントリー済フレンドユーザＩＤリスト５２２に代行支払を請願できるユーザＩＤが含まれていなければ、すなわちステップＳ５４の抽出結果が該当無しの場合（ステップＳ５６のＮＯ）、プレーヤに向けて代行支払できない旨の通知を行って（ステップＳ５８）、支払方法の選択受付に戻る。

一方、エントリー済フレンドユーザＩＤリスト５２２にユーザＩＤが含まれていれば（ステップＳ５６のＹＥＳ）、代行支払を請願できる先があることになる。ゲーム端末１３００はそのユーザＩＤを選択肢とする代行支払請願先の選択受付を行う（ステップＳ７０）。

そして、選択操作入力が行われたならば、ゲーム端末１３００は請願リクエストとともに、端末ＩＤ５１１と、操作ユーザＩＤ５１６と、請願先ユーザＩＤ５２４（先の代行支払請願先の選択受付における選択されたユーザＩＤ）とをサーバシステム１１００へ送信する（ステップＳ７２）。当該送信を「通信Ｆ」とする。

図１５に移って、サーバシステム１１００は、通信Ｆすなわち請願リクエストを受信すると（ステップＳ８０のＹＥＳ）、エントリー登録データ６５０（図９参照）を参照して、当該リクエストとともに受信した請願先ユーザＩＤ５２４が操作ユーザＩＤ６５３に合致する端末ＩＤ６５２のゲーム端末１３００へ、代行支払の承認リクエストとともに、受信した操作ユーザＩＤ（すなわち代行請願ユーザのＩＤ）を送信する（ステップＳ８２）。当該送信を「通信Ｇ」とする。

図１２に戻って、ゲーム端末１３００は、通信Ｇすなわち承認リクエストを受信すると（ステップＳ９０のＹＥＳ）、受信した請願リクエスト元の操作ユーザＩＤ５１６のプレーヤへの代行支払に応じるか否かの選択受付画面を表示し、選択入力を受け付ける（ステップＳ９２）。そして、承認可否の結果をサーバシステム１１００へ返信する（ステップＳ９４）。当該返信を「通信Ｈ」とする。

図１５に移って、サーバシステム１１００は、通信Ｈで受信した承認可否の結果を、請願リクエスト元へ返信する（ステップＳ１００）。当該返信を「通信Ｊ」とする。

再び図１２に戻って、ゲーム端末１３００は、通信Ｊすなわち代行支払への承認可否の結果を受信する。そして、代行支払が承認されなかったならば（ステップＳ１０６のＮＯ）、代行支払が不可能である旨をプレーヤに通知して（ステップＳ１０８）、ステップＳ２０の支払方法の選択受付に戻る（図１１参照）。

もし、代行支払が承認されたならば（ステップＳ１０６のＹＥＳ）、ゲーム端末１３００は請願先ユーザＩＤ５２４を支払ユーザＩＤ５１８に設定する（ステップＳ１１０）。
そして、エントリーリクエストとともに、端末ＩＤ５１１と、操作ユーザＩＤ５１６と、支払ユーザＩＤ５１８と、課金額５２０とをサーバシステム１１００へ送信する（ステップＳ１１２）。当該通信は「通信Ｃ」となる。

図１４に移って、サーバシステム１１００は、通信Ｃを受信すると、エントリー手続きと課金処理をする（ステップＳ３６〜Ｓ４０）。
そして、受信した操作ユーザＩＤ５１６と受信した支払ユーザＩＤ５１８とが同一でなければ（ステップＳ１５０のＮＯ）、サーバシステム１１００はユーザ登録データ６００を参照して、受信した操作ユーザＩＤ５１６の登録有無を判定する。もし、未登録であれば（ステップＳ１５２のＮＯ）、当該操作ユーザＩＤで新たな新規ユーザ登録を実行する（ステップＳ１５４）。

新規登録されたばかりでは、プレーヤキャラクタが未設定なので、サーバシステム１１００は、暫定のプレーヤキャラクタを自動生成して設定する（ステップＳ１５６）。
具体的には、エントリーリクエストとともに受信した支払ユーザＩＤ５１８に対応するプレーヤキャラクタセーブデータ６１０を元にして、その一部を改変して類似のキャラクタを自動生成し、これをステップＳ１５４で新規登録されたばかりのユーザ登録データ６００のプレーヤキャラクタセーブデータ６１０に設定し、キャラクタコピーフラグ６１２を「１（写）」に設定する。つまり、代行支払のついでに、ゲームで使用するキャラクタも暫定的に提供してもらう。

次に、サーバシステム１１００は、代行支払履歴に新しい履歴を追加し（ステップＳ１５８）、受信した支払ユーザＩＤ５１６のプレーヤへ代行支払を承認したことへの感謝の証しとして第１の特典を付与する（ステップＳ１６０：図４参照））。尚、第１の特典を返済成立とともに付与する、或いは第２の特典と共通化する構成とするならば、当該ステップを省略することができる。

さて、図１５に移って、エントリー終了条件（例えば、最初のエントリーリクエスト受信から所定時間経過）が満たされると（ステップＳ１７０のＹＥＳ）、サーバシステム１１００はエントリー済のゲーム端末１３００へゲーム開始信号を送信する（ステップＳ１７２）。当該送信を「通信Ｋ」とする。そして、サーバシステム１１００は、マルチプレイゲームの進行制御を開始する（ステップＳ１７４）。

図１２に戻って、ゲーム端末１３００はゲーム開始信号の受信待ちの状態にある（ステップＳ１７６，Ｓ１７８）。通信Ｋすなわちゲーム開始信号を受信すると（ステップＳ１７６のＹＥＳ、Ｓ１７８のＹＥＳ）、図１３に移って、ゲームプレイ制御を開始して、サーバシステム１１００と逐次通信して、オンラインマルチプレイゲームをプレイ可能にする（ステップＳ１８０）。当該逐次通信を「通信Ｌ」とする。

図１６に移って、オンラインマルチプレイゲームのゲーム終了条件が満たされると（ステップＳ２００のＹＥＳ）、サーバシステム１１００はゲームの進行制御を終了してゲーム終了信号をエントリーしていたゲーム端末１３００へ送信する（ステップＳ２０２）。当該送信を「通信Ｍ」とする。

図１３に移って、ゲーム端末１３００は通信Ｍすなわちゲーム終了信号を受信すると（ステップＳ２０４のＹＥＳ）、ゲームプレイ制御を終了する（ステップＳ２０６）。

図１６に戻って、ゲーム終了信号を送信した後、サーバシステム１１００はキャラクタコピーフラグ６１２（図８参照）が「１」、すなわち代行支払に伴って新規登録時に暫定的に類似キャラクタが設定されているユーザ登録データ６００を検索し、当該データのプレーヤキャラクタセーブデータ６１０を削除し、キャラクタコピーフラグ６１２を「０」に戻す（ステップＳ２２０）。つまり、代行支払のついでに暫定的に提供してもらっていたキャラクタを消去する。

次に、サーバシステム１１００は今回のゲーム成績が所定基準に達したかを判定する。そして、もし達していれば（ステップＳ２２２）、今回のゲームプレイにともなって登録された代行支払履歴の返済フラグ６６４を初期状態の「０」から返済済を意味する「１」へ変更し（ステップＳ２２４：図１０参照）、返済フラグ６５４を「１」にした履歴に係る代行支払ユーザＩＤ６６２と代行請願ユーザＩＤ６６３のゲーム端末１３００へ、所定の「返済義務の取り消し信号」を送信する（ステップＳ２２６）。一緒にマルチプレイができたことによって好成績をおさめることができたため、代行支払に対する返済義務を免除することとするものである。当該送信を「通信Ｐ」とする。

図１３に移って、ゲーム端末１３００は、ゲームプレイ制御の終了後にこの通信Ｐすなわち返済義務取り消し信号を受信すると（ステップＳ２４０ＹＥＳ）、その旨を自機のプレーヤへ向けて通知する返済義務取り消し通知処理を実行して（ステップＳ２４２）、一連の処理を終了する。

図１６に戻って、サーバシステム１１００では所定周期が到来すると（ステップＳ２５０のＹＥＳ）、「返済判定及び特典付与処理」を実行して（ステップＳ２５２）、ステップＳ１０に戻る。

図１７は、本実施形態における返済判定および特典付与処理の流れを説明するためのフローチャートである。
同処理において、サーバシステム１１００は登録済みのユーザ毎にループＡを実行する（ステップＳ２６０〜Ｓ２８２）。
ループＡでは、代行支払履歴データ６６０（図１０参照）を参照して、返済フラグ６６４が「０」の履歴についてその支払日時６６１の古い順にループＢを実行する（ステップＳ２６２〜Ｓ２８０）。

ループＢでは、処理対象とされる履歴の支払日時６６１から所定期間内（例えば、１４日以内）に、当該履歴における代行支払ユーザＩＤ６６２と代行請願ユーザＩＤ６６３との関係が逆転している他の履歴を検索する（ステップＳ２６４）。換言すると、相互に代行支払ユーザとなって相手のプレイ対価を支払ったことのあるユーザの組み合わせを抽出する。

もし、該当する他の履歴が有れば（ステップＳ２６４のＹＥＳ）、サーバシステム１１００は、処理対象とされる履歴の代行支払ユーザＩＤ６６２の示すユーザと代行請願ユーザＩＤ６６３の示すユーザとに第２の特典を付与する（ステップＳ２６６）。付与対象は何れか一方としてもよい。

そして、処理対象とされる履歴の返済フラグ６６４と、該当した他の履歴のうち支払日時６６１が最も古い一つの返済フラグ６６４とを「１（返済済）」に変更し（ステップＳ２６８）、ループＢを終了する。

もし、該当する他の履歴がなければ（ステップＳ２６４のＮＯ）、サーバシステム１１００は処理対象とされる履歴の支払日時６６１から所定期間経過している場合には（ステップＳ２７０のＹＥＳ）、期間内に代行支払へのお礼が行われなかった、すなわち返済不成立と判断する。
そして、処理対象とされる履歴の代行支払ユーザＩＤ６６２の示すユーザへ第３の特典を付与する一方（ステップＳ２７２）、代行請願ユーザＩＤ６６３の示すユーザに対しては負の特典を付与する（ステップＳ２７４）。そして、次いで、処理対象とされる履歴の返済フラグ６６４を「１」に変更して（ステップＳ２７６）、ループＢを終了する。

もし、該当する他の履歴がないが、支払日時６６１から所定期間経過していなければ（ステップＳ２７０のＮＯ）、ステップＳ２７２〜Ｓ２７６はスキップしてループＢを終了する。

全ての返済フラグ６６４が「０」の全ての代行支払の履歴についてループＢを実行し（ステップＳ２８０）、且つ、全ての登録済みのユーザについてループＡを実行したならば（ステップＳ２８２）、返済判定および特典付与処理を終了する。

以上、本実施形態によれば、電子決済を利用して業務用ゲーム装置でゲームをプレイする状況において、友人間でプレイ対価の「おごり」「おごられ」を実現することができる。よって、友人同士で連れだってゲームセンターに赴いたが、誰かがプレイ対価を支払えない事態であることがその場で判明したとしても、別の人がプレイ対価の支払を代行することで、一緒にプレイすることを諦めることなくゲームを楽しむことができる。
業務用のゲーム装置でゲームプレイを行おうとする場合には、友人同士で連れだってプレイすることが多いので、こうした作用効果は利便性を高めて他のゲームとの差別化を図り、集客力を高める効果が期待できる。

また、「おごり」「おごられ」の利用に伴って、特典を付与するので更にその効果を高めることができる。特に、期間内にお返しの「おごり」「おごられ」が行われたことが確認された場合の特典（第２の特典）と、期間内にお返しが確認されなかった場合の負の特典については、安易な「おごり」「おごられ」が横行するのを抑制し、礼節ある健全な利用を促進する意味で意義が大きい。

なお、電子決済用媒体６と媒体読取装置１３４２との構成を、プレーヤ本人と公知の生体情報読取装置との構成に置換した構成も可能である。この場合、媒体ＩＤの代わりに生体情報（例えば手のひら静脈や指紋）が用いられることになるが、同様の作用効果が得られる。

また、「おごり」「おごられ」の健全な利用実現の観点からすると、代行支払の利用回数に適宜制限を設ける構成も好適である。
具体的には、
１）ステップＳ８２の前に、代行支払履歴データ６６０を参照して、請願リクエスト元の操作ユーザＩＤが代行請願ユーザＩＤ６６３に設定されていて、且つ、返済フラグ６５４が「０」である履歴の回数をカウントするステップと、
２）カウント数が所定の上限値（例えば、ゲームプレイ頻度に応じて上昇する値）に達している場合に、ステップＳ８２とステップＳ１００をスキップして、請願リクエスト元のゲーム端末１３００へ代行支払への承認不可を強制的に返信するステップと、
を加える変形例が考えられる。

〔第２実施形態〕
次に、本発明を適用した第２実施形態について説明する。なお、第１実施形態と同様の要素については同じ符号を付与して説明は省略する。

図１８は、本実施形態における代行支払の実現方法を説明するための図である。
本実施形態を第１実施形態と比較すると、エントリーまでの手順が異なる。第１実施形態では、自己支払ができないプレーヤ２ｂは、自身の操作ユーザＩＤを設定した後、サーバシステム１１００を介した代行支払の承認をエントリー済の友人であるプレーヤ２ａから得ることで代行支払を実現した。これに対して本実施形態では、サーバシステム１１００を介した代行支払の承認過程は行わない。

具体的には、代行支払の承認はエントリー前にプレーヤ間で事前に形成されたものとする。代行支払するプレーヤ２ａは、自分が使用するゲーム端末１３００ａにて電子決済用媒体６を用いてプレーヤの登録と支払口座の指定とを一度に済ませて、支払方法の選択画面で「自己支払」を選択してエントリーする。
つまり、第１実施形態と同様にして、電子決済用媒体６から読み出した媒体ＩＤ５１２に基づいて取得された照合済ユーザＩＤ５１４が、操作ユーザＩＤ５１６と支払ユーザＩＤ５１８に設定される（図６参照）。

そして、ゲーム端末１３００ａからサーバシステム１１００へは、エントリーリクエストとともに、端末ＩＤ５１１と、操作ユーザＩＤ５１６と、支払ユーザＩＤ５１８（＝操作ユーザＩＤ）と、課金額５２０とが送信されて、当該ゲーム端末１３００ａとプレーヤ２ａとが対応づけてエントリーされる。

一方、代行支払を受けるプレーヤ２ｂが使用するゲーム端末１３００ｂについては、代行支払をするプレーヤ２ａが一旦、自分の電子決済用媒体６を用いて同じようにプレーヤの登録と支払口座の指定とを一度に済ませる。
ただし、ここで支払方法として「代行支払」を選択すると、ゲーム端末１３００ｂでは支払口座の指定すなわち支払ユーザＩＤ５１８は操作ユーザＩＤ５１６と同じ初期設定のままにして、プレーヤ登録の変更プロセスが行われる。そして当該変更プロセスによって、代行支払を受けるプレーヤ２ｂが自身のユーザＩＤを別途入力するとプレーヤ登録（操作ユーザＩＤ５１６）が変更される。
そして、ゲーム端末１３００ｂからサーバシステム１１００へ、エントリーリクエストとともに、端末ＩＤ５１１と、変更後の操作ユーザＩＤ５１６と、支払ユーザＩＤ５１８（＝変更前の操作ユーザＩＤ５１６に同じ）と、課金額５２０とが送信されて、当該ゲーム端末１３００ａとプレーヤ２ａとが対応づけてエントリーされる。

従って、本実施形態におけるゲーム端末１３００の機能構成では、図１９に示すように、代行支払設定部２１０に操作ユーザ設定変更部２１９が含まれる。操作ユーザ設定変更部２１９は、代行支払選択時に、操作入力に応じて操作ユーザＩＤ５１６を電子決済用媒体６の媒体ＩＤに基づく初期設定から変更し再設定する。

また、端末記憶部５００においても、代行支払の承認プロセスに必要とされたデータ（エントリー済フレンドユーザＩＤリスト５２２と、請願先ユーザＩＤ５２４：図６参照）が省略されている。

また、本実施形態におけるサーバシステム１１００の機能構成では、図２０に示すように、同じく代行支払の承認プロセスに必要とされた機能部（代行支払支援制御部２６０）が省略されている。サーバ記憶部５００ｓに記憶されるプログラムやデータは第１実施形態と同様である。

図２１〜図２２は、本実施形態のゲーム端末１３００における処理の流れを説明するためのフローチャートである。
ここでも、第１実施形態と比較すると、主に代行支払の承認プロセスに必要とされたステップが省略されている。すなわち、ステップＳ５０〜Ｓ５８、ステップＳ７０〜Ｓ７２、ステップＳ９０〜Ｓ９４、ステップＳ１０６〜Ｓ１１２（図１２参照）が省略さている。

代わりに、本実施形態のゲーム端末１３００は、支払方法として「代行支払」が選択された場合に（ステップＳ２２の代行支払）、支払ユーザＩＤ５１８にその時点における操作ユーザＩＤ５１６を設定し（ステップＳ２４）、操作ユーザＩＤ５１６の変更受付処理を実行する（ステップＳ２６）。そして、変更操作入力に応じて操作ユーザＩＤ５１６を変更して、代行支払を受けるプレーヤ２ｂのユーザＩＤとして（ステップＳ２８）、エントリーリクエストを送信する（ステップＳ３２）。

図２３〜図２４は、本実施形態のサーバシステム１１００における処理の流れを説明するためのフローチャートである。
ここでも、第１実施形態と比較すると、主に代行支払の承認プロセスに必要とされたステップが省略されている。すなわち、ステップＳ５２〜Ｓ５４、ステップＳ８０〜Ｓ８２、ステップＳ１００（図１５参照）が省略されている。

〔第３実施形態〕
次に、本発明を適用した第３実施形態について説明する。なお、第１実施形態と同様の要素については同じ符号を付与して説明は省略する。

図２５は、本実施形態における代行支払の実現方法を説明するための図である。本実施形態を第１実施形態と比較すると、ゲームシステムの構成とエントリーまでの手順とが異なる。

先ず、ゲームシステムの構成に着目すると、第１実施形態におけるサーバシステム１１００をユーザ登録管理機能とゲーム管理機能とに機能別に分割し、前者をサーバシステム１１００Ｃとし、後者を複数のゲーム端末１３００とＬＡＮ７で接続されたターミナル装置１２００として設けている。

ターミナル装置１２００は、本実施形態における対価支払装置の一例であり、サーバ装置であってオンラインマルチプレイゲームを実現するためのゲームサーバとしても機能する。
ターミナル装置１２００は、操作画面の表示手段と操作入力手段を兼ねるタッチパネル１２０６と、電子決済用媒体６に対応する媒体読取装置１２４２（第１実施形態の媒体読取装置１３４２に相当：図２参照）と、プレイ対価の現金払い用と電子決済用の口座へ入金用とを兼ねる現金受付装置１２４３と、が搭載されており、内蔵された制御基板１２５２（第１形態の制御基板１１５０に相当：図１参照）により統合的に制御される。

次に、エントリーまでの手順に着目すると、第１実施形態においては、各プレーヤ２ａ，２ｂは各々が使用するゲーム端末１３００ａ，１３００ｂ，…にてエントリーのためのプレーヤ登録や支払方法の選択などを行ったが、本実施形態では、ゲーム端末１３００と通信接続されたターミナル装置１２００にて一括して行う。

したがって、本実施形態におけるターミナル装置１２００の機能構成例は、図２６に示すように、第１実施形態におけるゲーム端末１３００とサーバシステム１１００のゲーム管理部２５０とを混成した構成から、サーバシステム１１００を介して代行支払の承認を得るための構成を省略した構成となる。

具体的に述べると、操作入力部１００ｔは、エントリーのための各種操作を入力し、入力信号をターミナル処理部２００ｔへ出力する。図２５のタッチパネル１２０６がこれに該当する。

媒体読み取り部１０２ｔは、図２５の媒体読取装置１２４２が該当する。
現金受付部１０４ｔは、図２５の現金受付装置１２４３に該当し、ユーザにより投入された投入額情報をターミナル処理部２００ｔへ出力する。

ターミナル処理部２００ｔは、所定のプログラムやデータに基づいて演算処理等することでターミナル装置１２００を統合的に制御して、ターミナル装置１２００と複数のゲーム端末１３００にてオンラインマルチプレイゲームを実現させる。図２５の制御基板１２５２が該当する。

そして、ターミナル処理部２００ｔは、ゲーム管理部２５０Ｃと、入金受付制御部２７２と、画像生成部２９２ｔと、通信制御部２９４ｔとを有する。

本実施形態のゲーム管理部２５０Ｃは、第１実施形態におけるエントリー準備部２０２（図６参照）と、エントリー受付制御部２５４（図７参照）と、ゲーム進行制御部２７０（図７参照）との機能を兼ねている。すなわち、本実施形態のゲーム管理部２５０Ｃは、ユーザＩＤ取得制御部２０４と、操作ユーザ設定部２０５と、支払ユーザ設定部２０６と、支払方法選択受付制御部２０７と、プレイ対価支払要求部２５６と、ゲーム進行制御部２７０と、を有する。

本実施形態の支払ユーザ設定部２０６は、支払方法として代行支払が選択された場合に、プレーヤ登録（操作ユーザＩＤ５１６の設定）に使用された電子決済用媒体６とは別の、代行支払を引き受けるプレーヤ２ｂの電子決済用媒体６の媒体ＩＤを用いて設定を行う。

プレイ対価支払要求部２５６は、サーバシステム１１００へエントリーされたゲーム端末１３００別のプレイ対価の決済を要求する。本実施形態では、ゲーム端末１３００別に、対価支払リクエストと、支払ユーザＩＤ５１８と、課金額５２０とをサーバシステム１１００へ送信する制御を行う。

入金受付制御部２７２は、ユーザ別の電子マネーの口座へ仮想通貨の補充に関する処理、いわゆる電子マネーのチャージ処理を実行する。
入金受付制御部２７２は、公知の電子決済に係る技術を適用することで実現できる。例えば本実施形態では、操作入力部１００ｔにて所定の入金操作を検出すると、所定の入金手順ガイダンスをタッチパネル１２０６へ表示させる。当該ガイダンスでは、入金先口座を指定するために電子決済用媒体６を媒体読取装置１２４２へかざした後に、入金したいだけの現金を現金受付装置１２４３へ投入するように促す。そして、媒体読み取り部１０２ｔで読み出した電子決済用媒体６の媒体ＩＤと、現金受付部１０４ｔから得た入金額情報と、を所定の入金リクエストとともにサーバシステム１１００Ｃへ送信する。サーバシステム１１００Ｃでは、当該入金リクエストを受信すると、受信した媒体ＩＤに対応するユーザ登録データ６００（図２７参照）を検索し、その口座残高６０４に受信した入金額情報を所定レートで換算した仮想通貨を加算する。

画像生成部２９２ｔは、エントリーに伴う各種選択画面や入力画面の画像信号を生成し、画像表示部３９２ｔに出力し画像表示させる。画像表示部３９２ｔは、図２５のタッチパネル１２０６が該当する。

通信制御部２９４ｔは、通信回線９やＬＡＮ７を介して外部装置とのデータ通信のための処理を実行する。
通信部３９４ｔは、通信回線９やＬＡＮ７と接続して通信を実現する。図２５の制御基板１２５２が搭載する無線通信モジュール等がこれに該当する。

ターミナル記憶部５００ｔは、サーバシステムプログラム５０１と、ゲーム管理プログラム５０５と、ゲーム初期設定データ５４０と、ゲーム進行制御データ６７０と、エントリー管理データ５１０とを記憶する。勿論、その他、タイマやカウンタ、各種フラグなどの情報を適宜記憶できる。

エントリー管理データ５１０は、ゲーム端末１３００別に用意され、端末ＩＤ５１１と、媒体ＩＤ５１２と、自機におけるプレーヤ登録を示す操作ユーザＩＤ５１６と、支払ユーザＩＤ５１８と、課金額５２０とが対応付けて格納される。勿論、これら以外のデータも適宜対応付けて格納することができる。

図２７は、本実施形態におけるサーバシステム１１００Ｃの機能構成例を示す機能ブロック図である。前述のように、サーバシステム１１００Ｃは、第１実施形態におけるユーザ登録管理の機能を担っており、ユーザ登録管理サーバと呼ぶこともできる。

具体的には、サーバシステム１１００Ｃは、サーバ処理部２００ｓに、ユーザ登録管理部２４０と、ユーザＩＤ照合部２５２と、代行支払履歴管理部２６６と、特典管理部２８０とを含む。

また、サーバ記憶部５００ｓは、サーバシステムプログラム５０１と、ユーザ登録管理プログラム５０３Ｃと、特典設定データ５４２と、ユーザ登録データ６００と、代行支払履歴データ６６０と、を記憶する。なお、本実施形態におけるユーザ登録管理プログラム５０３Ｃは、サーバ処理部２００ｓにユーザ登録管理部２４０と、ユーザＩＤ照合部２５２と、代行支払履歴管理部２６６と、特典管理部２８０との機能を実現させることができるものとする。

図２８〜図２９は、本実施形態におけるターミナル装置１２００における処理の流れを説明するためのフローチャートである。
図２８に示すように、ターミナル装置１２００では先ず、ＬＡＮ７で接続されている各ゲーム端末１３００別に本実施形態におけるエントリー受付に相当するループＤを実行する（ステップＳ３〜Ｓ３３）。

ループＤでは、ターミナル装置１２００は、タッチパネル１２０６にて処理対象とするゲーム端末１３００を操作するプレーヤ登録のために、電子決済用媒体６を媒体読取装置１２４２にかざすように促す表示を行う（ステップＳ５）。そして、媒体読取装置１２４２で電子決済用媒体６を検出すると、処理対象のゲーム端末１３００用のエントリー管理データ５１０を用意して（図２６参照）、電子決済用媒体６から媒体ＩＤを読み出して媒体ＩＤ５１２に格納する（ステップＳ６）。そして、当該媒体ＩＤ５１２に対応するユーザＩＤをサーバシステム１１００Ｃから取得し（ステップＳ８）、これを操作ユーザＩＤ５１６に設定する（ステップＳ１４）。

次に、ターミナル装置１２００は、処理対象とするゲーム端末１３００における支払方法の選択操作受付画面をタッチパネル１２０６にて表示する（ステップＳ２０）。
選択操作の結果が「自己支払」であれば（ステップＳ２２の自己支払）、ターミナル装置１２００は、支払ユーザＩＤ５１８に操作ユーザＩＤ５１６を設定して（ステップＳ３０）、サーバシステム１１００Ｃへエントリーリクエストを送信し（ステップＳ３２）、処理対象とするゲーム端末１３００へのループＤの処理を終了する。

一方、選択操作の結果が「代行支払」の場合は（ステップＳ２２の代行支払）、ターミナル装置１２００は、タッチパネル１２０６にて処理対象とするゲーム端末１３００のプレイ対価支払いの代行をするプレーヤを登録するために、該当者の電子決済用媒体６を媒体読取装置１２４２にかざすように促す表示を行う（ステップＳ２３）。そして、媒体読取装置１２４２で電子決済用媒体６を検出すると、記憶されている媒体ＩＤを読み出して（ステップＳ２４）、これに対応するユーザＩＤをサーバシステム１１００Ｃから取得し、これを支払ユーザＩＤ５１８に設定する（ステップＳ２４）。そして、サーバシステム１１００Ｃへエントリーリクエストを送信し（ステップＳ３２）、処理対象とするゲーム端末１３００へのループＤの処理を終了する。

全てのゲーム端末１３００に対してループＤを実行した場合、または最初のゲーム端末１３００に対してループＤを開始してから所定時間経過した場合には、ループＤを実行していないゲーム端末１３００が残っていたとしても、強制的にループＤを終了する。
そして、図２９に移って、ターミナル装置１２００は、サーバシステム１１００Ｃへエントリーされた各操作ユーザＩＤ５１６を送信して、送信した各操作ユーザＩＤ５１６に対応するプレーヤキャラクタセーブデータ６１０の返信を受ける（ステップＳ１７３）。そして、マルチプレイゲームの進行制御を開始する（ステップＳ１７４）。

ゲーム終了条件を満たしたならば（ステップＳ２００のＹＥＳ）、ターミナル装置１２００は、進行制御を終了して所定のゲーム終了信号をサーバシステム１１００Ｃへ送信する（ステップＳ２０１）。当該送信を「通信Ｑ」とする。

図３１に移って、サーバシステム１１００Ｃは、通信Ｑすなわちゲーム終了信号を受信すると（ステップＳ２１８のＹＥＳ）、キャラクタコピーフラグ６１２（図２７参照）が「１」、すなわち代行支払に伴って新規登録時に暫定的に類似キャラクタが設定されているユーザ登録データ６００を検索し、当該データのプレーヤキャラクタセーブデータ６１０を削除し、キャラクタコピーフラグ６１２を「０」に戻す（ステップＳ２２０）。

図２９に戻って、ターミナル装置１２００は、ゲーム成績が所定基準に達している場合には（ステップＳ２２２のＹＥＳ）、所定の返済義務取り消し信号とともに、今回のゲームをプレイした操作ユーザＩＤ５１６をサーバシステム１１００Ｃへ送信する（ステップＳ２２３）。当該送信を「通信Ｒ」とする。そして、返済義務取り消しの通知を各ゲーム端末１３００にて表示させる制御をして（ステップＳ２４２）、ターミナル装置１２００での処理を終了する。

図３１に移って、サーバシステム１１００Ｃは、通信Ｒすなわち返済義務取り消し信号を受信すると（ステップＳ２４４のＹＥＳ）、代行支払履歴データ６６０（図２７、図１０参照）を参照して、当該信号とともに受信した操作ユーザＩＤが、代行支払ユーザＩＤ６６２及び代行請願ユーザＩＤ６６３とされる履歴を抽出し、そのうち最新の履歴の返済フラグ６６４を「０」から「１」へ変更する（ステップＳ２４６）。つまり、今回のゲームプレイにおいて生じた代行支払の返済義務を取り消しとする。

そして、サーバシステム１１００Ｃは、所定周期で返済判定及び特典付与処理を実行する（ステップＳ２５０〜Ｓ２５２）。

なお、ターミナル装置１２００は、複数のゲーム端末１３００の内の何れかを兼ねる構成とすることもできる。すなわち、ターミナル装置を兼ねる第１のゲーム端末にて、代行支払い先の第２のゲーム端末を選択できる構成も可能である。この場合、当該ターミナル装置を兼ねたゲーム端末１３００は現金受付装置１２４３を備えることになる。すなわち、代行支払額の一部または全部を現金により支払うことも可能となる。より具体的には、ターミナル装置を兼ねる第１のゲーム端末を代行支払するプレーヤが使用し、電子決済用媒体６を用いずに、代行支払を受ける他プレーヤの分まで第１のゲーム端末の現金受付装置１２４３を用いて現金で代行支払することも可能となる。

〔変形例〕
以上、本発明を適用した実施形態について説明したが、本発明を適用可能な形態は上記に限定されるものではなく、適宜構成要素の追加・省略・変更を施すことができる。

［その１］
例えば、上記実施形態では、ゲーム進行制御に係る主だった処理をサーバシステム１１００またはターミナル装置１２００にて実行する構成としたが、演算処理の一部をゲーム端末１３００を含めて分散して実行させることもできる。

［その２］
また、上記実施形態では参加プレーヤは全て実在するユーザであるものとして説明したが、仮想ユーザを含むとしてもよい。例えば、エントリー受付開始から所定の受付時間が経過してもエントリー済のプレーヤの人数が規程値に達しなければ、不足分を仮想ユーザとして設定する構成などが可能である。

［その３］
また、上記実施形態における電子マネーの口座は、現金による預貯金口座に置き換えた構成も可能である。

［その４］
また、上記実施形態におけるフレンドリストは、ゲーム中での会話履歴やアイテムの交換履歴等の交流があったユーザのリストに置き換えることができる。

［その５］
また、上記実施形態に、ゲーム端末別に第１特典や、第２特典、第３特典、負の特典を個別に設定できる構成を追加してもよい。
具体的には、ゲーム端末１３００にて、管理者のみが起動可能なユーティリティプログラムを実装し、当該管理者に、そのゲーム装置１３００にて適用される特典種類別（第１特典や、第２特典、第３特典、負の特典）の特典内容を複数の候補の中から選択させ、選択端末記憶部５００に特典種類選択結果を記憶させる。そして、各特典を付与するステップにおいては、この選択結果を参照して設定されている内容の特典付与することとすればよい。

２，２ａ，２ｂ…プレーヤ
６…電子決済用媒体
１０２…媒体読取部
２００…端末処理部
２００ｓ…サーバ処理部
２００ｔ…ターミナル処理部
２０２…エントリー準備部
２０４…ユーザＩＤ取得制御部
２０５…操作ユーザ設定部
２０６…支払ユーザ設定部
２０７…支払方法選択受付制御部
２１０…代行支払設定部
２１２…請願先候補取得制御部
２１４…請願リクエスト部
２１６…請願応答制御部
２１８…支払ユーザ設定変更部
２１９…操作ユーザ設定変更部
２２０…ゲーム演算部
２４０…ユーザ登録管理部
２４２…プレイ対価支払制御部
２４６…返済管理制御部
２５０…ゲーム管理部
２５２…ユーザＩＤ照合部
２５４…エントリー受付制御部
２５６…プレイ対価支払要求部
２６０…代行支払支援制御部
２６２…請願先候補提供部
２６４…請願仲介制御部
２６６…代行支払履歴管理部
２７０…ゲーム進行制御部
２８０…特典管理部
２８２…特典付与対象抽出部
２８４…特典付与制御部
５００…端末記憶部
５００ｓ…サーバ記憶部
５００ｔ…ターミナル記憶部
５０３…ユーザ登録管理プログラム
５０４…ゲームプログラム
５０５…ゲーム管理プログラム
５１０…エントリー管理データ
５１１…端末ＩＤ
５１２…媒体ＩＤ
５１４…照合済ユーザＩＤ
５１６…操作ユーザＩＤ
５１８…支払ユーザＩＤ
５２４…請願先ユーザＩＤ
５２２…エントリー済フレンドユーザＩＤリスト
５２６…プレイデータ
５４２…特典設定データ
６００…ユーザ登録データ
６０２…ユーザＩＤ
６０６…登録済媒体ＩＤ
６０４…口座残高（財貨情報）
６０８…フレンドリスト
６１０…プレーヤキャラクタセーブデータ
６１２…キャラクタコピーフラグ
６１４…所有アイテムリスト
６５０…エントリー登録データ
６５１…エントリー日時
６５２…端末ＩＤ
６５３…操作ユーザＩＤ
６５４…支払ユーザＩＤ
６５４…返済フラグ
６６０…代行支払履歴データ
６６１…支払日時
６６２…代行支払ユーザＩＤ
６６３…代行請願ユーザＩＤ
６６４…返済フラグ
１１００…サーバシステム（管理装置）
１１０１…本体装置
１１５０…制御基板
１２００…ターミナル装置（対価支払設定装置）
１２４２…媒体読取装置
１２５２…制御基板
１３００…ゲーム端末（対価支払設定装置）
１３４２…媒体読取装置
１３５０…制御基板

Claims (9)

1. ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもある前記ゲーム端末、或いは、前記ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成され、所与のプレイ対価を前記財貨情報から支払う支払ユーザが前記対価支払設定装置により設定されてエントリーが受け付けられたエントリー済ユーザが前記ゲームをプレイすることが可能となるゲームシステムであって、
   前記対価支払設定装置は、
   前記エントリーが済んでいないために前記ゲームをプレイすることが不可能な状態にある未エントリーユーザのプレイ対価の支払を代行してもらう所与の代行支払ユーザを当該未エントリーユーザの操作に基づいて設定する代行支払ユーザ設定手段、
   を備え、
   前記管理装置は、
   前記代行支払ユーザ設定手段により設定された前記代行支払ユーザを前記支払ユーザとして前記未エントリーユーザのエントリーを受け付けて、当該代行支払ユーザの財貨情報から前記未エントリーユーザのプレイ対価を消費する代行支払処理を行う代行支払処理手段と、
   前記エントリー済ユーザを登録管理するエントリー管理手段であって、前記代行支払処理手段によりエントリーが受け付けられた前記未エントリーユーザを前記エントリー済ユーザとして登録管理するエントリー管理手段と、
   を備えた、
   ゲームシステム。
2. ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもある前記ゲーム端末、或いは、前記ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成され、所与のプレイ対価を前記財貨情報から支払う支払ユーザが前記対価支払設定装置により設定されてエントリーが受け付けられたエントリー済ユーザが前記ゲームをプレイすることが可能となるゲームシステムであって、
   前記対価支払設定装置は、
   前記エントリーが済んでいない未エントリーユーザのプレイ対価の支払を代行してもらう所与の代行支払ユーザを、前記エントリー済ユーザの中から、当該未エントリーユーザの選択操作に基づいて設定する代行支払ユーザ設定手段、
   を備え、
   前記管理装置は、
   前記代行支払ユーザ設定手段により設定された前記代行支払ユーザを前記支払ユーザとして前記未エントリーユーザのエントリーを受け付けて、当該代行支払ユーザの財貨情報から前記未エントリーユーザのプレイ対価を消費する代行支払処理を行う代行支払処理手段と、
   前記エントリー済ユーザを登録管理するエントリー管理手段であって、前記代行支払処理手段によりエントリーが受け付けられた前記未エントリーユーザを前記エントリー済ユーザとして登録管理するエントリー管理手段と、
   を備えた、
   ゲームシステム。
3. 前記管理装置は、
   ユーザ登録に係る処理を行って、各ユーザのキャラクタデータを含むユーザ登録データを管理するユーザ登録管理手段と、
   前記未エントリーユーザが、前記ユーザ登録管理手段による新規のユーザ登録を行う新規登録ユーザであった場合に、当該未エントリーユーザが前記ゲームで利用するキャラクタを、前記代行支払ユーザ設定手段により設定された前記代行支払ユーザの前記キャラクタデータに基づくキャラクタとして設定する暫定キャラクタ設定手段と、
   を備えた、
   請求項１又は２に記載のゲームシステム。
4. 前記暫定キャラクタ設定手段は、前記新規登録ユーザである前記未エントリーユーザのキャラクタデータに、前記代行支払ユーザの前記キャラクタデータに基づくキャラクタのデータを暫定的に設定し、前記ゲームの終了後に当該暫定的な設定を消去する、
   請求項３に記載のゲームシステム。
5. 前記管理装置は、
   前記代行支払ユーザに、所与の特典を付与する特典付与処理を実行する特典付与手段、
   を更に備えた請求項１〜４の何れか一項に記載のゲームシステム。
6. 前記特典は、ゲーム内で利用できるアイテム又はスキルの付与、能力パラメータ値の加算、および、経験値の加算、のうちの何れかである、
   請求項５に記載のゲームシステム。
7. 前記管理装置は、
   ユーザ間の友好度合を示すパラメータを管理する手段、
   を更に備え、
   前記特典付与手段は、前記友好度合を示すパラメータに基づいて前記特典を決定して付与する、
   請求項５又は６に記載のゲームシステム。
8. ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもある前記ゲーム端末、或いは、前記ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成され、所与のプレイ対価を前記財貨情報から支払う支払ユーザが前記対価支払設定装置により設定されてエントリーが受け付けられたエントリー済ユーザが前記ゲームをプレイすることが可能となるゲームシステムの前記管理装置であって、
   前記対価支払設定装置は、前記エントリーが済んでいないために前記ゲームをプレイすることが不可能な状態にある未エントリーユーザのプレイ対価の支払を代行してもらう所与の代行支払ユーザを当該未エントリーユーザの操作に基づいて設定する代行支払ユーザ設定手段、を有しており、
   前記対価支払設定装置の前記代行支払ユーザ設定手段により設定された前記代行支払ユーザを前記支払ユーザとして前記未エントリーユーザのエントリーを受け付けて、当該代行支払ユーザの財貨情報から前記未エントリーユーザのプレイ対価を消費する代行支払処理を行う代行支払処理手段と、
   前記エントリー済ユーザを登録管理するエントリー管理手段であって、前記代行支払処理手段によりエントリーが受け付けられた前記未エントリーユーザを前記エントリー済ユーザとして登録管理するエントリー管理手段と、
   を備えた管理装置。
9. ユーザがゲーム端末を操作してプレイするゲームのプレイ対価として支払うことができる各ユーザの財貨情報を管理する管理装置と、対価支払設定装置でもある前記ゲーム端末、或いは、前記ゲーム端末と通信可能な別体の対価支払設定装置とが通信可能に構成され、所与のプレイ対価を前記財貨情報から支払う支払ユーザが前記対価支払設定装置により設定されてエントリーが受け付けられたエントリー済ユーザが前記ゲームをプレイすることが可能となるゲームシステムの前記管理装置であって、
   前記対価支払設定装置は、前記エントリーが済んでいない未エントリーユーザのプレイ対価の支払を代行してもらう所与の代行支払ユーザを、前記エントリー済ユーザの中から、当該未エントリーユーザの選択操作に基づいて設定する代行支払ユーザ設定手段、を有しており、
   前記対価支払設定装置の前記代行支払ユーザ設定手段により設定された前記代行支払ユーザを前記支払ユーザとして前記未エントリーユーザのエントリーを受け付けて、当該代行支払ユーザの財貨情報から前記未エントリーユーザのプレイ対価を消費する代行支払処理を行う代行支払処理手段と、
   前記エントリー済ユーザを登録管理するエントリー管理手段であって、前記代行支払処理手段によりエントリーが受け付けられた前記未エントリーユーザを前記エントリー済ユーザとして登録管理するエントリー管理手段と、
   を備えた管理装置。

Images