JP5395210B2 - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置 - Google Patents

Description

本発明は、複数のユーザの各々の操作に応じて各ユーザによるゲームの進行を制御する技術、及び複数のユーザ間でデータの送受信や共有などを行う技術に関する。

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

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

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

従来のソーシャルゲームでは、例えば、複数のユーザが協力してバトル（対戦）などを実行する場合、一方のユーザ（要請元ユーザ）が他方のユーザに対して協力を要請し、他方のユーザ（要請先ユーザ）がその要請を受諾することによって両者の協力関係が形成されるようになっている。しかしながら、従来のソーシャルゲームでは、要請先ユーザに対して、要請元ユーザからの要請があったことが単に通知される構成となっていた。この場合、同じような要請が多数届いた場合等、要請先ユーザが要請を受諾することに対して消極的になる場合があり、結果として、両者の協力関係に基づくユーザ間の交流を図ることができないものとなっていた。

本発明は上述した観点に鑑みてなされたもので、ユーザからの要請に対して要請先ユーザが受諾するように動機付けることができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置を提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
ユーザによるゲーム上の要請を受け付ける受付手段と、
前記要請の要請先である要請先ユーザを決定する決定手段と、
前記要請先ユーザに前記要請を通知する通知手段と、
前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、
前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、
を具備し、
前記通知手段は、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
ことを特徴とする。

ここで、「操作入力に関する情報」とは、ゲーム制御装置に対して直接操作入力されることにより得られる情報に限られず、例えば、ゲーム制御装置にアクセス可能な外部装置に対して操作入力されることにより得られる情報であってもよい。
このゲーム制御装置では、要請先ユーザによる要請をユーザ（要請元ユーザ）が受諾したときの受諾情報が記憶装置に記憶されている場合、すなわち要請先ユーザによる要請を要請元ユーザが受諾したことがある場合、要請先ユーザに対する要請元ユーザからの要請の通知態様が変更される。このとき、要請先ユーザは、要請の通知態様が変更されることによって、自らの要請を受諾したことのある要請元ユーザからの要請であることを判別することができる。この場合、要請先ユーザは、要請元ユーザからの要請に応えようという使命感を生じ得ることから、要請元ユーザからの要請を受諾するように動機付けられる。したがって、両者の協力関係に基づくユーザ間の交流を促進することができ、ソーシャル性を向上させることができる。

上記ゲーム制御装置において、前記要請は、前記要請を行うユーザがゲーム上の有利な効果を得るために行われることであってもよい。
ここで、「ゲーム上の有利な効果」とは、例えば、ユーザがゲーム上保有するアイテムのパラメータを上昇させることであってもよいし、アイテムを用いることなくキャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。さらに、「ゲーム上の有利な効果」とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作などに応じて消費するゲーム上のポイントの消費量を通常よりも低減させることであってもよいし、当該ポイントを入手できることであってもよい。さらにまた、「ゲーム上の有利な効果」とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、アイテムのパラメータが大幅に上昇する確率を上昇させることであってもよい。
例えば、要請先ユーザが要請を受諾することによって、要請元ユーザ（ユーザ）がゲーム上の有利な効果を得られるように構成されている場合には、要請先ユーザは、要請元ユーザがゲームを有利に進めることに協力できたことを実感し得る。このため、要請先のユーザにとっては、要請を許諾した場合に得られる達成感を高めることができる。

上記ゲーム制御装置において、前記受諾情報は、前記要請先ユーザからの少なくとも１回の要請に対して前記ユーザが受諾した回数を含み、前記通知手段は、前記回数に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの少なくとも１回の要請に対して要請元ユーザ（ユーザ）が受諾した回数が多いほど、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、要請先ユーザからの要請を多く受諾したことのあるユーザであると判別することができる。この場合、要請先ユーザは、自らの要請を要請元ユーザが受諾してくれたことに報いるために、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

上記ゲーム制御装置において、前記受諾情報は、前記要請先ユーザからの要請に対する前記ユーザの貢献の程度を示す貢献度を含み、前記通知手段は、前記貢献度に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの要請に対する要請元ユーザ（ユーザ）の貢献度が高いほど、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、要請先ユーザからの要請に対して貢献度のより高いユーザであると判別することができる。この場合、要請先ユーザは、要請元ユーザの貢献に報いるために、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

上記ゲーム制御装置において、前記受諾情報は、前記要請先ユーザからの要請に対する前記ユーザの受諾時期から前記要請先ユーザに対する前記ユーザの要請の通知時期までの期間を含み、前記通知手段は、前記期間に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの要請に対する要請元ユーザ（ユーザ）の受諾時期から要請先ユーザに対する要請元ユーザの要請の通知時期までの期間が短いほど、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、当該要請元ユーザからの要請の通知時期から短い期間内に要請先ユーザからの要請を受諾したユーザであると判別することができる。この場合、要請先ユーザは、短い期間内で相互に要請し合うことで要請元ユーザに対する親近感を生じ得ることから、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

上記ゲーム制御装置において、前記受諾情報は、前記要請先ユーザからの要請を前記ユーザが受諾したときの前記要請先ユーザによるゲームの実行状況を含み、前記通知手段は、前記実行状況に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの要請を要請元ユーザ（ユーザ）が受諾したときの要請先ユーザによるゲームの実行状況が滞っていたほど（ゲームが進行していないほど）、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、要請先ユーザによるゲームの実行状況が滞っていたときの要請先ユーザからの要請を受諾したユーザであると判別することができる。この場合、要請先ユーザは、ゲームの実行状況が滞っていたときの自らの要請を要請元ユーザが受諾してくれたことに報いるために、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

上記ゲーム制御装置において、前記受諾情報は、前記要請先ユーザからの要請に対する前記ユーザの貢献の程度を示す貢献度を含み、前記通知手段は、前記ユーザからの要請を前記要請先ユーザに通知する際に、前記貢献度を前記要請先ユーザに通知してもよい。
この場合、要請先ユーザは、要請先ユーザからの要請に対する要請元ユーザの貢献度を具体的に認識することができる。このため、要請先ユーザは、要請元ユーザの貢献に報いるために、要請元ユーザからの要請に応えようという使命感をさらに高めることができる。これにより、要請元ユーザからの要請をより積極的に受諾するように動機付けることができる。

上記ゲーム制御装置において、前記通知手段は、前記要請先ユーザに対して要請を行うユーザが複数存在する場合に、前記受諾情報に基づいて、前記要請先ユーザに対する要請の通知態様を複数のユーザ毎に変更してもよい。
この場合、要請先ユーザは、例えば、複数の要請元ユーザからの要請のうち、要請先ユーザにとって優先度の高い要請を、各要請元ユーザの要請の通知態様に基づいて判別することができる。

本発明の第２の観点は、ゲーム制御方法である。
当該ゲーム制御方法は、
ユーザによるゲーム上の要請を受け付けるステップと、
前記要請の要請先である要請先ユーザを決定するステップと、
前記要請先ユーザに前記要請を通知するステップと、
前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付けるステップと、
前記要請の受諾に関する受諾情報を記憶装置に記憶させるステップと、
を備え、
前記要請を通知するステップでは、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する。

本発明の第３の観点は、コンピュータに、
ユーザによるゲーム上の要請を受け付ける機能、
前記要請の要請先である要請先ユーザを決定する機能、
前記要請先ユーザに前記要請を通知する機能、
前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける機能、及び
前記要請の受諾に関する受諾情報を記憶装置に記憶させる機能、
を実現させ、
前記要請を通知する機能では、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
ことを実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
ユーザによるゲーム上の要請を受け付ける受付手段、
前記要請の要請先である要請先ユーザを決定する決定手段、
前記要請先ユーザに前記要請を通知する通知手段、
前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段、
前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
前記通知手段は、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する。

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

本発明の第５の観点は、コミュニケーション装置である。
当該コミュニケーション装置は、
ユーザによる要請を受け付ける受付手段と、
前記要請の要請先である要請先ユーザを決定する決定手段と、
前記要請先ユーザに前記要請を通知する通知手段と、
前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、
前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、
を具備し、
前記通知手段は、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
ことを特徴とする。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、コミュニケーション装置によれば、ユーザからの要請に対して要請先ユーザが受諾するように動機付けることができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 データベースサーバに含まれるユーザデータベースの構成例を示す図。 モンスターキャラクタデータの内容を例示する図。 要請受諾リストのデータ構成例を示す図。 トップページを表示する通信端末の表示画面の一例を示す図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザの通信端末において表示される一連のウェブページを例示する図。 要請先ユーザの通信端末において表示される一連のウェブページを例示する図。 ユーザ及び要請先ユーザの各々の通信端末において表示されるウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置におけるバトル処理の一例を示すフローチャート。 （ａ），（ｂ）は、実施形態のゲーム制御装置の主要な処理の一例を示すシーケンスチャート。 変形例における要請受諾リストのデータ構成例を示す図。 変形例における要請受諾リストのデータ構成例を示す図。 実行状況データのデータ構成例を示す図。 要請先ユーザの通信端末において表示されるウェブページを例示する図。 要請先ユーザの通信端末において表示されるウェブページを例示する図。 要請先ユーザの通信端末において表示されるウェブページを例示する図。 通信端末及びゲームサーバの各々における各機能の構成例を示す図。

