JP5715615B2 - ゲーム制御装置、プログラム、ゲームシステム - Google Patents

Description

本発明は、複数のユーザの各々の操作に応じて、各ユーザによるゲームの進行を制御する技術に関する。

近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であって、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。

上述したソーシャルゲームでは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。このようなソーシャルゲームの一例として、下記の非特許文献１に記載されたデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、平成23年11月1日発行）、7-8頁

しかし、従来のソーシャルゲームでは、自分が持っているアイテムなどのオブジェクトが他のユーザにとって有益であるか否かがわからず、ユーザ間でのプレゼントや交換の機能があまり使用されていなかった。このため、仲間にとって有益であるにもかかわらず、自分にとって不要なオブジェクトは、捨てられ、あるいは、自分専用の用途に使用されていた。ユーザ間でのプレゼントや交換の機能が使用されないことは、ユーザ間でのコミュニケーションの機会を低下させるため、特にソーシャルゲームでは好ましくない。

本発明は上述した観点に鑑みてなされたもので、ユーザにとって不要なオブジェクトの他のユーザにとっての有益度を、適切なタイミングでユーザに示すことができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
このゲーム制御装置は、
オブジェクトを各ユーザに対応付ける対応付け手段（５３）、
ユーザに対し他のユーザを関連付ける関連付け手段（５４）、
第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段（５５）、
前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段（５６）、
前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段（５７）、
前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段（５８）、の各手段を備える。

本発明に係るゲーム制御装置は、ユーザが単独で使用するスタンドアローンのゲーム機であってもよいし、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよい。
本発明において「オブジェクト」とは、例えば、ゲーム上のキャラクタやアイテム等を含む。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
本発明において「ゲーム情報」は、ゲームの性質によって多様な情報を含みうる。例えば、ゲーム情報は、ゲームにおける各処理の履歴、ユーザのゲーム進行レベル、ユーザの保有するオブジェクトの情報、成長レベルなどを含む。
本発明において「オブジェクトの有益度」とは、オブジェクトを使用することによりユーザがゲームを有利に進めることができる程度をいう。
本発明において、「有益度に関する情報」とは、有益度自体に限られず、例えば、ユーザがゲームを有利に進めるためのオブジェクトの使用方法を示唆する情報であってもよい。

このゲーム制御装置によれば、第１のユーザが、第１のユーザに対応付けられた第１のオブジェクトの対応付けを解除しようとしたときに、第１のユーザに関連付けられた第２のユーザにおける第１のオブジェクトの有益度に関する情報が提示されるので、第１のオブジェクトの第１のユーザへの対応付けが解除される前に、第１のユーザが当該有益度を知ることができる。その結果、第１のユーザから第２のユーザへのオブジェクトのプレゼントや、第１のユーザと第２のユーザとの間のオブジェクトの交換をする機能が活用され、ユーザ間でコミュニケーションの機会を増大させることができる。

上記ゲーム装置において、前記判定手段（５７）は前記第１のオブジェクトの有益度が所定値以上であるか否かを判定し、前記第１の提示手段（５８）は、前記第１のオブジェクトの有益度が所定値以上である場合に、前記有益度に関する情報を前記第１のユーザに提示してもよい。
このゲーム装置によれば、第２のユーザにおける第１のオブジェクトの有益度が所定値以上である場合に有益度に関する情報が第１のユーザに提示されるので、第１のユーザに提示する情報量を低下させることができるとともに、第１のユーザは必要性の高い情報のみを受け取ることができる。
なお、所定値とは例えば定数等の一定値であっても良いし、第１のユーザ情報、又は、第２のユーザ情報に基づく変動値であっても良い。例えば、第１のユーザにおける第１のオブジェクトの有益度を判定し、第１のユーザにおける第１のオブジェクトの有益度と、第２のユーザにおける第１のオブジェクトの有益度と、を比較し、第２のユーザにおける第１のオブジェクトの有益度が大きい場合は、第２のユーザにおける第１のオブジェクトの有益度に関する情報を前記第１のユーザに提示しても良い。また、第１のオブジェクトの第１のユーザへの対応付けを解除する際に第２ユーザにおける有益度を表示する条件を第1のユーザが設定できても良い。例えば、「有益度が５以上の場合に表示する。」「合成においての有益度が高い場合は表示する。」等の指定ができるようにしても良い。

上記ゲーム装置において、前記第１のユーザへの対応付けが解除された前記第１のオブジェクトを前記第２のユーザへ対応付ける譲渡手段（５９）と、前記第１のオブジェクトを前記第２のユーザへ対応付けた後、前記第１のオブジェクトと前記有益度に関する情報を前記第２のユーザに提示する第２の提示手段（６０）、の各手段をさらに備えてもよい。
このゲーム装置によれば、第１のオブジェクトを譲り受けた第２のユーザが、第２の提示手段（６０）により第１のオブジェクトの有益度に関する情報を提示されることで、第１のオブジェクトの使用方法を知ることができる。

上記ゲーム装置において、前記第２の提示手段（６０）は、前記第１オブジェクトの有益度に関する情報に基づいて前記第１のオブジェクトを使用するための操作釦を提示してもよい。
本発明において、操作釦は、例えば、第１のオブジェクトを使用するためのショートカットメニューである。
このゲーム装置によれば、第１オブジェクトの有益度に関する情報に基づいて提示された操作釦を第２のユーザが選択操作して第１のオブジェクトを使用することができ、操作性が良好となる。

上記ゲーム装置において、前記第２のユーザへ対応付けられる前記第１のオブジェクトの使用方法を前記第１のユーザが指定するための指定手段（６２）をさらに備え、前記第２の提示手段（６０）は、前記第１のユーザにより指定された使用方法により前記第１のオブジェクトを使用するための操作釦を提示してもよい。
このゲーム装置によれば、指定手段（６２）により第１のユーザが第１のオブジェクトの使用方法を指定することができ、第２のユーザに対して指定した使用方法によって第１のオブジェクトを使用させることができる。

上記ゲーム装置において、前記判定手段（５７）は、ゲーム内のオブジェクトの使用方法ごとに前記第１のオブジェクトの複数の有益度を判定し、前記第１の提示手段（５８）は、前記複数の有益度の少なくとも一部をその使用方法と対応付けて有益度に関する情報として前記第１のユーザに提示してもよい。
このゲーム装置によれば、第１のオブジェクトについて判定された複数の有益度の少なくとも一部を、その使用方法とともに第１のユーザが知ることができる。そのため、第１のユーザは、第１のオブジェクトを第２のユーザに譲渡するか否かについて適切に判断できる。
なお、使用方法毎の有益度を全て表示しても良いし、ユーザが設定した条件、又は、所定の条件を満たす使用方法とその有益度のみを表示するようにしても良い。例えば、使用方法が合成で有益な場合のみ表示するようにユーザが設定できてもよいし、有益度が所定値以上の場合にのみその使用方法と有益度を表示するように条件を設定しても良い。

上記ゲーム装置において、前記第１の提示手段（５８）は、前記複数の有益度のうち、最も高い有益度に関する情報を前記第１のユーザに提示してもよい。
このゲーム装置によれば、複数の有益度のうち、最も高い有益度に関する情報を第１のユーザに提示することで、第１のユーザが第１のオブジェクトに対する最も有益な用途を知ることができる。そのため、第１のユーザは、第１のオブジェクトを第２のユーザに譲渡するか否かについて、より適切に判断できる。

上記ゲーム装置において、前記第１の提示手段（５８）は、第１のユーザに関連付けられる複数の第２のユーザのうち、前記有益度が最も高い第２のユーザにおける前記有益度に関する情報を前記第１のユーザに提示してもよい。
このゲーム装置によれば、第１のユーザに関連付けられる複数の第２のユーザのうち、有益度が最も高い第２のユーザにおける有益度に関する情報を第１のユーザに提示することで、第１のユーザが第１のオブジェクトを譲渡する相手を複数の第２のユーザから特定することが容易となる。

上記ゲーム装置において、前記判定手段（５７）は、ゲーム内のオブジェクトの使用方法ごとに前記第１のオブジェクトの複数の有益度を判定し、前記第２の提示手段（６０）は、前記複数の有益度の少なくとも一部をその使用方法と対応付けて前記第２のユーザに提示してもよい。
このゲーム装置によれば、第１のオブジェクトについて判定された複数の有益度の少なくとも一部を、その使用方法とともに第２のユーザが知ることができる。そのため、第１のオブジェクトを譲り受けた第２のユーザが、自身のゲームの実行状況に応じて、第１のオブジェクトの有益な使用方法を決定することができる。

上記ゲーム装置において、前記第２の提示手段（６０）は、前記複数の有益度のうち、最も高い有益度を前記第２のユーザに提示してもよい。
このゲーム装置によれば、複数の有益度のうち、最も高い有益度に関する情報を第２のユーザに提示するため、第２のユーザが第１のオブジェクトに対する最も有益な用途を知ることができる。

上記ゲーム装置において、前記第１のユーザと関連付けられた第２のユーザを前記第１のユーザとの関連度により評価する評価手段（６１）をさらに備え、前記判定手段（５７）は、前記関連度が所定の値以上である第２のユーザにおける前記第１のオブジェクトの有益度を判定してもよい。
本発明において、「関連度」とは、例えば、ゲームにおけるユーザ同士の協働、対戦、メッセージ送受信、オブジェクトの譲渡頻度等に対応するパラメータである。
このゲーム装置によれば、関連度が所定の値以上である第２のユーザにおける第１のオブジェクトの有益度を判定することで、ゲーム装置による処理の負担を軽減することができる。また、第１のユーザと関係付けられた第２のユーザが多数いる場合に、第１のオブジェクトの譲渡対象となる可能性の高い、関連度の高い第２のユーザの情報のみが、第１のユーザに提示されるため、第１のユーザにとって煩雑にならずに済む。

上記ゲーム装置において、前記第１のユーザと関連付けられた第２のユーザを前記第１のユーザとの関連度により評価する評価手段（６１）をさらに備え、前記第１の提示手段（５８）は、第１のユーザに関連付けられる複数の第２のユーザにおける前記有益度に関する情報を前記関連度が高い第２のユーザから順に、前記第１のユーザに提示してもよい。
このゲーム装置によれば、関連度が高い第２のユーザから優先して、有益度に関する情報を提示する場合、第１のオブジェクトを譲渡する対象となる可能性の高い、関連度の高い第２のユーザの情報から優先して、第１のユーザに提示されるため、第１のユーザにとって煩雑にならずにすむ。

上記ゲーム装置において、前記第２のユーザにより前記第１のオブジェクトが使用されたことを前記第１のユーザに通知する通知手段（６３）をさらに備えてもよい。
このゲーム装置によれば、第２のユーザにより第１のオブジェクトが使用されたことを第１のユーザが知ることができる。そのため、第１のユーザは、譲渡した第１のオブジェクトが使用された場合に満足感を得ることができる。

本発明の第２の観点は、ゲーム制御方法である。
このゲーム制御方法は、
オブジェクトを各ユーザに対応付ける対応付け情報を記憶装置に記憶させるステップと、
ユーザ同士を関連付けるステップと、
第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザとの対応付けを解除するステップと、
前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を前記記憶部から取得するステップと、前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定するステップと、
前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示するステップと、を含む。

本発明の第３の観点は、コンピュータに、
オブジェクトを各ユーザに対応付ける対応付け情報を記憶装置に記憶させる対応付け機能、ユーザ同士を関連付ける関連付け機能、
第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトと、第１のユーザとの対応付けを解除する解除機能、
前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を前記記憶部から取得する取得機能、
前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定機能、および
前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する提示機能、を実現するためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、光ディスク（ＤＶＤ−ＲＯＭ、ＣＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第４の観点は、ユーザの通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含む、ゲームシステムである。
このゲームシステムは、
オブジェクトを各ユーザに対応付ける対応付け手段（５３）、
ユーザ同士を関連付ける関連付け手段（５４）、
前記対応付け情報および前記関連付けの情報を記憶する記憶部（３０）、
第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトと、第１のユーザとの対応付けを解除する解除手段（５５）、
前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段（５６）、
前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段（５７）、
前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザの通信端末に提示する第１の提示手段（５８）、の各手段を、前記通信端末（１０）または前記サーバ（２０）のいずれか一方が備える。

なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定されるものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ユーザにとって不要なオブジェクトの他のユーザにとっての有益度を、適切なタイミングでユーザに示すことができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるゲーム情報データベースの構成例を示す図。 データベースサーバに含まれる保有オブジェクトデータベースの構成例を示す図。 データベースサーバに含まれる仲間データベースの構成例を示す図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示されるウェブページを例示する図。 ユーザの通信端末に表示されるウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置により行われる主要なフローチャート。 実施形態のゲーム制御装置により行われる主要なフローチャート。 実施形態のゲーム制御装置により行われる主要なフローチャート。 実施形態のゲーム制御装置により行われる主要なフローチャート。 実施形態のゲーム制御装置により行われる主要なフローチャート。 実施形態のゲーム制御装置により行われる主要なフローチャート。 変形例のゲーム装置で主要な役割を果たす機能を説明するための機能ブロック図。 ユーザの通信端末に表示されるウェブページを例示する図。 データベースサーバに含まれるプレゼント受領データベースの構成例を示す図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明のゲームシステムの一実施形態について説明する。

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０をウェブページ上で操作してゲームを実行する。

また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。

（２）通信端末の構成
図２Ａ，図２Ｂ及び図３を参照して通信端末１０について説明する。
図２Ａ及び図２Ｂはそれぞれ、通信端末１０の外観の例を示す図である。図２Ａは、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものである。図２Ｂは、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、及び、信号送受信部としての通信インタフェース部１７を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１８が設けられている。

ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフェース部１７を介して取得し、ウェブブラウザを実行してＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。そのようなプラグインの一例は、アドビシステムズ社（米国）によるフラッシュプレイヤである。あるいは、本実施形態でのＨＴＭＬデータを、動画及び音声の再生機能を備えたＨＴＭＬ５形式としてもよい。

ウェブブラウザは、ゲームサーバ２０とＨＴＴＰ(HyperText Transfer Protocol)に従った通信を行う。ウェブブラウザは、ユーザによる指示入力部１５の操作によってウェブページ上のＵＲＬ(Uniform Resource Locator)またはメニューが選択されると、ウェブページの更新のために、その選択結果を含むＨＴＴＰリクエストをゲームサーバ２０に送信する。ウェブブラウザは、ＨＴＴＰレスポンスとしてゲームサーバ２０からＨＴＭＬデータを取得し、解釈して、画像処理部１４を介してウェブページを表示部１６に表示する。

画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

通信端末１０が釦入力方式の通信端末（図２Ａ）である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のＵＲＬまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されているＵＲＬまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２Ａに示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。

通信端末１０がタッチパネル入力方式の通信端末（図２Ｂ）である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２Ｂに示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。

通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。

（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。

例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ゲームサーバ２０のウェブブラウザとの間でＨＴＴＰに従った通信を行う。例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、通信端末１０から受信したＨＴＴＰリクエスト（例えば、前述したように、ウェブページ上でのユーザのＵＲＬまたはメニューの選択結果を含む。）に基づいて所定のデータ処理や、演算処理を行い、その処理結果を含むＨＴＴＰレスポンスをゲームサーバ２０のウェブブラウザに返す。ＨＴＴＰレスポンスには、ウェブページを更新するためのＨＴＭＬデータが含まれる。また、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

