JP2014076176A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、検索装置 - Google Patents

Abstract

【課題】ユーザが所望のオブジェクトを検索する場合に興趣性を高めることができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、検索装置を提供する。
【解決手段】本発明のゲーム制御装置は、複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するものであって、ユーザと、前記オブジェクトとを対応付ける対応付け手段と、第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段と、所定の対価を設定する第２設定手段と、前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段と、抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段と、を備える。
【選択図】図１２

Description

本発明は、複数のユーザ間での移転対象となるオブジェクトを検索するときの技術に関する。

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

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

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス、2011年11月15日発行）、94頁

従来のゲームでは、例えば、ユーザが、他のユーザの保有するアイテム等のオブジェクトを入手する（移転する）場合、当該オブジェクトを保有する他のユーザとの間で所定の取引を行うことによって当該オブジェクトを入手することができるようになっている。しかしながら、従来のゲームでは、当該オブジェクトの検索を無制限に行うことができるようになっていたため、ユーザは、例えばオブジェクトの検索を繰り返し行うことによって、所望のオブジェクトを容易に探し出す場合があった。これにより、ユーザが所望のオブジェクトを探し出すことの面白みに欠ける仕組みとなっていた。

本発明は上述した観点に鑑みてなされたもので、ユーザが所望のオブジェクトを検索する場合に興趣性を高めることができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、検索装置を提供することを目的とする。

本発明の第１の観点は、複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するゲーム制御装置である。
当該ゲーム制御装置は、
ユーザと、前記オブジェクトとを対応付ける対応付け手段（５３）と、
第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段（５４）と、
所定の対価を設定する第２設定手段（５５）と、
前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段（５６）と、
抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段（５７）と、
を備える。

ここで、「オブジェクト」は、選択対象となり得るものであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
また、「第２ユーザ」は実在するものでなくてもよく、例えば、ゲーム製作者やゲームサービスの提供者などにより制作された仮想のユーザであってもよい。

このゲーム制御装置によれば、第１ユーザは、自らの入力によって、第２ユーザに対応付けられたオブジェクトの抽出条件を設定することができる。また、第１ユーザは、所定の対価を支払うことによって、第２ユーザに対応付けられたオブジェクトの中から抽出条件を満たすオブジェクトに関する情報を得ることができる。つまり、第１ユーザは、自ら設定した抽出条件を満たすオブジェクトに関する情報を得るために、所定の対価を支払う必要がある。このため、所望のオブジェクト（抽出条件を満たすオブジェクト）を検索するために対価を支払うべきか否かなどについて、第１ユーザに検討させることができるので、第１ユーザの判断力や戦略などが求められる仕組みとすることができる。これにより、ユーザが所望のオブジェクトを検索する場合に興趣性を高めることができる。
また、このゲーム制御装置によれば、所定の対価の支払いを条件としてオブジェクトの抽出を行うことにより、オブジェクトの検索が無制限に行われることを抑制することができる。このため、例えばユーザがオブジェクトの検索を無制限に行う場合と比較して、ゲーム制御装置の処理負荷を低減することができる。

上記ゲーム制御装置において、前記第２設定手段（５５）は、オブジェクトの属性に関する条件が前記抽出条件に含まれている場合に、当該属性に基づいて前記所定の対価を設定してもよい。
ここで、「オブジェクトの属性」とは、例えば、オブジェクトの特徴や性質などを示す情報であってもよいし、オブジェクトの特徴や性質などを分類するための情報であってもよい。
例えば、属性がオブジェクトの希少価値を示す情報である場合、抽出条件に含まれるオブジェクトの希少価値が高いほど、所定の対価が多く必要になるように設定されてもよい。この場合、希少価値の高いオブジェクトを検索することによって当該オブジェクトを入手する可能性を高めるために、多くの対価を支払うべきか否かなどについて、第１ユーザに慎重に検討させることができるので、第１ユーザの判断力や戦略などがより求められる仕組みとすることができる。また、この場合には、検索条件に含まれるオブジェクトの希少価値が高いほど、当該検索条件を満たすオブジェクトが検索し難くなる（つまり、入手し難くなる）ことから、希少価値の高いオブジェクトを入手するための難易度が低下することを抑制することが可能となる。

上記ゲーム制御装置において、前記第２設定手段（５５）は、オブジェクトの抽出数が前記抽出条件に含まれている場合に、当該抽出数に基づいて前記所定の対価を設定してもよい。
例えば、オブジェクトの抽出数が多いほど、所定の対価が多く必要になるように設定されてもよい。この場合、所望のオブジェクトを入手する可能性を高めるために多くの対価を支払うべきか（つまり、所望のオブジェクトの抽出数を多くすべきか）否かなどについて、第１ユーザにより慎重に検討させることができるので、第１ユーザの判断力や戦略などがさらに求められる仕組みとすることができる。

上記ゲーム制御装置において、前記抽出手段（５６）は、抽出したオブジェクトの数が前記抽出数未満の場合に、前記所定の対価の少なくとも一部を前記第１ユーザに返還してもよい。
このゲーム制御装置によれば、第１ユーザは、オブジェクトの抽出数が自ら設定した抽出数未満の場合、支払った対価の少なくとも一部を受け取ることが可能となる。このため、ユーザにとって、オブジェクトの検索による損失を低減する仕組みとすることができる。

上記ゲーム制御装置において、前記第２設定手段（５５）は、前記抽出条件に基づいてオブジェクトが抽出されるタイミングにおけるゲーム制御装置の処理負荷に関する情報に基づいて、前記所定の対価を設定してもよい。
例えば、オブジェクトが抽出されるタイミングにおけるゲーム制御装置の処理負荷が高いほど、所定の対価が多く必要になるように設定されてもよい。この場合、第１ユーザは、オブジェクトの検索に必要な対価をできるだけ低減するために、処理負荷の低いタイミングでオブジェクトの抽出を行うことが動機付けられる。このため、オブジェクトの検索に基づくゲーム制御装置の過負荷を抑制することができる。

上記ゲーム制御装置において、前記第２設定手段（５５）は、前記抽出条件と共通する抽出条件を用いて過去にオブジェクトを抽出した回数あるいは頻度に基づいて、前記所定の対価を設定してもよい。
例えば、第１ユーザが抽出条件と共通する抽出条件を用いて過去にオブジェクトを抽出した回数あるいは頻度に基づいて、所定の対価を設定してもよい。また、例えば、ゲームを実行する全てのユーザが抽出条件と共通する抽出条件を用いて過去にオブジェクトを抽出した回数あるいは頻度に基づいて、所定の対価を設定してもよい。
例えば複数のユーザが同じオブジェクトを検索する場合には、オブジェクトの抽出条件が共通する場合がある。また、複数のユーザが同じオブジェクトを所定期間の間集中して検索した場合には、ゲーム制御装置の処理負荷が高くなる場合がある。そこで、例えば、共通する抽出条件を用いて過去にオブジェクトを抽出した回数あるいは頻度が多いほど、所定の対価が多く必要になるように設定されてもよい。この場合、高い対価を支払ってまで当該オブジェクトを検索すべきか否かをユーザごとに慎重に検討させることができるので、当該オブジェクトの検索に基づくゲーム制御装置の過負荷を抑制することができる。

本発明の第２の観点は、複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するゲーム制御方法である。
当該ゲーム制御方法は、
ユーザと、前記オブジェクトとを対応付けるステップと、
第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定するステップと、
所定の対価を設定するステップと、
前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出するステップと、
抽出されたオブジェクトに関する情報を前記第１ユーザに通知するステップと、
を備える。