以下、本発明の実施形態について説明する。
ここで、本実施形態では、ユーザが保有する通信端末に対して、コミュニケーションサービスの一例であるゲーミングサービスを提供する場合を例に挙げて説明する。なお、コミュニケーションサービスは、ゲーミングサービスに限られず、例えば、複数のユーザ間でネットワークを介したデータ（例えば、コメントやメッセージなどのテキストデータ、画像データ、音声データなど）の送受信や共有などを行うことが可能なサービスであれば何でもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるものではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末１０に対する操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを使い、ゲーム上のモンスターであるモンスターキャラクタとバトルを行う対戦型デジタルカードゲーム（以下、適宜「本実施形態のゲーム」という。）を採り上げる。後述するように、本実施形態のゲームでは、ユーザがモンスターキャラクタとのバトル（対戦）で敗北すると支援要請を行うことができるように構成されている。また、このゲームでは、支援要請の要請先である他のユーザ（要請先ユーザ）が支援要請を受諾すると、支援要請元のユーザ（以降、要請元ユーザという。）の代わりに要請先ユーザがモンスターキャラクタとバトルを行うことで要請元ユーザを支援するように構成されている。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、例えば以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。
・戦士数
ユーザが保有する戦士カードの数である。戦士数の最大値（例えば、６０）は予め規定されている。
・勝利数
モンスターキャラクタとのバトルにおいて勝利した数である。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザのユーザＩＤのデータである。
・保有カードのデータ
保有カードのデータは、ユーザが保有している戦士カードのデータであり、例えば、図６に示すように、戦士カード毎の画像、攻撃力などのパラメータを含む。戦士カードがモンスターキャラクタとバトルを行うときに、モンスターキャラクタに対して攻撃力の値に応じたダメージを与えることができる。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報や、モンスターキャラクタのデータ（モンスターキャラクタデータ）や、要請受諾リストなどを記憶する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、各ユーザのモンスターキャラクタとのバトルの詳細結果などを含んでもよい。

モンスターキャラクタデータの一例を図７に示す。モンスターキャラクタデータは、バトルの相手となるモンスターキャラクタのデータを含む。モンスターキャラクタデータは、バトル処理の実行とともにゲームデータベース３２から例えばＲＡＭ２３にロードされ、記憶されるデータである。図７では、バトルに出現するモンスターキャラクタＭＣ１，ＭＣ２，ＭＣ３，…の各々について、ウェブページに表示される画像と、モンスターキャラクタの体力を示すＨＰ(Hit Point)の値とが対応付けられている。例えば、図７に示す例では、各モンスターキャラクタのＨＰは１５００〜２０００の範囲内であるが、この範囲の中からバトルを行うときにランダムにＨＰの値が設定されてもよい。

要請受諾リストは、要請の受諾に関する受諾情報が順に書き込まれたリストである。
図８は、要請受諾リストのデータ構成例を示す図である。図８に例示する要請受諾リストでは、支援を要請した要請元ユーザのユーザＩＤごとに、支援要請が行われたときのバトルのバトル相手（モンスターキャラクタ）と、バトル相手の残りＨＰと、要請元ユーザからの要請を受諾した要請先ユーザのユーザＩＤと、当該要請先ユーザが要請を受諾したときの日時である受諾日時とが書き込まれる。残りＨＰは、対応するモンスターキャラクタの最新のＨＰの値を示している。例えば、１又は複数回のバトルにおいてＨＰが低減した場合に、低減後のＨＰが要請受諾リストに書き込まれる。

本実施形態のゲームでは、後述するように、ユーザがモンスターキャラクタとのバトルにおいて敗北した場合に、他のユーザに対してそのバトルに対する支援要請を行うことができることとしているが、支援要請を行う条件は、ユーザがモンスターキャラクタとのバトルにおいて敗北したという条件に限られない。バトル開始時に無条件で支援要請できることとしてもよいし、バトルにおける所定の条件が満たされた場合にのみ支援要請ができることとしてもよい。バトルにおける所定の条件とは、例えば、ユーザがバトルで使用する戦士カード、及びバトル相手のモンスターキャラクタの攻撃力などのパラメータ（又は能力レベル）についての所定の条件であってもよく、より具体的には、例えば、戦士カードとモンスターキャラクタとの間の攻撃力の差が一定値あることという条件としてもよい。

（５）本実施形態のゲーム
以下、本実施形態のゲームのモンスターキャラクタとのバトル処理について、図９〜１４を参照しながら説明する。図９は、本実施形態のゲームにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１０〜１４は、バトル処理が実行されるときに通信端末１０上に表示されるウェブページの例を示す図である。また、ここでは、「ＡＢＣ」というユーザ（以下、ユーザ：ＡＢＣと表記する。）からの支援要請を「ＸＹＺ」というユーザ（以下、ユーザ：ＸＹＺと表記する。）が受諾し、その後、ユーザ：ＸＹＺからの支援要請がユーザ：ＡＢＣに通知される場合を一例として説明する。

先ず、ユーザ：ＡＢＣからの支援要請をユーザ：ＸＹＺが受諾する場合の一例について説明する。
図９に例示する本実施形態のゲームのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図９の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、戦士数、勝利数の各項目のデータ（図６参照）が表示される領域である。なお、図９において、戦士数の一例として「４０／６０」と表記されているが、これは、ユーザが保有する戦士カードが４０枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、本実施形態のゲームにおいてバトル処理の実行を開始するためのメニューｍ１を含む複数のメニュー（メニューｍ１以外は図示せず）が表示される領域である。

図９のトップページ上で、ユーザ：ＡＢＣによりメニューｍ１が選択操作されると、図１０のステップＳ１に示すようにウェブページが更新される。ステップＳ１のウェブページには、モンスターキャラクタ（図の例ではモンスターキャラクタＭＣ１）の画像のほか、「バトル開始」と表記されたメニューｍ１１などが表示される。

ステップＳ１のウェブページにおいて、ユーザ：ＡＢＣによりメニューｍ１１が選択されると、図１０のステップＳ２に示すようにウェブページが更新される。ステップＳ２のウェブページでは、ユーザ：ＡＢＣが保有する所定数（図の例では１０枚）の戦士カード２０２が表示される。また、ステップＳ２のウェブページでは、「攻撃する」と表記されたメニューｍ１２が表示される。戦士カード２０２は、ユーザ：ＡＢＣが保有する戦士カードの中からランダムに、あるいは予めユーザ：ＡＢＣの選択によって決定されてよい。
ここで、メニューｍ１２が選択操作されると、図１１のステップＳ３に示すようにウェブページが更新されて、ユーザ：ＡＢＣがモンスターキャラクタＭＣとの間でゲーム上のバトルを行うことになる。

モンスターキャラクタＭＣ１とのバトルでは、メニューｍ１２の選択操作に応じて行われる１０枚の戦士カードの攻撃によって、モンスターキャラクタＭＣ１のＨＰが低下する。メニューｍ１２が選択操作される毎に低下するＨＰの量は、戦士カードの攻撃力に応じて決定されてもよい。また、メニューｍ１２の選択操作に応じて、あるいはランダムなタイミングで、モンスターキャラクタＭＣ１から１０枚の戦士カードに対して順に攻撃が行われる。ステップＳ３のウェブページの１０枚の戦士カード２０２のうち、モンスターキャラクタＭＣ１に倒された戦士カード（ステップＳ３の例では、３枚のユーザの戦士カード２０２）については、倒れた形態でカードが表示される。バトルの結果、例えば、モンスターキャラクタＭＣ１のＨＰがゼロになり、且つ、ユーザ：ＡＢＣの１０枚の戦士カードのうち少なくとも１枚の戦士カードが倒されずにいる場合には、ユーザ：ＡＢＣがバトルに勝利し、モンスターキャラクタＭＣ１が撃破されたことになる。この場合、図１１のステップＳ４に示すようにウェブページが更新される。一方、例えば、モンスターキャラクタＭＣ１のＨＰがゼロにならず、且つ、ユーザ：ＡＢＣの１０枚の戦士カードがすべて倒された（全滅した）場合には、ユーザ：ＡＢＣがバトルに敗北したと判断されて、図１２のステップＳ５に示すようにウェブページが更新される。バトルに敗北した場合、モンスターキャラクタＭＣ１は消失せずに、バトル後に残存するＨＰが維持された状態となる。

なお、ステップＳ５のウェブページには、他のユーザに支援要請を行うための「支援要請する」と表記されたメニューｍ１３が表示される。
ここで、メニューｍ１３が選択操作されると、ユーザ：ＡＢＣは、支援の要請元ユーザとなる。なお、メニューｍ１３が選択操作された場合、他のモンスターキャラクタとのバトルが行われるようにしてもよい。この場合、他のモンスターキャラクタ（例えば、モンスターキャラクタＭＣ２）の画像が表示されたステップＳ１のウェブページに更新される。

