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

Abstract

【課題】複数のユーザとの間でオブジェクトの取引を容易に行うことができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供する。
【解決手段】ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定する設定手段と、ユーザ同士を関係付ける第１の関係付け手段と、第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供する情報提供手段と、を備える。
【選択図】図８

Description

本発明は、ユーザによるゲームの実行を制御する技術に関する。

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

上述したソーシャルゲームの一例として、非特許文献１に開示されているデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。この公知のデジタルカードゲームは、ユーザが様々なエリアを探索して新たなキャラクタやアイテムなどのカードを取得するクエスト処理を行うメニューが設けられている。このようなソーシャルゲームは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換などが行なわれている。
また、従来のソーシャルゲームでは、ユーザが、ゲーム上保有するアイテムやキャラクタなどのオブジェクトを他のユーザと取引することができるようになっている。

アプリＳＴＹＬＥ Vol.5（株式会社イースト・プレス）、7-8頁

従来のソーシャルゲームでは、ユーザ間でオブジェクトの取引が行われる場合、一方のユーザが、他方のユーザのゲーム内のウェブページにアクセスし、ウェブページ上に表示されたオブジェクトを参照することによって、他方のユーザに対して取引を申請する、という仕組みとなっている。この場合、複数のユーザに対して取引の申請を行うユーザにとっては、複数のユーザ毎に設けられたウェブページに一つずつアクセスする必要がある。したがって、複数のユーザとの間でオブジェクトの取引を行う際には、煩雑かつ手間のかかる操作が必要となるため、取引の活性化を図ることが困難であった。

本発明は上述した観点に鑑みてなされたもので、複数のユーザとの間でオブジェクトの取引を容易に行うことができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定する設定手段と、
ユーザ同士を関係付ける第１の関係付け手段と、
第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供する情報提供手段と、
を備える。

オブジェクトは、ユーザがゲーム上で保有可能なものであれば何でもよいが、例えば、アイテムやキャラクタを含む。キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。

このゲーム制御装置では、要求ユーザが第１のユーザの対象オブジェクトに関する情報を要求した場合には、要求ユーザに対して、第１のユーザ及び第２のユーザそれぞれの対象オブジェクトに関する情報が提供される。これにより、要求ユーザにとっては、１回の情報要求を行うことで、第１のユーザの対象オブジェクトに関する情報だけではなく、第２のユーザの対象オブジェクトに関する情報も得ることができる。このため、複数のユーザに対して取引の申請を行う場合に、例えば、複数のユーザ毎に設けられたウェブページに一つずつアクセスするなどの煩雑かつ手間のかかる操作が不要となることから、複数のユーザとの間でオブジェクトの取引を容易に行うことができ、ひいては取引の活性化を図ることができる。

上記ゲーム制御装置において、前記対象オブジェクトに関する情報には、前記対象オブジェクトの取引の条件に関する情報が関連付けられており、前記情報提供手段は、前記対象オブジェクトに関する情報と、当該情報に関連付けられた取引の条件に関する情報とを、前記要求ユーザに提供してもよい。
ここで、「取引の条件」とは、例えば、ゲーム上の仮想通貨を用いて取引が行われる場合には対象オブジェクトの販売価格であってもよいし、ユーザ間でオブジェクトを交換することによって取引が行われる場合には、交換可能なオブジェクトの数などであってもよい。
このゲーム制御装置によれば、第１のユーザ及び第２のユーザそれぞれの対象オブジェクトに関する情報と、第１のユーザの対象オブジェクトに関連付けられた取引の条件に関する情報と、第２のユーザの対象オブジェクトに関連付けられた取引の条件に関する情報とが、要求ユーザに提供される。このため、要求ユーザは、取引の条件に従って対象オブジェクトの取引を行うか否かを容易に判別することができる。これにより、複数のユーザに対して取引の申請を行う場合に、例えば、取引の条件をユーザ毎に問い合わせる等の煩雑な手続きが不要となることから、複数のユーザとの間でオブジェクトの取引を容易に行うことができる。

上記ゲーム制御装置において、前記情報提供手段は、第１のユーザ及び前記第２のユーザの対象オブジェクトが同一の場合に、前記第１のユーザ及び前記第２のユーザそれぞれの前記対象オブジェクトの取引の条件に関する情報を、前記対象オブジェクトに関する情報に関連付けてもよい。
このゲーム制御装置によれば、要求ユーザは、第１のユーザ及び第２のユーザの対象オブジェクトが同一の場合に、当該対象オブジェクトに対する第１のユーザ及び第２のユーザそれぞれの取引の条件に関する情報をまとめて取得することができる。このため、要求ユーザは、第１のユーザ及び第２のユーザのうち何れのユーザと取引を行うべきか容易に判別することが可能となる。これにより、複数のユーザとの間でオブジェクトの取引をさらに容易に行うことができる。

上記ゲーム制御装置において、前記情報提供手段は、第１のユーザ及び前記第２のユーザの対象オブジェクトが同一の場合に、前記第１のユーザ及び前記第２のユーザの取引の条件のうち、緩和された条件に関する情報を提供してもよい。
ここで、「緩和された条件」とは、要求ユーザにとって取引を実現できる可能性がより高い条件であってよく、例えば、ゲーム上の仮想通貨を用いて取引が行われる場合には対象オブジェクトの販売価格がより低く設定された条件であってもよい。また、ユーザ間でオブジェクトを交換することによって取引が行われる場合には、交換可能なオブジェクトの数が少なく設定された条件であってもよいし、交換可能なオブジェクトの希少価値が低く設定された条件などであってもよい。
このゲーム制御装置によれば、第１のユーザ及び第２のユーザの対象オブジェクトが同一の場合に、第１のユーザ及び第２のユーザの取引の条件のうち、要求ユーザにとって取引を実現できる可能性の高い条件が要求ユーザに提供される。このため、要求ユーザは、第１のユーザ及び第２のユーザのうち何れのユーザと取引を行うべきか検討する手間を軽減することができるので、複数のユーザとの間でオブジェクトの取引をさらに容易に行うことができる。

上記ゲーム制御装置において、前記情報提供手段は、前記第１のユーザ及び前記第２のユーザの対象オブジェクトのうち、前記要求ユーザの対象オブジェクトと異なるオブジェクトに関する情報を提供してもよい。
このゲーム制御装置によれば、要求ユーザが対象オブジェクトを設定している場合には、第１のユーザ及び第２のユーザの対象オブジェクトのうち、要求ユーザの対象オブジェクト以外の対象オブジェクトに関する情報が要求ユーザに提供される。要求ユーザの対象オブジェクトは、要求ユーザが既に保有し、かつ取引の対象とするオブジェクトであることから、要求ユーザは、そのオブジェクトを他のユーザから得ることに興味が低いと考えられるため、上述した構成とすることで、要求ユーザは、自身にとって必要な対象オブジェクトに関する情報を効率よく取得することができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける第２の関係付け手段を備え、前記情報提供手段は、第１のユーザの対象オブジェクトと同一の対象オブジェクトを保有する第２のユーザが複数存在する場合に、前記第２のユーザのうち前記第２の関係付け手段によって前記第１のユーザと関係付けられた第３のユーザの対象オブジェクトに関する情報を提供してもよい。
このゲーム制御装置によれば、第１のユーザ及び複数の第２のユーザの対象オブジェクトが同一の場合に、複数の第２のユーザのうち、第１のユーザと関係度の高い第３のユーザの対象オブジェクトに関する情報が要求ユーザに提供される。これにより、各ユーザは、自らの取引の機会を増やすために、他のユーザと関係付けることが動機付けられる。このため、ユーザ間の交流を促進することができることから、ゲームのソーシャル性を高めることができる。

