JP2014161689A - ゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラム - Google Patents

Abstract

【課題】仲間同士で交流を持ちながら、手間をかけることなく不要なアイテム等をポイント等に交換できる環境をユーザに提供する。
【解決手段】ゲーム管理装置は、ユーザに関係付けられた仲間を管理する仲間管理手段５１と、ユーザからの要求に応じて、仲間に提示するオブジェクトの売却条件を予め設定する設定手段５２と、前記売却条件が適用されるオブジェクトをユーザが入手した場合、前記仲間に当該オブジェクトの売却条件を提示する提示手段５３と、を備えている。
【選択図】図２０

Description

本発明は、ゲームを管理するゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムに関するものである。

従来から、インターネット上に設置されたゲームサーバに、ユーザの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、ユーザがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある（特許文献１等）。また、近年は携帯電話等の端末装置で簡単な操作を行うだけでブラウザゲーム等を楽しむことができるゲームシステムも普及している（特許文献２等）。

そして近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）のシステムに、前記ゲームシステムが組み込まれ、ＳＮＳのサービスの一つとして提供される、いわゆるソーシャルゲームが普及している。このようなソーシャルゲームにおいては、各ユーザがゲームサービスを利用している他のユーザと仲間になり、仲間同士でプレゼントのやり取りをする等、ユーザ同士が交流を行うことができるようになっている。

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

従来のゲームシステムにおいて、ユーザが自分にとっては不要なアイテムを所有している場合、そのアイテムを仲間にプレゼントしたり、売却してポイントに交換したりできる。ただし、ユーザが仲間にプレゼントをしても、その仲間からお返しのプレゼントがあるとは限らないため、プレゼントを積極的に行わないユーザも少なくない。また、仲間にプレゼントをするためには、プレゼント対象のアイテムやプレゼント先の相手を指定する等の面倒な操作が必要である。よって、ユーザ間の交流には繋がらない売却により、不要なアイテムを処分してしまうユーザも多いのが現状である。

本発明は、上記の事情に鑑みてなされたものであり、その目的は、所定の関連付けがなされているユーザ間で交流を持ちながら、手間をかけることなく不要なアイテム等をポイント等に交換できる環境をユーザに提供することである。

１）本発明の一局面によるゲーム管理装置（1,2,101,301）は、ゲームを管理するものであって、ユーザに関係付けられた他のユーザを管理する管理手段（51）と、ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定手段（52）と、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示手段（53）と、を備えている。

この構成のゲーム管理装置は、例えば各ユーザのゲーム端末（端末装置）と通信を行うことができるサーバなどの情報処理装置（コンピュータ）により構成することができる。あるいは、本ゲーム管理装置は、ゲーム端末としての情報処理装置により構成することもできる。あるいは、本ゲーム管理装置は、相互に通信する複数の情報処理装置（サーバ、ゲーム端末）により構成することもできる。

本ゲーム管理装置は、ユーザと所定の関連付けがなされている仲間やグループ員などの他のユーザを管理する管理手段を備えている。ここで、仲間とは、ゲーム内で構築されるユーザ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。なお、ユーザと関連付けがなされている他のユーザであれば、仲間という関係でなくてもよい。但し、以降の説明では、便宜上、「ユーザに関係付けられた他のユーザ」を、それを代表して「仲間」と記載する。

本構成では、ユーザが事前に仲間に提示するオブジェクトの交換条件を設定しておけば、当該交換条件が適用されるオブジェクトをユーザがゲーム内で入手した場合、当該交換条件が自動的に仲間に提示される。ここで、オブジェクトとは、ゲーム内のキャラクタやアイテム等である。例えば、野球のデジタルカードゲームでは、選手カード、回復アイテム、強化アイテム（特殊なバット、グローブ、スパイク等）などがオブジェクトに含まれる。また、オブジェクトの交換には、オブジェクトをゲーム内通貨やポイントと交換する、いわゆる「売却」が含まれる。また、オブジェクトを他のオブジェクトと交換する「物々交換」も含まれる。また、オブジェクトの交換を「トレード」等と称してもよい。

ここで、選手カードを用いた野球のデジタルカードゲームにおけるオブジェクトの交換条件の設定について例示する。なお、各選手カードには５段階のレア度（最低１〜最高５）の何れかが設定されているものとする。また、各選手カードには所属チーム（例えば、日本のプロ野球１２チームの何れか）が設定されているものとする。また、各ユーザも自分のチーム（前記１２チームの何れか）を持っているものとする。このようなゲームにおいて、例えば、（ａ）「自分のチーム以外のレア度４のカード」を「５００ポイント」と交換、（ｂ）「自分が既に所有しているレア度４以上のカード」を「回復アイテム１０個」と交換、（ｃ）「自分のチームのオーダーが全てレア度４以上である場合に、その後入手されるすべてのレア度４のカード」を「５００ポイント」と交換、等の条件を単独で、あるいは組み合わせて設定する。なお、このようなオブジェクトの交換条件は、ユーザの任意で、いつでも設定することも解除することもできる。

ユーザＡによって前記（ａ）の条件が設定されている場合を例に挙げると、ユーザＡが「自分のチーム以外のレア度４のカード」をゲーム内で入手した場合、提示手段が、ユーザＡの仲間のゲーム画面に、例えば、「このカードを５００ポイントで購入しませんか？」という交換条件を提示（表示）する。ここで、仲間がその提示内容を了承すれば交換（売買）が成立し、ユーザＡは自動的にオブジェクトの対価（ポイント）を入手できる。一方、ユーザＡからオブジェクトの交換条件の提示を受けた仲間がそれを拒否するか、所定時間（例えば３時間）以内に交換条件を了承するか否かの回答をしなければ、そのオブジェクトはユーザＡの所有となる。なお、交換条件を提示する仲間が複数いる場合は、後述するように、１人ずつ順番に提示してもよいし、同時に複数人に一括して提示してもよい。

本構成では、例えば、比較的希少価値が高いとされているオブジェクトであっても、ユーザが自分には不要と考える場合には、そのオブジェクトを仲間への売却対象（交換対象）として予め設定することができる。これにより、ユーザにとっては不要なオブジェクトを単に売却したりプレゼントしたりするのではなく、ユーザが仲間に有償でそのオブジェクトを譲るための処理（交換条件の提示処理）が、ユーザの手間を掛けることなく自動的に実行されることになる。交換条件を提示された仲間にとっては、そのオブジェクトを入手できる機会を与えられるので、オブジェクト入手のバリエーションが広がる。また、お互いに仲間同士での交換取引が行われるので、これを通して、仲間同士の交流を深めることもできる。このように、本構成により、所定の関連付けがなされているユーザ間で交流を持ちながら、手間をかけることなく不要なオブジェクト等をその他のものに交換できる環境をユーザに提供することができる。

２）上記の構成において、前記設定手段（52）は、ユーザからの要求に応じて、前記他のユーザの範囲および当該範囲内の他のユーザに提示するオブジェクトの交換条件を予め設定し、前記提示手段（53）は、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記範囲内の他のユーザに、当該オブジェクトの交換条件を提示することが好ましい。

本構成では、自動的な交換条件提示の対象となる仲間の範囲を定めることができる。すなわち、仲間の範囲と、その範囲の仲間に提示するオブジェクトの交換条件と、をユーザが事前に設定しておけば、交換条件が適用されるオブジェクトの入手時に、その交換条件が自動的に前記範囲内の仲間に提示される。

ここで、「仲間の範囲」は、例えば、「ユーザとの親密度」、「仲間のゲーム内レベル」、「仲間のゲームへのアクセス頻度」等の「仲間に関するゲーム情報」に基づいて定めることができる。あるいは、「仲間の範囲」は、「個人を特定する情報（仲間のユーザＩＤやユーザ名等）」に基づいて定めることもできる。例えば、親密度が所定以上（例えば親友レベル以上）の仲間と、それよりも低い（例えば、知り合いレベル）の仲間とで、仲間に提示するオブジェクトの交換条件を異ならせることができる。一例を挙げると、親密度が高い仲間には、親密度の低い仲間よりも、より良いオブジェクト（レア度の高いオブジェクト等）を安価に譲るように、予め条件設定することができる。本構成により、仲間の親密度等によって定められた仲間の範囲に応じた適切なオブジェクトの交換条件を、自動的に提示することが可能となる。

また、他のユーザの範囲としては、以下の構成とすることもできる。すなわち、他のユーザを、ユーザが過去にプレゼントをもらった他のユーザの中から選択する構成としてもよい。つまり、ゲーム管理装置の設定手段は、ユーザからの要求に応じて他のユーザの範囲を設定する場合に、その範囲に含めることができる他のユーザを、ユーザが過去にプレゼントをもらった他のユーザに限定するのである。

３）上記の１）または２）の構成において、前記交換条件には、交換対象のオブジェクトおよび当該オブジェクトとの交換に必要な対価の情報が含まれることが好ましい。

ここで、「交換対象のオブジェクト」の情報とは、例えば「自分のチーム以外のレア度４のカード」、「自分が既に所有しているレア度４以上のカード」等の、ユーザが任意に定めたオブジェクトの条件である。また、「当該オブジェクトとの交換に必要な対価」の情報とは、例えば「５００ポイント」、「回復アイテム１０個」等の、ユーザが任意に定めた対価の条件である。

なお、ユーザが「交換対象のオブジェクト」の条件を指定すれば、設定手段が、自動的にデフォルトの対価を初期設定するようにしてもよい。この場合、ユーザは、基本的に、交換条件として、交換対象のオブジェクトの条件のみを指定（入力）すればよい。また、この場合、デフォルトの対価をユーザが任意に変更できるようにすることが好ましい。このように、ユーザが「交換対象のオブジェクト」の条件のみを指定すれば、その対価がデフォルトで自動設定され、ユーザがデフォルトの対価を変更したいときだけ変更操作をすればよい構成とすることにより、ユーザが交換条件を容易に設定できるようになる。

４）上記の３）の構成において、前記交換条件が提示されてからの経過時間に応じて、前記対価を変更する対価変更手段（55）をさらに備えていることが好ましい。

例えば、仲間に交換条件が提示されてから所定時間が経過する毎に、対価となるポイントを大きくする。具体例としては、交換条件が提示されてからの経過時間が１時間以内の対価を「５００ポイント」、１時間経過後から２時間以内の対価を「１０００ポイント」、２時間経過後から３時間以内の対価を「１５００ポイント」とする。この場合、交換条件の提示を受けた仲間としては、早めに了承した方が安価にオブジェクトを入手できる。逆に、仲間に交換条件が提示されてから所定時間が経過する毎に、対価となるポイントを小さくしてもよい。本構成により、交換条件の提示を受けた仲間にとっては、了承のタイミングが重要となり、これにより興趣性を高めることができる。

５）上記の１）または２）の構成において、前記提示手段（53）は、前記交換条件が適用されるオブジェクトをユーザが入手した場合であって、前記交換条件の提示対象となり得る他のユーザが複数存在する場合、前記交換条件を提示した他のユーザとの交換取引が所定時間以内に成立しなければ、別の他のユーザに前記交換条件を提示することを繰り返すことによって、前記複数の他のユーザに対して、順次、前記交換条件の提示を行うことが好ましい。

この構成によれば、交換条件の提示対象となり得る他のユーザ、例えば、ユーザの仲間が複数存在する場合、複数の仲間のそれぞれに対して、条件提示を順次行う。すなわち、最初に交換条件の提示をした仲間から拒否されるか、所定時間（例えば３時間）以内の回答が無ければ、自動的に、次の仲間に交換条件の提示を行う。その後も、交換取引が所定時間以内に成立しなければ、交換条件の提示対象となる仲間を自動的に変えていく。勿論、ある仲間との交換取引が成立すれば、条件提示をしていない仲間が残っていても、交換条件の提示は打ち切られる。なお、ここで、後述するように、条件提示の繰返しの回数に上限を設けてもよい。例えば、仲間への条件提示は３回までとし、それでも交換取引が成立しない場合には、それ以上、条件提示を行わず、オブジェクトをユーザの所有物としてもよい。これはユーザが入手したオブジェクトが長時間、実質的に誰にも所有されないまま（または、ユーザが所有していても使用できない状態）になってしまい、ゲームに有効活用されない状況になることを回避するためである。

本構成のように、交換条件の提示を行う仲間を一人ずつ変えて、複数の仲間に交換条件の提示を行う方法の他に、後述するように、複数の他のユーザに対して、同時に、交換条件の提示を行う方法もある。複数の他のユーザに対して、同時に、交換条件の提示を行った場合、交換取引の成立は早い者勝ちとなる。これに対して、本構成の場合、交換条件の提示を受けた仲間は、所定時間以内であれば自分だけが交換取引を行うことができるので、他のユーザが先に交換を成立させてしまうことはなく、安心して交換取引を行うことができる。

６）上記５）の構成において、関係付けられた２人のユーザに対して親密度を付与する親密度付与手段（56）をさらに備え、前記提示手段（53）は、親密度の高い前記他のユーザから順に、前記交換条件の提示を行うことが好ましい。

ここで、親密度とは、仲間関係が成立している２人のユーザの親密さを示すものであり、２人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。例えば、２人の親密度は、ゲーム内の交流の回数や頻度に基づいて設定できる。本構成では、親密度の高い仲間から順に、交換条件の提示が行われるので、親密度の高い仲間ほど、交換取引を行う機会が増え、交流を深めることもできる。また、交換条件の提示を受けるユーザにとっては、相手との親密度が高いほど交換条件の提示を受け易くなり、オブジェクトを入手できる機会が増える。

７）上記の５）または６）の構成において、他のユーザとの交換取引が成立せず、交換取引の対象が次の他のユーザに移る毎に、交換条件である、オブジェクトとの交換に必要な対価を順次低下させる対価変更手段（55）をさらに備えていることが好ましい。

例えば、最初に交換条件の提示をする仲間に対しては、オブジェクトとの交換に必要な対価を５００ポイント（または１時間以内：５００ポイント、１〜２時間：１０００ポイント、２〜３時間：１５００ポイント）とする。この交換取引が成立せず、交換取引の対象が２人目の仲間に移った場合、オブジェクトとの交換に必要な対価を３００ポイント（または１時間以内：３００ポイント、１〜２時間：６００ポイント、２〜３時間：９００ポイント）とする。さらに、その交換取引が成立せず、交換取引の対象が３人目の仲間に移った場合、オブジェクトとの交換に必要な対価を２００ポイント（または１時間以内：２００ポイント、１〜２時間：４００ポイント、２〜３時間：６００ポイント）とする。

このように、交換取引が成立しなければ、交換取引の対象が別の仲間に移る毎に対価を順次低下させることにより、交換取引を成立させ易くすることができる。特に、ユーザにとって、オブジェクトがどの仲間とも交換できずに売れ残るよりは、対価が下がっても交換できる方がよいと考える場合に有効である。

８）上記の５）ないし７）の何れかの構成において、前記提示手段（53）は、前記交換条件を提示する他のユーザの人数を、所定人数に制限することが好ましい。

仲間に交換取引の提示をしている間は、ユーザが入手したオブジェクトがユーザ自身のものになるのか（取引不成立）、仲間のものになるのか（取引成立）が不確定な状態となる。そのような不確定な期間が長時間継続することは、ユーザが入手したオブジェクトの使用が長時間制限されることになるため、ゲームに有効活用されないオブジェクトが存在することになり好ましくない。そこで、交換取引が所定時間以内に成立しなければ、交換条件の提示対象となる仲間を一人ずつ変えていく構成の場合、交換条件を提示する仲間を所定人数に制限する。例えば、所定人数を３人とした場合、交換取引の制限時間を１人当たり３時間以内とすれば、前記不確定な期間は９時間（＝３人×３時間）以内に抑えることができる。本構成により、前記不確定な期間が長くなり過ぎることを効果的に防止することができる。

９）上記の１）ないし３）の何れかの構成において、前記提示手段（53）は、前記交換条件が適用されるオブジェクトをユーザが入手した場合であって、前記交換条件の提示対象となり得る他のユーザが複数存在する場合、当該複数の他のユーザに対して、同時に、前記交換条件の提示を行うことが好ましい。

この構成によれば、交換条件の提示対象の複数の仲間に対して、同時に、交換条件の提示を行うので、交換取引が所定時間以内に成立しなければ、交換条件の提示対象となる仲間を一人ずつ変えていく構成と比較して、取引の成否が分からない不確定な期間を短くすることができる。また、複数の仲間を対象に一斉に交換条件を提示し、交換取引の成立を早い者勝ちとするので、交換取引の成立の可能性を高めることができる。

１０）上記の９）の構成において、前記交換条件の提示が開始されてからの経過時間に応じて、交換条件である、オブジェクトとの交換に必要な対価を低下させる対価変更手段（55）をさらに備えていることが好ましい。

例えば、複数の仲間に同時にオブジェクトの交換条件が提示されてから所定時間が経過する毎に、対価となるポイントを小さくする。具体例としては、交換条件が提示されてからの経過時間が１時間以内の対価を「１５００ポイント」、１時間経過後から２時間以内の対価を「１０００ポイント」、２時間経過後から３時間以内の対価を「５００ポイント」とする。

複数の仲間に同時にオブジェクトの交換条件を提示する場合、オブジェクトを入手できる仲間は、最も早く交換条件を了承した一人だけである。よって、交換条件の提示を受けた各仲間は、提示されたオブジェクトが欲しければ、早めに交換条件を了承しなければ、他の仲間に先を越されてしまう。よって、各仲間は、対価が高くても早めに了承するか、時間をおいて安価になってから了承するかを検討することになり、この点で興趣性が増加する。

１１）上記の２）の構成において、ユーザが指定した個人を特定する情報に基づいて、他のユーザの範囲として特定の他のユーザが設定された場合、当該特定の他のユーザのゲーム情報に基づいて、又は当該特定の他のユーザおよび前記ユーザのゲーム情報に基づいて、当該特定の他のユーザに提示する前記交換条件を自動的に設定する自動設定手段（57）をさらに備えていることが好ましい。