ステップＳ５のウェブページにおいてユーザ：ＡＢＣがメニューｍ１３を選択操作すると、支援要請の要請先である要請先ユーザが決定され、決定された要請先ユーザの通信端末１０上には、要請元ユーザ（ここでは、ユーザ：ＡＢＣ）からの支援要請を受諾するか否かを確認するためのメッセージが表示される。要請先ユーザとして決定されたユーザ：ＸＹＺ向けのウェブページの一例を図１３のステップＳ６に示す。ステップＳ６のウェブページには、支援要請を受諾するか否かの選択を促すために、「受諾する」と表記されたメニューｍ１４と、「受諾しない」と表記されたメニューｍ１５とが表示される。ステップＳ６のウェブページにおいてメニューｍ１４（「受諾する」）が選択操作されると、図１３のステップＳ７に示すようにウェブページが更新されて、ユーザ：ＸＹＺが、自ら保有する所定数（図の例では１０枚）の戦士カード２０２を使用して、ユーザ：ＡＢＣのバトル相手であるモンスターキャラクタＭＣ１とバトルを行う画面に遷移する。ステップＳ７のウェブページは、例えば図１０のステップＳ２のウェブページと同形式であるが、モンスターキャラクタＭＣのＨＰの値は、ユーザ：ＡＢＣが敗北した時点のＨＰ（つまり、ステップＳ５のウェブページのモンスターキャラクタＭＣのＨＰ）の値となっている。

そして、ステップＳ７のウェブページにおいて、「攻撃する」と表記されたメニューｍ１２が選択操作されると、ユーザ：ＸＹＺがモンスターキャラクタＭＣ１との間でゲーム上のバトルを行うことになる。なお、ここでのバトル処理は、上述したステップＳ３〜Ｓ５のウェブページと同様に、ウェブページが更新されるようにして行われる。
ユーザ：ＸＹＺによるバトルの結果、例えば、モンスターキャラクタＭＣ１のＨＰがゼロになり、且つ、ユーザ：ＸＹＺの１０枚の戦士カードのうち少なくとも１枚の戦士カードが倒されずにいる場合には、ユーザ：ＸＹＺがバトルに勝利し、モンスターキャラクタＭＣ１が撃破されたことになる。この場合、ユーザ：ＡＢＣの勝利数が１つ増加する。また、ユーザ：ＡＢＣ及びユーザ：ＸＹＺの各々の勝利数が１つ増加してもよい。
一方、例えば、モンスターキャラクタＭＣ１のＨＰがゼロにならず、且つ、ユーザ：ＸＹＺの１０枚の戦士カードがすべて倒された（全滅した）場合には、ユーザ：ＸＹＺがバトルに敗北したと判断される。バトルに敗北した場合、モンスターキャラクタＭＣ１は消失せずに、バトル後に残存するＨＰが維持された状態となる。

なお、要請先ユーザであるユーザ：ＸＹＺが、支援要請されたバトルに敗北した場合、要請先ユーザであるユーザ：ＸＹＺが、支援要請されたバトルの対戦相手（ここでは、モンスターキャラクタＭＣ１）をバトルの対象とした支援要請を行えるようにしてもよい。この場合、処理が煩雑になるおそれがあるため、要請先ユーザは、支援要請されたバトルにおいて敗北した場合、当該バトルの対戦相手をバトルの対象とした支援要請を行えないようにすることが好ましい。この場合、要請元ユーザはユーザ：ＡＢＣのまま変わることなく、新たな要請先ユーザがユーザ：ＡＢＣからの支援要請を受諾してバトルを行うことになる。

次に、ユーザ：ＸＹＺからの支援要請がユーザ：ＡＢＣに通知される場合の一例について説明する。
例えば、ユーザ：ＸＹＺが、他のユーザからの支援要請に基づくことなく自ら実行したバトルにおいて敗北した場合、図１４のステップＳ８に例示するウェブページがユーザ：ＸＹＺの通信端末１０上に表示される。ステップＳ８のウェブページの例は、図１２のステップＳ５のウェブページと同形式であり、ユーザ：ＸＹＺが、モンスターキャラクタ（図の例では、モンスターキャラクタＭＣ２）とのバトルに敗北したことを示している。
ここで、メニューｍ１３が選択操作されると、ユーザ：ＸＹＺは、支援の要請元ユーザとなる。

ステップＳ８のウェブページにおいてユーザ：ＸＹＺがメニューｍ１３を選択操作すると、要請先ユーザが決定され、決定された要請先ユーザの通信端末１０上には、要請元ユーザ（ここでは、ユーザ：ＸＹＺ）からの支援要請を受諾するか否かを確認するためのメッセージが表示される。ここで、ユーザ：ＡＢＣが要請先ユーザとして決定された場合におけるユーザ：ＡＢＣ向けのウェブページの一例を図１４のステップＳ９に示す。ステップＳ９のウェブページは、図１３のステップＳ６のウェブページと形式が異なる（要請の通知態様が異なる）ように構成されている。具体的には、ステップＳ９のウェブページの例では、ユーザ：ＸＹＺが過去にユーザ：ＡＢＣからの要請を受諾したユーザであることを通知するメッセージ（図の例では、「あなたの支援要請に応じてくれたＸＹＺさん」）が他のテキストと比べて大きく表示されている。
このとき、要請先ユーザであるユーザ：ＡＢＣは、要請の通知態様が変更されることによって、自らの要請を受諾したことのある要請元ユーザ（ユーザ：ＸＹＺ）からの要請であることを判別することができる。この場合、ユーザ：ＡＢＣは、ユーザ：ＸＹＺからの要請に応えようという使命感を生じ得ることから、ユーザ：ＸＹＺからの要請を受諾するように動機付けられる。

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

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

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

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

対戦実行手段５２は、ユーザによるゲーム上のバトル（対戦）を実行する機能を備える。
ここで、本実施形態のゲームでは、バトルの相手（対戦相手）がモンスターキャラクタである場合を一例として説明しているが、対戦相手は、例えば、他のユーザであってもよいし、他のユーザの保有する複数あるいは単一の戦士カードからなるチームであってもよいし、ＣＰＵ２１が任意に抽出した複数あるいは単一の戦士カードからなるチームであってもよい。
なお、対戦実行手段５２は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。
対戦実行手段５２は、例えば、通信端末１０に表示するウェブページを、通信端末１０からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行するようにしてもよい。この場合、対戦実行手段５２の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に返信する。

例えば、図９に示すゲームのトップページ上でメニューｍ１が選択操作されたことによってＨＴＴＰリクエストが通信端末１０からゲームサーバ２０宛に送信されると、ゲームサーバ２０のＣＰＵ２１は、そのＨＴＴＰリクエストに応じて、図１０のステップＳ１に示すウェブページを表示するためのＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に送信する。このとき、ＨＴＭＬデータを作成するに当たって、ＣＰＵ２１は、モンスターキャラクタデータからゲームを実行中のユーザのバトル相手となるモンスターキャラクタを読み出してＲＡＭ２３に記憶させるとともに、読み出したデータに基づいてＨＴＭＬデータを生成する。

モンスターキャラクタとのバトル処理では、ゲームサーバ２０のＣＰＵ２１は、ユーザによる適切な操作に応じて、ユーザが保有する戦士カードのうちバトルで使用される所定数の戦士カードの選択結果を取得する。なお、以下では、理解の容易のために、バトルに参加する戦士カードの数を１枚とする。ＣＰＵ２１は、各ユーザについて、モンスターキャラクタを倒したタイミングで、あるいはランダムなタイミングで、ゲームデータベース３２が記憶するモンスターキャラクタデータのうちいずれかのモンスターキャラクタをバトルのために出現させる。具体的には、ＣＰＵ２１は、ユーザのバトル相手となるモンスターキャラクタのデータを読み出し、ＲＡＭ２３に新たに書き込む。このとき、モンスターキャラクタのデータのＨＰの初期値がランダムに決定される。例えば、モンスターキャラクタデータにおいてモンスターキャラクタＭＣ１のＨＰが１５００〜２０００の範囲として設定されているが、実際のバトル処理を行うときに使用されるＨＰの初期値として、１５００〜２０００の範囲の中からランダムに１つの値が決定される。
なお、ＣＰＵ２１は、要請先ユーザからのメニューｍ１４（「受諾する」）の選択操作を認識すると、当該要請先ユーザと、要請対象のバトルにおけるモンスターキャラクタとの間で、バトルの処理を実行する。具体的には、ＣＰＵ２１は、要請先ユーザが要請対象のバトルにおけるモンスターキャラクタに対して攻撃操作が可能となるようにＨＴＭＬデータを生成して、要請先ユーザの通信端末１０宛に送信する（例えば、図１３のステップＳ７のウェブページ参照）。このとき、バトル相手となるモンスターキャラクタのＨＰは、要請受諾リストに書き込まれている残りＨＰの値を元にバトルが開始される。このとき、ＣＰＵ２１は、要請受諾リストに書き込まれている残りＨＰの値をＲＡＭ２３に書き込む。