上記ゲーム制御装置において、前記情報提供手段は、第１のユーザの対象オブジェクトと同一の対象オブジェクトを保有する第２のユーザが複数存在する場合に、前記第１のユーザと前記第３のユーザとの前記ゲーム上の関係度合いを示すパラメータに基づいて、前記第３のユーザの対象オブジェクトに関する情報を提供してもよい。
このゲーム制御装置によれば、例えば、第１のユーザと第３のユーザの関係度が所定の閾値以上であれば、第３のユーザの対象オブジェクトに関する情報が要求ユーザに提供されるように構成されている場合には、第３のユーザは、自らの取引の機会を増やすために、第１のユーザとの関係度合いを高めることが動機付けられる。このため、ユーザ間の交流をさらに促進することができることから、ゲームのソーシャル性をさらに高めることができる。

上記ゲーム制御装置において、前記情報提供手段は、前記第１の関係付け手段によって前記第２のユーザと関係付けられ、且つ、前記第１のユーザと異なる他のユーザの対象オブジェクトに関する情報を提供してもよい。
このゲーム制御装置によれば、要求ユーザが第１のユーザの対象オブジェクトに関する情報を要求した場合には、要求ユーザに対して、第１のユーザ及び第２のユーザそれぞれの対象オブジェクトに関する情報だけでなく、第２のユーザと関係付けられた他のユーザの対象オブジェクトに関する情報も提供される。これにより、要求ユーザにとっては、１回の情報要求を行うことで、多くのユーザの対象オブジェクトに関する情報を得ることが可能となる。

本発明の第２の観点は、ゲーム制御装置におけるゲーム制御方法であって、
ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定するステップと、
ユーザ同士を関係付けるステップと、
第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供するステップと、
を備える。

本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定し、記憶装置に記憶させる機能、
ユーザ同士を関係付ける機能、及び
第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を前記記憶装置から取得して提供する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定する設定手段、
ユーザ同士を関係付ける第１の関係付け手段、
第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供する情報提供手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

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

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムよれば、複数のユーザとの間でゲーム上のオブジェクトの取引を容易に行うことができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 モンスターキャラクタデータベースのデータ構成の一例を示す図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 販売設定データのデータ構成の一例を示す図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 ユーザの通信端末において表示されるウェブページを例示する図。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すシーケンスチャート。 実施形態のゲーム制御装置の主要な処理の一例を示すシーケンスチャート。 変形例１に係るゲーム制御装置において表示されるウェブページを例示する図。 親密度データの構成例を示す図。 変形例６に係るゲーム制御装置において表示されるウェブページを例示する図。 通信端末及びゲームサーバの各々における各機能の構成例を示す図。

以下、本発明の実施形態について説明する。

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

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

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

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

ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。

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

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

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

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

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

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

例えば、ＣＰＵ２１は、無線通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。

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

本実施形態のゲーム制御装置によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲーム制御装置によって実現されるゲームの一例として、モンスターカードを用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、ユーザが、モンスターが描かれたゲーム内のカード（モンスターカード）を収集することによって自らのチームを作り上げ、他のユーザのチームとバトルを行うように構成されているゲームである。このゲームは、例えば、以下の処理を含む。
・クエスト処理：
少なくとも一つのモンスターカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してモンスターカードを得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費する。
・バトル処理：
他のユーザのチームとバトルを行う処理である。なお、バトル処理については、ここでは詳しく述べないが、例えばユーザがバトルで使用するモンスターカードの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）の大小に応じて、バトルの結果が決定されるように構成される。例えば、パラメータの値の大きいモンスターカードをバトルに使用したユーザが、それよりパラメータの値の小さいモンスターカードをバトルに使用した他のユーザに対して勝利する可能性が高くなるように設定されてもよい。この場合、ユーザの保有するモンスターカードのパラメータの値が大きいほど、他のユーザと比べてゲームをより優位に進められるようになる。また、ユーザのゲーム上の属性（後述する）と同じ属性を有するモンスターカードがバトルで使用されると、バトルの間、当該モンスターカードのパラメータが所定の割合だけ上昇するようになっていてもよい。
・販売設定処理：
ユーザが保有するモンスターカードを他のユーザに販売可能に設定するための処理である。一度に販売可能なモンスターカードの最大数（例えば１０枚）は、適宜設定されてもよい。また、モンスターカードを販売可能に設定するためには、モンスターカード１枚当たり所定数の所持コイン（後述する）が必要となるように設定されてもよい。
・移動処理：
ユーザの通信端末１０上に、ゲーム内に設けられた他のユーザのウェブページを表示させるための処理である。
・販売提携処理：
ユーザが、他のユーザに対して、モンスターカードの販売を提携して行うことを申請するための処理である。このゲームでは、ユーザ同士が販売提携をした場合、提携関係にある両ユーザが各々販売しているモンスターカードが、両ユーザのゲーム内のウェブページ上で販売されるようになっている。
・商品情報取得処理：
ユーザが、他のユーザにより販売されているモンスターカードに関する情報を取得するための処理である。

なお、本実施形態におけるモンスターカードは、本発明の「オブジェクト」の一例であるが、本発明の「オブジェクト」はこれに限られない。オブジェクトは、ユーザがゲーム上で保有可能なものであれば何でもよく、例えば、ユーザがゲーム上で保有することができるキャラクタやアイテムなどであってもよいし、ユーザがゲームを進行させ、あるいはゲーム上の特典を得るために必要となるキャラクタやアイテムなどであってもよい。
ここで、ゲーム上の特典とは、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。さらに、アイテムとは、例えば、体力ポイントなどを即時に回復する回復薬や、モンスターカードの能力を上昇させる薬品、武器あるいは防具などであってもよい。さらに、ゲーム上の有利な効果とは、例えば、アイテムを使用せずにモンスターカードの能力値を上昇させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、ゲーム上の有利な効果とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作に応じて消費するゲーム上の各種ポイント（体力ポイントなど）の消費量を通常よりも低減させることであってもよいし、ユーザが各種ポイントを入手できることであってもよい。さらに、ゲーム上の有利な効果とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよい。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・属性
ゲームにおいて、ユーザ登録時に、ユーザが指定する属性である。このゲームでは、例えば、Ａ、Ｂ、Ｃの３つの属性が設けられており、ユーザは３つの属性の中からいずれかの属性をユーザ登録時に選択する。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。例えば、クエスト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・体力ポイント
本実施形態のゲームにおいて、クエスト処理を実行する上で必要となるポイントである。体力ポイントは、クエスト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・モンスター数
ユーザが保有するモンスターカードの数である。モンスター数の最大値（例えば、６０）は予め規定されている。
・所持コイン
ユーザＩＤに対応するユーザがゲーム上で有料機能を利用するときに必要となるゲーム上の仮想通貨（コイン）の所持額である。所持コインは、例えば、ユーザが、他のユーザからモンスターカードを購入したときなどに消費（低減）し、ユーザが、他のユーザに対してモンスターカードを売却したときにその販売額に応じて増加してもよい。なお、所持コインは、例えば、ユーザがサービス提供者等に所定の方法で実際の金銭を支払うことで、その支払額に応じて増加してもよい。
・仲間ユーザＩＤ
ユーザの仲間として関係付けられた他のユーザ（仲間ユーザ）のユーザＩＤのデータである。
・提携ユーザＩＤ
ユーザの販売提携先として関係付けられた他のユーザ（提携ユーザ）のユーザＩＤのデータである。
・保有カードのパラメータ
ユーザが保有するモンスターカードのデータ（後述する）などが含まれる。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、クエスト処理の進行状況を示す情報や、他のユーザとのバトル結果についての情報などを含む。
また、本実施形態のゲームでは、モンスターカードの収集、モンスターカードを用いたバトル、モンスターカードの取引が行われるようになっている。そのため、ゲームデータベース３２には、複数のモンスターカードの各々のデータが記述されたモンスターキャラクタデータベースが記憶されている。モンスターキャラクタデータベースの例を図７に示す。

