以下、本発明の実施形態の例について図面に基づき詳細に説明する。
[第1実施形態]本発明の第1実施形態について説明する。図1は本発明の第1実施形態に係るゲームシステムの全体構成を示す。図1に示すように、本実施形態に係るゲームシステム1はゲームサーバ10とデータベース15と複数の端末20とを含む。ゲームサーバ10及び各端末20は通信ネットワーク2に接続され、ゲームサーバ10と各端末20との間で相互にデータ通信が可能である。
ゲームサーバ10は例えばサーバコンピュータによって実現される。図1に示すように、ゲームサーバ10は制御部11、記憶部12、及び通信部13を含む。制御部11は例えば一又は複数のマイクロプロセッサ等を含み、オペレーティングシステムやその他のプログラムに従って処理を実行する。記憶部12は主記憶部(例えばRAM)及び補助記憶部(例えばハードディスクドライブ又はソリッドステートドライブ)を含む。通信部13は通信ネットワーク2を介してデータ通信を行うためのものである。
ゲームサーバ10はデータベース15にアクセスすることが可能である。データベース15はゲームサーバ10に含まれていてもよいし、ゲームサーバ10とは別のサーバコンピュータに含まれていてもよい。データベース15には各種データが記憶される。
端末20はユーザが使用するコンピュータであり、ユーザがゲームをプレイするために使用される。端末20は、例えば、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータを含む)、携帯用ゲーム機、家庭用ゲーム機(据置型ゲーム機)、又はパーソナルコンピュータ等によって実現される。図1に示すように、端末20は制御部21、記憶部22、通信部23、操作部24、表示部25、及び音声出力部26を含む。
制御部21、記憶部22、及び通信部23はゲームサーバ10の制御部11、記憶部12、及び通信部13と同様である。操作部24は、例えばタッチパネル、キー、レバー、マウス、又はゲームコントローラ等を含み、ユーザがゲーム操作を行うためのものである。なお、操作部24は、ユーザが音声又はジェスチャによってゲーム操作を行うためのものであってもよい。表示部25は例えば液晶表示パネル又は有機ELディスプレイ等であり、制御部21の指示に従って画面を表示する。音声出力部26は例えばスピーカ又はヘッドホン等であり、制御部21の指示に従って音声データを出力する。
プログラムやデータは例えば通信ネットワーク2を介してゲームサーバ10又は端末20に供給される。なお、ゲームサーバ10又は端末20は、情報記憶媒体(例えば光ディスク又はメモリカード等)に記憶されたプログラム又はデータを読み取るための構成要素を含むようにしてもよい。そして、情報記憶媒体を介してゲームサーバ10又は端末20にプログラムやデータを供給するようにしてもよい。
ゲームシステム1では各種ゲームを実行することが可能である。例えば、ゲームシステム1で実行されるゲームはユーザ間取引機能を備えており、ゲーム内においてユーザ間取引を行うことが可能になっている。
「ユーザ間取引」とはゲーム内においてユーザ間で行われる取引である。また、「ユーザ間取引」では、例えばゲームにおいて利用される利用対象が取引の対象とされる。「ゲームにおいて利用される利用対象」とは、例えば、ゲームにおいて利用されるオブジェクト又はポイント等である。また、「ゲームにおいて利用されるオブジェクト」とは、例えば、ゲームにおいて利用されるゲームアイテム、ゲームカード、又はゲームキャラクタ等である。一方、「ゲームにおいて利用されるポイント」とは、例えば、ゲーム内通貨として利用されるポイントである。なお、ゲームによっては、ユーザによって所定のコマンドが実行されるごとにポイントが消費され、時間経過とともに、消費されたポイントが回復するようになっている場合がある。このようなポイントも「ゲームにおいて利用されるポイント」の一例に相当する。
例えば、ユーザ間で行われる譲渡が「ユーザ間取引」の一例に相当する。例えば、第1ユーザが第2ユーザとゲームアイテムを交換することや、第1ユーザが第2ユーザからゲームアイテムを購入すること等が「ユーザ間取引」の一例に相当する。また例えば、ユーザ間で行われる貸与も「ユーザ間取引」の一例に相当し得る。例えば、第1ユーザが第2ユーザにゲームアイテムを貸すことも「ユーザ間取引」の一例に相当し得る。
以下では、ユーザ間取引機能を備えたゲームの一例として、ゲーム内においてユーザ間でゲームアイテムの交換を行うことが可能なゲームについて説明する。
ゲームシステム1では、原則として、特定関係を有するユーザ間で取引を行うことが許容される。例えば、ユーザ同士が仲間関係(又は友人関係)を結ぶことが可能になっており、原則として、仲間関係を有するユーザ間で取引を行うことが許容される。
例えば、「仲間関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが申請を承諾することによって成立する。また例えば、「仲間関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが該一方のユーザと関係を結ぶことを申請したことによって成立する場合もある。また例えば、「仲間関係」は、ゲームシステム1が二名のユーザに関係を結ぶことを提案し、双方のユーザが提案を承諾することによって成立する場合もある。また例えば、「仲間関係」は、ゲームシステム1が自動的(強制的)に二名のユーザの間に関係を結ばせる場合もある。
またゲームシステム1では、仲間関係を有しないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、仲間関係を有しないユーザ間でも取引を行うことが可能である。
図2は上記のユーザ間取引機能について説明するための図であり、三名のユーザA,B,Cの関係の一例を示す。図2に示す例では、ユーザA,Cは仲間関係を有しているため、ユーザA,Cの間で取引を行うことが可能である。同様に、ユーザB,Cは仲間関係を有しているため、ユーザB,Cの間で取引を行うことが可能である。
さらにゲームシステム1では、ユーザA,Bの両方と仲間関係を有するユーザCが承認すれば、仲間関係を有しないユーザA,Bの間でも取引を行うことが可能である。言い換えれば、ユーザA,Bの両方と仲間関係を有するユーザCが仲介者(承認権限者)となることによって、仲間関係を有しないユーザA,Bの間でも取引を行うことが可能である。
図3〜図9は、仲間関係を有しないユーザA,Bの間で取引が成立するまでの流れの一例を説明するための図であり、端末20に表示される画面の一例を示す。
図3〜図9に示す各画面は、端末20がゲームサーバ10にアクセスすることによって端末20の表示部25に表示される。すなわち、端末20がゲームサーバ10とデータを送受信することによって、画面が表示部25に表示される。例えば、端末20は処理要求を示すデータをゲームサーバ10に送信する。この処理要求がゲームサーバ10で受信された場合、ゲームサーバ10は処理要求に応じて処理を実行し、処理結果を示すデータを、処理要求の送信元である端末20に返信する。このようなデータの送受信が端末20とゲームサーバ10との間で実行されることによって、画面が表示部25に表示される。
例えば、仲間関係を有しないユーザとの取引をユーザAが望む場合、まず、ユーザAは自らと仲間関係を有するユーザのうちから仲介者(承認権限者)を選択する。図3は仲介者を選択するための仲介者候補リスト画面の一例を示す。
仲介者候補リスト画面30には、ユーザAと仲間関係を有するユーザが仲介者候補として表示される。なお図3において、各仲介者候補に関連づけられた括弧内の数値は、仲介者候補と仲間関係を有しているユーザの人数を示す。言い換えれば、括弧内の数値は、仲介者候補がユーザAに紹介できる取引相手の人数を示す。
ユーザAは、仲介者候補リスト画面30に表示される仲介者候補のうちのいずれかを仲介者として選択する。仲介者が選択された場合、取引候補リスト画面がユーザAの端末20の表示部25に表示される。図4は取引候補リスト画面の一例を示す。ここでは、ユーザCが仲介者として選択された場合を想定する。
図4に示すように、取引候補リスト画面40には、ユーザCと仲間関係を有するユーザの所望アイテムリストが表示される。ゲームシステム1では、各ユーザが所望のゲームアイテムを登録できるようになっており、所望アイテムリストはユーザによって登録された所望のゲームアイテムのリストを示す。
例えば、図4に記載された「ゲームアイテムV(ユーザPさん)」は、ユーザPがゲームアイテムVを所望アイテムリストに登録していることを示す。また、取引候補リスト画面40では、ユーザAが所有しているゲームアイテムに「所有」との文字列が関連づけられる。例えば図4に示す例では、ユーザPが所望しているゲームアイテムVや、ユーザBが所望しているゲームアイテムXをユーザAが所有していることが示されている。
ユーザAは取引候補リスト画面40に表示されるゲームアイテムのうちのいずれかを選択する。例えば、ユーザAは自らが所有しているゲームアイテムを選択することが可能である。いずれかのゲームアイテムが選択された場合、申込画面がユーザAの端末20の表示部25に表示される。
なお、取引候補リスト画面40には「戻る」ボタン42が表示されており、「戻る」ボタン42が選択された場合には仲介者候補リスト画面30に戻る。
図5は申込画面の一例を示す。ここでは、ユーザBが所望しているゲームアイテムBが取引候補リスト画面40で選択された場合を想定する。すなわち、ユーザBが取引相手として選択され、かつ、ゲームアイテムBが取引対象として選択された場合を想定する。
図5に示すように、申込画面50は所望アイテム欄56及びコメント欄58を含む。ユーザAはユーザBにゲームアイテムXを提供する対価としてユーザBから入手したいゲームアイテムを設定できるようになっており、所望アイテム欄56には、ユーザBから入手したいゲームアイテムとしてユーザAが設定したゲームアイテムが表示される。また、ユーザAはユーザBへのコメントを入力できるようになっており、コメント欄58には、ユーザAによって入力されたコメントが表示される。図5に示す例では、ユーザBから入手したいゲームアイテムが所望アイテム欄56に設定されていない。その代わりに、ゲームアイテムYをほしい旨がコメント欄58に入力されている。
また、申込画面50には「はい」ボタン52及び「いいえ」ボタン54が表示される。「はい」ボタン52が選択された場合、取引の申込内容がデータベース15に登録され、ユーザAからユーザBへの取引申込が受け付けられる。一方、「いいえ」ボタン54が選択された場合、取引候補リスト画面40に戻る。
ユーザAからユーザBへの取引申込が行われた場合には、その旨がユーザBに通知される。例えば、ユーザAからの申し込みが行われた後でユーザBがゲームシステム1にアクセスした際に、ユーザAからの申し込みがある旨がトップ画面(図示せず)に表示される。ここで、「トップ画面」とは、例えばユーザB専用のトップ画面のことを意味しており、このトップ画面にはユーザBへの各種お知らせが表示される。なお、ユーザBへの上記通知は、例えば電子メール等を介して行われるようにしてもよい。
上記通知を受けたユーザBはユーザAからの申し込みを受諾するか否かを選択する。図6はユーザBの端末20の表示部25に表示される受諾画面の一例を示す。図6に示すように、受諾画面60にはユーザAから申し込まれた取引の内容が表示される。
受諾画面60には「はい」ボタン62及び「いいえ」ボタン64が表示される。「いいえ」ボタン64が選択された場合、ユーザBがユーザAからの申し込みを受諾しなかった旨がデータベース15に登録され、ユーザAに通知される。なお、所定の受諾期限内にユーザBがユーザAからの申し込みを受諾しなかった場合も同様である。
一方、「はい」ボタン62を選択された場合、ユーザBが所有しているゲームアイテムのうちから、ユーザAに提供するゲームアイテムが選択され、確認画面が表示される。
図7はユーザBの端末20の表示部25に表示される確認画面の一例を示す。ここでは、ユーザBがゲームアイテムYをユーザAに提供するゲームアイテムとして選択した場合を想定する。図7に示すように、確認画面70は、ユーザAとの取引を実行してもよいか否かをユーザBに確認するための画面である。
確認画面70には「はい」ボタン72及び「いいえ」ボタン74が表示される。「いいえ」ボタン74が選択された場合、受諾画面60に戻る。
一方、「はい」ボタン72が選択された場合、ユーザBがユーザAからの申し込みを受諾した旨がデータベース15に登録され、ユーザA,Bが取引を希望していることが仲介者(ユーザC)に通知される。例えば、ユーザBがユーザAからの申し込みを受諾した後でユーザCがゲームシステム1にアクセスした際に、ユーザA,Bが取引を希望している旨がトップ画面に表示される。または、例えば電子メール等を介して、ユーザA,Bが取引を希望している旨がユーザCに通知される。
上記通知を受けたユーザCはユーザA,Bの間の取引を承認するか否かを選択する。図8は、ユーザCの端末20の表示部25に表示される承認画面の一例を示す。図8に示すように、承認画面80にはユーザA,Bの間で行われようとしている取引の内容が表示される。また承認画面80にはユーザAの申込内容も表示される。これらに基づいて、ユーザCはこの取引を承認してもよいか否かを判断する。
承認画面80には「はい」ボタン82及び「いいえ」ボタン84が表示される。「いいえ」ボタン84が選択された場合、すなわち、ユーザCが取引を承認しなかった場合には取引が不成立となる。そして、取引が不成立になった旨がデータベース15に登録され、ユーザA,Bに通知される。なお、所定の承認期限内にユーザCが取引を承認しなかった場合も同様である。
一方、「はい」ボタン82が選択された場合、すなわち、ユーザCが取引を承認した場合には取引が成立となり、ユーザA,Bの間の取引が実行される。すなわち、取引が成立になった旨がデータベース15に登録されるとともに、ユーザA,Bの間でゲームアイテムの交換が実行される。そして、その旨がユーザA,Bに通知される。
ゲームシステム1では、仲間関係を有しないユーザA,Bの間の取引が上記のようにして実行される。すなわち、ユーザA,Bの両方と仲間関係を有するユーザC(仲介者:承認権限者)によって承認されることによって、ユーザA,Bの間の取引が成立する。ゲームシステム1によれば、取引を行うユーザの両方と仲間関係を有するユーザによって取引の内容が確認されることになるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム1によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
なお、上記に説明した例では、ユーザが所望アイテムリストを登録できるようになっていたが、ユーザは所望の交換条件(すなわち、他のユーザから入手したいゲームアイテムと、その対価として他のユーザに提供したいゲームアイテムとの組合せ)のリストを登録できるようにしてもよい。
図9はこの場合の取引候補リスト画面40の一例を示す。図9に示す例において、「ゲームアイテムX−ゲームアイテムY(ユーザBさん)」は、ユーザBが自らの所有するゲームアイテムYと他のユーザが所有するゲームアイテムXとを交換することを希望していることを示す。例えば、図9に示す取引候補リスト画面40において、ユーザBが取引相手として選択され、かつ、取引対象としてゲームアイテムX,Yが選択された場合には、申込画面50の所望アイテム欄56にゲームアイテムYが自動的に表示される。
次に、上記に説明した機能を実現するための構成について説明する。まず、データベース15に記憶されるデータについて説明する。図10及び図11は、データベース15に記憶されるデータのうちのユーザ間取引機能に関連するデータの一例を示す。
図10はユーザテーブルの一例を示す。ユーザテーブルはゲームシステム1を利用するユーザのリストを示す。図10に示すユーザテーブルは「ユーザID」、「ユーザ名」、「仲間」、「所有アイテム」、「所望アイテム」、及び「出品アイテム」フィールドを含む。「ユーザID」フィールドはユーザを一意に識別するための識別情報を示す。「ユーザ名」フィールドはユーザの名前を示す。
「仲間」フィールドには、ユーザと仲間関係を有しているユーザのリストが登録される。「所有アイテム」フィールドには、ユーザが所有しているゲームアイテムのリストが登録される。「所望アイテム」フィールドには、ユーザが所望しているゲームアイテムのリストが登録される。「出品アイテム」フィールドには、ユーザが他のユーザに提供したいと考えているゲームアイテムのリストが登録される。なお例えば、ユーザが仲間関係を有しているユーザのリストはユーザテーブルとは別個のテーブルに登録されるのが一般的であるが、ここでは、便宜上、ユーザが仲間関係を有しているユーザのリストがユーザテーブル内に記憶されることとしている。所有アイテムリスト、所望アイテムリストや、出品リストに関しても同様である。
図11はユーザ間取引テーブルの一例を示す。ユーザ間取引テーブルはゲーム内で行われるユーザ間取引に関する情報を示す。図11に示すユーザ間取引テーブルは「取引ID」、「申込者」、「取引相手」、「承認権限者」、「申込日時」、「アイテム1」、「アイテム2」、「コメント」、「アイテム3」、「受諾結果」、「承認結果」、「状況」、及び「更新日時」フィールドを含む。
「取引ID」フィールドは取引を一意に識別するための識別情報を示す。「申込者」フィールドは取引を申し込んだユーザを示す。「取引相手」フィールドは取引を申し込まれたユーザを示す。「承認権限者」フィールドは承認権限者(仲介者)として設定されたユーザを示す。
「アイテム1」フィールドには申込者が取引相手に提供するゲームアイテムが登録される。また、「アイテム2」フィールドには申込者が取引相手から入手したいゲームアイテムが登録される。さらに、「コメント」フィールドには申込者によって入力されたコメントが登録される。
「アイテム3」フィールドには取引相手が申込者に提供するゲームアイテムが登録される。「受諾結果」フィールドには取引相手の受諾結果が登録される。例えば、値「0」又は「1」が「受諾結果」フィールドに登録される。値「0」は受諾されていないことを示し、値「1」は受諾されたことを示す。「受諾承認結果」フィールドには承認権限者の承認結果が登録される。例えば、値「0」又は「1」が「承認結果」フィールドに登録される。値「0」は承認されていないことを示し、値「1」は承認されたことを示す。
「状況」フィールドは取引の現在の状況を示し、「更新日時」フィールドは「状況」フィールドが更新された日時を示す。例えば、値「0」〜「3」が「状況」フィールドに登録される。これら値は下記のような状況を示す。
(0)取引相手の受諾待ち
(1)承認権限者の承認待ち
(2)取引成立
(3)取引不成立
なお、図10及び図11に示したユーザテーブル及びユーザ間取引テーブルは、ユーザ間取引の対象がゲームアイテムである場合のユーザテーブル及びユーザ間取引テーブルの一例を示している。例えば、ユーザ間取引の対象がゲームカードである場合には、「所有アイテム」、「所望アイテム」、及び「出品アイテム」フィールドの代わりに、「所有カード」、「所望カード」、及び「出品カード」フィールドがユーザテーブルに含まれることになる。同様に、「アイテム1」、「アイテム2」、及び「アイテム3」フィールドの代わりに、「カード1」、「カード2」、及び「カード3」フィールドがユーザ間取引テーブルに含まれることになる。
次に、ゲームシステム1で実現される機能ブロックについて説明する。図12は、ゲームシステム1で実現される機能ブロックを示す機能ブロック図である。図12に示すように、ゲームシステム1は承認権限者設定部100、承認結果情報取得部102、ユーザ間取引許可部104、特定ユーザ間取引許可部106、及びユーザ間取引実行部108を含む。これらの機能ブロックはゲームサーバ10の制御部11によって実現される。すなわち、制御部11がプログラムに従って処理を実行することによって、制御部11がこれらの機能ブロックとして機能するようになる。
特定ユーザ間取引許可部106は、第1ユーザと第2ユーザとが特定関係を有する場合に、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可する。
まず、「ユーザ間取引」について説明する。先述したように、「ユーザ間取引」とはゲーム内においてユーザ間で行われる取引である。例えば、ユーザ間で行われる譲渡が「ユーザ間取引」の一例に相当する。「譲渡」は有償譲渡であってもよいし、無償譲渡であってもよい。「有償譲渡」には交換又は売買が含まれる。例えば、第1ユーザが第2ユーザとゲームアイテムを交換することや、第1ユーザが第2ユーザからゲームアイテムを購入すること等が「ユーザ間取引」の一例に相当する。
また例えば、ユーザ間で行われる貸与も「ユーザ間取引」の一例に相当し得る。「貸与」は有償貸与であってもよいし、無償貸与であってもよい。例えば、第1ユーザが第2ユーザにゲームアイテムを貸すことも「ユーザ間取引」の一例に相当し得る。
次に、「特定関係」について説明する。例えば、第1ユーザに関する情報に第2ユーザに関する情報が含まれている場合に、第1ユーザと第2ユーザとが特定関係を有していると判定される。例えば、第1ユーザに関する情報に第2ユーザに関する情報が含まれており、かつ、第2ユーザに関する情報に第1ユーザに関する情報が含まれている場合に、第1ユーザと第2ユーザとが特定関係を有していると判定される。
また例えば、第1ユーザと第2ユーザとを関連づけるデータがデータベース15(記憶装置)に記憶されている場合に、第1ユーザと第2ユーザとが特定関係を有していると判定される。例えば、第1ユーザの識別情報と第2ユーザの識別情報とが関連づけられている場合に、第1ユーザと第2ユーザとが特定関係を有していると判定される。
また例えば、「特定関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが申請を承諾することによって成立するような関係である。また例えば、「特定関係」は、一方のユーザが他方のユーザと関係を結ぶことを申請し、かつ、該他方のユーザが該一方のユーザと関係を結ぶことを申請することによって成立するような関係であってもよい。また例えば、「特定関係」は、ゲームシステム1が複数のユーザが互いに関係を結ぶように提案し、それら複数のユーザが提案を承諾した場合に成立するような関係であってもよい。また例えば、「特定関係」は、ゲームシステム1が自動的(強制的)に複数のユーザに関係を結ばせることによって成立するような関係であってもよい。
図2〜図9に示した例の場合、仲間関係(又は友人関係)が「特定関係」の一例に相当し、ゲームアイテムの交換が「ユーザ間取引」の一例に相当する。このため、例えば、特定ユーザ間取引許可部106は、第1ユーザと第2ユーザとが仲間関係を有している場合に、ゲーム内におけるゲームアイテムの交換を第1ユーザと第2ユーザとの間で行うことを許可する。
承認権限者設定部100は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。
例えば、承認権限者設定部100は、ユーザ間の関係に関するデータに基づいて、第1ユーザ及び第2ユーザ以外のユーザのうちから承認権限者を設定する。ここで、「ユーザ間の関係」とは「ゲーム内において築かれるユーザ間の関係」のことを意味する。例えば、上記の特定関係や仲間関係(又は友人関係)が「ユーザ間の関係」の一例に相当する。また、例えば、上記の特定関係や仲間関係(又は友人関係)を示すデータが「ユーザ間の関係に関するデータ」の一例に相当する。例えば、ユーザテーブルの「ユーザID」及び「仲間」フィールドが「ユーザ間の関係に関するデータ」の一例に相当する。
例えば、第1ユーザと第2ユーザとが他のユーザを介して関係づけられている場合に、承認権限者設定部100は該他のユーザを承認権限者として設定する。
ここで、「第1ユーザと第2ユーザとが他のユーザを介して関係づけられている」とは、例えば、第1ユーザと第2ユーザとが直接的に関係づけられていないが、他のユーザが介在することによって、第1ユーザと第2ユーザとが間接的に関係づけられている」ことを意味する。例えば、第1ユーザと第3ユーザとが直接的に関係づけられており、かつ、第3ユーザと第2ユーザとが直接的に関係づけられている場合(言い換えれば、第1ユーザと第3のユーザとが直接的な関係を築いており、かつ、第3ユーザと第2ユーザとが直接的な関係を築いている場合)に、第1ユーザと第2ユーザとが第3ユーザを介して関係づけられていることになる。このような場合に、承認権限者設定部100は第3ユーザを承認権限者として設定する。
なお、承認権限者設定部100の機能は下記のように言い換えることができる。
例えば、承認権限者設定部100は、第1ユーザと所定関係を有し、かつ、第2ユーザと所定関係を有する他のユーザを承認権限者として設定する。
ここで、「第1ユーザと所定関係を有するユーザ」とは、例えば、第1ユーザと直接的な関係を築いているユーザである。すなわち、第1ユーザと直接的に関係づけられているユーザである。
例えば、上記の「特定関係」が「所定関係」の一例に相当する。このため、例えば、承認権限者設定部100は、第1ユーザと特定関係を有し、かつ、第2ユーザと特定関係を有する他のユーザを承認権限者として設定する。
先述したように、図2〜図9に示した例では、仲間関係(又は友人関係)が「特定関係」の一例に相当している。このため、承認権限者設定部100は、第1ユーザと仲間関係を有し、かつ、第2ユーザと仲間関係を有する他のユーザを承認権限者として設定する。
承認結果情報取得部102は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認権限者が承認したか否かの承認結果に関する承認結果情報を取得する。
ユーザ間取引許可部104は、承認結果情報に基づいて、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可するか否かを決定する。
例えば、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認権限者が承認した場合に、ユーザ間取引許可部104は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可すると決定する。一方、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認権限者が承認しなかった場合に、ユーザ間取引許可部104は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可しないと決定する。
本実施形態に係るゲームシステム1では、第1ユーザと第2ユーザとが特定関係を有する場合、特定ユーザ間取引許可部106によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可される。一方、第1ユーザと第2ユーザとが特定関係を有しない場合には、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可するか否かがユーザ間取引許可部104によって決定されることになる。
ユーザ間取引実行部108は、第1ユーザと第2ユーザとの間でユーザ間取引を行うことを許可すると決定された場合に、第1ユーザと第2ユーザとの間のユーザ間取引を実行する。すなわち、第1ユーザと第2ユーザとの間でユーザ間取引を行うことを許可すると決定された場合、第1ユーザと第2ユーザとの間のユーザ間取引を実行可能な状態となり、ユーザ間取引実行部108は第1ユーザと第2ユーザとの間のユーザ間取引を実行する。
例えば、ユーザ間取引実行部108は、第1ユーザが所有している利用対象のうちの、当該ユーザ間取引の対象である利用対象を第1ユーザの利用対象の所有状況を示すデータから取り除き、第2ユーザの利用対象の所有状況を示すデータに追加し、かつ、第2ユーザが所有している利用対象のうちの、当該ユーザ間取引の対象である利用対象を第2ユーザの利用対象の所有状況を示すデータから取り除き、第1ユーザの利用対象の所有状況を示すデータに追加することによって、第1ユーザと第2ユーザとの間のユーザ間取引を実行する。
先述したように、「利用対象」とはゲームにおいてユーザによって利用される対象であり、例えば、ゲームにおいて利用されるオブジェクト又はポイント等が「利用対象」の一例に相当する。例えば、ゲームにおいて利用されるゲームアイテム、ゲームカード、ゲームキャラクタ、又はゲーム内通貨等が「利用対象」の一例に相当する。
また、「ユーザの上記利用対象の所有状況を示すデータ」(以下「所有状況データ」と記載する。)には、例えば、ユーザが所有している利用対象のリストを示すデータが含まれる。言い換えれば、例えば、ユーザが個々の利用対象を所有しているか否かを示すデータや、ユーザが所有している個々の利用対象の量を示すデータが「所有状況データ」に含まれる。
例えば、ユーザが所有しているゲームアイテムのリストを示すデータが「所有状況データ」に含まれる。言い換えれば、例えば、ユーザが個々のゲームアイテムを所有しているか否かを示すデータや、ユーザが所有している個々のゲームアイテムの個数を示すデータが「所有状況データ」に含まれる。例えば、図10に示すユーザテーブルの場合、ユーザテーブルの「所有アイテムリスト」フィールドが「所有状況データ」の一例に相当する。
例えば、ユーザA,Bの間の取引が「ユーザAが所有しているゲームアイテムXをユーザBに譲り渡す」という取引を含む場合、ユーザ間取引実行部108は、ユーザAが所有しているゲームアイテムのリストから1個のゲームアイテムXを取り除くようにして、ユーザAの所有状況データを更新し、ユーザBが所有しているゲームアイテムのリストに1個のゲームアイテムXを加えるようにして、ユーザBの所有状況データを更新する。
なお、ユーザAがゲームアイテムXを複数所有している場合であれば、ユーザ間取引実行部108は、ユーザAが所有しているゲームアイテムXの個数が一つ減るようにして、ユーザAの所有状況データを更新する。また、ユーザBがゲームアイテムXをすでに所有している場合であれば、ユーザ間取引実行部108は、ユーザBが所有しているゲームアイテムXの個数が一つ増えるようにして、ユーザBの所有状況データを更新する。
なお例えば、ユーザが所有しているポイント量を示すデータも「所有状況データ」の一例に相当し得る。例えば、ユーザA,Bの間の取引が「ユーザAからユーザBに100ポイントを譲り渡す」という取引を含む場合、ユーザ間取引実行部108は、ユーザAが所有しているポイント量(ポイント残高)が100ポイント減るようにして、ユーザAの所有状況データを更新し、ユーザBが所有しているポイント量(ポイント残高)が100ポイント増えるようにして、ユーザBの所有状況データを更新する。
なお、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが特定ユーザ間取引許可部106によって許可された場合にも、ユーザ間取引実行部108は第1ユーザと第2ユーザとの間のユーザ間取引を実行する。
次に、ゲームシステム1で実行される処理について説明する。図13は、ユーザが仲間関係を有していないユーザに取引を申し込む場合に実行される処理の一例を示す。なお以下では、ユーザAが仲間関係を有していないユーザに取引を申し込む場合を想定して上記処理について説明する。
図13に示すように、まず、端末20の制御部21は仲介者候補リスト画面データをゲームサーバ10に要求する(S101)。仲介者候補リスト画面データは仲介者候補リスト画面30を表示するためのデータ(例えばページデータ)である。ステップS101ではユーザAのユーザIDがゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、ゲームサーバ10の制御部11は仲介者候補リスト画面データをユーザAの端末20に送信する(S102)。例えば、制御部11はユーザテーブルを参照し、ユーザAと仲間関係を有しているユーザのリストを取得する。制御部11はこのリストに基づいて仲介者候補リスト画面データを生成し、ユーザAの端末20に送信する。
仲介者候補リスト画面データがユーザAの端末20で受信された場合、端末20の制御部21は仲介者候補リスト画面30を表示部25に表示する(S103)。
仲介者候補リスト画面30に表示される仲介者候補のうちのいずれかが仲介者(承認権限者)として選択された場合、制御部21は取引候補リスト画面データをゲームサーバ10に要求する(S104)。取引候補リスト画面データは取引候補リスト画面40を表示するためのデータ(例えばページデータ)である。ステップS104では、ユーザAのユーザIDや、仲介者として選択されたユーザのユーザIDがゲームサーバ10に送信される。なお以下では、ユーザCが仲介者として選択された場合を想定する。
上記要求がゲームサーバ10で受け付けられた場合、ゲームサーバ10の制御部11は取引候補リスト画面データをユーザAの端末20に送信する(S105)。例えば、制御部11はユーザテーブルを参照し、ユーザCと仲間関係を有するユーザを特定する。すなわち、制御部11は、ユーザCのユーザIDが「仲間」フィールドに含まれているユーザを特定する。すなわち、制御部11は、ユーザCのユーザIDが関連づけられているユーザを特定する。さらに、制御部11はユーザテーブルを参照し、ユーザCと仲間関係を有するユーザの所望アイテムリストを取得する。そして、制御部11はこのリストに基づいて取引候補リスト画面データを生成し、ユーザAの端末20に送信する。
取引候補リスト画面データがユーザAの端末20で受信された場合、端末20の制御部21は取引候補リスト画面40を表示部25に表示する(S106)。
取引候補リスト画面40に表示される取引候補のうちのいずれかが選択された場合、制御部21は申込画面データをゲームサーバ10に要求する(S107)。申込画面データは申込画面50を表示するためのデータ(例えばページデータ)である。ステップS107では、ステップS104で送信された情報に加えて、取引相手として選択されたユーザのユーザIDや、取引対象として選択されたゲームアイテムのIDがゲームサーバ10に送信される。なお以下では、ユーザBが取引相手として選択され、ゲームアイテムXが取引対象として選択された場合を想定する。
上記要求がゲームサーバ10で受け付けられた場合、ゲームサーバ10の制御部11は申込画面データをユーザAの端末20に送信する(S108)。申込画面データがユーザAの端末20で受信された場合、端末20の制御部21は申込画面50を表示部25に表示する(S109)。
申込画面50の「はい」ボタン52が選択された場合、制御部21は取引申込の受付をゲームサーバ10に要求する(S110)。すなわち、申込画面50で設定された申込内容がゲームサーバ10に送信される。この場合、ステップS107で送信された情報に加えて、ユーザAによって所望アイテムとして設定されたゲームアイテムのIDや、ユーザAによって入力されたコメントがゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、ゲームサーバ10の制御部11は取引申込の内容をデータベース15に登録する(S111)。すなわち、取引申込の内容がユーザ間取引テーブルに登録される。
例えば、ユーザ間取引テーブルに新たなレコードが追加される。そして、新たに付与された取引IDが「取引ID」フィールドに登録される。ユーザAのユーザIDが「申込者」フィールドに登録され、取引候補リスト画面40で取引相手として選択されたユーザBのユーザIDが「取引相手」フィールドに登録される。また、仲介者候補リスト画面30で仲介者(承認権限者)として選択されたユーザCのユーザIDが「承認権限者」フィールドに登録される。取引候補リスト画面40で取引対象として選択されたゲームアイテムXが「アイテム1」フィールドに登録される。申込画面50の所望アイテム欄56に設定されたゲームアイテムが「アイテム2」フィールドに登録され、コメント欄58に入力されたコメントが「コメント」フィールドに登録される。さらに、値「0」(取引相手の受諾待ち)が「状況」フィールドに登録され、現在日時が「申込日時」及び「更新日時」フィールドに登録される。
図14は、ユーザAからユーザBへの申し込みが受け付けられた後にユーザBがトップ画面にアクセスする場合に実行される処理の一例を示す。なお、先述したように、このトップ画面は例えばユーザB専用のトップ画面である。
図14に示すように、まず、ユーザBの端末20の制御部21はトップ画面データをゲームサーバ10に要求する(S201)。トップ画面データはトップ画面を表示するためのデータ(例えばページデータ)である。ステップS201では、ユーザBのユーザIDがゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、制御部11はユーザ間取引テーブルを参照し、ユーザBへの取引申込に関する情報を取得する(S202)。例えば、制御部11は、下記のような二つの条件をすべて満足する取引に関する情報を取得する。
(1)ユーザBが取引相手として登録されている。
(2)状況が「取引相手の受諾待ち」である。
その後、制御部11はトップ画面データをユーザBの端末20に送信する(S203)。この場合、トップ画面データにはステップS202で取得された取引申込のリストが埋め込まれる。トップ画面データがユーザBの端末20で受信された場合、制御部21はトップ画面を表示部25に表示する(S204)。この場合、ユーザBへの取引申込のリストがトップ画面に表示される。
トップ画面に表示された取引申込のいずれかがユーザBによって選択された場合、制御部21は受諾画面データをゲームサーバ10に要求する(S205)。受諾画面データは受諾画面60を表示するためのデータ(例えばページデータ)である。ステップS205では、ステップS201で送信される情報に加えて、ユーザBによって選択された取引申込の取引IDがゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、制御部11は受諾画面データをユーザBの端末20に送信する(S206)。例えば、制御部11はユーザ間取引テーブルを参照し、ユーザBによって選択された取引申込に関する情報を取得する。この情報に基づいて、制御部11は受諾画面データを生成し、ユーザBの端末20に送信する。
受諾画面データがユーザBの端末20で受信された場合、制御部21は受諾画面60を表示部25に表示する(S207)。受諾画面60の「はい」ボタン62又は「いいえ」ボタン64が選択された場合、制御部21は確認画面データをゲームサーバ10に要求する(S208)。確認画面データは確認画面70を表示するためのデータ(例えばページデータ)である。ステップS208では、ステップS205で送信される情報に加えて、受諾結果を示す情報がゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、制御部11は確認画面データをユーザBの端末20に送信する(S209)。この場合、制御部21は確認画面70を表示部25に表示する(S210)。確認画面70の「はい」ボタン72が選択された場合、制御部21は受諾結果の登録をゲームサーバ10に要求する(S211)。
上記要求がゲームサーバ10で受け付けられた場合、制御部11は受諾結果をユーザ間取引テーブルに登録する(S212)。例えば、制御部11はユーザ間取引テーブルにアクセスし、「アイテム3」、「受諾結果」、「状況」、及び「更新日時」フィールドを更新する。
例えば、ユーザBが取引申込を受諾した場合、ユーザBがユーザAに提供するゲームアイテムとして選択したゲームアイテムが「アイテム3」に登録され、値「1」が「受諾結果」フィールドに登録される。また、「状況」フィールドが「1」(承認権限者の承認待ち)に更新される。一方、ユーザBが取引申込を受諾しなかった場合には、「受諾結果」フィールドに「0」に登録され、「状況」フィールドが「3」(不成立)に変更される。なお、いずれの場合にも現在日時が「更新日時」フィールドに登録される。
図15は、ユーザBがユーザAからの申し込みを受諾した後にユーザCがトップ画面にアクセスした場合に実行される処理の一例を示す。なお、このトップ画面は例えばユーザC専用のトップ画面であり、このトップ画面にはユーザCへの各種お知らせが表示される。
図15に示すように、まず、ユーザCの端末20の制御部21はトップ画面データをゲームサーバ10に要求する(S301)。トップ画面データはトップ画面を表示するためのデータ(例えばページデータ)である。ステップS301では、ユーザCのユーザIDがゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、制御部11はユーザ間取引テーブルを参照し、ユーザCが承認権限者として設定されている取引に関する情報を取得する(S302)。例えば、制御部11は、下記のような二つの条件をすべて満足する取引に関する情報を取得する。
(1)ユーザCが承認権限者として登録されている。
(2)状況が「承認権限者の承認待ち」である。
その後、制御部11はトップ画面データをユーザCの端末20に送信する(S303)。この場合、トップ画面データにはステップS302で取得された取引のリストが埋め込まれる。
トップ画面データがユーザCの端末20で受信された場合、制御部21はトップ画面を表示部25に表示する(S304)。この場合、ユーザCが承認権限者として設定されている取引のリストがトップ画面に表示される。
トップ画面に表示された取引のいずれかがユーザCによって選択された場合、制御部21は承認画面データをゲームサーバ10に要求する(S305)。承認画面データは承認画面80を表示するためのデータ(例えばページデータ)である。ステップS305では、ステップS301で送信される情報に加えて、ユーザCによって選択された取引の取引IDがゲームサーバ10に送信される。
上記要求がゲームサーバ10で受け付けられた場合、制御部11は承認画面データをユーザCの端末20に送信する(S306)。例えば、制御部11はユーザ間取引テーブルを参照し、ユーザCによって選択された取引に関する情報を取得する。この情報に基づいて、制御部11は承認画面データを生成し、ユーザCの端末20に送信する。
承認画面データがユーザCの端末20で受信された場合、制御部21は承認画面80を表示部25に表示する(S307)。承認画面80の「はい」ボタン82又は「いいえ」ボタン84が選択された場合、制御部21は承認結果をゲームサーバ10に通知する(S308)。
上記通知がゲームサーバ10で受信された場合、制御部11はユーザ間取引が承認されたか否かを判定する(S309)。ユーザ間取引が承認されたと判定された場合、制御部11はこのユーザ間取引を許可すると決定し、このユーザ間取引を実行する(S310)。例えば、図8に示すようなユーザA,B間のユーザ間取引が承認権限者(ユーザC)によって承認されたと判定された場合、制御部11はこのユーザA,B間のユーザ間取引を許可すると決定し、このユーザA,B間のユーザ間取引を実行する。すなわち、制御部11は、1個のゲームアイテムXをユーザAの所有アイテムリストから取り除き、1個のゲームアイテムXをユーザBの所有アイテムリストに追加する。また、制御部11は、1個のゲームアイテムYをユーザBの所有アイテムリストから取り除き、1個のゲームアイテムYをユーザAの所有アイテムリストに追加する。
ステップS310が実行された後、制御部11は取引結果をユーザ間取引テーブルに登録する(S311)。例えば、制御部11はユーザ間取引テーブルにアクセスし、「承認結果」、「状況」、及び「更新日時」フィールドを更新する。例えば、「承認結果」フィールドに「1」が登録され、「状況」フィールドが「2」(成立)に変更される。また、現在日時が「更新日時」フィールドに登録される。
ステップS309において、ユーザ間取引が承認されなかったと判定された場合、制御部11はこのユーザ間取引を許可しないと決定し、このユーザ間取引を実行することなく、ステップS311を実行する。すなわち、制御部11は取引結果を取引テーブルに登録する(S311)。例えば、制御部11はユーザ間取引テーブルにアクセスし、「承認結果」、「状況」、及び「更新日時」フィールドを更新する。例えば、「承認結果」フィールドに「0」が登録され、「状況」フィールドが「3」(不成立)に変更される。また、現在日時が「更新日時」フィールドに登録される。
以上に説明したように、第1実施形態に係るゲームシステム1では、仲間関係を有していないユーザA,Bの間の取引が、ユーザA,Bの両方と仲間関係を有しているユーザC(承認権限者)によって承認されることによって成立する。ゲームシステム1によれば、取引を行うユーザの両方と仲間関係を有しているユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム1によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
[第2実施形態]本発明の第2実施形態について説明する。第2実施形態に係るゲームシステム1の全体構成は第1実施形態と同様である(図1参照)。また、第2実施形態に係るゲームシステム1もユーザ間取引機能を備えている。
第1実施形態に係るゲームシステム1では、個々のユーザ同士が仲間関係を結ぶようになっていたが、第2実施形態に係るゲームシステム1では、複数のユーザが所属するユーザグループが設定されるようになっている。
例えば、「ユーザグループ」とは、協力してゲームを進めるべく集まったユーザの集まりである。また例えば、「ユーザグループ」とは、共通の目的を達成すべく集まったユーザの集まりである。同一のユーザグループに所属する複数のユーザには同一の識別情報(例えばユーザグループID)が関連付けられることになるため、「ユーザグループ」とは、同一の識別情報(例えばユーザグループID)に関連づけられたユーザの集まりということもできる。また、ゲームによっては、同じユーザグループに所属する複数のユーザだけが共通に使用可能な機能(例えば掲示板又はチャット等)が用意される場合がある。このため、「ユーザグループ」とは、特定の機能を共通に使用可能なユーザの集まりということもできる。なお、ユーザグループは「チーム」、「ギルド」、又は「パーティ」等の名称で呼ばれる場合もある。
図16はユーザグループの一例を示す。図16に示す例では、ユーザA,C,D,E,Fが所属するユーザグループG1と、ユーザB,C,G,H,Iが所属するユーザグループG2と、ユーザH,J,K,L,Mが所属するユーザグループG3とが設定されている。なお、図16に示す例では、ユーザCがユーザグループG1,G2の両方に所属しており、ユーザHがユーザグループG2,G3の両方に所属している。
また、各ユーザグループでは、ユーザグループに所属するいずれかのユーザがリーダー(代表者)として設定されるようになっている。図16における星印は各ユーザグループのリーダーを示している。なお、リーダー以外の役割(例えばサブリーダー等)が設定されるようにしてもよい。
第2実施形態に係るゲームシステム1では、原則として、同じユーザグループに所属するユーザ間で取引(ゲーム内取引)を行うことが許容される。また、第2実施形態に係るゲームシステム1では、同じユーザグループに所属していないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、同じユーザグループに所属していないユーザ間でも取引を行うことが可能である。
図17は上記のようなユーザ間取引機能について説明するための図であり、三名のユーザA,B,Cの関係の一例を示す。
図17に示す例では、ユーザA,Cは同じユーザグループG1に所属しているため、ユーザA,Cの間では取引を行うことが可能である。同様に、ユーザB,Cは同じユーザグループG2に所属しているため、ユーザB,Cの間では取引を行うことが可能である。
さらに、第2実施形態に係るゲームシステム1では、ユーザAと同じユーザグループに所属し、かつ、ユーザBと同じユーザグループに所属するユーザCが承認すれば、同じユーザグループに所属していないユーザA,Bの間でも取引を行うことが可能になっている。すなわち、上記のようなユーザCが仲介者(承認権限者)となることによって、同じユーザグループに所属していないユーザA,Bの間でも取引を行うことが可能になっている。
第2実施形態に係るゲームシステム1においても、第1実施形態と同様の画面が表示される(図3〜図9参照)。ただし、第2実施形態に係るゲームシステム1の場合、仲介者候補リスト画面30には、ユーザAと同じユーザグループに所属するユーザのリストが表示される。また、取引候補リスト画面40には、仲介者として選択されたユーザが所属しているユーザグループ(ユーザAが所属しているユーザグループを除く。)に所属している各ユーザの所望アイテムリストが表示される。
第2実施形態に係るゲームシステム1で記憶されるデータについて説明する。図18は第2実施形態におけるユーザテーブルの一例を示す。図18に示すユーザテーブルは、「仲間」フィールドの代わりに「所属グループ」フィールドを含む点で、図10に示すユーザテーブルと相違する。「所属グループ」フィールドにはユーザが所属するユーザグループが登録される。例えば、ユーザが所属するユーザグループの識別情報(ユーザグループID)が「所属グループ」フィールドに登録される。ユーザが複数のユーザグループに所属する場合には、それら複数のユーザグループの各々の識別情報(ユーザグループID)が「所属グループ」フィールドに登録される。なお、ここでは省略されているが、実際には、各ユーザグループ内の役割(例えばリーダー)を割り当てられているユーザを特定するためのデータがデータベース15に記憶される。また、ユーザ間取引テーブルは第1実施形態と同様である(図11参照)。
第2実施形態に係るゲームシステム1で実現される機能ブロックは基本的に第1実施形態と同様である(図12参照)。ただし、承認権限者設定部100及び特定ユーザ間取引許可部106の機能は第1実施形態と異なる点があるため、この点について説明する。
第2実施形態における特定ユーザ間取引許可部106は、第1ユーザと第2ユーザとが特定関係を有する場合に、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可する。この点は第1実施形態と同様である。
しかしながら、第2実施形態に係る特定ユーザ間取引許可部106は、第1ユーザと第2ユーザとが同じユーザグループに所属する場合に、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可する。すなわち、第2実施形態では、同じユーザグループに所属するような関係が「特定関係」の一例に相当する。
第2実施形態における承認権限者設定部100は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。例えば、承認権限者設定部100は、ユーザ間の関係に関するデータに基づいて、第1ユーザ及び第2ユーザ以外のユーザのうちから承認権限者を設定する。例えば、承認権限者設定部100は、第1ユーザと所定関係を有し、かつ、第2ユーザと所定関係を有する他のユーザを承認権限者として設定する。この点は第1実施形態と同様である。
第2実施形態の場合にも、例えば、上記の「特定関係」が「所定関係」の一例に相当する。このため、例えば、承認権限者設定部100は、第1ユーザと特定関係を有し、かつ、第2ユーザと特定関係を有する他のユーザを承認権限者として設定する。
先述したように、第2実施形態の場合、同じユーザグループに所属するような関係が「特定関係」の一例に相当する。このため、第2実施形態における承認権限者設定部100は、第1ユーザと同じユーザグループに所属し、かつ、第2ユーザと同じユーザグループに所属する他のユーザを承認権限者として設定する。
第2実施形態に係るゲームシステム1において実行される処理も基本的に第1実施形態と同様である(図13〜図15参照)。
ただし、図13のステップS102において、制御部11はユーザテーブルを参照し、ユーザAと同じユーザグループに所属しているユーザのリストを取得する。例えば、制御部11はユーザAの「所属グループ」フィールドを参照し、ユーザAが所属しているユーザグループのユーザグループIDを取得する。また、制御部11は、ユーザAが所属しているユーザグループのユーザグループIDが「所属グループ」フィールドに含まれているユーザを特定する。すなわち、制御部11は、ユーザAが所属しているユーザグループのユーザグループIDが関連づけられているユーザを特定する。そして、制御部11は上記のユーザのリストに基づいて仲介者候補リスト画面データを生成し、ユーザAの端末20に送信する。
また、図13のステップS105において、制御部11はユーザテーブルを参照し、ユーザCと同じユーザグループに所属しているユーザを特定する。さらに、制御部11はユーザテーブルを参照し、特定されたユーザの所望アイテムリストを取得する。そして、制御部11はこのリストに基づいて取引候補リスト画面データを生成し、ユーザAの端末20に送信する。
以上に説明したように、第2実施形態に係るゲームシステム1では、同じユーザグループに所属していないユーザA,Bの間の取引が、ユーザA,Bの各々と同じユーザグループに所属しているユーザC(承認権限者)によって承認されることによって成立する。ゲームシステム1によれば、取引を行うユーザの各々と同じユーザグループに所属しているユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム1によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
[第3実施形態]本発明の第3実施形態について説明する。第3実施形態に係るゲームシステム1の全体構成は第1実施形態と同様である(図1参照)。また、第3実施形態に係るゲームシステム1もユーザ間取引機能を備えている。
第3実施形態に係るゲームシステム1では、個々のユーザ同士が友人関係を結ぶことが可能になっている。さらに、第3実施形態に係るゲームシステム1では、複数のユーザが所属するユーザグループを設定することも可能になっている。第3実施形態における「友人関係」は第1実施形態における「仲間関係」と類似のものであり、第3実施形態における「ユーザグループ」は第2実施形態における「ユーザグループ」と同様のものである。第3実施形態では、友人関係とユーザグループとの両方が別個のものとして設定される点で第1実施形態及び第2実施形態と異なっている。
第3実施形態に係るゲームシステム1では、原則として、友人関係を有するユーザ間で取引(ゲーム内取引)を行うことが許容される。また、第3実施形態に係るゲームシステム1では、友人関係を有していないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、友人関係を有していないユーザ間でも取引を行うことが可能になっている。
以下、第3実施形態におけるユーザ間取引機能の例について説明する。なおここでは、図16に示すようなユーザグループが設定されている場合を想定し、図16を参照しながら、第3実施形態におけるユーザ間取引機能の例について説明する。
まず、第1の例について説明する。ここでは、ユーザA,Eが取引を行う場合を想定する。なお、ユーザA,Eは友人関係を有していないこととする。図19はこの場合のユーザ間取引機能について説明するための図である。
先述したように、第3実施形態に係るゲームシステム1では、原則として、友人関係を有するユーザ間で取引を行うことが許容されるようになっている。この点、ユーザA,Eは友人関係を有していないが、第3実施形態に係るゲームシステム1では、ユーザA,Eと同じユーザグループに所属するユーザDが承認すれば、友人関係を有していないユーザA,Eの間でも取引を行うことが可能になっている。すなわち、上記のようなユーザDが仲介者(承認権限者)となることによって、友人関係を有していないユーザA,Eの間でも取引を行うことが可能になっている。
なお、ユーザA,Eが所属するユーザグループにおいて所定の役割を担っているユーザが承認した場合にのみ、ユーザA,Eの間でも取引を行うことが可能になるようにしてもよい。すなわち、ユーザA,Eが所属するユーザグループにおいて所定の役割を担っているユーザが仲介者(承認権限者)として設定されるようにしてもよい。
「所定の役割を担っているユーザ」とは、例えば、特別の権限が付与されたユーザである。言い換えれば、「所定の役割を担っているユーザ」とは、例えば、ユーザグループに所属する他のユーザが有していないような権限を有しているユーザである。
例えば、ユーザグループのリーダーが「所定の役割を担っているユーザ」の一例に相当する。このため、例えば、ユーザA,Eが所属するユーザグループのリーダーであるユーザFが承認した場合にのみ、ユーザA,Eの間でも取引を行うことが可能になるようにしてもよい。すなわち、ユーザA,Eが所属するユーザグループのリーダーであるユーザFが仲介者(承認権限者)として設定されるようにしてもよい。
第2の例について説明する。ここでは、ユーザA,Bが取引を行う場合を想定する。なお、ユーザA,Bは友人関係を有していないこととする。また、この場合のユーザ間取引機能は図17に示した例に類似しているため、ここでは図17を参照しながら説明する。
先述したように、第3実施形態に係るゲームシステム1では、原則として、友人関係を有するユーザ間で取引を行うことが許容されるようになっている。この点、ユーザA,Bは友人関係を有していないが、第3実施形態に係るゲームシステム1では、ユーザAと同じユーザグループに所属し、かつ、ユーザBと同じユーザグループに所属するユーザCが承認すれば、友人関係を有していないユーザA,Bの間でも取引を行うことが可能になっている。すなわち、上記のようなユーザCが仲介者(承認権限者)となることによって、友人関係を有していないユーザA,Bの間でも取引を行うことが可能になっている。
先述したように、この場合のユーザ間取引機能は図17に示したユーザ間取引機能(第2実施形態)と類似している。しかしながら、第2実施形態は、原則として、同じユーザグループに所属するユーザ間で取引が許容されるところ、例えば、同じユーザグループに所属してないユーザA,Bの間でも、ユーザAと同じユーザグループに所属し、かつ、ユーザBと同じユーザグループに所属するユーザCが承認すれば、取引を許容するものである。これに対し、第3実施形態は、原則として、友人関係を有するユーザ間で取引が許容されるところ、例えば、友人関係を有していないユーザA,Bの間でも、ユーザAと同じユーザグループに所属し、かつ、ユーザBと同じユーザグループに所属するユーザCが承認すれば、取引を許容するものである。この点で第3実施形態は第2実施形態と異なっている。
第3実施形態に係るゲームシステム1では第2実施形態と同様の画面が表示される。すなわち、仲介者候補リスト画面30には、ユーザAと同じユーザグループに所属するユーザのリストが表示される。また、取引候補リスト画面40には、仲介者として選択されたユーザが所属しているユーザグループ(ユーザAが所属しているユーザグループを除く。)に所属している各ユーザの所望アイテムリストが表示される。
また、第3実施形態におけるユーザテーブルは、図10に示すユーザテーブルと図18に示すユーザテーブルとを組み合わせたようなテーブルとなる。すなわち、第3実施形態におけるユーザテーブルは「仲間」フィールドと「所属グループ」フィールドとの両方を含む。
第3実施形態に係るゲームシステム1で実現される機能ブロックは基本的に第1実施形態と同様である(図12参照)。
第3実施形態における特定ユーザ間取引許可部106は第1実施形態と同様である。すなわち、特定ユーザ間取引許可部106は、第1ユーザと第2ユーザとが特定関係を有する場合に、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを許可する。
第3実施形態では、友人関係が「特定関係」の一例に相当し、特定ユーザ間取引許可部106は、第1ユーザと第2ユーザとが友人関係を有している場合に、ゲーム内におけるゲームアイテムの交換を第1ユーザと第2ユーザとの間で行うことを許可する。
第3実施形態における承認権限者設定部100は第1実施形態と異なる点がある。この点について説明する。
承認権限者設定部100は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。例えば、承認権限者設定部100は、ユーザ間の関係に関するデータに基づいて、第1ユーザ及び第2ユーザ以外のユーザのうちから承認権限者を設定する。例えば、承認権限者設定部100は、第1ユーザと所定関係を有し、かつ、第2ユーザと所定関係を有する他のユーザを承認権限者として設定する。この点は第1実施形態と同様である。
ただし、第3実施形態の場合、例えば、上記の「特定関係」以外の関係が「所定関係」の一例に相当する。すなわち、第3実施形態の場合、同じユーザグループに所属するような関係が「所定関係」の一例に相当する。このため、第3実施形態における承認権限者設定部100は、第1ユーザと同じユーザグループに所属し、かつ、第2ユーザと同じユーザグループに所属する他のユーザを承認権限者として設定する。
例えば、先述した第1の例のように、ユーザA(第1ユーザ)とユーザE(第2ユーザ)とがともにユーザグループG1に所属している場合、承認権限者設定部100は、ユーザAが所属するユーザグループG1に所属し、かつ、ユーザEが所属するユーザグループG1に所属する他のユーザを承認権限者として設定する。すなわち、承認権限者設定部100は、ユーザA,Eの両方が所属しているユーザグループG1に所属する他のユーザ(例えばユーザD)を承認権限者として設定する。
なおこの場合、承認権限者設定部100は、ユーザA,Eの両方が所属しているユーザグループG1において所定の役割を担っている他のユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部100は、ユーザグループG1に所属するユーザのうち、他のユーザが有していないような権限を有しているユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部100は、ユーザグループG1のリーダーであるユーザFを承認権限者として設定するようにしてもよい。
また例えば、先述した第2の例のように、ユーザA(第1ユーザ)とユーザB(第2ユーザ)とが異なるユーザグループG1,G2にそれぞれ所属している場合、承認権限者設定部100は、ユーザAが所属しているユーザグループG1に所属し、かつ、ユーザBが所属しているユーザグループG2に所属する他のユーザ(例えばユーザC)を承認権限者として設定する。
第3実施形態における承認結果情報取得部102、ユーザ間取引許可部104、及びユーザ間取引実行部108は第1実施形態と同様である。
また、第3実施形態に係るゲームシステム1で実行される処理も基本的に第2実施形態と同様である。
以上に説明した第3実施形態に係るゲームシステム1では、友人関係を有していないユーザA,Bの間の取引が、ユーザA,Bの各々と同じユーザグループに所属しているユーザC(承認権限者)によって承認されることによって成立する。ゲームシステム1によれば、取引を行うユーザの各々と同じユーザグループに所属しているユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム1によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
なお、第3実施形態に係るゲームシステム1では、原則として、同じユーザグループに所属するユーザ間で取引(ゲーム内取引)を行うことが許容されるようにしてもよい。また、第3実施形態に係るゲームシステム1では、同じユーザグループに所属していないユーザ間の取引を承認する権限を有する承認権限者が承認すれば、同じユーザグループに所属していないユーザ間でも取引を行うことが可能となるようにしてもよい。
図20は上記のようなユーザ間取引機能について説明するための図であり、三名のユーザA,B,Jの関係の一例を示す。なおここでは、図16に示すようなユーザグループが設定されていることとする。
先述したように、ここで説明している例では、原則として、同じユーザグループに所属するユーザ間で取引を行うことが許容されるようになっている。この点、ユーザA,Bは同じユーザグループに所属していないが(図16参照)、この場合、ユーザAと友人関係を有し、かつ、ユーザBと友人関係を有するユーザJが承認すれば、同じユーザグループに所属してないユーザA,Bの間でも取引を行うことが可能になる。すなわち、上記のようなユーザJが仲介者(承認権限者)となることによって、同じユーザグループに所属していないユーザA,Bの間でも取引を行うことが可能になる。
なお、図20に示したユーザ間取引機能は図2に示したユーザ間取引機能(第1実施形態)と類似している。しかしながら、第1実施形態(図2)は、原則として、仲間関係(又は友人関係)を有するユーザ間で取引が許容されるところ、例えば、仲間関係(又は友人関係)を有していないユーザA,Bの間でも、ユーザAと仲間関係(又は友人関係)を有し、かつ、ユーザBと仲間関係(又は友人関係)を有するユーザCが承認すれば、取引を許容するものである。これに対し、第3実施形態(図20)は、原則として、同じユーザグループに所属するユーザ間で取引を行うことが許容されるところ、例えば、同じユーザグループに所属していないユーザA,Bの間でも、ユーザAと友人関係を有し、かつ、ユーザBと友人関係を有するユーザJが承認すれば、取引を許容するものである。この点で第3実施形態(図20)は第1実施形態(図2)と異なっている。
ここで説明した例の場合、特定ユーザ間取引許可部106は、第1ユーザと第2ユーザと同じユーザグループに所属している場合に、ゲーム内におけるゲームアイテムの交換を第1ユーザと第2ユーザとの間で行うことを許可する。また、承認権限者設定部100は、第1ユーザと友人関係を有し、かつ、第2ユーザと友人関係を有する他のユーザを承認権限者として設定する。
この場合、同じユーザグループに所属していないユーザA,Bの間の取引が、ユーザA,Bの各々と友人関係を有しているユーザJ(承認権限者)によって承認されることによって成立する。ゲームシステム1によれば、取引を行うユーザの各々と友人関係を有しているユーザによって取引の内容が確認されることになるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム1によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
[第4実施形態]本発明の第4実施形態について説明する。第4実施形態に係るゲームシステム1の全体構成は第1実施形態と同様である(図1参照)。第4実施形態に係るゲームシステム1もユーザ間取引機能を備えている。
ただし、第4実施形態に係るゲームシステム1の機能ブロック図は図21に示すようになっており、第4実施形態に係るゲームシステム1は特定ユーザ間取引許可部106を含まない点で第1実施形態〜第3実施形態と相違する。
すなわち、第4実施形態に係るゲームシステム1では、第1ユーザと第2ユーザとの間の取引を承認する権限を有する承認権限者が承認した場合にのみ、第1ユーザと第2ユーザとの間で取引を行うことが許可されるようになっている。
第4実施形態における承認権限者設定部100は基本的に第1実施形態〜第3実施形態と同様である。承認権限者設定部100は、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者を設定する。例えば、承認権限者設定部100は、ユーザ間の関係に関するデータに基づいて、第1ユーザ及び第2ユーザ以外のユーザのうちから承認権限者を設定する。
例えば、第1ユーザと第2ユーザとが他のユーザを介して関係づけられている場合に、承認権限者設定部100は該他のユーザを承認権限者として設定する。
また例えば、承認権限者設定部100は、第1ユーザと所定関係を有し、かつ、第2ユーザと所定関係を有する他のユーザを承認権限者として設定する。
例えば、仲間関係(友人関係)が「所定関係」の一例に相当する。すなわち、承認権限者設定部100は、第1ユーザと仲間関係(又は友人関係)を有し、かつ、第2ユーザと仲間関係(又は友人関係)を有する他のユーザを承認権限者として設定する。例えば図2に示すように、承認権限者設定部100は、ユーザAと仲間関係を有し、かつ、ユーザBと仲間関係を有するユーザCを、ユーザA,Bの間の取引を承認する承認権限者として設定する。
また例えば、同じユーザグループに所属するような関係が「所定関係」の一例に相当する。すなわち、承認権限者設定部100は、第1ユーザと同じユーザグループに所属し、かつ、第2ユーザと同じユーザグループに所属する他のユーザを承認権限者として設定する。
例えば図19に示すように、承認権限者設定部100は、ユーザAと同じユーザグループG1に所属し、かつ、ユーザEと同じユーザグループG1に所属するユーザDを、ユーザA,Eの間の取引を承認する承認権限者として設定する。図19に示す例の場合、ユーザA,Eは同じユーザグループG1に所属しているため、承認権限者設定部100は、ユーザA,Eの両方と同じユーザグループG1に所属しているユーザDを、ユーザA,Eの間の取引を承認する承認権限者として設定する。
なおこの場合、承認権限者設定部100は、ユーザA,Eの両方が所属しているユーザグループG1において所定の役割を担っている他のユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部100は、ユーザグループG1に所属するユーザのうち、他のユーザが有していないような権限を有しているユーザを承認権限者として設定するようにしてもよい。例えば、承認権限者設定部100は、ユーザグループG1のリーダーであるユーザFを承認権限者として設定するようにしてもよい。
また例えば図17に示すように、承認権限者設定部100は、ユーザAが所属しているユーザグループG1に所属し、かつ、ユーザBが所属しているユーザグループG2に所属する他のユーザ(例えばユーザC)を、ユーザA,Bの間の取引を承認する承認権限者として設定する。
第4実施形態における承認結果情報取得部102、ユーザ間取引許可部104、及びユーザ間取引実行部108は第1実施形態又は第2実施形態と同様である。
なお、第4実施形態に係るゲームシステム1で表示される画面も第1実施形態又は第2実施形態と同様である。また、第4実施形態に係るゲームシステム1で実行される処理も第1実施形態又は第2実施形態と同様である。
以上に説明した第4実施形態に係るゲームシステム1では、例えば、ユーザA,Bの各々と仲間関係を有するユーザ(承認権限者)によって承認されることによって、ユーザA,Bの間の取引が成立する。また例えば、ユーザA,Bの各々と同じユーザグループに所属しているユーザ(承認権限者)によって承認されることによって、ユーザA,Bの間の取引が成立する。ゲームシステム1によれば、上記のようなユーザによって取引の内容が確認されるため、不正な取引が成立してしまうことを抑制することが可能になる。また、ゲームシステム1によれば、不正行為を行うユーザが参加するおそれがなさそうな取引まで過度に制限されることもない。
[第5実施形態]本発明の第5実施形態について説明する。第5実施形態に係るゲームシステム1の全体構成は第1実施形態と同様である(図1参照)。第5実施形態に係るゲームシステム1もユーザ間取引機能を備えている。
以上に説明した第1実施形態〜第4実施形態では、承認権限者(仲介者)が取引に受動的に関わるようになっていた。第5実施形態に係るゲームシステム1は、承認権限者が取引に能動的に関わる点で第1実施形態〜第4実施形態と異なる。
第5実施形態に係るゲームシステム1の概要について説明する。図22は第5実施形態に係るゲームシステム1の概要について説明するための図である。なお、ここでは、取引を行うユーザと仲間関係を有するユーザが承認権限者(仲介者)として設定される場合を想定する。また、ユーザA,Bの両方とユーザCが仲間関係を有している場合を想定する。
例えば、ユーザCは、ユーザCと仲間関係を有している他のユーザが所望している取引に関する情報(例えば、所望アイテムリスト、出品アイテムリスト、所有アイテムリスト、又は取引条件)を検索することによって、取引が成立するような仲間の組合せを見つける。
例えば、ユーザAの出品アイテムリスト(又は所有アイテムリスト)にゲームアイテムXが登録され、かつ、ユーザBの所望アイテムリストにゲームアイテムXが登録されている場合、ユーザCは、ユーザA,Bを、取引が成立するような仲間の組合せであると判断し、取引の提案対象として選択する。そして、ユーザCはユーザA,Bが取引を行うことを承認し、ユーザA,Bに取引(すなわちゲームアイテムXの授受)を行うように提案する。この場合、ユーザA,Bがともに提案を受け入れれば、ユーザA,Bの間で取引が実行される。
図23は第5実施形態に係るゲームシステム1の機能ブロック図を示す。図23に示すように、第5実施形態に係るゲームシステム1は、第1出力制御部110及び第2出力制御部112を含む点で第1実施形態と相違する。例えば、第1出力制御部110及び第2出力制御部112はゲームサーバ10において実現される。なお、第4実施形態と同様に、特定ユーザ間取引許可部106を省略するようにしてもよい。
第1出力制御部110は、承認権限者によって承認を受ける側の複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、承認権限者の端末20の出力部に出力するための制御を行う。
例えば、「ユーザが所望するユーザ間取引の内容に関する情報」とは、例えば、ユーザの所望アイテムリスト、出品アイテムリスト、又は取引条件(例えば交換条件)等である。
また例えば、ユーザCが、ユーザCと仲間関係を有するユーザの取引の承認権限者(仲介者)として設定され得る場合、「ユーザCによって承認を受ける側の複数のユーザ」とは、ユーザCと仲間関係を有する複数のユーザである。
この場合、第1出力制御部110は、ユーザCの仲間である複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、ユーザCの端末20の表示部25に表示するための制御を行う。例えば、ユーザCの仲間である複数のユーザの各々の所望アイテムリスト、出品アイテムリスト、又は取引条件等がユーザCの端末20の表示部25に表示される。
なお例えば、ユーザCが、ユーザCと同じユーザグループに所属するユーザの取引の承認権限者(仲介者)として設定される場合、「ユーザCによって承認を受ける側の複数のユーザ」とは、ユーザCと同じユーザグループに所属する複数のユーザである。
この場合、第1出力制御部110は、ユーザCと同じユーザグループに所属する複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、ユーザCの端末20の表示部25に表示するための制御を行う。例えば、ユーザCと同じユーザグループに所属する複数のユーザの各々の所望アイテムリスト、出品アイテムリスト、又は取引条件等がユーザCの端末20の表示部25に表示される。そして、ユーザCは表示部25に表示される情報を参照しながら、取引の提案対象とするユーザの組合せを選択する。
第2出力制御部112は、承認権限者によって承認を受ける側の複数のユーザのうちから承認権限者によって選択されたユーザの間でユーザ間取引を行うように提案することを示す提案情報を、承認権限者によって選択されたユーザの端末20の出力部に出力するための制御を行う。
例えば図22に示す例の場合であれば、第2出力制御部112は、承認権限者であるユーザCによって選択されたユーザA,Bの間で取引を行うように提案することを示す提案情報を、ユーザA,Bの各々の端末20に表示するための制御を行う。例えば、第2出力制御部112は、ユーザA,Bの間でゲームアイテムXに関する取引を行うように提案することを示す提案メッセージ(提案情報)を、ユーザA,Bの各々の端末20に表示するための制御を行う。例えば、ユーザA又はユーザBの端末20がゲームサーバ10にアクセスした場合に上記提案メッセージが画面に表示される。
以上に説明した第5実施形態に係るゲームシステム1によれば、承認権限者が積極的に取引に関わることが可能になる。
なお、本発明は以上に説明した第1実施形態〜第5実施形態に限定されるものではない。
[1]例えば、複数のユーザが承認権限者(仲介者)として設定されるようにしてもよい。
図24は、複数のユーザが承認権限者として設定される場合のユーザ間取引の一例を示す。図24に示す例ではユーザA,Cが仲間関係を有している。また、ユーザB,Cが仲間関係を有している。さらに、ユーザB,Kが仲間関係を有している。このような場合、ユーザA,KはユーザB,Cを介して関係づけられている。このため、承認権限者設定部100は、ユーザA,Kの間のユーザ間取引を承認する承認権限者としてユーザB,Cを設定する。
図25は、複数のユーザが承認権限者として設定される場合のユーザ間取引の他の一例を示す。図25に示す例ではユーザA,Cが同じユーザグループG1に所属している。また、ユーザB,Cが同じユーザグループG2に所属している。さらに、ユーザB,Kが同じユーザグループG3に所属している。このような場合、承認権限者設定部100は、ユーザA,Kの間のユーザ間取引を承認する承認権限者としてユーザB,Cを設定する。
図24及び図25に示す例の場合、ユーザB,Cの両方が承認した場合にユーザA,Kの間のユーザ間取引が許可される。なお、ユーザB,Cの少なくとも一方が承認した場合にユーザA,Kの間のユーザ間取引が許可されるようにしてもよい。
また、図24及び図25に示す例の場合、ユーザB,Cの一方のみが承認権限者として設定されるようにしてもよい。
なお、図24及び図25では二名のユーザが承認権限者として設定される場合について説明したが、三名以上のユーザが承認権限者として設定されるようにしてもよい。
以上のように、第1ユーザと第2ユーザとが複数の他のユーザを介して関係づけられている場合に、承認権限者設定部100は、該複数の他のユーザの全部又は一部を、第1ユーザと第2ユーザとの間のユーザ間取引を承認する承認権限者として設定するようにしてもよい。
言い換えれば、承認権限者設定部100は、第1ユーザと所定関係を有し、かつ、第2ユーザと所定関係を有する複数の他のユーザを、第1ユーザと第2ユーザとの間のユーザ間取引を承認する承認権限者として設定するようにしてもよい。
この場合、例えば下記に示すようなユーザが「第1ユーザと所定関係を有するユーザ」の一例に相当する。「第2ユーザと所定関係を有するユーザ」も同様である。
(1)第1ユーザと直接的な関係(例えば仲間関係)を有しているユーザ。すなわち、第1ユーザと直接的に関係づけられているユーザ。
(2)第1ユーザと同じユーザグループに所属しているユーザ。
(3)第1ユーザと間接的に関係付けられているユーザ。すなわち、第1ユーザと一又は複数の他のユーザを介して間接的に関係付けられているユーザ。
さらに、この場合、例えば下記に示すようなユーザが「第1ユーザと間接的に関係付けられているユーザ」の一例に相当する。
(3−1)第1ユーザと直接的な仲間関係を有しているユーザと直接的な仲間関係を有しているユーザ(すなわち、第1ユーザと他の一名のユーザを介して間接的に関係付けられているユーザ)。
(3−2)第1ユーザと直接的な仲間関係を有しているユーザと直接的な仲間関係を有しているユーザと直接的な仲間関係を有しているユーザ(すなわち、第1ユーザと他の二名のユーザを介して間接的に関係付けられているユーザ)。
(3−3)第1ユーザと他の三名以上のユーザを介して間接的に関係付けられているユーザ。
(3−4)第1ユーザが所属する第1ユーザグループに所属するユーザが所属する第2ユーザグループに所属するユーザ。
(3−5)第1ユーザと直接的な仲間関係を有しているユーザと同じユーザグループに属するユーザ。
例えば、図24に示すユーザCはユーザAと上記所定関係(1)を有するユーザに相当し、図24に示すユーザBはユーザAと上記所定関係(3−1)を有するユーザに相当している。
また例えば、図25に示すユーザCはユーザAと上記所定関係(2)を有するユーザに相当し、図25に示すユーザHはユーザAと上記所定関係(3−4)を有するユーザに相当する。
次に、第1ユーザと第2ユーザとの間のユーザ間取引を承認する複数の承認権限者が設定された場合のユーザ間取引許可部104の動作について説明する。
例えば、第1ユーザと第2ユーザとの間のユーザ間取引を承認した承認権限者の数が基準人数に達した場合に、ユーザ間取引許可部104は第1ユーザと第2ユーザとの間のユーザ間取引を許可する。
例えば、承認権限者の人数と等しい人数が「基準人数」として設定される。すなわち、承認権限者全員が承認した場合に、ユーザ間取引許可部104は第1ユーザと第2ユーザとの間のユーザ間取引を許可する。
または、承認権限者の過半数以上の人数が「基準人数」として設定されるようにしてもよい。すなわち、過半数以上の承認権限者が承認した場合に、ユーザ間取引許可部104は第1ユーザと第2ユーザとの間のユーザ間取引を許可するようにしてもよい。
あるいは、「1」が「基準人数」として設定されるようにしてもよい。または、2以上の定数が「基準人数」として設定されるようにしてもよい。
以上のようにすれば、例えば、ユーザA,Bが複数の他のユーザを介して関係づけられるような場合であっても、それら複数の他のユーザの全員又は一部によって承認されることによって、ユーザA,Bの間の取引が成立するようになる。
[2]例えば、承認権限者の承認が行われるタイミングは上記に説明したタイミングに限られない。
例えば図2〜図9に説明した例では、ユーザBがユーザAからの取引申込を受諾した段階で、承認権限者であるユーザCが承認を行うようになっていた。しかしながら、例えば、ユーザAがユーザCを仲介者(承認権限者)として選択した段階で、ユーザCが、自らと仲間関係を有しているユーザとユーザAとが取引を行うことを承認するようにしてもよい。または、例えば、ユーザAがユーザBを取引相手として選択した段階で、ユーザCが、ユーザAとユーザBとが取引を行うことを承認するようにしてもよい。
[3]例えば、ユーザ間取引が実行されるタイミングは上記に説明したタイミングに限られない。
例えば図15に示す処理では、承認権限者による承認が行われた直後(すなわち、承認画面80の「はい」ボタン82が選択された直後)に、ゲームサーバ10の制御部11がユーザ間取引を実行するようになっていた(ステップS310参照)。しかしながら、ステップS310において、ゲームサーバ10の制御部11は、ユーザ間取引が承認権限者によって承認されたことを示す情報(言い換えれば、ユーザ間取引が許可されたことを示す情報)をデータベース15に記憶させることによって、ユーザ間取引を実行可能な状態とするようにしてもよい。そして、所定のタイミング(例えば毎日の定時)において、制御部11は、実行可能な状態になっているユーザ間取引をまとめて実行するようにしてもよい。
[4]例えば、仲介者候補リスト画面30ではユーザが仲介者候補を検索できるようにしてもよい。なお以下では、ユーザAが仲介者候補を検索する場合を想定する。
例えば、ユーザAが指定したゲームアイテム(例えば所望のゲームアイテム)を所有しているユーザを仲介することが可能なユーザを仲介者候補として仲介者候補リスト画面30に表示するようにしてもよい。例えば、ユーザAが指定したゲームアイテムを所有しているユーザと仲間関係を有しているユーザを仲介者候補として仲介者候補リスト画面30に表示するようにしてもよい。
また例えば、ユーザAが出品又は所有しているゲームアイテムを所望しているユーザを仲介することが可能なユーザを仲介者候補として仲介者候補リスト画面30に表示するようにしてもよい。例えば、ユーザAが所有しているゲームアイテムを所望アイテムリストに登録しているユーザと仲間関係を有しているユーザを仲介者候補として仲介者候補リスト画面30に表示するようにしてもよい。
[5]例えば、ゲームシステム1の管理者が承認権限者として設定されてもよい。この場合、承認権限者設定部100を省略するようにしてもよい。
[6]例えば、以上では、ユーザ間取引としてゲームアイテムの交換が行われる場合について説明したが、先述したように、ユーザ間取引の取引対象はゲームアイテムに限られない。例えば、取引対象は、ゲームにおいて利用される他のオブジェクト(例えばゲームカード又はゲームキャラクタ等)であってもよい。また例えば、取引対象は、ゲームにおいて利用されるポイント(例えばゲーム内通貨等)であってもよい。
[発明のまとめ]以上の記載から本発明は例えば以下のように把握される。
本発明に係るゲームシステムは、ゲーム内において利用される利用対象を取引するユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段(102)と、前記承認結果情報に基づいて、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段(104)と、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを許可すると決定された場合に、前記第1ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第1ユーザの前記利用対象の所有状況を示すデータから取り除き、前記第2ユーザの前記利用対象の所有状況を示すデータに追加し、かつ、前記第2ユーザが所有している前記利用対象のうちの、当該ユーザ間取引の対象である前記利用対象を前記第2ユーザの前記利用対象の所有状況を示す前記データから取り除き、前記第1ユーザの前記利用対象の所有状況を示す前記データに追加することによって、前記第1ユーザと前記第2ユーザとの間の前記ユーザ間取引を実行するユーザ間取引実行手段(108)と、を含む。
また、本発明に係る取引制御装置は、ゲーム内において利用される利用対象を取引するユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段(102)と、前記承認結果情報に基づいて、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段(104)と、を含む。
また、本発明に係るプログラムは、ゲーム内において利用される利用対象を取引するユーザ間取引を第1ユーザと第2ユーザとの間で行うことを承認する権限を有する承認権限者が、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを承認したか否かの承認結果に関する承認結果情報を取得する承認結果情報取得手段(102)、及び、前記承認結果情報に基づいて、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを許可するか否かを決定するユーザ間取引許可手段(104)、としてコンピュータを機能させるためのプログラムである。
また、本発明に係る情報記憶媒体は、上記プログラムを記録したコンピュータ読み取り可能な情報記憶媒体である。
本発明によれば、不正行為を行う者が参加したユーザ間取引が成立してしまうことを抑制しつつ、不正行為を行う者が参加するおそれがなさそうなユーザ間取引を制限しないように図ることが可能になる。
本発明の一態様では、ユーザ間の関係に関するデータに基づいて、前記第1ユーザ及び前記第2ユーザ以外のユーザのうちから前記承認権限者を設定する承認権限者設定手段(100)を含むようにしてもよい。このようにすれば、ユーザ間の関係に関するデータに基づいて設定される承認権限者の承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる。
また本発明の一態様では、前記承認権限者設定手段(100)は、前記第1ユーザと前記第2ユーザとが一の他のユーザ又は複数の他のユーザを介して関係付けられている場合に、前記一の他のユーザ、又は、前記複数の他のユーザの全員又は一部を前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第1ユーザと第2ユーザとが一の他のユーザ又は複数の他のユーザを介して関係付けられている場合に、該一の他のユーザ、又は、該複数の他のユーザの全員又は一部の承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる。
また本発明の一態様では、前記承認権限者設定手段(100)は、前記第1ユーザと所定関係を有し、かつ、前記第2ユーザと所定関係を有する他のユーザを前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第1ユーザと所定関係を有し、かつ、第2ユーザと所定関係を有する他のユーザの承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる。
また本発明の一態様では、前記承認権限者設定手段(100)は、前記第1ユーザと前記第2ユーザとが所属している前記ユーザグループに所属している他のユーザを前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第1ユーザと第2ユーザとが所属しているユーザグループに所属している他のユーザの承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる。
また本発明の一態様では、前記承認権限者設定手段(100)は、前記第1ユーザと前記第2ユーザとが所属している前記ユーザグループに所属し、かつ、該ユーザグループにおいて所定の役割を担っている他のユーザを前記承認権限者として設定する手段を含むようにしてもよい。このようにすれば、第1ユーザと第2ユーザとが所属しているユーザグループにおいて所定の役割を担っている他のユーザの承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる。
また本発明の一態様では、前記第1ユーザと前記第2ユーザとが特定関係を有する場合に、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを許可する特定ユーザ間取引許可手段(106)を含み、前記第1ユーザと前記第2ユーザとが前記特定関係を有しない場合、前記第1ユーザと前記第2ユーザとの間で前記ユーザ間取引を行うことを許可するか否かが前記ユーザ間取引許可手段(104)によって決定されるようにしてもよい。このようにすれば、例えば、第1ユーザと第2ユーザとが特定関係を有しない場合であっても、承認権限者の承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる。
また本発明の一態様では、前記第1ユーザと前記特定関係を有し、かつ、前記第2ユーザと前記特定関係を有する他のユーザを前記承認権限者として設定する手段(100)を含むようにしてもよい。このようにすれば、第1ユーザと第2ユーザとが特定関係を有しない場合であっても、第1ユーザと特定関係を有し、かつ、第2ユーザと特定関係を有する他のユーザの承認によって、ゲーム内におけるユーザ間取引を第1ユーザと第2ユーザとの間で行うことが許可されるようになる
また本発明の一態様では、前記承認権限者によって承認を受ける側の複数のユーザの各々が所望するユーザ間取引の内容に関する情報を、前記承認権限者の端末の出力手段に出力するための制御を行う第1出力制御手段(110)と、前記複数のユーザのうちから前記承認権限者によって選択されたユーザの間で前記ユーザ間取引を行うように提案することを示す提案情報を、前記承認権限者によって選択された前記ユーザの端末の出力手段に出力するための制御を行う第2出力制御手段(112)と、を含むようにしてもよい。このようにすれば、承認権限者が取引を提案できるようになる。