ＣＰＵ２１は、バトルで使用される戦士カードのデータをユーザデータから読み出して、ＲＡＭ２３に記憶させ、以下のバトル処理を実行する。
ＣＰＵ２１は、例えば、ユーザが戦士カードを使ってモンスターキャラクタを攻撃するとき（例えば図１０のステップＳ２のウェブページでメニューｍ１２（「攻撃する」）が選択操作されたとき）には、使用される戦士カードの攻撃力の値に応じてモンスターキャラクタのＨＰを低減させる処理を行う。以下、メニューｍ１２（「攻撃する」）に対する操作を「攻撃操作」という。
例えば、戦士カードの攻撃力をＰａとし、ランダムに決定される係数をｋとすると、１回の攻撃操作によって、モンスターキャラクタのＨＰに対して行われる演算は、例えば以下の式（１）に従って行われるようにしてもよい。なお、式（１）では、攻撃前のＨＰをＨＰｂ、攻撃後のＨＰをＨＰａとして記す。更新されたＨＰの値（ＨＰａ）は、バトル実行中に逐次ＲＡＭ２３に上書きされる。

ＨＰａ＝ＨＰｂ−Ｐａ×ｋ …（１）

また、攻撃操作に応じてバトル相手のモンスターキャラクタから戦士カードに対して、一定の、あるいはランダムな値の攻撃力にて攻撃が加えられる。モンスターキャラクタの攻撃力は、ＨＰに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。モンスターキャラクタから加えられる攻撃力、あるいはその攻撃力の積算値（複数回の攻撃操作に伴う攻撃力の積算値）が戦士カードの防御力を上回った場合に、その戦士カードが倒されたことになる。ユーザがバトルで使用される戦士カードが１枚のみの場合、その戦士カードが倒されたときにはユーザの敗北となる。なお、戦士カードが複数枚バトルに参加する場合、モンスターキャラクタから加えられる攻撃の対象となる戦士カードは一定の順に、あるいはランダムに決定されてよい。

攻撃操作によるモンスターキャラクタのＨＰの更新は、上述した式（１）に限られない。例えば、上記式（１）におけるＰａは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃操作に応じてランダムに決定される数値としても良い。
また、バトルの勝敗の決定方法は適宜設定することができる。例えば、所定回数の攻撃操作によって、あるいは所定時刻までにモンスターキャラクタのＨＰをゼロにすることができなければ、そのモンスターキャラクタを倒せなかった（敗北した）と判断してもよい。

ＣＰＵ２１は、更新後のモンスターキャラクタのＨＰの値がゼロになった場合には、モンスターキャラクタを撃破した（モンスターキャラクタに勝利した）と判断し、ユーザデータの勝利数を１だけ増加させる。

受付手段５３は、要請元ユーザ（ユーザ）によるゲーム上の要請を受け付ける機能を備える。
ここで、「ゲーム上の要請」とは、例えば、バトル処理（対戦）における支援要請や、ユーザ間におけるアイテムの交換などのように、ゲーム上の必要のために行われるものであれば何でもよいが、例えば、要請を行うユーザがゲーム上の有利な効果を得るために行われることであってもよい。本実施形態の例では、要請元ユーザは、要請先ユーザが支援要請におけるバトルに勝利すると、要請元ユーザの勝利数が１つ増加するというゲーム上の有利な効果を得ることができる。
例えば、要請先ユーザが要請を受諾することによって、要請元ユーザ（ユーザ）がゲーム上の有利な効果を得られるように構成されている場合には、要請先ユーザは、要請元ユーザがゲームを有利に進めることに協力できたことを実感し得る。このため、要請先のユーザにとっては、要請を許諾した場合に得られる達成感を高めることができる。
なお、ゲーム上の有利な効果とは、例えば、ユーザがゲーム上保有するアイテムのパラメータを上昇させることであってもよいし、アイテムを用いることなくキャラクタ（例えば戦士カード）の能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。さらに、ゲーム上の有利な効果とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作などに応じて消費するゲーム上のポイントの消費量を通常よりも低減させることであってもよいし、当該ポイントを入手できることであってもよい。さらにまた、ゲーム上の有利な効果とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、アイテムのパラメータが大幅に上昇する確率を上昇させることであってもよい。

受付手段５３の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１２のステップＳ５に示すウェブページにおいてメニューｍ１３が選択操作されると、選択操作を行ったユーザ（ここでは、ユーザ：ＡＢＣ）を支援要請の要請元ユーザとして認識し、当該ユーザ（ユーザ：ＡＢＣ）のユーザＩＤをＲＡＭ２３に記憶する。また、ＣＰＵ２１は、図１４のステップＳ８に示すウェブページにおいてメニューｍ１３が選択操作されると、選択操作を行ったユーザ（ここでは、ユーザ：ＸＹＺ）を支援要請の要請元ユーザとして認識し、当該ユーザ（ユーザ：ＸＹＺ）のユーザＩＤをＲＡＭ２３に記憶する。

決定手段５４は、要請の要請先である要請先ユーザを決定する機能を備える。
決定手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、支援要請の要請元ユーザのユーザＩＤがＲＡＭ２３に記憶されると、ユーザデータベース３１にアクセスし、ユーザデータベース３１内の複数のユーザＩＤの中から少なくとも１つのユーザＩＤを抽出する。そして、ＣＰＵ２１は、抽出したユーザＩＤに対応するユーザを、要請先ユーザとして決定する。なお、抽出されたユーザＩＤは、ＲＡＭ２３に記憶される。
なお、ユーザＩＤの抽出方法は、例えば、ランダムであってもよいし、所定の規則に基づくものであってもよい。また、要請先ユーザは、例えば要請元ユーザの仲間であってもよい。

通知手段５５は、要請先ユーザに要請を通知する機能を備える。
通知手段５５の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、要請先ユーザを決定すると、要請受諾リストを参照し、要請先ユーザによる要請を要請元ユーザが受諾したことがあるか否かを判別する。具体的に説明すると、ＣＰＵ２１は、ユーザ：ＡＢＣからの支援要請の要請先ユーザとしてユーザ：ＸＹＺが決定された場合、ユーザ：ＸＹＺのユーザＩＤが要請元ユーザのユーザＩＤに記録され、且つ、ユーザ：ＡＢＣのユーザＩＤが要請を受諾した要請先ユーザのユーザＩＤに記録された受諾情報が要請受諾リスト内に記憶されているか否かを判別する。そして、ＣＰＵ２１は、当該受諾情報が要請受諾リスト内に記憶されていない場合に、要請先ユーザ（ユーザ：ＸＹＺ）による要請を要請元ユーザ（ユーザ：ＡＢＣ）が受諾したことがないと判別する。一方、当該受諾情報が要請受諾リスト内に記憶されている場合、ＣＰＵ２１は、要請先ユーザ（ユーザ：ＸＹＺ）による要請を要請元ユーザ（ユーザ：ＡＢＣ）が受諾したことがあると判別する。
ここで、本実施形態では、当該受諾情報が要請受諾リスト内に記憶されていない、すなわち要請先ユーザ（ユーザ：ＸＹＺ）による要請を要請元ユーザ（ユーザ：ＡＢＣ）が受諾したことがない場合を前提として説明する。ＣＰＵ２１は、要請先ユーザ（ユーザ：ＸＹＺ）による要請を要請元ユーザ（ユーザ：ＡＢＣ）が受諾したことがないと判別すると、図１３のステップＳ６に例示するウェブページを表示するためのＨＴＭＬデータを生成して、要請先ユーザ（ユーザ：ＸＹＺ）の通信端末１０宛に送信する。ここで、ステップＳ６に示すウェブページがユーザ：ＸＹＺの通信端末１０上に表示されるタイミングは、例えば、ユーザ：ＸＹＺがゲームをプレイ中の場合には、要請元ユーザ（ユーザ：ＡＢＣ）からの要請を受け付けたタイミングとほぼ同時であってもよく、ユーザ：ＸＹＺがゲームをプレイしていない場合には、ユーザ：ＸＹＺがゲームのプレイを開始したタイミングであってもよい。

また、通知手段５５は、要請先ユーザによる要請を要請元ユーザ（ユーザ）が受諾したときの受諾情報が記憶装置に記憶されている場合に、要請先ユーザに対する要請元ユーザの要請の通知態様を変更する機能を備える。
この場合における通知手段５５の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、要請先ユーザを決定すると、ゲームデータベース３２が構成された記憶装置にアクセスして、ゲームデータベース３２内の要請受諾リストを参照し、要請先ユーザによる要請を要請元ユーザが受諾したことがあるか否かを判別する。ここでは、ユーザ：ＸＹＺからの支援要請の要請先ユーザとしてユーザ：ＡＢＣが決定され、且つ、要請先ユーザ（ユーザ：ＡＢＣ）による要請を要請元ユーザ（ユーザ：ＸＹＺ）が受諾したことがある場合を前提として説明する。つまり、この場合には、ユーザ：ＸＹＺからの支援要請の要請先ユーザとしてユーザ：ＡＢＣが決定された時点において、ユーザ：ＡＢＣのユーザＩＤが要請元ユーザのユーザＩＤに記録され、且つ、ユーザ：ＸＹＺのユーザＩＤが要請を受諾した要請先ユーザのユーザＩＤに記録された受諾情報が要請受諾リスト内に記憶されている。
ＣＰＵ２１は、要請先ユーザ（ユーザ：ＡＢＣ）による要請を要請元ユーザ（ユーザ：ＸＹＺ）が受諾したことがあると判別すると、図１４のステップＳ９に例示するウェブページを表示するためのＨＴＭＬデータを生成して、要請先ユーザ（ユーザ：ＡＢＣ）の通信端末１０宛に送信する。なお、ステップＳ９に示すウェブページにおける要請の通知態様がステップＳ６に示すウェブページと異なる点については、上述したとおりである。また、ステップＳ９に示すウェブページがユーザ：ＡＢＣの通信端末１０上に表示されるタイミングは、上述したステップＳ６に示すウェブページが表示されるタイミングと同様であってよい。