（４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、データベース３１と、データベース３２とを備える。データベース３１は、ゲーム情報データベース（ゲーム情報ＤＢ）、保有オブジェクトデータベース（保有オブジェクトＤＢ）、仲間データベース（仲間ＤＢ）、プレゼント受領データベース（プレゼント受領ＤＢ）を含む。データベース３２は、オブジェクトデータベース（オブジェクトＤＢ）を含む。
なお、データベースサーバの構成は当該構成に限らず、複数のサーバ装置でそれぞれ異なるデータベースを管理してもよい。

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態のゲームの一例として、モンスターが描かれたデジタルカード（モンスターカード、以下適宜、単に「カード」という。）を用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。なお、ここでは、オブジェクトの一例としてモンスターカードを挙げるが、オブジェクトは、ゲーム上の使用対象あるいは操作対象などになり得るオブジェクトであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものやフィギュアになっているものをも含む。
このゲームは、ユーザがカードを入手することによって自らのチームを作り上げ、コンピュータ又は他のユーザのチームとバトルを行うように構成されている。なお、チーム（慣用的に「カードデッキ」ともいう）は、一般的に複数のカードによって構成されている。
このゲームは、例えば、以下の処理を含む。
・クエスト処理：
少なくとも一枚のカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してカードを得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費する。
・対戦処理：
ユーザのチームと、対戦相手のチームとの間で対戦を行う処理である。ここで、対戦相手は、コンピュータ又は他のユーザのチームである。なお、コンピュータのチームは、ＣＰＵ２１によって任意に抽出された１または複数のカードからなる。
・合成処理：
対戦を有利にするために、素材となるカード（素材カード）を用いて、ベースとなるカード（ベースカード）を強化する処理である。なお、合成処理では、所定量の合成ポイントを消費する。
・売却処理
保有するカードを合成ポイントに変換する処理である。カードの保有数に上限がある場合や、合成処理に必要な合成ポイントが不足する場合、売却処理によりカードと引き換えに合成ポイントが得られる。なお、本実施形態のゲームでは、カードをポイントと交換することはできるが、ポイントをカードに交換することができない。

また、ここでは詳しく述べないが、本実施形態のゲームは、例えばユーザがゲーム上保有するカードにおいて、当該ユーザのチームに含まれるカードと、それ以外のカード（つまり、当該ユーザのチームに含まれないカード）との交替等を実行するための編成処理を含んでもよい。

図６に、本実施形態のゲームにおいて適用されるゲーム情報データベースの一例を示す。この例では、ゲーム情報データベースは、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、ユーザ画像、属性、進行レベル、体力ポイント、使用可能コスト、及び合成ポイントの各項目についての情報を含む。

また、ゲーム情報データベースは、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたユーザのゲームの進行に関するゲーム情報を記憶、更新する。なお、後述する保有オブジェクトデータベース、仲間データベース、プレゼント受領データベース等についても、ゲームの進行に応じてゲームサーバ２０によって逐次更新されうる。

以下の説明では、ゲーム情報データベースに含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してゲーム情報という。ゲーム情報を構成する各項目のデータは、以下のとおりである。
・ユーザ名
ユーザ名は、ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名は、例えばユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・ユーザ画像
ユーザ画像は、ゲームの実行時に通信端末１０のユーザを特定するために表示される画像であり、例えばユーザによって予め選択されるアバタ画像であってもよい。
・進行レベル
ユーザのゲームにおける進行度合いを示すデータであり、ユーザによるゲームの進行に伴って増加する値である。例えば、進行レベルは、例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。進行レベルは、本実施形態のゲームにおいて予め規定された規則に従って増加する。進行レベルは例えば、対戦でユーザが勝利した数、又は対戦での勝率が増加するにつれて増加してもよい。
・体力ポイント
体力ポイントは、ユーザがクエスト処理を行う際に消費するコストを示す変数である。体力ポイントは、進行レベルが増加するにつれて増加するように設定されていてもよい。
・使用可能コスト
本実施形態のゲームでは、各カードに対してコストが対応付けられている。使用可能コストは、ユーザが１回の対戦で使用可能なカードのコストの総和の上限値である。つまり、ユーザは、１回の対戦では、各カードのコストの総和が使用可能コスト以下となるように、対戦で使用するカードを選択することがもとめられるようにしてもよい。使用可能コストは、例えば、進行レベルが大きくなるにつれて大きい値に設定されてもよい。
なお、使用可能コストを設定すること、すなわちユーザが１回の対戦で使用可能なカードのコストの総和の上限値を設定することは必須ではない。
・合成ポイント
合成ポイントは、ユーザが合成処理を行う際に消費されるコストである。

その他に、図示しないが、ゲーム情報データベースは、クエスト処理の履歴、対戦処理の履歴、オブジェクトの保有履歴（図鑑）、合成処理の履歴（カードの使用回数等）、売却処理の履歴などを含む。ここで、オブジェクトを「保有」している状態とは、例えば、ユーザに対応付けられたオブジェクトが、ユーザにより使用可能、処分可能であることをいう。例えば、ユーザによって、クエスト処理、対戦処理、合成処理において使用可能であること、及び、売却処理において売却可能であることをいう。なお、後述する保有オブジェクトデータベースにおいてオブジェクトの保有状態をフラグで管理し、一度保有オブジェクトデータベースに書き込んだオブジェクトについてはデータを消去しないことで、保有オブジェクトデータベースを保有履歴（図鑑）として用いることができる。
以上の情報を、本実施形態のゲームでは、ゲーム情報データベースに含まれる個々のユーザの情報を総称して「ゲーム情報」というが、「ゲーム情報」は上記した情報例に限られるものではなく、ゲームの性質によって多様な情報を含むようにしてもよい。

保有オブジェクトデータベースには、ユーザＩＤごとに各ユーザが保有する（各ユーザに対応付けられた）オブジェクトがオブジェクトＩＤ毎に記憶されている。
図７に、保有オブジェクトデータベースの構成例を示す。図７では、保有オブジェクトがカードの場合の例を示しているため、オブジェクトＩＤではなくカードＩＤと表記している。図７に示すように、ユーザＩＤごとの保有オブジェクトデータベースには、各ユーザが保有するカードのカードＩＤ毎に、カード名、カードの属性、モンスター画像、攻撃力、防御力、使用コスト、特技、成長レベル、レア度等のパラメータが対応付けられている。
なお、オブジェクトはカードに限られず、体力回復アイテム、カード抽選用アイテム等の様々なアイテムであってもよく、ユーザが保有するオブジェクトが保有オブジェクトデータベースで管理される。ここで、「カード抽選用アイテム」とは、当該アイテムを使用したユーザに、特定のオブジェクト、又は、複数のオブジェクトの中から所定の規則、又は、ランダムな確率で選択されたオブジェクトが付与されるアイテムである。

カードの攻撃力、防御力は、対戦において参照されるパラメータである。カードの属性とは、カード毎に設定される、ゲーム性に影響を与える特性であり、例えば、カードの特徴や性質などを示す情報であってもよいし、カードの特徴や性質などを分類するための情報であってもよい。例えば、属性の違いによりゲームの進行（後述する「クエスト」、「対戦」、「合成」等）において、影響を与えてもよい。例えば、「火」、「森」、「水」等の属性を各カードに設定し、後述する特技により、対戦時に「火」属性のカードは「森」属性のカードに対して対戦時に有利、「森」属性のカードは「水」属性のカードに対して対戦時に有利、「水」属性のカードは「火」属性のカードに対して対戦時に有利、となるように設定することができる。あるいは、後述する合成処理において、同属性のカードを合成する場合、異なる属性のカードを合成する場合よりも有利となるように設定することができる。あるいは、例えば野球ゲームにおいて、オブジェクトが野球の選手の場合、属性には、ゲーム上の選手（オブジェクト）のチームや、ポジション（例えば投手、捕手、一塁手、左翼手など）などが含まれてもよい。
使用コストは、そのカードをユーザが対戦時にカードを使用するか否かについて検討するときに参照されるパラメータである。前述したように、対戦時に使用するカードのコストの総和は、使用可能コスト以下に制限されるようにしてもよい。なお、攻撃力が大きいほどカードのコストを大きく設定してもよいが、攻撃力と無関係にカードのコストを設定してもよい。
特技は、例えば、クエストや対戦時に当該カードが含まれるチームの他のカードの攻撃力、防御力等のパラメータや、対戦相手のチームのカードの攻撃力、防御力等のパラメータを増減させるような効果を規定したものである。例えば、当該カードが含まれるチーム内の所定の属性のカードの攻撃力または防御力を上昇させる特技や、対戦相手のチーム内の所定の属性のカードの攻撃力または防御力を低下させる特技、特定のカードの組み合わせがチームに含まれている場合に、当該特定のカードの攻撃力または防御力を上昇させる特技等がある。
なお、特技は全てのカードが有してもよいし、一部のカードのみが有してもよい。また、特技にレベルが設定されており、レベルに応じて効果が変動するものであってもよい。
カードの成長レベルは、後述する合成処理によるカードの成長度を示すパラメータである。カードのレア度は、ゲーム全体におけるカードの希少性を示すパラメータである。

仲間データベースには、例えば仲間になるための申請などを契機として、各ユーザに関連付けられた他のユーザ（仲間）のユーザＩＤが記憶されている。

図８に仲間データベースの構成例を示す。図８に例示する仲間データベースには、ユーザＩＤごとに、仲間のユーザＩＤと、仲間からのプレゼントの受領回数、仲間へのプレゼントの送付回数、仲間との親密度（関連度）等が対応付けられている。関連度は、プレゼントの受領回数や送付回数により決定してもよい。例えば、プレゼントの受領回数が１０回以上であれば関連度を３、プレゼントの受領回数が５回以上９回以下であれば関連度を２、プレゼントの受領回数が４回以下であれば関連度を１と評価することができる。なお、仲間のユーザＩＤごとに、メッセージ（挨拶）の送信回数や、挨拶の受領回数を対応付けてもよい。

プレゼント受領データベース（図示せず）にはユーザ毎に、例えば、コンピュータから付与されたオブジェクトまたは他のユーザからプレゼントされたオブジェクトであって、当該ユーザが受領していないオブジェクトのオブジェクトＩＤが記憶されている。

図５に戻り、データベース３２は、ユーザに対応付けられる前のオブジェクトのパラメータを含むオブジェクトデータベース（図示せず）を含む。例えば、オブジェクトがカードの場合、オブジェクトデータベースには、ゲーム内で使用されるカードのカードＩＤに、カードの属性、モンスターの名称、モンスター画像、使用コスト、レア度、成長レベルに応じたカードの攻撃力、防御力のパラメータ等が対応付けられている。

（５）本実施形態のゲーム
以下、本実施形態のゲームについて、図９〜１５を参照しながら説明する。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

図９のトップページＰ１は、モンスター画像表示領域１０１、ユーザデータ表示領域１０２及びメニュー表示領域１０３を含む。トップページＰ１は処理対象のユーザ毎に構成されるが、図９のトップページＰ１は、処理対象の第１のユーザが「Ａ」というユーザ（以下、「ユーザ：Ａ」と表記する。）である場合の例である。
モンスター画像表示領域１０１は、処理対象となるユーザのゲーム情報に含まれる複数のカードのうち当該ユーザによって予め指定されたカードに対応する画像が表示される領域である。ユーザデータ表示領域１０２は、処理対象となるユーザのゲーム情報に含まれる、進行レベル、体力の各項目のデータ（図６参照）が表示される領域である。メニュー表示領域１０３には、本実施形態のゲームに設けられる処理（クエスト処理、対戦処理、合成処理、売却）にそれぞれ対応するメニューｍ１（「クエスト」）、メニューｍ２（「対戦」）、メニューｍ３（「合成」）、メニューｍ４（「売却」）が含まれる。なお、メニュー表示領域１０３には、上述した編成処理に対応するメニューが含まれてもよい。
このトップページＰ１上で、メニューｍ１〜ｍ４のいずれかが選択操作されることで、ゲームの実行が開始される。

〔クエスト処理〕
先ず、クエスト処理の一例を説明する。図９のトップページＰ１上でメニューｍ１が選択操作されると、クエスト処理が開始され、Ｐ２に示すようにウェブページが更新される。ウェブページＰ２には、探索の対象となるエリア（図の例では、エリア４）の進行度合いを示す達成率のゲージと、探索処理を実行するための「クエスト実行」と表記されたメニューｍ１０と、１回の探索に要する体力ポイントの値、１回の探索で得られる経験値、合成ポイントなどが含まれる。
メニューｍ１０がユーザ：Ａによって選択操作される度に所定の条件に沿った、あるいはランダムな増加量で達成率の値が増加する。そして、達成率が１００％に達すると、エリアの探索が終了して次のエリアに進むことができる。メニューｍ１０が選択操作される度に、ユーザ：Ａの体力ポイントが所定量（図９の例では、８）だけ消費される。探索対象のエリアは、複数設けられてもよい。なお、クエスト処理では、メニューｍ１０が選択操作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されているカードあるいはアイテムなどのオブジェクトや、経験値、合成ポイント等をユーザが入手できるように構成されている。

なお、ウェブページＰ２においてメニューｍ１０の選択操作を繰り返し行うと、上述したように体力ポイントが低下していくが、体力ポイントが１回の探索に要する体力ポイント（例えば８）よりも少なくなると、それ以上探索の実行ができない状態となる。その場合、ユーザが再び探索を実行できるようになるには、時間の経過によって体力ポイントが回復（増加）するまで待機することが必要となる。

〔対戦処理〕
次に、対戦処理の一例を説明する。図１０のトップページＰ１上でメニューｍ２が選択操作されると、対戦処理が開始され、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３には、対戦相手（Ｅ）の画像とともに、対戦の実行を指示するための「対戦開始」と表記されたメニューｍ２０などが含まれる。ウェブページＰ３上でユーザ：Ａがメニューｍ２０（「対戦開始」）の選択操作を行うと、ユーザ：Ａのチームと対戦相手：Ｄのチームとの間で対戦が行われる。
なお、本実施例のように、ＣＰＵ２１によって所定の条件、又はランダムに対戦相手が決定されてもよいし、所定の条件、又はランダムに選出された複数の対戦相手からなるリストを表示し、ユーザがその中から対戦相手を選択できても良い。また、対戦相手はコンピュータであってもよいし（ＣＯＭ対戦）、他のユーザであってもよい（ユーザ間対戦）。他のユーザはユーザ：Ａと関連付けられている仲間であってもよいし、ユーザと関連付けられていないユーザであってもよい。

対戦処理は、例えば、攻撃側のチームのオブジェクト(カード)情報、および、防御側のチームのオブジェクト(カード)情報に基づいて実行される。例えば、攻撃側のチームのカードの攻撃力の総和と、防御側のチームのカードの防御力の総和とを比較し、数字が大きい側を勝利、小さい側を敗北と決定することで、対戦処理を行うことができる。なお、対戦処理は攻撃力・防御力等のパラメータの総和の比較によるものに限らず、チームに設定されたオブジェクト(カード)に対応付けられた特技や属性に応じて、攻撃力・防御力を変動させた上で比較し勝敗を決定してもよいし、パラメータの数値の大小に応じて勝つ確率を変動させた上で抽選処理を行い、勝敗を決定してもよい。例えば、ユーザ：Ａや対戦相手：Ｅのチームに特技を持つカードがあれば、特技に応じて、当該カードが含まれるチーム内の所定の属性のカードの攻撃力または防御力を上昇させ、あるいは、対戦相手のチーム内の所定の属性のカードの攻撃力または防御力を低下させた後、攻撃側のチームのカードの攻撃力の総和と、防御側のチームのカードの防御力の総和とを比較してもよい。