本発明の第３の観点は、複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するプログラムであって、
コンピュータに、
ユーザと、前記オブジェクトとを対応付ける機能、
第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する機能、
所定の対価を設定する機能、
前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する機能、及び
抽出されたオブジェクトに関する情報を前記第１ユーザに通知する機能、
を実現させるためのプログラムである。

コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。

本発明の第４の観点は、通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含み、複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するゲームシステムであって、
ユーザと、前記オブジェクトとを対応付ける対応付け手段（５３）、
第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段（５４）、
所定の対価を設定する第２設定手段（５５）、
前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段（５６）、
抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段（５７）、
の各手段を、前記通信端末（１０）又は前記サーバ（２０）のいずれか一方が備える。

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。

本発明の第５の観点は、検索装置である。
当該検索装置は、
ユーザと、前記オブジェクトとを対応付ける対応付け手段（５３）と、
第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段（５４）と、
所定の対価を設定する第２設定手段（５５）と、
前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段（５６）と、
抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段（５７）と、
を備える。

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

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、検索装置によれば、ユーザが所望のオブジェクトを検索する場合に興趣性を高めることができる。

実施形態のゲームシステムの基本構成を示す図。 通信端末の外観の例を示す図。 通信端末の構成を示すブロック図。 ゲームサーバの構成を示すブロック図。 データベースサーバの構成を示すブロック図。 ユーザデータベースの構成例を示す図。 モンスターカードデータベースの構成例を示す図。 販売設定データの構成例を示す図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 ユーザの通信端末に表示される一連のウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 ユーザの通信端末に表示される一連のウェブページを例示する図。 履歴データの構成例を示す図。 ゲーム制御装置の各機能について、通信端末と、ゲームサーバ及びデータベースサーバとの間の分担例を示す図。

以下、本発明の実施形態について説明する。なお、本実施形態の説明において、モンスターカードはオブジェクトの一例である。

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

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

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

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

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

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

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

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

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

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

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

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

（４）データベースサーバの構成
データベースサーバ３０（記憶装置）は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態のゲームの一例として、モンスターカードを用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、ユーザが、モンスターが描かれたデジタルカード（モンスターカード）を入手することによって自らのチーム（カードデッキ）を作り上げ、他のユーザのチームとバトルを行うように構成されている。
このゲームは、例えば、以下の処理を含む。
・クエスト処理：
少なくとも一枚のモンスターカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してモンスターカードを得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費する。
・バトル処理：
ユーザのチームと他のユーザのチームとの間でバトル（対戦）を行う処理である。なお、本実施形態では、ユーザ間でバトルを行う場合を一例として説明しているが、ユーザの対戦相手は、例えばＣＰＵ２１によって任意に抽出された複数のモンスターカードからなるチームであってもよい。
・合成処理：
２枚以上のモンスターカードを一体化して特定のモンスターカードの能力を上昇させる処理である。この場合、特定のモンスターカードの能力は上昇するが、一体化に用いられたモンスターカードは消失する。
・販売処理
ユーザが保有するモンスターカードを他のユーザに販売するための処理である。ここで、「他のユーザ」は実在するものでなくてもよく、例えば、ゲーム製作者やゲームサービスの提供者などにより制作された仮想のユーザであってもよい。
・購入処理：
他のユーザが販売するモンスターカードをユーザが購入するための処理である。

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

図６に、本実施形態のゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、進行レベル、体力ポイント、ポイント、仲間のユーザＩＤ、保有カードのデータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、クエスト処理が継続的に実行されることで、順次進行レベルが上がるように構成される。
・体力ポイント
本実施形態のゲームにおいて、クエスト処理を実行する上で必要となるポイントである。体力ポイントは、探索を行う度に低減し、所定の時間が経過する毎に回復（増加）する値である。
・ポイント
本実施形態のゲームにおいて、購入処理を実行する上で必要となるポイントである。ポイントは、例えば、ユーザが、ゲーム提供者等に対して所定の方法で実際の金銭を支払うことでその支払額に応じて増加してもよいし、他のユーザとのバトルに勝利した場合に所定量増加してもよい。
・仲間のユーザＩＤ
例えば仲間になるための申請などを契機として、ユーザと関連付けられた他のユーザ（仲間）のユーザＩＤのリストである。
・保有カードのデータ
ユーザがゲーム上保有するモンスターカードのデータである。モンスターカードのデータの内容については後述する。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、例えば他のユーザとのバトルの結果についての情報（例えば勝敗等）などを含む。
また、ゲームデータベース３２は、上述した各種処理に関連して、モンスターカードデータベース及び販売設定データを記憶する。

モンスターカードデータベースは、本実施形態のゲームで用意される複数のモンスターカード（オブジェクト）の初期データが記述されているデータベースである。ここで、「オブジェクト」は、選択対象となり得るものであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
図７は、モンスターカードデータベースのデータ構成の一例を示す図である。図７に例示するモンスターカードデータベースは、モンスターカードの識別コード（図の例では、ＭＣ００１，ＭＣ００２，…）ごとに、対象となるモンスターカードの画像データ（画像）、対象となるモンスターの名前（モンスター名）、対象となるモンスターカードの属性（図の例では、能力レベル、能力を示すパラメータ（図の例では、攻撃力及び防御力）、特技、特技レベル及びレア度）の各項目のデータを含む。モンスターカードのデータのうち能力レベル、パラメータ及び特技レベルの各々の値は、ユーザが当該モンスターカードを強化対象として合成処理を行うことによって増加する。この場合、複数のユーザの各々が同一のモンスターカード（同一の識別コードのモンスターカード）を保有する場合であっても、当該モンスターカードの能力レベル、パラメータ及び特技レベルの各々の値は、ユーザごとに異なり得る。
能力レベルは、対象となるモンスターカードの能力の高さを示すデータである。能力レベルは、例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、対象となるモンスターカードを強化対象とした合成処理が行われることによって、能力レベルが上がるように構成される。
特技レベルは、対象となるモンスターカードが有する特技の能力の高さを示すデータである。能力レベルは、例えばＬｖ１（レベル１）からＬｖ２０（レベル２０）までの範囲のレベル値であり、例えば、同一の特技を有するモンスターカード同士を合成することによって、特技レベルが上がるように構成される。なお、特技レベルが高いほど、バトルにおいて当該特技レベルに対応する特技の発生（発動）確率、あるいは特技の効果が高くなる（例えば、自チームのモンスターカードの攻撃力あるいは防御力が増加する割合が高くなる）ように構成されてもよい。この場合、ユーザは、特技レベルの高いモンスターカードをチームに含めることで、バトルに勝利する可能性を高めることが可能となる。
また、レア度は、モンスターカードの希少価値の度合を示す値であり、例えば、その値が高い（つまり、希少価値が高い）ほど、ゲーム内で出現する確率が低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、能力の際立ったモンスターや人気のあるモンスターに対応するモンスターカードのレア度が高く（例えば、４あるいは５など）設定されてもよい。
なお、属性は、例えば、オブジェクトの特徴や性質などを示す情報であってもよいし、オブジェクトの特徴や性質などを分類するための情報であってもよい。例えば、野球ゲームの場合、属性には、ゲーム上の選手（オブジェクト）のチームや、ポジション（例えば投手、捕手、一塁手、左翼手など）などが含まれてもよい。