なお、上述した例では、要請元ユーザ（ユーザ：ＸＹＺ）が要請先ユーザ（ユーザ：ＡＢＣ）からの要請を受諾したユーザであることを通知するメッセージをウェブページに含むことによって、支援要請の通知態様を変更する場合を一例として説明したが、支援要請の通知の変更態様はこれに限られない。例えば、ステップＳ９のウェブページでは、通常の支援要請を通知するためのウェブページ（例えば、ステップＳ６のウェブページ）と比べて、ウェブページを構成するテキストのフォントの種類、サイズ、あるいは色などが変更されてもよい。また、例えば、通常の支援要請を通知するためのウェブページが静止画像を含む場合には、支援要請の通知態様を変更する際、当該画像が動画像（例えば、静止画像の色が変化するなど）に置き換えられてもよい。さらに、例えば、通常の支援要請を通知するためのウェブページが音声データを含む場合には、支援要請の通知態様を変更する際、当該音声データが変更されてもよい。また、ステップＳ６のウェブページの例では、要請元ユーザの表示名がテキストで表示されているが、支援要請の通知態様を変更する際、要請元ユーザの表示名が例えばアイコン等で表示されてもよい。さらに、通常の支援要請を通知するためのウェブページが所定の背景色で構成されている場合、支援要請の通知態様を変更する際、当該背景色が変更されてもよい。

受諾手段５６は、要請先ユーザの操作入力に関する情報に基づいて要請の受諾を受け付ける機能を備える。
ここで、「操作入力に関する情報」とは、ゲーム制御装置に対して直接操作入力されることにより得られる情報に限られず、例えば、ゲーム制御装置にアクセス可能な外部装置に対して操作入力されることにより得られる情報であってもよい。
受諾手段５６の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１３のステップＳ６に示すウェブページにおいてメニューｍ１４が選択操作されると、選択操作を行ったユーザ（ここでは、ユーザ：ＸＹＺ）を、支援要請を受諾した要請先ユーザとして認識し、当該要請先ユーザ（ユーザ：ＸＹＺ）のユーザＩＤをＲＡＭ２３に記憶する。また、ＣＰＵ２１は、図１４のステップＳ９に示すウェブページにおいてメニューｍ１４が選択操作されると、選択操作を行ったユーザ（ここでは、ユーザ：ＡＢＣ）を、支援要請を受諾した要請先ユーザとして認識し、当該要請先ユーザ（ユーザ：ＡＢＣ）のユーザＩＤをＲＡＭ２３に記憶する。

記憶手段５７は、要請の受諾に関する受諾情報を記憶装置に記憶させる機能を備える。
記憶手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、支援要請を受諾した要請先ユーザのユーザＩＤがＲＡＭ２３に記憶されると、ＲＡＭ２３に記憶された要請元ユーザのユーザＩＤ、バトル相手のモンスターキャラクタ、当該モンスターキャラクタの残りＨＰ、支援要請を受諾した要請先ユーザのユーザＩＤ及び要請の受諾日時を含む受諾情報を生成する。なお、要請の受諾日時は、例えば要請先ユーザがメニューｍ１４を選択操作したときの日時であってもよい。そして、ＣＰＵ２１は、ゲームデータベース３２が構成された記憶装置にアクセスして、当該受諾情報を、ゲームデータベース３２内の要請受諾リストに記録する。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１６のフローチャートを参照して説明する。図１６は、本実施形態のゲーム制御装置によって行われる、モンスターキャラクタとのバトル処理を示している。なお、ここでは、ユーザ：ＡＢＣがバトル処理を実行する場合を一例として説明する。

先ず、図１０のステップＳ１に示したようにモンスターキャラクタ（図の例ではモンスターキャラクタＭＣ１）が出現するウェブページ上で、メニューｍ１１が選択されたことが認識されると（ステップＳ１００：ＹＥＳ）、ＣＰＵ２１は、図１０のステップＳ２に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ１０２）。

ステップＳ２のウェブページ上でメニューｍ１２の選択操作、すなわち攻撃指示操作がなされたことが認識されると（ステップＳ１０４：ＹＥＳ）、ＣＰＵ２１は、モンスターキャラクタとのバトル処理を行う（ステップＳ１０６）。このバトル処理は、ユーザ：ＡＢＣのユーザデータと、モンスターキャラクタデータとに基づいて実行される。バトル処理においては、攻撃指示操作に応じて、ユーザ：ＡＢＣの手持ちの戦士カード（ユーザの戦士カードと仲間の戦士カード）からモンスターキャラクタに対して攻撃が行われ、それによってモンスターキャラクタのＨＰが低下し、ウェブページ上のＨＰゲージ２０１の目盛りの量が低下する。また、バトル処理においては、攻撃指示操作に応じて、あるいはランダムなタイミングで、モンスターキャラクタからユーザ：ＡＢＣの手持ちの戦士カードに対して攻撃が行われ、それによって１又は複数枚の戦士カードが倒される場合がある。ＨＰゲージ２０１の目盛りが変化する、あるいは戦士カードが倒されることによって、例えば図１１のステップＳ３に示すように、逐次ウェブページが更新される。

次に、ＣＰＵ２１は、モンスターキャラクタとのバトルが終了したか否かの判定（ステップＳ１０８）を行う。この判定は適宜行うことができる。例えば、一定回数の攻撃指示操作がなされたこと、あるいは最初に攻撃指示操作を行ってから一定時間経過したことをもってバトルが終了したと判定を行ってもよいし、モンスターキャラクタのＨＰがゼロになった場合、又はユーザ：ＡＢＣの手持ちの戦士カードがすべて倒された（全滅した）場合にバトルが終了したと判定してもよい。
モンスターキャラクタとのバトルが終了したと判定された場合には（ステップＳ１０８：ＹＥＳ）、ステップＳ１１０へ進む。モンスターキャラクタとのバトルが終了していないと判定された場合には（ステップＳ１０８：ＮＯ）、ステップＳ１０４へ戻り、次の攻撃指示操作を受け入れ可能な状態となる。

ＣＰＵ２１は、ユーザ：ＡＢＣがモンスターキャラクタとのバトルに勝利したと判定された場合に（ステップＳ１１０：ＹＥＳ）、図１１のステップＳ４に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザ：ＡＢＣの通信端末１０宛に送信する（ステップＳ１１２）。次に、ＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザ：ＡＢＣのユーザＩＤに対応する勝利数を１つ増加（インクリメント）する（ステップＳ１１４）。
一方、ＣＰＵ２１は、ユーザがモンスターキャラクタとのバトルに敗北したと判定された場合に（ステップＳ１１０：ＮＯ）、図１２のステップＳ５に示すウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する（ステップＳ１１６）。ここで、ユーザ：ＡＢＣがメニューｍ１３の選択操作を行った場合（ステップうＳ１１８：ＹＥＳ）、ＣＰＵ２１は、後述する要請処理を行う（ステップＳ１２０）。

次に、本実施形態のゲーム制御装置により行われる主要な処理のシーケンスの一例について、図１７（ａ）のシーケンスチャートを参照して説明する。図１７（ａ）は、ユーザ：ＡＢＣにより支援要請が行われた場合における要請処理の一例を示すシーケンスチャートである。

先ず、ゲームサーバ２０のＣＰＵ２１は、図１６のフローのステップＳ１１８においてメニューｍ１３が選択操作され、支援要請を含むＨＴＴＰリクエストを受信すると（ステップＳ２００）、選択操作を行ったユーザ（ここでは、ユーザ：ＡＢＣ）を支援要請の要請元ユーザとして認識し、当該ユーザ（ユーザ：ＡＢＣ）のユーザＩＤをＲＡＭ２３に記憶する。次に、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザデータベース３１内の複数のユーザＩＤの中から少なくとも１つのユーザＩＤを抽出する。そして、ＣＰＵ２１は、抽出したユーザＩＤに対応するユーザを、要請先ユーザとして決定する（ステップＳ２０２）。なお、ここでは、ユーザ：ＸＹＺが要請先ユーザとして決定されたこととする。