対戦が終了すると、対戦の結果を通知するウェブページ（Ｐ４に例示するウェブページ）がユーザ：Ａの通信端末１０上に表示される。なお、ウェブページＰ４は、ユーザ：Ａが対戦に勝利した場合に通信端末１０の表示部１６に表示されるウェブページの一例を示している。このゲームでは、ユーザ：Ａが対戦相手：Ｄに勝利すると、所定量の合成ポイント（図の例では１００）が特典としてユーザ：Ａに付与される。

〔合成処理〕
次に、合成処理の一例を説明する。図１１のトップページＰ１上でメニューｍ３が選択操作されると、合成処理が開始され、図１１のＰ５に示すようにウェブページが更新される。合成処理用のウェブページＰ５には、合成処理により強化させる対象となるベースカード（図１１ではａｂｃ）と、消失する素材カード（図１１ではａｂｄ）の画像が表示されるとともに、合成の実行を指示するための「合成する」と表記されたメニューｍ３１、合成の実行をキャンセルするための「キャンセル」と表記されたメニューｍ３２、ベースカードを選択するための「ベースカード選択」と表記されたメニューｍ３４、素材カードを選択するための「素材カード選択」と表記されたメニューｍ３５などが含まれる。ベースカード、素材カードは、それぞれメニューｍ３４、ｍ３５を選択操作した後、表示されるウェブページ（図示せず）において選択することができる。
ウェブページＰ５上でユーザ：Ａがメニューｍ３１（「合成する」）の選択操作を行うと、ベースカードの攻撃力、防御力、特技等のパラメータと、素材カードの攻撃力、防御力、特技等のパラメータとを基にして、合成処理後のベースカードの新たなパラメータが算出される。例えば、素材カードのパラメータに所定の係数を乗じた値を、ベースカードのパラメータに加算することで、合成処理後のベースカードの新たなパラメータを算出することができる。あるいは、例えば図１１に示すように、ベースカード：ａｂｃの特技：Ｘのパラメータ：１（Ｘ１）と、素材カード：ａｂｄの特技：Ｘのパラメータ：１（Ｘ１）を加算して、合成処理後のベースカード：ａｂｃの特技：Ｘの新たなパラメータを２（Ｘ２）としてもよい。
その後、図１１に示すウェブページＰ６に、合成処理後のベースカード（ａｂｃ）の新たなパラメータがベースカードの画像とともに表示される。同時に、ユーザ：Ａは素材カード：ａｂｄを保有していない状態となる（消失）。

なお、合成処理の方法は素材カードのパラメータに基づき、ベースカードのパラメータの上昇率が変動する方法に限らない。素材カードのその他のカード情報(例えば、レアリティなど)に応じて、ベースカードのパラメータの上昇率が変動してもよいし、素材カードのカード情報とは関係なく、所定の上昇率でベースカードのパラメータが変動してもよい。また、合成処理後のベースカードのパラメータの上昇率は、素材カードの属性がベースカードの属性と同じ場合には高く、素材カードの属性がベースカードの属性と異なる場合には低くなるように設定することができる。例えば、素材カードのパラメータに乗じる一定比率を、ベースカードの属性と素材カードの属性により変更してもよい。例えば、素材カードの属性がベースカードの属性と同じ場合には高い係数を用い、素材カードの属性がベースカードの属性と異なる場合には低い係数を用いてもよい。
なお、合成処理で選択されるカードは1つであってもよいし、複数であってもよい。

〔譲渡処理〕
本実施形態では、合成処理の際の素材カードのように、ユーザとオブジェクト(カード)の対応付けを解除するような処理の完了前に、譲渡処理が行われる場合がある。以下、一例として、合成処理の完了前に譲渡処理を行う場合について説明する。
合成処理時の素材カード：ｄｅｆが決定され、当該素材カード：ｄｅｆがユーザ：Ａの仲間にとって有益である場合には、ウェブページＰ７に示すように、当該カードを仲間にとって有益である旨のテキスト（例えば、図１２の「仲間がこのカードを必要としているかも知れません」）が表示されるとともに、仲間にとっての有益度に関する情報の表示を指示するための「確認する」と表記されたメニューｍ３３が表示される。ここで、素材カード：ｄｅｆが決定される場合として、（ａ）ＣＰＵ２１によって自動的に決定される場合、例えば、メニューｍ３を選択操作した後に自動的に決定される場合、（ｂ）ユーザによって選択・決定される場合、例えば、メニューｍ３５を選択操作してユーザが図示しないカードリストから素材カード：ｄｅｆを決定する場合、の２通りの場合がある。なお、ウェブページＰ５のような通常の合成処理用のウェブページにおいてメニューｍ３１（「合成する」）の選択操作を行った後、有益度に関する情報やメニューｍ３３を含むウェブページＰ７を表示してもよい。この場合、ウェブページＰ７でメニューｍ３１（「合成する」）の選択操作を行うことで合成処理が完了する。
なお、合成処理時の素材カードがユーザ：Ａ（第１のユーザ）にとって有益度が低い場合は、その旨の警告情報を提示しても良い。例えば、図１２に記載されるように、ベースカード：ａｂｃの特技：Ｘ１と素材カード：ｄｅｆの特技：Ｙ１が異なる場合は、合成処理後、素材カード：ｄｅｆ（第１のオブジェクト）の特技Ｙが失われてしまう。このように、消失するカードの用途がユーザ：Ａにとって有益度が低い場合、ウェブページＰ７に示すように、警告テキストが表示されても良い（例えば、図１２の「異なる特技同士を合成しようとしています！」）。
また、第１のユーザと第１のオブジェクトの対応付けを解除しようとしている場合、第１のユーザにおける第１オブジェクトの有益度と、第１のユーザと関連付けられた第２のユーザにおける第１オブジェクトの有益度を比較して、第２のユーザにおける有益度の方が高い場合にのみ第２のユーザにおける有益度に関する情報を表示しても良い。
なお、警告テキストが表示されるのは、消失するカードの用途がユーザにとって有益度が低い場合に限られない。

ウェブページＰ７上でユーザ：Ａがメニューｍ３３（「確認する」）の選択操作を行うと、図１３のＰ８に示すようにウェブページが更新される。ウェブページＰ８には、ユーザ：Ａの仲間であって、カード：ｄｅｆを欲しい他のユーザ（第２のユーザ）の欄が、欲しい理由とともにリスト表示される。ユーザ：Ｂ、Ｃ、Ｄはそれぞれ第２のユーザの一例である。
例えば、カード：ｄｅｆと同じ特技：Ｙを持つカードをユーザ：Ｂが保有している場合は、ウェブページＰ８のユーザ：Ｂの欄に「特技：Ｙのカードを集めています」と表示してもよい。
あるいは、カード：ｄｅｆをユーザ：Ｃが保有したことがない場合は、ウェブページＰ８のユーザ：Ｃの欄に「図鑑に登録されていません」と表示してもよい。
あるいは、カード：ｄｅｆと同じ属性のカードをユーザ：Ｄが多く保有している場合は、ウェブページＰ８の仲間：Ｄの欄に「同じ属性のカードを集めています」と表示してもよい。

ウェブページＰ８に表示する第２のユーザの欄のリストは、第１のユーザであるユーザ：Ａとの関連度が高い第２のユーザほど先に表示させてもよい。なお、図１３に示すウェブページＰ８では、ユーザ：Ａとの関連度として、ユーザ：Ａからのプレゼント送付回数や、ユーザ：Ａのプレゼント受領回数が多い第２のユーザの欄が上から順に表示されている。第２のユーザのリストが１画面に表示しきれない場合、スクロール表示してもよい。
図１３に示すウェブページＰ８ではプレゼント送付回数およびプレゼント受領回数の両方を表示しているが、いずれか一方のみを表示してもよいし、両方とも表示しなくてもよい。
あるいは、カード：ｄｅｆの有益度が高い第２のユーザほど先に表示させてもよい。例えば、カード：ｄｅｆの有益度がユーザ：Ｂでは３、ユーザ：Ｃでは２、ユーザ：Ｄでは１である場合、ユーザ：Ｂの欄、ユーザ：Ｃの欄、ユーザ：Ｄの欄の順にリスト表示してもよい。

ウェブページＰ８にリスト表示するユーザ：Ｂ、Ｃ、Ｄの欄には、それぞれカード：ｄｅｆをプレゼントするためのメニューｍ６１、ｍ６２、ｍ６３、および、プレゼントしないためのメニューｍ６４が表示される。ウェブページＰ８上でユーザ：Ａがメニューｍ６１の選択操作を行うと、カード：ｄｅｆがユーザ：Ａからユーザ：Ｂに譲渡される。同様に、ユーザ：Ａがメニューｍ６２の選択操作を行うと、カード：ｄｅｆがユーザ：Ａからユーザ：Ｃに譲渡され、ユーザ：Ａがメニューｍ６３の選択操作を行うと、カードｄｅｆがユーザ：Ａからユーザ：Ｄに譲渡される。一方、ユーザ：Ａがメニューｍ６４の選択操作を行うと、カード：ｄｅｆがユーザ：Ｂ、Ｃ、Ｄのいずれにも譲渡されずにウェブページＰ７、又は、Ｐ１が表示される。

ユーザ：Ａがメニューｍ６１の選択操作を行った場合、図１４に示すように、ユーザ：ＢのトップページＰ９にオブジェクトが譲渡(プレゼント)された事を示すメニューｍ５（「プレゼントが届いています」）が表示される。
ユーザ：Ｂがメニューｍ５の選択操作を行うと、図１４のＰ１０に示すようにウェブページが更新される。ウェブページＰ１０には、ユーザ：Ｂに譲渡されたプレゼント(オブジェクト)のリストが表示される。
各プレゼントの欄には、例えば、譲渡した第１のユーザ名（「Ａさん」）が表示される。また、各プレゼントの欄にユーザ：Ｂに対する有益度に関する情報（「合成素材用」、「体力回復用」）を譲渡した第１のユーザ名とともに表示しても良い。
また、当該プレゼントを保有するためのメニューｍ５２、ｍ５４（「受け取る」）が表示される。また、当該プレゼントを使用するためのショートカットメニューｍ５１（「合成する」）、ショートカットメニューｍ５３（「使う」）を表示しても良い。例えば、プレゼントが合成に使用すると有益度の高いカードである場合には、当該カードを使用するためのショートカットメニューｍ５１(「合成する」)を表示し、プレゼントが体力を回復するために使用すると有益度が高いアイテム（「回復薬」）であればショートカットメニューｍ５３（「使う」）を表示してもよい。あるいは、プレゼントが「チーム編成用」として有益度の高いカードである場合には、当該カードをチームに編成するためのチーム編成用画面へのショートカットメニュー（図示せず）を表示してもよい。

ユーザ：Ｂがショートカットメニューｍ５１の選択操作を行うと、図１４のＰ１１に示すようにウェブページが更新される。ウェブページＰ１１には、ユーザ：Ｂが受け取ったカード：ｄｅｆを素材カードとする合成処理用の画面が表示される。以後、図１１のウェブページＰ５と同様に合成処理を行うことができる。

〔売却処理〕
次に、カードを合成ポイントと交換する売却処理の一例を説明する。
図１５のトップページＰ１上でユーザ：Ａによりメニューｍ４が選択操作されると、売却処理が開始され、Ｐ１２に示すようにウェブページが更新される。ウェブページＰ１２には、ユーザ：Ａが売却しようとするカード：ａｂｃの詳細な情報が表示されるとともに、カード：ａｂｃの売却対価を示す情報（「５０００ポイント」）、売却の実行を指示するためのメニューｍ４１（「売却する」）、売却処理をキャンセルするためのメニューｍ４２（「キャンセル」）が表示される。
また、メニューｍ４１が実行されると、ユーザ：Ａは、売却対価を得るとともに、対応付けられたオブジェクト(カード：ａｂｃ)との対応付けが解除される。
そのため、合成処理の場合と同様に、対応付けが解除されるカードａｂｃが、ユーザ：Ａと関連付けられた他のユーザ（仲間）にとって有益である場合には、ウェブページＰ１２に示すように、当該カード：ａｂｃが仲間にとって有益である旨のテキスト（例えば、ウェブページＰ１２の「仲間がこのカードを必要としているかも知れません」）が表示されるとともに、仲間にとっての有益度に関する情報の表示を指示するための「確認する」と表記されたメニューｍ４３が表示される。

ユーザ：Ａが売却するカード：ａｂｃが決定され、当該カード：ａｂｃがユーザ：Ａの仲間にとって有益である場合には、ウェブページＰ１２に示すように、当該カードを仲間にとって有益である旨のテキスト（例えば、図１５の「仲間がこのカードを必要としているかも知れません」）が表示されるとともに、仲間にとっての有益度に関する情報の表示を指示するための「確認する」と表記されたメニューｍ４３が表示される。
ここで、売却するカード：ａｂｃが決定される場合として、（ａ）ＣＰＵ２１によって自動的に決定される場合、例えば、メニューｍ４を選択操作した後に自動的に決定される場合、（ｂ）ユーザによって選択・決定される場合、例えば、メニューｍ４を選択操作した後に表示される図示しないカードリストからユーザがカード：ａｂｃを決定する場合、の２通りの場合がある。なお、有益度に関する情報やメニューｍ４３が表示されない通常の売却処理用のウェブページにおいてメニューｍ４１（「売却する」）の選択操作を行った後、有益度に関する情報やメニューｍ４３を含むウェブページＰ１２を表示してもよい。この場合、ウェブページＰ１２でメニューｍ４１（「売却する」）の選択操作を行うことで売却処理が完了する。
ウェブページＰ１２上でユーザ：Ａがメニューｍ４３（「確認する」）の選択操作を行うと、ウェブページが更新され、図１３のＰ８と同様に、カード：ａｂｃを欲しい他のユーザのリストが、欲しい理由とともに表示される。以後、ウェブページＰ８と同様に、上述の〔譲渡処理〕の操作が行われる。

（６）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図１６を参照して説明する。図１６は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図１６の機能ブロック図において、対応付け手段５３、関連付け手段５４、解除手段５５、取得手段５６、判定手段５７、及び第1の提示手段５８が本発明の主要な構成に対応している。その他の手段（つまり、登録手段５１、実行手段５２、譲渡手段５９、第２の提示手段６０、及び評価手段６１）は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成要素である。

〔登録手段〕
登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。
登録手段５１の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作やユーザが指定するユーザＩＤやパスワード等のテキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えば、ＵＩＤ（Unique Identifier）などの端末の個体識別情報、ＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するゲーム情報を生成し、ゲーム情報データベースに格納する。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。

〔実行手段〕
実行手段５２は、通信端末１０に対するユーザのウェブページ上の選択操作に応じてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスにより本実施形態のゲームを実行する機能を備える。
実行手段５２は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。