販売設定データは、ユーザが保有するモンスターカードの中から販売設定したモンスターカードのデータが記述されているデータである。販売設定データのデータ構成例を図８に示す。図８に示す販売設定データは、ユーザ（ユーザＩＤ）ごとに、販売設定されたモンスターカードのデータ（図の例では、識別コード、能力レベル、攻撃力、防御力、特技レベル及びレア度）と、当該モンスターカードの販売価格とが含まれる。販売価格の内容は、販売処理において例えばユーザにより設定又は更新され得る。この場合、図８に例示するように、複数のユーザの各々が同一のモンスターカード（図の例では、識別コードが「ＭＣ００１」のモンスターカード）を販売設定した場合であっても、当該モンスターカードの販売価格はユーザごとに異なり得る。

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

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

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

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

次に、販売処理の一例を説明する。図１０のトップページＰ１上でメニューｍ４が選択操作されると、販売処理の実行が開始され、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３には、メニューｍ４の選択操作を行ったユーザ（ここでは、ユーザ：ＫＮＭ）が保有する全てのモンスターカードごとに、モンスターカードのデータを表示する領域が含まれる。それぞれのモンスターカードの領域には、モンスターカードの販売価格を入力するためのテキストボックス１０４と、モンスターカードの販売設定を実行するための「販売する」と表記されたメニューｍ１１などが含まれる。
ユーザ：ＫＮＭは、販売するモンスターカードに対応するテキストボックス１０４に当該モンスターカードの販売価格を入力した後に、メニューｍ１１の選択操作を行う。このようにして、モンスターカードの販売設定が行われる。
なお、ここでは、モンスターカードの販売価格がユーザの入力によって設定される場合を一例として説明したが、この場合に限られない。例えば、モンスターカードの販売価格は、ユーザによる入力を契機とせずに（つまり、自動的に）設定されてもよい。具体的に説明すると、モンスターカードの販売価格は、例えば、モンスターカードの属性（例えば、能力レベル、攻撃力、防御力、特技レベル及びレア度の少なくとも一つ）に基づいて自動的に設定されてもよい。例えば、能力レベル、攻撃力、防御力、特技レベル及びレア度のいずれかが高いほど、販売価格が高くなるように設定されてもよい。

次に、購入処理の一例を説明する。ここでは、処理対象のユーザが「ＡＢＣ」というユーザ（以下、「ユーザ：ＡＢＣ」と表記する。）である場合を一例として説明する。図１１のＰ４に例示するユーザ：ＡＢＣのトップページ上でメニューｍ５が選択操作されると、購入処理の実行が開始され、Ｐ５に示すようにウェブページが更新される。ウェブページＰ５は、他のユーザによって販売設定されたモンスターカードの検索条件（抽出条件）を設定できるように構成されており、検索条件の一例であるレア度を選択するためのプルダウンメニューｍ１２と、検索条件を設定するための「検索条件を設定」と表記されたメニューｍ１３とが含まれる。なお、検索条件は、レア度に限られず、モンスターカード（オブジェクト）に関するデータであれば如何なるデータを用いてもよい。例えば、検索条件には、モンスター名、能力レベル、攻撃力、防御力、特技、特技レベル及びレア度のうち少なくともいずれかに関する条件が含まれてもよい。また、ウェブページＰ５の例では、複数のレア度（例えば１，２，３，４，５）ごとに検索条件を設定できるように構成されているが、例えばレア度が「２以上」あるいは「４以下」などのように検索条件を設定できるようにしてもよい。

ユーザ：ＡＢＣがプルダウンメニューｍ１３を用いてレア度を選択した後に、メニューｍ１３を選択操作すると、Ｐ６に示すようにウェブページが更新される。ウェブページＰ６には、設定された検索条件（図の例では、レア度が「５」であること）と、検索料（図の例では２０００ポイント）と、検索を実行するための「検索実行」と表記されたメニューｍ１４などが含まれる。本実施形態のゲームでは、ユーザ：ＡＢＣは、自ら設定した検索条件を満たすモンスターカードに関する情報を得るために、検索料を支払う必要がある。このため、所望のモンスターカード（検索条件を満たすモンスターカード）を検索するために検索料を支払うべきか否かなどについて、ユーザ：ＡＢＣに慎重に検討させることができるので、ユーザ：ＡＢＣの判断力や戦略などが求められる仕組みとすることができる。

次に、ユーザ：ＡＢＣの保有するポイントの値が検索料以上の場合にユーザ：ＡＢＣがメニューｍ１４を選択操作すると、他のユーザによって販売設定されたモンスターカードの中から検索条件を満たすモンスターカードの検索が行われ、Ｐ７に示すようにウェブページが更新される。ウェブページＰ７には、検索条件を満たすモンスターカードごとに、モンスターカードのデータ（図の例では、画像、モンスター名、能力レベル、攻撃力、防御力、レア度）を表示する領域が含まれる。それぞれのモンスターカードに対応する領域には、モンスターカードの販売価格と、モンスターカードを購入するための「購入する」と表記されたメニューｍ１５などが含まれる。なお、ウェブページＰ７には、モンスターカードを販売する他のユーザを特定する情報（例えばユーザ名など）を含まなくてもよい。この場合、モンスターカードを購入するユーザは、モンスターカードを販売する他のユーザを特定することができないことから、例えば他のユーザとの間で現実の通貨を用いてモンスターカードの売買を行う行為（いわゆるリアルマネートレード）を抑制することが可能となる。
ユーザ：ＡＢＣがウェブページＰ７上で所望のモンスターカードに対応するメニューｍ１５を選択操作すると、選択操作されたメニューｍ１５に対応するモンスターカードの購入処理が行われる。そして、ユーザ：ＡＢＣは、選択操作したメニューｍ１５に対応するモンスターカードを入手することができる。

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

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

登録手段５１はさらに、異なるユーザ間を関連付ける機能を備えてもよい。つまり、登録手段５１は、例えばユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤとを関連付けて記録する。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤ（つまり、他のユーザ）を「仲間」として記録する。
この登録手段５１の機能は例えば、以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（仲間申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されてもよい。
ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０へ、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するウェブページを表示するためのＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間のユーザＩＤ」の項目（図６参照）にデータ（相手のユーザＩＤ）を書き込む。なお、ＣＰＵ２１は、仲間申請先のユーザの承認を不要とする場合は、ゲームを実行中のユーザによる所定の操作を契機として、両者を仲間として登録してもよい。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られず、ユーザと協働してゲームを実行した他のユーザ、例えば、ゲーム上の同一のステージやエリアなどを実行する他のユーザや、バトルを行った他のユーザなどを、ユーザとゲーム内で関係付けられた他のユーザ、つまり仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間でバトルを行うゲーム上のモードが存在する場合には、所定回数以上バトルを行ったユーザ同士を自動的に仲間として登録してもよい。

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

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

クエスト処理において、ＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、複数のモンスターカードの中から選択されたモンスターカードをユーザに付与する（対応付ける）ことを、所定の、あるいはランダムな確率で決定する。ここで、ＣＰＵ２１は、モンスターカードを付与することを決定した場合、モンスターカードを入手したことを通知するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。ＣＰＵ２１は、複数のモンスターカードの中から選択されたモンスターカードをユーザに付与することを決定した場合には、後述する対応付け手段５３の機能に基づいて、当該ユーザに対してモンスターカードを付与する処理を行う。

なお、バトル処理については、ここでは詳しく述べないが、例えばチームに含まれるモンスターカードの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）の大小に応じて、バトルの結果が決定されるように構成される。例えば、バトルを行う２人のユーザのうちチームに含まれるモンスターカードのパラメータの合計値の大きいユーザが、バトルに勝利する可能性が高くなるように設定されてもよい。また、ＣＰＵ２１は、バトルの結果を決定すると、ユーザデータベース３１にアクセスして、バトルに勝利したユーザのユーザＩＤに対応するポイントの値を所定量増加してもよい。