この構成によれば、ユーザが仲間の範囲として特定の仲間を指定するだけで、当該仲間のゲーム情報（例えば、仲間のチーム、ゲーム内レベル、親密度、ゲームへのアクセス頻度等）に基づいて、当該仲間に提示するオブジェクトの条件までもが自動的に設定される。例えば、ユーザが指定した仲間のチームの選手カードでレア度３または４のカードが、交換対象のオブジェクトの条件として自動的に設定される。この場合において、交換対象のオブジェクトのレア度は、提示対象の仲間のレベル等に応じて自動的に決定される。例えば、その仲間のゲーム内レベル、親密度またはゲームへのアクセス頻度が閾値以上の場合には前記オブジェクトの条件をレア度４とし、閾値未満の場合はレア度３とする。他の例としては、ユーザが指定した仲間がゲーム内で設定しているチーム構成（カードのデッキ）において弱いポジションがある（所定のレア度以上または所定の能力値以上の選手がいないポジションがある）場合には、そのポジションの選手カードで所定のレア度（例えばレア度４）という交換対象のオブジェクトの条件が自動的に設定される。

ところで、例えば、ユーザと他のユーザとが同じチームの場合、ユーザが所有していないカードについては、ユーザ自身が欲しい場合が想定される。よって、ユーザと他のユーザとが同じチームの場合には、仲間に提示するオブジェクトの条件を、ユーザが既に所有しているカードに限定してもよい。ユーザが複数枚を所有していれば、気軽に交換対象として提示することができるためである。また、前述のように、交換対象のオブジェクトの条件（レア度等）は、提示対象の仲間のレベルに応じて決定（初心者レベルであればレア度３、上位レベルであればレア度４等）することができるが、ユーザ自身のレベルも考慮して決定することが好ましい。なぜならば、ユーザが下位レベルであれば、レア度の高いオブジェクトを入手した場合、仲間に売却等したくないと考えることが想定されるからである。逆に、ユーザのレベルが非常に高ければ、相手が初心者であってもレア度の高いオブジェクトを売却してもよいと考えることが想定されるからである。そこで、ユーザが仲間の範囲として特定の仲間を指定すれば、自動設定手段が、当該仲間のゲーム情報および当該ユーザのゲーム情報の両方に基づいて、当該仲間に提示するオブジェクトの条件を自動的に設定するようにしてもよい。

上記の自動設定手段を備えた構成により、ユーザが特定の仲間を指定するだけで、その仲間のゲーム情報（およびユーザ自身のゲーム情報）を分析し、適切なオブジェクトの提示条件までもが自動的に設定されるので、ユーザの操作負担を軽減することができる。

１２）本発明の他の一局面によるゲーム管理装置（1,2,101,301）は、ゲームを管理するものであって、ユーザに関係付けられた他のユーザを管理する管理手段（51）と、ユーザからの要求に応じて、取引対象の前記他のユーザの範囲および当該範囲内の他のユーザに提示するオブジェクトの売却条件を予め設定する設定手段（52）と、前記売却条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの売却条件を自動的に提示する提示手段（53）と、を備え、前記売却条件には、売却対象のオブジェクトおよび当該オブジェクトの購入に必要な対価の情報が含まれる。

１３）本発明の他の一局面によるゲームシステムは、サーバ（1,2,101）と、当該サーバ（1,2,101）との間で通信を行う端末装置（3,301）と、を含むゲームシステムであって、ユーザに関係付けられた他のユーザを管理する管理手段（51）、ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定手段（52）、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示手段（53）、を前記サーバ（1,2,101）又は前記端末装置（3,301）の何れか一方が備える。

１４）本発明の他の一局面によるゲーム管理方法は、ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、コンピュータが、ユーザに関係付けられた他のユーザを管理する管理ステップと、コンピュータが、ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定ステップと、コンピュータが、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示ステップと、を含む。

１５）本発明の他の一局面によるプログラムは、コンピュータを、ゲームを管理するゲーム管理装置（1,2,101,301）として動作させるためのプログラムであって、前記コンピュータを、ユーザに関係付けられた他のユーザを管理する管理手段（51）、ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定手段（52）、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示手段（53）、として機能させるためのプログラムである。

本発明によれば、所定の関連付けがなされているユーザ間で交流を持ちながら、手間をかけることなく不要なアイテム等をポイント等に交換できる環境をユーザに提供することができる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。 ゲーム管理装置のハード構成の一例を示すブロック図である。 端末装置のハード構成の一例を示すブロック図である。 ゲームのメイン画面の一例を示す説明図である。 ユーザの所有するカードを表示する画面の一例を示す説明図である。 手動で仲間にカードを売却するための画面の一例を示す説明図である。 自動売却条件設定画面の一例を示す説明図である。 前記図７の画面中のプルダウンメニューの表示例を示す説明図である。 カードの売却条件の提示画面の一例を示す説明図である。 自動売却条件設定画面の他の例を示す説明図である。 自動売却条件設定画面の他の例を示す説明図である。 自動売却条件設定画面の他の例を示す説明図である。 自動売却条件設定画面の他の例を示す説明図である。 自動売却条件設定画面の他の例を示す説明図である。 前記図１４の画面における設定例を示す説明図である。 仲間リスト画面の一例を示す説明図である。 ゲーム管理装置の基本的な機能的構成の一例を示す機能ブロック図である。 ユーザのゲーム情報の一例を示す説明図である。 選手データベースの一例を示す説明図である。 ゲーム管理装置の主要な機能的構成の一例を示す機能ブロック図である。 自動売却条件の設定例を示す説明図である。 親密度に基づいて仲間の範囲を設定した自動売却条件の一例を示す説明図である。 ゲームレベルに基づいて仲間の範囲を設定した自動売却条件の一例を示す説明図である。 ゲームへのアクセス頻度に基づいて仲間の範囲を設定した自動売却条件の一例を示す説明図である。 親密度、ゲームレベルおよびゲームへのアクセス頻度を組み合わせて仲間の範囲を設定した自動売却条件の一例を示す説明図である。 個人を特定する情報に基づいて仲間の範囲を設定した自動売却条件の一例を示す説明図である。 仲間への売却条件提示中の管理情報の一例を示す説明図である。 売却条件の提示処理の一例を示すフローチャートである。 売却条件の提示処理の一例を示すフローチャートである。 売却条件の提示処理実行時の報知画面の一例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 売却条件の提示処理の他の例を示すフローチャートである。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 売却条件の提示処理の他の例を示すフローチャートである。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 自動売却条件を自動設定するための画面の一例を示す説明図である。 自動売却条件が自動設定されたときに表示される画面例を示す説明図である。 ゲーム管理装置の主要な構成の他の例を示す機能ブロック図である。 売却相手の候補者を報知する画面の一例を示す説明図である。 ゲームシステムの他の構成例を示すブロック図である。 ゲームシステムの他の構成例を示すブロック図である。

以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。

〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各ユーザの端末装置３とによって構成される。

本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成することができる。ゲームサーバ１は、ゲームサービスを受ける各ユーザの端末装置３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ２（記憶装置）に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。

ゲームサーバ１によるゲームサービスの提供の形態としては、ゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ１に実装されており、端末装置３でゲームを実行するのではなく、端末装置３でのゲーム操作入力に応じてゲームサーバ１でゲームを実行し、その実行結果を各ユーザの端末装置３に送信する形態がある。例えば、各ユーザの端末装置３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームをゲームサーバ１が提供する。あるいは、ゲームサーバ１でゲームを実行した結果のゲーム映像を、例えばストリーミング形式で端末装置３に送信する、いわゆるクラウドゲーミングのサービスをゲームサーバ１が提供する。

あるいは、後述するように、ゲーム実行プログラムの一部または全部をユーザの端末装置３側にインストールし、端末装置３においてもゲーム実行処理が行われるようなゲームシステムとすることもできる。

本実施の形態では、ゲームサーバ１によるゲームサービスの提供の一形態として、ブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、ユーザの端末装置３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置３をネットワーク４に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ１から提供されるゲームサービスを楽しむことができる。

このゲームシステムでは、ゲームサーバ１が、各ユーザの端末装置３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ１は、演算処理等の実行結果に基づいてデータベースサーバ２内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置３の画面に表示させるためのウェブページ情報（ゲーム画面データ）を各ユーザの端末装置３に送信する。

各ユーザの端末装置３には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ１から送信されたウェブページ情報を端末装置３の画面に表示することができるようになっている。この端末装置３としては、例えば、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータ（以下「ＰＣ」と呼称する）、タブレット型コンピュータ、通信機能を有するゲーム装置（据置型または携帯型のゲーム装置）または双方向の通信機能を備えた多機能型テレビジョン受像機（いわゆるスマートテレビ）など、ネットワーク４経由でゲームサーバ１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。

また、本実施の形態で提供されるゲームは、ユーザが、ゲームサービスを受けている他のユーザと交流を行いながらプレイすることができる、いわゆるソーシャルゲームの要素を有するものとすることができる。例えば、本実施の形態のゲームサーバ１およびデータベースサーバ２をソーシャルネットワーキングサービス（ＳＮＳ）のシステムに組み込むことによって、ＳＮＳのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにＳＮＳのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。

本実施の形態では、ユーザが事前に設定した売却候補のオブジェクト（キャラクタ、アイテム等）を入手した場合、そのオブジェクトが自動的に売却対象として仲間に提示される。すなわち、ユーザは、仲間に提示するオブジェクトおよびその売却条件（交換条件）を予め任意に設定することができる。そして、予め設定しておいた売却条件が適用されるオブジェクトをユーザがゲーム内で入手した場合、当該売却条件が自動的に仲間に提示される。ここで、仲間がその提示条件を了承すれば売買が成立し、ユーザＡは自動的にオブジェクトの対価（ポイント等）を入手できる。一方、売却条件の提示を受けた仲間がそれを拒否するか、所定時間以内にその条件を了承するか否かの回答をしなければ、そのオブジェクトはユーザの所有となる。

なお、「売却」とは、アイテム等のオブジェクトをゲーム内通貨やポイントと交換することであるが、オブジェクトを他のオブジェクトと交換する「物々交換」であってもよい。また、売却、物々交換を含むオブジェクトの交換を、「トレード」等と称してもよい。

さらに、本ゲーム管理装置では、売却条件の提示対象となる仲間の範囲を定めることができる。すなわち、仲間の範囲と、その範囲の仲間に提示するオブジェクトの売却条件をユーザが事前に設定しておけば、その条件が適用されるオブジェクトの入手時に、手間を掛けることなく確実に、その売却条件が自動的に前記範囲内の仲間に提示される。以下に、これを実現する本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。

〔ゲーム管理装置の構成〕
上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。図２にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ（Central Processing Unit）１１と、主記憶装置としてのＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１７を介して相互に接続されている。なお、バスライン１７と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲームサーバ１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

補助記憶装置１４は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１７を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。

通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各ユーザの端末装置３との間の通信を制御する。また、通信制御部１５は、ネットワーク４に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ１をＳＮＳに組み込んだシステム構成とした場合、ゲームサーバ１の通信制御部１５は、ＳＮＳサーバとの間の通信を制御する。

入出力制御部１６は、データベースサーバ２と通信可能に接続されており、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。

データベースサーバ２は、ゲームサーバ１が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各ユーザを一意に識別する識別情報（ユーザＩＤ）と対応付けて、各ユーザの各種ゲーム情報（ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。

本実施の形態では、ゲーム管理装置がゲームサーバ１およびデータベースサーバ２から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ１にデータベースサーバ２の機能を持たせて、ゲーム管理装置をゲームサーバ１のみで構成することもできる。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、ユーザが端末装置３を操作してゲームサーバ１へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。

また、本ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザの端末装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。

次に、本実施の形態に係るゲームサーバ１にアクセスしてゲームサービスの提供を受けるユーザの端末装置３の構成を説明する。

〔端末装置の構成〕
ユーザが操作する端末装置３としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯端末を例示してその構成を説明する。なお、携帯端末以外の端末装置３についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯端末と同様である。

ウェブサイト閲覧機能等を有する携帯端末は、フィーチャーフォン（Feature phone）やスマートフォン（Smartphone）等とも呼称され、図３にその構成例を示している。同図に示すように、端末装置３は、主に、ＣＰＵ３１と、主記憶装置としてのＲＯＭ３２及びＲＡＭ３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１とを備えており、構成要素３１〜３４、３６および３９〜４１はバスライン４２を介して相互に接続されている。なお、バスライン４２と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

ＣＰＵ３１は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置３全体の制御を行う。ＲＯＭ３２には、端末装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２または補助記憶装置３９からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ＨＴＭＬ等で記述されたゲーム画面データを表示するウェブブラウザは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。

画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイまたは有機ＬＥ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。

サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、端末装置３に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部３８は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。

補助記憶装置３９は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。

操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、端末装置３の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。

また、一般的な音声認識技術を利用して、音声入力部３７から入力された音声をＣＰＵ３１が解析し、各種入力を、音声により行うことができる構成としてもよい。

通信制御部４１は、通信インタフェース４１ａを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線ＬＡＮ接続機能、無線ＬＡＮや携帯電話回線網を介したインターネット接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信制御部４１は、ＣＰＵ３１からの命令に基づいて端末装置３を無線ＬＡＮやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ３１へ供給する。

なお、端末装置３には、その他にもＧＰＳ（Global Positioning System）信号受信回路、ＣＣＤ（Charge Coupled Device）イメージセンサ等の撮像装置（カメラ）、３軸加速度センサなどが備えられていてもよく、例えば、ＧＰＳ位置情報などをゲーム内で活用してもよい。

上記構成の端末装置３において、ゲームサービスを受けようとするユーザは、ウェブブラウザを立ち上げてゲームサーバ１が管理するゲームサイトにアクセスする入力操作を行う。このアクセスがゲームサーバ１に認証された場合、端末装置３の通信制御部４１がゲームサーバ１から送信されてくるＨＴＭＬ等で記述されたゲーム画面データを受信し、ＣＰＵ３１がウェブブラウザを実行してゲーム画面を表示部３５に表示させる。ここでユーザは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部４０を操作して選択入力する。この選択入力に応じてゲームサーバ１がゲームを進行させ、新たなゲーム画面データを端末装置３に送信する。そして、この新たなゲーム画面が端末装置３の表示部３５に表示され、以下、同様に、ユーザは、表示部３５に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ１が提供するゲームをプレイすることができるようになっている。

〔ゲームの説明〕
ゲーム管理装置によって提供されるゲームの例としては、サッカー、野球、テニス、アメリカンフットボール、バスケットボール、バレーボール、ゴルフ、ボクシング、競馬、カーレースなどを題材としたスポーツ・レースゲーム、シミュレーションゲーム、育成ゲーム、ロールプレイングゲーム、さらにはクイズゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、主に、ゲーム管理装置が野球ゲームを管理する例について、以下に説明する。

本実施の形態では、ユーザがゲーム内においてプロ野球（またはＭＬＢ）の実在選手に対応する選手キャラクタを所有し、当該選手キャラクタを用いて自分のチームをつくる野球ゲームを例に挙げる。

ユーザが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置３の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ１で管理されるとともに、ユーザの端末装置３の画面に表示される。また、選手キャラクタは、ゲーム内での試合等において、３次元コンピュータグラフィックスにより描写してもよい。また、ストリーミング形式等により、選手キャラクタやボールオブジェクト等を動画表示してもよい。ユーザは、ゲームを進行させながら選手カード（以下、単に「カード」と称す）を集め、自分だけのオリジナルチームを結成し、他のユーザと対戦することができる。ユーザはゲーム内の「オーダーモード」において、選手の打順およびポジションを設定できる。また、ユーザは、集めたカード同士を合体（合成）することによって、カードに表示されたキャラクタの能力を向上させる（すなわち、キャラクタを育成する）ことができ、より強いチーム作りを目指してゲームを楽しむ。

本実施の形態では、各カードには５段階のレア度（最低１〜最高５）の何れかが設定されている。また、各カードには選手の所属チーム（例えば、日本のプロ野球１２チームの何れか）が設定されている。また、後述するように、各ユーザは前記１２チームのうちの希望する何れか１つのチームを選択して、自分のチームとしている。

図４に、本ゲームのメイン画面（マイページ）の一例を示す。このメイン画面には、ユーザが所有するカードの中からリーダーとして選択された選手のカード２０１、ユーザのゲーム情報２０２（ユーザのレベル、各種ゲーム内ポイント、所有する選手キャラクタの数、仲間人数など）が表示される。カード２０１には、選手キャラクタの形態およびカードのレア度（希少価値の高さを星印の多さで示したもの）等が表記される。

本実施の形態のゲーム内ポイントとしては、行動ポイント、運営コスト、強化ポイント、抽選ポイントなどがある。行動ポイントは、ゲーム内エリア（ステージ）を探索して選手を仮想的にスカウトするという「スカウトモード」で使用されるゲーム進行用ポイントである。運営コストは、試合を運営する場合に必要なコストという位置付けで、他のユーザとゲーム内で試合を行う「試合モード」で使用されるポイントである。例えば、ゲーム中に消費されて減った行動ポイントや運営コストは、時間の経過により回復（例えば、３分経過毎に１ポイントずつ回復）するようにしたり、レベルアップ時または回復アイテムの使用により一気に回復するようにしたりできる。

強化ポイントは、ユーザが所有する複数のカードを合体（合成）することによってキャラクタを強化する「強化モード」で使用されるポイントである。この強化ポイントは、ユーザが保有するカードを売却する等によって獲得できる。抽選ポイントは、抽選でカードを獲得できる「抽選モード」で使用されるポイントである。この抽選ポイントは、ユーザが他のユーザとゲーム内で交流を行う等によって獲得できる。

また、メイン画面には、スカウト、試合、強化、抽選、オーダー、選手管理の各モードを選択するためのボタン群２０３も表示される。さらに、端末装置３の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、図示しない各種メニューボタン、システム運営者からのお知らせなど、様々な情報が表示されるようになっている。

本ゲームでは、ユーザが前述の「スカウトモード」または「抽選モード」を実行することによってカード（オブジェクト）を入手することができる。なお、ユーザがゲーム内で保持できるカードの枚数（選手数）には上限（例えば６０）を設けることができる。