実行手段５２がクエスト処理を実行する機能は、例えば以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、トップページ（図９のＰ１に例示するウェブページ）上でメニューｍ１が選択操作されると、クエスト処理用のウェブページ（図９のＰ２に例示するウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。次に、ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）の選択操作結果を含むＨＴＴＰリクエストを受信すると、以下の一連の処理を行う。すなわち、ＣＰＵ２１は、ゲーム情報データベースにアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する（減少させる）。次に、ＣＰＵ２１は、ユーザの達成率の値を所定量だけ増加させる。さらに、ＣＰＵ２１は、例えば、増加した達成率の値を含むＨＴＭＬデータを生成して、ユーザの通信端末１０へ送信する。このとき、ＣＰＵ２１は、達成率の値が１００％に達したと判断した場合には、探索対象を次のエリアに移行するように、ＨＴＭＬデータを生成する。
クエスト処理では、探索対象となるエリアごとに、１回の探索に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの進行レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。

クエスト処理において、ＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、複数のカードの中から選択されたカードをユーザに付与する（対応付ける）ことを、所定の、あるいはランダムな確率で決定する。ここで、ＣＰＵ２１は、カードを付与することを決定した場合、カードを入手したことを通知するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。ＣＰＵ２１は、複数のカードの中から選択されたカードをユーザに付与することを決定した場合には、クエスト用に予め設けられた複数のカードの中から、ユーザに対して付与されるカードを選択する。次に、ＣＰＵ２１は、選択したカードのデータをオブジェクトデータベースから読み出した後に、保有オブジェクトデータベースにアクセスする。そして、ＣＰＵ２１は、対象となるユーザＩＤの保有オブジェクトデータベースに、読み出したデータを書き込む。
また、ＣＰＵ２１は、クエスト処理において、カードと同様に所定のアイテムをユーザに付与してもよい。ここで、所定のアイテムは、例えば、体力回復アイテム、カード抽選用アイテムなどであってもよい。

また、実行手段５２は、対戦処理において、イベントにおけるゲームを実行する機能（本実施形態では、対戦を実行する機能）を備える。この機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ウェブページＰ３又はＰ６上でメニューｍ２０（「対戦開始」）が選択操作されたことを認識すると、処理対象のユーザ（ここでは、ユーザ：Ａ）のチームと、対戦相手（コンピュータ又は他のユーザ）のチームとの対戦結果を決定する処理を行う。
対戦結果の決定方法は、各チームに含まれるカードのパラメータの値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、対戦を行う２つのチームの各々に含まれる複数のカードのパラメータの値の合計を比較し、合計が大きな方のチームが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、パラメータの値の合計の差が大きいほど高い確率としてもよい。このとき、図７に示したように、パラメータの値を示す項目が複数（図７の例では、攻撃力と防御力の２つ）存在する場合には、各カードのパラメータの値を代表する値として、各項目の値に対して所定の重み付け（例えば、図７の例では、「攻撃力」を０．４、「防御力」を０．２の重み付けにする等）を行うことにより、総合的なパラメータの値を設定してもよい。
次に、ＣＰＵ２１は、対戦の結果を決定すると、対戦結果をユーザ：Ａに通知するウェブページ（例えば、ウェブページＰ４など）を表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。

実行手段５２が合成処理を実行する機能は、例えば以下のようにして実現される。ウェブページＰ５上でメニューｍ３１（「合成する」）が選択操作されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、ベースカードの攻撃力、防御力、特技等のパラメータと、素材カードの攻撃力、防御力、特技等のパラメータとを基にして、合成処理後のベースカードの新たなパラメータを算出する。その後、ＣＰＵ２１は、図１１に示すウェブページＰ６に、合成処理後のベースカード（ａｂｃ）の新たなパラメータをベースカードの画像とともに表示する。同時に、ＣＰＵ２１は、当該ユーザの保有オブジェクトデータベースにおいて素材カードの保有状態を解除することで、素材カードのユーザとの対応付けを解除する。同時に、合成処理を行ったユーザの合成履歴をゲーム情報データベースに記録する。

実行手段５２が売却処理を実行する機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１５のトップページＰ１上でユーザ：Ａによりメニューｍ４が選択操作されると、Ｐ１２に示すようにウェブページを更新する。これによって、Ｐ１２に示すように、ユーザ：Ａが売却しようとするカード：ａｂｃの詳細な情報とともに、カード：ａｂｃの売却対価を示す情報（「５０００ポイント」）、売却の実行を指示するためのメニューｍ４１（「売却する」）、売却処理をキャンセルするためのメニューｍ４２（「キャンセル」）を含むウェブページが表示される。ユーザによりメニューｍ４１が選択操作された場合、ＣＰＵ２１は、当該ユーザの保有オブジェクトデータベースにおいて譲渡するカード：ａｂｃの保有状態を解除することで、カード：ａｂｃのユーザとの対応付けを解除する。同時に、ＣＰＵ２１は、ゲーム情報データベースの合成ポイントに対して売却対価の値を加算する。ユーザによりメニューｍ４２が選択操作された場合、ＣＰＵ２１は、トップページＰ１を表示するためのＨＴＭＬデータを生成する。
なお、上記合成処理、売却処理の実行をする際に、保有オブジェクトデータベースにおいてオブジェクトの保有状態を解除するには、オブジェクトの情報を全て消去してもよい。また、保有履歴を残すために、オブジェクト毎に保有状態をフラグで示して管理してもよい。例えば、一度保有オブジェクトデータベースに書き込んだオブジェクトについて、保有状態であれば保有フラグを「１」、保有状態が解除されたら保有フラグを「０」とすることで、オブジェクトの保有状態を管理しながら保有履歴を残すことができる。

〔対応付け手段〕
対応付け手段５３は、オブジェクトをユーザに対応付ける機能を備える。対応付け手段５３の機能は、以下のようにして実現される。例えば、クエスト処理等において、カード等のオブジェクトをユーザに付与する場合、ＣＰＵ２１は、付与するオブジェクトのデータをオブジェクトデータベースから読み出した後に、読み出したデータを、対象となるユーザＩＤの保有オブジェクトデータベースまたはプレゼント受領データベースに書き込む。
なお、オブジェクトがユーザに付与される場合はクエスト処理に限らず、ユーザによるゲーム内ポイント等の対価の支払いを条件として、特定のオブジェクト、又は、複数のオブジェクトの中から所定の規則、又は、ランダムな確率で選択されたオブジェクトが付与されても良い。あるいは、「カード抽選用アイテム」を用いることで、当該アイテムを使用したユーザに、特定のオブジェクト、又は、複数のオブジェクトの中から所定の規則、又は、ランダムな確率で選択されたオブジェクトを付与してもよい。

〔関連付け手段〕
関連付け手段５４は、ユーザに対し他のユーザを関連付ける機能を備える。関連付け手段５４の機能は、例えば以下のようにして実現される。第１のユーザが他のユーザ（第２のユーザ）に対して仲間申請をし、第２のユーザが申請を承認した場合、ＣＰＵ２１は、第１のユーザの仲間データベースに第２のユーザのユーザＩＤを書き込むとともに、第２のユーザの仲間データベースに第１のユーザのユーザＩＤを書き込む。
あるいは、ゲーム内でユーザ同士のグループ（ギルド等）が設定されている場合、第１のユーザがあるグループへの参加が承認されたときに、当該グループ内の他のユーザ（第２のユーザ）のユーザＩＤを第１のユーザの仲間データベースに書き込むとともに、第２のユーザの仲間データベースに第１のユーザのユーザＩＤを書き込んでもよい。
なお、関連付け手段５４は、上述した申請及び承認の手順を採らずに、仲間を登録してもよい。例えば、ＣＰＵ２１は、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付けることで、指定先のユーザＩＤのユーザの承諾を得ることなく指定先のユーザＩＤを仲間として登録してもよい。
なお、ユーザ同士を関係付ける条件は、上述したものに限られず、同一のゲーム上のステージ若しくはエリアを実行するユーザや試合を行ったユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で対戦（バトル）を行うゲーム上のモードが存在する場合には、所定回数以上対戦を行ったユーザ同士や、協力して敵キャラクタと対戦をしたユーザ同士を自動的に仲間として登録してもよい。
本実施形態では、仲間データベースにデータを書き込むことによってユーザ同士の仲間関係の登録を実現する例を示したが、この例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。

〔解除手段〕
解除手段５５は、ユーザに対応付けられたオブジェクトの対応付けを解除する機能を備える。解除手段５５の機能は、例えば以下のようにして実現される。ユーザが体力回復用のアイテムを使用した場合、合成素材としてカードを使用した場合や、カードを売却した場合、ＣＰＵ２１は、ユーザＩＤの保有オブジェクトデータベースにおいて、使用済みのオブジェクトや売却済みのオブジェクトの保有状態を解除する。

〔取得手段〕
取得手段５６は、仲間のゲーム情報を取得する機能を備える。この機能は、例えば以下のようにして実現される。まず、第１のユーザが保有するカードが合成処理における素材カードとして決定された場合や、売却処理における売却するカードとして決定された場合、ＣＰＵ２１は、第１のユーザのユーザＩＤに対応する仲間データベースから仲間（第２のユーザ）のユーザＩＤ、プレゼント受領回数、プレゼント送付回数、関連度を読み出してＲＡＭ２３に書き出す。なお、ＣＰＵ２１が第２のユーザのユーザＩＤ、プレゼント受領回数、プレゼント送付回数、関連度を読み出すのは、所定の条件を満たす場合、例えば、ベースカードと素材カードの特技が異なる場合に限っても良い。
次に、ＣＰＵ２１は、第２のユーザに関するゲーム情報をゲーム情報データベースから読み出してＲＡＭ２３に書き出す。ここで、ゲーム情報には、例えば、クエスト処理の履歴、対戦処理の履歴、カードの保有履歴（図鑑）、合成処理の履歴（カードの使用回数等）、売却処理の履歴等がある。
例えば、ＣＰＵ２１は、第２のユーザのユーザＩＤに対応する保有オブジェクトデータベースに記憶されたオブジェクトＩＤを読み出してＲＡＭ２３に書き出す。ＣＰＵ２１は、保有オブジェクトデータベースに記憶されたオブジェクトＩＤを読み出してＲＡＭ２３に書き出してもよい。

なお、ＣＰＵ２１は、第１のユーザとの関連度に基づき読み出す第２のユーザを制限しても良い。例えば、第１のユーザとの関連度が所定の値以上であるユーザＩＤのみに対応する第２のユーザのゲーム情報を読み出してＲＡＭ２３に書き出してもよい。
あるいは、ＣＰＵ２１は、関連度が最も高いユーザＩＤのみに対応する第２のユーザのゲーム情報を読み出してＲＡＭ２３に書き出してもよい。
あるいは、ＣＰＵ２１は、プレゼント受領回数及び／又はプレゼント送付回数が所定数以上のユーザＩＤのみに対応する第２のユーザのゲーム情報を読み出してＲＡＭ２３に書き出してもよい。
あるいは、ＣＰＵ２１は、プレゼント受領回数及び／又はプレゼント送付回数が最も高いユーザＩＤのみに対応する第２のユーザのゲーム情報を読み出してＲＡＭ２３に書き出してもよい。

〔判定手段〕
判定手段５７は、ゲーム情報に基づき、オブジェクトの有益度を判定する機能を備える。判定手段５７の機能は、例えば以下のようにして実現される。

オブジェクトがカードである場合、例えば、以下の基準により有益度を判定することができる。
I．合成処理における有益度
例えば、ＣＰＵ２１は、第２のユーザのユーザＩＤに対応する保有オブジェクトデータベースにおいて、第１のオブジェクトの使用回数が所定の値以上である場合、第１のオブジェクトが第２のユーザにとってその使用用途において有益であると判定してもよい。例えば、使用回数が１０回以上であれば有益度を３、使用回数が５〜９回であれば有益度を２、使用回数が０〜４回であれば有益度を１と評価してもよい。

ＣＰＵ２１は、第２のユーザのユーザＩＤに対応する保有オブジェクトデータベースにおいて、当該カードの属性と同じ属性のカードＩＤが所定の数、又は所定比率以上、保有状態にある場合、当該カードが第２のユーザにとって有益である（合成処理において有益である）と判定してもよい。例えば、保有数が１０以上であれば有益度を３、保有数が５〜９であれば有益度を２、保有数が０〜４であれば有益度を１と評価してもよい。

ＣＰＵ２１は、第２のユーザのユーザＩＤに対応する保有オブジェクトデータベースにおいて、当該カードの特技と同じ特技のカードＩＤが所定の数、又は所定比率以上、保有状態にある場合、当該カードが第２のユーザにとって有益である（合成処理において有益である）と判定してもよい。例えば、保有数が１０以上であれば有益度を３、保有数が５〜９であれば有益度を２、保有数が０〜４であれば有益度を１と判定してもよい。

II．対戦処理における有益度
ＣＰＵ２１は、取得手段５６により読み出した第２のユーザの対戦処理の履歴を参照して、対戦相手の属性、又は、対戦相手の使用オブジェクト(カード)の属性毎の敗北回数を求め、当該第１のユーザのカードの属性が最も敗北回数が多い属性に対して有利な属性である場合、当該カードをチームに組み込むことで第２のユーザにとって対戦処理において有益であると判定してもよい。

さらに、例えば、当該カードのレア度が３以上ならば有益度を３、レア度が２であれば有益度を２、レア度が１であれば有益度を１、と判定してもよい。
また、ユーザの進行レベルに応じて有益度の判定基準を変更してもよい。
例えば、進行レベルが９以下の場合、レア度が３以上ならば有益度を３、レア度が２であれば有益度を２、レア度が１であれば有益度を１、と判定し、進行レベルが１０以上１９以下の場合、当該カードのレア度が４以上ならば有益度を３、レア度が３であれば有益度を２、レア度が２以下であれば有益度を１、と判定してもよい。
また、所定のカードの組み合わせでバトル等においてパラメータの変動等の効果が得られる特技がある場合、前記所定のカードの組み合わせと第２のユーザが保有しているカードの組み合わせに基づいて有益度を判定してもよい。例えば、カード：ａｂｃとカード：ｄｅｆの組み合わせがチームに含まれているときに特技が発動する場合、カード：ｄｅｆが第２のユーザの保有状態にあれば、カード：ａｂｃを有益であると判定してもよい。また、発動する特技の効果に応じて有益度を判定してもよい。例えば、カード：ａｂｃと第２のユーザが保有するカード：ｄｅｆの組み合わせがチームに含まれているときに発動する特技の効果が大きければ有益度を３、中程度であれば有益度を２、小さければ有益度を１、と判定してもよい。