また、合成処理については、例えば以下のように行われてよい。強化対象となるモンスターカード（ユーザによって指定された、残留するモンスターカード）をモンスターカードＡとし、モンスターカードＡに一体化させられて消失するモンスターカードをモンスターカードＢとする。この場合、合成処理では、ＣＰＵ２１がモンスターカードＡの「攻撃力」，「防御力」の能力値を示すパラメータに対して、モンスターカードＢの「攻撃力」，「防御力」の能力値を示すパラメータの一定比率をそれぞれ加算することで、モンスターカードＡの新たなパラメータを算出するようにしてもよい。また、ＣＰＵ２１は、モンスターカードＡの「攻撃力」，「防御力」の能力値を示すパラメータが、能力レベルごとに予め設定された所定値に達した場合に、モンスターカードＡの能力レベルを当該所定値に対応する能力レベルに更新してもよい。さらに、ＣＰＵ２１は、モンスターカードＡ及びモンスターカードＢの各々が同一の特技を有する場合、モンスターカードＡの特技レベルを増加させることを所定の、あるいはランダムな確率で決定してもよい。この合成処理によって、モンスターカードＢの能力上の特徴がモンスターカードＡに反映されることになる。
ＣＰＵ２１は、合成処理の後にユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータからモンスターカードＢのデータを削除し、モンスターカードＡの「攻撃力」，「防御力」の能力値を示すパラメータを書き換える。また、ＣＰＵ２１は、モンスターカードＡの能力レベルを更新する場合、モンスターカードの能力レベルを、当該所定値に対応する能力レベルに書き換える。さらに、ＣＰＵ２１は、モンスターカードＡの特技レベルを増加させることを決定した場合、モンスターカードＡの特技レベルを例えば１だけ増加させる。

実行手段５２が販売処理を実行する機能は、例えば以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、図１０のトップページＰ１上でメニューｍ４が選択操作されたことを認識すると、選択操作を行ったユーザのユーザＩＤに対応するユーザデータを参照して、当該ユーザの保有カードのデータを抽出する。次に、ＣＰＵ２１は、抽出したデータを用いて、図１０のＰ３に例示するウェブページを表示するためのＨＴＭＬデータを生成する。そして、ＣＰＵ２１は、生成したＨＴＭＬデータを当該ユーザの通信端末１０宛に送信する。
ＣＰＵ２１は、ウェブページＰ３上でメニューｍ１１が選択操作されたことを認識すると、選択操作されたメニューｍ１１に対応するモンスターカードの販売設定処理を行う。この処理について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、選択操作を行ったユーザのユーザＩＤに対応する保有カードのデータの中から、選択操作されたメニューｍ１１に対応するモンスターカードのデータ（識別コード、能力レベル、攻撃力、防御力、特技レベル、レア度）を抽出する。そして、ＣＰＵ２１は、販売設定データにアクセスして、抽出したデータと、選択操作されたメニューｍ１１に対応するテキストボックス１０４に入力されたテキスト情報（つまり、販売価格）とを、選択操作を行ったユーザのユーザＩＤに対応付けて記録する。

また、実行手段５２は、購入処理において、選択されたメニューｍ１５に対応するモンスターカードの購入処理を行う機能を備えてもよい。この場合、ゲームサーバ２０のＣＰＵ２１は、図１１のウェブページＰ７上でメニューｍ１５が選択操作されたことを認識すると、ユーザデータベース３１にアクセスして、選択操作を行ったユーザ（ここでは、ユーザ：ＡＢＣ）のユーザＩＤに対応するポイントの値が、選択操作されたメニューｍ１５に対応するモンスターカードの販売価格以上であるか否かを判別する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのポイントの値がモンスターカードの販売価格以上であると判別した場合、ユーザ：ＡＢＣのポイントの値から販売価格を減算して、選択されたメニューｍ１５に対応するモンスターカードの購入処理を行う。この処理の内容について以下に説明する。なお、ここでは、ユーザ：ＡＢＣが、ユーザ：ＫＮＭが販売設定したモンスターカードを購入する場合を一例として説明する。ＣＰＵ２１は、販売設定データにアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応するモンスターカードの中からメニューｍ１５に対応するモンスターカードのデータを抽出する。そして、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、抽出したデータを、ユーザ：ＡＢＣのユーザＩＤに対応する保有カードのデータに追記する。さらに、ＣＰＵ２１は、ユーザデータベース３１及び販売設定データの各々に対して、ユーザ：ＫＮＭのユーザＩＤに対応するモンスターカードの中からメニューｍ１５に対応するモンスターカードのデータを削除する。また、ＣＰＵ２１は、ユーザデータベース３１において、ユーザ：ＫＮＭのユーザＩＤに対応するポイントの値を販売価格だけ増加させる。

対応付け手段５３は、ユーザと、モンスターカード（オブジェクト）とを対応付ける機能を備える。
ここで、「対応付ける」とは、例えば、ユーザのユーザＩＤ（識別情報）とモンスターカード（オブジェクト）に関する情報（例えば識別情報など）とを連結する（リンクする）ことであってもよいし、ユーザＩＤに対応付けられたモンスターカード用のデータファイルに対してモンスターカードに関する情報を記憶することであってもよいし、ユーザＩＤに対応付けられたモンスターカードの数を増加させることであってもよい。また、ユーザＩＤ及び／又はカード情報は、外部の記憶装置に記憶されてもよい。さらに、ユーザＩＤとカード情報とを連結する情報（リンク情報）は、外部の記憶装置に記憶されてもよい。
また、対応付け手段５３がユーザとモンスターカードとを対応付ける契機は、例えば、クエスト処理においてユーザがモンスターカードを得た（発掘した）とき、ユーザが所定の抽選によってモンスターカードを得たとき、あるいはモンスターカードが他のユーザからプレゼントされたときなどが挙げられる。

対応付け手段５３の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、ゲームデータベース３２内のモンスターカードデータベースにアクセスし、モンスターカードデータベースから抽出されたモンスターカードのデータを、対象となるユーザのユーザＩＤに対応するユーザデータに記録する。
ここで、上述したクエスト処理において、ユーザに対してモンスターカードを対応付ける（付与する）場合について説明する。ＣＰＵ２１は、複数のモンスターカードの中から選択されたモンスターカードをユーザに付与することを、実行手段５２の機能に基づき決定した場合には、クエスト用に予め設けられた複数のモンスターカードの中から、付与されるモンスターカードを選択する。次に、ＣＰＵ２１は、選択したモンスターカードのデータをモンスターカードデータベースから読み出した後に、ユーザデータベース３１にアクセスする。そして、ＣＰＵ２１は、対象となるユーザＩＤのユーザデータ（保有カードのデータ）に対して、読み出したデータを追記する。

第１設定手段５４は、第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたモンスターカード（オブジェクト）の検索条件（抽出条件）を設定する機能を備える。
第１設定手段５４の機能は、例えば以下のとおり実現される。なお、ここでは、ユーザ：ＡＢＣが第１ユーザであって、ユーザ：ＡＢＣ以外の他のユーザ（ユーザ：ＫＮＭを含む）が第２ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、図１１のウェブページＰ５上でメニューｍ１３が選択操作されたことを認識すると、モンスターカードの検索条件を設定する処理を行う。この処理について具体的に説明すると、ＣＰＵ２１は、プルダウンメニューｍ１２を用いて選択されたレア度の値を検索条件として、例えばＲＡＭ２３などの記憶装置に記憶する。