次いで、ＣＰＵ２１は、要請先ユーザを決定すると、要請受諾リストを参照し、要請先ユーザによる要請を要請元ユーザが受諾したことがあるか否かを判別する（ステップＳ２０４）。具体的に説明すると、ＣＰＵ２１は、ユーザ：ＸＹＺのユーザＩＤが要請元ユーザのユーザＩＤに記録され、且つ、ユーザ：ＡＢＣのユーザＩＤが要請を受諾した要請先ユーザのユーザＩＤに記録された受諾情報が要請受諾リスト内に記憶されているか否かを判別する。なお、ここでは、要請先ユーザ（ユーザ：ＸＹＺ）による要請を要請元ユーザ（ユーザ：ＡＢＣ）が受諾したことがない場合を前提として説明する。
ＣＰＵ２１は、要請先ユーザ（ユーザ：ＸＹＺ）による要請を要請元ユーザ（ユーザ：ＡＢＣ）が受諾したことがないと判別すると、図１３のステップＳ６に例示するウェブページを表示するためのＨＴＭＬデータを生成して、要請先ユーザ（ユーザ：ＸＹＺ）の通信端末１０宛に送信する（ステップＳ２０６）。

ステップＳ６のウェブページ上でユーザ：ＸＹＺによってメニューｍ１４（「受諾する」）が選択操作され、支援要請が受諾されたことを認識すると（ステップＳ２０８）、ＣＰＵ２１は、メニューｍ１４の選択操作を行ったユーザ（ユーザ：ＸＹＺ）を、支援要請を受諾した要請先ユーザとして認識し、当該要請先ユーザ（ユーザ：ＸＹＺ）のユーザＩＤをＲＡＭ２３に記憶する。また、ＣＰＵ２１は、ＲＡＭ２３に記憶された要請元ユーザのユーザＩＤ、バトル相手のモンスターキャラクタ、当該モンスターキャラクタの残りＨＰ、支援要請を受諾した要請先ユーザのユーザＩＤ及び要請の受諾日時を含む受諾情報を生成する。そして、ＣＰＵ２１は、ゲームデータベース３２が構成された記憶装置にアクセスして、当該受諾情報を、ゲームデータベース３２内の要請受諾リストに記録する（ステップＳ２１０）。また、ＣＰＵ２１は、図１３のステップＳ７に例示するウェブページを表示するためのＨＴＭＬデータを生成して、要請先ユーザ（ユーザ：ＸＹＺ）の通信端末１０宛に送信する（ステップＳ２１２）。ここで、ユーザ：ＸＹＺによって行われるバトル処理の流れは、図１６のフローと同様であってもよい。

次に、本実施形態のゲーム制御装置により行われる主要な処理のシーケンスの一例について、図１７（ｂ）のシーケンスチャートを参照して説明する。図１７（ｂ）は、ユーザ：ＸＹＺにより支援要請が行われた場合における要請処理の一例を示すシーケンスチャートである。なお、ここでは、ユーザ：ＸＹＺがモンスターキャラクタとのバトルに敗北したことにより（図１６のフローのステップＳ１１０：ＮＯ）、図１４のステップＳ８に示すウェブページがユーザ：ＸＹＺの通信端末１０に表示されていることを前提とする。

先ず、ゲームサーバ２０のＣＰＵ２１は、図１６のフローのステップＳ１１８においてメニューｍ１３が選択操作され、支援要請を含むＨＴＴＰリクエストを受信すると（ステップＳ２２０）、選択操作を行ったユーザ（ここでは、ユーザ：ＸＹＺ）を支援要請の要請元ユーザとして認識し、当該ユーザ（ユーザ：ＸＹＺ）のユーザＩＤをＲＡＭ２３に記憶する。次に、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザデータベース３１内の複数のユーザＩＤの中から少なくとも１つのユーザＩＤを抽出する。そして、ＣＰＵ２１は、抽出したユーザＩＤに対応するユーザを、要請先ユーザとして決定する（ステップＳ２２２）。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザとして決定されたこととする。

次いで、ＣＰＵ２１は、要請先ユーザを決定すると、要請受諾リストを参照し、要請先ユーザ（ここでは、ユーザ：ＡＢＣ）による要請を要請元ユーザ（ここでは、ユーザ：ＸＹＺ）が受諾したことがあるか否かを判別する（ステップＳ２２４）。ここで、上述した図１７（ａ）のステップＳ２１０の処理において、ユーザ：ＡＢＣのユーザＩＤが要請元ユーザのユーザＩＤに記録され、且つ、ユーザ：ＸＹＺのユーザＩＤが要請を受諾した要請先ユーザのユーザＩＤに記録された受諾情報が要請受諾リスト内に記憶されている。このため、ＣＰＵ２１は、要請先ユーザによる要請を要請元ユーザが受諾したことがあると判別する。
ＣＰＵ２１は、要請先ユーザによる要請を要請元ユーザが受諾したことがあると判別すると、図１４のステップＳ９に例示するウェブページを表示するためのＨＴＭＬデータを生成する（ステップＳ２２６）。なお、ステップＳ９に示すウェブページは、ステップＳ６に示すウェブページと要請の通知態様が異なるように生成される。そして、ＣＰＵ２１は、生成したＨＴＭＬデータを要請先ユーザ（ユーザ：ＡＢＣ）の通信端末１０宛に送信する（ステップＳ２２８）。

上述したように、実施形態のゲーム制御装置によれば、ユーザ：ＡＢＣ（要請先ユーザ）による要請をユーザ：ＸＹＺ（要請元ユーザ）が受諾したときの受諾情報が記憶装置に記憶されている場合、すなわちユーザ：ＡＢＣによる要請をユーザ：ＸＹＺが受諾したことがある場合、ユーザ：ＡＢＣに対するユーザ：ＸＹＺからの要請の通知態様が変更される。このとき、ユーザ：ＡＢＣは、要請の通知態様が変更されることによって、自らの要請を受諾したことのあるユーザ：ＸＹＺからの要請であることを判別することができる。この場合、ユーザ：ＡＢＣは、ユーザ：ＸＹＺからの要請に応えたいという気持ちを生じ得ることから、ユーザ：ＸＹＺからの要請を受諾するように動機付けることができる。したがって、両者の協力関係に基づくユーザ間の交流を促進することができ、ソーシャル性を向上させることができる。

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

（８−１）変形例１
上記実施形態において、受諾情報は、要請先ユーザからの少なくとも１回の要請に対して要請元ユーザ（ユーザ）が受諾した回数を含み、通知手段５５は、前記回数に応じて、要請先ユーザに対する要請元ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの少なくとも１回の要請に対して要請元ユーザが受諾した回数が多いほど、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、要請先ユーザからの要請を多く受諾したことのあるユーザであると判別することができる。この場合、要請先ユーザは、自らの要請を要請元ユーザが受諾してくれたことに報いるために、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

通知手段５５の機能は例えば、以下のとおり実現される。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザであり、ユーザ：ＸＹＺが要請元ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＡＢＣを要請先ユーザとして決定すると、ゲームデータベース３２内の要請受諾リストを参照し、ユーザ：ＡＢＣからの少なくとも１回の要請に対するユーザ：ＸＹＺの受諾回数を計数する。ここで、ユーザ：ＸＹＺの受諾回数は、例えばユーザ：ＡＢＣが要請元ユーザとして記録された受諾情報のうち、ユーザ：ＸＹＺが要請先ユーザとして記録された受諾情報の数を計数することで求められてもよい。
そして、ＣＰＵ２１は、ユーザ：ＸＹＺからの要請をユーザ：ＡＢＣに通知するためのウェブページを表示するためのＨＴＭＬデータを生成する際に、例えばユーザ：ＸＹＺの受諾回数が多いほど、ユーザ：ＸＹＺからの要請が視覚的あるいは聴覚的により認識し易くなるようにウェブページを構成する。例えば、ユーザ：ＸＹＺの受諾回数が多いほど、ウェブページに表示されるテキストのフォントがより大きくなるように構成されてもよいし、メニューｍ１４のサイズが大きくなるように構成されてもよい。

（８−２）変形例２
上記実施形態において、受諾情報は、要請先ユーザからの要請に対する要請元ユーザ（ユーザ）の貢献の程度を示す貢献度を含み、通知手段５５は、前記貢献度に応じて、要請先ユーザに対する前記ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの要請に対する要請元ユーザの貢献度が高いほど、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、要請先ユーザからの要請に対して貢献度のより高いユーザであると判別することができる。この場合、要請先ユーザは、要請元ユーザの貢献に報いるために、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

