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

Description

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

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

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

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

ところで、ユーザが他のユーザとの協力プレイを行う場合、協力を要請する他のユーザを選択するゲームがある。このようなゲームにおいてユーザが協力を要請する他のユーザを選択するとき、ユーザは、自分と親しいユーザや、他のユーザの攻撃力等のパラメータが高いユーザに協力を要請する傾向にあるため、ユーザ同士の交流範囲が限定されるという問題がある。

本発明は上述した観点に鑑みてなされたもので、ゲーム内におけるユーザ同士の交流を促進することができる、ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
このゲーム制御装置は、
各ユーザのユーザ情報に、複数種類の属性情報のいずれかを対応付ける対応付け手段（５３）、
複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける受付手段（５５）、
前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記イベントに参加していないユーザ、及び／又は、参加済みのいずれかのユーザに提示する提示手段（５４）、
前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、前記イベントに参加済みの少なくともいずれかのユーザに付与する特典付与手段（５６）、の各手段を備える。

本発明において、イベントとは、複数のユーザが直接的または間接的に協働して行うゲーム上のプレイ対象である。例えば、複数のユーザが共通の敵と対戦するバトル等である。
本発明において、特典とは、ゲームにおいてユーザに与える何らかの利益をいう。例えば、イベントにおいてユーザを有利に扱うことであってもよい。例えばイベントが対戦処理である場合にユーザの攻撃力・防御力のパラメータを上昇させてもよい。あるいは、イベントやゲームの進捗に有利な効果を奏するものを特典としてもよい。あるいは、特典としてゲーム上のオブジェクトをユーザに付与してもよい。
本発明において、属性情報とは、ユーザの特徴や性質などを示す情報、あるいは、ユーザの特徴や性質などを分類するための情報である。属性には、例えば、年齢、性別、趣味（ゴルフ等）といった実際のユーザデータに基づく属性や、ゲームにおいて変化するもの（例えば、役職、職位等）を含んでもよい。

このゲーム制御装置によれば、イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、イベントに参加済みの少なくともいずれかのユーザに付与するため、異なる属性情報が対応付けられたユーザがイベントに参加する誘因を与えることができ、ユーザの交流範囲を異なる属性情報が対応付けられたユーザ同士まで拡大することができる。

上記ゲーム装置は、前記イベントに参加済みのユーザが、前記イベントへの参加を他のユーザへ要請する要請手段（５７）を備えてもよい。
このゲーム装置によれば、イベントに参加済みのユーザが、前記イベントへの参加を他のユーザへ要請することで、ユーザ同士の交流を図ることができる。

上記ゲーム装置において、前記提示手段（５４）は、前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記要請先ユーザに提示してもよい。
このゲーム装置によれば、要請先ユーザが、提示された前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を参照して、イベントへの参加の是非を検討することができる。また、要請先ユーザと同じ属性が対応付けられたユーザがいないイベントを選択して参加することを要請先ユーザに促すことができる。

上記ゲーム装置において、ユーザと他のユーザを関連付ける関連付け手段（５８）を備え、
前記特典付与手段（５６）は、前記イベントに最初に参加した第１のユーザに関連付けられた第２のユーザが前記イベントへ参加した場合、前記イベントに参加済みの少なくともいずれかのユーザに特典を付与してもよい。
このゲーム装置によれば、第１のユーザに関連付けられた第２のユーザが前記イベントへ参加した場合、前記イベントに参加済みの少なくともいずれかのユーザに特典が付与されるため、第１のユーザに関連付けられた第２のユーザの参加を促進することができ、交流を深耕することができる。

あるいは、上記ゲーム装置において、ユーザと他のユーザを関連付ける関連付け手段（５８）を備え、前記特典付与手段（５６）は、前記イベントに最初に参加した第１のユーザに関連付けられた第２のユーザの前記イベントへの参加数が増えるにつれて増加する特典を、前記イベントに参加済みの少なくともいずれかのユーザに付与してもよい。
このゲーム装置によれば、第１のユーザに関連付けられた第２のユーザの前記イベントへの参加数が増えるにつれて増加する特典が、前記イベントに参加済みの少なくともいずれかのユーザに付与されるため、第１のユーザに関連付けられた第２のユーザの参加をさらに促進することができ、交流をさらに深耕することができる。

上記ゲーム装置において、前記特典付与手段（５６）は、同じ属性情報が対応付けられたユーザのうち最も早く前記イベントに参加したユーザに特典を付与してもよい。
このゲーム装置によれば、同じ属性情報が対応付けられたユーザのうち最も早く前記イベントに参加したユーザに特典を付与することで、イベントに参加済みのユーザに対応付けられた属性情報と異なる属性が対応付けられたユーザの、より早い参加を促進することができる。

上記ゲーム装置において、前記特典付与手段（５６）は、同じ属性情報が対応付けられた複数のユーザが前記イベントに参加した場合、早く参加したユーザに対してより多くの特典を付与してもよい。
このゲーム装置によれば、同じ属性情報が対応付けられた複数のユーザのうち、早く参加したユーザに対してより多くの特典を付与するため、参加済みのユーザに対応付けられた人数が少ない属性情報が対応付けられたユーザの、より早い参加を促進することができる。

本発明の第２の観点は、ゲーム制御装置である。
このゲーム制御装置は、
各ユーザのユーザ情報に、複数種類の属性情報のいずれかを対応付ける対応付け手段（５３）、
ユーザと他のユーザを関連付ける関連付け手段（５８）、
複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける受付手段（５５）、
前記イベントに最初に参加した第１のユーザが、前記イベントへの参加を他のユーザへ要請する要請手段（５７）、
前記イベントへの参加を要請された要請先ユーザが前記イベントへの参加を申請する申請手段（５５）、
前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を前記第１のユーザ、及び／又は、要請先ユーザに提示する提示手段（５４）、
前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典、および、前記第１のユーザに関連付けられた第２のユーザの前記イベントへの参加数が増えるにつれて増加する特典を、前記第１のユーザに付与するとともに、前記イベントに参加済みの前記第２のユーザに特典を付与し、同じ属性情報が対応付けられたユーザのうち最も早く前記イベントに参加したユーザに特典を付与する特典付与手段（５６）、
の各手段を備える。

本発明の第３の観点は、ゲーム制御方法である。
このゲーム制御方法は、
各ユーザのユーザ情報に、複数種類の属性情報のいずれかを対応付けるステップ、
複数のユーザが参加可能なイベントに対するユーザの参加を受け付けるステップ、
前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記イベントに参加していないユーザ、及び／又は、参加済みのいずれかのユーザに提示するステップ、
前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、前記イベントに参加済みの少なくともいずれかのユーザに付与するステップ、
を含む。

本発明の第４の観点は、コンピュータに、
各ユーザのユーザ情報に、複数種類の属性情報のいずれかを対応付ける機能、
複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける機能、
前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記イベントに参加していないユーザ、及び／又は、参加済みのいずれかのユーザに提示する機能、
前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、前記イベントに参加済みの少なくともいずれかのユーザに付与する機能、
を実現するためのプログラムである。

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