第２設定手段５５は、検索料（所定の対価）を設定する機能を備える。
ここで、「対価」とは、例えば、ユーザが保有するゲーム上のポイントなどであってもよいし、所定のアイテムやキャラクタなどであってもよい。
第２設定手段５５の機能は、例えば以下のようにして実現される。なお、ここでは、ポイントを対価として用いる場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、図１１のウェブページＰ５上でメニューｍ１３が選択操作されると、検索料を設定する処理を行う。この処理の内容について具体的に説明すると、ＣＰＵ２１は、例えばゲームデータベース３２に記録された所定の検索料（例えば１００ポイント）を読み出して、例えばＲＡＭ２３などの記憶装置に記憶してもよい。ここで検索料の値は任意に設定され得るが、例えば、以下に説明するように、検索条件に基づいて設定されてもよい。
なお、ウェブページＰ６を表示するためのＨＴＭＬデータが生成される場合、例えばＲＡＭ２３などの記憶装置に記憶された検索料をウェブページＰ６に含むようにＨＴＭＬデータが生成される。

第２設定手段５５は、モンスターカード（オブジェクト）のレア度（属性）に関する条件が検索条件（抽出条件）に含まれている場合に、当該レア度に基づいて検索料（所定の対価）を設定してもよい。
例えば、検索条件に含まれるレア度が高いほど、検索料が多く必要になるように設定されてもよい。この場合、レア度の高いモンスターカードを入手する可能性を高めるために多くの検索料を支払うべきか否かなどについて、ユーザ：ＡＢＣ（第１ユーザ）に慎重に検討させることができるので、ユーザ：ＡＢＣの判断力や戦略などがより求められる仕組みとすることができる。また、この場合には、検索条件に含まれるレア度が高いほど、当該検索条件を満たすモンスターカードが検索し難くなる（つまり、入手し難くなる）ことから、レア度の高いモンスターカードを入手するための難易度が低下することを抑制することが可能となる。
この場合における第２設定手段５５の機能は、例えば以下のように実現できる。なお、ここでは、検索条件に含まれるモンスターカードのレア度が高いほど、検索料が多く必要になる場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、検索料を設定する処理を行う場合、例えば以下のように設定されたデータを用いて、検索料をもとめる。
・検索条件としてレア度を１に設定した場合、検索料は１００ポイント
・検索条件としてレア度を２に設定した場合、検索料は２００ポイント
・検索条件としてレア度を３に設定した場合、検索料は５００ポイント
・検索条件としてレア度を４に設定した場合、検索料は１０００ポイント
・検索条件としてレア度を５に設定した場合、検索料は２０００ポイント
このように検索料を設定した場合、検索条件として設定したレア度が高くなるほど、多くの検索料が必要となる。
次に、ＣＰＵ２１は、もとめた検索料を例えばＲＡＭ２３などの記憶装置に記憶する。
なお、ここでは、属性がレア度である場合を一例として説明したが、この場合に限られない。例えば、属性が、能力レベル、攻撃力、防御力、あるいは特技レベルの場合であっても、上記と同様に検索料を設定することが可能である。

また、ＣＰＵ２１は、レア度（属性）に基づいて検索料を設定する場合、ユーザによるゲームの実行状況に応じて検索料を変動させてもよい。
ここで、「ゲームの実行状況」とは、例えば、ユーザが、ゲーム上で制覇（クリア）したパートの数であってもよいし、ユーザが、ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、「ゲームの実行状況」とは、例えば、ユーザがゲーム上で獲得した特定のアイテムの数であってもよいし、ゲームの進行度（進行レベル）の高さなどであってもよい。
例えば検索条件として同じ属性（例えばレア度５）が設定されている場合、ユーザによるゲームの実行状況が進んでいる（例えば、ユーザの進行レベルが高い）ほど、検索料が低くなるように設定されてもよい。例えば、進行レベルが１つ上がるごとに、検索料を所定の割合だけ減らしてもよい。この場合、ゲームの実行状況が進んでいないユーザ（例えばゲームの初心者）は、ゲームの実行状況が進んでいるユーザ（例えばゲームの上級者）と比べて検索料が高くなることから、例えばレア度の高いモンスターカードを検索し難くなる（入手し難くなる）。これにより、例えば、ゲームの初心者がレア度の高いモンスターカードを容易に入手することを抑制することが可能となる。

抽出手段５６は、第１ユーザによる検索料（所定の対価）の支払いを条件として、第２ユーザに対応付けられたモンスターカード（オブジェクト）の中から検索条件（抽出条件）を満たすモンスターカードを抽出する機能を備える。
抽出手段５６の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１１のウェブページＰ６上でユーザ：ＡＢＣ（第１ユーザ）によってメニューｍ１４が選択操作されたことを認識すると、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するポイントの値が検索料以上であるか否かを判別する。そして、ＣＰＵ２１は、ポイントの値が検索料以上であると判別すると、ポイントの値から検索料を減算した（検索料を支払った）後に、モンスターカードの検索処理を行う。この処理について具体的に説明すると、ＣＰＵ２１は、販売設定データにアクセスして、販売設定された全てのモンスターカードの中から検索条件を満たすモンスターカードを抽出する。例えば、レア度が５であることが検索条件である場合には、販売設定された全てのモンスターカードのうちレア度が５のモンスターカードが抽出される。
また、ＣＰＵ２１は、抽出したモンスターカードのデータ及び販売価格を例えばＲＡＭ２３などの記憶装置に記憶する。

通知手段５７は、抽出されたモンスターカード（オブジェクト）に関する情報を第１ユーザに通知する機能を備える。
通知手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、抽出手段５６の機能に基づいてモンスターカードの検索処理を行うと、抽出したモンスターカードのデータ及び販売価格を通知するウェブページ（Ｐ７に例示するウェブページ）を表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣ（第１ユーザ）の通信端末１０に送信する。この場合、ＣＰＵ２１は、抽出手段５６の機能に基づいて例えばＲＡＭ２３などの記憶装置に記憶されたモンスターカードのデータ及び販売価格をウェブページに含むようにＨＴＭＬデータを生成する。

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

先ず図１３のフローチャートにおいて、トップページＰ１上でクエスト処理の実行を指示するメニューｍ１が選択操作されたことを認識すると、ゲームサーバ２０のＣＰＵ２１は、図９のＰ２に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。ＣＰＵ２１は、メニューｍ１０（「クエスト実行」）が選択操作されたことを認識すると（ステップＳ１００：ＹＥＳ）、複数のモンスターカードの中から選択されたモンスターカードをユーザ：ＫＮＭに付与することを、所定の、あるいはランダムな確率で決定する（ステップＳ１０２）。次に、ＣＰＵ２１は、モンスターカードを付与することを決定すると（ステップＳ１０２：ＹＥＳ）、ユーザ：ＫＮＭにモンスターカードを付与する処理を行う（ステップＳ１０４）。この場合、ＣＰＵ２１は、ゲームデータベース３２内のモンスターカードデータベースにアクセスし、クエスト用に予め設けられた複数のモンスターカードの中から、付与されるモンスターカードを選択する。次に、ＣＰＵ２１は、選択したモンスターカードのデータをモンスターカードデータベースから読み出した後に、ユーザデータベース３１にアクセスする。そして、ＣＰＵ２１は、ユーザ：ＫＮＭのユーザＩＤに対応する保有カードのデータに対して、読み出したデータを追記する。なお、ＣＰＵ２１は、ステップＳ１０２においてモンスターカードをユーザに付与しないことを決定した場合（ステップＳ１０２：ＮＯ）、ステップＳ１０６の処理に移行する。
ＣＰＵ２１は、ユーザ：ＫＮＭの達成率と体力ポイントとを更新し（ステップＳ１０６）、更新後の達成率を表示するＨＴＭＬデータを生成してユーザ：ＫＮＭの通信端末１０に送信する。
なお、ＣＰＵ２１は、メニューｍ１０が選択操作されずに所定時間経過した場合（ステップＳ１００：ＮＯ）、クエスト処理を終了してもよい。