III．保有履歴に基づく有益度
ＣＰＵ２１は、第１のユーザが合成処理に用いようとしたカードや、第１のユーザが売却しようとしたオブジェクト（以下、「第１のオブジェクト」という）のオブジェクトＩＤが、仲間（第２のユーザ）のユーザＩＤに対応する保有履歴（図鑑）に記録されていない場合、第１のオブジェクトが第２のユーザにとって有益であると判定する。なお、保有オブジェクトデータベースにおいて、オブジェクトの保有状態を解除する際にオブジェクトの情報を消去せずに、オブジェクトの保有状態が解除されたことをフラグで示す場合は、保有オブジェクトデータベースに記録されていないオブジェクトを有益と判定する。
また、例えば、「図鑑」が１ページにつき１６枚のカードからなり、１６枚のカードを集める度にユーザが報酬を得るようにゲームが設定されている場合、残り１枚を集めることで報酬が得られる状態の場合には有益度を３、残り２枚を集めることで報酬が得られる状態の場合には有益度を２、残り３枚を集めることで報酬が得られる状態の場合には有益度を１、と判定してもよい。また、所定のカードの組み合わせでバトル等においてパラメータの変動等の効果が得られる特技がある場合、前記所定のカードの組み合わせと第２のユーザが保有しているカードの履歴に基づいて有益か否かを判断しても良い。例えば、第１のユーザとの対応付けが解除されようとしていた第１のオブジェクトと第２ユーザに対応付けられたオブジェクトとを組み合わせると、所定の特技が発動するオブジェクトの組み合わせになる場合に有益と判断する。

IV．ユーザの設定に基づく有益度
ユーザが自身の欲しいオブジェクトを登録できるようにゲームが設定されている場合を想定する。この場合、例えば、データベース３１に、ユーザ毎に、ユーザが欲しいオブジェクトを登録するための「欲しいアイテムデータベース」を設けてもよい。このとき、ＣＰＵ２１は、第１のオブジェクトが第２のユーザのユーザＩＤに対応する「欲しいアイテムデータベース」に登録されている場合に、第１のオブジェクトが第２のユーザにとって有益であると判定してもよい。

オブジェクトに対応付けられたレア度に基づきオブジェクトの有益度を判定する場合、または、カード抽選時に抽選対象のオブジェクトのレア度を制限するカード抽選用アイテムの有益度を判定する場合、ＣＰＵ２１は、第２のユーザのユーザＩＤに対応する保有オブジェクトデータベースを参照し、第１ユーザとの対応付けを解除されようとしたオブジェクトのレア度、又は、カード抽選用アイテムの使用によって取得可能なカードのレア度と同じか、それ以上のレア度の保有カードの枚数が所定数以下であると判断した場合には、前記オブジェクト、又は、当該カード抽選用アイテムが第２のユーザにとって有益であると判定してもよい。

オブジェクトが体力回復アイテムの場合、ＣＰＵ２１は、ゲーム情報データベースを参照し、第２のユーザに対応するユーザＩＤの体力ポイントに応じて、有益度を判定しても良く、例えば、当該体力ポイントが所定の値以下であれば、当該体力回復アイテムが第２のユーザにとって有益であると判定してもよい。

〔第１の提示手段〕
第１の提示手段５８は、第１のオブジェクトの有益度に関する情報を第１のユーザに提示する機能を備える。第１の提示手段５８の機能は、例えば、以下のようにして実現される。
例えば、第１のユーザの通信端末１０において、ウェブページＰ７上で第１のユーザがメニューｍ３３（「確認する」）の選択操作をした場合、または、ウェブページＰ１２上で第１のユーザがメニューｍ４３（「確認する」）を選択操作した場合、通信端末１０のＣＰＵ１１は、その選択操作結果を含むＨＴＴＰリクエストをゲームサーバ２０へ送信する。ゲームサーバ２０のＣＰＵ２１は、当該リクエストを取得すると、第１のユーザの仲間（第２のユーザ）のゲーム情報を仲間データベース及びゲーム情報データベースを参照して取得し、取得したゲーム情報に基づいて、第１のオブジェクトの有益度を判定する。その後、ＣＰＵ２１は、図１３のＰ８に示すようなウェブページのＨＴＭＬデータを第１のユーザの通信端末１０に送信し、第１のユーザの通信端末１０の表示部１６に表示させる。
ウェブページＰ８には、仲間（第２のユーザ）毎に、第１のオブジェクトの有益度に関する情報を第１のユーザに提示する欄がリスト表示されるとともに、各第２のユーザに第１のオブジェクトを譲渡するためのメニューｍ６１〜ｍ６３（「プレゼントする」）が表示される。
なお、ウェブページＰ５のような通常の合成処理用のウェブページにおいてメニューｍ３１（「合成する」）の選択操作が行われた後、ＣＰＵ２１が第１のオブジェクトの有益度を判定し、Ｐ８に示すようなウェブページのＨＴＭＬデータを生成してもよい。また、有益度に関する情報やメニューｍ４３が表示されない通常の売却処理用のウェブページ（図示せず）においてメニューｍ４１（「売却する」）の選択操作を行った後、ＣＰＵ２１が第１のオブジェクトの有益度を判定し、Ｐ８に示すようなウェブページのＨＴＭＬデータを生成してもよい。

I．合成処理における有益度
例えば、ＣＰＵ２１は、当該カードと同じ特技を持つカードを第２のユーザが所定の枚数以上保有しているために、当該カードが有益であると判定した場合、第２のユーザの欄に「同じ特技のカードを集めています」と表示するウェブページＰ８のＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。
ＣＰＵ２１は、当該カードと同じ属性のカードを第２のユーザが所定の枚数以上保有しているために、当該カードが有益であると判定した場合は、仲間の欄に「同じ属性のカードを集めています」と表示するウェブページＰ８のＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。

II．対戦処理における有益度
ＣＰＵ２１は、当該カードをチームに組み込むことで第２のユーザにとって対戦処理において有益であると判定した場合は、第２のユーザの欄に「チーム構築のため欲しがっています」と表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。

III．保有履歴に基づく有益度
ＣＰＵ２１は、当該カードのオブジェクトＩＤが第２のユーザの保有履歴（図鑑）に記録されていないために、当該カードが有益であると判定した場合は、第２のユーザの欄に「図鑑に登録されていません」と表示するウェブページＰ８のＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。

ここで、ＣＰＵ２１は、複数の基準で有益度が判定される場合、全ての判定基準に対応する有益度に関する情報を表示するウェブページＰ８のＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。ＣＰＵ２１は、判定基準に優先順位をあらかじめ設定し、当該優先順位の順に判定基準に沿った有益度を表示するようにしても良い。
また、当該優先順位に基づき、有益度の表示対象を制限しても良い。例えば、有益度があると判定された判定基準が複数ある場合、最も優先順位が高い判定基準に対応する有益度に関する情報のみを表示するようにしてもよいし、優先順位は高いが有益度が所定の値以下である判定基準に対応する有益度に関する情報は表示しないようにしてもよい。

例えば、（１）合成処理における有益度、（２）対戦処理における有益度、（３）保有履歴に基づく有益度をこの順番で優先させることをあらかじめ定めておく。そして、第２のユーザに対して、第１のオブジェクトが合成処理において有益であると判定し、かつ、第１のオブジェクトのオブジェクトＩＤが保有履歴（図鑑）に記憶されていないために有益であると判定した場合、ＣＰＵ２１は、第１のオブジェクトが合成処理において有益である旨（例えば、「Ｂさんが合成のために欲しがっています」）の表示をするウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。

あるいは、ＣＰＵ２１は、複数の基準で有益度が判定される場合、当該複数の有益度の比較結果に基づいて、表示順を決定しても良い。また、当該複数の有益度の比較結果に基づいて、表示対象を制限しても良く、例えば、最も有益度が高い判定基準に対応する有益度に関する情報のみを表示するようにしてもよいし、有益度が所定の値以上である判定基準に対応する有益度に関する情報のみを表示するようにしても良い。例えば、ＣＰＵ２１は、第１のオブジェクトの第２のユーザにおける有益度について、（１）合成処理における有益度がＢ、（２）対戦処理における有益度がＣ、（３）保有履歴に基づく有益度がＡ、と判定された場合、判定基準（３）に基づき、第２のユーザの欄に「このカードで図鑑コンプリート！」と表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。
なお、判定基準に優先度を設け、有益度と優先度に基づいて、表示順を決定したり、表示する対象を制限しても良い。例えば、それぞれの基準における有益度が同一の場合には、判定基準の優先度に基づき、優先度が高い判定基準の有益度を表示するようにしても良い。

また、ＣＰＵ２１は、第２のユーザが複数いる場合に、それぞれの第２ユーザに対する第１のオブジェクトの有益度に基づいて、第２ユーザの有益度の表示順や表示対象を制限しても良い。例えば、第１のオブジェクトの有益度が高い第２のユーザの欄から順にリスト表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。例えば、第１のオブジェクトの有益度が、ユーザ：Ｂでは３、ユーザ：Ｃでは２、ユーザ：Ｄでは１と判断された場合、ＣＰＵ２１は、ユーザ：Ｂの欄、ユーザ：Ｃの欄、ユーザ：Ｄの欄の順にリスト表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。

また、ＣＰＵ２１は、有益度が所定の値以上である場合にのみ第２のユーザの欄を表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。例えば、有益度が２以上である場合に第２のユーザの欄を表示するように基準をあらかじめ設定しておく。そしてＣＰＵ２１は、第１のオブジェクトの有益度が、ユーザ：Ｂでは３、ユーザ：Ｃでは２、ユーザ：Ｄでは１と判断した場合、ユーザ：Ｂの欄、ユーザ：Ｃの欄のみをリスト表示し、ユーザ：Ｄの欄を表示しないウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。ウェブページにこの第２のユーザの欄を表示するか否かの基準は、第１のユーザが設定を変更できるようにしてもよい。

あるいは、ＣＰＵ２１は、ＲＡＭ２３に書き出した第１ユーザに対する第２ユーザの関連度に基づき、当該複数の第２ユーザの有益度の表示順や表示対象を制限しても良い。例えば、第１ユーザに対する関連度が所定の値であるユーザＩＤのみに対応する第２のユーザの欄をリスト表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。この場合、ＣＰＵ２１は、関連度が高い第２のユーザの欄から順にリスト表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。
あるいは、ＣＰＵ２１は、ＲＡＭ２３に書き出した関連度が最も高いユーザＩＤのみに対応する第２のユーザの欄のみを表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。

あるいは、ＣＰＵ２１は、ＲＡＭ２３に書き出したプレゼント受領回数及び／又はプレゼント送付回数に基づき、当該複数の第２ユーザの有益度の表示順や表示対象を制限しても良い。例えば、当該プレゼント受領回数及び／又はプレゼント送付回数が所定数以上のユーザＩＤのみに対応する第２のユーザの欄をリスト表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。この場合、ＣＰＵ２１は、プレゼント受領回数及び／又はプレゼント送付回数が高い第２のユーザの欄から順にリスト表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。
あるいは、ＣＰＵ２１は、ＲＡＭ２３に書き出したプレゼント受領回数及び／又はプレゼント送付回数が最も高いユーザＩＤのみに対応する第２のユーザの欄のみを表示するウェブページのＨＴＭＬデータを生成して第１のユーザの通信端末１０に送信してもよい。
この場合、ＣＰＵ２１は、第２のユーザの欄にプレゼント送付回数およびプレゼント受領回数の両方またはいずれか一方のみを表示するウェブページのＨＴＭＬデータを生成してもよいし、両方とも表示しないウェブページのＨＴＭＬデータを生成してもよい。

〔譲渡手段〕
譲渡手段５９は、第１のオブジェクトを第１のユーザから第２のユーザへ譲渡する機能を備える。譲渡手段５９の機能は、例えば、以下のようにして実現される。第１のユーザが第２のユーザにオブジェクトを譲渡した場合、ＣＰＵ２１は、第１のユーザの保有オブジェクトデータベースにおいて、第１のユーザが譲渡した第１のオブジェクトに対応するオブジェクトＩＤの情報を消去すると同時に、第２のユーザのプレゼント受領データベースにおいて、第２のユーザが譲り受けたオブジェクトに対応するオブジェクトＩＤの情報を書き込む。

また、第１のユーザが第２のユーザに第１のオブジェクトを譲渡すると同時に、第２のユーザが第１のユーザに第２のオブジェクトを譲渡する場合、すなわち、第１のユーザの第１のオブジェクトと第２のユーザの第２のオブジェクトを交換（トレード）する場合、ＣＰＵ２１は、第１のユーザの保有オブジェクトデータベースにおいて、第１のユーザが譲渡した第１のオブジェクトに対応するオブジェクトＩＤの情報を消去するととともに、第１のユーザのプレゼント受領データベースにおいて、第１のユーザが譲り受けた第２のオブジェクトに対応するオブジェクトＩＤの情報を書き込む。同時に、ＣＰＵ２１は、第２のユーザの保有オブジェクトデータベースにおいて、第２のユーザが譲渡した第２のオブジェクトに対応するオブジェクトＩＤの情報を消去するととともに、第２のユーザのプレゼント受領データベースにおいて、第２のユーザが譲り受けた第１のオブジェクトに対応するオブジェクトＩＤの情報を書き込む。

なお、実行手段５２が合成処理を完了する前や、売却処理を完了する前に譲渡処理を実行する機能は、例えば以下のようにして実現される。図１２のウェブページＰ７においてユーザがメニューｍ３３（「確認する」）の選択操作を行った場合や、図１５のウェブページＰ１２においてユーザ：Ａがメニューｍ４３（「確認する」）の選択操作を行った場合、ゲームサーバ２０のＣＰＵ２１は、図１３に示すウェブページＰ８を表示するためのＨＴＭＬデータを生成する。ウェブページＰ８上でユーザ：Ａがメニューｍ６１の選択操作を行うと、ＣＰＵ２１は、ユーザ：Ａの保有オブジェクトデータベースにおいて譲渡するカード：ａｂｃのカードＩＤの情報を消去し、カード：ａｂｃのユーザ：Ａとの対応付けを解除するとともに、カード：ａｂｃのカードＩＤの情報をユーザ：Ｂのプレゼント受領データベースに書き込む。メニューｍ６２、ｍ６３の選択操作が行われた場合も同様である。
ユーザによりメニューｍ６４が選択操作された場合、ＣＰＵ２１は、元のウェブページＰ７またはＰ１２を表示するためのＨＴＭＬデータを生成する。

〔第２の提示手段〕
第２の提示手段６０は、第１のオブジェクトの有益度に関する情報を第２のユーザに提示する機能を備える。第２の提示手段６０の機能は、例えば、以下のようにして実現される。
第１のオブジェクトを第１のユーザから第２のユーザへ譲渡した後、ＣＰＵ２２は、第２のユーザの通信端末１０の表示部１６に表示するウェブページＰ９のＨＴＭＬデータを生成して第２のユーザの通信端末１０に送信する。トップページＰ９には、第２のユーザにプレゼントが譲渡（プレゼント）された事を示すメニューｍ５（「プレゼントが届いています」）が表示される。
なお、判定手段５７により複数の基準で有益度が判定される場合、第２の提示手段６０は、全ての判定基準に対応する有益度に関する情報を表示してもよい。あるいは、第１の提示手段５８と同様に、優先順位の順に判定基準に沿った有益度を表示してもよい。また、当該優先順位に基づき、有益度の表示対象を制限してもよい。例えば、有益度があると判定された判定基準が複数ある場合、最も優先順位が高い判定基準に対応する有益度に関する情報のみを表示するようにしてもよいし、有益度が所定の値以上である判定基準に対応する有益度に関する情報のみを表示するようにしてもよい。
あるいは、複数の基準で有益度が判定される場合、当該複数の有益度の比較結果に基づいて、表示順を決定してもよい。また、当該複数の有益度の比較結果に基づいて、表示対象を制限しても良く、例えば、最も有益度が高い判定基準に対応する有益度に関する情報のみを表示するようにしてもよいし、有益度が所定の値以上である判定基準に対応する有益度に関する情報のみを表示するようにしてもよい。
あるいは、当該複数の有益度の比較結果に基づいて、表示順を決定してもよい。また、当該複数の有益度の比較結果に基づいて、表示対象を制限しても良く、例えば、最も有益度が高い判定基準に対応する有益度に関する情報のみを表示するようにしてもよいし、有益度が所定の値以上である判定基準に対応する有益度に関する情報のみを表示するようにしてもよい。
なお、判定基準に優先度を設け、有益度と優先度に基づいて、表示順を決定したり、表示する対象を制限してもよい。例えば、それぞれの基準における有益度が同一の場合には、判定基準の優先度に基づき、優先度が高い判定基準の有益度を表示するようにしてもよい。