本発明の第５の観点は、複数のユーザの通信端末（１０）と、当該通信端末（１０）からアクセスされるサーバ（２０）とを含む、ゲームシステムである。
このゲームシステムは、
各ユーザのユーザ情報に、複数種類の属性情報のいずれかを対応付ける対応付け手段（５３）、
複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける受付手段（５５）、
前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記イベントに参加していないユーザ、及び／又は、参加済みのいずれかのユーザに提示する提示手段（５４）、
前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、前記イベントに参加済みの少なくともいずれかのユーザに付与する特典付与手段（５６）、
の各手段を、前記通信端末（１０）または前記サーバ（２０）のいずれか一方が備える。

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

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、ゲーム内におけるユーザ同士の交流を促進することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施形態のゲームのタイプは特に限定されるものではないが、以下では、実施形態のゲームの一例として、モンスターカード（以下適宜、単に「カード」という。）を用いたデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。このゲームは、ユーザが、モンスターが描かれたデジタルカード（モンスターカード）を入手することによって自らのチーム（カードデッキ）を作り上げ、コンピュータ又は他のユーザのチームとバトルを行うように構成されている。なお、カードデッキは、一般的に複数のカードによって構成されている。
このゲームは、例えば、以下の処理を含む。
・クエスト処理：
少なくとも一枚のモンスターカードからなる自らのチームを作り上げていくために、ゲーム上で設定されているエリアを探索してモンスターカードを得る処理である。このゲームでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費する。
・対戦処理：
ユーザのチームと、コンピュータ又は他のユーザのチームとの間で対戦を行う処理である。ここで、コンピュータのチームとは、例えばＣＰＵ２１によって任意に抽出された複数のモンスターカードからなるチームである。対戦処理では、ユーザの入力に基づき、ユーザのチームとコンピュータのチームとの間での対戦（以下、ＣＯＭ対戦という。）、あるいはユーザのチームと他のユーザのチームとの間での対戦（以下、ユーザ間対戦という。）のいずれかが発生するようになっている。
・イベント処理：
複数のユーザのチームと、コンピュータが選択したモンスターとの間で対戦を行う処理である。ここで、イベント処理におけるコンピュータが選択するモンスターは、通常の対戦処理に用いられるモンスターカードよりも攻撃力・防御力を高くしても良い。この様にすると、イベントを発見したユーザは、単独で勝利できない場合が多く、他のユーザにイベントへの参加を要請することを動機づけられる。

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

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・ユーザの属性（属性情報）
ユーザの特徴や性質などを示す情報、あるいは、ユーザの特徴や性質などを分類するための情報である。例えば、年齢（２０代〜３０代）、性別（男、女）、趣味（ゴルフ等）といった実際のユーザデータに基づく属性であってもよい。また、ゲーム上の属性をユーザが任意に設定してもよい。
なお、ユーザが保有するオブジェクトの属性（後述）に基づいてユーザの属性を定めてもよい。
・進行レベル
ゲーム上のユーザの進行レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、クエスト処理が継続的に実行されることで、順次進行レベルが上がるように構成される。
・体力ポイント
体力ポイントは、ユーザがクエスト処理を行う際に消費するコストを示す変数である。ユーザ毎に体力ポイントの上限値を定めてもよく、体力ポイントの上限値は、進行レベルが増加するにつれて増加するように設定されていてもよい。体力ポイントは、時間の経過によって上限値まで増加（回復）するように設定してもよい。
・勝利ポイント
ユーザが、対戦処理においてコンピュータ又は他のユーザのチームとの対戦に勝利することにより取得したポイントである。このゲームでは、ユーザの勝利ポイントの合計が予め設定された所定値に達するごとに、当該ユーザに対してゲーム上の特典が付与されるようになっている。
・仲間のユーザＩＤ
例えば仲間になるための申請などを契機として、ユーザと関連付けられた他のユーザ（仲間）のユーザＩＤのリストである。
・保有オブジェクトの識別コード
ユーザがゲーム上保有するモンスターカードやアイテム（回復薬等）のオブジェクトの識別コードである。識別コードに対応するモンスターカード等のデータの内容については後述する。

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

モンスターデータベースは、本実施形態のゲームで用意される全てのモンスターカード（オブジェクト）の情報が記述されているデータベースである。
なお、モンスターデータベースは、ユーザに付与されることがない、モンスターの情報が記述されていてもよい。例えば、後述するイベントに出現する強敵のモンスターの情報が含まれていてもよい。
図７は、モンスターデータベースのデータ構成の一例を示す図である。図７に例示するモンスターデータベースは、モンスターカード、又は、後述するイベントに出現するモンスターの識別コード（図の例では、ＭＣ００１，ＭＣ００２，…）ごとに、対象となるモンスターの画像データ（画像）、対象となるモンスターの名前（モンスター名）及び対象となるモンスターのパラメータ（図の例では、モンスターの能力を示す攻撃力・防御力の値及びレア度）の各項目のデータを含む。例えば、攻撃力や防御力などのパラメータが大きいほど、モンスターカードに対応するモンスターの対戦処理やイベント処理における能力が高いことを示すように設定されてもよい。
また、レア度は、モンスターカードの希少価値の度合を示す値であり、例えば、その値が高い（つまり、希少価値が高い）ほど、ゲーム内で出現する確率が低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、能力の際立ったモンスターや人気のあるモンスターカードに対応するモンスターカードのレア度が高く（例えば、４あるいは５など）設定されてもよい。
なお、オブジェクトの特徴や性質などを示す情報や、オブジェクトの特徴や性質などを分類するための情報である属性情報をオブジェクト毎に対応付けてもよい。また、イベントに出現するモンスター毎に対戦処理やイベント処理に用いられるＨＰに関する情報を対応付けてもよい。

イベントデータベースは、本実施形態のゲームで実行されるイベントの情報が記述されているデータベースである。
図８は、イベントデータベースのデータ構成の一例を示す図である。図８に例示するイベントデータベースは、イベントＩＤ（図の例では、ＥＶ００１，ＥＶ００２，…）ごとに、イベントの発見者であるユーザ及び発見者以外のイベントへの参加者であるユーザ（参加済みユーザ）のユーザＩＤ、救援要請がされたユーザ（要請先ユーザ）のユーザＩＤを含む。なお、イベントデータベースは、イベントに関する他のパラメータを含んでもよい。例えば、イベントにモンスターが出現する場合、モンスターの識別コードを含んでもよい。また、イベントに出現するモンスターのＨＰがイベントの進行に伴って変化するような場合、ＨＰを含んでもよい。例えば、また、イベントに出現するモンスターのＨＰがイベントの進行に伴って減少する場合、「ＨＰ残量」を含んでもよい。

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

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

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

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

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

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

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