次に、図１４を参照して、販売処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、図１０のトップページＰ１上でメニューｍ４が選択操作されたことを認識すると、図１０のＰ３に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０に送信する。次に、ＣＰＵ２１は、ウェブページＰ３上でメニューｍ１１が選択操作されたことを認識すると（ステップＳ２００：ＹＥＳ）、選択操作されたメニューｍ１１に対応するモンスターカードの販売設定処理を行う（ステップＳ２０２）。この処理について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＫＮＭのユーザＩＤに対応する保有カードのデータの中から、選択操作されたメニューｍ１１に対応するモンスターカードのデータ（識別コード、能力レベル、攻撃力、防御力、特技レベル、レア度）を抽出する。そして、ＣＰＵ２１は、販売設定データにアクセスして、抽出したデータと、選択操作されたメニューｍ１１に対応するテキストボックス１０４に入力されたテキスト情報（つまり、販売価格）とを、ユーザ：ＫＮＭのユーザＩＤに対応付けて記録する。
なお、ＣＰＵ２１は、ウェブページＰ３上でメニューｍ１１が選択操作されずに所定時間経過した場合（ステップＳ２００：ＮＯ）、販売処理を終了してもよい。

次に、図１５を参照して、購入処理を行うときのフローチャートの一例を説明する。
なお、図１５のフローチャートでは、ユーザ：ＡＢＣがゲームを実行する場合を一例として説明する。
ＣＰＵ２１は、図１１のトップページＰ４上でメニューｍ５が選択操作されたことを認識すると、図１１のＰ５に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０に送信する。ＣＰＵ２１は、ウェブページＰ５上でメニューｍ１３が選択操作されたことを認識すると（ステップＳ３００：ＹＥＳ）、モンスターカードの検索条件を設定する処理を行う（ステップＳ３０２）。この処理について具体的に説明すると、ＣＰＵ２１は、プルダウンメニューｍ１２を用いて選択されたレア度の値を検索条件として、例えばＲＡＭ２３などの記憶装置に記憶する。次いで、ＣＰＵ２１は、検索料を設定する処理を行う（ステップＳ３０４）。ここで、ＣＰＵ２１は、例えば、モンスターカードのレア度に関する条件が検索条件に含まれている場合に、当該レア度に基づいて検索料を設定してもよい。また、ＣＰＵ２１は、検索料を例えばＲＡＭ２３などの記憶装置に記憶する。

次に、ＣＰＵ２１は、図１１のウェブページＰ６上でユーザ：ＡＢＣによってメニューｍ１４が選択操作されたことを認識すると（ステップＳ３０６：ＹＥＳ）、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するポイントの値が検索料以上であるか否かを判別する（ステップＳ３０８）。そして、ＣＰＵ２１は、ポイントの値が検索料以上であると判別すると（ステップＳ３０８：ＹＥＳ）、ポイントの値から検索料を減算した（検索料を支払った）後に、モンスターカードの検索処理を行う（ステップＳ３１０）。この処理について具体的に説明すると、ＣＰＵ２１は、販売設定データにアクセスして、販売設定された全てのモンスターカードの中から検索条件を満たすモンスターカードを抽出する。また、ＣＰＵ２１は、抽出したモンスターカードのデータ及び販売価格を通知するウェブページ（Ｐ７に例示するウェブページ）を表示するためのＨＴＭＬデータを生成して（ステップＳ３１２）、ユーザ：ＡＢＣの通信端末１０に送信する。

さらに、ＣＰＵ２１は、図１１のウェブページＰ７上でメニューｍ１５が選択操作されたことを認識すると（ステップＳ３１４：ＹＥＳ）、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するポイントの値が、選択操作されたメニューｍ１５に対応するモンスターカードの販売価格以上であるか否かを判別する。そして、ＣＰＵ２１は、ユーザ：ＡＢＣのポイントの値がモンスターカードの販売価格以上であると判別した場合、ユーザ：ＡＢＣのポイントの値から販売価格を減算して、選択されたメニューｍ１５に対応するモンスターカードの購入処理を行う（ステップＳ３１６）。このようにして、ユーザ：ＡＢＣは、選択操作したメニューｍ１５に対応するモンスターカードを入手することができる。
なお、ＣＰＵ２１は、ウェブページＰ５上でメニューｍ１３が選択操作されずに所定時間経過した場合（ステップＳ３００：ＮＯ）、ウェブページＰ６上でメニューｍ１４が選択操作されずに所定時間経過した場合（ステップＳ３０６：ＮＯ）、ユーザ：ＡＢＣのポイントの値が検索料未満であった場合（ステップＳ３０８：ＮＯ）、あるいはウェブページＰ７上でメニューｍ１５が選択操作されずに所定時間経過した場合（ステップＳ３１４：ＮＯ）、購入処理を終了してもよい。

上述したように、本実施形態のゲーム制御装置によれば、ユーザ：ＡＢＣ（第１ユーザ）は、自らの入力によって、他のユーザ（第２ユーザ）に対応付けられたモンスターカード（オブジェクト）の検索条件（抽出条件）を設定することができる。また、ユーザ：ＡＢＣは、検索料（所定の対価）を支払うことによって、他のユーザに対応付けられたモンスターカードの中から検索条件を満たすモンスターカードに関する情報を得ることができる。つまり、ユーザ：ＡＢＣは、自ら設定した検索条件を満たすモンスターカードに関する情報を得るために、検索料を支払う必要がある。このため、所望のモンスターカード（検索条件を満たすモンスターカード）を検索するために検索料を支払うべきか否かなどについて、ユーザ：ＡＢＣに慎重に検討させることができるので、ユーザ：ＡＢＣの判断力や戦略などが求められる仕組みとすることができる。これにより、ユーザが所望のモンスターカードを検索する場合に興趣性を高めることができる。

（８）変形例
以下、上述した実施形態の変形例について説明する。

（８−１）変形例１
上記実施形態において、第２設定手段５５は、モンスターカード（オブジェクト）の抽出数が検索条件（抽出条件）に含まれている場合に、当該抽出数に基づいて検索料（所定の対価）を設定してもよい。
例えば、モンスターカードの抽出数が多いほど、多くの検索料が必要になるように設定されてもよい。この場合、所望のモンスターカードを入手する可能性を高めるために多くの検索料を支払うべきか（つまり、所望のモンスターカードの抽出数を多くすべきか）否かなどについて、ユーザ：ＡＢＣ（第１ユーザ）により慎重に検討させることができるので、ユーザ：ＡＢＣの判断力や戦略などがさらに求められる仕組みとすることができる。

本変形例では、例えば、ウェブページＰ５の代わりに、図１６のＰ８に例示するウェブページがユーザ：ＡＢＣの通信端末１０に表示されてもよい。ウェブページＰ８には、レア度を選択するためのプルダウンメニューｍ１２と、特技レベルを選択するためのプルダウンメニューｍ１６と、検索件数（抽出数）を選択するためのプルダウンメニューｍ１７と、検索条件を設定するための「検索条件を設定」と表記されたメニューｍ１３とが含まれる。
本変形例における第１設定手段５４では、ＣＰＵ２１は、ウェブページＰ８上でメニューｍ１３が選択操作されたことを認識すると、プルダウンメニューｍ１２，ｍ１６，ｍ１７の各々を用いて選択されたレア度、特技レベル及び検索件数の各々の値を検索条件として設定する。
本変形例における第２設定手段５５の機能は、例えば以下のように実現できる。なお、ここでは、モンスターカードの抽出数が多いほど、検索料が多く必要になる場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、検索料を設定する処理を行う場合、例えば以下の式（１）を用いて検索料を算出してもよい。なお、式（１）では、検索料をＦ、レア度に対応する検索料をＦａ、レア度以外の検索条件の数をＮ、レア度以外の１つの検索条件当たりの検索料をＦｂ、検索件数をＳＮとして記す。