第２のユーザがメニューｍ５の選択操作を行うと、ＣＰＵ２１は、図１４のＰ１０に示すようにウェブページを更新する。ウェブページＰ１０には、第２のユーザに譲渡されたプレゼント（オブジェクト）のリストが表示される。各プレゼントの欄には、例えば、譲渡した第１のユーザ名（「Ａさん」）が表示される。また、各プレゼントの欄にユーザ：Ｂに対する有益度に関する情報（「合成素材用」、「体力回復用」）を譲渡した第１のユーザ名とともに表示させてもよい。また、当該プレゼントを保有するためのメニューｍ５２、ｍ５４（「受け取る」）が表示される。また、当該プレゼントを使用するためのショートカットメニューｍ５１（「合成する」）、ショートカットメニューｍ５３（「使う」）を表示させてもよい。例えば、プレゼントが合成に使用すると有益度の高いカードである場合には、当該カードを使用するためのショートカットメニューｍ５１(「合成する」)を表示させ、プレゼントが体力を回復するために使用すると有益度が高いアイテム（「回復薬」）であればショートカットメニューｍ５３（「使う」）を表示させてもよい。あるいは、プレゼントが「チーム編成用」として有益度の高いカードである場合には、当該カードをチームに編成するためのチーム編成用画面へのショートカットメニューを表示させてもよい。

〔評価手段〕
評価手段６１は、第１のユーザに関連付けられた第２のユーザの関連度を評価する機能を備える。評価手段６１の機能は、例えば、以下のようにして実現される。
例えば、ＣＰＵ２１は、第１のユーザの仲間データベースを参照し、第２のユーザとのプレゼントや挨拶の受領回数が１０回以上であれば関連度を３、プレゼントや挨拶の受領回数が５回以上９回以下であれば関連度を２、プレゼントや挨拶の受領回数が４回以下であれば関連度を１と判定することができる。あるいは、第２のユーザとの協働プレイの履歴を記憶しておく場合には、ＣＰＵ２１は、例えば、協働プレイの回数が１０回以上であれば関連度を３、協働プレイの回数が５回以上９回以下であれば関連度を２、協働プレイの回数が１回以上４回以下であれば関連度を１と判定してもよい。
なお、前記履歴情報については、評価タイミングから一定期間前までの回数に基づき判定するようにしても良い。このように評価期間を限定することで直近のユーザ関係を反映することができ、且つ、データの保存に関する負荷が軽減される。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１７〜図２２のフローチャートを参照して説明する。図１７は、本実施形態のゲームにおいてクエスト処理を行うときのフローチャートである。図１８は、本実施形態のゲームにおいて、対戦処理を行うときのフローチャートである。図１９は、本実施形態のゲームにおいて、合成処理を行うときのフローチャートである。図２０は、本実施形態のゲームにおいて、売却処理を行うときのフローチャートである。図２１は、本実施形態のゲームにおいて、譲渡処理を行うときの譲渡するユーザ側のフローチャートである。図２２は、本実施形態のゲームにおいて、譲渡処理を行った後の譲り受けたユーザ側のフローチャートである。
なお、図１７〜図２２のフローチャートにおける各処理の実行に伴って適宜、Ｐ１〜Ｐ１２の各ウェブページを表示するためのＨＴＭＬデータがゲームサーバ２０から通信端末１０宛に送信されるが、煩雑とならないようにＨＴＭＬデータの送信処理をフローチャートには記載しない場合もある。フローチャート上で、ウェブページＰ１〜Ｐ１２の各々が表示されるタイミングは、Ｐ１〜Ｐ１２の符号で示してある。
なお、図１７〜図２１のフローチャートでは、ユーザ：Ａがゲームを実行する場合を一例として説明する。

〔クエスト処理〕
先ず図１７のフローチャートにおいて、トップページＰ１上でメニューｍ１（「クエスト」）が選択操作されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図９のＰ２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）が選択操作されたことを認識すると（ステップＳ１００：ＹＥＳ）、複数のモンスターカードの中から選択されたモンスターカードをユーザ：Ａに付与するか否かについて、所定の、あるいはランダムな確率で決定する。モンスターカードをユーザ：Ａに付与することを決定すると（ステップＳ１０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａにモンスターカードを対応付ける付与する処理を行う（ステップＳ１０４）。この場合、ＣＰＵ２１は、オブジェクトデータベースにアクセスし、クエスト用に予め設けられた複数のモンスターカードの中から、付与されるモンスターカードを選択する。次に、ＣＰＵ２１は、選択したモンスターカードのデータをオブジェクトデータベースから読み出した後に、保有オブジェクトデータベースにアクセスして、読み出したデータを書き込む。なお、ＣＰＵ２１は、ステップＳ１０２においてモンスターカードをユーザに付与しないことを決定した場合（ステップＳ１０２：ＮＯ）、ステップＳ１０６の処理に移行する。
ＣＰＵ２１は、ゲーム情報データベースにアクセスしてユーザ：Ａの達成率、体力ポイント、経験値、合成ポイント等を更新し、更新後の値を表示するＨＴＭＬデータを生成してユーザ：Ａの通信端末１０に送信する（ステップＳ１０６）。
なお、ＣＰＵ２１は、メニューｍ１０が選択操作されずに所定時間経過した場合、又は、メニューｍ１０以外の選択操作がされた場合（ステップＳ１００：ＮＯ）、クエスト処理を終了してもよい。
また、ＣＰＵ２１は、ステップＳ１０２の処理において、ユーザ：Ａに対して所定のアイテム（例えば、ユーザの体力ポイント及びイベントの抽選権利回数を上限値まで回復させるアイテム）を、所定の、あるいはランダムな確率で付与するか否かについて決定してもよい。

〔対戦処理〕
次に、図１８を参照して、対戦処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、トップページＰ１上でメニューｍ２（「対戦」）が選択操作されたことを認識すると、Ｐ３に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。
ＣＰＵ２１は、ウェブページＰ３上でメニューｍ２０（「対戦開始」）が選択操作されたことを認識すると（ステップＳ２００：ＹＥＳ）、処理対象のユーザ（ここでは、ユーザ：Ａ）のチームと、対戦相手（コンピュータ又は他のユーザ）のチームとの対戦結果を決定する処理を行う（ステップＳ２０２）。
そして、ＣＰＵ２１は、ユーザ：Ａが対戦に勝利した場合（ステップＳ２０４：ＹＥＳ）、ユーザ：Ａに対して合成ポイントを加算する処理を行う（ステップＳ２０６）。ここで、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：Ａが勝利した場合、ゲーム情報データベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する合成ポイントの値を所定値（例えば１００）だけ増加させる。一方、ＣＰＵ２１は、ユーザ間対戦においてユーザ：Ａが勝利した場合、ゲーム情報データベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する合成ポイントの値を所定値（例えば５００）だけ増加させると同時に、対戦相手のユーザＩＤに対応する合成ポイントの値を所定値（例えば５００）だけ減少させる。

一方、ＣＰＵ２１は、ユーザ：Ａが対戦に敗北した場合（ステップＳ２０４：ＮＯ）、ユーザ：Ａに対して合成ポイントを減算する処理を行う（ステップＳ２０８）。ここで、ＣＰＵ２１は、ＣＯＭ対戦においてユーザ：Ａが敗北した場合、ゲーム情報データベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する合成ポイントの値を所定値（例えば１００）だけ減少させる。一方、ＣＰＵ２１は、ユーザ間対戦においてユーザ：Ａが敗北した場合、ゲーム情報データベースにアクセスして、ユーザ：ＡのユーザＩＤに対応する合成ポイントの値を所定値（例えば５００）だけ減少させると同時に、対戦相手のユーザＩＤに対応する合成ポイントの値を所定値（例えば５００）だけ増加させる。

なお、ＣＰＵ２１は、ウェブページＰ３又はＰ６上でメニューｍ２０（「対戦開始」）が選択操作されない状態で所定時間経過した場合、又は、メニューｍ２０以外の選択操作がされた場合（ステップＳ２００：ＮＯ）、対戦処理を終了してもよい。

〔合成処理〕
次に、図１９を参照して、合成処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、トップページＰ１上でメニューｍ３（「合成」）が選択操作されたことを認識すると（ステップＳ３００：ＹＥＳ）、Ｐ５に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。
次に、ユーザ：Ａがメニューｍ３４、ｍ３５を操作することにより、例えばベースカード：ａｂｃ、素材カード：ｄｅｆを決定する（ステップＳ３０２）。なお、メニューｍ３が選択操作された際に素材カードが自動選択されてもよい。次に、ＣＰＵ２１は、ユーザ：Ａの仲間データベースを参照する（ステップＳ３０４）。次に、ＣＰＵ２１は、ユーザ：Ａの仲間（第２のユーザ）における、素材カード：ｄｅｆの有益度を判定するのに用いる、第２のユーザのゲーム情報を取得する（ステップＳ３０６）。例えば、ＣＰＵ２１は、第２のユーザのユーザＩＤに対応するゲーム情報データベース、保有オブジェクトデータベース、対戦処理の履歴、オブジェクトの保有履歴、「欲しいアイテムデータベース」等を参照して第２のユーザのゲーム情報を取得する。
次に、ＣＰＵ２１は、取得した第２のユーザのゲーム情報に基づいて、素材カード：ｄｅｆが第２のユーザにとって有益か否かを判定する（ステップＳ３０８）。素材カード：ｄｅｆが第２のユーザにとって有益である場合（ステップＳ３０８：ＹＥＳ）、ＣＰＵ２１は、図１２に示すように、当該カードを第２のユーザが必要としているかもしれない旨のテキストとともに、メニューｍ３３（「確認する」）を含むウェブページＰ７のＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信し、ステップＳ３１０に移行する。一方、素材カード：ｄｅｆが第２のユーザにとって有益でない場合（ステップＳ３０８：ＮＯ）、ＣＰＵ２１は、図１１に示すように、通常の合成画面であるウェブページＰ５のＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信し、ステップＳ３１２に移行する。
ステップＳ３１０において、ＣＰＵ２１は、ウェブページＰ７のメニューｍ３３（「確認する」）が操作されたか否かを判定する。メニューｍ３３（「確認する」）が操作されたと判断した場合（ステップＳ３１０：ＹＥＳ）、ＣＰＵ２１は、図２１に示す譲渡処理に移行する。メニューｍ３３（「確認する」）が操作されない場合（ステップＳ３１０：ＮＯ）、つまりメニューｍ３１又はｍ３２が操作された場合、ＣＰＵ２１は、ステップＳ３１２に移行する。
ステップＳ３１２において、ＣＰＵ２１は、メニューｍ３１（「合成する」）が操作されたか否かを判定する。ＣＰＵ２１は、メニューｍ３１（「合成する」）が選択操作されたと判定すると（ステップＳ３１２：ＹＥＳ）、ベースカード：ａｂｃと、素材カード：ｄｅｆとの合成結果を決定する処理を行う（ステップＳ３１４）。次に、ＣＰＵ２１は、保有オブジェクトデータベースにアクセスして、ユーザ：Ａが保有するベースカード：ａｂｃの攻撃力、防御力、成長レベルを更新し、更新後の値（合成結果）を表示するＨＴＭＬデータを生成してユーザ：Ａの通信端末１０に送信する。メニューｍ３２（「キャンセル」）が選択操作された場合（ステップＳ３１２：ＮＯ）、合成処理を終了する。なお、ＣＰＵ２１は、メニューｍ３１、ｍ３２、ｍ３３以外の選択操作がされた場合（ステップＳ３１２：ＮＯ）、合成処理を終了してもよい。また、トップページＰ１上でメニューｍ３以外の選択操作がされた場合（ステップＳ３００：ＮＯ）、合成処理を終了してもよい。

〔売却処理〕
次に、図２０を参照して、売却処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、トップページＰ１上でメニューｍ４（「売却」）が選択操作されたことを認識すると（ステップＳ４００：ＹＥＳ）、ユーザ：Ａが売却するカードを選択するためのウェブページ（図示せず）を表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。
次に、ユーザ：Ａが売却するカード（売却カード）を選択する（ステップＳ４０２）。なお、メニューｍ４が選択操作された際に売却カードが自動選択されてもよい。次に、ＣＰＵ２１は、ユーザ：Ａの仲間データベースを参照する（ステップＳ４０４）。次に、ＣＰＵ２１は、ユーザ：Ａの仲間（第２のユーザ）における、売却カードの有益度を判定するのに用いる、第２のユーザのゲーム情報を取得する（ステップ４０６）。例えば、ＣＰＵ２１は、第２のユーザのユーザＩＤに対応するゲーム情報データベース、保有オブジェクトデータベース、対戦処理の履歴、オブジェクトの保有履歴、「欲しいアイテムデータベース」等を参照して第２のユーザのゲーム情報を取得する。
次に、ＣＰＵ２１は、取得した第２のユーザのゲーム情報に基づいて、売却カードが第２のユーザにとって有益か否かを判定する（ステップＳ４０８）。売却カードが第２のユーザにとって有益である場合（ステップＳ４０８：ＹＥＳ）、ＣＰＵ２１は、図１５に示すように、当該カード：ａｂｃを第２のユーザが必要としているかもしれない旨のテキストとともに、メニューｍ４３（「確認する」）を含むウェブページＰ１２のＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信し、ステップＳ４１０に移行する。一方、売却カードが第２のユーザにとって有益でない場合（ステップＳ４０８：ＮＯ）、ＣＰＵ２１は、通常の売却画面（図示せず）であるウェブページのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信し、ステップＳ４１２に移行する。
ステップＳ４１０において、ＣＰＵ２１は、ウェブページＰ１２のメニューｍ４３（「確認する」）が操作されたか否かを判定する。メニューｍ４３（「確認する」）が操作されたと判断した場合（ステップＳ４１０：ＹＥＳ）、ＣＰＵ２１は、図２１に示す譲渡処理に移行する。メニューｍ４３（「確認する」）が操作されない場合（ステップＳ４１０：ＮＯ）、つまりメニューｍ４１又はｍ４２が操作された場合、ＣＰＵ２１は、ステップＳ４１２に移行する。
ステップＳ４１２において、ＣＰＵ２１は、メニューｍ４１（「売却する」）が操作されたか否かを判定する。ＣＰＵ２１は、メニューｍ４１（「売却する」）が選択操作されたと判定すると（ステップＳ４１２：ＹＥＳ）、売却結果を決定する。具体的には、ＣＰＵ２１は、保有オブジェクトデータベースにおいてユーザ：Ａが保有する売却カードの情報を消去するとともに、ゲーム情報データベースにおいて、ユーザ：ＡのユーザＩＤに対応する合成ポイントに対し、カード：ａｂｃの売却対価に相当する合成ポイントを加算する（ステップＳ４１４）。その後、ＣＰＵ２１は、カード：ａｂｃの売却対価（売却結果）を表示するＨＴＭＬデータを生成してユーザ：Ａの通信端末１０に送信する。