〔イベント処理〕
次に、イベントにおける救援要請処理の一例を説明する。図９のウェブページＰ２において、メニューｍ１０が選択操作された後、所定の、あるいはランダムな確率で、図１１のＰ５に例示するウェブページがユーザ：Ａの通信端末１０上に表示される（ユーザ：Ａによるイベントの発見）。ウェブページＰ５には、ユーザ：Ａが戦うべき敵に関する情報（モンスター：ＡＢＣの画像、ＨＰ：１２０００、攻撃力：６０００、防御力：４０００等）とともに、攻撃の実行を指示するための「対戦開始」と表記されたメニューｍ１１などが含まれる。
ユーザ：Ａがメニューｍ１１を選択操作すると、モンスター：ＡＢＣとの対戦処理が行われ、対戦の結果を通知するウェブページ（Ｐ４またはＰ６に例示するウェブページ）がユーザ：Ａの通信端末１０上に表示される。ユーザ：Ａが勝利した場合は、図１０のＰ４と同様のウェブページがユーザ：Ａの通信端末１０上に表示される。
ユーザ：Ａが敗北した場合、図１１のＰ６に例示するようなウェブページがユーザ：Ａの通信端末１０上に表示される。ウェブページＰ６は、ユーザ：Ａが戦った後の敵に関する情報（モンスター：ＡＢＣの画像、対戦の結果を示す情報（ＨＰ：５０００、攻撃力：６０００、防御力：４０００等）を含む。なお、図１１の例では、ユーザ：Ａと対戦した後の敵に関する情報が表示される。すなわち、図１１において、モンスターのＨＰが、ウェブページＰ５の１２０００からウェブページＰ６の５０００に減少している。
また、ウェブページＰ６は、選択操作されることによりユーザ：Ａがイベントへの参加を他のユーザに要請するためのメニューｍ１２（「救援要請」）を含む。ユーザ：Ａがメニューｍ１２の選択操作をすると、所定の確率で、あるいはランダムに選択された、ユーザ：Ａ以外の他のユーザ（第２のユーザ）に対し、救援要請がされる。なお、救援要請をする他のユーザは１人であってもよいし、複数であってもよい。
その後、図１１のＰ７に例示するようなウェブページがユーザ：Ａの通信端末１０上に表示される。ウェブページＰ７は、ユーザ：Ａが救援要請をした他のユーザに関する情報（「Ｂさんに救援要請しました！」）等を含む。

救援要請を受けた他のユーザ：Ｂ（第２のユーザ）が、その後、ゲームにアクセスすると、図１２に示すようなトップページＰ８がユーザ：Ｂの通信端末１０上に表示される。
トップページＰ８は、ユーザ：Ｂから救援要請があったことを示すメニューｍ３（「Ａさんから救援要請があります」）を含む。
トップページＰ８において、ユーザ：Ｂがメニューｍ３を選択操作すると、図１２のＰ９に例示するウェブページがユーザ：Ｂの通信端末１０上に表示される。ウェブページＰ９は、ユーザ：Ｂが参加申請可能なイベントに関する情報のリストを含むようにしてもよい。例えば、ウェブページＰ９は、ユーザ：Ａが発見したイベントに関する情報（モンスター：ＡＢＣの画像、対戦の結果を示す情報（ＨＰ：５０００、攻撃力：６０００、防御力：４０００、発見者（Ａ）及び発見者の属性に関する情報（Ｘ）等）、ユーザ：Ｃが発見したイベントに関する情報（モンスター：ＤＥＦの画像、対戦の結果を示す情報（ＨＰ：４０００、攻撃力：３０００、防御力：２０００、発見者（Ｃ）、参加者（Ｄ）及び発見者、参加者の属性に関する情報（Ｙ、Ｚ）等）を含む。なお、発見者の属性に関する情報はテキストであってもよいし、属性に対応するイラストであってもよい。

また、ウェブページＰ９は、各イベントへユーザ：Ｂが参加申請するためのメニューｍ３１、ｍ３２（「救援する」）を含んでもよい。ウェブページＰ９において、ユーザ：Ｂがメニューｍ３１を選択操作すると、図１２のＰ１０に例示するウェブページがユーザ：Ｂの通信端末１０上に表示される。ウェブページＰ１０には、ユーザ：Ｂが戦うべき敵に関する情報（モンスター：ＡＢＣの画像、ＨＰ：５０００、攻撃力：６０００、防御力：４０００等）とともに、攻撃の実行を指示するための「対戦開始」と表記されたメニューｍ３３等が含まれる。ここで、ユーザ：Ｂが戦うべき敵に関する情報は、ユーザ：Ａが戦った後の敵に関する情報である。すなわち、モンスターのＨＰが、ウェブページＰ５の１２０００からウェブページＰ１０の５０００に減少している。なお、イベント参加済みのユーザの属性情報を表示しても良い。例えば、イベントの発見者及び参加者の属性の割合が分かるように、イベントの発見者及び参加者の属性の割合に応じて、ウェブページＰ１０の表示を変更してもよい。例えば、最も多い属性がＸであれば、ウェブページＰ１０の背景を赤、最も多い属性がＹであれば、ウェブページＰ１０の背景を緑、最も多い属性がＺであれば、ウェブページＰ１０の背景を青、としてもよい。あるいは、属性に対応するアイコンを、属性の数に応じてウェブページＰ１０に含ませてもよい。例えば、属性が「火」、「水」、「木」等であれば、火のイラストを含むアイコン、水のイラストを含むアイコン、木のイラストを含むアイコンを、各属性の参加者の人数に応じてウェブページＰ１０に含ませてもよい。また、属性毎の参加割合や参加人数をウェブページＰ１０に含ませてもよい。
その後、ユーザ：Ｂがメニューｍ３３を操作すると、モンスター：ＡＢＣとの対戦処理が行われ、対戦の結果を通知するウェブページ（Ｐ４またはＰ６に例示するウェブページ）がユーザ：Ｂの通信端末１０上に表示される。なお、救援要請を受けたユーザ：Ｂが敗北した場合にも、ウェブページＰ６と同様にメニューｍ１２（「救援要請」）を表示してもよいし、表示しなくてもよい。

なお、後述するように、ウェブページＰ９に表示されるイベントの発見者（Ａさん、Ｃさん）や参加者（Ｄさん）の人数や属性と、新たに参加するユーザ：Ｂの属性との関係により、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力を変動させた上で勝敗が決定される。

また、イベントに参加済みのユーザは、イベント終了までイベントの処理を複数回実行しても良い。例えば、イベントの発見者であるユーザ：Ａが、モンスター：ＡＢＣのＨＰ残量が０となる前に、再びモンスター：ＡＢＣとの対戦処理を行ってもよい。この場合、後述するように、イベントに参加済みのユーザの属性情報の数に応じて、ユーザ：Ａの攻撃力・防御力を増加させてもよい。

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

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

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

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

クエスト処理において、ＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、複数のカードの中から選択されたカードをユーザに付与すること、または、イベント処理を行うことを、所定の、あるいはランダムな確率で決定する。ここで、ＣＰＵ２１は、カードを付与することを決定した場合、カードを入手したことを通知するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。ＣＰＵ２１は、複数のカードの中から選択されたカードをユーザに付与することを決定した場合には、クエスト用に予め設けられた複数のカードの中から、ユーザに対して付与されるカードを選択する。次に、ＣＰＵ２１は、対象となるユーザＩＤのユーザデータベースに、選択したカードの識別コードを書き込む。また、ＣＰＵ２１は、クエスト処理において、カード以外の所定のオブジェクト（アイテム等）の識別コードを対象となるユーザＩＤのユーザデータベースに書き込んでもよい。

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