図７に示すように、モンスターキャラクタデータベースには、モンスターキャラクタ（ＭＣ１，ＭＣ２，…）ごとに、画像、攻撃力、防御力、レア度、属性の各項目のデータを含む。なお、レア度とは、モンスターカードの希少価値の度合を示す値であり、その値が高いほどゲーム内で出現する確率が非常に低く設定されている。なお、本実施形態では、レア度を１〜５の５段階で表しており、能力（攻撃力、防御力など）の際立ったモンスターキャラクタや人気のあるモンスターキャラクタのレア度は高く設定されている。

（５）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述したモンスターカードを用いたデジタルカードゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図８を参照して説明する。図８は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図８の機能ブロック図において、設定手段５３、関係付け手段（第１の関係付け手段）５４及び情報提供手段５５が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。
また、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。

登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。この登録処理は、ユーザが本実施形態のゲームにユーザ登録を行うときに実行される。
なお、登録手段５１は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。

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

ゲーム進行手段５２は、ユーザが本実施形態のゲームを実行するに当たって、ユーザのログイン時の認証処理を実行する機能を備える。
このゲーム進行手段５２の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。

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

ゲーム進行手段５２によって通信端末１０に表示されるゲームのトップページの例を図９に示す。図９に示すトップページは、個々のユーザＩＤに応じたウェブページで構成される。図９に例示されるトップページは、ユーザデータ表示領域、モンスター画像表示領域、メニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、属性、技能レベル（レベル）、体力ポイント、モンスター数、仲間ユーザ（仲間ユーザのユーザＩＤの数）、提携ユーザ（提携ユーザのユーザＩＤの数）の各項目のデータ（図６参照）が表示される領域である。なお、図９において、モンスター数の一例として「４０／６０」と表記されているが、これは、ユーザが保有するモンスターカードが４０枚であり、最大で保有可能なモンスターカードの枚数が６０枚であることを示す。モンスター画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数のモンスターカードのうちユーザによって予め指定されたモンスターカードの画像が表示される領域である。メニュー表示領域には、本実施形態のゲームに設けられる複数の処理のうち一部の処理（クエスト処理、販売設定処理、移動処理）に対応したメニューとして、それぞれ「クエスト」、「販売設定」、「移動」と表記されたメニューｍ１，ｍ２，ｍ３が含まれる。

例えば図９に示すトップページをユーザの通信端末１０に表示する場合、ゲーム進行手段５２の機能は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、モンスター画像表示領域に表示すべきモンスターカードの画像データを読み出す。次にＣＰＵ２１は、図９に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。
ＣＰＵ２１は、通信端末１０に表示されたメニューｍ１、ｍ２又はｍ３に対するユーザの選択操作に応じた処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。

また、ゲーム進行手段５２は、クエスト処理を実行する機能を備える。
［クエスト処理］
クエスト処理は、少なくとも一つのモンスターカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してモンスターカードを得る処理である。
クエスト処理において、ゲーム進行手段５２は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図９のトップページ上でメニューｍ１が選択操作されると、図１０に示すウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。図１０に示すウェブページには、探索の対象となるエリア（図１０の例では、エリア１）の進行度合いを示す探索率のゲージ、探索処理を実行するための「探索する」と表記されたメニューｍ１０などが含まれる。
クエスト処理において、ユーザは、メニューｍ１０を選択操作する。この操作を契機として、探索の対象となるエリアについての探索が行われる。このとき、メニューｍ１０が選択操作されて探索が行われる度に、「探索率」（％）の値がランダムな増加量で増加する。上述したように、このゲームでは、１回の探索につき、所定量（例えば５ポイント）の体力ポイントが減少するように構成されている。探索が行われる（メニューｍ１０が選択操作される）度に、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する。また、ＣＰＵ２１は、探索が行われる度に、増加した探索率を含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。なお、図１０に示すウェブページは、１回の探索に要する体力ポイントの値が表示されるように構成されてもよい。

クエスト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、クエスト用に予め設けられた複数のモンスターカードの中から所定の、あるいはランダムな確率で抽選を行う。ＣＰＵ２１は、抽選によりモンスターカードを得た（発掘した）場合には、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのデータに対して、発掘されたモンスターカードのデータを追加して、モンスター数の値を１だけ増加させる。さらに、ＣＰＵ２１は、モンスターカードが得られたことを表す情報を表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図１０においてエリアの探索率が１００％に達すると、エリア１についての探索は終了し、探索対象は次のエリア（この場合、エリア２）に移る。

クエスト処理では、探索対象となるエリアごとに、１回の探索処理に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索処理で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。
クエスト処理では、メニューｍ１０に対する選択操作を行う度に体力ポイントが減少していくため、クエスト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される体力ポイントがクエスト処理の実行前よりも減少されて表示されることになる。なお、体力ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）する。

さらに、ゲーム進行手段５２は、販売設定処理を実行する機能を備える。
［販売設定処理］
販売設定処理は、ユーザが保有するモンスターカードを他のユーザに販売可能に設定するための処理である。
販売設定処理において、ゲーム進行手段５２は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図９のトップページ上でメニューｍ２が選択操作されると、選択操作を行ったユーザのユーザＩＤに対応するユーザデータを参照して、当該ユーザの保有カードのデータを抽出する。そして、ＣＰＵ２１は、図１１に示すウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。図１１に示すウェブページには、選択操作を行ったユーザが保有するモンスターカードの全てを表示する領域が含まれる。それぞれのモンスターカードに対応する領域には、モンスターカードの販売価格（図の例ではコインの枚数）を入力するためのテキストボックス１００と、販売者からのコメントなどを入力するためのテキストボックス１０１と、販売設定を実行するための「販売する」と表記されたメニューｍ１１などが含まれる。

設定手段５３は、販売設定処理において、ユーザがゲーム上保有する一又は複数のモンスターカード（オブジェクト）を、取引の対象となる対象オブジェクトとして設定する機能を備える。
ここで、本実施形態では、ユーザが自ら保有するモンスターカードを他のユーザに販売することを「取引」の一例として説明しているが、本発明の「取引」はこれに限られない。「取引」とは、例えば、ユーザが他のユーザからモンスターカードを購入することであってもよい。
設定手段５３は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、図１１に示すウェブページ上でメニューｍ１１が選択操作されると、選択操作されたメニューｍ１１に対応するモンスターカードの販売設定処理を行う。販売設定処理について具体的に説明すると、ＣＰＵ２１は、選択操作されたメニューｍ１１に対応するモンスターカードのデータ（画像、攻撃力、防御力、レア度、属性など）と、選択操作されたメニューｍ１１と同じ領域に含まれるテキストボックス１００，１０１に入力されたテキスト情報とを、ゲームデータベース３２内の販売設定データに記録する。図１２に販売設定データの構成例を示す。図１２に示すように、販売設定データは、ユーザ（ユーザＩＤ）ごとに、販売設定されたモンスターカードのデータと、当該モンスターカードの販売価格と、当該モンスターカードを販売するユーザからのコメントなどが記述されるデータである。つまり、モンスターカードが販売設定データに記録されることにより、当該モンスターカードは、対象オブジェクトとして設定される。
なお、ユーザが他のユーザからモンスターカードを購入することにより取引が行われる場合には、販売設定データと同様に構成された購入設定データを設けてもよい。この場合、購入設定データには、販売価格の代わりに購入希望価格が含まれてもよい。