また、本ゲームでは、ユーザが所持しているカードについて、売却してゲーム内ポイン（またはゲーム内通貨）と交換することもできる。本ゲームでは、ユーザが所持しているカードを仲間に売却することも、仲間を通さずにその場でカードを売却してゲーム内ポインに交換することも可能である。仲間に売却する場合、その仲間にカードの売却条件（カードとその対価）を提示し、それを相手が了承してはじめて売却（売買取引）が完了する。一方、仲間を通さない売却は、相手の了承を得る必要がないので、ユーザがカードの売却操作を行えば、直ぐに売却処理が実行され、そのカードを失う代わりにゲーム内ポインを獲得できる。

本実施の形態では、ユーザが手動で仲間にカードの売却条件を提示することも、予めカードの売却条件を設定することによって、自動で仲間に売却条件を提示することもできる。

ユーザが手動で仲間にカードの売却条件を提示する場合の操作の一例を、次に示す。ユーザが「抽選モード」等を実行することによってカードを入手した場合、図５に例示する画面に遷移し、入手したカード２０５およびカードの情報２０６が表示される。カードの情報２０６としては、選手名、所属チーム、ポジション、能力値などが含まれる。あるいは、図４のメイン画面において、選手管理ボタン２０３ａを押せば、図示しない選手管理画面に遷移し、ユーザが保持している選手のカード一覧が表示される。ここで、ユーザが特定のカードを指定（選択）すれば、図５の画面に遷移し、指定されたカード２０５およびカードの情報２０６が表示される。また、この画面には、「仲間に売却」ボタン２０７「即売却」ボタン２０８およびプレゼントボタン２０９等も表示される。「仲間に売却」ボタン２０７は、画面に表示されているカード２０５を仲間に売却するためのボタンである。「即売却」ボタン２０８は、仲間を通さないでその場ですぐに売却するためのボタンである。プレゼントボタン２０９は、画面に表示されているカード２０５を無償で他人へプレゼントするためのボタンである。

図５の画面でユーザが前記「仲間に売却」ボタン２０７を押せば、先ず、売却相手の仲間を選択するための仲間リスト画面（図１６参照）に遷移する。ここで、ユーザが、仲間リストの中から売却相手を指定すれば、図６の画面に遷移する。この画面には、売却対象のカードの表示領域２１０、売却相手の表示領域２１１、カード売却の対価の表示領域２１２、メッセージ設定領域２１３等が設けられる。

表示領域２１０には、売却対象のカード２０５、そのカードの情報２０６、そのカードのユーザの所持数の情報２１４等が表示される。また、表示領域２１１には、売却相手として選択した仲間の情報２１５（仲間のアバター、名前、レベル、チーム等）が表示される。表示領域２１２には、売却対象のカード２０５を売却した場合にユーザが入手する対価の情報２１６が表示される。ゲームサーバ１は、売却対象のカード２０５のレア度等に応じて、自動的にデフォルトの対価を初期設定する。このデフォルトの対価は、変更ボタン２１７を押せば、ユーザが任意に変更できる。例えば、ユーザは、カード本来の価値よりも安価なポイントを対価として設定し、仲間にカードを安価に譲ることもできる。逆に、カード本来の価値よりも高いポイントを対価として設定することも可能である。メッセージ設定領域２１３には、売却相手の仲間に送るメッセージの入力領域２１８が設けられる。

さらに、画面には条件提示ボタン２１９が表示され、ユーザがこのボタン２１９を押せば、表示されているカード２０５およびその対価の情報２１６を含む売却条件が、売却相手の仲間に提示される。また、メッセージの入力領域２１８に任意のメッセージを入力している場合、売却条件と併せてメッセージも相手に届けられる。この場合、ゲームサーバ１は、ユーザから売却条件の提示があった旨を仲間の端末装置３に報知する。

このように、ユーザが手動で、カードの売却条件を仲間に提示するには、面倒な作業が必要である。これに対して、以下に説明する仲間への売却条件自動提示は、カードの売却条件を予め設定しておくだけで、その売却条件が適用されるカードをユーザが入手した場合に、ゲームサーバ１が自動的に売却条件を仲間に提示するので、ユーザの操作負担を大幅に軽減できる。

図７には、自動で仲間に売却条件を提示するための設定画面（自動売却条件設定画面）の一例を示す。この画面には、売却するカードの条件を設定する領域２２１およびカード売却の対価を設定する領域２２２が設けられている。

例えば、領域２２１には、「自分のチーム以外のレア度４のカード」、「既に所有しているレア度４のカード」等の条件項目が予め表示されている。そして、ユーザがチェックボックス等により条件項目を選択するだけで簡単に条件を設定できるようになっている。

また、領域２２１には、チームおよびレア度の条件を設定するための入力部２４１、２２４（プルダウンメニュー）を設けてもよい。図８に入力部２４１、２２４のプルダウンメニューの表示例を示す。カードのチーム条件を設定する入力部２４１には、「自分のチーム以外」、「相手のチーム」、「全てのチーム」、「セ・リーグ」、「パ・リーグ」および特定のチーム（プロ野球の１２チームの何れか）を指定できる選択肢が表示される。また、カードのレア度条件を設定する入力部２４２には、レア度１〜５の選択肢が表示される。

また、図７の画面の領域２２２には、領域２２１で設定された条件のカードを売却した場合にユーザが入手する対価を設定するための対価設定部２２５が設けられている。ゲームサーバ１は、領域２２１で設定されたカード条件に応じて、自動的にデフォルトの対価を対価設定部２２５に初期設定する。この対価のデフォルト値は、予め定められた、売却対象のカードの価値と等価の値（例えば、レア度４のカードは５００強化ポイント等）である。このデフォルトの対価は、変更ボタン２２６を押せば、ユーザが任意に変更できる。よって、ユーザは、売却対象のカードの本来の価値よりも安く対価を設定したり、逆に高く対価を設定したりできる。

また、自動売却条件設定画面には設定ボタン２２７が設けられ、このボタンを押すことにより、ユーザの端末装置３から設定情報がゲームサーバ１に送信される。ゲームサーバ１では、前記設定情報を受信し、ユーザＩＤと対応付けて、カード売却条件をデータベースサーバ２に記憶する。

上記では、売却対象のカード条件として、チームの条件およびレア度の条件を適用できる例を示したが、これに限定されるものではない。例えば、ポジション（投手、野手、一塁手、二塁手、…）の条件を、単独で、またはチーム、レア度等の条件と組み合わせて、適用できるようにしてもよい。例えば、ユーザのチーム内の投手のポジションについてはレア度の高いカードが揃っており、ユーザにとっては投手のカードの重要性が低い場合、カード条件として投手のポジションでレア度４を設定することができる。この場合、ユーザがレア度４の投手のカードを入手した場合に、売却条件が自動的に仲間に提示される。

また、例えば、「自分のチームのオーダーが全てレア度４以上である場合に、その後入手されるすべてのレア度４のカード」というような、より複雑な条件を、売却対象のカード条件として設定することもできる。

また、「ユーザが入手したカードが、相手が保有していないカードの場合のみ、仲間に売却条件を提示する」という条件を、単独で、または他の条件と組み合わせて、適用できるようにしてもよい。これは、相手が既に保有しているカードと同じカードについては、相手が購入する可能性が低いことを考慮したものである。また、「ユーザが入手したカードが、相手が保有しているカードと同じカードの場合のみ、仲間に売却条件を提示する」という条件を、単独で、または他の条件と組み合わせて、適用できるようにしてもよい。これは、相手が手放すことなく保有しているカードは、相手の好みのカードであり、相手が購入する可能性が高いことを考慮したものである。この条件設定により、相手がどのようなカードを所有しているかによって、売却条件の提示処理の実行の有無を切り替えることが可能となる。

また、「ユーザが入手したカードが、自分が保有しているカードと同じカードの場合のみ、仲間に売却条件を提示する」という条件を、単独で、または他の条件と組み合わせて、適用できるようにしてもよい。これは、自分が既に保有しているカードを重複して入手した場合、そのカードは自分では不要（またはそれほど重要でない）と考えて、ユーザが当該条件を任意に設定できるようにするものである。また、「ユーザが入手したカードが、自分が保有していないカードの場合のみ、仲間に売却条件を提示する」という条件を適用できるようにしてもよい。」これは、同じカードを集めているユーザが当該条件を任意に設定できるようにするものである。この条件設定により、ユーザ自身がどのようなカードを所有しているかによって、売却条件の提示処理の実行の有無を切り替えることが可能となる。

上記のようにしてユーザが予め仲間への売却条件（売却対象のカードおよびその対価）を設定しておけば、その条件が適用されるカードをユーザが入手した場合、ゲームサーバ１は、当該カードの売却条件を自動的に仲間に提示する。該当する仲間が複数いる場合は、その中からランダムに選択した仲間に売却条件を提示してもよいし、親密度の高い仲間から、順次、売却条件を提示してもよい。

あるいは、売却条件が適用されるカードをユーザが入手したとき、ゲームにアクセス（ログイン）している仲間が存在すれば、その仲間に対して優先的に売却条件を提示してもよい。もし、売却条件が適用されるカードをユーザが入手したとき、ゲームにアクセスしている仲間がいなければ、その後、最初にゲームにアクセスした仲間に対して優先的に売却条件を提示してもよい。

図９に、ゲームサーバ１から仲間の端末装置３に送信された、カードの売却条件の提示画面の一例を示す。この画面は、ユーザＡが、予め設定していた売却条件を満たすカードを入手したことにより、当該売却条件が仲間Ｂに自動的に提示されたときの画面例である。例えば、図４に示すように、仲間Ｂのメイン画面には「仲間Ａより：カードを購入しませんか？」等のお知らせのメッセージ２０４が表示され、このメッセージ２０４をクリックすれば、図９の画面が表示されるようになっている。あるいは、前記のメッセージ２０４のクリックを経ることなく、仲間Ｂの端末装置３がゲームサーバ１にアクセスしたときに、直接、図９の画面が表示されるようにしてもよい。

図９の画面には、売却対象のユーザＡのカード２２８およびそのカードの情報２２９、ユーザＡに関する情報２３０（仲間のアバターまたは写真、名前、レベル、親密度等）、対価を含む売却条件の情報２３１等が表示される。図９では、売却条件の情報２３１として、「このカードを売却したいので、５００強化ポイントで購入しませんか？」というテキストの情報が表示されている例を示している。

また、画面には、現在、仲間Ｂが所有している強化ポイントの情報２３２、購入するボタン２３３、購入しないボタン２３４、購入の有効期限の情報２３５なども表示される。ここで、仲間Ｂが、購入するボタン２３３を押せば、提示された条件を了承したことになる。この場合、ゲームサーバ１は、ユーザＡのカードと、仲間Ｂの５００強化ポイント（カードの対価）との交換処理を実行する。一方、仲間Ｂが、購入しないボタン２３４を押せば、ユーザＡの条件提示に対して購入を拒否したことになる。また、仲間ＢがユーザＡのカードを購入するためには、有効期限内（例えば、条件提示の開始から３時間以内）に提示された条件を了承する必要がある。

また、複数の仲間に売却条件を提示する場合、１人ずつ順番に提示する方法と、同時に複数人に一括して提示する方法とがある。その詳細については後述する。

また、売却条件の提示対象となる仲間の範囲を、ユーザが任意に設定できるようにしてもよい。この場合、仲間の範囲と、その範囲の仲間に提示するカードの売却条件とをユーザが事前に設定しておけば、その条件が適用されるカードの入手時に、その売却条件が自動的に前記範囲内の仲間に提示される。

ここで、「仲間の範囲」は、「ユーザとの親密度」、「仲間のレベル」、「仲間のゲームへのアクセス頻度」等の「仲間に関するゲーム情報」に基づいて定めることができる。あるいは、「仲間の範囲」は、仲間のユーザＩＤやユーザ名等の「個人を特定する情報」に基づいて定めることもできる。

先ず、「仲間の範囲」を、「ユーザとの親密度」に基づいて定める例について説明する。ここで、親密度とは、仲間関係が成立している２人のユーザの親密さを示すものであり、２人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。

例えば、２人の親密度は、ゲーム内の交流の回数や頻度に基づいて設定でき、ユーザが仲間と交流するほど、その仲間との親密度は高くなる。ゲーム内の交流の例としては、挨拶、メッセージ送信、プレゼント、対戦協力、チャットなどが挙げられるが、これに限らず、ゲームの種類や内容に応じて様々な交流を適用できる。ここで、挨拶とは、ボタンを押す等の簡単な操作だけでゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール（応援）を送る、ガッツ（やる気）を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。ゲームサーバ１は、仲間関係にある２人の親密度を、データベースサーバ２に記憶して管理している。例えば、親密度は、最低１〜最高５の５段階で表される。なお、親密度付与処理の詳細は後述する。

図１０には、ユーザが親密度によって仲間の範囲を指定した上で、カードの売却条件を任意に設定するための自動売却条件設定画面の一例を示す。この画面には、前述した売却するカードの条件を設定する領域２２１およびカード売却の対価を設定する領域２２２の他に、仲間指定領域２２０が設けられている。

仲間指定領域２２０では、親密度の範囲を指定するための入力部２４１・２４２が表示され、プルダウンメニューから親密度の値を選択して仲間の範囲を指定できる例を示している。例えば、入力部２４１で「３」を選択し、入力部２４２を空白（未選択）とした場合、「親密度３以上」を設定することができる。また、例えば、入力部２４１を空白とし、入力部２４２で「３」を選択した場合、「親密度３以下」を設定することができる。また、例えば、入力部２４１で「２」を選択し、入力部２４２で「４」を選択した場合、「親密度２〜４」を設定することができる。

なお、範囲指定の入力方法はこれに限定されるものではなく、例えば親密度の値を端末装置３におけるキー入力、音声入力（音声認識による入力）等により直接入力できるようにしてもよい。

図１０の自動売却条件設定画面での操作により、異なる仲間の範囲には、異なるカードの売却条件を設定することができる。例えば、親密度が所定以上の仲間と、それよりも低い仲間とで、仲間に売却するカードの条件を次のように異ならせることができる。すなわち、親密度が高い仲間には、親密度の低い仲間よりも、より良い（レア度の高い）カードが自動的に提示されるようにすることができる。一例を挙げると、親密度が３以上の仲間の範囲に対しては、仲間に提示するカードのレア度の条件を「レア度４」に設定する。一方、親密度が２以下の仲間の範囲に対しては、仲間に提示するカードのレア度の条件を「レア度３」に設定する。

あるいは、同じレア度のカードを提示するにしても、親密度が高い仲間には、親密度の低い仲間よりも、対価を安価に設定することもできる。一例を挙げると、仲間に提示するカードの条件を「自分のチーム以外のレア度４のカード」とし、その対価については、親密度が３以上の仲間の範囲に対しては「３００ポイント」に設定し、親密度が２以下の仲間の範囲に対しては「５００ポイント」に設定する。このように、図１０の自動売却条件設定画面での操作により、仲間の親密度に応じた任意の売却条件が設定可能となる。

次に、「仲間の範囲」を、「仲間のレベル」に基づいて定める例について説明する。ここで、レベルとは、ゲームの進行度やゲームの習熟度を示す指標となるものであり、ゲームを進行させることにより向上したり、対戦ゲームで所定の勝利条件を満たすことにより向上したりする。本野球ゲームでは、ユーザがゲームを進行させる（例えば、スカウトモードを実行する）ことにより経験値が蓄積され、当該経験値が一定量に達することによりユーザのレベルがアップするようになっている。なお、ゲーム内対戦の勝敗等によりレベルが決定されるゲームでは、ユーザのレベルは向上したり低下したりする。

また、本野球ゲームでは、複数のレベルのゲーム内リーグが存在する。例えば、最下位レベルの第１リーグから最上位レベルの第１０リーグまでの１０のゲーム内リーグが存在し、各ユーザのチームが何れかのゲーム内リーグに所属して、同一リーグの他のユーザのチームと自動で対戦を行う（これを「自動対戦」と称する）。また、この自動対戦の成績に応じて、異なるリーグに所属するユーザのチーム同士の入替戦が自動で実行され、ユーザのチームが所属するゲーム内リーグのレベルが変化する。よって、「仲間のレベル」として、仲間のチームが所属するゲーム内リーグのレベルを用いることもできる。また、レベルを、ランク、グレード、段位等と称してもよい。

図１１には、ユーザがレベルによって仲間の範囲を指定した上で、プレゼントするカードの条件を任意に設定するための自動プレゼント条件設定画面の一例を示す。この画面では、仲間指定領域２２０にレベルによって仲間の範囲を指定するための入力部２４３・２４４が表示され、レベルの値を端末装置３におけるキー入力、音声入力等により直接入力できる。なお、プルダウンメニューからレベルの値を選択して範囲指定できるようにしてもよい。その際、レベルの値は１単位でもよいが、入力時の判断を簡便に行えるようにするために１０単位にしてもよい（１０、２０、３０等）。なお、他の領域２２１・２２２については、図１０の画面と同様である。

図１１の自動売却条件設定画面での操作により、異なる仲間の範囲には、異なるカードの条件を設定することができる。例えば、レベルが所定以上の仲間と、それよりも低い仲間とで、仲間に提示するカードの条件を異ならせることができる。レベルの低い仲間（ゲームを開始して間もないような仲間等）については、レア度が高くないカードを提示しても喜んでもらえるが、レベルの高い仲間については、レア度が高くないカードを提示してもあまり喜んでもらえない可能性が高い。これは、レベルの高い仲間は、高いレア度のカードをすでに複数保有している場合が多く、保有していない高いレア度のカードは欲しいと思っても、低いレア度のカードには関心がないと考えられるためである。そこで、例えば、レベルが３０以上の仲間の範囲に対しては、仲間に提示するカードのレア度の条件を「レア度４」に設定する。一方、レベルが２９以下の仲間の範囲に対しては、仲間に提示するカードのレア度の条件を「レア度３」に設定する。このように、図１１の自動売却条件設定画面での操作により、仲間のゲームへのアクセス頻度に応じた任意の売却条件が設定可能となる。

次に、「仲間の範囲」を、「仲間のゲームへのアクセス頻度」に基づいて定める例について説明する。ゲームへのアクセス頻度については、現在から遡る所定期間（例えば１週間）のゲームへのアクセス日数またはアクセス回数により表すことができる。あるいは、先週の（先月の）アクセス日数またはアクセス回数をアクセス頻度としてもよい。ユーザによっては、以前は頻繁にゲームをしていたが、最近は殆どゲームをしていないというユーザもある。よって、ゲームへのアクセス頻度は、最近のゲームへのアクセス頻度が反映されるように、例えば現在から遡る１週間または先週１週間のアクセス日数等とすることが好ましい。