また、実行手段５２は、イベント処理を行う機能を有する。この機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、クエスト処理において、ユーザ：Ａによるメニューｍ１０（「クエスト実行」）の選択操作を認識した後、イベント処理を行うことを決定した場合（ユーザ：Ａがイベントを発見した場合）、イベントに出現するモンスターの識別コードを、所定の規則で、あるいはランダムな確率で決定する。次に、ＣＰＵ２１は、ユーザ：Ａが発見したイベントに関する情報（発見者：ＡのユーザＩＤ、決定されたモンスターの識別コード、ＨＰ等）をイベントＩＤ毎に書き込む。
次に、ＣＰＵ２１は、モンスターデータベースから決定した識別コードに対応する情報（モンスターの画像、モンスター名、攻撃力、防御力、レア度等）の一部又は全てを読み出し、図１１のＰ５に例示するようなウェブページのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。以後、ＣＰＵ２１は、対戦処理と同様にして対戦の結果を決定すると、対戦結果をユーザ：Ａに通知するウェブページ（例えば、ウェブページＰ４又はＰ６など）を表示するためのＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。
また、対戦結果が敗北であった場合、ＣＰＵ２１は、イベントデータベースに、対戦結果に基づく情報（モンスターのＨＰ残量等）を書き込む。ウェブページＰ６において、ユーザ：Ａがメニューｍ１２を選択操作すると、ＣＰＵ２１は、イベントへの参加を要請するユーザのユーザＩＤを決定し、イベントデータベースに書き込むとともに、要請先のユーザに関する情報を含むウェブページＰ７のＨＴＭＬデータを生成して、ユーザ：Ａの通信端末１０に送信する。

対応付け手段５３は、各ユーザのユーザ情報に、複数種類の属性情報のいずれかを対応付ける機能を備える。対応付け手段５３の機能は、例えば以下のとおり実現される。
ゲームサーバ２０のＣＰＵ２１は、登録されたユーザの通信端末１０から通信インタフェース部２６を介して属性登録要求メッセージを受信する。属性の登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作等）によって自動的に生成されるように、ウェブページが構成されていてもよい。
ＣＰＵ２１は、属性登録要求メッセージを受信し、属性登録要求メッセージに含まれているユーザＩＤに対応するユーザデータベース３１に、複数種類の属性情報のいずれかを登録する。なお、属性情報の対応付けは、ＣＰＵ２１がユーザＩＤにランダムまたは所定の条件に基づき、属性情報を対応付けてもよいし、ユーザの要望に応じて登録してもよい。また、属性情報の設定タイミングはゲーム登録時に限らず、ゲーム中の規定のタイミングまたは所定の条件が満たされたタイミングでも良い。例えば、ユーザＩＤの登録処理時に属性情報を対応付けてもよいし、ユーザがゲームを実行可能となった後、任意で属性情報を登録可能としてもよい。さらに、属性情報を変更することが出来ても良い。例えば、登録された属性情報をユーザが任意に、あるいはランダムまたは所定の条件を満たした際にＣＰＵ２１により変更可能としてもよい。なお、ユーザが保有するオブジェクトの属性に基づいてＣＰＵ２１が定めた属性をユーザデータベース３１に登録してもよい。

提示手段５４は、前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記イベントに参加していないユーザ、及び／又は、参加済みのいずれかのユーザに提示する機能を有する。提示手段５４の機能は、例えば以下の通り実現される。
ＣＰＵ２１は、ユーザ：Ｂ（第２のユーザ）がゲームにアクセスすると、イベントデータベースを参照し、ユーザ：Ｂに対応するユーザＩＤがいずれかのイベントＩＤの要請先ユーザＩＤの欄に記録されているか否かを判定する。ユーザ：Ｂに対応するユーザＩＤがいずれかのイベントＩＤの要請先ユーザＩＤの欄に記録されている場合、ＣＰＵ２１は、図１２に示すように、メニューｍ３を含むトップページＰ８のＨＴＭＬデータを生成し、ユーザ：Ｂの通信端末１０宛に送信する。トップページＰ８において、ユーザ：Ｂがメニューｍ３を選択操作した場合、ＣＰＵ２１は、イベントデータベースを参照し、ユーザ：ＢのユーザＩＤが要請先ユーザＩＤに記録されたイベントＩＤの欄に記録された情報に基づき、各イベントの発見者及び参加者のユーザＩＤを取得する。次に、ＣＰＵ２１は、発見者及び参加者のユーザＩＤからユーザデータベースを参照して発見者及び参加者の属性情報を取得する。その後、ＣＰＵ２１は、図１２に示すように、ユーザ：Ｂが参加申請可能なイベントの発見者及び参加者の属性情報を含む、イベントに関する情報のリストを含むウェブページＰ９のＨＴＭＬデータを生成し、ユーザ：Ｂの通信端末１０宛に送信する。

受付手段５５は、複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける機能を有する。受付手段５５の機能は、例えば以下のとおり実現される。
ユーザ：Ｂがメニューｍ３を選択操作した場合、ＣＰＵ２１は、イベントデータベースを参照し、ユーザ：ＢのユーザＩＤが要請先ユーザＩＤに記録されたイベントＩＤの欄に記録された情報に基づき、図１２に示すように、ユーザ：Ｂが参加申請可能なイベントに関する情報のリストとともに、ユーザ：Ｂがイベントに参加するためのメニューｍ３１、ｍ３２を含むウェブページＰ９のＨＴＭＬデータを生成し、ユーザ：Ｂの通信端末１０宛に送信する。

ウェブページＰ９において、ユーザ：Ｂによるモンスター：ＡＢＣと対戦するというイベントに対する参加申請としてメニューｍ３１またはメニューｍ３２の選択操作を受け付けると、ＣＰＵ２１は、対応するイベントＩＤに関する情報をイベントデータベースから読み出し、図１２のウェブページＰ１０のＨＴＭＬデータを生成し、ユーザ：Ｂの通信端末１０宛に送信する。また、ＣＰＵ２１は、イベントデータベースの要請先ユーザＩＤの欄からユーザ：ＢのユーザＩＤを削除すると同時に、参加者ユーザＩＤの欄にユーザ：ＢのユーザＩＤを書き込む。以後、上述したのと同様にイベント処理が行われる。

特典付与手段５６は、イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、イベントに参加可能なユーザに付与する。ここで、特典とは、例えばイベント処理においてユーザを有利に扱うことであってもよいし、イベント処理の終了後のクエスト処理においてユーザを有利に扱うことであってもよい。あるいは、オブジェクトを特典としてユーザに付与してもよい。特典付与手段５６の機能は、例えば以下のとおり実現される。