本変形例における通知手段５５の機能を実現するに当たり、例えば図１８に示す要請受諾リストがゲームデータベース３２に記憶されてもよい。図１８に示す要請受諾リストは、複数の受諾情報ごとに貢献度が含まれる点において図８の要請受諾リストと異なっている。ここで、貢献度は、本実施形態のゲームを例に挙げれば、１回のバトル処理におけるモンスターキャラクタへの攻撃回数（つまり、メニューｍ１２の選択回数）であってもよいし、１回のバトル処理においてモンスターキャラクタに与えたダメージの合計などであってもよい。なお、モンスターキャラクタへの攻撃回数や、モンスターキャラクタに与えたダメージの合計などは、対戦実行手段５２の機能によってＲＡＭ２３に記憶されてもよい。
本変形例における記憶手段５７では、ゲームサーバ２０のＣＰＵ２１は、要請先ユーザによる要請対象のバトルが終了すると、ＲＡＭ２３に記憶された要請元ユーザのユーザＩＤ、バトル相手のモンスターキャラクタ、当該モンスターキャラクタの残りＨＰ、要請先ユーザのユーザＩＤ、要請の受諾日時及び貢献度を含む受諾情報を生成する。そして、ＣＰＵ２１は、生成した受諾情報を要請受諾リストに記録する。
また、本変形例における通知手段５５の機能は、例えば以下のようにして実現できる。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザであり、ユーザ：ＸＹＺが要請元ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＡＢＣを要請先ユーザとして決定すると、ゲームデータベース３２内の要請受諾リストを参照し、ユーザ：ＡＢＣからの要請に対するユーザ：ＸＹＺの貢献度を抽出する。
そして、ＣＰＵ２１は、ユーザ：ＸＹＺからの要請をユーザ：ＡＢＣに通知するためのウェブページを表示するためのＨＴＭＬデータを生成する際に、ユーザ：ＸＹＺの貢献度が高いほど、ユーザ：ＸＹＺからの要請が視覚的あるいは聴覚的により認識し易くなるようにウェブページを構成してもよい。例えば、ユーザ：ＸＹＺの貢献度が高いほど（例えば、モンスターキャラクタへの攻撃回数や、モンスターキャラクタに与えたダメージの合計が多いほど）、ウェブページに表示されるテキストのフォントがより大きくなるように構成されてもよいし、メニューｍ１４のサイズが大きくなるように構成されてもよい。

（８−３）変形例３
上記実施形態において、受諾情報は、要請先ユーザからの要請に対する要請元ユーザ（ユーザ）の受諾時期から要請先ユーザに対する要請元ユーザの要請の通知時期までの期間を含み、通知手段は、前記期間に応じて、要請先ユーザに対する要請元ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの要請に対する要請元ユーザの受諾時期から要請先ユーザに対する要請元ユーザの要請の通知時期までの期間が短いほど、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、当該要請元ユーザからの要請の通知時期から短い期間内に要請先ユーザからの要請を受諾したユーザであると判別することができる。この場合、要請先ユーザは、短い期間内で相互に要請し合うことで要請元ユーザに対する親近感を生じ得ることから、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

本変形例における通知手段５５の機能は、例えば以下のようにして実現できる。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザであり、ユーザ：ＸＹＺが要請元ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、図１７（ｂ）のシーケンスのステップＳ２２６において、ゲームデータベース３２内の要請受諾リストを参照し、ユーザ：ＡＢＣからの要請に対してユーザ：ＸＹＺが受諾したことを示す受諾情報が存在する場合には、当該受諾情報からユーザ：ＸＹＺの受諾時期を抽出する。
そして、ＣＰＵ２１は、ユーザ：ＸＹＺからの要請をユーザ：ＡＢＣに通知するためのウェブページを表示するためのＨＴＭＬデータを生成する際に、例えば、ユーザ：ＸＹＺの受諾時期からＨＴＭＬデータを生成するまでの経過時間が短いほど、ユーザ：ＸＹＺからの要請が視覚的あるいは聴覚的により認識し易くなるようにウェブページを構成してもよい。例えば、ユーザ：ＸＹＺの受諾時期からＨＴＭＬデータを生成するまでの経過時間が短いほど、ウェブページに表示されるテキストのフォントがより大きくなるように構成されてもよいし、メニューｍ１４のサイズが大きくなるように構成されてもよい。

（８−４）変形例４
上記実施形態において、受諾情報は、要請先ユーザからの要請を要請元ユーザ（ユーザ）が受諾したときの要請先ユーザによるゲームの実行状況を含み、通知手段５５は、前記実行状況に応じて、要請先ユーザに対する要請元ユーザの要請の通知態様を変更してもよい。
例えば、要請先ユーザからの要請を要請元ユーザ（ユーザ）が受諾したときの要請先ユーザによるゲームの実行状況が滞っていたほど（ゲームが進行していないほど）、要請先ユーザに対する要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるように、要請の通知態様を変更してもよい。この場合、要請先ユーザは、要請元ユーザの要請が視覚的あるいは聴覚的により認識し易くなるほど、当該要請元ユーザが、要請先ユーザによるゲームの実行状況が滞っていたときの要請先ユーザからの要請を受諾したユーザであると判別することができる。この場合、要請先ユーザは、ゲームの実行状況が滞っていたときの自らの要請を要請元ユーザが受諾してくれたことに報いるために、要請元ユーザからの要請に応えようという使命感を高めることができる。これにより、要請元ユーザからの要請を積極的に受諾するように動機付けることができる。

本変形例における通知手段５５の機能を実現するに当たり、例えば図１９に示す要請受諾リストがゲームデータベース３２に記憶されてもよい。図１９に示す要請受諾リストは、複数の受諾情報ごとに、要請先ユーザが要請を受諾したときの要請元ユーザによるゲームの実行状況が含まれる点において図８の要請受諾リストと異なっている。ここで、要請元ユーザによるゲームの実行状況は、本実施形態のゲームを例に挙げれば、モンスターキャラクタとのバトルにおいて要請元ユーザが勝利を得るまでの進行状況であってもよいし、要請元ユーザのバトルの勝利数であってもよい。
また、ゲームの実行状況は、例えば、図２０に例示する実行状況データに基づいて設定されてもよい。図２０に示す実行状況データは、例えばモンスターキャラクタとのバトルにおいて要請元ユーザが勝利を得るまでの状況（図の例では、「余裕がある」、「苦戦している」など）ごとに、当該状況に該当する条件が予め設定されたデータである。なお、図２０の例では、「苦戦している」という実行状況が、「余裕である」という実行状況と比較して、ゲームの実行状況が滞っていることを示している。また、各実行状況に対応する条件は任意に設定され得る。例えば、モンスターキャラクタと１回のバトルを行うために、要請元ユーザが保有するポイントから所定量のポイントが消費されるように構成されている場合、要請元ユーザが当該所定量よりも多量のポイントを保有していたときには、「余裕がある」という実行状況に該当するようにしてもよいし、要請元ユーザが当該所定量未満のポイントしか保有していない（つまり、モンスターキャラクタとのバトルを行うことができない）ときには、「苦戦している」という実行状況に該当するようにしてもよい。なお、実行状況データは、ゲームデータベース３２に記憶されてもよい。

本変形例における記憶手段５７では、ゲームサーバ２０のＣＰＵ２１は、例えば図１７（ａ）のシーケンスのステップＳ２１０において、要請元ユーザのユーザＩＤ、バトル相手のモンスターキャラクタ、当該モンスターキャラクタの残りＨＰ、支援要請を受諾した要請先ユーザのユーザＩＤ、要請の受諾日時及び要請先ユーザが要請を受諾したときの要請元ユーザによるゲームの実行状況を含む受諾情報を生成する。ここで、ＣＰＵ２１は、例えば図２０に示す実行状況データを参照して、要請元ユーザによるゲームの実行状況を設定してもよい。なお、図２０の例において、バトルに参加している戦士カードの攻撃力は、例えば要請元ユーザのユーザデータ内の保有カードのデータに記録されている値であってよい。また、図２０の例において、モンスターキャラクタのＨＰは、例えばＲＡＭ２３に記憶された残りＨＰであってよい。そして、ＣＰＵ２１は、生成された受諾情報を、ゲームデータベース３２内の要請受諾リストに記録する。
本変形例における通知手段５５の機能は、例えば以下のようにして実現できる。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザであり、ユーザ：ＸＹＺが要請元ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、図１７（ｂ）のシーケンスのステップＳ２２６において、ゲームデータベース３２内の要請受諾リストを参照し、ユーザ：ＡＢＣからの要請に対してユーザ：ＸＹＺが受諾したことを示す受諾情報が存在する場合には、当該受諾情報からユーザ：ＡＢＣによるゲームの実行状況を抽出する。
そして、ＣＰＵ２１は、ユーザ：ＸＹＺからの要請をユーザ：ＡＢＣに通知するためのウェブページを表示するためのＨＴＭＬデータを生成する際に、例えば、ユーザ：ＡＢＣによるゲームの実行状況が滞っていたほど、ユーザ：ＸＹＺからの要請が視覚的あるいは聴覚的により認識し易くなるようにウェブページを構成してもよい。例えば、ユーザ：ＡＢＣによるゲームの実行状況が滞っていたほど、ウェブページに表示されるテキストのフォントがより大きくなるように構成されてもよいし、メニューｍ１４のサイズが大きくなるように構成されてもよい。ここで、ユーザ：ＡＢＣの通信端末１０に表示されるウェブページの一例を図２１に示す。図２１に例示するウェブページには、例えば、要請元ユーザであるユーザ：ＸＹＺが、ユーザ：ＡＢＣによるゲームの実行状況が「苦戦している」という実行状況であったときにユーザ：ＡＢＣからの支援申請を受諾したユーザであることを通知するメッセージが含まれてもよい。