なお、アクセス日数については、１日に１回以上ゲームサーバ１にアクセス（ログイン）した場合にゲームにアクセスした日としてカウントされる。ユーザのゲームへのアクセスは、アクセスログとして記録されている。よって、ゲームサーバ１は、各ユーザのアクセスログに基づいてアクセス頻度を取得できる。

図１２には、ユーザがゲームへのアクセス頻度によって仲間の範囲を指定した上で、提示するカードの条件を任意に設定するための自動売却条件設定画面の一例を示す。この画面では、仲間指定領域２２０にゲームへのアクセス頻度によって仲間の範囲を指定するための入力部２４５・２４６が表示され、アクセス頻度の値を端末装置３におけるキー入力、音声入力等により直接入力できる。なお、プルダウンメニューからアクセス頻度の値を選択して範囲指定できるようにしてもよい。なお、他の領域２２１・２２２については、図１０の画面と同様である。

図１２の自動売却条件設定画面での操作により、異なる仲間の範囲には、異なるカードの条件を設定することができる。例えば、ゲームへのアクセス頻度が所定以上の仲間と、それよりも低い仲間とで、仲間に提示するカードの条件を異ならせることができる。ゲームへのアクセス頻度が高い仲間については、仲間同士でお互いにカードの売買等を行うことにより、コミュニケーションの活性化が図れる。一方、ゲームへのアクセス頻度が低い仲間については、あまりゲームを行っていないことから、そもそもカードの売買を行う相手としてあまり魅力的ではない。そこで、例えば、１週間に４日以上ゲームにアクセスする仲間の範囲に対しては、仲間に提示するカードのレア度の条件を「レア度４」に設定する。一方、ゲームへのアクセスが１週間に３日以下の仲間の範囲に対しては、仲間に提示するカードのレア度の条件を「レア度３」に設定する。

また、例えば、所定のアクセス頻度以下（例えば、１週間に１日以下）の仲間の範囲については、自動売却の条件を設定しないことにより、売却条件の提示処理が実行されないようにすることも可能である。あるいは、所定のアクセス頻度以下の仲間の範囲については、売却条件の提示処理を実行しないという設定をしてもよい。

このように、図１２の自動売却条件設定画面での操作により、仲間のゲームへのアクセス頻度に応じた任意の売却条件が設定可能となる。

なお、図１０〜図１２では、それぞれ、親密度、レベル、ゲームへのアクセス頻度によって仲間の範囲を指定できる例を示したが、これらを組み合わせて仲間の範囲を指定できるようにしてもよい。例えば、図１３に示すように、仲間指定領域２２０に、親密度の範囲を指定するための入力部２４１・２４２、レベルの範囲を指定するための入力部２４３・２４４、およびゲームへのアクセス頻度の範囲を指定するための入力部２４５・２４６を設ける。この場合、例えばユーザが親密度の範囲のみ入力部２４１・２４２で指定し、その他の入力部については空欄にすれば、親密度だけで仲間の範囲を指定できる。また、例えばユーザが親密度の範囲を入力部２４１・２４２で指定すると共に、レベルの範囲を入力部２４３・２４４で指定すれば、親密度とレベルを組み合わせて仲間の範囲を指定できる。この組み合わせは、ＡＮＤ条件またはＯＲ条件の何れにすることも可能である。また、ゲームへのアクセス頻度による仲間の範囲の指定も同様である。

次に、「仲間の範囲」を、仲間のユーザＩＤやユーザ名等の「個人を特定する情報」に基づいて定める例について説明する。この場合、ゲームサーバ１は、特定の仲間を指定したユーザからの要求に応じて、仲間の範囲を仲間のユーザＩＤ等に基づいて設定する。

図１４および図１５には、ユーザが仲間の範囲に含まれる特定の仲間を指定した上で、提示するカードの条件を任意に設定するための自動売却条件設定画面の一例を示す。図１４は自動売却条件設定画面を開いた当初の状態の画面例、図１５はユーザによって特定の仲間を指定する入力が行われた後の画面例である。

図１４の画面の仲間指定領域２２０では、ユーザの全ての仲間の中から任意の仲間を１人以上選択できる。この仲間指定領域２２０には仲間リストボタン２４７が設けられており、当該ボタン２４７を押せば、端末装置３から仲間リスト要求がゲームサーバ１へ送信される。ゲームサーバ１は、ユーザの端末装置３からこの要求を受信して、当該ユーザの仲間リストを表示させる情報を端末装置３へ送信する。これにより端末装置３には、例えば図１６に示すような仲間リスト画面が表示され、任意の仲間を選択できるようになる。この仲間リスト画面には、ユーザの仲間のアバター、名前、レベル、チーム、リーダーに設定しているカード等の情報を含む仲間の一覧が表示される。なお、画面に表示しきれない仲間の情報については、画面をスクロールする又は仲間リストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。この仲間リスト画面で任意の仲間を選択（例えば、仲間のアバターまたは名前の部分をクリック）すれば、図１５に示すように自動売却条件設定画面に戻り、選択した仲間の情報２４８（仲間のアバター、名前、レベル、チーム等）が画面に表示される。図１５の例では、ユーザが仲間Ｂおよび仲間Ｃを選択した例を示している。なお、１人の仲間だけを仲間の範囲として設定してもよいし、３人以上の仲間を選択して仲間の範囲（条件付けのグループ）を設定してもよい。

なお、仲間指定領域２２０にユーザＩＤを入力する領域を設け、ユーザが仲間のユーザＩＤを直接入力することによって、特定の仲間を指定するようにしてもよい。但し、一般的にユーザが自分の仲間のユーザＩＤを覚えていることは少ないので、前述のように、仲間リスト画面から特定の仲間を選択できるようにすることが望ましい。ユーザが仲間リスト画面から特定の仲間を選択した場合も、ゲームサーバ１では、その仲間のユーザＩＤに基づいてゲーム情報を管理しているので、ユーザが仲間のユーザＩＤを指定したことと実質的には同様である。

また、後述するように、ユーザが仲間の範囲として特定の仲間を指定しようとする場合に、ユーザの仲間のゲーム情報に基づいて、売却相手の候補者となる仲間をユーザに報知するようにしてもよい。

なお、他の領域２２１・２２２については、図１０の画面と同様である。図１４および図１５の自動売却条件設定画面での操作により、仲間の範囲に特定の仲間を指定し、仲間の範囲毎に異なるカードの条件を設定することができる。例えば、ユーザＡにとって、仲間Ｂおよび仲間Ｃは、お互いにレア度の高い相手チームの選手カードを売買し合うような特別な仲間の場合、提示するカードの条件として、例えば「仲間のチームでレア度５の選手カード」に設定する。本構成により、特定の仲間に対して任意の売却条件を設定することが可能となる。

また、後述するように、仲間の範囲として特定の仲間が設定された場合、その仲間のゲーム情報に基づいて、その仲間に提示するカードの条件（またはその対価を含む売却条件）をゲームサーバ１が自動的に設定するようにしてもよい。

〔ゲーム管理装置の機能的構成および動作〕
次に、上記のゲームを実現するゲーム管理装置の機能的構成の一例について説明する。図１７は、端末装置３と通信するゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の基本的な構成を示す機能ブロック図である。

本実施の形態に係るゲーム管理装置は、ユーザ情報記憶制御手段６０、受信手段６１、実行手段６２、画面生成手段６３、送信手段６４、アクセス管理手段６５および交流制御手段６６等を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

ユーザ情報記憶制御手段６０は、各ユーザのゲームに関する情報をデータベースサーバ２に記憶して管理する。ユーザ情報記憶制御手段６０がデータベースサーバ２に記憶している、ユーザのゲームに関する情報であるユーザ情報データベースの一例（この例ではユーザＩＤ＝０００００１の１人分の情報）を、図１８に示す。

ユーザ情報記憶制御手段６０は、ユーザＩＤと対応付けて、ユーザの基本情報、希望チーム、レベル情報、保有カード、保有ポイント、保有アイテム、仲間情報、アクセスログ、交流履歴、欲しい物の情報等を、データベースサーバ２の所定の記憶領域に記憶する。

ユーザの基本情報としては、ログインＩＤ、パスワード、ユーザ名（ゲーム内で使用するニックネーム等）等がある。ここで、ログインＩＤおよびパスワードは、各ユーザが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。ユーザ名は、ゲーム内で使用するニックネーム等である。

希望チームは、ユーザがゲームサービスを受けるための利用登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定したお気に入りチームの情報である。本実施の形態では、各ユーザが、複数のチーム（例えば、現実世界の日本のプロ野球１２チーム）のうちの希望する何れか１つのチームを登録することができる。

レベル情報には、前述したユーザのレベル、ゲーム内リーグのレベル等がある。

保有カードの情報とは、ゲーム内でユーザが保有している選手キャラクタのカードの情報（選手ＩＤ、能力値等）である。また、図１９に例示するように、データベースサーバ２には、選手ＩＤと対応付けられて、選手キャラクタの名前、背番号、ポジション、所属チーム、初期能力値（未強化の値）、レア度、画像データなどが記憶された選手データベース（選手ＤＢ）が存在する。よって、ゲームサーバ１は、ユーザ情報記憶制御手段６０によって記憶されている選手ＩＤに基づいて、当該選手ＩＤに対応するカード（選手キャラクタ）に関する各種情報を、選手ＤＢから取得できるようになっている。

保有ポイントおよび保有アイテムの情報は、ゲーム内でユーザが保有している各種ポイント（ポイントに準ずる値などを含む）およびアイテムの情報である。本実施の形態では、前述の経験値、強化ポイント、抽選ポイント、行動ポイント、運営コストなどが保有ポイントの情報に含まれる。また、アイテムには、前述の回復アイテムや選手キャラクタを強化するための強化アイテム等が含まれる。各アイテムにはそれらを一意に識別するアイテムＩＤが付されており、アイテムＩＤによって管理される。

また、仲間情報とは、ユーザに関係付けられた仲間の情報であり、ユーザＩＤと対応付けられて仲間のユーザＩＤがデータベースサーバ２に記憶される。また、アクセスログとは、ユーザの端末装置３がゲームサーバ１へアクセス（ログイン）した日時等の時間情報である。また、交流履歴とは、ユーザが他のユーザ（仲間等）にゲーム内で交流を行った履歴の情報である。この交流履歴には、交流の種類、相手、時間の情報が含まれる。交流の種類としては、挨拶、メッセージ送信、プレゼント、対戦協力、チャットなどがある。交流の相手の情報として、相手のユーザＩＤが記憶される。

また、本ゲームでは、各ユーザが欲しいと思うカードやアイテムを欲しい物として登録できる。ユーザが登録した欲しい物の情報（選手ＩＤ等）も、ユーザＩＤと対応付けられてデータベースサーバ２に記憶される。

次に、図１７に示す受信手段６１、実行手段６２、画面生成手段６３、送信手段６４について説明する。受信手段６１および送信手段６４は、ゲームサーバ１のＣＰＵ１１および通信制御部１５により実現される機能である。

ユーザの端末装置３のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する入力の操作を行った場合、当該入力に関する情報（ゲーム画面のリクエスト等）が端末装置３のウェブブラウザによってゲームサーバ１へ送信される。ゲームサーバ１では、前記入力に関する情報を受信手段６１が受信したとき、実行手段６２が、当該情報に応じてユーザのゲームに関する情報を読み出して演算やデータ処理を行うことによってゲームを実行する。

例えば、試合モードで他のユーザのチームと対戦するという入力操作がユーザによって行われた場合を例に挙げると、実行手段６２は、対戦を行う両ユーザのユーザＩＤに対応した両チームの選手キャラクタ（試合に出場するキャラクタ）の情報をデータベースサーバ２から読み出す。そして、実行手段６２は、ＡＩ（Artificial Intelligence）プログラム等により、両チームの選手キャラクタの能力等のパラメータに基づいて、野球の試合のシミュレーションを実行し、試合の勝敗を決定する。

次に、画面生成手段６３について説明する。画面生成手段６３は、実行手段６２による実行結果に応じて、例えばＨＴＭＬデータからなるゲーム画面データを生成する。ＨＴＭＬデータには、データベースサーバ２から読み出されたキャラクタ等の画像データを含めてもよい。また、ＨＴＭＬデータには、端末装置３のウェブブラウザのプラグインによって動作するスクリプト（プログラム）が埋め込まれていてもよい。ゲームサーバ１から提供されたスクリプトが端末装置３で実行される場合は、端末装置３で表示されるゲーム画面を動画とすることも可能である。あるいは、画面生成手段６３は、ストリーミング形式の映像を生成してもよい。

また、送信手段６４は、画面生成手段６３により生成された画面データ（ＨＴＭＬデータ、ストリーミング形式の映像データ等）を、ゲーム画面のリクエストに対するレスポンスとして、または実行手段６２による実行結果として、ユーザの端末装置３へ送信する。このゲーム画面データを受信したユーザの端末装置３では、ウェブブラウザおよびそのプラグイン等によって表示部３５にゲーム画面が表示される。

次に、アクセス管理手段６５について説明する。アクセス管理手段６５は、ゲームサービスを受けようとするユーザが端末装置３を操作してゲームサーバ１にアクセス（ログイン）しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザＩＤと対応付けられたログインＩＤおよびパスワードに基づく認証がある。また、ユーザがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できるように、端末装置３である携帯電話やスマートフォンの個体識別番号（電話番号とは別の端末を一意に識別するための情報）、または契約者固有ＩＤ（端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないＩＤ）を利用した認証を行ってもよい。

次に、交流制御手段６６について説明する。交流制御手段６６は、ゲーム内で行われるユーザ同士の交流やコミュニケーションを実現するものである。交流制御手段６６は、ユーザの端末装置３から、他のユーザ（特に、仲間）に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該ユーザから当該他のユーザに対しての交流処理を実行する実行手段６２を制御する。交流処理には、例えば、挨拶、メッセージの伝達、プレゼント、対戦協力、チャットなどがある。

次に、図２０の機能ブロック図を参照して、ゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能的構成について説明する。ゲーム管理装置としてのゲームサーバ１は、主に、仲間管理手段５１（管理手段）、設定手段５２、提示手段５３および交換手段５４を備えている。これらの各手段は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

仲間管理手段５１は、ユーザに関係付けられた仲間（他のユーザ）を管理する機能を有する。あるユーザが他のユーザと仲間関係を構築するための一形態としては、２人のユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ１を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。その他の形態としては、既にゲームサービスに登録済みのユーザが、未登録のユーザをゲームに招待し、招待を受けたユーザがゲームサービスに登録した場合に、招待した側とされた側との２人のユーザを仲間同士とする形態もある。仲間管理手段５１は、図１８に例示するように、仲間関係にあるユーザ同士のユーザＩＤを関係付けてデータベースサーバ２に記憶し、仲間管理を行う。

設定手段５２は、ユーザからの要求に応じて、仲間に提示するオブジェクトの交換条件（本実施の形態ではカードの売却条件）を予め設定する機能を有する。例えば、ユーザの端末装置３に表示される図７の自動売却条件設定画面で、ユーザが、カードの売却条件を入力して設定ボタン２２７を押せば、端末装置３からは条件設定要求がゲームサーバ１へ送信される。これがユーザからの要求である。ゲームサーバ１の設定手段５２は、ユーザからの条件設定要求を受信し、ユーザが指定したカードの売却条件を設定（登録）する。すなわち、ユーザＩＤと対応付けて、カードの売却条件を、データベースサーバ２に記憶する。

なお、カードの売却条件には、売却対象のカードおよび当該カードとの交換に必要な対価の情報が含まれる。ユーザが、売却対象のカードの条件を指定（入力）すれば、設定手段５２が、自動的に、デフォルトの対価を設定することが好ましい。

ここで、前記のデフォルトの対価は、ユーザが指定した売却対象のカードと等価なポイント（またはゲーム内通貨等）とすることができる。あるいは、ユーザが仲間にカードを安く譲ることを前提としたゲーム仕様とする場合、売却対象のカード本来の価値よりも安価な対価（例えば、等価なポイントが５００ポイントのところ３００ポイントに設定する）を、デフォルトの対価として自動設定するようにしてもよい。逆に、ユーザが仲間にカードを少し高めに売却することを前提としたゲーム仕様とする場合、売却対象のカード本来の価値よりも高価な対価（例えば、等価なポイントが５００ポイントのところ６００ポイントに設定する）を、デフォルトの対価として自動設定するようにしてもよい。このように、対価がデフォルトで自動的に設定される場合、ユーザは、基本的に、カードの売却条件として、売却対象のカードの条件のみを指定（入力）すればよい。

また、自動的に設定されたデフォルトの対価を、ユーザによる入力操作（図７の変更ボタン２２６の操作等）により、任意に変更できるようにすることが好ましい。このように、ユーザが売却対象のカードの条件のみを指定すれば、その対価がデフォルトで自動設定され、ユーザがデフォルトの対価を変更したいときだけ変更操作をすればよい構成とすることにより、ユーザがカードの売却条件を容易に設定できるようになる。

図２１に、ユーザＩＤ＝０００００１のユーザＡが設定した自動売却条件の一例を示す。この例では、売却対象のカードとして「自分のチーム以外のレア度４のカード」、その対価として「５００強化ポイント」という第１の売却条件と、売却対象のカードとして「自分が既に所有しているレア度５のカード」、その対価として「１０００強化ポイント」という第２の売却条件とが設定されている。

また、例えば、図１０〜図１５の自動売却条件設定画面では、ユーザが仲間の範囲を指定してカードの売却条件を設定できる。すなわち、設定手段５２は、ユーザからの要求に応じて、仲間の範囲および当該範囲内の仲間に提示するカードの交換条件を予め設定する機能を有する。