ウェブページＰ１０において、ユーザ：Ｂがメニューｍ３３の選択操作を行うと、ＣＰＵ２１は、イベントデータベースから対応するイベントＩＤにおける発見者及び参加者のユーザＩＤを読み出す。次に、ＣＰＵ２１は、読み出した発見者および参加者のユーザＩＤに基づきユーザデータベースからユーザＩＤに対応する属性情報を読み出す。ＣＰＵ２１は読み出したユーザＩＤに対応する属性情報について、属性情報ごとに人数を集計し、ＲＡＭ２３に書き込む。その後、ＣＰＵ２１は、集計した属性情報の数や、属性情報ごとの人数に応じて、ユーザ：Ｂに特典を付与する。
例えば、ＣＰＵ２１は、イベントに参加済みのユーザ（発見者及びユーザ：Ｂを含む参加者）の属性情報の種類数に応じて、特典として、ユーザ：Ｂの攻撃力・防御力を所定量、又は、所定比率で、増加させてもよい。例えば、ユーザの属性情報の種類数がｎのとき、ユーザ：Ｂの攻撃力・防御力に（１＋０．２×ｎ）を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力としてもよい。
あるいは、特典とはならないが、ユーザの属性情報の種類数が所定の数ｋよりも少ない場合、ユーザ：Ｂの攻撃力・防御力を減少させてもよい。例えば、ユーザの属性情報の種類数がｎのとき、ユーザ：Ｂの攻撃力・防御力に｛１＋０．２×（ｎ−ｋ）｝を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力としてもよい。
あるいは、ユーザ：Ｂの属性情報が、イベントに参加済みのユーザの属性情報のいずれとも異なる場合に、ユーザ：Ｂに特典を付与してもよい。すなわち、ユーザ：Ｂが同じ属性情報が対応付けられた他のユーザよりも早くイベントに参加したときに、ユーザ：Ｂの攻撃力・防御力を所定量、又は所定比率（例えば２０％）、増加させてもよい。
この場合、ユーザ：Ｂと同じ属性情報が対応付けられた他のユーザ：Ｃがユーザ：Ｂの後にイベントに参加したとき、ユーザ：Ｃの攻撃力・防御力を増加させなくてもよい。
あるいは、ユーザ：Ｂと同じ属性情報が対応付けられた他のユーザがイベントに参加済みか否かにより、ユーザ：Ｂの攻撃力・防御力を変動させてもよい。例えば、ユーザ：Ｂの属性と同じ属性情報が対応付けられた参加者が多いほど、ユーザ：Ｂの攻撃力・防御力の増加率が小さくなるように設定してもよい。例えば、ユーザ：Ｂの属性の参加者がユーザ：Ｂでｍ番目（ｍは自然数）であるとき、ユーザ：Ｂの攻撃力・防御力に（１＋０．１／ｍ）を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力としてもよい。

また、イベントに参加済みのユーザは、イベント終了までイベントの処理を複数回実行してもよい。例えば、イベントの発見者であるユーザ：Ａが、モンスター：ＡＢＣのＨＰ残量が０となる前に、再びモンスター：ＡＢＣとの対戦処理を行ってもよい。この場合にも、イベントに参加済みのユーザの属性情報の数に応じて、ユーザ：Ａの攻撃力・防御力を所定量、又は、所定の比率で、増加させてもよい。例えば、ユーザの属性情報の種類数がｎのとき、ユーザ：Ａの攻撃力・防御力に（１＋０．２×ｎ）を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ａのチームの攻撃力・防御力としてもよい。
なお、複数回実行した際に、属性情報の数に応じた特典が付与されるのは発見者のみに限定してもよい。
あるいは、モンスター：ＡＢＣのＨＰ残量が０となった場合に、イベントの発見者であるユーザ：Ａに、イベントに参加済みのユーザの属性情報の数に応じた能力及び／又はレア度を備えたオブジェクトを付与してもよい。例えば、イベントに参加済みのユーザの属性情報の数が多いほど、レア度が高いカードをユーザ：Ａに付与してもよい。

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

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

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

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

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

〔イベント処理〕
次に、図１６を参照してイベント処理を行うときのフローチャートの一例を説明する。
ＣＰＵ２１は、クエスト処理のステップＳ１０２において、イベント処理を行うことを決定した場合、イベントに出現するモンスターの識別コードを、所定の規則で、あるいはランダムな確率で決定する（ステップＳ３００）。次に、ＣＰＵ２１は、ユーザ：Ａが発見したイベントに関する情報（発見者：ＡのユーザＩＤ、決定されたモンスターの識別コード、ＨＰ等）をイベントＩＤ毎に書き込む。
次に、ＣＰＵ２１は、ウェブページＰ５において、ユーザ：Ａがメニューｍ１１の選択操作を行ったか否かを判定する（ステップＳ３０２）。メニューｍ１１以外の選択操作が行われた場合（ステップＳ３０２：ＮＯ）、ＣＰＵ２１は、イベント処理を終了する。
ユーザ：Ａがメニューｍ１１の選択操作を行った場合（ステップＳ３０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａとモンスター：ＡＢＣとの対戦結果を決定する処理を行う（ステップＳ３０４）。
ＣＰＵ２１は、ユーザ：Ａが対戦に勝利した場合（ステップＳ３０６：ＹＥＳ）、ユーザ：Ａに対して勝利ポイントを加算する処理を行う（ステップＳ３０８）。

一方、ＣＰＵ２１は、ユーザ：Ａが対戦に敗北した場合（ステップＳ３０６：ＮＯ）、対戦結果に関する情報（モンスターＡＢＣのＨＰ残量等）をイベントデータベースに書き込む（ステップＳ３１０）。
次に、ＣＰＵ２１は、ウェブページＰ６において、ユーザ：Ａがメニューｍ１２の選択操作を行ったか否かを判定する（ステップＳ３１２）。メニューｍ１２以外の選択操作が行われた場合（ステップＳ３１２：ＮＯ）、ＣＰＵ２１は、イベント処理を終了する。
ユーザ：Ａがメニューｍ１２の選択操作を行った場合（ステップＳ３１２：ＹＥＳ）、ＣＰＵ２１は、救援を要請するユーザ（要請先ユーザ）を決定する（ステップＳ３１４）。例えば、ＣＰＵ２１は、所定の確率で、あるいはランダムに、ユーザ：Ａ以外の他のユーザ（第２のユーザ）のユーザＩＤを選択し、イベントデータベースの要請先ユーザＩＤの欄に書き込む。その後、ＣＰＵ２１は、イベント処理を終了する。

〔受付処理〕
次に、図１７を参照して、ユーザ：Ｂのイベントへの参加を受け付ける受付処理の一例を説明する。
まず、ユーザ：Ｂがゲームにアクセスすると、ＣＰＵ２１は、イベントデータベースを参照し、ユーザ：Ｂにイベントへの参加要請があるか否かを判定する（ステップＳ４００）。例えば、ＣＰＵ２１は、ユーザ：Ｂに対応するユーザＩＤがいずれかのイベントＩＤの要請先ユーザＩＤの欄に記録されているか否かを判定する。ユーザ：Ｂにイベントへの参加要請がない場合（ステップＳ４００：ＮＯ）、ＣＰＵ２１は、受付処理を終了する。
ユーザ：Ｂにイベントへの参加要請がある場合（ステップＳ４００：ＹＥＳ）、ＣＰＵ２１は、メニューｍ３を含むトップページＰ８のＨＴＭＬデータを生成し、ユーザ：Ｂの通信端末１０宛に送信する。次に、ＣＰＵ２１は、トップページＰ８において、ユーザ：Ｂがメニューｍ３の選択操作を行ったか否かを判定する（ステップＳ４０２）。ユーザ：Ｂがメニューｍ３の選択操作を行った場合（ステップＳ４０２：ＹＥＳ）、ＣＰＵ２１は、ウェブページＰ９において、ユーザ：Ｂがメニューｍ３１、ｍ３２の選択操作を行ったか否かを判定する（ステップＳ４０４）。ユーザ：Ｂがメニューｍ３１、ｍ３２以外の選択操作を行った場合（ステップＳ４０４：ＮＯ）、ＣＰＵ２１は、受付処理を終了する。
ユーザ：Ｂがメニューｍ３１、ｍ３２の選択操作を行った場合（ステップＳ４０４：ＹＥＳ）、ＣＰＵ２１は、選択操作されたメニューｍ３１、ｍ３２に応じて対戦モンスターを決定する（ステップＳ４０６）。次に、ＣＰＵ２１は、ユーザ：ＢのユーザＩＤを対応するイベントデータベースの要請先ユーザＩＤから削除し、参加者ユーザＩＤにユーザ：ＢのユーザＩＤを追加する。
次に、ＣＰＵ２１は、ウェブページＰ１０において、ユーザ：Ｂがメニューｍ３３の選択操作を行ったか否かを判定する（ステップＳ４０８）。ユーザ：Ｂがメニューｍ３３以外の選択操作を行った場合（ステップＳ４０８：ＮＯ）、ＣＰＵ２１は、受付処理を終了する。