ゲーム進行手段５２は、移動処理を実行する機能を備える。
［移動処理］
移動処理は、ユーザの通信端末１０上に、ゲーム内に設けられた他のユーザのウェブページを表示させるための処理である。
移動処理におけるゲーム進行手段５２の機能は、図１３のステップＳ１〜Ｓ２を参照すると、例えば以下のとおり実現される。図１３のステップＳ１〜Ｓ２は、移動処理においてユーザの通信端末１０に表示される一連のウェブページを例示する図である。図１３では、移動処理を実行するユーザが「ＫＮＭ」（以下、ユーザ：ＫＮＭと表記する。）であって、「ＡＢＣ」というユーザ（以下、ユーザ：ＡＢＣと表記する。）のゲーム内のウェブページに移動（アクセス）する場合を一例として説明する。

先ず、ユーザ：ＫＮＭの通信端末１０のトップページ上でメニューｍ３（図９参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、移動先のユーザの複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに抽出する。そして、ＣＰＵ２１は、複数の候補を抽出すると、図１３のステップＳ１に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０宛に送信する。ステップＳ１のウェブページは、複数の候補のリストからいずれかの候補を移動先として選択可能に構成されている。
複数の候補のリストからいずれかの候補（ここでは、ユーザ：ＡＢＣ）を選択する操作がユーザ：ＫＮＭによってなされると、ＣＰＵ２１は、図１３のステップＳ２に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０宛に送信する。ステップＳ２に示すウェブページには、ユーザ：ＡＢＣのゲーム内のウェブページであることを示すテキストなどの情報と、本実施形態のゲームに設けられる複数の処理のうち一部の処理（販売提携処理、商品情報取得処理）に対応したメニューとして、それぞれ「販売提携の申請」、「商品情報取得」と表記されたメニューｍ２０，ｍ２１などが含まれる。

なお、ゲーム進行手段５２は、複数の候補の抽出に当たって、所定の条件に基づいて複数の候補を抽出してもよい。ここで、所定の条件とは、例えば、移動処理を実行するユーザの属性と同じ属性のモンスターキャラクタに対応するモンスターカードを販売設定した他のユーザを候補として抽出することであってもよいし、ユーザの属性と同じ属性のモンスターキャラクタに対応するモンスターカードを所定数以上販売設定した他のユーザを候補として抽出することであってもよい。また、所定の条件とは、例えば、レア度が所定値以上のモンスターキャラクタに対応するモンスターカードを販売設定している他のユーザを候補として抽出することであってもよい。さらに、所定の条件とは、例えば、モンスターキャラクタ同士を合成させることにより、能力値の高いモンスターキャラクタのパラメータを上昇させることができるようにゲームが構成されている場合には、能力値の小さいモンスターキャラクタに対応するモンスターカードを所定数以上販売設定している他のユーザを候補として抽出することであってもよい。さらに、所定の条件とは、例えば、ユーザの保有するモンスターキャラクタのうち同じ属性のモンスターキャラクタが所定数以上存在する場合には、当該属性のモンスターキャラクタに対応するモンスターカードを所定数以上販売設定している他のユーザを候補として抽出することであってもよい。
この場合、ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０のトップページ上でメニューｍ３（図９参照）の選択操作がなされ、その選択結果を受信すると、ユーザデータベース３１にアクセスし、所定の条件を満たす他のユーザを候補として抽出すればよい。

関係付け手段５４は、ユーザ同士を関係付ける機能を備える。具体的には、関係付け手段５４は、ユーザＩＤに基づく申請を契機として、当該ユーザＩＤを他のユーザＩＤと関係付けて登録する。すなわち、関係付け手段５４は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤに対応するユーザを「提携ユーザ」として登録する。なお、以下の説明では、ユーザＩＤが販売提携の関係にあることと、対応するユーザが販売提携の関係にあることとは、同義である。なお、関係付け手段５４は、本発明の「第１の関係付け手段」の一例である。
関係付け手段５４は、販売提携処理を実行する。
［販売提携処理］
販売提携処理は、ユーザが、他のユーザに対して、モンスターカードの販売提携を申請するための処理である。上述したように、このゲームでは、ユーザ同士が販売提携をした場合、提携関係にある両ユーザが各々販売しているモンスターカードが、両ユーザのゲーム内のウェブページ上で販売されるようになっている。

販売提携処理におけるゲームの流れを、図１３を参照して説明する。図１３では、販売提携を申請するユーザ（申請元のユーザ）がユーザ：ＫＮＭであり、販売提携の申請先のユーザがユーザ：ＡＢＣである場合を一例として示している。図１３のステップＳ３〜５は、販売提携処理においてユーザの通信端末１０に表示されるウェブページの例を順に示している。
先ず、ユーザ：ＫＮＭが、図１３のステップＳ２に示すウェブページ上で、メニューｍ２０を選択すると、図１３のステップＳ３に示すウェブページが、ユーザ：ＡＢＣの通信端末１０上に表示される。ここで、ステップＳ３に示すウェブページが通信端末１０上に表示されるタイミングは、例えば、ユーザ：ＡＢＣがゲームをプレイ中の場合には、ユーザ：ＫＮＭがユーザ：ＡＢＣを選択したタイミングとほぼ同時であってもよく、ユーザ：ＡＢＣがゲームをプレイしていない場合には、ユーザ：ＡＢＣがゲームのプレイを開始したタイミングであってもよい。
ステップＳ３に示すウェブページには、申請元のユーザ（ユーザ：ＫＮＭ）の表示画像と、申請元のユーザからの販売提携の申請が届いた旨を示すメッセージと、販売提携の申請を受けるか否かを選択するためのメニューｍ２２，ｍ２３などが含まれる。ユーザ：ＡＢＣは、ユーザ：ＫＮＭからの販売提携の申請を受けるか否かを選択する。

ユーザ：ＡＢＣが、ステップＳ３に示すウェブページ上で、メニューｍ２２を選択する（販売提携の申請を受ける）と、図１３のステップＳ４に示すウェブページが、ユーザ：ＫＮＭの通信端末１０上に表示される。ステップＳ４に示すウェブページには、ユーザ：ＫＮＭがユーザ：ＡＢＣと販売提携したことを示すメッセージと、ユーザ：ＫＮＭが販売設定したモンスターカード（商品）がユーザ：ＡＢＣのゲーム内のウェブページで販売されることを通知するメッセージなどが含まれる。
一方、ユーザ：ＡＢＣが、ステップＳ３に示すウェブページ上で、メニューｍ２２を選択する（つまり、販売提携の申請を受ける）と、図１３のステップＳ５に示すウェブページが、ユーザ：ＡＢＣの通信端末１０上に表示される。ステップＳ５に示すウェブページには、ユーザ：ＡＢＣがユーザ：ＫＮＭと販売提携したことを示すメッセージと、ユーザ：ＡＢＣが販売設定したモンスターカード（商品）がユーザ：ＫＮＭのゲーム内のウェブページで販売されることを通知するメッセージなどが含まれる。