前述のように、仲間の範囲は、親密度、レベル、ゲームへのアクセス頻度、個人を特定する情報（仲間のユーザＩＤ等）などに基づいて設定できる。すなわち、ユーザの端末装置３に表示される図１０〜図１５等の自動プレゼント条件設定画面で、ユーザが仲間の範囲および当該範囲の仲間に提示するカードの売却条件を入力して設定ボタン２２７を押せば、端末装置３からは条件設定要求がゲームサーバ１へ送信される。これがユーザからの要求である。ゲームサーバ１の設定手段５２は、ユーザからの条件設定要求を受信し、ユーザが入力した仲間の範囲およびカードの売却条件を設定（登録）する。すなわち、ユーザＩＤと対応付けて、仲間の範囲および当該範囲内の仲間に提示するカードの売却条件を、データベースサーバ２に記憶する。

図２２ないし図２６に、ユーザＩＤ＝０００００１のユーザＡが設定した自動売却条件（仲間の範囲およびカード売却条件）の一例を示す。図２２は、仲間の範囲を親密度に基づいて定めて自動プレゼント条件を設定した例である。ここで、ゲームサーバ１が親密度を付与する構成について以下に説明する。

ゲームサーバ１は、親密度付与手段５６（図３３参照）を備えている。この親密度付与手段５６は、仲間関係にある２人のユーザに対して親密度を付与する機能を有する。ゲームサーバ１は、仲間関係にある２人の親密度を、データベースサーバ２に記憶して管理している。以下に、親密度付与の具体例を挙げる。

親密度付与手段５６は、例えば、仲間同士の２人のユーザ間で交流処理が実行される毎に、所定値（例えば１ポイント）の親密ポイントを付与するようになっている。なお、交流の内容により付与する親密ポイントを変えてもよい。例えば、挨拶は１ポイント、メッセージ送信は２ポイント、売買およびプレゼントは３ポイント、対戦協力およびチャットは４ポイント等としてもよい。なお、仲間同士の一方または両方の交流が所定期間（例えば１週間）途絶えた場合、２人の親密ポイントが所定ポイント（例えば３ポイント）減少するようにしてもよい。また、本実施の形態では、２人の親密ポイントに応じて、例えば５段階の親密度が設けられている。例えば、親密ポイントが０〜２４ポイントで親密度＝１（知り合い）、２５〜４９ポイントで親密度＝２（友人）、５０〜７４ポイントで親密度＝３（親友）、７５〜９９ポイントで親密度＝４（相棒）、１００ポイント以上で親密度＝５（盟友）となる。

前述のように、本ゲームでは、ユーザが他のユーザとゲーム内で交流（挨拶、カードの売買等）を行うことにより、抽選ポイントを獲得できる。そして、相手との親密度が高くなるほど、その相手との交流により獲得できる抽選ポイント（ゲーム内ポイント）は大きくなるというメリットを生じる。すなわち、ユーザが仲間と売買を行えば、親密度が向上し、獲得できる抽選ポイントも大きくなるので、売買を行うことに対してもより強い動機づけが与えられるはずである。しかしながら、上記のようなメリットがあると分かっていても、売買のための操作（自分の手持ちカードの中から、あるいは新たなカードの入手毎に、不要なカードを決め、さらにそれを欲しがっていそうな仲間を想定した上で、その相手に不要カードの売却条件を提示するための操作）を、毎回、手動で行う場合、その操作が手間であるがゆえに、仲間への売却条件の提示自体が積極的に行われない可能性がある。この点、本実施の形態によれば、カードの売却を行うための事前の設定を行うだけで、あとは自動的に仲間への売却条件の提示が行われ、且つ、売買取引が成立すれば自動的に親密ポイントも獲得されることになるので、ユーザにとって非常に有用な機能を提供することができる。

そして、本実施の形態では、仲間の範囲を親密度等に基づいて定めて、自動売却条件をその範囲に適したものに設定できる。以下には、親密度に基づいて仲間の範囲を設定する具体例を示す。

一般的に、ユーザは、親密度が高い仲間ほど、相手の欲しがるカード（例えば、レア度の高いカード）を売却対象として提示したり、そのカードの対価を安くしたりして、相手を喜ばせたいと考える。そこで、図２２では、親密度が３以上の仲間の範囲には、売却対象のカードとして「自分のチーム以外のレア度４のカード」、その対価として「２００強化ポイント」という自動売却条件が設定され、親密度が２以下の仲間の範囲には、売却対象のカードとして「自分のチーム以外のレア度３のカード」、その対価として「３００強化ポイント」という自動売却条件が設定されている例を示している。

なお、図２２の例では、仲間の範囲を、親密度が３以上と２以下との２段階に分けた例を示したがこれに限定されない。例えば、仲間の範囲を、親密度１、２〜４、５の３段階に分けたり、親密度１、２、３、４、５の５段階に分けたりしてもよい。また、親密度５の仲間にだけ自動売却条件を設定し、その他の親密度の仲間には自動売却条件を設定しない（すなわち、売却条件の提示処理が実行されない）ようにしてもよい。

図２３は、仲間の範囲をレベルに基づいて定めて自動売却条件を設定した例である。前述のように、レベルが高い仲間には、レア度の低いカードを提示してもあまり喜んでもらえない可能性が高い。そこで、図２３では、レベルが３０以上の仲間の範囲には、売却対象のカードとして「自分のチーム以外のレア度４のカード」、その対価として「５００強化ポイント」という自動売却条件が設定され、レベルが２９以下の仲間の範囲には、売却対象のカードとして「自分のチーム以外のレア度３のカード」、その対価として「３００強化ポイント」という自動売却条件が設定されている例を示している。

なお、図２３の例では、仲間の範囲を、レベル３０以上とレベル２９以下との２段階に分けた例を示したがこれに限定されない。例えば、仲間の範囲を、レベル９以下、１０〜２９、３０〜４９、５０以上の４段階に分ける等、仲間の範囲は任意に設定できる。そして、例えば、レベル９以下の仲間にはレア度２、レベル１０〜２９の仲間にはレア度３、レベル３０〜４９の仲間にはレア度４、レベル５０以上の仲間にはレア度５の各カードを自動的に売却対象として提示する条件を設定することができる。

図２４は、仲間の範囲をゲームへのアクセス頻度に基づいて定めて自動売却条件を設定した例である。ゲームへのアクセス頻度が低い仲間にレア度の高いカードを提示しても、その仲間はあまりゲームを行っていないので、相手がそれを購入したり、相手からもレア度の高いカードが提示されたりすることも少ないと考えられる。逆に、ゲームへのアクセス頻度が高い仲間にレア度の高いカードを提示すれば、相手がそれを購入したり、相手からもレア度の高いカードが提示されたりする可能性が前記の場合よりも高くなり、カードの売買を通した良好な関係の構築に期待が持てる。そこで、図２４では、ゲームへのアクセス頻度が４日／週以上の仲間の範囲には、売却対象のカードとして「自分のチーム以外のレア度４のカード」、その対価として「５００強化ポイント」という自動売却条件が設定され、アクセス頻度が２日〜３日／週の仲間の範囲には、売却対象のカードとして「自分のチーム以外のレア度３のカード」、その対価として「３００強化ポイント」という自動売却条件が設定されている例を示している。また、この例では、アクセス頻度が１日／週以下の仲間の範囲には、自動売却条件を設定していない。これは一例であり、仲間の範囲はユーザが任意に設定できる。

また、図２５には、親密度、レベル、ゲームへのアクセス頻度の３つをＡＮＤ条件によって組み合わせて仲間の範囲を設定した例を示している。この例では、親密度４以上、且つ、レベル１００以上、且つ、アクセス頻度５日／週の条件を満たす仲間に対して、売却対象のカードとして「相手のチームでレア度４のカード」、その対価として「３００強化ポイント」という自動売却条件を対応付けている。なお、ユーザにとっては、自分のチームのカード（特にレア度の高いもの）は貴重であるため、手放したくないと考えることも多い。そこで、売却対象のカードの条件として「相手のチームのカード」という条件を設定した場合でも、ユーザ自身のチームのカードは条件から除外されるように、ユーザが任意に設定できるようにしてもよい。

このように、親密度、レベル、ゲームへのアクセス頻度等のゲーム情報を用いれば、個人を特定することなく仲間の範囲を設定できる。

一方、図２６には、仲間の範囲を、個人を特定する情報（仲間のユーザＩＤ）に基づいて定めて自動売却条件を設定した例を示している。この例では、仲間の範囲が仲間ＢのユーザＩＤ＝０００００２および仲間ＣのユーザＩＤ＝０００００５によって定められ、当該仲間の範囲に、売却対象のカードとして「相手のチームでレア度４のカード」、その対価として「３００強化ポイント」という自動売却条件が対応付けられている。また、ユーザＩＤ＝００００１０の仲間Ｄに対しては、売却対象のカードとして「相手のチームでレア度５のカード」、その対価として「５００強化ポイント」という自動売却条件が対応付けられている。このように、ユーザが自動でカードの売却条件を提示したい特定の仲間を指定して、任意の売却条件を設定できる。

上記のようにして行われた自動売却条件の設定は、ユーザの任意でいつもで解除することができる。すなわち、ユーザが端末装置３で所定の解除操作を行えば、ユーザからの解除要求がゲームサーバ１へ送信される。ゲームサーバ１は、この解除要求に応じて、ユーザＩＤに対応づけて記憶されている自動売却条件の設定情報を削除する、または、設定解除フラグを立てる。本実施の形態では、仲間の範囲を複数指定して、複数の自動売却条件を設定できるが、全ての設定を一括して解除することもできるし、一部の設定のみを解除することもできる。

また、提示手段５３は、前記のようにして設定された自動売却条件が適用されるカードをユーザが入手した場合、仲間に当該カードの売却条件を自動的に提示する機能を有する。特に、仲間の範囲を定めて自動売却条件が設定されている場合、提示手段５３は、自動売却条件が適用されるカードをユーザが入手した場合、その範囲内の仲間に、当該カードの売却条件を自動的に提示する機能を有する。例えば、提示手段５３は、自動売却条件が適用される、売却対象のカードをユーザが入手した場合、図９に示す画面（売却対象のカード２２８および売却条件の情報２３１を含む画面）を生成し、ユーザの仲間の端末装置３に送信する。

提示対象となる仲間が複数存在する場合、提示手段５３は、その中からランダムに選択した１人の仲間に売却条件を提示してもよい。あるいは、提示対象となる複数の仲間に対して、１人ずつ順番に、あるいは同時に、売却条件を提示してもよい。あるいは、提示対象となる複数の仲間の中からランダムに選択した所定数（２人以上）の仲間に対して、１人ずつ順番に、あるいは同時に、売却条件を提示してもよい。あるいは、親密度の高い仲間から、順次、売却条件を提示してもよい。あるいは、ゲームにアクセス（ログイン）している仲間に対して優先的に売却条件を提示してもよい。

ところで、売却対象となったカードを仲間に提示している間は、ユーザが入手したカードがユーザ自身のものになるのか（取引不成立）、仲間のものになるのか（取引成立）が不確定な状態となる。よって、売却対象となったカードは、仲間への売却条件の提示期間中、ユーザが対戦に使用したり、強化（育成）したりできない。そこで、提示手段５３は、ユーザが入手したカードの売却条件を仲間に提示している間、仲間への売却条件提示中において、以下に示す管理情報をデータベースサーバ２に記憶して、仲間との取引を管理している。ここで、「ユーザが入手したカードの売却条件を仲間に提示している間」には、仲間がゲームにアクセスしていないため、実際には、仲間への提示が行われているわけではないが、仲間がゲームにアクセスすればその仲間へ売却条件を提示できる状態となっている期間を含む。

図２７に、仲間への売却条件提示管理情報の一例を示す。同図に示すように、提示手段５３は、当該ユーザのユーザＩＤと対応付けて、取引ＩＤ、売却条件、提示対象の仲間のユーザＩＤ、開始時間、取引の成否フラグ等をデータベースサーバ２に記憶して、仲間との取引を管理している。ここで、図２７中の売却条件の情報としては、売却対象のカードの選手ＩＤおよびその対価が含まれる。開始時間とは、仲間に売却条件の提示が可能となった時間である。また、取引の成否フラグは、例えば、仲間との売買取引が成立した場合「１」、成立しなかった場合「０」とする１ビットの情報である。仲間が提示条件を了承すれば取引は成立し、仲間が提示条件を拒否するか、または所定時間（例えば３時間）以内に条件を了承するか否かの回答をしなければ取引は不成立となる。

交換手段５４は、カードの売却条件（オブジェクトの交換条件）を提示され仲間（他のユーザ）による当該条件を了承する操作に応じて、当該条件に基づく交換処理を実行する機能を有する。例えば、「ユーザＡが選手Ａのカードを５００強化ポイントで売却する」という条件を仲間Ｂが了承した場合（例えば、図９の画面で購入するボタン２３３を押した場合）、交換手段５４は、ユーザＡが入手した選手Ａのカードと、仲間Ｂの５００強化ポイントとを交換する処理を実行する。すなわち、図１８に例示するユーザ情報データベースにおいて、ユーザＡのユーザＩＤと対応付けて記憶されている選手Ａのカードを削除すると共に、当該選手Ａのカードを仲間ＢのユーザＩＤと対応付けて記憶する。さらに、仲間Ｂの保有ポイントから対価分を削減し、ユーザＡの保有ポイントに加算する。

なお、カードの売却条件を仲間に自動的に提示することを実現する構成は、図２０の仲間管理手段５１、設定手段５２、提示手段５３によって実現でき、交換手段５４は必須の構成要素ではない。交換手段５４は、売却条件の提示後の処理を実行する好ましい付加的構成要素である。

ここで、ゲームサーバ１による売却条件の提示処理の例を、図２８および図２９のフローチャートを参照しながら、以下に説明する。

例えば、ユーザがスカウトモード、抽選モード等のゲームを実行し、新たにカードを入手した場合（Ｓ１でＹＥＳ）、ゲームサーバ１は、ユーザが予め設定している自動売却条件を、データベースサーバ２から取得する（Ｓ２）。その後、ゲームサーバ１は、ユーザが入手したカードが、自動売却条件の適用対象であるか否かを判断する（Ｓ３）。

ユーザＩＤと関連付けて設定されている自動売却条件としては、図２１に例示するように、仲間の範囲を定めずに全ての仲間を対象とした自動売却条件と、図２２ないし図２６に例示するように、仲間の範囲を定めた自動売却条件とがある。ここでは、親密度に基づいて仲間の範囲を定めた、図２２の自動売却条件を適用する場合を例示する。

例えば、ユーザＡが入手したカードが、ユーザ自身のチーム以外のレア度４のカードであった場合、親密度３以上の仲間に提示する売却条件の適用基準を満たす（Ｓ３でＹＥＳ）。よって、この場合、ゲームサーバ１は、ユーザＡが入手したカードを、ユーザＡによる操作を伴うことなく、親密度３以上の仲間に売却条件を自動的に提示することになる。そこで、ゲームサーバ１は、対象となる親密度３以上の仲間の中から、売却条件を提示する仲間を決定する（Ｓ４）。例えば、ゲームサーバ１は、対象となる仲間の中からランダムに１人の仲間を決定する。

あるいは、ゲームサーバ１は、対象となる仲間の中から親密度に基づいて、売却条件を提示する仲間を決定してもよい。この場合、売却条件の提示先として、常に、親密度の最も高い仲間を決定することもできるが、次のようにして、その都度、親密度の違う仲間を決定することもできる。例えば、該当する仲間が２人いる（ユーザＡとの親密度の高い順から仲間Ｂ、仲間Ｃとする）場合について説明する。ユーザＡが自動売却対象のカードを入手した場合、そのカードの提示先を先ず仲間Ｂに決定する。その後、ユーザＡが自動売却対象の別のカードを入手した場合、そのカードの提示先を仲間Ｃに決定する。その後、ユーザＡが自動売却対象の別のカードを入手した場合、再度、そのカードの提示先を先ず仲間Ｂに決定する。このように、自動売却対象のカードを入手する毎に、親密度の高い仲間から、順次、提示先を決定し、ローテーションを行う。

前記ステップＳ４で売却条件を提示する仲間を決定した後、ゲームサーバ１は、その仲間に、売却条件を提示する（Ｓ５）。例えば、ゲームサーバ１は、その仲間に、図９の画面データを送信する。また、ゲームサーバ１は、ユーザＡのユーザＩＤと対応付けて、仲間への売却条件提示管理情報（図２７参照）を、データベースサーバ２に記憶する。

なお、Ｓ４で決定した仲間が、ゲームにアクセスしていないこともある。この場合、その仲間の端末装置３が、その後、ゲームサーバ１にアクセスしたときに、売却条件を提示することになる。

さらに、ゲームサーバ１は、ユーザＡに対して、入手したカードの購入を仲間に打診中である旨を報知する（Ｓ６）。例えば、ゲームサーバ１は、図３０に示す報知画面を生成し、ユーザＡの端末装置３に送信する。この報知画面には、報知内容を表示する領域２５０、ユーザＡが入手した売却対象のカードを表示する領域２５１、カードの購入を打診中の相手を表示する領域２５２、メッセージ送信領域２５３などが設けられる。領域２５０には、例えば「あなたが入手したカードの購入を仲間に打診しています。」というテキストが表示される。領域２５１には、ユーザＡが入手したカード２５６およびカードの情報２５７（選手名、所属チーム、ポジション、能力値等）が表示される。領域２５２には購入打診中の仲間のアバター、名前、レベル、チーム、リーダーに設定しているカード等が表示される。

メッセージ送信領域２５３には、購入打診中の仲間に送るためのメッセージ入力部２５４および送信ボタン２５５が表示される。ここで、ユーザがメッセージ入力部２５４に任意のメッセージを入力して送信ボタン２５５を押せば、ゲームサーバ１がそのメッセージを、仲間に届ける。なお、メッセージ送信領域２５３は省略することもできる。また、画面内の閉じるボタン２５８を押せば、報知画面を閉じて元のゲーム画面に戻ることができる。

その後、売却条件を提示された仲間がカードを購入する操作（例えば、図９の購入するボタン２３３を押す操作）を行えば（図２９のＳ７でＹＥＳ）、売買取引が成立し、ゲームサーバ１は、売却条件に従って、ユーザＡのカードと仲間のポイントとを交換する交換処理を実行する（Ｓ８）。この場合、ゲームサーバ１は、ユーザＡがゲームにアクセスしたときに、仲間との売買取引が成立した旨を報知する（Ｓ９）。