ユーザ：Ｂがメニューｍ３３の選択操作を行った場合（ステップＳ４０８：ＹＥＳ）、ＣＰＵ２１は、イベントに参加済みのユーザ（発見者及びＢを含む参加者）の属性情報の種類数に応じた特典を、ユーザ：Ｂに付与する（ステップＳ４１０）。ここでは、イベントに参加済みのユーザ（発見者及びユーザ：Ｂを含む参加者）の属性情報の種類数に応じて、上述したように、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力を変動させる。
次に、ＣＰＵ２１は、変動させたユーザ：Ｂのチームの攻撃力・防御力に基づいて、モンスター：ＡＢＣとの対戦の結果を決定する（ステップＳ４１２）。
そして、ＣＰＵ２１は、ユーザ：Ｂが対戦に勝利した場合（ステップＳ４１４：ＹＥＳ）、ユーザ：Ａに対して勝利ポイントを加算する処理を行う（ステップＳ４１６）。一方、ＣＰＵ２１は、ユーザ：Ａが対戦に敗北した場合（ステップＳ４１４：ＮＯ）、ユーザ：Ａに対して勝利ポイントを減算する処理を行う（ステップＳ４１８）。その後、ＣＰＵ２１は、処理を終了する。

以上説明したように、このゲーム装置では、イベントに参加済みのユーザ（発見者及びＢを含む参加者）の属性情報の種類数に応じた特典を、イベントに参加可能なユーザに付与するため、異なる属性情報が対応付けられたユーザのイベントへの参加を促進することができる。

なお、上記実施形態において、イベントに参加済みのユーザ（発見者及びＢを含む参加者）の属性情報の種類数に基づき、所定の演算式（１＋０．２×ｎ）に当てはめて特典を算出し、ユーザに付与する例について説明したが、本発明はこれに限られない。例えば、予め属性情報の種類数と特典を対応付けたテーブルデータを記憶しておき、種類数に対応する特典を当該テーブルに基づいて決定してもよい。また、イベントに参加済みのユーザ（発見者及びＢを含む参加者）の属性情報の種類数が１であればユーザ：Ｂの攻撃力・防御力をそのまま（増加率０％）、種類数が２であればユーザ：Ｂの攻撃力・防御力を１．０５倍（増加率５％）、種類数が３であればユーザ：Ｂの攻撃力・防御力を１．１０倍（増加率１０％）、種類数が４であればユーザ：Ｂの攻撃力・防御力を１．１８倍（増加率１８％）、・・・種類数が８であればユーザ：Ｂの攻撃力・防御力を２倍（増加率１００％）というように、種類数と増加率が比例しなくてもよい。

また、上記実施形態において、クエスト処理の途中でモンスター：ＡＢＣと対戦するイベントについて説明したが、本発明はこれに限られない。例えば、イベントは複数のユーザが直接的または間接的に協働（参加）して行うゲーム上のプレイ対象であり、具体的には、複数のユーザがクエストを実行することで得ることが出来る特定のアイテム数の合計値を競い合うものでも良い。また、イベントの発生タイミングも所定の、または、ランダムな確率で発生するものに限らず、ユーザがゲーム上の所定の条件を満たした場合に発生することとしても良い。例えば、トップページＰ１でメニューｍ２を選択操作した場合に、所定の確率でモンスター：ＡＢＣと対戦するイベントが発生してもよいし、クエストを所定回数行うとモンスター：ＡＢＣと対戦するイベントが発生しても良い。
また、上記実施形態において、特典を対戦処理における参加済みユーザのパラメータ（攻撃力・防御力）の変動として説明したがこれに限られない。例えば、イベントの進捗に有利な効果を奏するものを特典としてもよく、具体的には、複数のユーザが参加可能なクエストをイベントとした場合、イベントに参加済みのユーザの属性情報の数に応じて、探索に要する体力ポイントの値を減らしたり、１回の探索で得られる経験値を増やしたり、複数のユーザが参加可能なバトルをイベントとした場合は、上記実施例のように対戦処理に用いられるパラメータを変動させる他に勝利ポイントを増やしたりする等の特典を付与してもよい。
また、特典はイベントの進捗に有利な効果を奏するものに限らず、ゲームの進捗に有利な効果を奏するものであっても良い。例えば、複数のユーザが参加可能なバトルをイベントした場合に、クエストの進捗に有利な効果を奏するものを特典としても良い。このような場合であっても、クエストの進捗を有利にするために異なる属性情報を持つユーザとのイベント実行が促進されると思われるためである。

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

（８−１）変形例１
本変形例に係るゲーム制御装置の機能ブロック図を、図１８に示す。図１８に示すように、本変形例では、図１３の機能ブロック図と比較して、要請手段５７が追加された点で異なる。要請手段５７は、イベントに参加済みのユーザ：Ａが、前記イベントへの参加を他のユーザ：Ｂへ要請する機能を有する。要請手段５７の機能は、例えば、以下のようにして実現される。

本変形例においては、イベント処理において、図１１のウェブページＰ６において、メニューｍ１２をユーザ：Ａが選択操作した場合、イベントへの参加を要請するユーザを選択するウェブページに遷移する。

図１１のウェブページＰ６において、ユーザ：Ａがメニューｍ１２の選択操作をすると、図１９のＰ１０に例示するようなウェブページがユーザ：Ａの通信端末１０上に表示される。ウェブページＰ１０には、ユーザ：Ａが参加したイベントへ参加可能な他のユーザ（第２のユーザ）に関する情報を含む欄がリスト表示される。ユーザ：Ｂ、Ｃ、Ｄ、Ｅはそれぞれ第２のユーザの一例である。