販売提携処理において、関係付け手段５４は、以下のようにして実現できる。図１３のステップＳ２に示すウェブページにおいて、ユーザ：ＫＮＭ（申請元のユーザ）が、メニューｍ２０を選択すると、ゲームサーバ２０のＣＰＵ２１は、申請元のユーザの通信端末１０から、申請先のユーザのユーザＩＤ（あるいは、対応するユーザ名）を指定した提携申請メッセージを受け付ける。この提携申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。
ＣＰＵ２１は、提携申請メッセージを受け付けると、提携申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく提携申請を受ける（承認する）か否かを返信することを要求するためのウェブページ（図１３のステップＳ３に示すウェブページ）を表示させるＨＴＭＬデータを送信する。図１３のステップＳ３に示すウェブページにおいて、メニューｍ２２が選択操作されることにより、提携申請を承認する承認メッセージが返信されれば、ＣＰＵ２１は、両者を提携ユーザとして登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「提携ユーザ」の箇所（図６参照）にデータを書き込む。
そして、ＣＰＵ２１は、図１３のステップＳ４に示すウェブページを表示するためのＨＴＭＬデータを生成して、申請元のユーザの通信端末１０宛に送信する。また、ＣＰＵ２１は、図１３のステップＳ５に示すウェブページを表示するためのＨＴＭＬデータを生成して、申請先のユーザの通信端末１０宛に送信する。

情報提供手段５５は、ユーザ（第１のユーザ）の取引対象のモンスターカード（対象オブジェクト）に関する情報を要求する要求ユーザに対して、ユーザ（第１のユーザ）及び当該ユーザに関係付けられた提携ユーザ（第２のユーザ）それぞれの取引対象のモンスターカードに関する情報を提供する機能を備える。ここで、要求ユーザは、ユーザ（第１のユーザ）と同一であってもよいし、異なっていてもよい。要求ユーザがユーザと同一の場合、ゲーム内の自らのウェブページを通信端末１０上に表示させたときに、提携ユーザの取引対象のモンスターカードに関する情報が表示されているか否かを確認することが可能となる。また、モンスターカードに関する情報は、テキストデータ、画像データ、音声データなどであってもよい。

また、情報提供手段５５は、取引対象のモンスターカード（対象オブジェクト）に関する情報に、当該モンスターカードの取引の条件に関する情報が関連付けられている場合には、取引対象のモンスターカードに関する情報と、当該情報に関連付けられた取引の条件に関する情報とを、要求ユーザに提供してもよい。
ここで、「取引の条件」とは、例えば、ゲーム上の仮想通貨（コイン）を用いて取引が行われる場合にはモンスターカードの販売価格であってもよいし、ユーザ間でモンスターカードやアイテムなどのオブジェクトを交換することによって取引が行われる場合には、交換可能なオブジェクトの数などであってもよい。
この場合、ユーザ及び提携ユーザそれぞれの取引対象のモンスターカードに関する情報と、ユーザの取引対象のモンスターカードに関連付けられた取引の条件に関する情報と、提携ユーザの取引対象のモンスターカードに関連付けられた取引の条件に関する情報とが、要求ユーザに提供される。このため、要求ユーザは、取引の条件に従ってモンスターカードの取引を行うか否かを容易に判別することができる。これにより、複数のユーザに対して取引の申請を行う場合に、例えば、取引の条件をユーザ毎に問い合わせる等の煩雑な手続きが不要となることから、複数のユーザとの間でモンスターカードの取引を容易に行うことができる。

情報提供手段５５は、商品情報取得処理を実行する機能を備える。
［商品情報取得処理］
商品情報取得処理は、ユーザが、他のユーザがゲーム内で販売しているモンスターカードに関する情報を取得するための処理である。
商品情報取得処理におけるゲームの流れを、図１４及び図１５を参照して説明する。図１４及び図１５では、モンスターカードに関する情報を要求するユーザ（要求ユーザ）がユーザ：ＸＹＺであり、ユーザ：ＫＮＭ（第１のユーザ）によって販売されているモンスターカードに関する情報を要求する場合を一例として示している。なお、図１４のステップＳ１０は、上述した移動処理においてユーザ：ＸＹＺの通信端末１０に表示される一連のウェブページを例示する図である。ここでは、ユーザ：ＸＹＺが、ユーザ：ＫＮＭのゲーム内のウェブページに移動（アクセス）していることを前提として説明する。

先ず、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、図１５のステップＳ１１に示すウェブページがユーザ：ＸＹＺの通信端末１０上に表示される。ステップＳ１１に示すウェブページには、ユーザ：ＫＮＭが販売設定したモンスターカードに関する情報（図の例では、モンスターキャラクタ名、モンスターキャラクタの画像、攻撃力、防御力、レア度、属性）が含まれている。また、ステップＳ１１に示すウェブページには、ユーザ：ＫＮＭと販売提携した提携ユーザであるユーザ：ＡＢＣ（第２のユーザ）が販売設定したモンスターカードに関する情報も含まれている。ここで、ステップＳ１１に例示したウェブページには、ユーザ：ＡＢＣが販売設定したモンスターキャラクタに関する情報を表示する領域に、ユーザ：ＡＢＣによって販売されているモンスターカードであることを示すテキストなどの情報（図の例では「提供者：ＡＢＣさん」というテキスト）を表示するための表示領域１０２が設けられてもよい。さらにまた、ステップＳ１１に例示したウェブページでは、モンスターカードの販売価格（取引の条件）と、販売者からのコメントと、モンスターカードを購入するための「購入する」と表記されたメニューｍ２４とがモンスターカードに関連付けられて表示されてもよい。
この場合、ユーザ：ＸＹＺは、ユーザ：ＫＮＭが販売設定したモンスターカードに関する情報を要求した場合に、ユーザ：ＫＮＭ及びユーザ：ＡＢＣそれぞれの販売するモンスターカードに関する情報を得ることができる。これにより、ユーザ：ＸＹＺにとっては、１回の情報要求を行うことで、ユーザ：ＫＮＭの販売するモンスターカードに関する情報だけではなく、ユーザ：ＡＢＣの販売するモンスターカードに関する情報も得ることができる。

商品情報取得処理における情報提供手段５５の機能は、以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１が選択操作されると、ゲームデータベース３２内のユーザ：ＫＮＭのユーザＩＤに対応する販売設定データに記録されているデータを抽出する。また、ＣＰＵ２１は、ユーザ：ＫＮＭの提携ユーザのユーザＩＤに対応する販売設定データに記録されているデータを抽出する。そして、ＣＰＵ２１は、抽出したデータを含むようにして図１５のステップＳ１１に示すウェブページを表示するためのＨＴＭＬデータを生成し、ユーザ：ＸＹＺの通信端末１０宛に送信する。

また、ＣＰＵ２１は、ステップＳ１１のウェブページ上でメニューｍ２４が選択操作された場合には、モンスターカードの取引処理を行ってもよい。取引処理の一例について具体的に説明すると、ＣＰＵ２１は、ユーザ：ＸＹＺがメニューｍ２４を選択操作したことを認識すると、ユーザ：ＸＹＺのユーザＩＤに対応する所持コインから、選択操作されたメニューｍ２４に対応する販売価格分のコインを減算するとともに、選択操作されたメニューｍ２４に対応するモンスターカードのデータを、ユーザ：ＸＹＺのユーザＩＤに対応する保有カードのデータに記録する。また、ＣＰＵ２１は、ユーザ：ＫＮＭのユーザＩＤに対応する所持コインに、選択操作されたメニューｍ２４に対応する販売価格分のコインを加算するとともに、ユーザ：ＫＮＭのユーザＩＤに対応する保有カードのデータ及び販売設定データから、選択操作されたメニューｍ２４に対応するモンスターカードのデータを消去する。
なお、ＣＰＵ２１は、メニューｍ２４を選択操作したユーザのユーザＩＤに対応する所持コインの額が販売価格に満たない場合には、取引処理を行わなくてもよい。