ここでユーザに報知する、最終的な売買成立（交換成立）の内容については、誰にどのようなオブジェクトを売却して、何ポイントを得たかについての情報を含む。このように、売買取引の成立後に取引相手の情報等を含む報知が行われることにより、ユーザは、自分のカードを購入してくれた仲間に対して、御礼のメッセージを送信する等の対応を素早く行うことができ、ユーザ間の交流促進にも寄与する。また、ゲームサーバ１は、売買（交換）成立の時間の情報をユーザに報知するようにしてもよい。ここで、売買成立の時間とは、売却条件の提示開始から仲間がその条件を了承するまでにかかった時間の情報である。売買成立の時間が短い場合、カードを購入した仲間がそのカードに大きな興味を示したと推測できる。また、いつも売買成立の時間が遅かったり、売買の成立に至らないことが多かったりする場合には、現在設定している自動売却条件の見直しを考えることができる。特に、後述するように、仲間に売却条件が提示されてからの経過時間に応じて、対価が変更される構成においては、売買成立の時間をユーザに報知することが好ましい。

一方、売却条件を提示された仲間がカードの購入を拒否する操作（例えば、図９の購入しないボタン２３４を押す操作）を行なうか（Ｓ１０でＹＥＳ）、あるいは売却条件の提示開始から（売却条件が提示可能となってから）仲間がカード購入に関する操作を行うことなく所定時間、例えば３時間が経過した場合（Ｓ１１でＹＥＳ）、売買取引は不成立となる（Ｓ１２）。この場合、ゲームサーバ１は、ユーザＡがゲームにアクセスしたときに、仲間との売買取引が成立しなかった旨を報知する（Ｓ１３）。また、この場合ユーザが入手したカードは、ユーザ自身の所有物となる。

以上のように、本実施の形態のゲーム管理装置は、ユーザに関係付けられた仲間（他のユーザ）を管理する仲間管理手段５１と、ユーザからの要求に応じて、取引対象の前記仲間の範囲および当該範囲内の仲間に提示するオブジェクトの売却条件を予め設定する設定手段５２と、前記売却条件が適用されるオブジェクトをユーザが入手した場合、前記仲間に当該オブジェクトの売却条件を自動的に提示する提示手段５３と、を備え、前記売却条件には、売却対象のオブジェクトおよび当該オブジェクトの購入に必要な対価の情報が含まれる構成である。

本実施の形態では、例えば、比較的希少価値が高いとされているカードであっても、ユーザが自分には不要と考える場合には、そのカードを仲間への売却対象として予め設定することができる。これにより、ユーザにとっては不要な（またはそれほど重要ではない）カードを単に売却したりプレゼントしたりするのではなく、ユーザが仲間に有償でそのカードを譲るための処理（売却条件の提示処理）が、ユーザの手間を掛けることなく自動的に実行されることになる。売却条件を提示された仲間にとっては、そのカードを入手できる機会を与えられるので、カード入手のバリエーションが広がる。また、お互いに仲間同士での売買取引が行われるので、これを通して、仲間同士の交流を深めることもできる。このように、本構成により、仲間同士で交流を持ちながら、手間をかけることなく不要なカード等を売却してポイント等に交換できる環境をユーザに提供することができる。また、親密度等によって仲間の範囲を定め、その範囲に応じた適切なオブジェクトの売却条件を設定することが可能となる。

ところで、図３０の画面では、売却条件が自動的に仲間に提示された後に、その仲間にユーザがメッセージを送信できる構成について説明したが、ユーザが予め任意のメッセージを設定できるようにしてもよい。例えば、図７、図１０〜図１５の自動売却条件設定画面において、図示しないメッセージ入力部を設ける。ユーザは、自動売却条件を指定すると共に、メッセージ入力部に任意のメッセージを入力した上で、設定ボタン２２７を押す。これにより、ユーザの端末装置３からは、入力したメッセージを含んだ条件設定要求がゲームサーバ１へ送信される。ゲームサーバ１の設定手段５２は、ユーザからの条件設定要求を受信し、ユーザが入力した売却条件およびメッセージを設定（登録）する。すなわち、ユーザＩＤと対応付けて、売却条件およびメッセージを、データベースサーバ２に記憶する。これにより、ゲームサーバ１は、仲間に売却条件を自動的に提示する際に、予め設定されているメッセージを、当該仲間に自動送信する。この構成により、ユーザは、予めメッセージを設定しておけば、手間を掛けることなく、仲間に売却条件が自動的に提示される毎に、その仲間にメッセージを送ることができる。

なお、売却条件が仲間に提示されるたびにいつも同じメッセージが送信されるのを回避するため、ユーザが予め複数のメッセージを設定できるようにしてもよい。この場合、ゲームサーバ１は、売却条件を仲間に提示する毎に、設定されている複数のメッセージからランダムに選択したメッセージを相手に送信する。あるいは、ゲームサーバ１は、設定されている複数のメッセージに所定の順番を付けて、自売却条件を仲間に提示する毎に、その順番に従って送信するメッセージを順次変更する。

ところで、ユーザが仲間の範囲を定めて、自動売却条件の設定を行っても、その範囲に含まれる仲間の中には、ゲームへの関心がかなり希薄になったり、ゲームを止めてしまったりする者もいる。あるいは、自動売却条件を設定した時点で、既にゲームを止めている者が仲間の範囲に含まれている可能性もある。そこで、一旦、自動売却条件が設定された仲間であっても、ゲームへの関心がかなり希薄又はゲームを止めた仲間を、対象から除外する構成について以下に説明する。この構成のゲームサーバ１は、図３１に示すように、除外手段５０を備えている。

除外手段５０は、ユーザが設定した仲間の範囲に含まれる者であっても、ゲームへのアクセス頻度が所定値以下、またはゲームへの非アクセス期間が所定期間以上になった者を、設定対象から自動的に除外する機能を有する。ここで、「仲間のゲームへのアクセス頻度が所定値以下」とは、所定期間（例えば先月１か月間、あるいは現在から遡る１か月間）の仲間のゲームへのアクセス日数が所定日数（例えば３日）以下となる場合が挙げられる。仲間のゲームへのアクセス頻度が所定値（３日／月）以下の場合、その仲間についてはゲームへの関心がかなり希薄である、またはゲームを止めてしまったと判断できる。なお、アクセス頻度に関する前記所定値は、「３日／月」に限定されるものではなく、例えば「７日／２か月」としてもよく、任意の値を設定できる。

また、「ゲームへの非アクセス期間が所定期間（例えば３０日間）以上」になった仲間についても、ゲームへの関心がかなり希薄である、またはゲームを止めてしまったと判断できる。ゲームへの非アクセス期間に関する前記所定期間も、３０日間に限定されるものではなく、例えば２週間としてもよく、任意の期間を設定できる。

なお、「ゲームへのアクセス頻度が所定値以下」、または「ゲームへの非アクセス期間が所定期間以上」の判断に際しては、自動プレゼントの設定が行われた時点以降の仲間のゲームへのアクセスを対象としてもよいが、それ以前のゲームへのアクセスを対象とすることもできる。これは、自動売却条件の設定が行われた時点で、既に、ゲームへの関心がかなり希薄になっていたり、ゲームを止めていたりする可能性もあるためである。

例えば、ゲームサーバ１は、毎日（または１週間に１回等でもよい）、決まった時刻（例えば午前０時）に、ユーザＡが設定した自動売却条件の提示対象となる仲間の範囲（図２２〜図２６参照）に含まれる仲間に対して、次の処理を実行する。すなわち、ゲームサーバ１は、前記仲間のアクセスログ（図１８参照）に基づいて、ゲームへのアクセス頻度が所定値以下、またはゲームへの非アクセス期間が所定期間以上になっている除外対象の仲間が存在するか否かを判断する。ここで、除外対象の仲間が存在する場合には、除外手段５０が、その仲間を、自動プレゼントの設定対象から自動的に除外する。例えば、除外手段５０は、除外対象の仲間に対する自動プレゼントの設定を、自動的に解除する。具体例を以下に説明する。

先ず、図２６に示す自動売却条件が設定されている場合を例に挙げて説明する。ユーザＩＤ＝００００１０（仲間Ｄ）が除外対象と判断された場合、除外手段５０は、当該仲間に対して設定されている自動売却条件を自動的に解除する（設定情報を消去する又は消去フラグを立てる）。また、仲間の範囲に含まれるユーザＩＤ＝０００００２（仲間Ｂ）およびユーザＩＤ＝０００００５（仲間Ｃ）のうち仲間Ｃのみが除外対象と判断された場合、除外手段５０は、仲間の範囲からユーザＩＤ＝０００００５のみを消去する（または消去フラグを立てる）。

次に、図２２に示す自動売却条件が設定されている場合を例に挙げて説明する。例えば、親密度≧３の仲間の範囲に含まれるユーザＩＤ＝００００１０（仲間Ｄ）が除外対象と判断された場合、除外手段５０は、当該仲間の範囲から、ユーザＩＤ＝００００１０を除外する。この場合、仲間の範囲は親密度によって定められているので、仲間の範囲から仲間Ｄを除外するために、除外手段５０は、例えば非対象者の情報としてユーザＩＤ＝００００１０をデータベースサーバ２に記憶し、仲間Ｄを売却条件提示の非対象者として管理する。また、図２３〜図２５に示すように仲間の範囲がレベル、ゲームへのアクセス頻度等によって定められている場合も同様である。

本構成により、ゲームへの関心がかなり希薄又はゲームを止めた仲間、すなわち売却条件を提示する価値の低い（又はない）仲間に対して、自動的に売却条件が提示されることを回避することができる。また、そのような仲間に対する設定解除操作をユーザが行う必要がなくなり、ユーザの操作の手間を省くことができる。

また、除外手段５０が、前述の除外対象の仲間を自動的に除外した場合、その旨をその理由と共にユーザに報知することが好ましい。例えば、ユーザＡの端末装置３がゲームにアクセスしたとき、ゲームサーバ１は、「仲間Ｄは３０日以上ゲームにアクセスしなかったため、自動売却の対象から除外しました。」等のメッセージを含む報知画面を生成し、ユーザＡの端末装置３へ送信する。

また、自動売却の設定対象となった仲間について、その仲間のゲーム情報（親密度、レベル、ゲームへのアクセス頻度等）が変動することにより、設定対象が変わる（その仲間が自動売却の設定対象から外れる、またはその仲間が含まれる仲間の範囲が変化して自動売却条件が変わる）ことがある。この場合、ゲームサーバ１は、ユーザにその旨の報知（アラート）を行う報知手段を備えていることが好ましい。この報知により、仲間のゲーム情報の変動に伴い、一旦設定した自動売却条件の対象が変わったことをユーザに認識させ、その仲間に対する自動売却条件を見直す機会を与えることができる。以下に、具体例を説明する。

例えば、図２２に示すように、「親密度≧３」の仲間の範囲に「自分のチーム以外のレア度４のカード」というカード条件を対応付けた自動売却条件を、ユーザＡが設定したとする。この自動売却条件が設定された当初は、「親密度３」の仲間Ｃが自動売却の設定対象であったが、仲間ＣがユーザＡとあまり交流しなかったこと等により、親密度が２に低下した場合を想定する。この場合、仲間Ｃは、「親密度≧３」の仲間の範囲から外れる。もしも、「親密度≦２」の仲間の範囲に対して自動売却条件が設定されていなかった場合、仲間Ｃは自動売却の設定対象から外れてしまうことになる。また、図２２に示すように「親密度≦２」の仲間の範囲に対して「自分のチーム以外のレア度３のカード」というカード条件が設定されている場合でも、仲間Ｃが「親密度≧３」から「親密度≦２」へ移ったことに伴って自動売却条件が変わってしまう。この場合、ゲームサーバ１の報知手段は、例えば「仲間Ｃとの親密度が２に低下したため、仲間Ｃは自動売却の対象から外れてしまいました（または、仲間Ｃに対する売却条件が変わってしまいました）。」というメッセージを表示する報知画面を生成し、ユーザＡの端末装置３に送信する。

また、上記報知の際、ゲームサーバ１は、（ａ）仲間Ｃに対して元の自動売却条件を適用する、（ｂ）仲間Ｃに対する自動売却条件を再設定する、（ｃ）仲間Ｃに対する自動売却を解除する、等の選択肢をユーザＡに提示してもよい。ユーザＡが前記（ａ）の選択肢を選んだ場合、ゲームサーバ１は、「親密度≧３」の仲間の範囲から外れたにも関わらず、仲間Ｃに対して元の自動売却条件「自分のチーム以外のレア度４のカード」をそのまま設定する。このように、元の自動売却条件をそのまま適用可能とする理由は、仲間との親密度（又は仲間のレベル等）が低くなった場合に、売却を止めてしまったり、提示するカードのレア度を下げたりするというのは行い難い場合もあるためである。また、ユーザＡが前記（ｂ）の選択肢を選んだ場合、例えば図１５の自動売却条件設定画面で、仲間の範囲として仲間Ｃのみが指定されている画面に遷移し、ユーザＡが仲間Ｃに対して任意の自動売却条件を再設定できるようにする。

上記の説明では、仲間の親密度が低下して自動売却の対象が変わる例を示したが、仲間の親密度が向上して自動売却の対象が変わる場合も同様である。また、自動売却の対象となった仲間のレベル、ゲームへのアクセス頻度等のゲーム情報が変動することにより、自動売却の対象が変わる場合も同様である。

ところで、前記の図２８および図２９のフローチャートでは、１人の仲間に対して売却条件を提示する処理例を示したが、以下には、複数の仲間に対して売却条件を提示する例について説明する。

本実施の形態の提示手段５３は、売却条件（交換条件）が適用されるカード（オブジェクト）をユーザが入手した場合であって、売却条件の提示対象となり得る仲間が複数存在する場合、売却条件を提示したある仲間との売買取引が所定時間以内に成立しなければ、別の仲間に売却条件を提示することを繰り返すことによって、前記複数の仲間に対して、順次、売却条件の提示を行う機能を有する。

すなわち、最初に売却条件の提示をした仲間から拒否されるか、所定時間（例えば３時間）以内の回答が無ければ、自動的に、次の仲間に売却条件の提示を行う。その後も、売買取引が所定時間以内に成立しなければ、売却条件の提示対象となる仲間を自動的に変えていく。勿論、ある仲間との売買取引が成立すれば、条件提示をしていない仲間が残っていても、売却条件の提示は打ち切られる。

ここで、提示手段５３は、売却条件を提示する仲間の人数を、所定人数（例えば３人）に制限することが好ましい。その理由は次のとおりである。すなわち、前述のとおり、仲間に売買取引の提示をしている間は、ユーザが入手したカードがユーザ自身のものになるのか（取引不成立）、仲間のものになるのか（取引成立）が不確定な状態となる。そのような不確定な期間が長時間継続することは、ユーザが入手したカードの使用が長時間制限されることになるため、好ましくない。そこで、売買取引が所定時間以内に成立しなければ、売却条件の提示対象となる仲間を一人ずつ変えていく構成の場合、売却条件を提示する仲間を所定人数、例えば３人に制限する。よって、売買取引の制限時間を１人当たり３時間以内とした場合、前記不確定な期間は９時間（＝３人×３時間）以内に抑えることができる。これにより、前記不確定な期間が長くなり過ぎることを効果的に防止することができる。

なお、売却条件を提示する仲間の所定人数は３人に限定されるものではなく、２人または４人以上であってもよい。

本構成を適用したゲームサーバ１による売却条件の提示処理の例を、図２８および図３２のフローチャートを参照しながら、以下に説明する。なお、既出のステップと同様のステップには同一の記号を付記し、その説明を省略する。

本実施の形態においても、基本的に、図２８のステップＳ１〜Ｓ６はそのまま適用できる。ステップＳ６の後、図３２のステップＳ７に移行する。この図３２は、図２９の変形例である。図３２では、売却条件を提示された仲間がカードの購入を拒否する操作を行なうか（Ｓ１０でＹＥＳ）、あるいは売却条件の提示開始から（売却条件が提示可能となってから）仲間がカード購入に関する操作を行うことなく所定時間、例えば３時間が経過した場合（Ｓ１１でＹＥＳ）、３人の仲間に売買取引を打診したか否かが判断される（Ｓ２１）。このステップＳ２１でＮＯならば、ゲームサーバ１は、売却条件を提示する他の仲間を決定し（Ｓ２２）、その仲間に売却を提示する（Ｓ２３）。すなわち、ある仲間との売買取引が所定時間以内に成立しなければ、売却条件の提示対象となる仲間を変更する。これを、図３２の例では３人の仲間に対して繰り返す。

このように、売却（交換）対象のオブジェクトを、仲間に順次提示していく場合には、取引の状況に変化があった場合、ゲームサーバ１がユーザにその状況を報知するようにしてもよい。例えば、最初に売買取引を打診した仲間がカードの購入を拒否するか、あるいは所定時間以内に返答がない場合には、その旨、および次に誰に売却条件を提示しているか等の情報をユーザに報知する。また、２人目の仲間に打診した売買取引が成立せずに、売却条件の提示が３人目の仲間に移った場合も同様に報知する。

３人の仲間に売買取引を打診したにも関わらず、だれも提示したカードを購入しなかった場合、売買取引は不成立となり（Ｓ１２）、ゲームサーバ１は、ユーザＡに仲間との売買取引が成立しなかった旨を報知する（Ｓ１３）。この場合、ユーザが入手したカードは、ユーザ自身の所有物となる。

一方、例えば最初に売買取引を打診した仲間がカードを購入すれば（Ｓ７でＹＥＳ）、その時点で売買取引が成立し、２人目の仲間への売買取引の打診は行われない。また、最初の仲間との売買取引が成立しなかったが、２人目の仲間との間で売買取引が成立すれば、３人目の仲間への売買取引の打診は行われない。

図３２では、売買取引を打診する仲間を最大３人に制限しているが、制限人数はこれに限定されない。また、打診する人数に制限を設けることなく、売却条件の提示対象となり得る仲間全員に対して、１人ずつ打診してもよい。