Ｆ＝（Ｆａ＋（Ｎ×Ｆｂ））×ＳＮ…（１）

ここで、レア度に対応する検索料は上記実施形態で説明したデータを用いてもよく、例えば検索条件として設定されたレア度が５の場合、Ｆａの値は２０００である。また、Ｆｂの値は任意に設定し得るが、ここでは、一例として２００とする。さらに、Ｎの値は、ここでは２（特技レベル、検索件数）となる。例えば、検索条件として、レア度が５、特技レベルが７、検索件数が５に設定された場合には、図１６のウェブページＰ９に例示するように、検索料Ｆは１２０００ポイント（＝（２０００＋（２×２００））×５）となる。
式（１）を用いた場合、検索件数（ＳＮ）が多くなるほど、検索料（Ｆ）を多く設定することが可能となる。
なお、ここでは、式（１）を用いて検索料をもとめる場合を一例として説明したが、この場合に限られない。検索料は、例えば所定の演算式を用いて、検索件数を当該演算式に当てはめることによってもとめられてもよい。

（８−２）変形例２
上記変形例１において、抽出手段５６は、抽出したモンスターカード（オブジェクト）の数が抽出数未満の場合に、検索料（所定の対価）の少なくとも一部を第１ユーザに返還してもよい。
本変形例によれば、ユーザ：ＡＢＣ（第１ユーザ）は、モンスターカードの抽出数が自ら設定した抽出数未満の場合、支払った検索料の少なくとも一部を受け取ることが可能となる。このため、ユーザにとって、モンスターカードの検索による損失を低減する仕組みとすることができる。

本変形例における抽出手段５６の機能は、例えば以下のように実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１５のフローのステップＳ３１０の処理において、モンスターカードの抽出数が抽出条件として設定された検索件数未満であった場合、検索料の少なくとも一部をユーザ：ＡＢＣに返還する処理を行う。ここで、返還される検索料の値は、例えば、ステップＳ３０４で設定された検索料からモンスターカードの抽出数を検索件数としたときの検索料を減算した値であってもよいし、ステップＳ３０４で設定された検索料の全てであってもよい。当該処理の内容について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応するポイントを返還される検索料の値だけ増加させる。

（８−３）変形例３
上記実施形態において、第２設定手段５５は、検索条件（抽出条件）に基づいてモンスターカード（オブジェクト）が抽出されるタイミングにおけるゲーム制御装置の処理負荷に関する情報に基づいて、検索料（所定の対価）を設定してもよい。
例えば、モンスターカードが抽出されるタイミングにおけるゲーム制御装置の処理負荷が高いほど、多くの検索料が必要になるように設定されてもよい。この場合、ユーザ：ＡＢＣ（第１ユーザ）は、検索料をできるだけ低減するために、処理負荷の低いタイミングでモンスターカードの検索を行うことが動機付けられる。このため、モンスターカードの検索に基づくゲーム制御装置の過負荷を抑制することができる。

本変形例における第２設定手段５５の機能は、例えば以下のように実現される。なお、ここでは、モンスターカードが抽出されるタイミングにおけるゲーム制御装置の処理負荷が高いほど、多くの検索料が必要になる場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、例えば、図１５のフローのステップＳ３０４の処理において検索料を設定する処理を行う場合、ゲームサーバ２０の処理負荷に関する情報を取得した後に、例えば以下の式（２）を用いて検索料を算出してもよい。なお、式（２）では、検索料をＦ、係数をｋ、基準となる検索料、例えば、レア度に対応する検索料をＦａとして記す。

Ｆ＝ｋ×Ｆａ…（２）

ここで、係数ｋは、ゲームサーバ２０の処理負荷に関する情報に基づき設定してもよい。ゲームサーバ２０の処理負荷に関する情報には、例えばＣＰＵ２１あるいはメモリの使用率などが含まれ得るが、ここでは、ゲームサーバ２０の処理負荷に関する情報がＣＰＵ２１の使用率である場合を一例として説明する。この場合、係数ｋの値は、例えば以下のように設定されたデータを用いて設定することができる。
・ＣＰＵ２１の使用率が３０％未満の場合、ｋ＝１
・ＣＰＵ２１の使用率が３０％以上５０％未満の場合、ｋ＝１．５
・ＣＰＵ２１の使用率が５０％以上８０％未満の場合、ｋ＝２
・ＣＰＵ２１の使用率が８０％以上の場合、ｋ＝３
このように係数ｋを設定した場合、ゲームサーバ２０の処理負荷（つまり、ＣＰＵ２１の使用率）が高くなるほど、多くの検索料Ｆが必要となる。

また、ＣＰＵ２１は、検索条件に基づいてモンスターカードが抽出された過去のタイミングにおけるゲーム制御装置の処理負荷に関する情報に基づいて、検索料を設定してもよい。この場合、ＣＰＵ２１は、例えば図１７に例示する履歴データを参照して係数ｋを求めてもよい。図１７に例示する履歴データは、ＣＰＵ２１の使用率がモンスターカードの抽出を行ったタイミングごとに記録されたデータである。ＣＰＵ２１は、例えば、図１５のフローのステップＳ３１０の処理を行うごとにゲームサーバ２０の処理負荷に関する情報（ＣＰＵ２１の使用率）を取得し、取得した情報を履歴データに追記する。なお、履歴データは、例えばゲームデータベース３２に記憶されてもよい。
また、ＣＰＵ２１は、例えば、図１５のフローのステップＳ３０４の処理において検索料を設定する処理を行う場合、履歴データを参照して、当該処理を行うタイミングと最も近いタイミングのＣＰＵ使用率を抽出する。そして、ＣＰＵ２１は、抽出したＣＰＵ使用率に基づき係数ｋをもとめてもよい。

さらに、ＣＰＵ２１は、所定期間ごとのゲーム制御装置の処理負荷に関する情報に基づき、検索料を設定してもよい。この場合、ＣＰＵ２１は、例えば、ゲームサーバ２０の処理負荷に関する情報（ＣＰＵ２１の使用率）の所定の時間帯（例えば１１時〜１３時、１３時〜１５時など）ごとの平均値をもとめ、当該平均値に基づいて所定の時間帯ごとに係数ｋを設定してもよい。この場合、所定の時間帯と、ＣＰＵ２１の使用率の平均値と、係数ｋとの関係を示すデータは、例えば以下のように示される。
時間帯 ＣＰＵの使用率の平均値 係数ｋ
・１１時〜１３時 ８０％ １．８
・１３時〜１５時 ６０％ １．６
・１５時〜１７時 ７０％ １．７
ＣＰＵ２１は、例えば、図１５のフローのステップＳ３０４の処理において検索料を設定する処理を行う場合、このデータを参照して、当該処理を行うタイミングを含む時間帯に対応する係数ｋを抽出する。そして、ＣＰＵ２１は、抽出した係数ｋを用いて検索料をもとめてもよい。

