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

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 (6)

1. 複数のオブジェクトと、行列における各オブジェクトの位置と、を示す情報であり、かつ、ユーザに対応付けられた情報である行列情報を用いてゲームの実行を制御するゲーム制御装置であって、
   前記オブジェクトと、前記ユーザとを対応付ける対応付け手段と、
   第１ユーザに対応付けられたオブジェクトのうち、第２ユーザに対してゲーム上の有利な効果を生じさせるオブジェクトである第１オブジェクトに関する情報と、前記効果に関する情報と、を前記第１ユーザに提供する情報提供手段と、
   前記情報提供手段によって前記第１オブジェクトに関する情報および前記効果に関する情報が前記第１ユーザに提供された後の前記第１ユーザの入力に関する情報に基づいて、前記第１オブジェクトに対応付けられるユーザを前記第１ユーザから前記第２ユーザに変更する変更手段と、
   前記第１オブジェクトに対応付けられるユーザを前記第２ユーザに変更した場合に、前記第１オブジェクトが前記第２ユーザに対応付けられたことによって前記第２ユーザに対して生じさせる効果に応じたゲーム上の特典を前記第１ユーザに付与する付与手段と、
   前記第１オブジェクトに対応付けられるユーザを前記第２ユーザに変更した場合に、前記第１オブジェクトに関する情報と、前記第１ユーザに関する情報と、前記第１オブジェクトが前記第２ユーザに対応付けられたことによって前記第２ユーザに対して生じさせる効果に関する情報と、を前記第２ユーザに提示する提示手段と、を備え、
   前記効果は、前記第２ユーザに対応付けられた行列情報に対応する行列において、前記第２ユーザに対応付けられたオブジェクトの位置と、前記第１オブジェクトの位置との組み合わせが複数の所定条件のうちのいずれかの条件を満たすことである、ゲーム制御装置。
2. ユーザに対応付けられたオブジェクトのうち、当該ユーザによって選択されたオブジェクトからなるグループを設定する設定手段を備え、
   前記付与手段は、前記第１オブジェクトに対応付けられるユーザを前記第２ユーザに変更した場合であって、前記第２ユーザに対応付けられた行列情報に対応する行列において、前記第２ユーザのグループを構成するオブジェクトの位置の組み合わせが前記複数の所定条件のうちのいずれかの条件を満たすことになる場合に、前記特典を前記第１ユーザに付与することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記付与手段は、前記第１オブジェクトに対応付けられるユーザを前記第２ユーザに変更した場合に、前記第１オブジェクトが前記第２ユーザに対応付けられることによって、前記第２ユーザに対応付けられた行列情報に対応する行列において、前記第２ユーザに対応付けられたオブジェクトの位置の組み合わせが満たす条件に応じたゲーム上の特典を前記第２ユーザに付与することを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記付与手段は、前記第１オブジェクトに対応付けられるユーザを前記第２ユーザに変更した場合に、前記第２ユーザに対応付けられた行列情報に対応する行列において、前記第１オブジェクトの位置と、前記第２ユーザに対応付けられたオブジェクトの位置との組み合わせが前記複数の所定条件のうちのいずれかの条件を満たす毎に、当該組み合わせが満たす条件に応じたゲーム上の特典を第１ユーザに付与することを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. コンピュータを、請求項１〜４のいずれかに記載されたゲーム制御装置の各手段として機能させるためのプログラム。
6. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
   請求項１〜４のいずれかに記載されたゲーム制御装置の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。

Images