本構成のように、売却条件の提示を行う仲間を一人ずつ変えて、複数の仲間に売却条件の提示を行う方法の他に、後述するように、複数の仲間に対して、同時に、売却条件の提示を行う方法もある。複数の仲間に対して、同時に、交換条件の提示を行った場合、売買取引の成立は早い者勝ちとなる。これに対して、本構成の場合、売却条件の提示を受けた仲間は、所定時間以内であれば自分だけが売買取引を行うことができるので、他の仲間が先に取引を成立させてしまうことはなく、安心して売買取引を行うことができる。

次に、売買取引を打診する仲間の順番を親密度に基づいて決定する構成について説明する。この構成のゲームサーバ１は、図３３に示すように、前述の親密度付与手段５６を備えており、提示手段５３は、売却条件の提示対象となり得る仲間が複数存在する場合に、親密度の高い仲間から順に、売却条件の提示を行う機能を有する。

例えば、図２８のフローチャートのステップＳ４では、売却条件の提示対象となり得る仲間のうち、最も親密度の高い仲間を、売却条件の提示を行う仲間として決定する。また、図３２のステップＳ２２では、親密度が２番目または３番目に高い仲間を、売却条件の提示を行う仲間として決定する。

この構成では、親密度の高い仲間から順に、売却条件の提示が行われるので、親密度の高い仲間ほど、売買取引を行う機会が増え、交流を深めることもできる。また、相手との親密度が高いほど売却条件の提示を受け易くなり、仲間からカードを入手できる機会が増える。

次に、経過時間に応じて、対価を変更する構成について説明する。この構成のゲームサーバ１は、図３４に示すように、対価変更手段５５をさらに備えている。この対価変更手段５５は、仲間に売却条件が提示されてからの経過時間に応じて、前記対価を変更する機能を有する。ここで、仲間に売却条件が提示されてからの経過時間とは、ゲームにアクセスしている仲間に、実際に、売却条件が提示されたときを基準として、その後の経過時間とすることができる。あるいは、売却条件を仲間に提示可能ではあるが、その仲間がゲームにアクセスしていないために、実際にはその売却条件が仲間に提示されていない場合において、売却条件が提示可能となったときを基準として、その後の経過時間に応じて、前記対価を変更してもよい。

例えば、対価変更手段５５は、仲間に売却条件が提示されてから所定時間が経過する毎に、対価となるポイントを大きくする。具体例としては、売却条件が提示されてからの経過時間が１時間以内の対価を「５００ポイント」、１時間経過後から２時間以内の対価を「１０００ポイント」、２時間経過後から３時間以内の対価を「１５００ポイント」とする。ゲームサーバ１は、対価が変更される毎に、変更後の対価を仲間に提示する。この場合、売却条件の提示を受けた仲間としては、早めに了承した方が安価にカードを入手できる。

なお、これは一例であり、時間経過と対価との関係は任意に定めることができる。例えば、対価を経過時間ｔの関数ｆ（ｔ）として表し、時間経過に応じて連続的に対価を変更するようにしてもよい。また、対価がポイントではなくアイテム（回復アイテム等）の場合、アイテムの個数を変更するようにしてもよい。例えば、交換条件が提示されてからの経過時間が１時間以内の対価を「回復アイテム１０個」、１時間経過後から２時間以内の対価を「回復アイテム１５個」、２時間経過後から３時間以内の対価を「回復アイテム２０個」とする。

また、仲間に売却条件が提示されてから所定時間が経過する毎に、対価となるポイント等を小さくしてもよい。本構成により、売却条件（交換条件）の提示を受けた仲間にとっては、了承のタイミングが重要となり、これにより興趣性を高めることができる。

また、前述した、売却条件を提示した仲間との売買取引が所定時間以内に成立しなければ、別の仲間に売却条件を提示することを繰り返すことによって、複数の仲間に対して、順次、売却条件の提示を行う構成において、対価変更手段５５は、次のようにして対価を変更することが好ましい。すなわち、対価変更手段５５は、仲間との売買取引（交換取引）が成立せず、取引の対象が次の仲間に移る毎に、売却条件である、カードを購入するのに必要な対価を、順次低下させる機能を有する。

例えば、最初に売却条件の提示をする仲間に対しては、カードの購入に必要な対価を５００ポイント（または１時間以内：５００ポイント、１〜２時間：１０００ポイント、２〜３時間：１５００ポイント）とする。この売買取引が成立せず、取引の対象が２人目の仲間に移った場合、対価を３００ポイント（または１時間以内：３００ポイント、１〜２時間：６００ポイント、２〜３時間：９００ポイント）にする。さらに、この売買取引が成立せず、取引の対象が３人目の仲間に移った場合、対価を２００ポイント（または１時間以内：２００ポイント、１〜２時間：４００ポイント、２〜３時間：６００ポイント）とする。以下、同様にして取引の対象が次の仲間に移る毎に、対価を低下させる。

このように、売買取引が成立しなければ、取引の対象が別の仲間に移る毎に対価を順次低下させることにより、売買取引を成立させ易くすることができる。ユーザにとっては、カードが売却できずに売れ残るよりは、対価が下がっても売却できる方がよいと考えることもある。例えば、そのように考えるユーザが、本構成による対価の低下機能を予め有効化した場合にのみ（すなわち、ユーザの端末装置３で有効化の設定操作を行っている場合のみ）、本構成の対価の自動低下処理が実行されるようにしてもよい。勿論、そのような有効化の設定がなくとも、本構成の対価の自動低下処理が実行されるものとしてもよい。

次に、複数の仲間に売却条件を提示する場合、同時に複数人に一括して提示する構成について説明する。この構成の提示手段５３は、売却条件が適用されるカードをユーザが入手した場合であって、売却条件の提示対象となり得る仲間が複数存在する場合、当該複数の仲間に対して、同時に、前記売却条件の提示を行う機能を有する。

本構成を適用したゲームサーバ１による売却条件の提示処理の例を、図３５のフローチャートを参照しながら、以下に説明する。なお、既出のステップと同様のステップには同一の記号を付記し、適宜その説明を省略する。

ユーザＡがゲーム内で新たにカードを入手した場合（Ｓ１でＹＥＳ）、ゲームサーバ１は、ユーザＡが予め設定している自動売却条件を取得し（Ｓ２）、そのカードが自動売却条件の適用対象であるか否かを判断する（Ｓ３）。ここで、そのカードが自動売却条件の適用対象であった場合（Ｓ３でＹＥＳ）、ゲームサーバ１は、売却条件の提示対象の全ての仲間に対して、同時に、売却条件の提示を行う（Ｓ３１）。例えば、図２１に例示するように、仲間の範囲を定めずに全ての仲間を対象とした自動売却条件が設定されている場合、ゲームサーバ１は、全ての仲間に対して一斉に売却条件を提示する。また、図２２ないし図２６に例示するように、仲間の範囲を定めて自動売却条件が設定されている場合、その範囲内の全ての仲間に対して一斉に売却条件を提示する。例えば、ゲームサーバ１は、対象となる全ての仲間に対して、図９の画面データを送信する。また、ゲームサーバ１は、ユーザＡのユーザＩＤと対応付けて、複数の仲間を対象として、売却条件提示管理情報（図２７参照）を、データベースサーバ２に記憶する。

なお、ゲームサーバ１は、対象となる全ての仲間に対して、売却条件を提示できる状態になるが、ゲームにアクセスしていない仲間に対しては、売却条件を提示する画面データを送信できないので、実質的には、アクセスしている仲間に対して、売却条件が提示されることになる。ゲームにアクセスしていない仲間であっても、売買取引の有効期間内（例えば売却条件の提示開始から３時間以内）にアクセスすれば、売却条件が提示される。ただし、売買取引の有効期間が経過していなくても、売却条件を提示された仲間の１人がカードを購入してしまうと、その時点で売買取引は終了してしまう。

さらに、ゲームサーバ１は、ユーザＡに対して、入手したカードの購入を、対象となる複数の仲間に打診中である旨を報知する（Ｓ６）。

その後、売却条件を提示された仲間の１人が最初にカードを購入する操作（例えば、図９の購入するボタン２３３を押す操作）を行えば（３２でＹＥＳ）、売買取引が成立し、ゲームサーバ１は、売却条件に従って、ユーザＡのカードとその仲間のポイントとを交換する交換処理を実行する（Ｓ８）。この場合、ゲームサーバ１は、ユーザＡがゲームにアクセスしたときに、仲間との売買取引が成立した旨を報知する（Ｓ９）。これにより、全ての仲間との売買取引は終了となるので、提示されたカードを購入していない仲間は、最早、そのカードを購入することはできない。

一方、売却条件を提示された何れの仲間も、カードの購入を購入する操作を行うことなく所定の売買取引の有効期間、例えば３時間が経過した場合（Ｓ３３でＹＥＳ）、売買取引は不成立となる（Ｓ１２）。この場合、ゲームサーバ１は、ユーザＡがゲームにアクセスしたときに、仲間との売買取引が成立しなかった旨を報知する（Ｓ１３）。また、この場合ユーザが入手したカードは、ユーザ自身の所有物となる。

この構成によれば、売却条件の提示対象の複数の仲間に対して、同時に、売却条件の提示を行うので、売買取引が所定時間以内に成立しなければ、売却条件の提示対象となる仲間を一人ずつ変えていく構成と比較して、取引の成否が分からない不確定な期間を短くすることができる。また、複数の仲間を対象に一斉に売却条件を提示し、売買取引の成立を早い者勝ちとするので、売買取引の成立の可能性を高めることができる。

また、このように複数の仲間に対して、同時に、売却条件の提示を行う構成においては、対価変更手段５５が、売却条件の提示が開始されてからの経過時間に応じて、売却条件である、カードの購入に必要な対価を低下させるようにしてもよい。

例えば、複数の仲間に同時にカードの売却条件が提示されてからの経過時間が１時間以内の対価を「１５００ポイント」、１時間経過後から２時間以内の対価を「１０００ポイント」、２時間経過後から３時間以内の対価を「５００ポイント」とする。ゲームサーバ１は、対価が変更される毎に、変更後の対価を各仲間に提示する。

なお、これは一例であり、時間経過と対価との関係は任意に定めることができる。例えば、対価を経過時間ｔの関数ｆ（ｔ）として表し、時間経過に応じて連続的に対価が減少するようにしてもよい。また、対価がポイントではなくアイテム（回復アイテム等）の場合、アイテムの個数を変更するようにしてもよい。例えば、交換条件が提示されてからの経過時間が１時間以内の対価を「回復アイテム２０個」、１時間経過後から２時間以内の対価を「回復アイテム１５個」、２時間経過後から３時間以内の対価を「回復アイテム１０個」とする。

複数の仲間に同時にカードの売却条件を提示する場合、前述のように、そのカードを入手できる仲間は、最も早くその売却条件を了承した一人だけである。よって、売却条件の提示を受けた各仲間は、提示されたカードが欲しければ、早めに売却条件を了承しなければ、他の仲間に先を越されてしまう。よって、各仲間は、対価が高くても早めに了承するか、時間をおいて安価になってから了承するかを検討することになり、この点で興趣性が増加する。

次に、仲間の範囲としてユーザが特定の仲間を指定した場合、ゲームサーバ１がその仲間に対する自動売却条件を自動的に設定する構成について説明する。この構成のゲームサーバ１は、図３６に示すように、自動設定手段５７を備えている。この自動設定手段５７は、ユーザが指定した個人を特定する情報に基づいて、仲間の範囲として特定の仲間が設定された場合、当該特定の仲間のゲーム情報に基づいて（又は、当該特定の仲間および前記ユーザのゲーム情報に基づいて）、当該特定の仲間に提示する売却条件を自動的に設定する機能を有する。

ここでは、図３７に示す自動売却条件の自動設定画面において、ユーザが特定の仲間を選択するだけで、自動設定手段５７が当該仲間に提示する売却条件を自動設定する例について説明する。図３７の画面には、仲間指定領域２６１が設けられている。この仲間指定領域２６１の仲間リストボタン２４７を押せば、図１６の仲間リスト画面に遷移し、ここで特定の仲間を指定すれば、ユーザの端末装置３からはその操作情報（指定された仲間のユーザＩＤを含む）がゲームサーバ１へ送信される。この操作情報に応じて、自動設定手段５７は指定された仲間のゲーム情報をデータベースサーバ２から取得し、仲間のゲーム情報に基づいてカードの売却条件を自動的に設定する。

例えば、自動設定手段５７は、指定された仲間のチームの選手で所定のレア度（レア度３、レア度４等）という売却対象のカードの条件を自動的に設定する。この場合、自動設定手段５７は、仲間のレベル、仲間の親密度、仲間のゲームへのアクセス頻度等の仲間のゲーム情報に基づいて、適切な条件を設定することができる。例えば、その仲間のレベル、親密度またはゲームへのアクセス頻度が閾値以上の場合には、売却対象のカードの条件をレア度４とし、閾値未満の場合はレア度３とする。また、その対価は、例えば売却対象のカードと等価なポイントとする。

あるいは指定された仲間が設定しているチームオーダ（カードのデッキ）において弱いポジションがある（所定のレア度以上または所定の能力値以上の選手がいないポジションがある）場合には、そのポジションの選手カードで所定のレア度（例えばレア度４）という売却対象のカードの条件を自動的に設定する。一例を挙げると、仲間のチームオーダに含まれる投手キャラクタにレア度４以上のものがない場合、仲間のチームの投手カードでレア度４以上という売却対象のカードの条件を自動設定する。また、その対価は、例えば売却対象のカードと等価なポイントとする。

ところで、例えば、ユーザと仲間とが同じチームの場合、ユーザは相手のチーム（＝自分のチーム）のカードを売却したくない場合が想定される。よって、この場合、ユーザと同じチームの仲間は、自動設定手段５７による自動設定の対象から除外してもよい。

あるいは、ユーザと仲間とが同じチームの場合、ユーザが所有していないカードについては、ユーザ自身が欲しい場合が想定される。よって、ユーザと仲間とが同じチームの場合には、仲間に提示するカードの条件を、ユーザが既に所有しているカードに限定してもよい。また、前述のように、売却対象のカードの条件（レア度等）は、提示対象の仲間のレベルに応じて決定（初心者レベルであればレア度３、上位レベルであればレア度４等）することができるが、ユーザ自身のレベルも考慮して決定することが好ましい。なぜならば、ユーザが下位レベルであれば、レア度の高いカードを入手した場合、仲間に売却したくないと考えることが想定されるからである。逆に、ユーザのレベルが非常に高ければ、相手が初心者であってもレア度の高いカードを売却してもよいと考えることが想定されるからである。そこで、ユーザが仲間の範囲として特定の仲間を指定すれば、自動設定手段が、当該仲間のゲーム情報および当該ユーザのゲーム情報の両方に基づいて、当該仲間に提示するカードの売却条件を自動的に設定するようにしてもよい。

自動設定手段５７は、自動設定した自動売却条件に関する情報を、ユーザＩＤと対応付けてデータベースサーバ２に記憶する。

自動売却条件が自動設定された場合、ゲームサーバ１は、例えば図３８に例示する画面を端末装置３へ送信し、自動設定された条件をユーザに通知することが好ましい。図３８の画面の仲間指定領域２６１には、ユーザによって指定された仲間の情報２６２（アバター、名前、レベル、チーム等）が表示される。なお、図示しない仲間変更ボタンを設けて、指定する仲間を変更することができるようにしてもよい。また、画面には、自動設定された売却条件に関する情報の表示領域２６３が設けられる。この表示領域２６３には、自動設定されたカードの売却条件２６４、了解ボタン２６５、条件変更ボタン２６６等が表示される。図３８では、仲間Ｂを指定したことにより、売却対象のカード「仲間のチームの投手カード（レア度４）」、その対価「５００強化ポイント」というカードの売却条件２６４が自動設定された例を示している。ここで了解ボタン２６５を押せば、図３８の画面が閉じられ、図４のメイン画面に遷移する、または図３７の画面に戻る。一方、ユーザが、自動設定された条件を変更したいと考えた場合、条件変更ボタン２６６を押すことにより、任意の条件に変更することもできる。

自動設定手段５７を備えた構成により、ユーザが特定の仲間を指定するだけで、自動設定手段５７がその仲間のゲーム情報（およびユーザ自身のゲーム情報）を分析し、適切なカードの売却条件までもが自動的に設定されるので、ユーザの操作負担を軽減することができる。

次に、ゲームサーバ１が、売却相手（オブジェクトの交換相手）の候補者となる仲間をユーザに報知する構成について説明する。この構成のゲームサーバ１は、図３９に示すように、候補者報知手段５８を備えている。この候補者報知手段５８は、ユーザに関係付けられた仲間のゲーム情報（例えば、プレゼント履歴、交流履歴等）に基づいて、売却相手の候補者となる仲間を抽出してユーザに報知する機能を有する。

一例を挙げると、ユーザに対して頻繁にカードを売却してくれたり、挨拶、プレゼント、メッセージ等を送ってくれたりする仲間を売却相手の候補者として抽出し、ユーザのゲーム画面に表示する。また、その中でも、最近（例えば、直近の２週間）よくユーザに対してアクセス（挨拶等）してくれる仲間を優先して売却相手の候補者として抽出することが好ましい。かつてはよく交流していたが、現在は殆ど交流していない仲間や、途中でゲームを止めてしまった仲間もいるからである。

売却相手の候補者を抽出する処理例を次に示す。ゲームサーバ１は、現在から遡る所定期間（例えば２週間）に、所定回数（例えば、１０回）以上、ユーザに対して交流を行った仲間を、売却相手の候補者として抽出する。ここで、交流には、カードの売買、挨拶、メッセージ送信、プレゼント、対戦協力、チャットなどを含めることができる。また、これに限らず、ゲームの種類や内容に応じて様々な交流を適用できる。図１８に示すように、各ユーザのゲーム情報としての交流の履歴は、ユーザＩＤと対応付けてデータベースサーバ２に記憶されている。よって、ユーザの仲間の交流履歴に基づいて、現在から遡る所定期間内に、仲間がユーザに対して、何回、交流を行ったかが分かる。