また、ウェブページＰ１０にリスト表示するユーザ：Ｂ、Ｃ、Ｄ、Ｅの欄には、それぞれユーザ：Ａがイベントへの参加を要請するためのメニューｍ１３、ｍ１４、ｍ１５、ｍ１６（「救援要請する」）、および、ユーザ：Ｂ、Ｃ、Ｄ、Ｅに一括でイベントへの参加を要請するためのメニューｍ１７（「一括要請する」）、いずれのユーザにもイベントへの参加を要請せずに通常のクエスト処理の画面に戻るためのメニューｍ１８（「要請しない」）等が表示される。ウェブページＰ７上でユーザ：Ａがメニューｍ１３の選択操作を行うと、ユーザ：Ｂへ救援要請がされる。すなわち、ユーザ：Ｂに対応するユーザＩＤがイベントデータベースの要請先ユーザＩＤの欄に追記される。同様に、ウェブページＰ１０上でユーザ：Ａがメニューｍ１４、ｍ１５、ｍ１６の選択操作を行うと、それぞれ、ユーザ：Ｃ、Ｄ、Ｅへ救援要請がされる。ウェブページＰ１０上でユーザ：Ａがメニューｍ１７の選択操作を行うと、ウェブページＰ１０に表示された全てのユーザ：Ｂ、Ｃ、Ｄ、Ｅへ救援要請がされる。一方、ウェブページＰ１０上でユーザ：Ａがメニューｍ１８の選択操作を行うと、ウェブページＰ１０に表示されたいずれのユーザに対しても救援要請がされず、通常のクエスト処理の画面（例えば図９のウェブページＰ２）が表示される。なお、複数のユーザを選択して救援要請を可能としてもよい。

このように、本変形例においては、イベントの発見者であるユーザ：Ａが、他のユーザに対応付けられた属性情報を参照して、既に参加済みのユーザに対応付けられた属性情報とは異なる属性情報が対応付けられたユーザを選択して参加を要請することができ、ユーザ：Ａの交流範囲を、ユーザ：Ａとは異なる属性情報が対応付けられたユーザにまで拡大することができる。

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

本変形例においては、特典付与手段５６は、属性情報の種類数に応じた攻撃力・防御力の増加に加えて、イベントの参加者であるユーザ：Ｂが発見者であるユーザ：Ａと関連付けられている（仲間である）か否かにより、ユーザ：Ｂの攻撃力・防御力を変動させる。例えば、参加者であるユーザ：Ｂが発見者であるユーザ：Ａと仲間である場合、ユーザ：Ｂの攻撃力・防御力を、所定量、又は、所定比率（例えば２０％）、増加させてもよい。
あるいは、特典付与手段５６は、イベントに参加済みのユーザ：Ａの仲間の参加人数に応じて、ユーザ：Ｂの攻撃力・防御力を増加させてもよい。例えば、参加済みのユーザ：Ａの仲間の参加人数がｎのとき、ユーザ：Ｂの攻撃力・防御力に（１＋０．２×ｎ）を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力としてもよい。あるいは、特典とはならないが、ユーザ：Ａの仲間の参加人数が所定の数ｋよりも少ない場合、ユーザ：Ｂの攻撃力・防御力を減少させてもよい。例えば、ユーザ：Ａの仲間の参加人数がｎのとき、ユーザ：Ｂの攻撃力・防御力に｛１＋０．２×（ｎ−ｋ）｝を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ｂのチームの攻撃力・防御力としてもよい。

また、イベントに参加済みのユーザは、イベント終了までイベントの処理を複数回実行してもよい。例えば、イベントの発見者であるユーザ：Ａが、モンスター：ＡＢＣのＨＰ残量が０となる前に、再びモンスター：ＡＢＣとの対戦処理を行ってもよい。この場合、特典付与手段５６は、イベントにユーザ：Ａの仲間が参加している場合に、ユーザ：Ａの攻撃力・防御力を、所定量、又は、所定比率（例えば２０％）、増加させてもよい。
あるいは、特典付与手段５６は、イベントに参加済みの仲間の数に応じて、ユーザ：Ａの攻撃力・防御力を所定量、又は所定比率、増加させてもよい。例えば、ユーザの仲間の数がｎのとき、ユーザ：Ａの攻撃力・防御力に（１＋０．２×ｎ）を乗じた値を、モンスター：ＡＢＣとの対戦処理におけるユーザ：Ａのチームの攻撃力・防御力としてもよい。
あるいは、モンスター：ＡＢＣのＨＰ残量が０となった場合に、イベントの発見者であるユーザ：Ａに、イベントに参加済みの仲間の数に応じた能力及び／又はレア度を備えたオブジェクトを付与してもよい。イベントに参加済みの仲間の数が多いほど、例えばレア度が高いカードをユーザ：Ａに付与してもよい。
なお、複数回実行した際に、属性情報の数に応じた特典が付与されるのは発見者のみに限定してもよい。

図２１のＰ１１は、本変形例における、イベントへの参加を要請するユーザを選択するウェブページの例である。本変形例において、ウェブページＰ１１は、イベントへの参加を要請するユーザが仲間であるか否かの情報を含む。このため、参加を要請するユーザ：Ａは、特典を得るために、仲間を優先して参加を要請することができる。
なお、ユーザ：Ｂが発見者であるユーザ：Ａと関連付けられていない（仲間でない）場合でも、ユーザ：Ａの仲間の参加人数に応じた特典をユーザ：Ｂに付与してもよい。この場合、イベントへの参加を要請するユーザをユーザ：Ｂが選択するウェブページが、要請先ユーザがユーザ：Ａの仲間であるか否かの情報を含んでもよい。ユーザ：Ｂは、特典を得るために、ユーザ：Ａの仲間を優先して参加を要請することができる。

図２２のＰ１２は、本変形例における、ユーザ：Ｂが参加申請可能なイベントに関する情報のリストを含むウェブページの例である。本変形例において、ウェブページＰ１２は、イベントの発見者であるユーザがユーザ：Ｂの仲間であるか否かの情報を含む。このため、このため、参加を申請するユーザ：Ｂは、特典を得るために、参加者の属性の種類数と、発見者が仲間であるか否かの情報を参酌して、イベントへの参加を検討することができる。

このように、本変形例においては、イベントの発見者であるユーザ：Ａと他のユーザ：Ｂとの関連付けの有無（仲間であるか否か）を参酌して、イベントへの参加の要請や参加の申請を検討することができる。また、ユーザ：Ａは異なる属性の仲間にイベントへの参加の要請をしたときに最も多くの特典を得られ、ユーザ：Ｂは異なる属性の仲間が発見したイベントに参加したときに最も多くの特典を得られる。このため、ユーザが異なる属性のユーザを仲間にすることを促進し、ユーザの仲間の範囲を、自分とは異なる属性情報が対応付けられたユーザにまで拡大することができる。

（８−３）変形例３
本変形例に係るゲーム制御装置の機能ブロック図を、図２３に示す。図２３に示すように、本変形例では、図２０の機能ブロック図と比較して、属性変更手段５９が追加された点で異なる。
属性変更手段は、ユーザが所定の条件を満たした場合に属性を変更する機能を有する。属性変更手段５９の機能は、例えば以下のようにして実現される。
ユーザが所定の条件を満たした場合、ＣＰＵ２１は、属性変更登録要求メッセージを受信し、属性変更登録要求メッセージに含まれているユーザＩＤに対応するユーザデータベース３１に、要求された属性情報を登録する。
所定の条件とは、例えば所定のクエストを達成した場合でもよいし、所定のアイテムを使用した場合でもよい。
さらに、属性の変更を要求したユーザに対して、属性変更手段５９は、イベントに参加済みのユーザの属性情報に基づいて、特典を得やすい属性を提示してもよい。例えば、イベントに参加済みのユーザの属性情報に基づいて、最も参加者が少ない属性を提示してもよい。なお、提示する属性は、イベント全体の参加済みの属性情報に基づき決定してもよいし、各ユーザの参加済みのイベントにおける参加済みの属性情報に基づき決定してもよい。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。上記実施形態及び各変形例に記載された技術的事項は適宜組合せて適用してもよい。
ユーザの属性は上述した実施形態に限られず、例えば、ユーザが所属するゲーム内のグループや、グループ内の役職（役割）も属性に含まれる。例えば、野球ゲームの場合、属性には、ゲーム上の選手（ユーザ）のチームや、ポジション（例えば投手、捕手、一塁手、左翼手など）などが含まれてもよい。属性はユーザが最初にゲームを開始する時に定めた後、変更ができなくてもよいし、ゲームの途中で変更可能としてもよい。