メニューｍ４２（「キャンセル」）が選択操作された場合（ステップＳ４１２：ＮＯ）、ＣＰＵ２１は売却処理を終了する。なお、ＣＰＵ２１は、メニューｍ４１、ｍ４２、ｍ４３以外の選択操作がされた場合（ステップＳ４１２：ＮＯ）、売却処理を終了してもよい。また、トップページＰ１上でメニューｍ４以外の選択操作がされた場合（ステップＳ４００：ＮＯ）、売却処理を終了してもよい。

〔譲渡処理〕
次に、図２１を参照して、譲渡処理を行うときの譲渡するユーザ側のフローチャートの一例を説明する。
ＣＰＵ２１は、ウェブページＰ７上でメニューｍ３３（「確認する」）が選択操作されたことを認識した場合、または、ウェブページＰ１２上でメニューｍ４３（「確認する」）が選択操作されたことを認識した場合、ステップＳ３０８またはＳ４０８で判断された有益度に関する情報を含む、Ｐ８に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。

ＣＰＵ２１は、ウェブページＰ８上でメニューｍ６１〜ｍ６３（「プレゼントする」）のいずれかが選択操作されたことを認識すると（ステップＳ５００：ＹＥＳ）、メニューｍ６１〜ｍ６３のいずれが選択操作されたかを判断する（ステップＳ５０２）。
メニューｍ６１が操作された場合、ユーザ：Ｂに譲渡する。具体的には、ＣＰＵ２１は、ユーザ：ＡのユーザＩＤに対応する保有オブジェクトデータベースのカード：ｄｅｆに対応するカードＩＤの情報を消去するとともに、ユーザ：ＢのユーザＩＤに対応するプレゼント受領データベースにカード：ａｂｃに対応するカードＩＤの情報を書き込む（ステップＳ５０４）。
メニューｍ６２が操作された場合、ユーザ：Ｃに譲渡する。具体的には、ＣＰＵ２１は、ユーザ：ＡのユーザＩＤに対応する保有オブジェクトデータベースのカード：ｄｅｆに対応するカードＩＤの情報を消去するとともに、ユーザ：ＣのユーザＩＤに対応するプレゼント受領データベースにカード：ａｂｃに対応するカードＩＤの情報を書き込む（ステップＳ５０６）。
メニューｍ６３が操作された場合、ユーザ：Ｄに譲渡する。具体的には、ＣＰＵ２１は、ユーザ：ＡのユーザＩＤに対応する保有オブジェクトデータベースのカード：ｄｅｆに対応するカードＩＤの情報を消去するとともに、ユーザ：ＤのユーザＩＤに対応するプレゼント受領データベースにカード：ａｂｃに対応するカードＩＤの情報を書き込む（ステップＳ５０８）。
その後、ＣＰＵ２１は、カード：ｄｅｆの譲渡が完了したことを表示するＨＴＭＬデータを生成してユーザ：Ａの通信端末１０に送信する。

なお、ＣＰＵ２１は、ウェブページＰ８上でメニューｍ６４（「キャンセル」）が選択操作された場合、あるいは、メニューｍ６１〜ｍ６３（「プレゼントする」）のいずれもが選択操作されない状態で所定時間経過した場合、譲渡処理を終了してもよい（ステップＳ５００：ＮＯ）。

次に、図２２を参照して、譲渡処理後の譲り受けたユーザ側のフローチャートの一例を説明する。なお、図２２では、プレゼントを譲り受けたユーザ：Ｂがゲームを実行する場合を一例として説明する。
ＣＰＵ２１は、ウェブページＰ９上でメニューｍ５（「プレゼントが届いています」）が選択操作されたことを認識した場合、Ｐ１０に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。なお、ユーザ：Ａがユーザ：Ｂに譲渡する前に判定された有益度に関する情報を用いてウェブページＰ１０のＨＴＭＬデータを生成してもよいし、ユーザ：ＢがウェブページＰ９上でメニューｍ５（「プレゼントが届いています」）を選択操作したタイミングでユーザ：Ｂにとっての有益度を判定し、判定された有益度に関する情報を用いてウェブページＰ１０のＨＴＭＬデータを生成してもよい。ユーザ：Ａがプレゼントを譲渡した時からユーザ:Ｂがプレゼントを保有するまでにユーザ：Ｂのゲーム情報が変更される場合があるため、ユーザ:Ｂがプレゼントを保有する時にユーザ：Ｂにとっての有益度を判定すると、直近のユーザ：Ｂのゲーム情報を反映して有益度を判定することができる。以下では、ユーザ：ＢがウェブページＰ９上でメニューｍ５（「プレゼントが届いています」）を選択操作したタイミングでユーザ：Ｂにとっての有益度を判定する場合について説明する。
ウェブページＰ９上でメニューｍ５（「プレゼントが届いています」）が選択操作されたことをＣＰＵ２１が認識した場合（ステップＳ６００：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ｂのゲーム情報を取得する（ステップＳ６０２）。例えば、ＣＰＵ２１は、ユーザ：Ｂのゲーム情報データベース、保有オブジェクトデータベース、対戦処理の履歴、オブジェクトの保有履歴、「欲しいアイテムデータベース」等を参照して第２のユーザのゲーム情報を取得する。次に、ＣＰＰＵ２１は、取得したゲーム情報を参照して、プレゼント受領データベース内のオブジェクト（受領オブジェクト）のユーザ：Ｂにとっての有益度を判定する（ステップＳ６０４）。その後、ＣＰＵ２１は、受領オブジェクト毎に、判定した有益度に関する情報（「合成素材用」、「体力回復用」）とともに、有益度に対応するショートカットメニューｍ５１（「合成する」）、ｍ５３（「使う」）、メニューｍ５２、ｍ５４（「受け取る」）を表示する。

ＣＰＵ２１は、ウェブページＰ１０上でショートカットメニューｍ５１（「合成する」）、ｍ５３（「使う」）またはメニューｍ５２、ｍ５４（「受け取る」）のいずれかが選択操作されたことを認識すると（ステップＳ６０６：ＹＥＳ）、ＣＰＵ２１は、保有処理を行う。すなわち、ユーザ：ＢのユーザＩＤに対応するプレゼント受領データベースから受領オブジェクトのオブジェクトＩＤの情報を削除するとともに、ユーザ：ＢのユーザＩＤに対応する保有オブジェクトデータベースに当該オブジェクトＩＤの情報を書き込む（ステップＳ６０８）。
次に、ＣＰＵは、ショートカットメニューｍ５１が選択操作されたか否かを判断する（ステップＳ６１０）。ショートカットメニューｍ５１が選択操作された場合（ステップＳ６１０：ＹＥＳ）、ＣＰＵ２１は、プレゼントされたオブジェクトであるカードを素材カードとする合成処理を行う（ステップＳ６１２）。

ショートカットメニューｍ５１が選択操作されずに（ステップＳ６１０：ＮＯ）、ショートカットメニューｍ５３（「使う」）が選択操作された場合（ステップＳ６１４：ＹＥＳ）、ＣＰＵ２１は当該オブジェクトの使用処理を行う(ステップＳ６１６)。例えば、プレゼントされたオブジェクトが回復薬であれば、保有オブジェクトデータベースから当該回復薬の情報を削除するとともに、ユーザ：Ｂの体力ポイントを増加（回復）させる。
ＣＰＵ２１は、ウェブページＰ１０上でショートカットメニューｍ５１、ｍ５３のいずれも操作されず、メニューｍ５２、ｍ５４が操作された場合（ステップＳ６１４：ＮＯ）処理を終了する。なお、ショートカットメニューｍ５１、ｍ５３、メニューｍ５２、ｍ５４以外の選択操作がされた場合（ステップＳ６０６：ＮＯ）、処理を終了してもよい。また、ウェブページＰ９上でメニューｍ５以外が選択操作された場合（ステップＳ６００：ＮＯ）、処理を終了してもよい。
なお、本実施例ではメニューｍ５１の選択操作(合成処理)の有無の後にメニューｍ５３選択操作(使用処理)を判定したがこれに限らず、これらの処理は並行に行ってもよいし、異なる順序で判定しても良い。

以上説明したように、このゲーム制御装置では、第１のユーザが、第１のユーザに対応付けられた第１のオブジェクトの対応付けを解除しようとしたときに、第１のユーザに関連付けられた第２のユーザにおける第１のオブジェクトの有益度に関する情報が提示されるので、第１のオブジェクトの第１のユーザへの対応付けが解除される前に、第１のユーザが当該有益度を知ることができる。その結果、第１のユーザから第２のユーザへのオブジェクトのプレゼントや、第１のユーザと第２のユーザとの間のオブジェクトの交換（トレード）をする機能が活用され、ユーザ間でコミュニケーションの機会を増大させることができる。

本実施形態において、第１のオブジェクトの有益度が所定値以上である場合に有益度に関する情報が第１のユーザに提示される場合、第１のユーザに提示する情報量を低下させることができるとともに、第１のユーザは必要性の高い情報のみを受け取ることができるが、本発明はこれに限られない。例えば、有益度を所定値以上か否かに関わらず全て表示しても良く、別の条件に従って表示する対象を制限しても良い。

本実施形態において、第１のオブジェクトを譲り受けた第２のユーザが、第２の提示手段６０により第１のオブジェクトの有益度に関する情報を提示される場合、第２のユーザは第１のオブジェクトの使用方法を知ることができるが、本発明はこれに限られない。例えば、第１のオブジェクトの有益度に関する情報を第２のユーザに有益度を表示しなくても良いし、第１のオブジェクトの有益度のみを表示しても良い。

本実施形態において、使用方法毎の第１オブジェクトの有益度に関する情報に基づいた操作釦を第２のユーザに提示する場合、第２のユーザが当該操作釦を選択操作することで第１のオブジェクトを前記使用方法で使用する処理が実行され、操作性が良好となるが、本発明はこれに限られない。例えば、第１のオブジェクトの有益度を表示するのみで、前記使用方法で使用する処理を実行するための操作釦を表示しなくても良い。

本実施形態において、第１のオブジェクトについて判定された複数の有益度の少なくとも一部、または、最も高い有益度に関する情報を第１のユーザに提示する場合、第１のユーザは第１のオブジェクトを第２のユーザに譲渡するか否かについて適切に判断できるが、本発明はこれに限られない。例えば、第１のオブジェクトについて判定された複数の有益度の全てを表示しても良いし、一定以上の有益度を有する情報のみ表示するようにしてもよい。

本実施形態において、第１のユーザに関連付けられる複数の第２のユーザのうち、有益度が最も高い第２のユーザにおける有益度に関する情報を第１のユーザに提示する場合、第１のユーザが第１のオブジェクトを譲渡する相手を複数の第２のユーザから特定することが容易となるが、本発明はこれに限られない。例えば、全ての第２のユーザにおける有益度を提示しても良いし、一定以上の有益度を有する情報のみ表示するようにしてもよい。

本実施形態において、第１のオブジェクトについて判定された複数の有益度に関する情報の少なくとも一部を、その使用方法とともに第２のユーザに提示する場合、第１のオブジェクトを譲り受けた第２のユーザは、第１のオブジェクトの有益な使用方法の他に「受け取る」メニューが提示され、「受け取る」メニューを選択操作することで、自身のゲームの実行状況に応じて、第１のオブジェクトの使用方法を決定することができるが、本発明はこれに限られない。例えば、第１のユーザが有益度に基づいて使用方法を設定して譲渡することができ、第２のユーザは第１のユーザが設定した使用方法でしか譲渡されたカードを使用できないように制限しても良い。また、第１のユーザは第２ユーザの使用に付いて使用期限等を設けても良い。なお、使用方法で使用されない場合は第１ユーザに返却されても良い。

本実施形態において、複数の有益度のうち、最も高い有益度に関する情報を第２のユーザに提示する場合、第２のユーザが第１のオブジェクトに対する最も有益な用途を知ることができるが、本発明はこれに限られない。全ての有益度に関する情報を表示しても良いし、所定値以上の有益度を表示しても良い。

本実施形態において、関連度が所定の値以上である第２のユーザにおける第１のオブジェクトの有益度を判定する場合、ゲーム装置による処理の負担を軽減することができるが、本発明はこれに限られない。この場合、第１のユーザと関連付けられた第２のユーザが多数いる場合、第１のオブジェクトを譲渡する対象となる可能性の高い、関連度の高い第２のユーザの情報のみが、第１のユーザに提示されるため、第１のユーザにとって煩雑にならずにすむ。例えば、関連度の値に関わらず、所定の又はランダムな条件に基づいて第２のユーザを選出して有益度を判定してもよいし、全ての第２ユーザに対して有益度を判定しても良い。

本実施形態において、関連度が高い第２のユーザから優先して、有益度に関する情報を提示する場合、第１のオブジェクトを譲渡する対象となる可能性の高い、関連度の高い第２のユーザの情報から優先して、第１のユーザに提示されるため、第１のユーザにとって煩雑にならずにすむが、本発明はこれに限られない。例えば、関連度が低いユーザが優先して表示しても良いし、所定の又はランダムな条件に基づいて表示順を決定しても良い。

（８）変形例
以下、上述した実施形態の変形例について説明する。
（８−１）変形例１
本変形例に係るゲーム制御装置の機能ブロック図を、図２３に示す。図２３に示すように、本変形例では、図１６の機能ブロック図と比較して、指定手段６２と通知手段６３が追加された点で異なる。
指定手段６２は、第２のユーザに譲渡される第１のオブジェクトの使用方法を第１のユーザが指定する機能を備える。
通知手段６３は、第２のユーザに譲渡された第１のオブジェクトが第２のユーザにより使用されたときに、その使用に関する情報を第１のユーザに通知する機能を備える。

本変形例を実現するためのウェブページの一例について、図２４〜図２６を用いて説明する。
図２４は、譲渡処理が行われる場合の第１のユーザであるユーザ：Ａの通信端末１０に表示されるウェブページＰ１３を示す図である。本変形例のウェブページＰ１３が図１３のウェブページＰ８と異なる点は、ユーザ：Ｂの欄に、別の判定基準で判断された、複数の有益度に関する情報が表示されるとともに、各情報に対応するメニューｍ７１（「合成素材としてプレゼント」）、メニューｍ７２（「チーム編成用としてプレゼント」）が表示されていることである。

図２５は、本変形例を実現するためのプレゼント受領データベースを示す図である。プレゼント受領データベースには、各ユーザ毎に、コンピュータから付与されたオブジェクトまたは他のユーザからプレゼントされたオブジェクトであって、当該ユーザが受領していないオブジェクトのオブジェクトＩＤが記憶される。なお、本変形例においては、カードＩＤに、使用方法が対応付けられている。使用方法は、ユーザがオブジェクトを受領したときに指定手段６２により指定される。

