(57)【要約】【課題】不正行為を行う者が参加したユーザ間取引が成立してしまうことを抑制しつつ、不正行為を行う者が参加するおそれがなさそうなユーザ間取引を制限しないように図ることが可能なゲームシステムを提供すること。【解決手段】承認結果情報取得部１０２は、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、第１ユーザと第２ユーザとの間でユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する。ユーザ間取引許可部１０４は、承認結果情報に基づいて、第１ユーザと第２ユーザとの間でユーザ間取引を行うことを許可するか否かを決定する。【選択図】図１２
2015150207.tif 000002
【特許請求の範囲】
【請求項１】
ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段と、
前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段と、
前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可すると決定された場合に、前記第１ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第１ユーザの前記利用対象の所有状況を示すデータから取り除き、前記第２ユーザの前記利用対象の所有状況を示すデータに追加し、かつ、前記第２ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第２ユーザの前記利用対象の所有状況を示す前記データから取り除き、前記第１ユーザの前記利用対象の所有状況を示す前記データに追加することによって、前記第１ユーザと前記第２ユーザとの間の前記ユーザ間取引を実行するユーザ間取引実行手段と、
を含むことを特徴とするゲームシステム。
【請求項２】
請求項１に記載のゲームシステムにおいて、
ユーザ間の関係に関するデータに基づいて、前記第１ユーザ及び前記第２ユーザ以外のユーザのうちから前記承認権限者を設定する承認権限者設定手段を含む、
ことを特徴とするゲームシステム。
【請求項３】
請求項２に記載のゲームシステムにおいて、
前記承認権限者設定手段は、前記第１ユーザと前記第２ユーザとが一の他のユーザ又は複数の他のユーザを介して関係付けられている場合に、前記一の他のユーザ、又は、前記複数の他のユーザの全員又は一部を前記承認権限者として設定する手段を含む、
ことを特徴とするゲームシステム。
【請求項４】
請求項２又は３に記載のゲームシステムにおいて、
前記承認権限者設定手段は、前記第１ユーザと所定関係を有し、かつ、前記第２ユーザと所定関係を有する他のユーザを前記承認権限者として設定する手段を含む、
ことを特徴とするゲームシステム。
【請求項５】
請求項２乃至４のいずれかに記載のゲームシステムにおいて、
前記承認権限者設定手段は、前記第１ユーザと前記第２ユーザとが所属している前記ユーザグループに所属している他のユーザを前記承認権限者として設定する手段を含む、
ことを特徴とするゲームシステム。
【請求項６】
請求項５に記載のゲームシステムにおいて、
前記承認権限者設定手段は、前記第１ユーザと前記第２ユーザとが所属している前記ユーザグループに所属し、かつ、該ユーザグループにおいて所定の役割を担っている他のユーザを前記承認権限者として設定する手段を含む、
ことを特徴とするゲームシステム。
【請求項７】
請求項１乃至６のいずれかに記載のゲームシステムにおいて、
前記第１ユーザと前記第２ユーザとが特定関係を有する場合に、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可する特定ユーザ間取引許可手段を含み、
前記第１ユーザと前記第２ユーザとが前記特定関係を有しない場合、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かが前記ユーザ間取引許可手段によって決定される、
ことを特徴とするゲームシステム。
【請求項８】
請求項７に記載のゲームシステムにおいて、
前記第１ユーザと前記特定関係を有し、かつ、前記第２ユーザと前記特定関係を有する他のユーザを前記承認権限者として設定する手段を含む、
ことを特徴とするゲームシステム。
【請求項９】
請求項１乃至８のいずれかに記載のゲームシステムにおいて、
前記承認権限者によって承認を受ける側の複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、前記承認権限者の端末の出力手段に出力するための制御を行う第１出力制御手段と、
前記複数のユーザのうちから前記承認権限者によって選択されたユーザの間で前記ユーザ間取引を行うように提案することを示す提案情報を、前記承認権限者によって選択された前記ユーザの端末の出力手段に出力するための制御を行う第２出力制御手段と、
を含むことを特徴とするゲームシステム。
【請求項１０】
ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段と、
前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段と、
を含むことを特徴とする取引制御装置。
【請求項１１】
ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段、及び、
前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はゲームシステム、取引制御装置、及びプログラムに関する。
【背景技術】
【０００２】
ゲーム内においてユーザ間で取引を行うことができるようなユーザ間取引機能を備えるゲームシステムが知られている。例えば、ゲーム内においてユーザ間でゲームアイテムを交換できるようになっているゲームシステムが知られている。
【０００３】
このようなゲームシステムでは、詐欺等の不正行為を行う者がユーザ間取引に参加してしまうことを防止するべく、ユーザ間取引機能に制限がかけられている場合がある。例えば、特定関係を有するユーザ間でのみユーザ間取引を許可するようになっている場合がある。例えば、仲間関係（友人関係）を有するユーザ間でのみユーザ間取引を許可していたり、同じユーザグループに所属するユーザ間でのみユーザ間取引を許可していたりする場合がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−００４２１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のゲームシステムでは、上記のような制限がユーザ間取引機能にかけられていることによって、ユーザ間取引の相手が限られてしまい、不正行為を行う者を参加するおそれがなさそうなユーザ間取引までも制限されてしまっていた。
【０００６】
本発明は上記課題に鑑みてなされたものであって、その目的は、不正行為を行う者が参加したユーザ間取引が成立してしまうことを抑制しつつ、不正行為を行う者が参加するおそれがなさそうなユーザ間取引を制限しないように図ることが可能なゲームシステム、取引制御装置、及びプログラムを提供することにある。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明に係るゲームシステムは、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段と、前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段と、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可すると決定された場合に、前記第１ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第１ユーザの前記利用対象の所有状況を示すデータから取り除き、前記第２ユーザの前記利用対象の所有状況を示すデータに追加し、かつ、前記第２ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第２ユーザの前記利用対象の所有状況を示す前記データから取り除き、前記第１ユーザの前記利用対象の所有状況を示す前記データに追加することによって、前記第１ユーザと前記第２ユーザとの間の前記ユーザ間取引を実行するユーザ間取引実行手段と、を含む。
【０００８】
また、本発明に係る取引制御装置は、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段と、前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段と、を含む。
【０００９】
また、本発明に係るプログラムは、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段、及び、前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段、としてコンピュータを機能させるためのプログラムである。
【００１０】
また、本発明に係る情報記憶媒体は、上記プログラムを記録したコンピュータ読み取り可能な情報記憶媒体である。
【図面の簡単な説明】
【００１１】
【図１】本発明の実施形態に係るゲームシステムの全体構成の一例を示す図である。
【図２】ユーザ間取引機能について説明するための図である。
【図３】仲介者候補リスト画面の一例を示す図である。
【図４】取引候補リスト画面の一例を示す図である。
【図５】申込画面の一例を示す図である。
【図６】受諾画面の一例を示す図である。
【図７】確認画面の一例を示す図である。
【図８】承認画面の一例を示す図である。
【図９】取引候補リスト画面の他の一例を示す図である。
【図１０】ユーザテーブルの一例を示す図である。
【図１１】ユーザ間取引テーブルの一例を示す図である。
【図１２】第１〜第３実施形態に係るゲームシステムの機能ブロック図である。
【図１３】ゲームシステムで実行される処理の一例を示す図である。
【図１４】ゲームシステムで実行される他の処理の一例を示す図である。
【図１５】ゲームシステムで実行される他の処理の一例を示す図である。
【図１６】ユーザグループの一例を示す図である。
【図１７】第２実施形態におけるユーザ間取引機能について説明するための図である。
【図１８】ユーザテーブルの他の一例を示す図である。
【図１９】第３実施形態おけるユーザ間取引機能について説明するための図である。
【図２０】第３実施形態におけるユーザ間取引機能について説明するための図である。
【図２１】第４実施形態に係るゲームシステムの機能ブロック図である。
【図２２】第５実施形態に係るゲームシステムの概要について説明するための図である。
【図２３】第５実施形態に係るゲームシステムの機能ブロック図である。
【図２４】ユーザ間取引機能について説明するための図である。
【図２５】ユーザ間取引機能について説明するための図である。
【発明を実施するための形態】
【００１２】
以下、本発明の実施形態の例について図面に基づき詳細に説明する。
【００１３】
［第１実施形態］本発明の第１実施形態について説明する。図１は本発明の第１実施形態に係るゲームシステムの全体構成を示す。図１に示すように、本実施形態に係るゲームシステム１はゲームサーバ１０とデータベース１５と複数の端末２０とを含む。ゲームサーバ１０及び各端末２０は通信ネットワーク２に接続され、ゲームサーバ１０と各端末２０との間で相互にデータ通信が可能である。
【００１４】
ゲームサーバ１０は例えばサーバコンピュータによって実現される。図１に示すように、ゲームサーバ１０は制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は例えば一又は複数のマイクロプロセッサ等を含み、オペレーティングシステムやその他のプログラムに従って処理を実行する。記憶部１２は主記憶部（例えばＲＡＭ）及び補助記憶部（例えばハードディスクドライブ又はソリッドステートドライブ）を含む。通信部１３は通信ネットワーク２を介してデータ通信を行うためのものである。
【００１５】
ゲームサーバ１０はデータベース１５にアクセスすることが可能である。データベース１５はゲームサーバ１０に含まれていてもよいし、ゲームサーバ１０とは別のサーバコンピュータに含まれていてもよい。データベース１５には各種データが記憶される。
【００１６】
端末２０はユーザが使用するコンピュータであり、ユーザがゲームをプレイするために使用される。端末２０は、例えば、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、携帯用ゲーム機、家庭用ゲーム機（据置型ゲーム機）、又はパーソナルコンピュータ等によって実現される。図１に示すように、端末２０は制御部２１、記憶部２２、通信部２３、操作部２４、表示部２５、及び音声出力部２６を含む。
【００１７】
制御部２１、記憶部２２、及び通信部２３はゲームサーバ１０の制御部１１、記憶部１２、及び通信部１３と同様である。操作部２４は、例えばタッチパネル、キー、レバー、マウス、又はゲームコントローラ等を含み、ユーザがゲーム操作を行うためのものである。なお、操作部２４は、ユーザが音声又はジェスチャによってゲーム操作を行うためのものであってもよい。表示部２５は例えば液晶表示パネル又は有機ＥＬディスプレイ等であり、制御部２１の指示に従って画面を表示する。音声出力部２６は例えばスピーカ又はヘッドホン等であり、制御部２１の指示に従って音声データを出力する。
【００１８】
プログラムやデータは例えば通信ネットワーク２を介してゲームサーバ１０又は端末２０に供給される。なお、ゲームサーバ１０又は端末２０は、情報記憶媒体（例えば光ディスク又はメモリカード等）に記憶されたプログラム又はデータを読み取るための構成要素を含むようにしてもよい。そして、情報記憶媒体を介してゲームサーバ１０又は端末２０にプログラムやデータを供給するようにしてもよい。
【００１９】
ゲームシステム１では各種ゲームを実行することが可能である。例えば、ゲームシステム１で実行されるゲームはユーザ間取引機能を備えており、ゲーム内においてユーザ間取引を行うことが可能になっている。
【００２０】
「ユーザ間取引」とはゲーム内においてユーザ間で行われる取引である。また、「ユーザ間取引」では、例えばゲームにおいて利用される利用対象が取引の対象とされる。「ゲームにおいて利用される利用対象」とは、例えば、ゲームにおいて利用されるオブジェクト又はポイント等である。また、「ゲームにおいて利用されるオブジェクト」とは、例えば、ゲームにおいて利用されるゲームアイテム、ゲームカード、又はゲームキャラクタ等である。一方、「ゲームにおいて利用されるポイント」とは、例えば、ゲーム内通貨として利用されるポイントである。なお、ゲームによっては、ユーザによって所定のコマンドが実行されるごとにポイントが消費され、時間経過とともに、消費されたポイントが回復するようになっている場合がある。このようなポイントも「ゲームにおいて利用されるポイント」の一例に相当する。
【００２１】
例えば、ユーザ間で行われる譲渡が「ユーザ間取引」の一例に相当する。例えば、第１ユーザが第２ユーザとゲームアイテムを交換することや、第１ユーザが第２ユーザからゲームアイテムを購入すること等が「ユーザ間取引」の一例に相当する。また例えば、ユーザ間で行われる貸与も「ユーザ間取引」の一例に相当し得る。例えば、第１ユーザが第２ユーザにゲームアイテムを貸すことも「ユーザ間取引」の一例に相当し得る。
【００２２】
以下では、ユーザ間取引機能を備えたゲームの一例として、ゲーム内においてユーザ間でゲームアイテムの交換を行うことが可能なゲームについて説明する。
【００２３】
ゲームシステム１では、原則として、特定関係を有するユーザ間で取引を行うことが許容される。例えば、ユーザ同士が仲間関係（又は友人関係）を結ぶことが可能になっており、原則として、仲間関係を有するユーザ間で取引を行うことが許容される。
【００２４】
例えば、「仲間関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが申請を承諾することによって成立する。また例えば、「仲間関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが該一方のユーザと関係を結ぶことを申請したことによって成立する場合もある。また例えば、「仲間関係」は、ゲームシステム１が二名のユーザに関係を結ぶことを提案し、双方のユーザが提案を承諾することによって成立する場合もある。また例えば、「仲間関係」は、ゲームシステム１が自動的（強制的）に二名のユーザの間に関係を結ばせる場合もある。
【００２５】
またゲームシステム１では、仲間関係を有しないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、仲間関係を有しないユーザ間でも取引を行うことが可能である。
【００２６】
図２は上記のユーザ間取引機能について説明するための図であり、三名のユーザＡ，Ｂ，Ｃの関係の一例を示す。図２に示す例では、ユーザＡ，Ｃは仲間関係を有しているため、ユーザＡ，Ｃの間で取引を行うことが可能である。同様に、ユーザＢ，Ｃは仲間関係を有しているため、ユーザＢ，Ｃの間で取引を行うことが可能である。
【００２７】
さらにゲームシステム１では、ユーザＡ，Ｂの両方と仲間関係を有するユーザＣが承認すれば、仲間関係を有しないユーザＡ，Ｂの間でも取引を行うことが可能である。言い換えれば、ユーザＡ，Ｂの両方と仲間関係を有するユーザＣが仲介者（承認権限者）となることによって、仲間関係を有しないユーザＡ，Ｂの間でも取引を行うことが可能である。
【００２８】
図３〜図９は、仲間関係を有しないユーザＡ，Ｂの間で取引が成立するまでの流れの一例を説明するための図であり、端末２０に表示される画面の一例を示す。
【００２９】
図３〜図９に示す各画面は、端末２０がゲームサーバ１０にアクセスすることによって端末２０の表示部２５に表示される。すなわち、端末２０がゲームサーバ１０とデータを送受信することによって、画面が表示部２５に表示される。例えば、端末２０は処理要求を示すデータをゲームサーバ１０に送信する。この処理要求がゲームサーバ１０で受信された場合、ゲームサーバ１０は処理要求に応じて処理を実行し、処理結果を示すデータを、処理要求の送信元である端末２０に返信する。このようなデータの送受信が端末２０とゲームサーバ１０との間で実行されることによって、画面が表示部２５に表示される。
【００３０】
例えば、仲間関係を有しないユーザとの取引をユーザＡが望む場合、まず、ユーザＡは自らと仲間関係を有するユーザのうちから仲介者（承認権限者）を選択する。図３は仲介者を選択するための仲介者候補リスト画面の一例を示す。
【００３１】
仲介者候補リスト画面３０には、ユーザＡと仲間関係を有するユーザが仲介者候補として表示される。なお図３において、各仲介者候補に関連づけられた括弧内の数値は、仲介者候補と仲間関係を有しているユーザの人数を示す。言い換えれば、括弧内の数値は、仲介者候補がユーザＡに紹介できる取引相手の人数を示す。
【００３２】
ユーザＡは、仲介者候補リスト画面３０に表示される仲介者候補のうちのいずれかを仲介者として選択する。仲介者が選択された場合、取引候補リスト画面がユーザＡの端末２０の表示部２５に表示される。図４は取引候補リスト画面の一例を示す。ここでは、ユーザＣが仲介者として選択された場合を想定する。
【００３３】
図４に示すように、取引候補リスト画面４０には、ユーザＣと仲間関係を有するユーザの所望アイテムリストが表示される。ゲームシステム１では、各ユーザが所望のゲームアイテムを登録できるようになっており、所望アイテムリストはユーザによって登録された所望のゲームアイテムのリストを示す。
【００３４】
例えば、図４に記載された「ゲームアイテムＶ（ユーザＰさん）」は、ユーザＰがゲームアイテムＶを所望アイテムリストに登録していることを示す。また、取引候補リスト画面４０では、ユーザＡが所有しているゲームアイテムに「所有」との文字列が関連づけられる。例えば図４に示す例では、ユーザＰが所望しているゲームアイテムＶや、ユーザＢが所望しているゲームアイテムＸをユーザＡが所有していることが示されている。
【００３５】
ユーザＡは取引候補リスト画面４０に表示されるゲームアイテムのうちのいずれかを選択する。例えば、ユーザＡは自らが所有しているゲームアイテムを選択することが可能である。いずれかのゲームアイテムが選択された場合、申込画面がユーザＡの端末２０の表示部２５に表示される。
【００３６】
なお、取引候補リスト画面４０には「戻る」ボタン４２が表示されており、「戻る」ボタン４２が選択された場合には仲介者候補リスト画面３０に戻る。
【００３７】
図５は申込画面の一例を示す。ここでは、ユーザＢが所望しているゲームアイテムＢが取引候補リスト画面４０で選択された場合を想定する。すなわち、ユーザＢが取引相手として選択され、かつ、ゲームアイテムＢが取引対象として選択された場合を想定する。
【００３８】
図５に示すように、申込画面５０は所望アイテム欄５６及びコメント欄５８を含む。ユーザＡはユーザＢにゲームアイテムＸを提供する対価としてユーザＢから入手したいゲームアイテムを設定できるようになっており、所望アイテム欄５６には、ユーザＢから入手したいゲームアイテムとしてユーザＡが設定したゲームアイテムが表示される。また、ユーザＡはユーザＢへのコメントを入力できるようになっており、コメント欄５８には、ユーザＡによって入力されたコメントが表示される。図５に示す例では、ユーザＢから入手したいゲームアイテムが所望アイテム欄５６に設定されていない。その代わりに、ゲームアイテムＹをほしい旨がコメント欄５８に入力されている。
【００３９】
また、申込画面５０には「はい」ボタン５２及び「いいえ」ボタン５４が表示される。「はい」ボタン５２が選択された場合、取引の申込内容がデータベース１５に登録され、ユーザＡからユーザＢへの取引申込が受け付けられる。一方、「いいえ」ボタン５４が選択された場合、取引候補リスト画面４０に戻る。
【００４０】
ユーザＡからユーザＢへの取引申込が行われた場合には、その旨がユーザＢに通知される。例えば、ユーザＡからの申し込みが行われた後でユーザＢがゲームシステム１にアクセスした際に、ユーザＡからの申し込みがある旨がトップ画面（図示せず）に表示される。ここで、「トップ画面」とは、例えばユーザＢ専用のトップ画面のことを意味しており、このトップ画面にはユーザＢへの各種お知らせが表示される。なお、ユーザＢへの上記通知は、例えば電子メール等を介して行われるようにしてもよい。
【００４１】
上記通知を受けたユーザＢはユーザＡからの申し込みを受諾するか否かを選択する。図６はユーザＢの端末２０の表示部２５に表示される受諾画面の一例を示す。図６に示すように、受諾画面６０にはユーザＡから申し込まれた取引の内容が表示される。
【００４２】
受諾画面６０には「はい」ボタン６２及び「いいえ」ボタン６４が表示される。「いいえ」ボタン６４が選択された場合、ユーザＢがユーザＡからの申し込みを受諾しなかった旨がデータベース１５に登録され、ユーザＡに通知される。なお、所定の受諾期限内にユーザＢがユーザＡからの申し込みを受諾しなかった場合も同様である。
【００４３】
一方、「はい」ボタン６２を選択された場合、ユーザＢが所有しているゲームアイテムのうちから、ユーザＡに提供するゲームアイテムが選択され、確認画面が表示される。
【００４４】
図７はユーザＢの端末２０の表示部２５に表示される確認画面の一例を示す。ここでは、ユーザＢがゲームアイテムＹをユーザＡに提供するゲームアイテムとして選択した場合を想定する。図７に示すように、確認画面７０は、ユーザＡとの取引を実行してもよいか否かをユーザＢに確認するための画面である。
【００４５】
確認画面７０には「はい」ボタン７２及び「いいえ」ボタン７４が表示される。「いいえ」ボタン７４が選択された場合、受諾画面６０に戻る。
【００４６】
一方、「はい」ボタン７２が選択された場合、ユーザＢがユーザＡからの申し込みを受諾した旨がデータベース１５に登録され、ユーザＡ，Ｂが取引を希望していることが仲介者（ユーザＣ）に通知される。例えば、ユーザＢがユーザＡからの申し込みを受諾した後でユーザＣがゲームシステム１にアクセスした際に、ユーザＡ，Ｂが取引を希望している旨がトップ画面に表示される。または、例えば電子メール等を介して、ユーザＡ，Ｂが取引を希望している旨がユーザＣに通知される。
【００４７】
上記通知を受けたユーザＣはユーザＡ，Ｂの間の取引を承認するか否かを選択する。図８は、ユーザＣの端末２０の表示部２５に表示される承認画面の一例を示す。図８に示すように、承認画面８０にはユーザＡ，Ｂの間で行われようとしている取引の内容が表示される。また承認画面８０にはユーザＡの申込内容も表示される。これらに基づいて、ユーザＣはこの取引を承認してもよいか否かを判断する。
【００４８】
承認画面８０には「はい」ボタン８２及び「いいえ」ボタン８４が表示される。「いいえ」ボタン８４が選択された場合、すなわち、ユーザＣが取引を承認しなかった場合には取引が不成立となる。そして、取引が不成立になった旨がデータベース１５に登録され、ユーザＡ，Ｂに通知される。なお、所定の承認期限内にユーザＣが取引を承認しなかった場合も同様である。
【００４９】
一方、「はい」ボタン８２が選択された場合、すなわち、ユーザＣが取引を承認した場合には取引が成立となり、ユーザＡ，Ｂの間の取引が実行される。すなわち、取引が成立になった旨がデータベース１５に登録されるとともに、ユーザＡ，Ｂの間でゲームアイテムの交換が実行される。そして、その旨がユーザＡ，Ｂに通知される。
【００５０】
ゲームシステム１では、仲間関係を有しないユーザＡ，Ｂの間の取引が上記のようにして実行される。すなわち、ユーザＡ，Ｂの両方と仲間関係を有するユーザＣ（仲介者：承認権限者）によって承認されることによって、ユーザＡ，Ｂの間の取引が成立する。ゲームシステム１によれば、取引を行うユーザの両方と仲間関係を有するユーザによって取引の内容が確認されることになるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム１によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
【００５１】
なお、上記に説明した例では、ユーザが所望アイテムリストを登録できるようになっていたが、ユーザは所望の交換条件（すなわち、他のユーザから入手したいゲームアイテムと、その対価として他のユーザに提供したいゲームアイテムとの組合せ）のリストを登録できるようにしてもよい。
【００５２】
図９はこの場合の取引候補リスト画面４０の一例を示す。図９に示す例において、「ゲームアイテムＸ−ゲームアイテムＹ（ユーザＢさん）」は、ユーザＢが自らの所有するゲームアイテムＹと他のユーザが所有するゲームアイテムＸとを交換することを希望していることを示す。例えば、図９に示す取引候補リスト画面４０において、ユーザＢが取引相手として選択され、かつ、取引対象としてゲームアイテムＸ，Ｙが選択された場合には、申込画面５０の所望アイテム欄５６にゲームアイテムＹが自動的に表示される。
【００５３】
次に、上記に説明した機能を実現するための構成について説明する。まず、データベース１５に記憶されるデータについて説明する。図１０及び図１１は、データベース１５に記憶されるデータのうちのユーザ間取引機能に関連するデータの一例を示す。
【００５４】
図１０はユーザテーブルの一例を示す。ユーザテーブルはゲームシステム１を利用するユーザのリストを示す。図１０に示すユーザテーブルは「ユーザＩＤ」、「ユーザ名」、「仲間」、「所有アイテム」、「所望アイテム」、及び「出品アイテム」フィールドを含む。「ユーザＩＤ」フィールドはユーザを一意に識別するための識別情報を示す。「ユーザ名」フィールドはユーザの名前を示す。
【００５５】
「仲間」フィールドには、ユーザと仲間関係を有しているユーザのリストが登録される。「所有アイテム」フィールドには、ユーザが所有しているゲームアイテムのリストが登録される。「所望アイテム」フィールドには、ユーザが所望しているゲームアイテムのリストが登録される。「出品アイテム」フィールドには、ユーザが他のユーザに提供したいと考えているゲームアイテムのリストが登録される。なお例えば、ユーザが仲間関係を有しているユーザのリストはユーザテーブルとは別個のテーブルに登録されるのが一般的であるが、ここでは、便宜上、ユーザが仲間関係を有しているユーザのリストがユーザテーブル内に記憶されることとしている。所有アイテムリスト、所望アイテムリストや、出品リストに関しても同様である。
【００５６】
図１１はユーザ間取引テーブルの一例を示す。ユーザ間取引テーブルはゲーム内で行われるユーザ間取引に関する情報を示す。図１１に示すユーザ間取引テーブルは「取引ＩＤ」、「申込者」、「取引相手」、「承認権限者」、「申込日時」、「アイテム１」、「アイテム２」、「コメント」、「アイテム３」、「受諾結果」、「承認結果」、「状況」、及び「更新日時」フィールドを含む。
【００５７】
「取引ＩＤ」フィールドは取引を一意に識別するための識別情報を示す。「申込者」フィールドは取引を申し込んだユーザを示す。「取引相手」フィールドは取引を申し込まれたユーザを示す。「承認権限者」フィールドは承認権限者（仲介者）として設定されたユーザを示す。
【００５８】
「アイテム１」フィールドには申込者が取引相手に提供するゲームアイテムが登録される。また、「アイテム２」フィールドには申込者が取引相手から入手したいゲームアイテムが登録される。さらに、「コメント」フィールドには申込者によって入力されたコメントが登録される。
【００５９】
「アイテム３」フィールドには取引相手が申込者に提供するゲームアイテムが登録される。「受諾結果」フィールドには取引相手の受諾結果が登録される。例えば、値「０」又は「１」が「受諾結果」フィールドに登録される。値「０」は受諾されていないことを示し、値「１」は受諾されたことを示す。「受諾承認結果」フィールドには承認権限者の承認結果が登録される。例えば、値「０」又は「１」が「承認結果」フィールドに登録される。値「０」は承認されていないことを示し、値「１」は承認されたことを示す。
【００６０】
「状況」フィールドは取引の現在の状況を示し、「更新日時」フィールドは「状況」フィールドが更新された日時を示す。例えば、値「０」〜「３」が「状況」フィールドに登録される。これら値は下記のような状況を示す。
（０）取引相手の受諾待ち
（１）承認権限者の承認待ち
（２）取引成立
（３）取引不成立
【００６１】
なお、図１０及び図１１に示したユーザテーブル及びユーザ間取引テーブルは、ユーザ間取引の対象がゲームアイテムである場合のユーザテーブル及びユーザ間取引テーブルの一例を示している。例えば、ユーザ間取引の対象がゲームカードである場合には、「所有アイテム」、「所望アイテム」、及び「出品アイテム」フィールドの代わりに、「所有カード」、「所望カード」、及び「出品カード」フィールドがユーザテーブルに含まれることになる。同様に、「アイテム１」、「アイテム２」、及び「アイテム３」フィールドの代わりに、「カード１」、「カード２」、及び「カード３」フィールドがユーザ間取引テーブルに含まれることになる。
【００６２】
次に、ゲームシステム１で実現される機能ブロックについて説明する。図１２は、ゲームシステム１で実現される機能ブロックを示す機能ブロック図である。図１２に示すように、ゲームシステム１は承認権限者設定部１００、承認結果情報取得部１０２、ユーザ間取引許可部１０４、特定ユーザ間取引許可部１０６、及びユーザ間取引実行部１０８を含む。これらの機能ブロックはゲームサーバ１０の制御部１１によって実現される。すなわち、制御部１１がプログラムに従って処理を実行することによって、制御部１１がこれらの機能ブロックとして機能するようになる。
【００６３】
特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザとが特定関係を有する場合に、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可する。
【００６４】
まず、「ユーザ間取引」について説明する。先述したように、「ユーザ間取引」とはゲーム内においてユーザ間で行われる取引である。例えば、ユーザ間で行われる譲渡が「ユーザ間取引」の一例に相当する。「譲渡」は有償譲渡であってもよいし、無償譲渡であってもよい。「有償譲渡」には交換又は売買が含まれる。例えば、第１ユーザが第２ユーザとゲームアイテムを交換することや、第１ユーザが第２ユーザからゲームアイテムを購入すること等が「ユーザ間取引」の一例に相当する。
【００６５】
また例えば、ユーザ間で行われる貸与も「ユーザ間取引」の一例に相当し得る。「貸与」は有償貸与であってもよいし、無償貸与であってもよい。例えば、第１ユーザが第２ユーザにゲームアイテムを貸すことも「ユーザ間取引」の一例に相当し得る。
【００６６】
次に、「特定関係」について説明する。例えば、第１ユーザに関する情報に第２ユーザに関する情報が含まれている場合に、第１ユーザと第２ユーザとが特定関係を有していると判定される。例えば、第１ユーザに関する情報に第２ユーザに関する情報が含まれており、かつ、第２ユーザに関する情報に第１ユーザに関する情報が含まれている場合に、第１ユーザと第２ユーザとが特定関係を有していると判定される。
【００６７】
また例えば、第１ユーザと第２ユーザとを関連づけるデータがデータベース１５（記憶装置）に記憶されている場合に、第１ユーザと第２ユーザとが特定関係を有していると判定される。例えば、第１ユーザの識別情報と第２ユーザの識別情報とが関連づけられている場合に、第１ユーザと第２ユーザとが特定関係を有していると判定される。
【００６８】
また例えば、「特定関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが申請を承諾することによって成立するような関係である。また例えば、「特定関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが該一方のユーザと関係を結ぶことを申請することによって成立するような関係であってもよい。また例えば、「特定関係」は、ゲームシステム１が複数のユーザが互いに関係を結ぶように提案し、それら複数のユーザが提案を承諾した場合に成立するような関係であってもよい。また例えば、「特定関係」は、ゲームシステム１が自動的（強制的）に複数のユーザに関係を結ばせることによって成立するような関係であってもよい。
【００６９】
図２〜図９に示した例の場合、仲間関係（又は友人関係）が「特定関係」の一例に相当し、ゲームアイテムの交換が「ユーザ間取引」の一例に相当する。このため、例えば、特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザとが仲間関係を有している場合に、ゲーム内におけるゲームアイテムの交換を第１ユーザと第２ユーザとの間で行うことを許可する。
【００７０】
承認権限者設定部１００は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。
【００７１】
例えば、承認権限者設定部１００は、ユーザ間の関係に関するデータに基づいて、第１ユーザ及び第２ユーザ以外のユーザのうちから承認権限者を設定する。ここで、「ユーザ間の関係」とは「ゲーム内において築かれるユーザ間の関係」のことを意味する。例えば、上記の特定関係や仲間関係（又は友人関係）が「ユーザ間の関係」の一例に相当する。また、例えば、上記の特定関係や仲間関係（又は友人関係）を示すデータが「ユーザ間の関係に関するデータ」の一例に相当する。例えば、ユーザテーブルの「ユーザＩＤ」及び「仲間」フィールドが「ユーザ間の関係に関するデータ」の一例に相当する。
【００７２】
例えば、第１ユーザと第２ユーザとが他のユーザを介して関係づけられている場合に、承認権限者設定部１００は該他のユーザを承認権限者として設定する。
【００７３】
ここで、「第１ユーザと第２ユーザとが他のユーザを介して関係づけられている」とは、例えば、第１ユーザと第２ユーザとが直接的に関係づけられていないが、他のユーザが介在することによって、第１ユーザと第２ユーザとが間接的に関係づけられている」ことを意味する。例えば、第１ユーザと第３ユーザとが直接的に関係づけられており、かつ、第３ユーザと第２ユーザとが直接的に関係づけられている場合（言い換えれば、第１ユーザと第３のユーザとが直接的な関係を築いており、かつ、第３ユーザと第２ユーザとが直接的な関係を築いている場合）に、第１ユーザと第２ユーザとが第３ユーザを介して関係づけられていることになる。このような場合に、承認権限者設定部１００は第３ユーザを承認権限者として設定する。
【００７４】
なお、承認権限者設定部１００の機能は下記のように言い換えることができる。
【００７５】
例えば、承認権限者設定部１００は、第１ユーザと所定関係を有し、かつ、第２ユーザと所定関係を有する他のユーザを承認権限者として設定する。
【００７６】
ここで、「第１ユーザと所定関係を有するユーザ」とは、例えば、第１ユーザと直接的な関係を築いているユーザである。すなわち、第１ユーザと直接的に関係づけられているユーザである。
【００７７】
例えば、上記の「特定関係」が「所定関係」の一例に相当する。このため、例えば、承認権限者設定部１００は、第１ユーザと特定関係を有し、かつ、第２ユーザと特定関係を有する他のユーザを承認権限者として設定する。
【００７８】
先述したように、図２〜図９に示した例では、仲間関係（又は友人関係）が「特定関係」の一例に相当している。このため、承認権限者設定部１００は、第１ユーザと仲間関係を有し、かつ、第２ユーザと仲間関係を有する他のユーザを承認権限者として設定する。
【００７９】
承認結果情報取得部１０２は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認権限者が承認したか否かの承認結果に関する承認結果情報を取得する。
【００８０】
ユーザ間取引許可部１０４は、承認結果情報に基づいて、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可するか否かを決定する。
【００８１】
例えば、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認権限者が承認した場合に、ユーザ間取引許可部１０４は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可すると決定する。一方、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認権限者が承認しなかった場合に、ユーザ間取引許可部１０４は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可しないと決定する。
【００８２】
本実施形態に係るゲームシステム１では、第１ユーザと第２ユーザとが特定関係を有する場合、特定ユーザ間取引許可部１０６によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可される。一方、第１ユーザと第２ユーザとが特定関係を有しない場合には、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可するか否かがユーザ間取引許可部１０４によって決定されることになる。
【００８３】
ユーザ間取引実行部１０８は、第１ユーザと第２ユーザとの間でユーザ間取引を行うことを許可すると決定された場合に、第１ユーザと第２ユーザとの間のユーザ間取引を実行する。すなわち、第１ユーザと第２ユーザとの間でユーザ間取引を行うことを許可すると決定された場合、第１ユーザと第２ユーザとの間のユーザ間取引を実行可能な状態となり、ユーザ間取引実行部１０８は第１ユーザと第２ユーザとの間のユーザ間取引を実行する。
【００８４】
例えば、ユーザ間取引実行部１０８は、第１ユーザが所有している利用対象のうちの、当該ユーザ間取引の対象である利用対象を第１ユーザの利用対象の所有状況を示すデータから取り除き、第２ユーザの利用対象の所有状況を示すデータに追加し、かつ、第２ユーザが所有している利用対象のうちの、当該ユーザ間取引の対象である利用対象を第２ユーザの利用対象の所有状況を示すデータから取り除き、第１ユーザの利用対象の所有状況を示すデータに追加することによって、第１ユーザと第２ユーザとの間のユーザ間取引を実行する。
【００８５】
先述したように、「利用対象」とはゲームにおいてユーザによって利用される対象であり、例えば、ゲームにおいて利用されるオブジェクト又はポイント等が「利用対象」の一例に相当する。例えば、ゲームにおいて利用されるゲームアイテム、ゲームカード、ゲームキャラクタ、又はゲーム内通貨等が「利用対象」の一例に相当する。
【００８６】
また、「ユーザの上記利用対象の所有状況を示すデータ」（以下「所有状況データ」と記載する。）には、例えば、ユーザが所有している利用対象のリストを示すデータが含まれる。言い換えれば、例えば、ユーザが個々の利用対象を所有しているか否かを示すデータや、ユーザが所有している個々の利用対象の量を示すデータが「所有状況データ」に含まれる。
【００８７】
例えば、ユーザが所有しているゲームアイテムのリストを示すデータが「所有状況データ」に含まれる。言い換えれば、例えば、ユーザが個々のゲームアイテムを所有しているか否かを示すデータや、ユーザが所有している個々のゲームアイテムの個数を示すデータが「所有状況データ」に含まれる。例えば、図１０に示すユーザテーブルの場合、ユーザテーブルの「所有アイテムリスト」フィールドが「所有状況データ」の一例に相当する。
【００８８】
例えば、ユーザＡ，Ｂの間の取引が「ユーザＡが所有しているゲームアイテムＸをユーザＢに譲り渡す」という取引を含む場合、ユーザ間取引実行部１０８は、ユーザＡが所有しているゲームアイテムのリストから１個のゲームアイテムＸを取り除くようにして、ユーザＡの所有状況データを更新し、ユーザＢが所有しているゲームアイテムのリストに１個のゲームアイテムＸを加えるようにして、ユーザＢの所有状況データを更新する。
【００８９】
なお、ユーザＡがゲームアイテムＸを複数所有している場合であれば、ユーザ間取引実行部１０８は、ユーザＡが所有しているゲームアイテムＸの個数が一つ減るようにして、ユーザＡの所有状況データを更新する。また、ユーザＢがゲームアイテムＸをすでに所有している場合であれば、ユーザ間取引実行部１０８は、ユーザＢが所有しているゲームアイテムＸの個数が一つ増えるようにして、ユーザＢの所有状況データを更新する。
【００９０】
なお例えば、ユーザが所有しているポイント量を示すデータも「所有状況データ」の一例に相当し得る。例えば、ユーザＡ，Ｂの間の取引が「ユーザＡからユーザＢに１００ポイントを譲り渡す」という取引を含む場合、ユーザ間取引実行部１０８は、ユーザＡが所有しているポイント量（ポイント残高）が１００ポイント減るようにして、ユーザＡの所有状況データを更新し、ユーザＢが所有しているポイント量（ポイント残高）が１００ポイント増えるようにして、ユーザＢの所有状況データを更新する。
【００９１】
なお、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが特定ユーザ間取引許可部１０６によって許可された場合にも、ユーザ間取引実行部１０８は第１ユーザと第２ユーザとの間のユーザ間取引を実行する。
【００９２】
次に、ゲームシステム１で実行される処理について説明する。図１３は、ユーザが仲間関係を有していないユーザに取引を申し込む場合に実行される処理の一例を示す。なお以下では、ユーザＡが仲間関係を有していないユーザに取引を申し込む場合を想定して上記処理について説明する。
【００９３】
図１３に示すように、まず、端末２０の制御部２１は仲介者候補リスト画面データをゲームサーバ１０に要求する（Ｓ１０１）。仲介者候補リスト画面データは仲介者候補リスト画面３０を表示するためのデータ（例えばページデータ）である。ステップＳ１０１ではユーザＡのユーザＩＤがゲームサーバ１０に送信される。
【００９４】
上記要求がゲームサーバ１０で受け付けられた場合、ゲームサーバ１０の制御部１１は仲介者候補リスト画面データをユーザＡの端末２０に送信する（Ｓ１０２）。例えば、制御部１１はユーザテーブルを参照し、ユーザＡと仲間関係を有しているユーザのリストを取得する。制御部１１はこのリストに基づいて仲介者候補リスト画面データを生成し、ユーザＡの端末２０に送信する。
【００９５】
仲介者候補リスト画面データがユーザＡの端末２０で受信された場合、端末２０の制御部２１は仲介者候補リスト画面３０を表示部２５に表示する（Ｓ１０３）。
【００９６】
仲介者候補リスト画面３０に表示される仲介者候補のうちのいずれかが仲介者（承認権限者）として選択された場合、制御部２１は取引候補リスト画面データをゲームサーバ１０に要求する（Ｓ１０４）。取引候補リスト画面データは取引候補リスト画面４０を表示するためのデータ（例えばページデータ）である。ステップＳ１０４では、ユーザＡのユーザＩＤや、仲介者として選択されたユーザのユーザＩＤがゲームサーバ１０に送信される。なお以下では、ユーザＣが仲介者として選択された場合を想定する。
【００９７】
上記要求がゲームサーバ１０で受け付けられた場合、ゲームサーバ１０の制御部１１は取引候補リスト画面データをユーザＡの端末２０に送信する（Ｓ１０５）。例えば、制御部１１はユーザテーブルを参照し、ユーザＣと仲間関係を有するユーザを特定する。すなわち、制御部１１は、ユーザＣのユーザＩＤが「仲間」フィールドに含まれているユーザを特定する。すなわち、制御部１１は、ユーザＣのユーザＩＤが関連づけられているユーザを特定する。さらに、制御部１１はユーザテーブルを参照し、ユーザＣと仲間関係を有するユーザの所望アイテムリストを取得する。そして、制御部１１はこのリストに基づいて取引候補リスト画面データを生成し、ユーザＡの端末２０に送信する。
【００９８】
取引候補リスト画面データがユーザＡの端末２０で受信された場合、端末２０の制御部２１は取引候補リスト画面４０を表示部２５に表示する（Ｓ１０６）。
【００９９】
取引候補リスト画面４０に表示される取引候補のうちのいずれかが選択された場合、制御部２１は申込画面データをゲームサーバ１０に要求する（Ｓ１０７）。申込画面データは申込画面５０を表示するためのデータ（例えばページデータ）である。ステップＳ１０７では、ステップＳ１０４で送信された情報に加えて、取引相手として選択されたユーザのユーザＩＤや、取引対象として選択されたゲームアイテムのＩＤがゲームサーバ１０に送信される。なお以下では、ユーザＢが取引相手として選択され、ゲームアイテムＸが取引対象として選択された場合を想定する。
【０１００】
上記要求がゲームサーバ１０で受け付けられた場合、ゲームサーバ１０の制御部１１は申込画面データをユーザＡの端末２０に送信する（Ｓ１０８）。申込画面データがユーザＡの端末２０で受信された場合、端末２０の制御部２１は申込画面５０を表示部２５に表示する（Ｓ１０９）。
【０１０１】
申込画面５０の「はい」ボタン５２が選択された場合、制御部２１は取引申込の受付をゲームサーバ１０に要求する（Ｓ１１０）。すなわち、申込画面５０で設定された申込内容がゲームサーバ１０に送信される。この場合、ステップＳ１０７で送信された情報に加えて、ユーザＡによって所望アイテムとして設定されたゲームアイテムのＩＤや、ユーザＡによって入力されたコメントがゲームサーバ１０に送信される。
【０１０２】
上記要求がゲームサーバ１０で受け付けられた場合、ゲームサーバ１０の制御部１１は取引申込の内容をデータベース１５に登録する（Ｓ１１１）。すなわち、取引申込の内容がユーザ間取引テーブルに登録される。
【０１０３】
例えば、ユーザ間取引テーブルに新たなレコードが追加される。そして、新たに付与された取引ＩＤが「取引ＩＤ」フィールドに登録される。ユーザＡのユーザＩＤが「申込者」フィールドに登録され、取引候補リスト画面４０で取引相手として選択されたユーザＢのユーザＩＤが「取引相手」フィールドに登録される。また、仲介者候補リスト画面３０で仲介者（承認権限者）として選択されたユーザＣのユーザＩＤが「承認権限者」フィールドに登録される。取引候補リスト画面４０で取引対象として選択されたゲームアイテムＸが「アイテム１」フィールドに登録される。申込画面５０の所望アイテム欄５６に設定されたゲームアイテムが「アイテム２」フィールドに登録され、コメント欄５８に入力されたコメントが「コメント」フィールドに登録される。さらに、値「０」（取引相手の受諾待ち）が「状況」フィールドに登録され、現在日時が「申込日時」及び「更新日時」フィールドに登録される。
【０１０４】
図１４は、ユーザＡからユーザＢへの申し込みが受け付けられた後にユーザＢがトップ画面にアクセスする場合に実行される処理の一例を示す。なお、先述したように、このトップ画面は例えばユーザＢ専用のトップ画面である。
【０１０５】
図１４に示すように、まず、ユーザＢの端末２０の制御部２１はトップ画面データをゲームサーバ１０に要求する（Ｓ２０１）。トップ画面データはトップ画面を表示するためのデータ（例えばページデータ）である。ステップＳ２０１では、ユーザＢのユーザＩＤがゲームサーバ１０に送信される。
【０１０６】
上記要求がゲームサーバ１０で受け付けられた場合、制御部１１はユーザ間取引テーブルを参照し、ユーザＢへの取引申込に関する情報を取得する（Ｓ２０２）。例えば、制御部１１は、下記のような二つの条件をすべて満足する取引に関する情報を取得する。
（１）ユーザＢが取引相手として登録されている。
（２）状況が「取引相手の受諾待ち」である。
【０１０７】
その後、制御部１１はトップ画面データをユーザＢの端末２０に送信する（Ｓ２０３）。この場合、トップ画面データにはステップＳ２０２で取得された取引申込のリストが埋め込まれる。トップ画面データがユーザＢの端末２０で受信された場合、制御部２１はトップ画面を表示部２５に表示する（Ｓ２０４）。この場合、ユーザＢへの取引申込のリストがトップ画面に表示される。
【０１０８】
トップ画面に表示された取引申込のいずれかがユーザＢによって選択された場合、制御部２１は受諾画面データをゲームサーバ１０に要求する（Ｓ２０５）。受諾画面データは受諾画面６０を表示するためのデータ（例えばページデータ）である。ステップＳ２０５では、ステップＳ２０１で送信される情報に加えて、ユーザＢによって選択された取引申込の取引ＩＤがゲームサーバ１０に送信される。
【０１０９】
上記要求がゲームサーバ１０で受け付けられた場合、制御部１１は受諾画面データをユーザＢの端末２０に送信する（Ｓ２０６）。例えば、制御部１１はユーザ間取引テーブルを参照し、ユーザＢによって選択された取引申込に関する情報を取得する。この情報に基づいて、制御部１１は受諾画面データを生成し、ユーザＢの端末２０に送信する。
【０１１０】
受諾画面データがユーザＢの端末２０で受信された場合、制御部２１は受諾画面６０を表示部２５に表示する（Ｓ２０７）。受諾画面６０の「はい」ボタン６２又は「いいえ」ボタン６４が選択された場合、制御部２１は確認画面データをゲームサーバ１０に要求する（Ｓ２０８）。確認画面データは確認画面７０を表示するためのデータ（例えばページデータ）である。ステップＳ２０８では、ステップＳ２０５で送信される情報に加えて、受諾結果を示す情報がゲームサーバ１０に送信される。
【０１１１】
上記要求がゲームサーバ１０で受け付けられた場合、制御部１１は確認画面データをユーザＢの端末２０に送信する（Ｓ２０９）。この場合、制御部２１は確認画面７０を表示部２５に表示する（Ｓ２１０）。確認画面７０の「はい」ボタン７２が選択された場合、制御部２１は受諾結果の登録をゲームサーバ１０に要求する（Ｓ２１１）。
【０１１２】
上記要求がゲームサーバ１０で受け付けられた場合、制御部１１は受諾結果をユーザ間取引テーブルに登録する（Ｓ２１２）。例えば、制御部１１はユーザ間取引テーブルにアクセスし、「アイテム３」、「受諾結果」、「状況」、及び「更新日時」フィールドを更新する。
【０１１３】
例えば、ユーザＢが取引申込を受諾した場合、ユーザＢがユーザＡに提供するゲームアイテムとして選択したゲームアイテムが「アイテム３」に登録され、値「１」が「受諾結果」フィールドに登録される。また、「状況」フィールドが「１」（承認権限者の承認待ち）に更新される。一方、ユーザＢが取引申込を受諾しなかった場合には、「受諾結果」フィールドに「０」に登録され、「状況」フィールドが「３」（不成立）に変更される。なお、いずれの場合にも現在日時が「更新日時」フィールドに登録される。
【０１１４】
図１５は、ユーザＢがユーザＡからの申し込みを受諾した後にユーザＣがトップ画面にアクセスした場合に実行される処理の一例を示す。なお、このトップ画面は例えばユーザＣ専用のトップ画面であり、このトップ画面にはユーザＣへの各種お知らせが表示される。
【０１１５】
図１５に示すように、まず、ユーザＣの端末２０の制御部２１はトップ画面データをゲームサーバ１０に要求する（Ｓ３０１）。トップ画面データはトップ画面を表示するためのデータ（例えばページデータ）である。ステップＳ３０１では、ユーザＣのユーザＩＤがゲームサーバ１０に送信される。
【０１１６】
上記要求がゲームサーバ１０で受け付けられた場合、制御部１１はユーザ間取引テーブルを参照し、ユーザＣが承認権限者として設定されている取引に関する情報を取得する（Ｓ３０２）。例えば、制御部１１は、下記のような二つの条件をすべて満足する取引に関する情報を取得する。
（１）ユーザＣが承認権限者として登録されている。
（２）状況が「承認権限者の承認待ち」である。
【０１１７】
その後、制御部１１はトップ画面データをユーザＣの端末２０に送信する（Ｓ３０３）。この場合、トップ画面データにはステップＳ３０２で取得された取引のリストが埋め込まれる。
【０１１８】
トップ画面データがユーザＣの端末２０で受信された場合、制御部２１はトップ画面を表示部２５に表示する（Ｓ３０４）。この場合、ユーザＣが承認権限者として設定されている取引のリストがトップ画面に表示される。
【０１１９】
トップ画面に表示された取引のいずれかがユーザＣによって選択された場合、制御部２１は承認画面データをゲームサーバ１０に要求する（Ｓ３０５）。承認画面データは承認画面８０を表示するためのデータ（例えばページデータ）である。ステップＳ３０５では、ステップＳ３０１で送信される情報に加えて、ユーザＣによって選択された取引の取引ＩＤがゲームサーバ１０に送信される。
【０１２０】
上記要求がゲームサーバ１０で受け付けられた場合、制御部１１は承認画面データをユーザＣの端末２０に送信する（Ｓ３０６）。例えば、制御部１１はユーザ間取引テーブルを参照し、ユーザＣによって選択された取引に関する情報を取得する。この情報に基づいて、制御部１１は承認画面データを生成し、ユーザＣの端末２０に送信する。
【０１２１】
承認画面データがユーザＣの端末２０で受信された場合、制御部２１は承認画面８０を表示部２５に表示する（Ｓ３０７）。承認画面８０の「はい」ボタン８２又は「いいえ」ボタン８４が選択された場合、制御部２１は承認結果をゲームサーバ１０に通知する（Ｓ３０８）。
【０１２２】
上記通知がゲームサーバ１０で受信された場合、制御部１１はユーザ間取引が承認されたか否かを判定する（Ｓ３０９）。ユーザ間取引が承認されたと判定された場合、制御部１１はこのユーザ間取引を許可すると決定し、このユーザ間取引を実行する（Ｓ３１０）。例えば、図８に示すようなユーザＡ，Ｂ間のユーザ間取引が承認権限者（ユーザＣ）によって承認されたと判定された場合、制御部１１はこのユーザＡ，Ｂ間のユーザ間取引を許可すると決定し、このユーザＡ，Ｂ間のユーザ間取引を実行する。すなわち、制御部１１は、１個のゲームアイテムＸをユーザＡの所有アイテムリストから取り除き、１個のゲームアイテムＸをユーザＢの所有アイテムリストに追加する。また、制御部１１は、１個のゲームアイテムＹをユーザＢの所有アイテムリストから取り除き、１個のゲームアイテムＹをユーザＡの所有アイテムリストに追加する。
【０１２３】
ステップＳ３１０が実行された後、制御部１１は取引結果をユーザ間取引テーブルに登録する（Ｓ３１１）。例えば、制御部１１はユーザ間取引テーブルにアクセスし、「承認結果」、「状況」、及び「更新日時」フィールドを更新する。例えば、「承認結果」フィールドに「１」が登録され、「状況」フィールドが「２」（成立）に変更される。また、現在日時が「更新日時」フィールドに登録される。
【０１２４】
ステップＳ３０９において、ユーザ間取引が承認されなかったと判定された場合、制御部１１はこのユーザ間取引を許可しないと決定し、このユーザ間取引を実行することなく、ステップＳ３１１を実行する。すなわち、制御部１１は取引結果を取引テーブルに登録する（Ｓ３１１）。例えば、制御部１１はユーザ間取引テーブルにアクセスし、「承認結果」、「状況」、及び「更新日時」フィールドを更新する。例えば、「承認結果」フィールドに「０」が登録され、「状況」フィールドが「３」（不成立）に変更される。また、現在日時が「更新日時」フィールドに登録される。
【０１２５】
以上に説明したように、第１実施形態に係るゲームシステム１では、仲間関係を有していないユーザＡ，Ｂの間の取引が、ユーザＡ，Ｂの両方と仲間関係を有しているユーザＣ（承認権限者）によって承認されることによって成立する。ゲームシステム１によれば、取引を行うユーザの両方と仲間関係を有しているユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム１によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
【０１２６】
［第２実施形態］本発明の第２実施形態について説明する。第２実施形態に係るゲームシステム１の全体構成は第１実施形態と同様である（図１参照）。また、第２実施形態に係るゲームシステム１もユーザ間取引機能を備えている。
【０１２７】
第１実施形態に係るゲームシステム１では、個々のユーザ同士が仲間関係を結ぶようになっていたが、第２実施形態に係るゲームシステム１では、複数のユーザが所属するユーザグループが設定されるようになっている。
【０１２８】
例えば、「ユーザグループ」とは、協力してゲームを進めるべく集まったユーザの集まりである。また例えば、「ユーザグループ」とは、共通の目的を達成すべく集まったユーザの集まりである。同一のユーザグループに所属する複数のユーザには同一の識別情報（例えばユーザグループＩＤ）が関連付けられることになるため、「ユーザグループ」とは、同一の識別情報（例えばユーザグループＩＤ）に関連づけられたユーザの集まりということもできる。また、ゲームによっては、同じユーザグループに所属する複数のユーザだけが共通に使用可能な機能（例えば掲示板又はチャット等）が用意される場合がある。このため、「ユーザグループ」とは、特定の機能を共通に使用可能なユーザの集まりということもできる。なお、ユーザグループは「チーム」、「ギルド」、又は「パーティ」等の名称で呼ばれる場合もある。
【０１２９】
図１６はユーザグループの一例を示す。図１６に示す例では、ユーザＡ，Ｃ，Ｄ，Ｅ，Ｆが所属するユーザグループＧ１と、ユーザＢ，Ｃ，Ｇ，Ｈ，Ｉが所属するユーザグループＧ２と、ユーザＨ，Ｊ，Ｋ，Ｌ，Ｍが所属するユーザグループＧ３とが設定されている。なお、図１６に示す例では、ユーザＣがユーザグループＧ１，Ｇ２の両方に所属しており、ユーザＨがユーザグループＧ２，Ｇ３の両方に所属している。
【０１３０】
また、各ユーザグループでは、ユーザグループに所属するいずれかのユーザがリーダー（代表者）として設定されるようになっている。図１６における星印は各ユーザグループのリーダーを示している。なお、リーダー以外の役割（例えばサブリーダー等）が設定されるようにしてもよい。
【０１３１】
第２実施形態に係るゲームシステム１では、原則として、同じユーザグループに所属するユーザ間で取引（ゲーム内取引）を行うことが許容される。また、第２実施形態に係るゲームシステム１では、同じユーザグループに所属していないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、同じユーザグループに所属していないユーザ間でも取引を行うことが可能である。
【０１３２】
図１７は上記のようなユーザ間取引機能について説明するための図であり、三名のユーザＡ，Ｂ，Ｃの関係の一例を示す。
【０１３３】
図１７に示す例では、ユーザＡ，Ｃは同じユーザグループＧ１に所属しているため、ユーザＡ，Ｃの間では取引を行うことが可能である。同様に、ユーザＢ，Ｃは同じユーザグループＧ２に所属しているため、ユーザＢ，Ｃの間では取引を行うことが可能である。
【０１３４】
さらに、第２実施形態に係るゲームシステム１では、ユーザＡと同じユーザグループに所属し、かつ、ユーザＢと同じユーザグループに所属するユーザＣが承認すれば、同じユーザグループに所属していないユーザＡ，Ｂの間でも取引を行うことが可能になっている。すなわち、上記のようなユーザＣが仲介者（承認権限者）となることによって、同じユーザグループに所属していないユーザＡ，Ｂの間でも取引を行うことが可能になっている。
【０１３５】
第２実施形態に係るゲームシステム１においても、第１実施形態と同様の画面が表示される（図３〜図９参照）。ただし、第２実施形態に係るゲームシステム１の場合、仲介者候補リスト画面３０には、ユーザＡと同じユーザグループに所属するユーザのリストが表示される。また、取引候補リスト画面４０には、仲介者として選択されたユーザが所属しているユーザグループ（ユーザＡが所属しているユーザグループを除く。）に所属している各ユーザの所望アイテムリストが表示される。
【０１３６】
第２実施形態に係るゲームシステム１で記憶されるデータについて説明する。図１８は第２実施形態におけるユーザテーブルの一例を示す。図１８に示すユーザテーブルは、「仲間」フィールドの代わりに「所属グループ」フィールドを含む点で、図１０に示すユーザテーブルと相違する。「所属グループ」フィールドにはユーザが所属するユーザグループが登録される。例えば、ユーザが所属するユーザグループの識別情報（ユーザグループＩＤ）が「所属グループ」フィールドに登録される。ユーザが複数のユーザグループに所属する場合には、それら複数のユーザグループの各々の識別情報（ユーザグループＩＤ）が「所属グループ」フィールドに登録される。なお、ここでは省略されているが、実際には、各ユーザグループ内の役割（例えばリーダー）を割り当てられているユーザを特定するためのデータがデータベース１５に記憶される。また、ユーザ間取引テーブルは第１実施形態と同様である（図１１参照）。
【０１３７】
第２実施形態に係るゲームシステム１で実現される機能ブロックは基本的に第１実施形態と同様である（図１２参照）。ただし、承認権限者設定部１００及び特定ユーザ間取引許可部１０６の機能は第１実施形態と異なる点があるため、この点について説明する。
【０１３８】
第２実施形態における特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザとが特定関係を有する場合に、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可する。この点は第１実施形態と同様である。
【０１３９】
しかしながら、第２実施形態に係る特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザとが同じユーザグループに所属する場合に、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可する。すなわち、第２実施形態では、同じユーザグループに所属するような関係が「特定関係」の一例に相当する。
【０１４０】
第２実施形態における承認権限者設定部１００は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。例えば、承認権限者設定部１００は、ユーザ間の関係に関するデータに基づいて、第１ユーザ及び第２ユーザ以外のユーザのうちから承認権限者を設定する。例えば、承認権限者設定部１００は、第１ユーザと所定関係を有し、かつ、第２ユーザと所定関係を有する他のユーザを承認権限者として設定する。この点は第１実施形態と同様である。
【０１４１】
第２実施形態の場合にも、例えば、上記の「特定関係」が「所定関係」の一例に相当する。このため、例えば、承認権限者設定部１００は、第１ユーザと特定関係を有し、かつ、第２ユーザと特定関係を有する他のユーザを承認権限者として設定する。
【０１４２】
先述したように、第２実施形態の場合、同じユーザグループに所属するような関係が「特定関係」の一例に相当する。このため、第２実施形態における承認権限者設定部１００は、第１ユーザと同じユーザグループに所属し、かつ、第２ユーザと同じユーザグループに所属する他のユーザを承認権限者として設定する。
【０１４３】
第２実施形態に係るゲームシステム１において実行される処理も基本的に第１実施形態と同様である（図１３〜図１５参照）。
【０１４４】
ただし、図１３のステップＳ１０２において、制御部１１はユーザテーブルを参照し、ユーザＡと同じユーザグループに所属しているユーザのリストを取得する。例えば、制御部１１はユーザＡの「所属グループ」フィールドを参照し、ユーザＡが所属しているユーザグループのユーザグループＩＤを取得する。また、制御部１１は、ユーザＡが所属しているユーザグループのユーザグループＩＤが「所属グループ」フィールドに含まれているユーザを特定する。すなわち、制御部１１は、ユーザＡが所属しているユーザグループのユーザグループＩＤが関連づけられているユーザを特定する。そして、制御部１１は上記のユーザのリストに基づいて仲介者候補リスト画面データを生成し、ユーザＡの端末２０に送信する。
【０１４５】
また、図１３のステップＳ１０５において、制御部１１はユーザテーブルを参照し、ユーザＣと同じユーザグループに所属しているユーザを特定する。さらに、制御部１１はユーザテーブルを参照し、特定されたユーザの所望アイテムリストを取得する。そして、制御部１１はこのリストに基づいて取引候補リスト画面データを生成し、ユーザＡの端末２０に送信する。
【０１４６】
以上に説明したように、第２実施形態に係るゲームシステム１では、同じユーザグループに所属していないユーザＡ，Ｂの間の取引が、ユーザＡ，Ｂの各々と同じユーザグループに所属しているユーザＣ（承認権限者）によって承認されることによって成立する。ゲームシステム１によれば、取引を行うユーザの各々と同じユーザグループに所属しているユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム１によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
【０１４７】
［第３実施形態］本発明の第３実施形態について説明する。第３実施形態に係るゲームシステム１の全体構成は第１実施形態と同様である（図１参照）。また、第３実施形態に係るゲームシステム１もユーザ間取引機能を備えている。
【０１４８】
第３実施形態に係るゲームシステム１では、個々のユーザ同士が友人関係を結ぶことが可能になっている。さらに、第３実施形態に係るゲームシステム１では、複数のユーザが所属するユーザグループを設定することも可能になっている。第３実施形態における「友人関係」は第１実施形態における「仲間関係」と類似のものであり、第３実施形態における「ユーザグループ」は第２実施形態における「ユーザグループ」と同様のものである。第３実施形態では、友人関係とユーザグループとの両方が別個のものとして設定される点で第１実施形態及び第２実施形態と異なっている。
【０１４９】
第３実施形態に係るゲームシステム１では、原則として、友人関係を有するユーザ間で取引（ゲーム内取引）を行うことが許容される。また、第３実施形態に係るゲームシステム１では、友人関係を有していないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、友人関係を有していないユーザ間でも取引を行うことが可能になっている。
【０１５０】
以下、第３実施形態におけるユーザ間取引機能の例について説明する。なおここでは、図１６に示すようなユーザグループが設定されている場合を想定し、図１６を参照しながら、第３実施形態におけるユーザ間取引機能の例について説明する。
【０１５１】
まず、第１の例について説明する。ここでは、ユーザＡ，Ｅが取引を行う場合を想定する。なお、ユーザＡ，Ｅは友人関係を有していないこととする。図１９はこの場合のユーザ間取引機能について説明するための図である。
【０１５２】
先述したように、第３実施形態に係るゲームシステム１では、原則として、友人関係を有するユーザ間で取引を行うことが許容されるようになっている。この点、ユーザＡ，Ｅは友人関係を有していないが、第３実施形態に係るゲームシステム１では、ユーザＡ，Ｅと同じユーザグループに所属するユーザＤが承認すれば、友人関係を有していないユーザＡ，Ｅの間でも取引を行うことが可能になっている。すなわち、上記のようなユーザＤが仲介者（承認権限者）となることによって、友人関係を有していないユーザＡ，Ｅの間でも取引を行うことが可能になっている。
【０１５３】
なお、ユーザＡ，Ｅが所属するユーザグループにおいて所定の役割を担っているユーザが承認した場合にのみ、ユーザＡ，Ｅの間でも取引を行うことが可能になるようにしてもよい。すなわち、ユーザＡ，Ｅが所属するユーザグループにおいて所定の役割を担っているユーザが仲介者（承認権限者）として設定されるようにしてもよい。
【０１５４】
「所定の役割を担っているユーザ」とは、例えば、特別の権限が付与されたユーザである。言い換えれば、「所定の役割を担っているユーザ」とは、例えば、ユーザグループに所属する他のユーザが有していないような権限を有しているユーザである。
【０１５５】
例えば、ユーザグループのリーダーが「所定の役割を担っているユーザ」の一例に相当する。このため、例えば、ユーザＡ，Ｅが所属するユーザグループのリーダーであるユーザＦが承認した場合にのみ、ユーザＡ，Ｅの間でも取引を行うことが可能になるようにしてもよい。すなわち、ユーザＡ，Ｅが所属するユーザグループのリーダーであるユーザＦが仲介者（承認権限者）として設定されるようにしてもよい。
【０１５６】
第２の例について説明する。ここでは、ユーザＡ，Ｂが取引を行う場合を想定する。なお、ユーザＡ，Ｂは友人関係を有していないこととする。また、この場合のユーザ間取引機能は図１７に示した例に類似しているため、ここでは図１７を参照しながら説明する。
【０１５７】
先述したように、第３実施形態に係るゲームシステム１では、原則として、友人関係を有するユーザ間で取引を行うことが許容されるようになっている。この点、ユーザＡ，Ｂは友人関係を有していないが、第３実施形態に係るゲームシステム１では、ユーザＡと同じユーザグループに所属し、かつ、ユーザＢと同じユーザグループに所属するユーザＣが承認すれば、友人関係を有していないユーザＡ，Ｂの間でも取引を行うことが可能になっている。すなわち、上記のようなユーザＣが仲介者（承認権限者）となることによって、友人関係を有していないユーザＡ，Ｂの間でも取引を行うことが可能になっている。
【０１５８】
先述したように、この場合のユーザ間取引機能は図１７に示したユーザ間取引機能（第２実施形態）と類似している。しかしながら、第２実施形態は、原則として、同じユーザグループに所属するユーザ間で取引が許容されるところ、例えば、同じユーザグループに所属してないユーザＡ，Ｂの間でも、ユーザＡと同じユーザグループに所属し、かつ、ユーザＢと同じユーザグループに所属するユーザＣが承認すれば、取引を許容するものである。これに対し、第３実施形態は、原則として、友人関係を有するユーザ間で取引が許容されるところ、例えば、友人関係を有していないユーザＡ，Ｂの間でも、ユーザＡと同じユーザグループに所属し、かつ、ユーザＢと同じユーザグループに所属するユーザＣが承認すれば、取引を許容するものである。この点で第３実施形態は第２実施形態と異なっている。
【０１５９】
第３実施形態に係るゲームシステム１では第２実施形態と同様の画面が表示される。すなわち、仲介者候補リスト画面３０には、ユーザＡと同じユーザグループに所属するユーザのリストが表示される。また、取引候補リスト画面４０には、仲介者として選択されたユーザが所属しているユーザグループ（ユーザＡが所属しているユーザグループを除く。）に所属している各ユーザの所望アイテムリストが表示される。
【０１６０】
また、第３実施形態におけるユーザテーブルは、図１０に示すユーザテーブルと図１８に示すユーザテーブルとを組み合わせたようなテーブルとなる。すなわち、第３実施形態におけるユーザテーブルは「仲間」フィールドと「所属グループ」フィールドとの両方を含む。
【０１６１】
第３実施形態に係るゲームシステム１で実現される機能ブロックは基本的に第１実施形態と同様である（図１２参照）。
【０１６２】
第３実施形態における特定ユーザ間取引許可部１０６は第１実施形態と同様である。すなわち、特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザとが特定関係を有する場合に、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを許可する。
【０１６３】
第３実施形態では、友人関係が「特定関係」の一例に相当し、特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザとが友人関係を有している場合に、ゲーム内におけるゲームアイテムの交換を第１ユーザと第２ユーザとの間で行うことを許可する。
【０１６４】
第３実施形態における承認権限者設定部１００は第１実施形態と異なる点がある。この点について説明する。
【０１６５】
承認権限者設定部１００は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。例えば、承認権限者設定部１００は、ユーザ間の関係に関するデータに基づいて、第１ユーザ及び第２ユーザ以外のユーザのうちから承認権限者を設定する。例えば、承認権限者設定部１００は、第１ユーザと所定関係を有し、かつ、第２ユーザと所定関係を有する他のユーザを承認権限者として設定する。この点は第１実施形態と同様である。
【０１６６】
ただし、第３実施形態の場合、例えば、上記の「特定関係」以外の関係が「所定関係」の一例に相当する。すなわち、第３実施形態の場合、同じユーザグループに所属するような関係が「所定関係」の一例に相当する。このため、第３実施形態における承認権限者設定部１００は、第１ユーザと同じユーザグループに所属し、かつ、第２ユーザと同じユーザグループに所属する他のユーザを承認権限者として設定する。
【０１６７】
例えば、先述した第１の例のように、ユーザＡ（第１ユーザ）とユーザＥ（第２ユーザ）とがともにユーザグループＧ１に所属している場合、承認権限者設定部１００は、ユーザＡが所属するユーザグループＧ１に所属し、かつ、ユーザＥが所属するユーザグループＧ１に所属する他のユーザを承認権限者として設定する。すなわち、承認権限者設定部１００は、ユーザＡ，Ｅの両方が所属しているユーザグループＧ１に所属する他のユーザ（例えばユーザＤ）を承認権限者として設定する。
【０１６８】
なおこの場合、承認権限者設定部１００は、ユーザＡ，Ｅの両方が所属しているユーザグループＧ１において所定の役割を担っている他のユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部１００は、ユーザグループＧ１に所属するユーザのうち、他のユーザが有していないような権限を有しているユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部１００は、ユーザグループＧ１のリーダーであるユーザＦを承認権限者として設定するようにしてもよい。
【０１６９】
また例えば、先述した第２の例のように、ユーザＡ（第１ユーザ）とユーザＢ（第２ユーザ）とが異なるユーザグループＧ１，Ｇ２にそれぞれ所属している場合、承認権限者設定部１００は、ユーザＡが所属しているユーザグループＧ１に所属し、かつ、ユーザＢが所属しているユーザグループＧ２に所属する他のユーザ（例えばユーザＣ）を承認権限者として設定する。
【０１７０】
第３実施形態における承認結果情報取得部１０２、ユーザ間取引許可部１０４、及びユーザ間取引実行部１０８は第１実施形態と同様である。
【０１７１】
また、第３実施形態に係るゲームシステム１で実行される処理も基本的に第２実施形態と同様である。
【０１７２】
以上に説明した第３実施形態に係るゲームシステム１では、友人関係を有していないユーザＡ，Ｂの間の取引が、ユーザＡ，Ｂの各々と同じユーザグループに所属しているユーザＣ（承認権限者）によって承認されることによって成立する。ゲームシステム１によれば、取引を行うユーザの各々と同じユーザグループに所属しているユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム１によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
【０１７３】
なお、第３実施形態に係るゲームシステム１では、原則として、同じユーザグループに所属するユーザ間で取引（ゲーム内取引）を行うことが許容されるようにしてもよい。また、第３実施形態に係るゲームシステム１では、同じユーザグループに所属していないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、同じユーザグループに所属していないユーザ間でも取引を行うことが可能となるようにしてもよい。
【０１７４】
図２０は上記のようなユーザ間取引機能について説明するための図であり、三名のユーザＡ，Ｂ，Ｊの関係の一例を示す。なおここでは、図１６に示すようなユーザグループが設定されていることとする。
【０１７５】
先述したように、ここで説明している例では、原則として、同じユーザグループに所属するユーザ間で取引を行うことが許容されるようになっている。この点、ユーザＡ，Ｂは同じユーザグループに所属していないが（図１６参照）、この場合、ユーザＡと友人関係を有し、かつ、ユーザＢと友人関係を有するユーザＪが承認すれば、同じユーザグループに所属してないユーザＡ，Ｂの間でも取引を行うことが可能になる。すなわち、上記のようなユーザＪが仲介者（承認権限者）となることによって、同じユーザグループに所属していないユーザＡ，Ｂの間でも取引を行うことが可能になる。
【０１７６】
なお、図２０に示したユーザ間取引機能は図２に示したユーザ間取引機能（第１実施形態）と類似している。しかしながら、第１実施形態（図２）は、原則として、仲間関係（又は友人関係）を有するユーザ間で取引が許容されるところ、例えば、仲間関係（又は友人関係）を有していないユーザＡ，Ｂの間でも、ユーザＡと仲間関係（又は友人関係）を有し、かつ、ユーザＢと仲間関係（又は友人関係）を有するユーザＣが承認すれば、取引を許容するものである。これに対し、第３実施形態（図２０）は、原則として、同じユーザグループに所属するユーザ間で取引を行うことが許容されるところ、例えば、同じユーザグループに所属していないユーザＡ，Ｂの間でも、ユーザＡと友人関係を有し、かつ、ユーザＢと友人関係を有するユーザＪが承認すれば、取引を許容するものである。この点で第３実施形態（図２０）は第１実施形態（図２）と異なっている。
【０１７７】
ここで説明した例の場合、特定ユーザ間取引許可部１０６は、第１ユーザと第２ユーザと同じユーザグループに所属している場合に、ゲーム内におけるゲームアイテムの交換を第１ユーザと第２ユーザとの間で行うことを許可する。また、承認権限者設定部１００は、第１ユーザと友人関係を有し、かつ、第２ユーザと友人関係を有する他のユーザを承認権限者として設定する。
【０１７８】
この場合、同じユーザグループに所属していないユーザＡ，Ｂの間の取引が、ユーザＡ，Ｂの各々と友人関係を有しているユーザＪ（承認権限者）によって承認されることによって成立する。ゲームシステム１によれば、取引を行うユーザの各々と友人関係を有しているユーザによって取引の内容が確認されることになるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム１によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
【０１７９】
［第４実施形態］本発明の第４実施形態について説明する。第４実施形態に係るゲームシステム１の全体構成は第１実施形態と同様である（図１参照）。第４実施形態に係るゲームシステム１もユーザ間取引機能を備えている。
【０１８０】
ただし、第４実施形態に係るゲームシステム１の機能ブロック図は図２１に示すようになっており、第４実施形態に係るゲームシステム１は特定ユーザ間取引許可部１０６を含まない点で第１実施形態〜第３実施形態と相違する。
【０１８１】
すなわち、第４実施形態に係るゲームシステム１では、第１ユーザと第２ユーザとの間の取引を承認する権限を有する承認権限者が承認した場合にのみ、第１ユーザと第２ユーザとの間で取引を行うことが許可されるようになっている。
【０１８２】
第４実施形態における承認権限者設定部１００は基本的に第１実施形態〜第３実施形態と同様である。承認権限者設定部１００は、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。例えば、承認権限者設定部１００は、ユーザ間の関係に関するデータに基づいて、第１ユーザ及び第２ユーザ以外のユーザのうちから承認権限者を設定する。
【０１８３】
例えば、第１ユーザと第２ユーザとが他のユーザを介して関係づけられている場合に、承認権限者設定部１００は該他のユーザを承認権限者として設定する。
【０１８４】
また例えば、承認権限者設定部１００は、第１ユーザと所定関係を有し、かつ、第２ユーザと所定関係を有する他のユーザを承認権限者として設定する。
【０１８５】
例えば、仲間関係（友人関係）が「所定関係」の一例に相当する。すなわち、承認権限者設定部１００は、第１ユーザと仲間関係（又は友人関係）を有し、かつ、第２ユーザと仲間関係（又は友人関係）を有する他のユーザを承認権限者として設定する。例えば図２に示すように、承認権限者設定部１００は、ユーザＡと仲間関係を有し、かつ、ユーザＢと仲間関係を有するユーザＣを、ユーザＡ，Ｂの間の取引を承認する承認権限者として設定する。
【０１８６】
また例えば、同じユーザグループに所属するような関係が「所定関係」の一例に相当する。すなわち、承認権限者設定部１００は、第１ユーザと同じユーザグループに所属し、かつ、第２ユーザと同じユーザグループに所属する他のユーザを承認権限者として設定する。
【０１８７】
例えば図１９に示すように、承認権限者設定部１００は、ユーザＡと同じユーザグループＧ１に所属し、かつ、ユーザＥと同じユーザグループＧ１に所属するユーザＤを、ユーザＡ，Ｅの間の取引を承認する承認権限者として設定する。図１９に示す例の場合、ユーザＡ，Ｅは同じユーザグループＧ１に所属しているため、承認権限者設定部１００は、ユーザＡ，Ｅの両方と同じユーザグループＧ１に所属しているユーザＤを、ユーザＡ，Ｅの間の取引を承認する承認権限者として設定する。
【０１８８】
なおこの場合、承認権限者設定部１００は、ユーザＡ，Ｅの両方が所属しているユーザグループＧ１において所定の役割を担っている他のユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部１００は、ユーザグループＧ１に所属するユーザのうち、他のユーザが有していないような権限を有しているユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部１００は、ユーザグループＧ１のリーダーであるユーザＦを承認権限者として設定するようにしてもよい。
【０１８９】
また例えば図１７に示すように、承認権限者設定部１００は、ユーザＡが所属しているユーザグループＧ１に所属し、かつ、ユーザＢが所属しているユーザグループＧ２に所属する他のユーザ（例えばユーザＣ）を、ユーザＡ，Ｂの間の取引を承認する承認権限者として設定する。
【０１９０】
第４実施形態における承認結果情報取得部１０２、ユーザ間取引許可部１０４、及びユーザ間取引実行部１０８は第１実施形態又は第２実施形態と同様である。
【０１９１】
なお、第４実施形態に係るゲームシステム１で表示される画面も第１実施形態又は第２実施形態と同様である。また、第４実施形態に係るゲームシステム１で実行される処理も第１実施形態又は第２実施形態と同様である。
【０１９２】
以上に説明した第４実施形態に係るゲームシステム１では、例えば、ユーザＡ，Ｂの各々と仲間関係を有するユーザ（承認権限者）によって承認されることによって、ユーザＡ，Ｂの間の取引が成立する。また例えば、ユーザＡ，Ｂの各々と同じユーザグループに所属しているユーザ（承認権限者）によって承認されることによって、ユーザＡ，Ｂの間の取引が成立する。ゲームシステム１によれば、上記のようなユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム１によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
【０１９３】
［第５実施形態］本発明の第５実施形態について説明する。第５実施形態に係るゲームシステム１の全体構成は第１実施形態と同様である（図１参照）。第５実施形態に係るゲームシステム１もユーザ間取引機能を備えている。
【０１９４】
以上に説明した第１実施形態〜第４実施形態では、承認権限者（仲介者）が取引に受動的に関わるようになっていた。第５実施形態に係るゲームシステム１は、承認権限者が取引に能動的に関わる点で第１実施形態〜第４実施形態と異なる。
【０１９５】
第５実施形態に係るゲームシステム１の概要について説明する。図２２は第５実施形態に係るゲームシステム１の概要について説明するための図である。なお、ここでは、取引を行うユーザと仲間関係を有するユーザが承認権限者（仲介者）として設定される場合を想定する。また、ユーザＡ，Ｂの両方とユーザＣが仲間関係を有している場合を想定する。
【０１９６】
例えば、ユーザＣは、ユーザＣと仲間関係を有している他のユーザが所望している取引に関する情報（例えば、所望アイテムリスト、出品アイテムリスト、所有アイテムリスト、又は取引条件）を検索することによって、取引が成立するような仲間の組合せを見つける。
【０１９７】
例えば、ユーザＡの出品アイテムリスト（又は所有アイテムリスト）にゲームアイテムＸが登録され、かつ、ユーザＢの所望アイテムリストにゲームアイテムＸが登録されている場合、ユーザＣは、ユーザＡ，Ｂを、取引が成立するような仲間の組合せであると判断し、取引の提案対象として選択する。そして、ユーザＣはユーザＡ，Ｂが取引を行うことを承認し、ユーザＡ，Ｂに取引（すなわちゲームアイテムＸの授受）を行うように提案する。この場合、ユーザＡ，Ｂがともに提案を受け入れれば、ユーザＡ，Ｂの間で取引が実行される。
【０１９８】
図２３は第５実施形態に係るゲームシステム１の機能ブロック図を示す。図２３に示すように、第５実施形態に係るゲームシステム１は、第１出力制御部１１０及び第２出力制御部１１２を含む点で第１実施形態と相違する。例えば、第１出力制御部１１０及び第２出力制御部１１２はゲームサーバ１０において実現される。なお、第４実施形態と同様に、特定ユーザ間取引許可部１０６を省略するようにしてもよい。
【０１９９】
第１出力制御部１１０は、承認権限者によって承認を受ける側の複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、承認権限者の端末２０の出力部に出力するための制御を行う。
【０２００】
例えば、「ユーザが所望するユーザ間取引の内容に関する情報」とは、例えば、ユーザの所望アイテムリスト、出品アイテムリスト、又は取引条件（例えば交換条件）等である。
【０２０１】
また例えば、ユーザＣが、ユーザＣと仲間関係を有するユーザの取引の承認権限者（仲介者）として設定され得る場合、「ユーザＣによって承認を受ける側の複数のユーザ」とは、ユーザＣと仲間関係を有する複数のユーザである。
【０２０２】
この場合、第１出力制御部１１０は、ユーザＣの仲間である複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、ユーザＣの端末２０の表示部２５に表示するための制御を行う。例えば、ユーザＣの仲間である複数のユーザの各々の所望アイテムリスト、出品アイテムリスト、又は取引条件等がユーザＣの端末２０の表示部２５に表示される。
【０２０３】
なお例えば、ユーザＣが、ユーザＣと同じユーザグループに所属するユーザの取引の承認権限者（仲介者）として設定される場合、「ユーザＣによって承認を受ける側の複数のユーザ」とは、ユーザＣと同じユーザグループに所属する複数のユーザである。
【０２０４】
この場合、第１出力制御部１１０は、ユーザＣと同じユーザグループに所属する複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、ユーザＣの端末２０の表示部２５に表示するための制御を行う。例えば、ユーザＣと同じユーザグループに所属する複数のユーザの各々の所望アイテムリスト、出品アイテムリスト、又は取引条件等がユーザＣの端末２０の表示部２５に表示される。そして、ユーザＣは表示部２５に表示される情報を参照しながら、取引の提案対象とするユーザの組合せを選択する。
【０２０５】
第２出力制御部１１２は、承認権限者によって承認を受ける側の複数のユーザのうちから承認権限者によって選択されたユーザの間でユーザ間取引を行うように提案することを示す提案情報を、承認権限者によって選択されたユーザの端末２０の出力部に出力するための制御を行う。
【０２０６】
例えば図２２に示す例の場合であれば、第２出力制御部１１２は、承認権限者であるユーザＣによって選択されたユーザＡ，Ｂの間で取引を行うように提案することを示す提案情報を、ユーザＡ，Ｂの各々の端末２０に表示するための制御を行う。例えば、第２出力制御部１１２は、ユーザＡ，Ｂの間でゲームアイテムＸに関する取引を行うように提案することを示す提案メッセージ（提案情報）を、ユーザＡ，Ｂの各々の端末２０に表示するための制御を行う。例えば、ユーザＡ又はユーザＢの端末２０がゲームサーバ１０にアクセスした場合に上記提案メッセージが画面に表示される。
【０２０７】
以上に説明した第５実施形態に係るゲームシステム１によれば、承認権限者が積極的に取引に関わることが可能になる。
【０２０８】
なお、本発明は以上に説明した第１実施形態〜第５実施形態に限定されるものではない。
【０２０９】
［１］例えば、複数のユーザが承認権限者（仲介者）として設定されるようにしてもよい。
【０２１０】
図２４は、複数のユーザが承認権限者として設定される場合のユーザ間取引の一例を示す。図２４に示す例ではユーザＡ，Ｃが仲間関係を有している。また、ユーザＢ，Ｃが仲間関係を有している。さらに、ユーザＢ，Ｋが仲間関係を有している。このような場合、ユーザＡ，ＫはユーザＢ，Ｃを介して関係づけられている。このため、承認権限者設定部１００は、ユーザＡ，Ｋの間のユーザ間取引を承認する承認権限者としてユーザＢ，Ｃを設定する。
【０２１１】
図２５は、複数のユーザが承認権限者として設定される場合のユーザ間取引の他の一例を示す。図２５に示す例ではユーザＡ，Ｃが同じユーザグループＧ１に所属している。また、ユーザＢ，Ｃが同じユーザグループＧ２に所属している。さらに、ユーザＢ，Ｋが同じユーザグループＧ３に所属している。このような場合、承認権限者設定部１００は、ユーザＡ，Ｋの間のユーザ間取引を承認する承認権限者としてユーザＢ，Ｃを設定する。
【０２１２】
図２４及び図２５に示す例の場合、ユーザＢ，Ｃの両方が承認した場合にユーザＡ，Ｋの間のユーザ間取引が許可される。なお、ユーザＢ，Ｃの少なくとも一方が承認した場合にユーザＡ，Ｋの間のユーザ間取引が許可されるようにしてもよい。
【０２１３】
また、図２４及び図２５に示す例の場合、ユーザＢ，Ｃの一方のみが承認権限者として設定されるようにしてもよい。
【０２１４】
なお、図２４及び図２５では二名のユーザが承認権限者として設定される場合について説明したが、三名以上のユーザが承認権限者として設定されるようにしてもよい。
【０２１５】
以上のように、第１ユーザと第２ユーザとが複数の他のユーザを介して関係づけられている場合に、承認権限者設定部１００は、該複数の他のユーザの全部又は一部を、第１ユーザと第２ユーザとの間のユーザ間取引を承認する承認権限者として設定するようにしてもよい。
【０２１６】
言い換えれば、承認権限者設定部１００は、第１ユーザと所定関係を有し、かつ、第２ユーザと所定関係を有する複数の他のユーザを、第１ユーザと第２ユーザとの間のユーザ間取引を承認する承認権限者として設定するようにしてもよい。
【０２１７】
この場合、例えば下記に示すようなユーザが「第１ユーザと所定関係を有するユーザ」の一例に相当する。「第２ユーザと所定関係を有するユーザ」も同様である。
（１）第１ユーザと直接的な関係（例えば仲間関係）を有しているユーザ。すなわち、第１ユーザと直接的に関係づけられているユーザ。
（２）第１ユーザと同じユーザグループに所属しているユーザ。
（３）第１ユーザと間接的に関係付けられているユーザ。すなわち、第１ユーザと一又は複数の他のユーザを介して間接的に関係付けられているユーザ。
【０２１８】
さらに、この場合、例えば下記に示すようなユーザが「第１ユーザと間接的に関係付けられているユーザ」の一例に相当する。
（３−１）第１ユーザと直接的な仲間関係を有しているユーザと直接的な仲間関係を有しているユーザ（すなわち、第１ユーザと他の一名のユーザを介して間接的に関係付けられているユーザ）。
（３−２）第１ユーザと直接的な仲間関係を有しているユーザと直接的な仲間関係を有しているユーザと直接的な仲間関係を有しているユーザ（すなわち、第１ユーザと他の二名のユーザを介して間接的に関係付けられているユーザ）。
（３−３）第１ユーザと他の三名以上のユーザを介して間接的に関係付けられているユーザ。
（３−４）第１ユーザが所属する第１ユーザグループに所属するユーザが所属する第２ユーザグループに所属するユーザ。
（３−５）第１ユーザと直接的な仲間関係を有しているユーザと同じユーザグループに属するユーザ。
【０２１９】
例えば、図２４に示すユーザＣはユーザＡと上記所定関係（１）を有するユーザに相当し、図２４に示すユーザＢはユーザＡと上記所定関係（３−１）を有するユーザに相当している。
【０２２０】
また例えば、図２５に示すユーザＣはユーザＡと上記所定関係（２）を有するユーザに相当し、図２５に示すユーザＨはユーザＡと上記所定関係（３−４）を有するユーザに相当する。
【０２２１】
次に、第１ユーザと第２ユーザとの間のユーザ間取引を承認する複数の承認権限者が設定された場合のユーザ間取引許可部１０４の動作について説明する。
【０２２２】
例えば、第１ユーザと第２ユーザとの間のユーザ間取引を承認した承認権限者の数が基準人数に達した場合に、ユーザ間取引許可部１０４は第１ユーザと第２ユーザとの間のユーザ間取引を許可する。
【０２２３】
例えば、承認権限者の人数と等しい人数が「基準人数」として設定される。すなわち、承認権限者全員が承認した場合に、ユーザ間取引許可部１０４は第１ユーザと第２ユーザとの間のユーザ間取引を許可する。
【０２２４】
または、承認権限者の過半数以上の人数が「基準人数」として設定されるようにしてもよい。すなわち、過半数以上の承認権限者が承認した場合に、ユーザ間取引許可部１０４は第１ユーザと第２ユーザとの間のユーザ間取引を許可するようにしてもよい。
【０２２５】
あるいは、「１」が「基準人数」として設定されるようにしてもよい。または、２以上の定数が「基準人数」として設定されるようにしてもよい。
【０２２６】
以上のようにすれば、例えば、ユーザＡ，Ｂが複数の他のユーザを介して関係づけられるような場合であっても、それら複数の他のユーザの全員又は一部によって承認されることによって、ユーザＡ，Ｂの間の取引が成立するようになる。
【０２２７】
［２］例えば、承認権限者の承認が行われるタイミングは上記に説明したタイミングに限られない。
【０２２８】
例えば図２〜図９に説明した例では、ユーザＢがユーザＡからの取引申込を受諾した段階で、承認権限者であるユーザＣが承認を行うようになっていた。しかしながら、例えば、ユーザＡがユーザＣを仲介者（承認権限者）として選択した段階で、ユーザＣが、自らと仲間関係を有しているユーザとユーザＡとが取引を行うことを承認するようにしてもよい。または、例えば、ユーザＡがユーザＢを取引相手として選択した段階で、ユーザＣが、ユーザＡとユーザＢとが取引を行うことを承認するようにしてもよい。
【０２２９】
［３］例えば、ユーザ間取引が実行されるタイミングは上記に説明したタイミングに限られない。
【０２３０】
例えば図１５に示す処理では、承認権限者による承認が行われた直後（すなわち、承認画面８０の「はい」ボタン８２が選択された直後）に、ゲームサーバ１０の制御部１１がユーザ間取引を実行するようになっていた（ステップＳ３１０参照）。しかしながら、ステップＳ３１０において、ゲームサーバ１０の制御部１１は、ユーザ間取引が承認権限者によって承認されたことを示す情報（言い換えれば、ユーザ間取引が許可されたことを示す情報）をデータベース１５に記憶させることによって、ユーザ間取引を実行可能な状態とするようにしてもよい。そして、所定のタイミング（例えば毎日の定時）において、制御部１１は、実行可能な状態になっているユーザ間取引をまとめて実行するようにしてもよい。
【０２３１】
［４］例えば、仲介者候補リスト画面３０ではユーザが仲介者候補を検索できるようにしてもよい。なお以下では、ユーザＡが仲介者候補を検索する場合を想定する。
【０２３２】
例えば、ユーザＡが指定したゲームアイテム（例えば所望のゲームアイテム）を所有しているユーザを仲介することが可能なユーザを仲介者候補として仲介者候補リスト画面３０に表示するようにしてもよい。例えば、ユーザＡが指定したゲームアイテムを所有しているユーザと仲間関係を有しているユーザを仲介者候補として仲介者候補リスト画面３０に表示するようにしてもよい。
【０２３３】
また例えば、ユーザＡが出品又は所有しているゲームアイテムを所望しているユーザを仲介することが可能なユーザを仲介者候補として仲介者候補リスト画面３０に表示するようにしてもよい。例えば、ユーザＡが所有しているゲームアイテムを所望アイテムリストに登録しているユーザと仲間関係を有しているユーザを仲介者候補として仲介者候補リスト画面３０に表示するようにしてもよい。
【０２３４】
［５］例えば、ゲームシステム１の管理者が承認権限者として設定されてもよい。この場合、承認権限者設定部１００を省略するようにしてもよい。
【０２３５】
［６］例えば、以上では、ユーザ間取引としてゲームアイテムの交換が行われる場合について説明したが、先述したように、ユーザ間取引の取引対象はゲームアイテムに限られない。例えば、取引対象は、ゲームにおいて利用される他のオブジェクト（例えばゲームカード又はゲームキャラクタ等）であってもよい。また例えば、取引対象は、ゲームにおいて利用されるポイント（例えばゲーム内通貨等）であってもよい。
【０２３６】
［発明のまとめ］以上の記載から本発明は例えば以下のように把握される。
【０２３７】
本発明に係るゲームシステムは、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段（１０２）と、前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段（１０４）と、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可すると決定された場合に、前記第１ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第１ユーザの前記利用対象の所有状況を示すデータから取り除き、前記第２ユーザの前記利用対象の所有状況を示すデータに追加し、かつ、前記第２ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第２ユーザの前記利用対象の所有状況を示す前記データから取り除き、前記第１ユーザの前記利用対象の所有状況を示す前記データに追加することによって、前記第１ユーザと前記第２ユーザとの間の前記ユーザ間取引を実行するユーザ間取引実行手段（１０８）と、を含む。
【０２３８】
また、本発明に係る取引制御装置は、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段（１０２）と、前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段（１０４）と、を含む。
【０２３９】
また、本発明に係るプログラムは、ゲーム内において利用される利用対象を取引するユーザ間取引を第１ユーザと第２ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段（１０２）、及び、前記承認結果情報に基づいて、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段（１０４）、としてコンピュータを機能させるためのプログラムである。
【０２４０】
また、本発明に係る情報記憶媒体は、上記プログラムを記録したコンピュータ読み取り可能な情報記憶媒体である。
【０２４１】
本発明によれば、不正行為を行う者が参加したユーザ間取引が成立してしまうことを抑制しつつ、不正行為を行う者が参加するおそれがなさそうなユーザ間取引を制限しないように図ることが可能になる。
【０２４２】
本発明の一態様では、ユーザ間の関係に関するデータに基づいて、前記第１ユーザ及び前記第２ユーザ以外のユーザのうちから前記承認権限者を設定する承認権限者設定手段（１００）を含むようにしてもよい。このようにすれば、ユーザ間の関係に関するデータに基づいて設定される承認権限者の承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる。
【０２４３】
また本発明の一態様では、前記承認権限者設定手段（１００）は、前記第１ユーザと前記第２ユーザとが一の他のユーザ又は複数の他のユーザを介して関係付けられている場合に、前記一の他のユーザ、又は、前記複数の他のユーザの全員又は一部を前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第１ユーザと第２ユーザとが一の他のユーザ又は複数の他のユーザを介して関係付けられている場合に、該一の他のユーザ、又は、該複数の他のユーザの全員又は一部の承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる。
【０２４４】
また本発明の一態様では、前記承認権限者設定手段（１００）は、前記第１ユーザと所定関係を有し、かつ、前記第２ユーザと所定関係を有する他のユーザを前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第１ユーザと所定関係を有し、かつ、第２ユーザと所定関係を有する他のユーザの承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる。
【０２４５】
また本発明の一態様では、前記承認権限者設定手段（１００）は、前記第１ユーザと前記第２ユーザとが所属している前記ユーザグループに所属している他のユーザを前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第１ユーザと第２ユーザとが所属しているユーザグループに所属している他のユーザの承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる。
【０２４６】
また本発明の一態様では、前記承認権限者設定手段（１００）は、前記第１ユーザと前記第２ユーザとが所属している前記ユーザグループに所属し、かつ、該ユーザグループにおいて所定の役割を担っている他のユーザを前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第１ユーザと第２ユーザとが所属しているユーザグループにおいて所定の役割を担っている他のユーザの承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる。
【０２４７】
また本発明の一態様では、前記第１ユーザと前記第２ユーザとが特定関係を有する場合に、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可する特定ユーザ間取引許可手段（１０６）を含み、前記第１ユーザと前記第２ユーザとが前記特定関係を有しない場合、前記第１ユーザと前記第２ユーザとの間で前記ユーザ間取引を行うことを許可するか否かが前記ユーザ間取引許可手段（１０４）によって決定されるようにしてもよい。このようにすれば、例えば、第１ユーザと第２ユーザとが特定関係を有しない場合であっても、承認権限者の承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる。
【０２４８】
また本発明の一態様では、前記第１ユーザと前記特定関係を有し、かつ、前記第２ユーザと前記特定関係を有する他のユーザを前記承認権限者として設定する手段（１００）を含むようにしてもよい。このようにすれば、第１ユーザと第２ユーザとが特定関係を有しない場合であっても、第１ユーザと特定関係を有し、かつ、第２ユーザと特定関係を有する他のユーザの承認によって、ゲーム内におけるユーザ間取引を第１ユーザと第２ユーザとの間で行うことが許可されるようになる
【０２４９】
また本発明の一態様では、前記承認権限者によって承認を受ける側の複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、前記承認権限者の端末の出力手段に出力するための制御を行う第１出力制御手段（１１０）と、前記複数のユーザのうちから前記承認権限者によって選択されたユーザの間で前記ユーザ間取引を行うように提案することを示す提案情報を、前記承認権限者によって選択された前記ユーザの端末の出力手段に出力するための制御を行う第２出力制御手段（１１２）と、を含むようにしてもよい。このようにすれば、承認権限者が取引を提案できるようになる。
【符号の説明】
【０２５０】
１  ゲームシステム、２  通信ネットワーク、１０  ゲームサーバ、１１，２１  制御部、１２，２２  記憶部、１３，２３  通信部、１５  データベース、２０  端末、２４  操作部、２５  表示部、２６  音声出力部、３０  仲介者候補リスト画面、４０  取引候補リスト画面、４２  「戻る」ボタン、５０  申込画面、５２，６２，７２，８２  「はい」ボタン、５４，６４，７４，８４  「いいえ」ボタン、５６  所望アイテム欄、５８  コメント欄、６０  受諾画面、７０  確認画面、８０  承認画面、１００  承認権限者設定部、１０２  承認結果情報取得部、１０４  ユーザ間取引許可部、１０６  特定ユーザ間取引許可部、１０８  ユーザ間取引実行部、１１０  第１出力制御部、１１２  第２出力制御部。
【図１】
2015150207.tif 000003
【図２】
2015150207.tif 000004
【図３】
2015150207.tif 000005
【図４】
2015150207.tif 000006
【図５】
2015150207.tif 000007
【図６】
2015150207.tif 000008
【図７】
2015150207.tif 000009
【図８】
2015150207.tif 000010
【図９】
2015150207.tif 000011
【図１０】
2015150207.tif 000012
【図１１】
2015150207.tif 000013
【図１２】
2015150207.tif 000014
【図１３】
2015150207.tif 000015
【図１４】
2015150207.tif 000016
【図１５】
2015150207.tif 000017
【図１６】
2015150207.tif 000018
【図１７】
2015150207.tif 000019
【図１８】
2015150207.tif 000020
【図１９】
2015150207.tif 000021
【図２０】
2015150207.tif 000022
【図２１】
2015150207.tif 000023
【図２２】
2015150207.tif 000024
【図２３】
2015150207.tif 000025
【図２４】
2015150207.tif 000026
【図２５】
2015150207.tif 000027