（８−５）変形例５
上記実施形態において、受諾情報は、要請先ユーザからの要請に対する要請元ユーザ（ユーザ）の貢献の程度を示す貢献度を含み、通知手段５５は、要請元ユーザからの要請を要請先ユーザに通知する際に、前記貢献度を要請先ユーザに通知してもよい。
この場合、要請先ユーザは、要請先ユーザからの要請に対する要請元ユーザの貢献度を具体的に認識することができる。このため、要請先ユーザは、要請元ユーザの貢献に報いるために、要請元ユーザからの要請に応えようという使命感をさらに高めることができる。これにより、要請元ユーザからの要請をより積極的に受諾するように動機付けることができる。

本変形例では、例えば図１８に示す要請受諾リストがゲームデータベース３２に記憶されてもよい。
また、本変形例における通知手段５５の機能は、例えば以下のようにして実現できる。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザであり、ユーザ：ＸＹＺが要請元ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ユーザ：ＡＢＣを要請先ユーザとして決定すると、ゲームデータベース３２内の要請受諾リストを参照し、ユーザ：ＡＢＣからの要請に対するユーザ：ＸＹＺの貢献度を抽出する。
そして、ＣＰＵ２１は、ユーザ：ＸＹＺからの要請をユーザ：ＡＢＣに通知するためのウェブページを表示するためのＨＴＭＬデータを生成する際に、ユーザ：ＸＹＺの貢献度を含むようにウェブページを構成してもよい。ここで、ウェブページの表示例を図２２に示す。図２２に例示するウェブページには、例えば、ユーザ：ＡＢＣからの要請に対するユーザ：ＸＹＺの貢献度（図の例では、モンスターキャラクタに与えたダメージの合計）を通知するメッセージなどが含まれる。なお、貢献度の部分が他の部分と比べて大きな表示変化（例えば、貢献度の部分のみをさらに拡大表示するなど）となるようにしてもよい。

（８−６）変形例６
上記実施形態において、通知手段５５は、要請先ユーザに対して要請を行う要請元ユーザが複数存在する場合に、受諾情報に基づいて、要請先ユーザに対する要請の通知態様を複数のユーザ毎に変更してもよい。
この場合、要請先ユーザは、例えば、複数の要請元ユーザからの要請のうち、要請先ユーザにとって優先度の高い要請を、各要請元ユーザの要請の通知態様に基づいて判別することができる。

本変形例における通知手段５５の機能は、例えば以下のようにして実現できる。なお、ここでは、ユーザ：ＡＢＣが要請先ユーザである場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、例えば複数の要請元ユーザからの要請の要請先ユーザとしてユーザ：ＡＢＣを決定した場合、ゲームデータベース３２内の要請受諾リストを参照し、ユーザ：ＡＢＣからの要請に対して要請先ユーザが受諾したことを示す受諾情報が存在するか否かを複数の要請元ユーザ毎に判別する。
そして、ＣＰＵ２１は、受諾情報が存在すると判別された要請元ユーザからの要請をユーザ：ＡＢＣに通知するためのウェブページを表示するためのＨＴＭＬデータを生成する。ここで、例えば、ユーザ：ＡＢＣからの要請に対する要請元ユーザの受諾回数が多いほど、当該要請元ユーザからの要請が視覚的あるいは聴覚的により認識し易くなるようにウェブページを構成してもよい。ここで、ユーザ：ＡＢＣの通信端末１０に表示されるウェブページの一例を図２３に示す。図２３に例示するウェブページでは、ユーザ：ＡＢＣからの要請に対する要請元ユーザの受諾回数が多いほど、当該要請元ユーザの表示名を含むメッセージが大きく表示されるようになっている。また、ユーザ：ＡＢＣからの要請に対する要請元ユーザの受諾回数が多いほど、当該要請元ユーザに対応する「受諾する」と表記されたメニューｍ１４のサイズが大きく形成されてもよい。

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

例えば、上述した実施形態では、コミュニケーション装置の一例であるゲーム制御装置がゲームを実行する場合の例について説明したが、これに限られず、任意のコミュニケーション装置に本発明を適用することができる。例えば、複数のユーザ間でネットワークを介したデータ（例えば、コメントやメッセージなどのテキストデータ、画像データ、音声データなど）の送受信や共有などを行うことが可能なコミュニケーションサービスにおいて、ユーザが他のユーザに対して何らかの要請（例えば、ゲームに招待することや、情報やデータなどの交換の依頼など）を行うことができるように構成されている場合には、本発明の構成を好適に適用することができる。このようなコミュニケーション装置では、例えば、過去に要請先ユーザが要請元ユーザに行った要請に対する要請元ユーザの受諾回数に応じて、要請元ユーザからの要請が要請先ユーザに通知される際の当該要請の通知態様が変更されるように構成されてもよい。

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

上述した実施形態では、実行対象のゲームがカードを用いたバトルゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、ユーザによる要請を他のユーザ（要請先ユーザ）に通知し、要請先ユーザが当該要請を受諾することを受け付けるように構成されている場合には、本発明を好適に適用することができる。

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

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

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

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

Claims (12)

1. ユーザによるゲーム上の要請を受け付ける受付手段と、
   前記要請の要請先である要請先ユーザを決定する決定手段と、
   前記要請先ユーザに前記要請を通知する通知手段と、
   前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、
   前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、
   を具備し、
   前記通知手段は、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
   ことを特徴とする、ゲーム制御装置。
2. 前記受諾情報は、前記要請先ユーザからの少なくとも１回の要請に対して前記ユーザが受諾した回数を含み、
   前記通知手段は、前記回数に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、ことを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記受諾情報は、前記要請先ユーザからの要請に対する前記ユーザの貢献の程度を示す貢献度を含み、
   前記通知手段は、前記貢献度に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、ことを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記受諾情報は、前記要請先ユーザからの要請に対する前記ユーザの受諾時期から前記要請先ユーザに対する前記ユーザの要請の通知時期までの期間を含み、
   前記通知手段は、前記期間に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、ことを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記受諾情報は、前記要請先ユーザからの要請を前記ユーザが受諾したときの前記要請先ユーザによるゲームの実行状況を含み、
   前記通知手段は、前記実行状況に応じて、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、ことを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記受諾情報は、前記要請先ユーザからの要請に対する前記ユーザの貢献の程度を示す貢献度を含み、
   前記通知手段は、前記ユーザからの要請を前記要請先ユーザに通知する際に、前記貢献度を前記要請先ユーザに通知する、ことを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記通知手段は、前記要請先ユーザに対して要請を行うユーザが複数存在する場合に、前記受諾情報に基づいて、前記要請先ユーザに対する要請の通知態様を複数のユーザ毎に変更する、ことを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. 前記要請は、前記要請元ユーザがゲーム上の有利な効果を得るために行われることを特徴とする、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. ゲーム制御装置によって実行されるゲーム制御方法であって、
   前記ゲーム制御装置の受付手段が、ユーザによるゲーム上の要請を受け付けるステップと、
   前記ゲーム制御装置の決定手段が、前記要請の要請先である要請先ユーザを決定するステップと、
   前記ゲーム制御装置の通知手段が、前記要請先ユーザに前記要請を通知するステップと、
   前記ゲーム制御装置の受諾手段が、前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付けるステップと、
   前記ゲーム制御装置の記憶手段が、前記要請の受諾に関する受諾情報を記憶装置に記憶させるステップと、
   を備え、
   前記要請を通知するステップでは、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
   ゲーム制御方法。
10. コンピュータに、
    ユーザによるゲーム上の要請を受け付ける機能、
    前記要請の要請先である要請先ユーザを決定する機能、
    前記要請先ユーザに前記要請を通知する機能、
    前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける機能、及び
    前記要請の受諾に関する受諾情報を記憶装置に記憶させる機能、
    を実現させ、
    前記要請を通知する機能では、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
    ことを実現させるためのプログラム。
11. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    ユーザによるゲーム上の要請を受け付ける受付手段、
    前記要請の要請先である要請先ユーザを決定する決定手段、
    前記要請先ユーザに前記要請を通知する通知手段、
    前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段、
    前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
    前記通知手段は、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
    ゲームシステム。
12. ユーザによる要請を受け付ける受付手段と、
    前記要請の要請先である要請先ユーザを決定する決定手段と、
    前記要請先ユーザに前記要請を通知する通知手段と、
    前記要請先ユーザの操作入力に関する情報に基づいて前記要請の受諾を受け付ける受諾手段と、
    前記要請の受諾に関する受諾情報を記憶装置に記憶させる記憶手段と、
    を具備し、
    前記通知手段は、前記要請先ユーザによる要請を前記ユーザが受諾したときの受諾情報が前記記憶装置に記憶されている場合に、前記要請先ユーザに対する前記ユーザの要請の通知態様を変更する、
    ことを特徴とする、コミュニケーション装置。

Images