以下、図２４のウェブページＰ１３において、ユーザ：Ａによるカード：ｄｅｆのユーザ：Ｂへの譲渡が行われる場合の譲渡処理について説明する。
ユーザ：ＡによりウェブページＰ１３のメニューｍ７１（「合成素材としてプレゼント」）の選択操作が行われた場合、ＣＰＵ２１は、ユーザ：Ａの保有オブジェクトデータベースにおいて譲渡するカード：ｄｅｆのカードＩＤの情報を消去し、カード：ｄｅｆのユーザとの対応付けを解除するとともに、カード：ｄｅｆのカードＩＤの情報をユーザ：Ｂのプレゼント受領データベースに追加する。このとき、ＣＰＵ２１は、ユーザ：Ｂのプレゼント受領データベースにおいて、カード：ｄｅｆのカードＩＤに対応する「使用方法」の欄に「合成」と書き込む。

一方、ユーザ：ＡによりウェブページＰ１３のメニューｍ７２（「チーム編成用としてプレゼント」）の選択操作が行われた場合、ＣＰＵ２１は、ユーザ：Ａの保有オブジェクトデータベースにおいて譲渡するカード：ｄｅｆのカードＩＤの情報を消去し、カード：ｄｅｆのユーザとの対応付けを解除するとともに、カード：ｄｅｆのカードＩＤの情報をユーザ：Ｂのプレゼント受領データベースに追加する。このとき、ＣＰＵ２１は、ユーザ：Ｂのプレゼント受領データベースにおいて、カード：ｄｅｆのカードＩＤに対応する「使用方法」の欄に「チーム」と書き込む。

次に、カード：ｄｅｆをユーザ：Ａより譲り受けたユーザ：Ｂにおける受領操作について説明する。
図２６に示すように、ユーザ：ＢのトップページＰ９にプレゼントが届いたことを示すメニューｍ５（「プレゼントが届いています」）が表示される。
ユーザ：Ｂがメニューｍ５の選択操作を行うと、図２６のＰ１４またはＰ１５に示すようにウェブページが更新される。ウェブページＰ１４、Ｐ１５には、ユーザ：Ｂに譲渡したプレゼントのリストが表示される。各プレゼントの欄には、譲渡した第１のユーザ名（「Ａさん」）、ユーザ：Ｂに対する有益度に関する情報（「合成素材用」又は「チーム編成用」）とともに表示される。

ここで、ＣＰＵ２１は、ユーザ：Ｂのプレゼント受領データベースを参照して、受領したカード：ｄｅｆの「使用方法」が「合成」である場合には、ウェブページＰ１４に示すように、有益度に関する情報として「合成素材用」の表示をするとともに、当該プレゼントを使用するためのショートカットメニューｍ５５（「合成する」）を表示する。一方、カード：ｄｅｆの「使用方法」が「チーム」である場合には、ＣＰＵ２１は、ウェブページＰ１５に示すように、有益度に関する情報として「チーム編成用」の表示をするとともに、当該プレゼントを使用するためのショートカットメニューｍ５７（「チーム編成」）を表示する。
このように、本変形例においては、ＣＰＵ２１がショートカットメニューｍ５５、ｍ５７を第２のユーザに提示することにより、第１のオブジェクトの使用方法を第１のユーザが指定することができる。

なお、いずれの場合においても、ユーザ：Ｂがユーザ：Ａにより指定された用途以外でカード：ｄｅｆを使用したい場合には、ショートカットメニューｍ５５、ｍ５７を用いずに、メニューｍ５６（「受け取る」）によりカード：ｄｅｆを保有状態にした後、所望の用途に用いることができる。

ユーザ：Ｂがショートカットメニューｍ５５を選択操作した場合、カード：ｄｅｆを合成素材とする合成処理が行われる。合成処理後、ＣＰＵ２１は、図２７のＰ１６に示すように、ユーザ：Ａのトップページに、ユーザ：Ｂがカード：ｄｅｆを合成素材として使用したことを通知するテキストｍ６（「Ｂさんがｄｅｆを合成素材に使いました」）を表示するためのＨＴＭＬデータを生成することが好ましい。

一方、ユーザ：Ｂがショートカットメニューｍ５７を選択操作した場合、カード：ｄｅｆをチームに組み込むチーム編成処理が行われる。チーム編成処理後、ＣＰＵ２１は、図２７のＰ１７に示すように、ユーザ：Ａのトップページに、ユーザ：Ｂがカード：ｄｅｆをチーム編成に使用したことを通知するテキストｍ７（「Ｂさんがｄｅｆをチーム編成に使いました」）を表示するためのＨＴＭＬデータを生成することが好ましい。

このように、本変形例においては、テキストｍ６、ｍ７により、第２のユーザによる第１のオブジェクトの使用方法を第１のユーザに通知することができる。このため、第２のユーザにより第１のオブジェクトが使用されたことを第１のユーザが知ることができる。
また、指定手段６２により第１のユーザが第１のオブジェクトの使用方法を指定する場合、第２のユーザに対して指定した使用方法によって第１のオブジェクトを使用させることができるが、本発明はこれに限られない。例えば、第２のユーザに対して指定した使用方法とは異なる使用方法によって第１のオブジェクトを第２のユーザが使用できるようにしてもよい。

（８−２）変形例２
なお、上述のように合成処理や売却処理の完了する前に第１のユーザから第２のユーザに一方的に譲渡するのではなく、第２のユーザから第１のユーザへの交換を条件として譲渡としても良い。つまり、図１２のウェブページＰ７においてユーザがメニューｍ３３（「確認する」）の選択操作を行った場合や、図１５のウェブページＰ１２においてユーザ：Ａがメニューｍ４３（「確認する」）の選択操作を行った場合、ゲームサーバ２０のＣＰＵ２１は、図１３に示すウェブページＰ８を表示するためのＨＴＭＬデータを生成する。ウェブページＰ８上でユーザ：Ａがメニューｍ６１の選択操作を行うと、ＣＰＵ２１は、ユーザ：Ａの保有オブジェクトデータベースにおいて譲渡するカード：ａｂｃのカードＩＤの情報を消去し、カード：ａｂｃを譲渡(交換)対象カードとして記憶するとともに、カード：ａｂｃのカードＩＤの情報をユーザ：Ｂの譲受対象カードとして書き込む。そして、ユーザ：Ｂが当該譲受対象カードであるカード：ａｂｃの対価であるオブジェクト、例えば、ユーザ：Ｂの保有カードの中のカード：ｘｙｚを譲渡対象カードとして選択する。カード：ｘｙｚが選択されると、Ｂの保有オブジェクトデータベースにおいて譲渡するカード：ｘｙｚのカードＩＤの情報を消去し、カード：ｘｙｚを譲渡(交換)対象カードとして記憶するとともに、カード：ｘｙｚのカードＩＤの情報をユーザ：Ａの譲受対象カードとして書き込む。その後、ユーザ：Ａによってカード：ｘｙｚとの交換が了承されると、カード：ａｂｃがユーザ：Ｂの保有オブジェクトデータベースに、カード：ｘｙｚがユーザ：Ａの保有オブジェクトデータベースに書き込まれる。
なお、上記例において、ユーザ：Ｂが交換対象を提示し、ユーザ：Ａが了承した場合に交換することとしたが、これに限られず、ユーザＢがユーザＡへの譲渡対象を設定したら自動的に交換が成立したとして、それぞれの保有情報を更新してもよい。
また、保有オブジェクトデータベース以外で譲渡対象・譲受対象を管理する例で説明したがデータの保管方法はこれに限られず、保有データベース上でフラグによって管理してもよい。例えば、譲渡対象となっている場合にフラグを「１」、譲渡対象となっていない場合にフラグを「０」としておいても良い。このようにしておくと、仮にいずれかのユーザの了承が得られずに譲渡（交換）が不成立となった場合にフラグを変更するだけで済む為、データ整理上、好適である。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。

上述した実施形態では、複数のカード（モンスターカード）を用いてバトルを行う場合を例として説明したが、これに限られない。バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。

上述した各実施形態では、ユーザによる通信端末１０に対する所定の操作入力は、ユーザの通信端末１０に対する所定の操作釦の押下操作の入力や、タッチパネル機能を備えた通信端末１０に対する表示画面上のタッチ操作の入力であるとしたが、操作入力はこれに限られない。操作入力は、加速度センサを備えた通信端末１０を振ることによる操作入力、あるいはジェスチャによる操作入力（ジェスチャ入力）であってもよい。ジェスチャ入力では、撮像機能を備えた通信端末１０に対する所定のジェスチャを行うことで通信端末１０がそのジェスチャを画像認識し、予めジェスチャに対応付けられた操作入力を認識する。また、音声認識プログラムを実行可能な通信端末１０の場合には、操作入力は、音声を入力することにより行われてもよい。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
また、例えば、家庭用ゲーム機がオフライン状態の場合であっても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。
さらに、例えば、アドホックネットワーク等のように、複数の通信端末（例えば携帯電話やゲーム機など）が自律的にネットワークを構成して、データの送受信を各通信端末間で直接行う場合においても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。

上述した各実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記各実施形態に記載したようにして通信端末１０によっても各機能を実現できる。例えば、図２８（ａ），（ｂ）に、図１６に示した機能ブロック図の各機能について、通信端末１０と、ゲームサーバ２０及びデータベースサーバ３０との機能分担の例を示す。また、上述した各実施形態では、各種データをデータベースサーバ３０（データベース３１、３２）が記憶している構成としたが、通信端末１０内の記憶装置に記憶させてもよい。その場合には、記憶装置は、通信端末１０内のＲＡＭ１３や図示しないＨＤＤ(Hard Disk Drive)などの大容量記憶装置であってよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…データベース
３２…データベース
５１…登録手段
５２…実行手段
５３…対応付け手段
５４…関連付け手段
５５…解除手段
５６…取得手段
５７…判定手段
５８…第１の提示手段
５９…譲渡手段
６０…第２の提示手段
６１…評価手段
６２…指定手段
６３…通知手段

Claims (14)

1. オブジェクトを各ユーザに対応付ける対応付け手段、
   ユーザに対し他のユーザを関連付ける関連付け手段、
   第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
   前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
   前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
   前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
   の各手段を備え、
   前記判定手段は、前記第１のオブジェクトの有益度が所定値以上であるか否かを判定し、
   前記第１の提示手段は、前記第１のオブジェクトの有益度が所定値以上である場合に、前記有益度に関する情報を前記第１のユーザに提示する、ゲーム制御装置。
2. オブジェクトを各ユーザに対応付ける対応付け手段、
   ユーザに対し他のユーザを関連付ける関連付け手段、
   第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
   前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
   前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
   前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
   前記第１のユーザへの対応付けが解除された前記第１のオブジェクトを前記第２のユーザへ対応付ける譲渡手段、
   前記第１のオブジェクトを前記第２のユーザへ対応付けた後、前記第１のオブジェクトと前記有益度に関する情報を前記第２のユーザに提示する第２の提示手段、
   の各手段を備えた、ゲーム制御装置。
3. 前記第２の提示手段は、前記第１オブジェクトの有益度に関する情報に基づいて前記第１のオブジェクトを使用するための操作釦を提示する、請求項２に記載のゲーム制御装置。
4. 前記第２のユーザへ対応付けられる前記第１のオブジェクトの使用方法を前記第１のユーザが指定するための指定手段をさらに備え、
   前記第２の提示手段は、前記第１のユーザにより指定された使用方法により前記第１のオブジェクトを使用するための操作釦を提示する、請求項２または３に記載のゲーム制御装置。
5. オブジェクトを各ユーザに対応付ける対応付け手段、
   ユーザに対し他のユーザを関連付ける関連付け手段、
   第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
   前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
   前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
   前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
   の各手段を備え、
   前記判定手段は、ゲーム内のオブジェクトの使用方法ごとに前記第１のオブジェクトの複数の有益度を判定し、
   前記第１の提示手段は、前記複数の有益度の少なくとも一部をその使用方法と対応付けて有益度に関する情報として前記第１のユーザに提示する、ゲーム制御装置。
6. 前記第１の提示手段は、前記複数の有益度のうち、最も高い有益度に関する情報を前記第１のユーザに提示する、請求項５に記載のゲーム制御装置。
7. オブジェクトを各ユーザに対応付ける対応付け手段、
   ユーザに対し他のユーザを関連付ける関連付け手段、
   第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
   前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
   前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
   前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、第１のユーザに関連付けられる複数の第２のユーザのうち、前記有益度が最も高い第２のユーザにおける前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
   の各手段を備えた、ゲーム制御装置。
8. 前記判定手段は、ゲーム内のオブジェクトの使用方法ごとに前記第１のオブジェクトの複数の有益度を判定し、
   前記第２の提示手段は、前記複数の有益度の少なくとも一部をその使用方法と対応付けて前記第２のユーザに提示する、請求項２〜４のいずれか一項に記載のゲーム制御装置。
9. 前記第２の提示手段は、前記複数の有益度のうち、最も高い有益度を前記第２のユーザに提示する、請求項８に記載のゲーム制御装置。
10. オブジェクトを各ユーザに対応付ける対応付け手段、
    ユーザに対し他のユーザを関連付ける関連付け手段、
    第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
    前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
    前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
    前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
    前記第１のユーザと関連付けられた第２のユーザを前記第１のユーザとの関連度により評価する評価手段、
    の各手段を備え、
    前記判定手段は、前記関連度が所定の値以上である第２のユーザにおける前記第１のオブジェクトの有益度を判定する、ゲーム制御装置。
11. オブジェクトを各ユーザに対応付ける対応付け手段、
    ユーザに対し他のユーザを関連付ける関連付け手段、
    第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
    前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
    前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
    前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
    前記第１のユーザと関連付けられた第２のユーザを前記第１のユーザとの関連度により評価する評価手段、
    の各手段を備え、
    前記第１の提示手段は、第１のユーザに関連付けられる複数の第２のユーザにおける前記有益度に関する情報を前記関連度が高い第２のユーザから順に、前記第１のユーザに提示する、ゲーム制御装置。
12. オブジェクトを各ユーザに対応付ける対応付け手段、
    ユーザに対し他のユーザを関連付ける関連付け手段、
    第１のユーザの入力に基づいて指定された、第１のユーザに対応付けられた第１のオブジェクトの、第１のユーザへの対応付けを解除する解除手段、
    前記第１のユーザにより前記第１のオブジェクトが指定されたときに、前記第１のユーザに関連付けられた第２のユーザのゲーム情報を取得する取得手段、
    前記第２のユーザのゲーム情報に基づき、前記第２のユーザにおける前記第１のオブジェクトの有益度を判定する判定手段、
    前記第１のオブジェクトの前記第１のユーザへの対応付けが解除される前に、前記有益度に関する情報を前記第１のユーザに提示する第１の提示手段、
    前記第２のユーザにより前記第１のオブジェクトが使用されたことを前記第１のユーザに通知する通知手段、
    の各手段を備えた、ゲーム制御装置。
13. コンピュータを、請求項１〜１２のいずれかに記載されたゲーム制御装置の各手段として機能させるためのプログラム。
14. ユーザの通信端末と、当該通信端末からアクセスされるサーバとを含む、ゲームシステムであって、
    請求項１〜１２のいずれかに記載されたゲーム制御装置の各手段を、前記通信端末または前記サーバのいずれか一方が備えた、ゲームシステム。

Images