（８−４）変形例４
上記実施形態において、第２設定手段５５は、検索条件（抽出条件）と共通する検索条件を用いて過去にモンスターカード（オブジェクト）を抽出した回数あるいは頻度に基づいて、検索料（所定の対価）を設定してもよい。
例えば、第１ユーザが検索条件と共通する検索条件を用いて過去にモンスターカードを抽出した回数あるいは頻度に基づいて、検索料を設定してもよい。また、例えば、ゲームを実行する全てのユーザが検索条件と共通する検索条件を用いて過去にモンスターカードを抽出した回数あるいは頻度に基づいて、検索料を設定してもよい。
例えば複数のユーザが同じモンスターカードを検索する場合には、モンスターカードの検索条件が共通する場合がある。また、複数のユーザが同じモンスターカードを所定期間の間集中して検索した場合には、ゲーム制御装置の処理負荷が高くなる場合がある。そこで、例えば、共通する検索条件を用いて過去にモンスターカードを抽出した回数あるいは頻度が多いほど、多くの検索料が必要になるように設定されてもよい。この場合、多くの検索料を支払ってまで当該モンスターカードを検索すべきか否かをユーザごとに慎重に検討させることができるので、当該モンスターカードの検索に基づくゲーム制御装置の過負荷を抑制することができる。

本変形例における第１設定手段５４では、ＣＰＵ２１は、例えば、図１５のフローのステップＳ３０２の処理を行うごとに、モンスターカードの検索条件を例えばＲＡＭ２３などの記憶装置に追記してもよい。
本変形例における第２設定手段５５の機能は、例えば以下のように実現される。なお、ここでは、共通する検索条件を用いて過去にモンスターカードを抽出した回数が多いほど、多くの検索料が必要になる場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、例えば、図１５のフローのステップＳ３０４の処理において検索料を設定する処理を行う場合、例えばＲＡＭ２３などの記憶装置を参照して、ステップＳ３０２の処理において設定された検索条件と共通する（同一の）検索条件の数をもとめる。また、ＣＰＵ２１は、上述した式（２）を用いて検索料を算出してもよい。この場合、係数ｋの値は、例えば以下のように設定されたデータを用いて設定することができる。
・検索条件と共通する検索条件の数が０以上１００未満の場合、ｋ＝１
・検索条件と共通する検索条件の数が１００以上１０００未満の場合、ｋ＝１．５
・検索条件と共通する検索条件の数が１０００以上１００００未満の場合、ｋ＝２
・検索条件と共通する検索条件の数が１００００以上の場合、ｋ＝３
このように係数ｋを設定した場合、共通する検索条件を用いて過去にモンスターカードを抽出した回数が多いほど、多くの検索料Ｆが必要となる。
なお、ここでは、検索条件と共通する検索条件を用いて過去にモンスターカードを抽出した回数に基づいて係数ｋを設定する場合を一例として説明したが、この場合に限られない。例えば、検索条件と共通する検索条件を用いて過去にモンスターカードを抽出した頻度に基づいて係数ｋを設定してもよい。
また、ＣＰＵ２１は、例えば、モンスターカードの抽出を行った最新の時刻からの経過時間に基づいて検索料を設定してもよい。この場合、ＣＰＵ２１は、モンスターカードの抽出を行った最新の時刻から検索料を設定するまでの期間の長さに応じて、係数ｋの値を設定してもよい。例えば、モンスターカードの抽出を行った最新の時刻から検索料を設定するまでの期間が短いほど、モンスターカードの検索が多く行われていると考えられる。このため、例えば、モンスターカードの抽出を行った最新の時刻から検索料を設定するまでの期間が短いほど、係数ｋの値が大きくなるように設定されてもよい。

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

上述した各実施形態では、複数のカード（モンスターカード）を用いてバトルを行う場合を例として説明したが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の各種オブジェクトを用いてバトルを行ってもよい。また、バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。あるいは、カード等のオブジェクトを使用せずにバトルを行ってもよい。

上述した各実施形態では、実行対象のゲームが、モンスターカードを用いたカードバトルゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、複数のユーザ間でオブジェクトを移転可能に構成されている場合には、本発明を好適に適用することができる。

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

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

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

上述した実施形態その他の記載では、ゲーム上のオブジェクトを移転する場合について説明したが、本発明は、移転対象となるオブジェクトがゲーム上のオブジェクトに限られない。
つまり、物品等の有体物（オブジェクト）やプログラム、データ等の無体物（オブジェクト）を移転対象とした検索装置であってもよい。この検索装置は、例えば、移転対象となるオブジェクトをユーザ間で取引するショッピングサービスシステムなどに適用され得る。この場合、対応付け手段５３は、ユーザとオブジェクトとを対応付ける機能を備えてもよい。第１設定手段５４は、第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する機能を備えてもよい。第２設定手段５５は、所定の対価を設定する機能を備えてもよい。抽出手段５６は、前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する機能を備えてもよい。通知手段５７は、抽出されたオブジェクトに関する情報を前記第１ユーザに通知する機能を備えてもよい。

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…実行手段
５３…対応付け手段
５４…第１設定手段
５５…第２設定手段
５６…抽出手段
５７…通知手段

Claims (10)

1. 複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するゲーム制御装置であって、
   ユーザと、前記オブジェクトとを対応付ける対応付け手段と、
   第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段と、
   所定の対価を設定する第２設定手段と、
   前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段と、
   抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段と、
   を備えた、ゲーム制御装置。
2. 前記第２設定手段は、オブジェクトの属性に関する条件が前記抽出条件に含まれている場合に、当該属性に基づいて前記所定の対価を設定することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記第２設定手段は、オブジェクトの抽出数が前記抽出条件に含まれている場合に、当該抽出数に基づいて前記所定の対価を設定することを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記抽出手段は、抽出したオブジェクトの数が前記抽出数未満の場合に、前記所定の対価の少なくとも一部を前記第１ユーザに返還することを特徴とする、
   請求項３に記載されたゲーム制御装置。
5. 前記第２設定手段は、前記抽出条件に基づいてオブジェクトが抽出されるタイミングにおけるゲーム制御装置の処理負荷に関する情報に基づいて、前記所定の対価を設定することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記第２設定手段は、前記抽出条件と共通する抽出条件を用いて過去にオブジェクトを抽出した回数あるいは頻度に基づいて、前記所定の対価を設定することを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するゲーム制御方法であって、
   ユーザと、前記オブジェクトとを対応付けるステップと、
   第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定するステップと、
   所定の対価を設定するステップと、
   前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出するステップと、
   抽出されたオブジェクトに関する情報を前記第１ユーザに通知するステップと、
   を備えた、ゲーム制御方法。
8. 複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するプログラムであって、
   コンピュータに、
   ユーザと、前記オブジェクトとを対応付ける機能、
   第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する機能、
   所定の対価を設定する機能、
   前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する機能、及び
   抽出されたオブジェクトに関する情報を前記第１ユーザに通知する機能、
   を実現させるためのプログラム。
9. 通信端末と、当該通信端末からアクセスされるサーバとを含み、複数のユーザ間でオブジェクトを移転可能なゲームの実行を制御するゲームシステムであって、
   ユーザと、前記オブジェクトとを対応付ける対応付け手段、
   第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段、
   所定の対価を設定する第２設定手段、
   前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段、
   抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。
10. ユーザとオブジェクトとを対応付ける対応付け手段と、
    第１ユーザによる所定の入力に関する情報に基づいて、一又は複数の第２ユーザに対応付けられたオブジェクトの抽出条件を設定する第１設定手段と、
    所定の対価を設定する第２設定手段と、
    前記第１ユーザによる前記所定の対価の支払いを条件として、前記第２ユーザに対応付けられたオブジェクトの中から前記抽出条件を満たすオブジェクトを抽出する抽出手段と、
    抽出されたオブジェクトに関する情報を前記第１ユーザに通知する通知手段と、
    を備えた、検索装置。

Images