図４０に、売却相手の候補者を報知する画面例を示す。この画面は、例えば、図１４または図３７の自動売却条件を設定するための画面で、仲間リストボタン２４７を押した後に表示される仲間リスト画面である。なお、自動売却条件を設定する場合だけではなく、ユーザが手動で仲間にカードを売却する操作を行う場合にも、図４０の仲間リストを表示してもよい。

図４０の仲間リストでは、ゲームサーバ１が抽出した売却相手の候補者に対して、「候補者」のラベル２７１を表示してユーザに報知する。この例では、現在から遡る２週間以内に、１０回以上、ユーザに挨拶等の交流をした仲間に対して、前記ラベル２７１が表示されている。また、仲間リストには、現在から遡る所定期間（例えば２週間）に、仲間がユーザに対して交流を行った回数の情報２７２が表示される。この回数の情報２７２の表示は、省略することもできる。また、仲間リストの表示の優先度に関し、ユーザに対して交流を行った回数が多い仲間ほど優先度を高くする（上位に表示される）ようにすることが好ましい。

ユーザに対して、頻繁に、カードを安く売却してくれたり、挨拶、プレゼント等してくれたりする仲間がいても、いざその仲間を自動売却の対象となる特定の仲間として指定しようとしても、ユーザがその仲間の名前等を思い出せないこともある。しかし、本構成により、よく交流してくれる仲間等が売却相手の候補者として報知されることにより、ユーザは円滑に特定の仲間を指定することができるようになる。

次に、自動売却が行われる期間を限定できる構成について説明する。前述したように、一旦、自動売却が設定された仲間であっても、ゲームへの関心がかなり希薄又はゲームを止めた仲間を、自動売却の対象から除外する構成をとることができるが、これ以外に、下記のような構成とすることもできる。すなわち、ユーザからの要求に基づいて自動売却ト条件が設定された後、延々と売却条件を自動的に提示するのではなく、自動売却条件が設定されてから所定期間（例えば１週間、１か月等）のみ、条件を満たす対象カードの入手時に売却条件の提示処理が実行されるよう限定するのである。これによって、マンネリ感を無くすことができる。この構成のゲームサーバ１は、自動売却条件設定後、予め定められた所定期間（自動売却期間）が経過すれば、自動売却条件の設定を自動的に解除する。ここで、自動売却期間は、ユーザが任意の期間を指定することができるようにしてもよいし、ゲームサーバ１において予め初期設定されているデフォルトの期間を使用することもできる。例えば、ユーザが自動売却条件を設定する際に、自動売却期間を１週間等に限定する操作を行えば、その操作に応じてゲームサーバ１が、自動売却条件の設定日時、自動売却期間（または自動売却の解除予定日時）等の情報を、ユーザＩＤと対応付けて記憶装置（データベースサーバ２等）に記憶し、自動売却期間を管理する。あるいは、ユーザが自動売却期間を限定する操作を行わなくとも、ゲームサーバ１が自動売却期間を自動的に設定し、その期間の経過後に、自動売却条件の設定を自動的に解除するようにしてもよい。

自動売却が行われる期間を限定するか否かをユーザが任意に設定できる場合、次のこともできる。すなわち、ある仲間の範囲に対する自動売却条件については自動売却が行われる期間を限定し、別の仲間の範囲に対する自動売却条件については自動売却が行われる期間を限定しないということも可能である。また、ある仲間の範囲に対する自動売却条件については自動売却期間を１週間に限定し、別の仲間の範囲に対する自動売却条件については自動売却期間を１か月に限定するということも可能である。

また、自動売却期間の経過により自動売却条件の設定が解除された場合、ゲームサーバ１がその旨をユーザに報知し、ユーザに自動売却期間の再設定（実質的な自動売却期間の延長）を行うか否かを問い合わせてもよい。なお、上記の構成は、前述した、仲間のアクセス日数やアクセス頻度に基づき自動売却を解除する構成と併用してもよい。すなわち、本構成のように、基本的には１か月経過すれば自動売却は解除されるものとするが、その１か月が経過するまでの間で、売却相手（売却条件の提示対象）の仲間のゲームへのアクセスが例えば２週間ない、といった場合には１か月を待たずに、その仲間に対する自動売却条件の設定を解除してもよい。つまり、自動売却条件の固定的な解除期間（前記自動売却期間）を設けつつ、仲間のアクセス頻度を優先的に見て解除の判断を行うのである。

〔ゲームシステムの他の構成例〕
前述の各実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各ユーザの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであり、サーバ（ゲームサーバ１およびデータベースサーバ２）によってゲーム管理装置を構成する例である。この構成は、前述のように、ブラウザゲーム、ソーシャルゲーム、クラウドゲーミング等のサービスをユーザに提供するのに適した構成であるが、ゲーム管理装置の構成はこれに限定されない。

例えば、ゲームサーバ１が、各ユーザのゲーム情報を管理し、ゲーム内でのユーザ間の交流等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置側にて行われるゲームシステムにも適用できる。

すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置が、インターネット通信、無線ＬＡＮ通信、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信、または有線ＬＡＮ通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。

そして、サーバと端末装置とは互いに通信して各種データの送受が可能であり、共にＣＰＵ、ＲＯＭ、ＲＡＭ、補助記憶装置、通信制御部等を備えた情報処理装置（コンピュータ）であって、同様のハード構成を有する。よって、サーバと端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、サーバ又は端末装置の何れか一方が備えていればよい。すなわち、ゲーム管理装置は、互いに通信して各種データの送受を行うサーバおよび端末装置に設けられる構成とすることができ、前述の実施の形態と同様の作用効果を奏する。

例えば、図２０ではゲームサーバ１が、仲間管理手段５１、設定手段５２、提示手段５３および交換手段５４を備えていたが、図４１に例示するように、各手段の機能をサーバおよび端末装置の何れかに持たせることが可能である。ここで、図４１に示すサーバのハード構成は、図２に示したゲームサーバ１と同様であり、端末装置のハード構成は、図３に示した端末装置３と同様である。図４１には、サーバ１０１に仲間管理手段５１を設けると共に、端末装置３０１に設定手段５２、提示手段５３および交換手段５４を設ける構成例を示している。なお、図４１はゲームシステムの構成の一例であり、他の構成も可能である。

また、図４２に示すように、端末装置３０１が、仲間管理手段５１、設定手段５２、提示手段５３および交換手段５４を備えている構成とすることもできる。すなわち、ゲーム管理装置をゲーム端末である端末装置３０１それ自体に実装することができ、この場合も前述の実施の形態と同様の作用効果を奏する。この場合、サーバ１０１が、各ユーザのゲーム情報を管理したり、端末装置３０１間で行われる挨拶やメッセージの送受等のサービスをユーザに提供したりするが、その他の処理は全て端末装置３０１側で実行されるようにすることができる。あるいは、各ユーザのゲーム情報の管理も、各ユーザの端末装置３０１側で行うこともできる。

また、前述の除外手段５０、対価変更手段５５、親密度付与手段５６、自動設定手段５７、候補者報知手段５８等についても、サーバ側だけではなく、端末装置（ゲーム端末）側に設けることもできる。

〔その他の実施の形態〕
前記の実施の形態では、ユーザと関連付けがなされている他のユーザを仲間とする例を示したが、ユーザと関連付けがなされている他のユーザであれば、仲間という関係でなくても本発明を適用できる。

また、前記の実施の形態では、オブジェクトとして主にカードを例示したが、オブジェクトには、ゲーム内の様々なキャラクタやアイテム等が含まれる。例えば、キャラクタに装着される装備品、回復アイテム、強化アイテム、魔法アイテム等もオブジェクトに含まれる。

また、前記の実施の形態では、「オブジェクトの交換」として、主に、オブジェクトをゲーム内通貨やポイントと交換する「売却」を例示したが、オブジェクトを他のオブジェクトと交換する「物々交換」であってもよい。「物々交換」の場合、交換対象のオブジェクトの対価がゲーム内通貨やポイントではなく、アイテム等のオブジェクトとなるだけであり、基本的には「売却」と同様である。

また、予め設定した交換条件が適用されるオブジェクトをユーザが入手し、かつ、そのオブジェクトに関する他のユーザとの交換取引が成立した場合に、ゲーム管理装置が、当該ユーザに特典を付与する特典付与手段を備えている構成としてもよい。ここで、特典については、例えば、ゲーム内通貨やポイントの付与、アイテムの付与、キャラクタの能力向上、レアアイテムの抽選確率の向上等、ゲームの種類、内容に応じた様々な特典が適用できる。

この構成により、ユーザに対して、他のユーザとの交換取引を積極的に行おうとする動機付けを与えることができる。また、交換取引の成立により特典が得られるので、ユーザによって取引が成立し易い交換条件（例えば、対価を安くする等の条件）が設定され易くなる。これにより、交換条件を提示された他のユーザにとっても、交換取引が魅力的なものとなり、交換取引成立の可能性が高まる。本構成により、交換取引を通して、ユーザ間の交流を促進することができ、ゲームの活性化に繋げることができる。

また、予め設定した交換条件が適用されるオブジェクトをユーザが入手し、かつ、そのオブジェクトに関する他のユーザとの交換取引が成立した場合に、ゲーム管理装置が、当該他のユーザに特典を付与する特典付与手段を備えている構成としてもよい。すなわち、交換条件を提示された他のユーザが、その条件を了承して交換取引を成立させれば、当該他のユーザに特典が付与される。この構成により、交換条件を提示された他のユーザにとっては、それを了承すれば特典が得られるので、交換取引が益々魅力的なものとなり、交換取引成立の可能性がより高まる。本構成により、交換取引を通して、ユーザ間の交流を促進することができ、ゲームの活性化に繋げることができる。

なお、予め設定した交換条件が適用されるオブジェクトをユーザが入手し、かつ、そのオブジェクトに関する他のユーザとの交換取引が成立した場合に、ユーザのみに特典を付与する構成、他のユーザのみに特典を付与する構成、ユーザおよび他のユーザの両方に特典を付与する構成の何れを採用してもよい。

また、ユーザが他のユーザ（仲間等）の範囲を定めて、オブジェクトの交換条件を設定できる構成において、ユーザが設定できる他のユーザについては、ユーザが過去にプレゼントをもらった他のユーザの中から選択する必要がある構成としてもよい。すなわち、ゲーム管理装置の設定手段５２は、ユーザからの要求に応じて他のユーザの範囲を設定する場合に、その範囲に含めることができる他のユーザを、ユーザが過去にプレゼントをもらった他のユーザに限定する。

例えば、図１４または図３７の自動売却条件を設定するための画面で、ユーザが仲間リストボタン２４７を押した後に表示される仲間リスト画面（図１６または図４０参照）には、ユーザにプレゼントを贈ったことのある仲間のみがゲームサーバ１によって抽出されて表示されるようにする。この仲間リスト画面でユーザが仲間を選択すれば、仲間の範囲（他のユーザの範囲）に含まれる者を、ユーザが過去にプレゼントをもらった仲間に限定することができる。ゲームサーバ１は、図１８に例示するユーザ情報データベースにおいて、各ユーザの交流履歴として、プレゼントを贈った相手の情報等を記録しており、ユーザが誰にいつプレゼントを贈ったかを管理している。この情報に基づいて、ゲームサーバ１は、ユーザにプレゼントを贈ったことのある仲間を抽出することができる。なお、前記プレゼントの期間を所定期間に限定し、ユーザは、例えば過去１か月間にプレゼントをもらった他のユーザの中から、オブジェクトの交換条件を設定する他のユーザを選択する必要があるものとしてもよい。

本構成によれば、プレゼントを切っ掛けとして、プレゼントを贈ってくれた相手にオブジェクトの交換条件を設定できるようになるので、プレゼントの促進にも寄与する。

あるいは、ユーザが他のユーザ（仲間等）の範囲を定めて、オブジェクトの交換条件を設定できる構成において、ユーザが設定できる他のユーザについては、ユーザが過去にプレゼントをもらった、または交換条件を提示してもらった、他のユーザの中から選択する必要がある構成としてもよい。すなわち、ゲーム管理装置の設定手段５２は、ユーザからの要求に応じて他のユーザの範囲を設定する場合に、その範囲に含めることができる他のユーザを、ユーザが過去にプレゼントをもらった、または交換条件を提示してもらった、他のユーザに限定する。これは、交換条件の提示（有償譲渡の申し出）を、プレゼント（無償譲渡）と同様に扱うものである。ゲームサーバ１は、図２７に例示するように、データベースサーバ２に仲間（他のユーザ）への売却条件提示管理情報を記憶しており、この情報に基づいて、ユーザが過去に交換条件を提示してもらった他のユーザを抽出することが可能であり、プレゼントの場合と同様の処理が可能である。前記と同様に、売却条件提示の期間を所定期間に限定してもよい。

また、各種情報を記憶装置に記憶する記憶制御機能を有する構成（ユーザ情報記憶制御手段６０など）に関し、記憶装置そのものについては当該構成に含まれないので、ゲーム管理装置（またはゲームシステム）の内外を問わず、どこに設置されていてもよい。例えば、記憶装置は、ゲームサーバ１が有するＲＡＭ１３や補助記憶装置１４、データベースサーバ２、端末装置３が有するＲＡＭ３３や補助記憶装置３９、あるいはゲーム管理装置や端末装置とは別構成のファイルサーバ（オンラインストレージ）等であってもよい。

また、前述の各実施の形態で説明した各構成は、適宜組み合わせて適用することができる。

また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてサーバ、端末装置（ゲーム端末）のＣＰＵにより実行される。また、プログラムをサーバ等に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。

１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
４ ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
５０ 除外手段
５１ 仲間管理手段（管理手段）
５２ 設定手段
５３ 提示手段
５４ 交換手段
５５ 対価変更手段
５６ 親密度付与手段
５７ 自動設定手段
５８ 候補者報知手段
１０１ サーバ（ゲーム管理装置、ゲームシステム）
３０１ 端末装置（ゲーム管理装置、ゲームシステム）

Claims (15)

1. ゲームを管理するゲーム管理装置であって、
   ユーザに関係付けられた他のユーザを管理する管理手段と、
   ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定手段と、
   前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示手段と、を備えているゲーム管理装置。
2. 前記設定手段は、ユーザからの要求に応じて、前記他のユーザの範囲および当該範囲内の他のユーザに提示するオブジェクトの交換条件を予め設定し、
   前記提示手段は、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記範囲内の他のユーザに、当該オブジェクトの交換条件を提示する請求項１に記載のゲーム管理装置。
3. 前記交換条件には、交換対象のオブジェクトおよび当該オブジェクトとの交換に必要な対価の情報が含まれる請求項１または２に記載のゲーム管理装置。
4. 前記交換条件が提示されてからの経過時間に応じて、前記対価を変更する対価変更手段をさらに備えている請求項３に記載のゲーム管理装置。
5. 前記提示手段は、前記交換条件が適用されるオブジェクトをユーザが入手した場合であって、前記交換条件の提示対象となり得る他のユーザが複数存在する場合、前記交換条件を提示した他のユーザとの交換取引が所定時間以内に成立しなければ、別の他のユーザに前記交換条件を提示することを繰り返すことによって、前記複数の他のユーザに対して、順次、前記交換条件の提示を行う請求項１または２に記載のゲーム管理装置。
6. 関係付けられた２人のユーザに対して親密度を付与する親密度付与手段をさらに備え、
   前記提示手段は、親密度の高い前記他のユーザから順に、前記交換条件の提示を行う請求項５に記載のゲーム管理装置。
7. 他のユーザとの交換取引が成立せず、交換取引の対象が次の他のユーザに移る毎に、交換条件である、オブジェクトとの交換に必要な対価を順次低下させる対価変更手段をさらに備えている請求項５または６に記載のゲーム管理装置。
8. 前記提示手段は、前記交換条件を提示する他のユーザの人数を、所定人数に制限する請求項５ないし７の何れか１項に記載のゲーム管理装置。
9. 前記提示手段は、前記交換条件が適用されるオブジェクトをユーザが入手した場合であって、前記交換条件の提示対象となり得る他のユーザが複数存在する場合、当該複数の他のユーザに対して、同時に、前記交換条件の提示を行う請求項１ないし３の何れか１項に記載のゲーム管理装置。
10. 前記交換条件の提示が開始されてからの経過時間に応じて、交換条件である、オブジェクトとの交換に必要な対価を低下させる対価変更手段をさらに備えている請求項９に記載のゲーム管理装置。
11. ユーザが指定した個人を特定する情報に基づいて、他のユーザの範囲として特定の他のユーザが設定された場合、当該特定の他のユーザのゲーム情報に基づいて、又は当該特定の他のユーザおよび前記ユーザのゲーム情報に基づいて、当該特定の他のユーザに提示する前記交換条件を自動的に設定する自動設定手段をさらに備えている請求項２に記載のゲーム管理装置。
12. ゲームを管理するゲーム管理装置であって、
    ユーザに関係付けられた他のユーザを管理する管理手段と、
    ユーザからの要求に応じて、取引対象の前記他のユーザの範囲および当該範囲内の他のユーザに提示するオブジェクトの売却条件を予め設定する設定手段と、
    前記売却条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの売却条件を自動的に提示する提示手段と、を備え、
    前記売却条件には、売却対象のオブジェクトおよび当該オブジェクトの購入に必要な対価の情報が含まれるゲーム管理装置。
13. サーバと、当該サーバとの間で通信を行う端末装置と、を含むゲームシステムであって、
    ユーザに関係付けられた他のユーザを管理する管理手段、
    ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定手段、
    前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示手段、を前記サーバ又は前記端末装置の何れか一方が備えるゲームシステム。
14. ゲームの管理を行うコンピュータにおけるゲーム管理方法であって、
    コンピュータが、ユーザに関係付けられた他のユーザを管理する管理ステップと、
    コンピュータが、ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定ステップと、
    コンピュータが、前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示ステップと、を含むゲーム管理方法。
15. コンピュータを、ゲームを管理するゲーム管理装置として動作させるためのプログラムであって、
    前記コンピュータを、
    ユーザに関係付けられた他のユーザを管理する管理手段、
    ユーザからの要求に応じて、前記他のユーザに提示するオブジェクトの交換条件を予め設定する設定手段、
    前記交換条件が適用されるオブジェクトをユーザが入手した場合、前記他のユーザに、当該オブジェクトの交換条件を提示する提示手段、
    として機能させるためのプログラム。

Images