上述した実施形態では、複数のカード（モンスターカード）を用いてバトルを行う場合を例として説明したが、これに限られない。バトルにおけるカードやオブジェクトは複数でなくてもよく、単一のカードやオブジェクトで構わない。
また、上述した実施形態では、オブジェクトの一例としてモンスターカードを挙げて説明したが、オブジェクトは、ゲーム上の使用対象あるいは操作対象などになり得るオブジェクトであれば如何なるものでもよく、例えばゲーム上のアイテムやキャラクタを含んでもよい。キャラクタとは、例えば現実世界に存在するもの（例えばスポーツ選手や歌手、アイドル、動物等）を模したものや、ゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものやフィギュアになっているものをも含んでもよい。
上述の実施形態においては、イベントでモンスターに敗北したときに救援要請を可能としていたが、本発明はこのように救援要請を行うための時期的または内容的な条件を有する場合に限らない。イベント中に所定の条件を満たす事を必要とせず、例えば、対戦開始前に救援要請を可能としてもよいし、イベント中の任意のタイミング、例えば、対戦結果が決定する前に救援要請を可能としてもよい。
また、上述の実施形態においては、参加申請可能なイベントに関する情報のリストのみを表示することとしたが、本発明はこれに限らず、参加済みのイベントに関する情報のリストを含んでもよい。この場合、ＣＰＵ２１は、ユーザが参加済み、または参加可能なイベントに関する情報のリストを含むウェブページのＨＴＭＬデータを生成すればよい。この場合、ＣＰＵ２１は、要請先ユーザに対応するユーザＩＤが発見者ユーザＩＤ、参加者ユーザＩＤ、要請先ユーザＩＤのいずれかの欄に記録されているイベントＩＤを探し、当該イベントＩＤの発見者ＩＤ、参加者ＩＤに対応する属性情報をユーザデータベースから取得すればよい。
また、イベントへの参加の申請は、直接的な参加の申請に限らず、間接的な参加の申請であってもよい。例えば、複数人のグループで協働してゲームを行うイベントである場合、グループに入ることをイベントへの参加の申請としてもよいし、協働してゲームをすることで、自動的に当該グループの実行するイベントへの参加申請としてもよい。

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

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
また、ユーザが単独で使用するスタンドアローンのゲーム機の場合、他のユーザのデータをメモリカード等により取り込むことで実現可能である。また、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよいし、相互に無線又は有線による通信を確立できる通信端末であってもよい。
また、例えば、家庭用ゲーム機がオフライン状態の場合であっても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。
さらに、例えば、アドホックネットワーク等のように、複数の通信端末（例えば携帯電話やゲーム機など）が自律的にネットワークを構成して、データの送受信を各通信端末間で直接行う場合においても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。

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

１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…バス
２０…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０…データベースサーバ
３１…データベース
３２…データベース
５１…登録手段
５２…実行手段
５３…対応付け手段
５４…提示手段
５５…受付手段
５６…特典付与手段
５７…要請手段
５８…関連付け手段
５９…属性変更手段

Claims (10)

1. 各ユーザのユーザ情報に、ユーザの特徴や性質などを示す情報、または、ユーザの特徴や性質などを分類するための情報である複数種類の属性情報のいずれかを対応付ける対応付け手段、
   複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける受付手段、
   前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、少なくとも前記イベントに参加していないユーザに提示する提示手段、
   前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典を、前記イベントに参加済みの少なくともいずれかのユーザに付与する特典付与手段、
   の各手段を備えた、ゲーム制御装置。
2. 前記イベントに参加済みのユーザが、前記イベントへの参加を他のユーザへ要請する要請手段を備える請求項１に記載のゲーム制御装置。
3. 前記提示手段は、前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、前記イベントへの参加を要請された要請先ユーザに提示する、請求項１または２に記載のゲーム制御装置。
4. ユーザと他のユーザを関連付ける関連付け手段を備え、
   前記特典付与手段は、前記イベントに最初に参加した第１のユーザに関連付けられた第２のユーザが前記イベントへ参加した場合、前記第１のユーザ及びイベントに参加済みの前記第２のユーザの少なくとも一方に特典を付与する、請求項１〜３に記載のゲーム制御装置。
5. ユーザと他のユーザを関連付ける関連付け手段を備え、
   前記特典付与手段は、前記イベントに最初に参加した第１のユーザに関連付けられた第２のユーザの前記イベントへの参加数が増えるにつれて増加する特典を、前記第１のユーザ及びイベント参加済みの前記第２のユーザの少なくとも一方に付与する、請求項１または３に記載のゲーム制御装置。
6. 前記特典付与手段は、同じ属性情報が対応付けられたユーザのうち最も早く前記イベントに参加したユーザに特典を付与する、請求項１〜５のいずれか一項に記載のゲーム制御装置。
7. 前記特典付与手段は、同じ属性情報が対応付けられた複数のユーザが前記イベントに参加した場合、早く参加したユーザに対してより多くの特典を付与する、請求項１〜６のいずれか一項に記載のゲーム制御装置。
8. 各ユーザのユーザ情報に、ユーザの特徴や性質などを示す情報、または、ユーザの特徴や性質などを分類するための情報である複数種類の属性情報のいずれかを対応付ける対応付け手段、
   ユーザと他のユーザを関連付ける関連付け手段、
   複数のユーザが参加可能なイベントに対するユーザの参加を受け付ける受付手段、
   前記イベントに最初に参加した第１のユーザが、前記イベントへの参加を他のユーザへ要請する要請手段、
   前記イベントに参加済みの各ユーザのユーザ情報に対応付けられた属性情報を、少なくとも要請先ユーザに提示する提示手段、
   前記イベントに参加済みのユーザのユーザ情報に対応付けられる属性情報の種類数に応じた特典、および、前記第１のユーザに関連付けられた第２のユーザの前記イベントへの参加数が増えるにつれて増加する特典を、前記第１のユーザに付与するとともに、前記イベントに参加済みの前記第２のユーザに特典を付与し、同じ属性情報が対応付けられたユーザのうち最も早く前記イベントに参加したユーザに特典を付与する特典付与手段、
   の各手段を備えた、ゲーム制御装置。
9. コンピュータに、請求項１〜８のいずれかのゲーム制御装置の各手段として機能させるためのプログラム。
10. 複数のユーザの通信端末と、当該通信端末からアクセスされるサーバとを含む、ゲームシステムであって、請求項１〜８のいずれかのゲーム制御装置の各手段を、前記通信端末または前記サーバのいずれか一方が備えた、ゲームシステム。

Images