（６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１６のフローチャートを参照して説明する。図１６のフローチャートは、ゲーム進行手段５２及び設定手段５３が販売設定処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すフローチャートである。

先ず、図９のトップページ上でメニューｍ２が選択操作されると（ステップＳ１００：ＹＥＳ）、ゲームサーバ２０のＣＰＵ２１は、選択操作を行ったユーザのユーザＩＤに対応するユーザデータを参照して、当該ユーザの保有カードのデータを抽出する。そして、ＣＰＵ２１は、図１１に示すウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。この場合、選択操作を行ったユーザの通信端末１０には、図１１に示すウェブページが表示される（ステップＳ１１０）。ここで、ユーザが、販売の対象となるモンスターカードの販売価格及びユーザのコメントをそれぞれテキストボックス１００，１０１に入力した後に、当該モンスターカードに対応するメニューｍ１１を選択すると（ステップＳ１２０：ＹＥＳ）、ＣＰＵ２１は、選択操作されたメニューｍ１１に対応するモンスターカードの販売設定処理を行う（ステップＳ１３０）。販売設定処理について具体的に説明すると、ＣＰＵ２１は、選択操作されたメニューｍ１１に対応するモンスターカードのデータ（画像、攻撃力、防御力、レア度、属性など）と、選択操作されたメニューｍ１１と同じ領域に含まれるテキストボックス１００，１０１に入力されたテキスト情報とを、ゲームデータベース３２内の販売設定データに記録する。

次に、本実施形態のゲーム制御装置により行われる主要な処理のシーケンスの一例について、図１７のシーケンスチャートを参照して説明する。図１７は、ゲーム進行手段５２及び関係付け手段５４が、移動処理及び販売提携処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すシーケンスチャートである。ここでは、移動処理及び販売提携処理を実行するユーザがユーザ：ＫＮＭ、ユーザ：ＫＮＭの提携先となるユーザがユーザ：ＡＢＣである場合を一例として説明する。

先ず、ユーザ：ＫＮＭの通信端末１０のトップページ上でメニューｍ３（図９参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、移動先のユーザの複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに抽出する。そして、ＣＰＵ２１は、複数の候補を抽出すると、図１３のステップＳ１に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０宛に送信する。
次に、ユーザ：ＫＮＭの通信端末１０のＣＰＵ１１は、図１３のステップＳ１に示すウェブページにおいて複数の候補のリストからいずれかの候補（ここでは、ユーザ：ＡＢＣ）を選択する操作がユーザ：ＫＮＭによってなされると、ユーザ：ＫＮＭのゲーム内のウェブページを表示するためのＨＴＭＬデータの要求メッセージを、無線通信インタフェース部１７を介してゲームサーバ２０に送信する（ステップＳ２００）。一方、ゲームサーバ２０のＣＰＵ２１は、要求メッセージを受信すると、図１３のステップＳ２に示すウェブページを表示するためのＨＴＭＬデータをユーザ：ＫＮＭの通信端末１０宛に送信する（ステップＳ２１０）。

次に、図１３のステップＳ２に示すウェブページにおいて、ユーザ：ＫＮＭが、メニューｍ２０を選択すると、ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＫＮＭの通信端末１０から、ユーザ：ＡＢＣのユーザＩＤ（あるいは、対応するユーザ名）を指定した提携申請メッセージを受け付ける（ステップＳ２２０）。ＣＰＵ２１は、提携申請メッセージを受け付けると、提携申請メッセージに含まれるユーザＩＤ（ユーザ：ＡＢＣのユーザＩＤ）に基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤ（ユーザ：ＫＮＭのユーザＩＤ）に基づく提携申請を受ける（承認する）か否かを返信することを要求するためのウェブページ（図１３のステップＳ３に示すウェブページ）を表示させるＨＴＭＬデータを送信する（ステップＳ２３０）。

ユーザ：ＡＢＣが、図１３のステップＳ３に示すウェブページにおいて、メニューｍ２２を選択操作すると、ユーザ：ＡＢＣの通信端末１０のＣＰＵ１１は、提携申請を承認する承認メッセージをゲームサーバ２０に送信する（ステップＳ２４０）。ゲームサーバ２０のＣＰＵ２１は、承認メッセージを受信すると、ユーザ：ＫＮＭとユーザ：ＡＢＣの両者を提携ユーザとして登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「提携ユーザ」の箇所（図６参照）にデータを書き込む（ステップＳ２５０）。
そして、ＣＰＵ２１は、図１３のステップＳ４に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＫＮＭの通信端末１０宛に送信する（ステップＳ２６０）。また、ＣＰＵ２１は、図１３のステップＳ５に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ２７０）。

次に、本実施形態のゲーム制御装置により行われる主要な処理のシーケンスの一例について、図１８のシーケンスチャートを参照して説明する。図１８は、情報提供手段５５が商品情報取得処理を実行する機能を実現するために、主としてゲームサーバ２０のＣＰＵ２１によって実行される一連の処理を示すシーケンスチャートである。ここでは、モンスターカードに関する情報を要求するユーザ（要求ユーザ）がユーザ：ＸＹＺであり、ユーザ：ＫＮＭ（第１のユーザ）によって販売されているモンスターカードに関する情報を要求する場合を一例として説明する。また、ここでは、ユーザ：ＸＹＺが、ユーザ：ＫＮＭのゲーム内のウェブページに移動（アクセス）していることを前提として説明する。

先ず、ユーザ：ＡＢＣの通信端末１０のＣＰＵ１１は、図１４のステップＳ１０に示すウェブページにおいてメニューｍ２１が選択操作されると、ユーザ：ＫＮＭの販売するモンスターカードに関する情報を要求するための要求メッセージを、無線通信インタフェース部１７を介してゲームサーバ２０に送信する（ステップＳ３００）。一方、ゲームサーバ２０のＣＰＵ２１は、要求メッセージを受信すると、ゲームデータベース３２内のユーザ：ＫＮＭのユーザＩＤに対応する販売設定データに記録されているデータを抽出する。また、ＣＰＵ２１は、ユーザ：ＫＮＭの提携ユーザのユーザＩＤに対応する販売設定データに記録されているデータを抽出する（ステップＳ３１０）。そして、ＣＰＵ２１は、抽出したデータを含むようにして図１５のステップＳ１１に示すウェブページを表示するためのＨＴＭＬデータを生成し、ユーザ：ＸＹＺの通信端末１０宛に送信する（ステップＳ３２０）。

上述したように、実施形態のゲーム制御装置によれば、ユーザ：ＸＹＺ（要求ユーザ）がユーザ：ＫＮＭ（第１のユーザ）の販売するモンスターカード（対象オブジェクト）に関する情報を要求した場合には、ユーザ：ＸＹＺに対して、ユーザ：ＫＮＭ及びユーザ：ＫＮＭの提携ユーザであるユーザ：ＡＢＣ（第２のユーザ）それぞれの販売するモンスターカードに関する情報が提供される。これにより、ユーザ：ＸＹＺにとっては、１回の情報要求を行うことで、ユーザ：ＫＮＭの販売するモンスターカードに関する情報だけではなく、ユーザ：ＡＢＣの販売するモンスターカードに関する情報も得ることができる。このため、複数のユーザに対して取引の申請を行う場合に、例えば、複数のユーザ毎に設けられたウェブページに一つずつアクセスするなどの煩雑かつ手間のかかる操作が不要となることから、複数のユーザとの間でオブジェクトの取引を容易に行うことができ、ひいては取引の活性化を図ることができる。

（７）変形例
（７−１）変形例１
上記実施形態において、情報提供手段５５は、ユーザ（第１のユーザ）及び当該ユーザの提携ユーザ（第２のユーザ）の取引の対象となるモンスターカード（対象オブジェクト）が同一の場合に、ユーザ及び提携ユーザそれぞれのモンスターカードの取引の条件に関する情報を、モンスターカードに関する情報に関連付けてもよい。
この場合、要求ユーザは、ユーザ及び提携ユーザの取引対象のモンスターカードが同一の場合に、当該モンスターカードに対するユーザ及び提携ユーザそれぞれの取引の条件に関する情報をまとめて取得することができる。このため、要求ユーザは、ユーザ及び提携ユーザのうち何れのユーザと取引を行うべきか容易に判別することが可能となる。これにより、複数のユーザとの間でモンスターカードの取引をさらに容易に行うことができる。

本変形例における情報提供手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、ユーザ：ＫＮＭ及びユーザ：ＡＢＣの販売設定データを参照し、同一のモンスターカードが販売設定されているか否か判別する。そして、ＣＰＵ２１は、同一のモンスターカードが販売設定されていると判別すると、当該モンスターカードの表示領域にユーザ：ＫＮＭ及びユーザ：ＡＢＣそれぞれの販売価格が含まれるウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する。ユーザ：ＸＹＺの通信端末１０上に表示されるウェブページの一例を図１９に示す。図１９に示すウェブページでは、一つのモンスターカード（図の例では、モンスターキャラクタＭＣ３２１に対応するモンスターカード）の表示領域に、ユーザ：ＫＮＭ及びユーザ：ＡＢＣそれぞれの販売価格が含まれている。また、「購入する」と表記されたメニューが、それぞれの販売価格ごとに対応付けられるように設けられてもよい。

（７−２）変形例２
上記実施形態において、情報提供手段５５は、ユーザ（第１のユーザ）及び当該ユーザの提携ユーザ（第２のユーザ）の取引の対象となるモンスターカード（対象オブジェクト）が同一の場合に、ユーザ及び提携ユーザの取引の条件のうち、緩和された条件に関する情報を提供してもよい。
ここで、「緩和された条件」とは、要求ユーザにとって取引を実現できる可能性がより高い条件であってよく、例えば、ゲーム上の仮想通貨（コイン）を用いて取引が行われる場合にはモンスターカードの販売価格がより低く設定された条件であってもよい。また、ユーザ間でモンスターカードやアイテムを交換することによって取引が行われる場合には、交換可能なモンスターカードやアイテムの数が少なく設定された条件であってもよいし、交換可能なモンスターカードやアイテムの希少価値（レア度）が低く設定された条件などであってもよい。
このゲーム制御装置によれば、ユーザ及び提携ユーザの取引対象のモンスターカードが同一の場合に、ユーザ及び提携ユーザの取引の条件のうち、要求ユーザにとって取引を実現できる可能性の高い条件が要求ユーザに提供される。このため、要求ユーザは、ユーザ及び提携ユーザのうち何れのユーザと取引を行うべきか検討する手間を軽減することができるので、複数のユーザとの間でモンスターカードの取引をさらに容易に行うことができる。

本変形例における情報提供手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、ユーザ：ＫＮＭ及びユーザ：ＡＢＣの販売設定データを参照し、同一のモンスターカードが販売設定されているか否か判別する。そして、ＣＰＵ２１は、同一のモンスターカードが販売設定されていると判別すると、当該モンスターカードの表示領域にユーザ：ＫＮＭ及びユーザ：ＡＢＣそれぞれの販売価格のうち低い販売価格が含まれるウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する。
また、ユーザ間でモンスターカードやアイテムを交換することによって取引が行われる場合の一例について説明する。例えば、一つのモンスターカードについて、ユーザ：ＫＮＭの取引条件が「レア度が１のモンスターカード３０枚と交換すること」、ユーザ：ＡＢＣの取引条件が「レア度が２のモンスターカード２０枚と交換すること」であって、ユーザ：ＸＹＺは、レア度が１のモンスターカードを１０枚、レア度が２のモンスターカードを１９枚保有していた場合には、ユーザ：ＡＢＣの取引条件がユーザ：ＸＹＺに提供されるようにしてもよい。

（７−３）変形例３
上記実施形態において、情報提供手段５５は、ユーザ（第１のユーザ）及び当該ユーザの提携ユーザ（第２のユーザ）の取引の対象となるモンスターカード（対象オブジェクト）のうち、要求元ユーザの取引対象のモンスターカードと異なるモンスターカード（オブジェクト）に関する情報を提供してもよい。
この場合、要求ユーザが取引対象のモンスターカードを設定している場合には、ユーザ及び提携ユーザの取引対象のモンスターカードのうち、要求ユーザのモンスターカード以外のモンスターカードに関する情報が要求ユーザに提供される。要求ユーザが既に保有し、かつ取引の対象として設定するモンスターカードは、要求ユーザにとって、他のユーザから取得することに興味が低いと考えられるため、上述した構成とすることで、要求ユーザは、自身にとって必要なモンスターカードに関する情報を効率よく取得することができる。

本変形例における情報提供手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、ユーザ：ＸＹＺ、ユーザ：ＫＮＭ及びユーザ：ＡＢＣの販売設定データを参照する。そして、ＣＰＵ２１は、ユーザ：ＫＮＭ及びユーザ：ＡＢＣの販売設定データに記録されたモンスターカードのうち、ユーザ：ＸＹＺの販売設定データに記録されたモンスターカードを除くモンスターカードに関する情報を含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する。

（７−４）変形例４
上記実施形態において、ユーザ同士を関係付ける登録手段５１（第２の関係付け手段）を備え、情報提供手段５５は、ユーザ（第１のユーザ）の取引対象となるモンスターカード（対象オブジェクト）と同一のモンスターカードを取引対象として保有する提携ユーザ（第２のユーザ）が複数存在する場合に、提携ユーザのうち登録手段５１によってユーザと関係付けられた仲間ユーザ（第３のユーザ）の取引対象のモンスターカードに関する情報を提供してもよい。
例えば、ユーザ及び複数の提携ユーザの取引対象のモンスターカードが同一の場合に、複数の提携ユーザのうち、ユーザと関係度の高い仲間ユーザのモンスターカードに関する情報が要求ユーザに提供される。これにより、各ユーザは、自らの取引の機会を増やすために、他のユーザと関係付ける（仲間になる）ことが動機付けられる。このため、ユーザ間の交流を促進することができることから、ゲームのソーシャル性を高めることができる。

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

本変形例における情報提供手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、ユーザ：ＫＮＭのユーザデータに記録された提携ユーザの販売設定データを参照し、同一のモンスターカードが販売設定されているか否か判別する。そして、ＣＰＵ２１は、同一のモンスターカードが販売設定されていると判別すると、ユーザ：ＫＮＭのユーザデータを参照して、提携ユーザが仲間ユーザとして記録されているか否かを判別する。そして、ＣＰＵ２１は、提携ユーザが仲間ユーザとして記録されている場合に、当該提携ユーザの取引対象のモンスターデータに関する情報を含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する。

（７−５）変形例５
上記変形例４において、情報提供手段５５は、ユーザ（第１のユーザ）の取引対象のモンスターカード（対象オブジェクト）と同一のモンスターカードを保有する提携ユーザ（第２のユーザ）が複数存在する場合に、ユーザと仲間ユーザ（第３のユーザ）とのゲーム上の関係度合いを示すパラメータに基づいて、仲間ユーザのモンスターカードに関する情報を提供してもよい。
例えば、ユーザと仲間ユーザの関係度を示す親密度が所定の閾値以上であれば、仲間ユーザのモンスターカードに関する情報が要求ユーザに提供されるように構成されている場合には、仲間ユーザは、自らの取引の機会を増やすために、ユーザとの関係度合いを高めることが動機付けられる。このため、ユーザ間の交流をさらに促進することができることから、ゲームのソーシャル性をさらに高めることができる。
ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図２０に示す。図２０に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図２０では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。

本変形例における情報提供手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、ユーザ：ＫＮＭのユーザデータに記録された提携ユーザの販売設定データを参照し、同一のモンスターカードが販売設定されているか否か判別する。そして、ＣＰＵ２１は、同一のモンスターカードが販売設定されていると判別すると、ユーザ：ＫＮＭのユーザデータを参照して、提携ユーザが仲間ユーザとして記録されているか否かを判別する。そして、ＣＰＵ２１は、提携ユーザが仲間ユーザとして記録されている場合に、親密度データを参照して、ユーザ：ＫＮＭと当該提携ユーザの親密度が所定の閾値（例えば５）以上であるか否かを判別する。そして、ＣＰＵ２１は、親密度が閾値以上であれば、提携ユーザの取引対象のモンスターデータに関する情報を含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する。

（７−６）変形例６
上記実施形態において、情報提供手段５５は、関係付け手段５４（第１の関係付け手段）によって提携ユーザ（第２のユーザ）と関係付けられ、且つ、ユーザ（第１のユーザ）と異なる他のユーザの取引対象のモンスターカード（対象オブジェクト）に関する情報を提供してもよい。
本変形例によれば、要求ユーザがユーザのモンスターカードに関する情報を要求した場合には、要求ユーザに対して、ユーザ及び提携ユーザそれぞれのモンスターカードに関する情報だけでなく、提携ユーザと関係付けられた他のユーザのモンスターカードに関する情報も提供される。これにより、要求ユーザにとっては、１回の情報要求を行うことで、多くのユーザのモンスターカードに関する情報を得ることが可能となる。

本変形例における情報提供手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザ：ＸＹＺが、図１４のステップＳ１０に示すウェブページ上でメニューｍ２１を選択すると、ユーザ：ＫＮＭのユーザデータに記録された提携ユーザ（ユーザ：ＡＢＣ）の販売設定データに記録されたモンスターカードのデータを抽出する。また、ＣＰＵ２１は、ユーザ：ＡＢＣのユーザデータに記録された提携ユーザ（ここでは、「ＤＥＦ」というユーザとする。）の販売設定データに記録されたモンスターカードのデータを抽出する。そして、ＣＰＵ２１は、抽出したモンスターカードのデータを含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＸＹＺの通信端末１０宛に送信する。ユーザ：ＸＹＺの通信端末１０上に表示されるウェブページの一例を図２１に示す。図２１に示すウェブページでは、ユーザ：ＡＢＣの提携ユーザである「ＤＥＦ」のモンスターカードに関する情報が含まれている。

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

例えば、上述した実施形態では、適用されるゲームがモンスターカードを用いたデジタルカードゲームである場合を想定したが、ユーザがオブジェクトを保有可能に構成されているゲームであれば、ゲームの種別は如何なるものでもよい。例えば、野球やサッカーなどの対戦形式のデジタルカードゲームにおいて、選手キャラクタやアイテムなどをユーザ間で取引することができるようにしてもよい。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。

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

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…無線通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム進行手段
５３…設定手段
５４…関係付け手段
５５…情報提供手段

Claims (11)

1. ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定する設定手段と、
   ユーザ同士を関係付ける第１の関係付け手段と、
   第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供する情報提供手段と、
   を備えた、ゲーム制御装置。
2. 前記対象オブジェクトに関する情報には、前記対象オブジェクトの取引の条件に関する情報が関連付けられており、
   前記情報提供手段は、前記対象オブジェクトに関する情報と、当該情報に関連付けられた取引の条件に関する情報とを、前記要求ユーザに提供することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記情報提供手段は、第１のユーザ及び前記第２のユーザの対象オブジェクトが同一の場合に、前記第１のユーザ及び前記第２のユーザそれぞれの前記対象オブジェクトの取引の条件に関する情報を、前記対象オブジェクトに関する情報に関連付けることを特徴とする、
   請求項２に記載されたゲーム制御装置。
4. 前記情報提供手段は、第１のユーザ及び前記第２のユーザの対象オブジェクトが同一の場合に、前記第１のユーザ及び前記第２のユーザの取引の条件のうち、緩和された条件に関する情報を提供することを特徴とする、
   請求項２または３に記載されたゲーム制御装置。
5. 前記情報提供手段は、前記第１のユーザ及び前記第２のユーザの対象オブジェクトのうち、前記要求ユーザの対象オブジェクトと異なるオブジェクトに関する情報を提供することを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. ユーザ同士を関係付ける第２の関係付け手段を備え、
   前記情報提供手段は、第１のユーザの対象オブジェクトと同一の対象オブジェクトを保有する第２のユーザが複数存在する場合に、前記第２のユーザのうち前記第２の関係付け手段によって前記第１のユーザと関係付けられた第３のユーザの対象オブジェクトに関する情報を提供することを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記情報提供手段は、第１のユーザの対象オブジェクトと同一の対象オブジェクトを保有する第２のユーザが複数存在する場合に、前記第１のユーザと前記第３のユーザとの前記ゲーム上の関係度合いを示すパラメータに基づいて、前記第３のユーザの対象オブジェクトに関する情報を提供することを特徴とする、
   請求項６に記載されたゲーム制御装置。
8. 前記情報提供手段は、前記第１の関係付け手段によって前記第２のユーザと関係付けられ、且つ、前記第１のユーザと異なる他のユーザの対象オブジェクトに関する情報を提供することを特徴とする、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. ゲーム制御装置におけるゲーム制御方法であって、
   ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定するステップと、
   ユーザ同士を関係付けるステップと、
   第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供するステップと、
   を備えた、ゲーム制御方法。
10. ゲームの実行を制御するために、コンピュータに、
    ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定し、記憶装置に記憶させる機能、
    ユーザ同士を関係付ける機能、及び
    第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を前記記憶装置から取得して提供する機能、
    を実現させるためのプログラム。
11. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    ユーザがゲーム上保有する一又は複数のオブジェクトを、取引の対象となる対象オブジェクトとして設定する設定手段、
    ユーザ同士を関係付ける第１の関係付け手段、
    第１のユーザの対象オブジェクトに関する情報を要求する要求ユーザに対して、前記第１のユーザ及び前記第１のユーザに関係付けられた第２のユーザそれぞれの対象オブジェクトに関する情報を提供する情報提供手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。

Images