JP6678867B2 - サーバ、制御プログラム - Google Patents

Description

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

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

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

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

従来のソーシャルゲームにおいて、複数のユーザが協力してプレイするように構成され
たゲームが存在する。例えば、所定の期間内で特定のユーザが他のユーザと協力して敵キ
ャラクタを攻撃するように構成されているゲームが知られている。しかしながら、このよ
うな従来のゲームでは、常に固定化した仲間のユーザ同士で協力してゲームを行う傾向に
あり、コミュニケーションの程度が低い他のユーザ、あるいは今までコミュニケーション
をとったことがない他のユーザと協力してゲームを行うように動機付ける仕組みとなって
いなかった。つまり、従来の協力プレイを利用したゲームでは、十分にソーシャル性を発
揮できる仕組みとなっていなかった。

本発明は上述した観点に鑑みてなされたもので、複数のユーザが協力してゲームを行う
場合に、コミュニケーションの程度が低いユーザ同士、あるいは今までコミュニケーショ
ンをとったことがないユーザ同士で協力してゲームを行うように動機付けることができる
ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的と
する。

本発明の第１の観点は、複数のユーザの協力によって処理が行われるイベントを含むゲ
ームの実行を制御するゲーム制御装置である。
このゲーム制御装置は、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段（
５３）と、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行する実行手段（５２）と、
前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段（５４）と
、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得手段（５４）によって取得されたユーザの数に関する情報に
応じた特典を付与する特典付与手段（５５）と、
を備える。

このゲーム制御装置の実行対象となるゲームには、イベント以外のゲーム要素として、
協力プレイによるものだけでなく、ユーザの単独プレイによるものが含まれてもよい。
このゲーム制御装置において、「ユーザの数に関する情報」とは、ユーザの数自体を示
す数値データに限られず、当該数値データと同一の値でなくとも当該数値データと連動し
て変動する情報や、当該数値データに対応付けられた情報であってもよい。

このゲーム制御装置では、所定のイベントに対応付けられるユーザ（例えば、そのイベ
ントに参加しているユーザ）の数に応じて、そのイベント内の処理の実行に伴う特典が付
与される。つまり、イベントに対応付けられるユーザが多いほどイベント内の処理の実行
に伴って多くの特典が付与されることになる。つまり、固定化した仲間のユーザ同士でイ
ベント内の処理を実行するよりも、より多くのユーザがイベントに参加することが有利と
なる仕組みとなっている。そのため、このゲーム制御装置によれば、複数のユーザが協力
してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、ある
いは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うよ
うに動機付けることができる。

上記ゲーム制御装置において、前記対応付け手段（５３）は、前記イベントの開始時刻
から所定時間が経過したときに、ユーザの前記イベントへの対応付けを解除してもよい。
この構成により、イベントに参加しているユーザの数に応じて特典を得られるという有
利な効果が持続する時間が制限されるため、限られた時間内でのユーザ間のコミュニケー
ションが促進されるとともに、有利な効果が持続し過ぎることないようにゲーム進行にお
けるユーザ間の公平性が担保される。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整
数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目に前記イベン
トに対応付けられたユーザと異なる場合に、前記Ｎ番目のユーザが対応付けられてから、
又は前記Ｎ番目のユーザによる前記処理の実行が開始若しくは終了してから所定時間が経
過したときに、ユーザの前記イベントへの対応付けを解除してもよい。
この構成により、イベントに対応付けられるユーザが連続して同一ユーザでない場合に
は、既に対応付けられている複数のユーザのイベントへの対応付けは解除されず、イベン
トに対応付けられたユーザの数に応じて特典を得られるという有利な効果が持続する。そ
のため、異なるユーザが入れ替わりイベント内の処理を実行するように動機付けられるこ
とになり、例えばイベントに対応付けられているユーザ間でコミュニケーションをとるこ
とが促進される。

上記ゲーム制御装置において、前記取得手段（５４）によって取得されたユーザの数が
多いほど、前記所定時間を短くしてもよい。
イベントに対応付けられているユーザの数が多いほどより多くの特典が得られる状況と
なるが、そのような状況が長く継続すると、ゲーム進行におけるユーザ間の公平性が担保
されない場合がある。そのため、ユーザの数が多いほど上記所定時間を短くすることで、
ゲーム進行におけるユーザ間の公平性を担保することが好ましい。

上記ゲーム制御装置において、前記実行手段（５２）による前記イベント内の処理の実
行回数が多いほど、前記所定時間を短くしてもよい。
イベントに対応付けられているユーザの数が多いほど、つまりイベント内の処理の実行
回数が多くなるほど、より多くの特典が得られる状況となるが、そのような状況が長く継
続すると、ゲーム進行の公平性が担保されない場合がある。そのため、イベント内の処理
の実行回数が多いほど上記所定時間を短くすることで、ゲーム進行の公平性を担保するこ
とが好ましい。

上記ゲーム制御装置において、ユーザを前記イベントに対応付けるためのユーザの入力
を受け付けるタイミングで、前記取得手段（５４）によって取得されたユーザの数に関す
る情報を、当該ユーザに提示する提示手段（５７）を備えてもよい。
このような提示手段（５７）を備えることで、例えばイベントに参加する（対応付けら
れる）前にユーザは、既にイベントに参加しているユーザの数がわかるため、これからイ
ベントに参加しようとするときに、ユーザの数に応じた特典の大小を推定できるようにな
る。そのため、ユーザがイベントに参加することに対する動機付けがより強く働かせるこ
とができるようになる。

上記ゲーム制御装置において、前記特典付与手段（５５）は、前記イベントの結果が所
定の条件を満たす場合に、前記イベントに対応付けられたユーザに対して、さらに特典を
付与してもよい。「所定の条件」は、イベントの種別に応じて適宜決定してよいが、例え
ば、イベントが複数ユーザで協力してバトルを行うことである場合には、「所定の条件」
は、そのバトルで勝利することであってもよい。
この構成では、イベントの結果次第でイベントに参加する（対応付けられる）ユーザに
対して追加の特典が付与されるか否かが決定されるため、既にイベントに参加済みのユー
ザ間で、イベントの結果が所定の条件を満たすように、コミュニケーションをとることが
促進される。

前記イベントの結果が所定の条件を満たす場合に付与される特典は、前記イベントが終
了した時点において前記取得手段（５４）によって取得されたユーザの数に関する情報に
応じた特典であってもよい。
この構成では、イベントが終了する時点までにできるだけ多くのユーザがイベントに参
加する（対応付けられる）ことが、既にイベントに参加しているユーザにとって有利であ
る。そのため、ユーザ間で、より多くのユーザがイベントに参加するよう働きかけが行わ
れるようにコミュニケーションをとることが促進される。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整
数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目に前記イベン
トに対応付けられたユーザと同一である場合に、当該ユーザの前記イベントへの対応付け
を解除してもよい。
この構成では、同一のユーザが連続してイベントに対応付けられた場合には、当該ユー
ザのイベントへの対応付けが解除され、イベントに対応付けられたユーザの数が低減する
ことになる。そのため、より多くのユーザの間で入れ替わり対応付けが行われてイベント
内の処理を実行することが動機付けられ、ユーザ間でコミュニケーションをとることが促
進される。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整
数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目までに前記イ
ベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザ
の前記イベントへの対応付けを解除してもよい。
この構成では、既にイベントに参加済みのユーザが再度イベントに参加して処理を実行
した場合には、当該ユーザのイベントへの対応付けが解除され、イベントに対応付けられ
たユーザの数が低減することになる。つまり、固定化した仲間のユーザ同士で入れ替わり
イベントに参加しても多くの特典を得ることができなくなるため、固定化した仲間のユー
ザ同士でイベント内の処理を実行することが回避される。結果として、複数のユーザが協
力してイベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あ
るいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行う
ように動機付けることができる。

上記ゲーム制御装置において、前記対応付け手段（５３）は、Ｎ番目（Ｎ：２以上の整
数）のユーザが前記イベントに対応付けられ、かつ当該ユーザがＮ−１番目までに前記イ
ベントに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前記所定時
間を短くしてもよい。
この構成では、既にイベントに参加済みのユーザが再度イベントに参加して処理を実行
した場合、イベントに参加しているユーザの数に応じて特典を得られるという有利な効果
が持続する時間が短くなる。そのため、固定化した仲間のユーザ同士で入れ替わりイベン
トに参加しても多くの特典を得る機会が少なくなるため、固定化した仲間のユーザ同士で
イベント内の処理を実行することが回避される。結果として、複数のユーザが協力してイ
ベント内の処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今
までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動
機付けることができる。

本発明の第２の観点は、複数のユーザの協力によって処理が行われるイベントを含むゲ
ームの実行を制御するゲーム制御方法である。
このゲーム制御方法は、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付けるステップと、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行するステップと、
前記イベントに対応付けられたユーザの数に関する情報を取得するステップと、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得するステップによって取得されたユーザの数に関する情報に
応じた特典を付与するステップと、
を備える。

本発明の第３の観点は、複数のユーザの協力によって処理が行われるイベントを含むゲ
ームの実行を制御するプログラムである。
このプログラムは、
コンピュータに、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける機能、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行する機能、
前記イベントに対応付けられたユーザの数に関する情報を取得する機能、及び、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得する機能によって取得されたユーザの数に関する情報に応じ
た特典を付与する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末（１０）と、当該通信端末からアクセスされるサーバ
（２０）とを含み、複数のユーザの協力によって処理が行われるイベントを含むゲームの
実行を制御するゲームシステムである。
このゲームシステムは、
ユーザの入力情報に基づいて、当該ユーザを前記イベントに対応付ける対応付け手段（
５３）、
前記イベントに対応付けられたユーザの入力情報に基づいて、前記イベント内の処理を
実行する実行手段（５２）、
前記イベントに対応付けられたユーザの数に関する情報を取得する取得手段（５４）、
及び、
前記イベントに対応付けられたユーザの前記イベント内の前記処理の実行によって、当
該ユーザに対して、前記取得手段（５４）によって取得されたユーザの数に関する情報に
応じた特典を付与する特典付与手段（５５）、
の各手段を、前記通信端末（１０）又は前記サーバ（２０）のいずれか一方が備えた、
を備えた、ゲームシステムである。
なお、上記では、本発明の理解を容易にするため、適宜図面に記載された符号を括弧書
きで記載しているが、これにより本発明に係るゲーム制御装置等が図示の態様に限定され
るものではない。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、複
数のユーザが協力してゲームを行う場合に、コミュニケーションの程度が低いユーザ同士
、あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを
行うように動機付けることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本実施形態のゲームシステムによって実現されるゲームのタイプは特に限定されるもの
ではないが、以下では、本実施形態のゲームの一例として、ユーザの通信端末１０に対す
る操作に応じて、ユーザがゲーム上で仮想的に保有する戦士カードを用いてエリアを探索
するクエストを実行するデジタルカードゲーム（以下、適宜「本実施形態のゲーム」とい
う。）を採り上げる。後述するように、クエストの途中でゲーム上の恐竜キャラクタとの
間で他のユーザと協力してバトルを行う仕組みとなっている。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特
定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータ
を構成する各項目のデータの内容は、以下のとおりである。
・ユーザ名
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。
ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ゲ
ームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上
でユーザを特定する名称である。
・進行レベル
ゲーム上のユーザの進行レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ
１００（レベル１００）までの範囲のレベル値である。ユーザがクエストを実行すること
で経験値が増加し、経験値が一定値に達すると進行レベルが１だけ増加し、経験値がリセ
ットされる（ゼロになる）。
・体力ポイント
クエストを実行する毎に所定量減少し、所定の時間が経過する毎に回復（増加）するポ
イントである。ユーザがクエストを実行するときの体力の値を示している。
・攻撃ポイント
本実施形態のゲームにおいて、戦士カードを使用した恐竜キャラクタとのバトルを行う
上で必要となるポイントである。ユーザは、１又は複数の保有カードによって恐竜キャラ
クタとバトルを行うときの攻撃チームを組むことができるが、攻撃チームに含まれる保有
カードのポイント消費量（攻撃ポイントの消費量）の総和が攻撃ポイントを超えることは
できない。攻撃ポイントは、恐竜キャラクタと１回のバトルを行うことで、攻撃チームに
含まれる保有カードのポイント消費量の総和が低減し、所定の時間が経過する毎に回復（
増加）する。
・特典ポイント
恐竜キャラクタとバトルを行ったときに恐竜キャラクタに与えたダメージに応じて得ら
れる特典である。
・恐竜撃破数
本実施形態のゲームにおいて、ユーザがバトルによって撃破した恐竜キャラクタの数で
ある。
・仲間のユーザＩＤ
対象となるユーザＩＤと関係付けられた他のユーザＩＤのデータである。
・保有カードのデータ
保有カードのデータは、ユーザが保有している戦士カード（保有カード）のデータであ
り、例えば、図６に示すように、戦士カードのカードＩＤ（ＷＲ０８０等）と、ポイント
消費量（攻撃ポイントの消費量）と、攻撃力及び防御力のパラメータの値とから構成され
る。本実施形態のゲームでは、戦士カードが恐竜キャラクタとバトルを行うときに、攻撃
力の値が大きいほど恐竜キャラクタに対して多くのダメージを与えることができ、防御力
の値が大きいほど恐竜キャラクタから攻撃を受けたときにダメージを受け難くすることが
できる設定となっている。

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

恐竜キャラクタデータの一例を図７に示す。恐竜キャラクタデータは、バトルの相手と
なる恐竜キャラクタに関するデータを含む。恐竜キャラクタデータは、恐竜キャラクタに
固有のキャラクタＩＤ（ＤＣ１，ＤＣ２，ＤＣ３，…）ごとに、恐竜キャラクタの画像と
、恐竜キャラクタの体力を示すＨＰ(Hit Point)の値とが対応付けられている。例えば、
図７に示す例では、各恐竜キャラクタのＨＰは１５００〜２０００の範囲内であるが、こ
の範囲の中からバトルを行うときにランダムにＨＰの値が設定されてもよい。
後述するように、恐竜キャラクタデータの中からバトル相手となる恐竜キャラクタが選
択されると、その恐竜キャラクタのデータが例えばＲＡＭ２３にロードされる。

バトル管理データは、ユーザごとにバトルの状態を管理するためのデータである。図８
にバトル管理データのデータ構成例を示す。図８に示すバトル管理データでは、ユーザ（
ユーザ名又はユーザＩＤ）ごとに、バトルＩＤ、バトル相手、消滅時刻、バトル履歴、残
ＨＰ、追撃レベル、追撃終了時刻、及び、撃破フラグの各項目についてのデータを含む。
各項目のデータの内容は、以下のとおりである。

・バトルＩＤ
恐竜キャラクタが出現したときに、その恐竜キャラクタと行われる一連のバトルを識別
するための識別情報（図８の例では、識別番号）である。本実施形態のゲームでは、ユー
ザがクエストを実行中に恐竜キャラクタと遭遇し、その恐竜キャラクタとのバトルが開始
されるが、恐竜キャラクタと遭遇したユーザを、以下の説明では「発見ユーザ」という。
バトル管理データでは、バトルＩＤは、発見ユーザに対応付けて記述される。
発見ユーザと恐竜キャラクタとの間のバトル、及び、後述する支援ユーザと恐竜キャラ
クタとのバトルはすべて、共通のバトルＩＤに対応付けて管理される。なお、発見ユーザ
と恐竜キャラクタとの間のバトル、及び、後述する支援ユーザと恐竜キャラクタとのバト
ルを総称して、「恐竜キャラクタとのバトル」と適宜表記する。なお、本発明のイベント
は、複数のユーザによって処理が行われるイベントであるが、本実施形態において、発見
ユーザ及び支援ユーザによる共通の恐竜キャラクタとのバトルは、イベントの一例である
。
・バトル相手
特定のバトルにおいてバトルの相手となる恐竜キャラクタを示す。
・消滅時刻
特定のバトルにおいてバトル相手の恐竜キャラクタが消滅する時刻である。本実施形態
のゲームでは、恐竜キャラクタを消滅時刻までに撃破した場合に、恐竜撃破数が増加する
。
・バトル履歴
本実施形態のゲームでは、発見ユーザが恐竜キャラクタを撃破できなかった場合には、
発見ユーザは他のユーザに対して支援要請を行うことができ、支援要請を受諾したユーザ
がその恐竜キャラクタとバトルを行うことができるように構成されている。支援要請を受
諾してバトルを行うユーザを、以下の説明では「支援ユーザ」という。
バトル履歴の項目には、発見ユーザ（図８の例では、ユーザＫＮＭ）と、バトルに対応
付けられた１又は複数の支援ユーザ（図８の例では、ユーザＡＢＣ，ユーザＱＲＳ）が順
に記述されている。また、発見ユーザと支援ユーザの各々と恐竜キャラクタとのバトルに
よる恐竜キャラクタのＨＰ低下量が記述される。
・残ＨＰ
バトル相手の恐竜キャラクタの残りのＨＰを示す。図８の例では、発見ユーザであるユ
ーザＫＮＭと恐竜キャラクタのバトルの結果、恐竜キャラクタの残ＨＰが２０００から１
１００まで低下したことを意味している。
・追撃レベル
特定のバトルにおいて、支援を行ったユーザの数（つまり、特定のバトルに対応付けら
れた、異なるユーザＩＤの支援ユーザの数）と同一の値である。追撃レベルは、後述する
追撃終了時刻まで上昇可能な値である。本実施形態のゲームでは、同一の攻撃チームを使
用する場合に、追撃レベルが増加すればするほど、恐竜キャラクタに与えるダメージ（つ
まり、ＨＰの低下量）がより大きくなるように構成されている。
・追撃終了時刻
追撃レベルが上昇可能な追撃期間の終期である。追撃終了時刻に達すると、追撃レベル
がリセットされる（つまり、ゼロに戻る）。
・撃破フラグ
バトル相手の恐竜キャラクタが撃破されたか否かを示すフラグである。撃破フラグが「
０」である場合には恐竜キャラクタが撃破されていないことを意味し、撃破フラグが「１
」である場合には恐竜キャラクタが撃破されたことを意味する。

（５）本実施形態のゲーム
以下、本実施形態のゲームの恐竜キャラクタとのバトル処理について、図９〜１４を参
照しながら説明する。
図９は、ユーザがクエスト実行中に恐竜キャラクタと遭遇するときのウェブページの表
示例を示す図である。図１０は、発見ユーザが恐竜キャラクタとバトルを行うときのウェ
ブページの表示例を示す図である。図１１は、発見ユーザが支援要請を行うときのウェブ
ページの表示例を示す図である。図１２は、１番目の支援ユーザが恐竜キャラクタとバト
ルを行うときのウェブページの表示例を示す図である。図１３は、２番目の支援ユーザが
恐竜キャラクタとバトルを行うときのウェブページの表示例を示す図である。図１４は、
バトルに参加しているユーザ間でメッセージの送受信を行うときのウェブページの表示例
を示す図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメ
ニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１
０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいは
タッチパネル操作によるウェブページのスクロール操作によって変化しうる。

（５−１）恐竜キャラクタとの遭遇（図９）
図９のトップページＰ０は個々のユーザＩＤに応じたウェブページで構成されるが、図
９の例では、ユーザＫＮＭのトップページＰ０を示している。
図９の例では、トップページＰ０は、ユーザデータ表示領域、戦士画像表示領域及びメ
ニュー表示領域を含む。ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータ
に含まれる、進行レベル、体力ポイント、攻撃ポイント、特典ポイント、恐竜撃破数の各
項目のデータ（図６参照）が表示される領域である。
戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カー
ドのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、本実施形態のゲームにおいて、クエスト処理の実行を開始するた
めのメニューｍ１を含む複数のメニュー（メニューｍ１以外は図示せず）が表示される領
域である。なお、クエスト処理とは、アイテムを取得するためにエリアを探索する処理で
ある。

図９のゲームのトップページＰ０上でメニューｍ１が選択操作されると、Ｐ１に示すよ
うにウェブページが更新される。このウェブページＰ１には、ユーザがクエストとしてエ
リアを探索するためのメニューｍ５（「探索する」）が含まれる。メニューｍ５が選択操
作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されている様々なア
イテムのいずれかをユーザが入手できるように構成してもよい。メニューｍ５が選択操作
される度に一定の、あるいはランダムな増加量で進行度の値が増加し、進行度が１００％
に達するとエリアの探索が終了する。メニュー５が選択操作される度に、ユーザＫＮＭの
体力ポイントが所定量だけ消費され（図９の例では、−５）、ユーザＫＮＭの経験値が所
定量だけ増加する（図９の例では、＋８）。探索対象のエリアは、複数設けられてもよく
、実行中のエリアの達成率が１００％に達すると次のエリアに移動できるとしてもよい。
体力ポイントが上記所定量未満になった場合にはクエスト処理を実行することはできな
い。その場合には、体力ポイントが回復するまでユーザＫＮＭは待機する必要がある。

メニューｍ５の選択操作に応じてランダムなタイミングで、あるいは、所定数のエリア
のクエストが完了すると、ユーザＫＮＭは恐竜キャラクタに遭遇する仕組みとなっている
。例えば、図９のウェブページＰ２では、ユーザＫＮＭが遭遇した恐竜キャラクタＤＣ１
（「恐竜ＤＣ１」）の画像と、メニューｍ１０（「バトルする」）及びメニューｍ１１（
「バトルしない」）とが含まれる。この場合、発見ユーザは、ユーザＫＮＭである。ウェ
ブページＰ２においてメニューｍ１０が選択操作されると、Ｐ３に示すようにウェブペー
ジが更新される。このウェブページＰ３では、例えば、遭遇した恐竜キャラクタが消滅す
るまでの時間（つまり、消滅時刻までの時間）と、プルダウンメニューｍ１５とが表示さ
れる。

プルダウンメニューｍ１５は、所定数の攻撃チーム、例えば攻撃チーム１〜３のいずれ
かを選択することができるように設定されている。この場合、プルダウンメニューｍ１５
に設定される複数の攻撃チームは、例えば、以下のように予め設定されてもよいが、ウェ
ブページＰ３が表示される時点でユーザＫＮＭの攻撃ポイントが少ない場合には、選択で
きない攻撃チームもありうる。
・攻撃チーム１：ユーザの攻撃ポイントの最大値の１００％を消費して、ユーザが保有
する戦士カードの中から編成した攻撃チーム
・攻撃チーム２：ユーザの攻撃ポイントの最大値の６０％を消費して、ユーザが保有す
る戦士カードの中から編成した攻撃チーム
・攻撃チーム３：ユーザの攻撃ポイントの最大値の３０％を消費して、ユーザが保有す
る戦士カードの中から編成した攻撃チーム

（５−２）発見ユーザと恐竜キャラクタとのバトル（図１０）
図９のウェブページＰ３においてユーザＫＮＭの攻撃チームが選択操作されると、図１
０のＰ４に示すようにウェブページが更新される。すなわち、選択された攻撃チームに含
まれる戦士カードを使用してユーザＫＮＭが恐竜キャラクタＤＣ１との間でバトルを実行
するためのウェブページに切り替わる。
ウェブページＰ４は、ユーザＫＮＭがバトルで使用する複数枚の戦士カードからなる攻
撃チームＴＭの画像と、バトル相手の恐竜キャラクタＤＣ１の画像と、恐竜キャラクタＤ
Ｃ１のＨＰ(Hit Point)を示すＨＰゲージと、メニューｍ２０（「攻撃する」）とを含む
。ＨＰは、恐竜キャラクタの体力を示す値である。ユーザＫＮＭが使用する戦士カードが
すべて倒される前に恐竜キャラクタのＨＰをゼロにできれば、ユーザＫＮＭがバトルに勝
利して恐竜キャラクタＤＣ１を撃破したことを意味し、ユーザＫＮＭが使用する戦士カー
ドがすべて倒された時点で恐竜キャラクタのＨＰがゼロになっていなければ、ユーザＫＮ
Ｍがバトルで敗北したことを意味する。

ウェブページＰ４においてメニューｍ２０が選択操作されると、Ｐ５に示すようにウェ
ブページが更新される。ウェブページＰ５では、ウェブページＰ４と比べて、ユーザＫＮ
Ｍがバトルに使用する戦士カードによって恐竜キャラクタＤＣ１に対する攻撃が行われ、
その結果、恐竜キャラクタのＨＰが低下した場合が示されている。なお、メニューｍ２０
が選択操作される度にバトル相手の恐竜キャラクタから戦士カードに対して攻撃が加えら
れる。
ウェブページＰ６に示すように、恐竜キャラクタＤＣ１のＨＰがゼロに達した時点で攻
撃チーム内のいずれかの戦士カードが倒されずに残っていれば、ユーザＫＮＭがバトルに
勝利し、恐竜キャラクタＤＣ１が撃破されたことになる。

他方、ウェブページＰ７に示すように、恐竜キャラクタＤＣ１のＨＰがゼロに達する前
にすべての戦士カードが倒されると、ユーザＫＮＭがバトルに敗北したことになる。ウェ
ブページＰ７では、ユーザＫＮＭとのバトルによって恐竜キャラクタＤＣ１が怯んだ状態
となっていることが通知される。恐竜キャラクタが怯んだ状態となっている期間が、追撃
レベルが上昇可能な追撃期間である。ウェブページＰ７の例では、追撃期間が８分である
こと（「復活まで、あと８分！」）と表示されている。この追撃期間内に、恐竜キャラク
タに対して攻撃が行われた場合には、通常よりも多くのダメージを恐竜キャラクタに与え
られるように構成されている。また、恐竜キャラクタＤＣ１の消滅時刻までの時間(ウェ
ブページＰ７の例では、２０分)も表示されている。ウェブページＰ７が表示される時点
では、支援ユーザが１度もバトルを実行していないため、追撃レベルが「０」と表示され
ている。
ウェブページ７には、他のユーザに対して支援要請を行うためのメニューｍ２１（「支
援要請する」）と、再度自ら攻撃を行うためのメニューｍ２２（「もう一度攻撃する」）
とが表示される。例えば、図９のウェブページＰ３において攻撃チーム３を選択した場合
等、少ない攻撃ポイントを消費してウェブページＰ４，Ｐ５での攻撃を行った場合には、
ユーザＫＮＭの攻撃ポイントが十分に残っている場合がある。その場合には、ユーザＫＮ
Ｍは、メニューｍ２２を選択して直ちに恐竜キャラクタＤＣ１と再度バトルを行うことが
できる。
なお、ウェブページＰ７では、メニューｍ２１及びメニューｍ２２を設けた例について
説明したが、これに限られない。ユーザＫＮＭが敗北した場合に、自動的に他のユーザに
支援要請が行われるようにしてもよい。その場合には、ウェブページＰ７には、ユーザＫ
ＮＭが敗北したため支援要請が行われたことを通知するテキストが表示される。

（５−３）発見ユーザによる支援要請（図１１）
図１１のウェブページＰ７（図１０のウェブページＰ７と同じ）において、メニューｍ
２１（「支援要請する」）が選択操作されると、Ｐ８に示すようにウェブページが更新さ
れて、ユーザＫＮＭの支援要請が受け付けられたことが通知される。
なお、図９〜１１に関連付けて、発見ユーザが恐竜キャラクタを撃破できなかったとき
に、発見ユーザが他のユーザに対して支援要請を行う場合について説明したが、これに限
られない。発見ユーザは、自ら恐竜キャラクタとのバトルを行わずに支援要請を行うこと
ができるようにしてもよい。その場合には、図９のウェブページＰ２において、支援要請
を行うためのメニューを設けるようにすればよく、当該メニューの選択操作に応じて、ユ
ーザＫＮＭの支援要請が受け付けられる。

（５−４）１番目の支援ユーザと恐竜キャラクタとのバトル（図１２）
図１２に示す例では、１番目の支援ユーザがユーザＡＢＣである場合を例にしている。
ユーザＫＮＭによる支援要請が受け付けられると、その支援要請を例えばクエストを実
行中の他のユーザが閲覧することができる仕組みとなっている。図１２のウェブページＰ
９は、ユーザＡＢＣがクエストを実行中に表示されるウェブページであり、ユーザＫＮＭ
からの支援要請を受諾するか否かを選択するためのメニューｍ３１（「受諾する」）及び
メニューｍ３２（「受諾しない」）が表示されている。好ましくは、ウェブページＰ９で
は、支援対象のバトルについての情報として、バトル相手の恐竜キャラクタ及び残ＨＰの
データ、恐竜キャラクタの消滅時刻までの残り時間（２０分）、追撃終了時刻までの残り
時間（８分）、及び現在の追撃レベル（０）の例が表示されている。

ウェブページＰ９においてメニューｍ３１（「受諾する」）が選択操作されると、図９
のウェブページＰ３に示したのと同様に攻撃チームを選択するためのウェブページ（図示
せず）が表示され、ユーザＡＢＣと恐竜キャラクタＤＣ１とのバトルが開始される。恐竜
キャラクタＤＣ１のＨＰゲージは、図１０のウェブページＰ７で表示されているものと同
じ値となっている。バトルが開始された後のウェブページの表示の変化は、発見ユーザと
恐竜キャラクタＤＣ１とのバトルと同様であるが、ウェブページＰ１０では、追撃レベル
が０→１に上昇して表示される。つまり、支援ユーザＡＢＣによるバトルの開始によって
、支援ユーザの数が０→１と変化したため、追撃レベルが０→１に上昇している。

図１２では、発見ユーザＫＮＭと同様に、１番目の支援ユーザＡＢＣもバトルに敗北し
た場合の表示例がウェブページＰ１１に示されている。ウェブページＰ１１に示すように
、恐竜キャラクタＤＣ１のＨＰがゼロに達する前にすべての戦士カードが倒されると、ユ
ーザＡＢＣがバトルに敗北したことになる。ウェブページＰ１１では、ユーザＡＢＣとの
バトルによって恐竜キャラクタＤＣ１が怯んだ状態となっていることが通知される。ウェ
ブページＰ１１の例では、追撃期間が３分であること（「復活まで、あと３分！」）と表
示されている。この追撃期間内に、恐竜キャラクタに対して攻撃が行われた場合には、通
常よりも多くのダメージを恐竜キャラクタに与えられるように構成されている。また、恐
竜キャラクタＤＣ１の消滅時刻までの時間(ウェブページＰ１１の例では、１５分)も表示
されている。ウェブページＰ１１が表示される時点では、支援ユーザが１人であるため、
追撃レベルが「１」と表示されている。
ウェブページＰ１１には、再度自ら攻撃を行うためのメニューｍ２２（「もう一度攻撃
する」）が表示される。ユーザＡＢＣの攻撃ポイントが十分に残っている場合には、ユー
ザＡＢＣは、メニューｍ２２を選択して直ちに恐竜キャラクタＤＣ１と再度バトルを行う
ことができる。

（５−５）２番目の支援ユーザと恐竜キャラクタとのバトル（図１３）
図１３に示す例では、２番目の支援ユーザがユーザＱＲＳである場合を例にしている。
２番目の支援ユーザは、発見ユーザによる支援要請を２番目に受諾したユーザである。
図１３のウェブページＰ１２は、ユーザＱＲＳがクエストを実行中に表示されるウェブ
ページであり、ユーザＫＮＭからの支援要請を受諾するか否かを選択するためのメニュー
ｍ３１（「受諾する」）及びメニューｍ３２（「受諾しない」）が表示されている。好ま
しくは、ウェブページＰ１２では、支援対象のバトルについての情報として、バトル相手
の恐竜キャラクタ及び残ＨＰのデータ、恐竜キャラクタの消滅時刻までの残り時間（１５
分）、追撃終了時刻までの残り時間（３分）、及び現在の追撃レベル（１）の例が表示さ
れている。

ウェブページＰ１２においてメニューｍ３１（「受諾する」）が選択操作されると、図
９のウェブページＰ３に示したのと同様に攻撃チームを選択するためのウェブページ（図
示せず）が表示され、ユーザＱＲＳと恐竜キャラクタＤＣ１とのバトルが開始される。恐
竜キャラクタＤＣ１のＨＰゲージは、図１２のウェブページＰ１１で表示されているもの
と同じ値となっている。バトルが開始された後のウェブページの表示の変化は、１番目の
支援ユーザと恐竜キャラクタＤＣ１とのバトルと同様であるが、ウェブページＰ１３では
、追撃レベルが１→２に上昇して表示される。つまり、支援ユーザＱＲＳによるバトルの
開始によって、支援ユーザの数が１→２と変化したため、追撃レベルが１→２に上昇して
いる。

図１３では、２番目の支援ユーザＱＲＳがバトルに勝利した場合の表示例がウェブペー
ジＰ１４に示されている。ウェブページＰ１４に示すように、恐竜キャラクタＤＣ１のＨ
Ｐがゼロに達した時点で攻撃チーム内のいずれかの戦士カードが倒されずに残っていれば
、ユーザＱＲＳがバトルに勝利し、恐竜キャラクタＤＣ１が撃破されたことになる。

（５−６）バトルに参加しているユーザ間でのメッセージの送受信（図１４）
「バトルに参加しているユーザ」とは、発見ユーザと支援ユーザを意味する。
本実施形態のゲームでは、恐竜キャラクタに遭遇してからその恐竜キャラクタが撃破さ
れるか、消滅するまでの間（つまり、恐竜キャラクタとのバトルが行われている間）、そ
のバトルに参加しているユーザ間でメッセージの送信及び受信が可能となるように構成さ
れている。図１４では、発見ユーザＫＮＭと１番目の支援ユーザＡＢＣとの間で、メッセ
ージの送信及び受信が行われる場合が例示されている。

図１４のウェブページＰ１５に示すように、例えばクエストを実行中のユーザＫＮＭ向
けのウェブページ上では、特定のバトルに参加しているユーザ（発見ユーザと支援ユーザ
）のリストが表示される。発見ユーザであるユーザＫＮＭ向けのリストには、支援ユーザ
であるユーザＡＢＣ，ユーザＱＲＳが選択操作可能に表示される。ウェブページＰ１５に
おいて例えばユーザＡＢＣが選択操作されると、Ｐ１６に示すようにウェブページが更新
される。ウェブページＰ１６には、選択されたユーザＡＢＣ宛てのメッセージを入力する
ためのテキストボックスｂ１とメニューｍ４０（「送信」）が表示されている。

ウェブページＰ１６においてユーザＫＮＭがメッセージをテキストボックスｂ１に入力
した状態でメニューｍ４０が選択操作されると、メッセージがゲームサーバ２０へ送信さ
れる。メッセージがゲームサーバ２０に正しく受信されると、そのメッセージがゲームサ
ーバ２０に受け付けられる。
ユーザＫＮＭからのメッセージが受け付けられた後、例えばクエストを実行中のユーザ
ＡＢＣ向けのウェブページが更新されると、更新後のウェブページには、Ｐ１７に示すよ
うにユーザＫＮＭからのメッセージが表示される。

（６）ゲーム制御装置における各処理の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置における各処理につ
いて説明する。
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装
置が構成されている。以下では、上述したデジタルカードゲームが適用される場合を例と
して、本実施形態のゲーム制御装置で実現される機能について、図１５を参照して説明す
る。図１５は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための
機能ブロック図である。なお、図１５の機能ブロック図中、登録手段５１及び通信手段５
６は、必ずしも必須の構成要素ではない。

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

ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含ま
れていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後
、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要
求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、その
ユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを
通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、ユーザＩＤに対応するユーザデータを生成し、ユー
ザデータベース３１に格納する。登録が完了すると、ユーザは、本実施形態のゲームを実
行することが可能となる。

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

ゲーム実行手段５２は、ユーザによるゲームを実行する機能を備える。
ゲーム実行手段５２の機能は、例えば、通信端末１０に表示するウェブページを、通信
端末１０からの要求に応じて逐次更新させることによって、ゲーム上のバトルを実行する
ようにしてもよい。この場合、ゲーム実行手段５２の機能を実現するために、ゲームサー
バ２０のＣＰＵ２１は、通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリ
クエストに応じてゲーム上の所定の処理を行い、ゲームの実行結果としてのＨＴＭＬデー
タを含むＨＴＴＰレスポンスを通信端末１０へ返信する。

［クエスト処理］
実行対象のゲームの内容が例えば図９に関連付けて説明したクエストである場合、ゲー
ムサーバ２０のＣＰＵ２１は、ユーザによるメニューｍ５（「探索する」）の選択操作結
果を含むＨＴＴＰリクエストを受信すると、処理対象のユーザの進行度、体力ポイント、
及び経験値を更新する処理を行う。ＣＰＵ２１は、ユーザの進行度、体力ポイント、及び
経験値のデータを、クエストの実行開始時（メニューｍ１の選択時）にデータベースサー
バ３０からＲＡＭ２３に転送し、クエスト中はＲＡＭ２３内のデータに対して更新処理を
行い、クエスト終了時に、ＲＡＭ２３内の更新後のデータをデータベースサーバ３０内の
データに上書きするようにしてもよい。
メニューｍ５の選択操作に応じてランダムなタイミングで、あるいは、所定数のエリア
のクエストが完了すると、ＣＰＵ２１は、ユーザを恐竜キャラクタに遭遇させることを決
定する。このとき、ＣＰＵ２１は、恐竜キャラクタデータにアクセスして遭遇対象（つま
りバトル相手）となるいずれかの恐竜キャラクタを例えばランダムに選択する。

［バトル処理］
ゲーム実行手段５２は、恐竜キャラクタとのバトル処理において、特定のバトル（イベ
ント）の発見ユーザ及び支援ユーザ（イベントに対応付けられたユーザ）の入力情報に基
づいて、当該バトル内の処理を実行する機能を備える。本実施形態では、入力情報は、ユ
ーザの選択操作結果を含むＨＴＴＰリクエストである。

バトル処理におけるゲーム実行手段５２の機能は、例えば以下のようにして実現するこ
とができる。ゲームサーバ２０のＣＰＵ２１は先ず、実行対象のゲームの内容が例えば図
１０に関連付けて説明した恐竜キャラクタとのバトルである場合、選択した恐竜キャラク
タとのＨＰを恐竜キャラクタデータから読み出してＲＡＭ２３に記憶させるとともに、読
み出したデータに基づいてＨＴＭＬデータを生成する。

バトルの開始前に、ＣＰＵ２１は、ユーザによる攻撃チームの選択操作に応じて、ユー
ザが保有する戦士カードの中からバトルで使用される戦士カードを選択する。
例えば、上述した攻撃チーム１が選択された場合には、ＣＰＵ２１は、ユーザの攻撃ポ
イントの最大値の１００％を消費してユーザの保有カードの中から戦士カードを選択する
。このとき、ＣＰＵ２１は、例えば攻撃力の高い戦士カードから順に選択するとともにポ
イント消費量を積算していき、その積算値が攻撃ポイントの最大値の１００％を超えない
範囲で最大枚数の戦士カードを選択する。戦士カードを選択した後は、ＣＰＵ２１は、ユ
ーザの現在の攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを
算出し、ユーザデータに記憶する。
上述した攻撃チーム２が選択された場合には、ＣＰＵ２１は、ユーザの攻撃ポイントの
最大値の６０％を消費してユーザの保有カードの中から戦士カードを選択する。このとき
、ＣＰＵ２１は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費
量を積算していき、その積算値が攻撃ポイントの最大値の６０％を超えない範囲で最大枚
数の戦士カードを選択する。戦士カードを選択した後は、ＣＰＵ２１は、ユーザの現在の
攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユー
ザデータに記憶する。
上述した攻撃チーム３が選択された場合には、ＣＰＵ２１は、ユーザの攻撃ポイントの
最大値の３０％を消費してユーザの保有カードの中から戦士カードを選択する。このとき
、ＣＰＵ２１は、例えば攻撃力の高い戦士カードから順に選択するとともにポイント消費
量を積算していき、その積算値が攻撃ポイントの最大値の３０％を超えない範囲で最大枚
数の戦士カードを選択する。戦士カードを選択した後は、ＣＰＵ２１は、ユーザの現在の
攻撃ポイントからポイント消費量の積算値を減算して新たな攻撃ポイントを算出し、ユー
ザデータに記憶する。

ＣＰＵ２１は、バトル相手の恐竜キャラクタのデータを、バトル管理データに新たに書
き込む。このとき、恐竜キャラクタのデータのＨＰの初期値がランダムに決定される。例
えば、恐竜キャラクタデータにおいて恐竜キャラクタＤＣ１のＨＰが１５００〜２０００
の範囲として設定されているが、実際のバトル処理を行うときに使用されるＨＰの初期値
として、１５００〜２０００の範囲の中からランダムに１つの値が決定される。

ＣＰＵ２１は、出現中の恐竜キャラクタのデータをバトル管理データから読み出し、バ
トルで使用される戦士カードのデータをユーザデータから読み出して、ＲＡＭ２３に記憶
させ、以下のバトル処理を実行する。
具体的には、恐竜キャラクタとのバトルにおいて例えばメニューｍ２０（「攻撃する」
）が選択操作され、ユーザが戦士カードを使って恐竜キャラクタを攻撃するとき（例えば
図１０のウェブページＰ４，Ｐ５等）には、ＣＰＵ２１は、使用される攻撃チームを構成
する戦士カードの攻撃力の総和に応じて恐竜キャラクタのＨＰを低減させる処理を行う。
なお、バトル中に倒された戦士カードの攻撃力については、攻撃力の総和の算出対象とは
ならない。以下、メニューｍ２０（「攻撃する」）に対する操作を「攻撃操作」という。
例えば、攻撃チームの攻撃力の総和をＰａとし、追撃レベルに応じて決定される係数を
ｋとすると、１回の攻撃操作によって、恐竜キャラクタのＨＰに対して行われる演算は、
例えば以下の式（１）に従って行われるようにしてもよい。更新されたＨＰの値は、バト
ル実行中に逐次ＲＡＭ２３に上書きされる。

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

ここで、係数ｋは、追撃レベルが上昇するほど増加する値である。一例を挙げれば、
・追撃レベルが０のときに、ｋ＝１．０
・追撃レベルが１のときに、ｋ＝１．２
・追撃レベルが２のときに、ｋ＝１．４
・追撃レベルが３のときに、ｋ＝１．６
などとテーブル形式で規定してもよい。
また、追撃レベルをＬとしたときに、ｋ＝（１＋Ｌ）と演算式によって求めるようにし
てもよい。いずれの場合も、追撃レベルが上昇するほど、つまり支援ユーザの数が増加す
るほど、ユーザの攻撃チームによる攻撃によって、より多くのダメージ（ＨＰの低下量）
が恐竜キャラクタに与えられるような仕組みとなっている。

また、攻撃操作に応じてバトル相手の恐竜キャラクタから攻撃チームに対して、一定の
、あるいはランダムな値の攻撃力にて攻撃が加えられる。恐竜キャラクタの攻撃力は、Ｈ
Ｐに概ね比例した値としてもよいし、一定の、あるいはランダムな値であってもよい。Ｃ
ＰＵ２１は、例えば、恐竜キャラクタから攻撃チームに対して加える攻撃力、あるいはそ
の攻撃力の積算値（複数回の攻撃操作に伴う攻撃力の積算値）に応じて、ユーザの攻撃チ
ームのうち倒される戦士カードの枚数を決定する。倒される戦士カードの枚数は、例えば
、戦士カードに含まれる戦士カードの防御力の総和が大きいほど少なくしてもよい。
ＣＰＵ２１は、攻撃チームに含まれる戦士カードがすべて倒され、かつ恐竜キャラクタ
のＨＰがゼロになっていない場合には、ユーザの敗北であると判断する。他方、ＣＰＵ２
１は、攻撃チームに含まれる少なくとも１枚の戦士カードが倒されずに残っており、かつ
恐竜キャラクタのＨＰがゼロになった場合には、ユーザの勝利であると判断する。

攻撃操作による恐竜キャラクタのＨＰの更新は、上述した式（１）に限られない。例え
ば、上記式（１）におけるＰａは戦士カードの攻撃力ではなく、所定の範囲の中から攻撃
操作に応じてランダムに決定される数値としても良い。その場合も、追撃レベルが上昇す
ればするほど恐竜キャラクタのＨＰの低下量が大きくなるように設定する。

対応付け手段５３は、ユーザの入力情報に基づいて、当該ユーザを支援ユーザとして特
定のバトル（イベント）に対応付ける機能を備える。
対応付け手段５３の機能は、以下のようにして実現することができる。ゲームサーバ２
０のＣＰＵ２１は、発見ユーザからの支援要請を受け付けると、例えばＲＡＭ２３内に、
発見ユーザのユーザＩＤと対応付けて支援要請フラグをセットする。発見ユーザ以外のユ
ーザであって、かつクエストを実行中のユーザの通信端末１０からＨＴＴＰリクエストを
受信した場合、ＣＰＵ２１は、発見ユーザと対応付けられた支援要請フラグがセットされ
ているか否かを判定し、セットされている場合には、発見ユーザからの支援要請を受諾す
るか否かを問い合わせるためのメニューを含むＨＴＭＬデータを生成して、ＨＴＴＰリク
エストに対する返信を行う。それによって、発見ユーザ以外のユーザであって、かつクエ
ストを実行中のユーザの通信端末１０には、例えば図１２のＰ９に例示したウェブページ
が表示される。この問い合わせに対して、支援要請を受諾することを含むＨＴＴＰリクエ
ストを受信した場合には、ＣＰＵ２１は、ＨＴＴＰリクエストの送信元の通信端末１０の
ユーザを支援ユーザとして、対象となるバトルに対応付ける。この対応付けは、具体的に
は、後述するように、対象となるバトルＩＤに対応付けて支援ユーザのユーザＩＤがバト
ル管理データに書き込まれることによって行われる。

取得手段５４は、特定のバトルの支援ユーザ（イベントに対応付けられたユーザ）の数
に関する情報として、追撃レベルの情報を取得する機能を備える。本実施形態では、「特
定のバトルの支援ユーザの数」は、特定のバトルＩＤのバトルにおいて、重複しないユー
ザＩＤを備えた支援ユーザの数であり、追撃レベルに相当する。
取得手段５４の機能を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザが恐
竜キャラクタに遭遇した時点、発見ユーザ及び支援ユーザと恐竜キャラクタのバトルが開
始及び終了する時点で、バトル管理データを更新する処理を行う。具体的には、以下のと
おりである。

ＣＰＵ２１は、ユーザが恐竜キャラクタに遭遇した時点で、バトルＩＤを生成してバト
ル管理データに書き込む。ＣＰＵ２１は、バトル相手の恐竜キャラクタを恐竜キャラクタ
データから選択すると、その恐竜キャラクタのキャラクタＩＤをバトルＩＤと対応付けて
バトル管理データに書き込む。ＣＰＵ２１は、消滅時刻として例えばユーザが恐竜キャラ
クタに遭遇した時点から起算して所定時間後（例えば３０分後）に設定して、バトル管理
データに書き込む。
ＣＰＵ２１は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが開始する
時点で、発見ユーザ及び支援ユーザの各々のユーザＩＤをバトルＩＤと対応付けてバトル
管理データに書き込む。

ＣＰＵ２１は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが開始する
時点で、発見ユーザ及び支援ユーザの各々のユーザＩＤと対応付けて、追撃レベルをバト
ル管理データに書き込む。このとき、ＣＰＵ２１は、発見ユーザ（図８の例では、ユーザ
ＫＮＭ）に対応する追撃レベルを「０」とし、１番目の支援ユーザ（図８の例では、ユー
ザＡＢＣ）に対応する追撃レベルを「１」とする。ＣＰＵ２１は、Ｎ番目（Ｎ：２以上の
整数）の支援ユーザに対応する追撃レベルは決定するに当たって、Ｎ番目の支援ユーザの
ユーザＩＤと、既に書き込み済みの発見ユーザ及び１〜Ｎ−１番目の支援ユーザの各々の
ユーザＩＤとを比較する。その結果、一致するユーザＩＤが存在する場合には、ＣＰＵ２
１は、Ｎ番目の支援ユーザに対応する追撃レベルを、Ｎ−１番目の支援ユーザに対応する
追撃レベルと同一とする。他方、一致するユーザＩＤが存在しない場合には、ＣＰＵ２１
は、Ｎ番目の支援ユーザに対応する追撃レベルを、Ｎ−１番目の支援ユーザに対応する追
撃レベルに１加えた値とする。このような算出方法により、特定のバトルＩＤのバトルで
は、追撃レベルは、重複しないユーザＩＤを備えた支援ユーザの数と同一となる。

ＣＰＵ２１は、発見ユーザ及び支援ユーザの各々と恐竜キャラクタのバトルが終了する
時点で、ＲＡＭ２３内のデータを基に、発見ユーザ及び支援ユーザの各々のユーザＩＤと
対応付けて、恐竜キャラクタのＨＰ低下量と残ＨＰをバトル管理データに書き込む。ＣＰ
Ｕ２１は、バトル相手の恐竜キャラクタが撃破されたか否か（つまり、ＨＰがゼロになっ
たか否か）に応じて、撃破フラグをバトル管理データに書き込む。
また、ＣＰＵ２１は、恐竜キャラクタが撃破された場合（つまり、ＨＰの値がゼロにな
った場合）には、発見ユーザ及び支援ユーザの各々のユーザデータの恐竜撃破数を１だけ
増加させる。

ＣＰＵ２１は、追撃レベルが上昇可能な追撃期間の終期として追撃終了時刻を設定して
、バトル管理データに書き込む。追撃終了時刻の設定時刻は、特に限定されるものではな
いが、例えば、ユーザが恐竜キャラクタに遭遇した時点から起算して所定時間後（例えば
２０分後）の時刻であってもよい。また、後に変形例で述べるように、追撃終了時刻の設
定時刻は、支援ユーザのバトル実行状況に応じて設定されてもよい。
なお、ＣＰＵ２１は、現在時刻が追撃終了時刻に達した場合には、追撃レベルとしてゼ
ロを書き込む。

特典付与手段５５は、特定のバトル（イベント）に対応付けられた発見ユーザ及び支援
ユーザのバトル内の処理の実行によって、当該ユーザに対して、取得手段５４によって取
得された支援ユーザの数に関する情報、つまり追撃レベルに応じた特典を付与する機能を
備える。本実施形態では、「バトル内の処理の実行」は、例えば攻撃操作の実行に相当す
る。
追撃レベルに応じた特典の一例は、特定のバトルにおいて、発見ユーザ及び支援ユーザ
の各々に対して、各ユーザが恐竜キャラクタに与えたダメージ（つまり、ＨＰ低下量）に
応じた特典であってもよい。式（１）により示したように、ＨＰ低下量は、Ｐａ×ｋ（Ｐ
ａ：攻撃チームの攻撃力の総和、ｋ：追撃レベルに応じて増加する係数）によって定まる
ため、追撃レベルが上昇するほど多くのダメージを恐竜キャラクタに与えることができ、
より大きい特典をユーザが得ることができる。
特典は、例えばゲーム上の特典ポイントとして付与することができる。特典ポイントは
、その大きさに応じて例えば体力ポイントやゲーム上の様々なアイテムと交換可能であっ
てもよい。

特典付与手段５５の機能は、以下のようにして実現することができる。ゲームサーバ２
０のＣＰＵ２１は、例えばバトルが終了したタイミングで、バトル管理データにアクセス
し、発見ユーザ及び支援ユーザの各々のＨＰ低下量を読み出す。次いでＣＰＵ２１は、読
み出したＨＰ低下量に基づいて、発見ユーザ及び支援ユーザの各々に付与すべき特典ポイ
ントを算出する。特典ポイントを算出するに当たって、ＣＰＵ２１は、ＨＰ低下量と特典
ポイントの関係を記述したＲＯＭ２２内のデータ（図示せず）を参照してもよいし、ＨＰ
低下量に対して所定の演算式を当てはめて特典ポイントを算出する。いずれの場合でも、
ＨＰ低下量が大きいほど特典ポイントが大きくなるように設定される。
なお、ユーザに特典ポイントを付与するタイミングは、適宜設定することができる。Ｃ
ＰＵ２１は、バトルが終了する都度に、算出した特典ポイントをユーザに付与してもよい
し、恐竜キャラクタとのバトルの結果が決定するか、あるいは恐竜キャラクタが消滅した
後に、一括して（つまり、それまで算出した特典ポイントを積算して）ユーザに付与して
もよい。なお、ユーザへの特典ポイントの付与は、例えばユーザデータに特典ポイントを
記憶させることであってもよい。特典ポイントがユーザに付与された場合には、その都度
ユーザに通知することが好ましい。

通信手段５６は、ユーザ間でのメッセージの送受信を行う機能を備える。
通信手段５６の機能は、例えば、図１４に示したユーザＫＮＭとユーザＡＢＣ間のメッ
セージの送受信を例にすると、以下のようにして実現できる。ゲームサーバ２０のＣＰＵ
２１は、ユーザＫＮＭの通信端末１０から、入力されたメッセージとその送信先のユーザ
（この場合、ユーザＡＢＣ）の情報を含むＨＴＴＰリクエストを受信すると、メッセージ
とその送信先のユーザの情報を一時的に記憶する。次いでＣＰＵ２１は、ユーザＡＢＣの
通信端末１０からクエストについてのＨＴＴＰリクエスト（例えば、図９のメニューｍ１
又はｍ５の選択操作結果を含むＨＴＴＰリクエスト）を受信すると、そのＨＴＴＰリクエ
ストに応じた実行結果とともに、一時的に記憶しておいたユーザＫＮＭからのメッセージ
を含むようにしてＨＴＭＬデータを生成して、ユーザＡＢＣの通信端末１０へ送信する。
それによって、ユーザＡＢＣの通信端末１０に、ユーザＫＮＭからのメッセージが表示さ
れる。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について
、図１６Ａ及び図１６Ｂのシーケンスチャートを参照して説明する。図１６Ａ及び図１６
Ｂは、本実施形態のゲーム制御装置によって行われる、本実施形態のゲームのバトル処理
を示している。図１６Ａ及び図１６Ｂでは、図１１〜１３に記載された各ウェブページが
表示されるタイミングを符号により示している。なお、図１６Ａ及び図１６Ｂでは、図９
〜１３で示したように、発見ユーザがユーザＫＮＭであり、１番目の支援ユーザがユーザ
ＡＢＣ、２番目の支援ユーザがユーザＱＲＳである場合を例として示している。

図１６Ａでは先ず、ユーザＫＮＭが恐竜キャラクタＤＣ１に遭遇し、バトル処理が行わ
れることが想定されている（ステップＳ１００）。このバトル処理では、ゲームサーバ２
０のＣＰＵ２１は、ユーザＫＮＭによる攻撃操作結果を含むＨＴＴＰリクエストを受信す
ると、例えば上記式（１）に従って、ユーザＫＮＭによって予め選択された攻撃チームを
構成する戦士カードの攻撃力の総和に応じて恐竜キャラクタＤＣ１のＨＰを低減させる処
理を行う。また、ＣＰＵ２１は、攻撃操作に応じてバトル相手の恐竜キャラクタＤＣ１か
ら攻撃チームに対して、一定の、あるいはランダムな値の攻撃力にて攻撃を加える処理を
行う。例えば、ＣＰＵ２１は、恐竜キャラクタＤＣ１から攻撃チームに対して加える攻撃
力を例えばランダムに決定し、その攻撃力あるいはその攻撃力の積算値（複数回の攻撃操
作に伴う攻撃力の積算値）に応じて、ユーザの攻撃チームのうち倒される戦士カードの枚
数を決定する。

バトル処理が終了すると、ＣＰＵ２１は、バトル管理データを更新する。具体的には、
ＣＰＵ２１は、図８に例示したバトル管理データのユーザＫＮＭ（ユーザＩＤ：００００
０１）に対応付けて記載されているように、ＨＰ低下量、残ＨＰ、追撃終了時刻、撃破フ
ラグの値を書き込むことによってバトル管理データを更新する（ステップＳ１１０）。こ
こでは、発見ユーザであるユーザＫＮＭがバトルに敗北した場合が想定されており、撃破
フラグには「０」が書き込まれる。
ユーザＫＮＭが敗北した後、支援要請を行うためのメニューの選択操作に応じて、ユー
ザＫＮＭの通信端末１０は、支援要請を行うためのメニューの選択操作結果を含むＨＴＴ
Ｐをゲームサーバ２０へ送信する（ステップＳ１２０）。ゲームサーバ２０は、ユーザＫ
ＮＭからの支援要請を受け付けると、支援要請を受け付けたことを示すテキストを含むＨ
ＴＭＬデータを生成して、ユーザＫＮＭの通信端末１０へ送信する（ステップＳ１３０）
。次いで、ＣＰＵ２１は、例えばＲＡＭ２３内に、発見ユーザであるユーザＫＮＭのユー
ザＩＤと対応付けて支援要請フラグをセットする（ステップＳ１４０）。

発見ユーザ（この例では、ユーザＫＮＭ）以外のユーザであって、かつクエストを実行
中の他のユーザの通信端末１０からＨＴＴＰリクエストを受信した場合、ＣＰＵ２１は、
発見ユーザと対応付けられた支援要請フラグがセットされているか否かを判定し、セット
されている場合には、発見ユーザからの支援要請を受諾するか否かを問い合わせるための
メニューを含むＨＴＭＬデータを生成して、ＨＴＴＰリクエストに対する返信を行う（ス
テップＳ１５０）。この問い合わせに対して、支援要請を受諾することを含むＨＴＴＰリ
クエストを受信した場合には、ＣＰＵ２１は、ＨＴＴＰリクエストの送信元の通信端末１
０のユーザを支援ユーザとして、対象となるバトルに対応付ける。図１６Ａの例では、ユ
ーザＡＢＣが、ユーザＫＮＭからの支援要請を受諾するメニューを選択操作し（ステップ
Ｓ１６０：ＹＥＳ）、それによってユーザＡＢＣの通信端末１０は、その選択操作結果（
支援要請の受諾）を含むＨＴＴＰリクエストをゲームサーバ２０へ送信する（ステップＳ
１７０）。このＨＴＴＰリクエストを受信すると、ゲームサーバ２０は、バトル履歴の欄
に１番目の支援ユーザであるユーザＡＢＣのユーザＩＤを書き込み、かつ追撃レベルを「
１」と書き込むことによって、バトル管理データを更新する（ステップＳ１８０）。

その後、ユーザＡＢＣと恐竜キャラクタＤＣ１との間のバトル処理が行われる（ステッ
プＳ１９０）。ＣＰＵ２１は、ステップＳ１９０のバトル処理における恐竜キャラクタの
初期ＨＰとして、発見ユーザであるユーザＫＮＭに対応する残ＨＰをバトル管理データか
ら読み出し、ＲＡＭ２３に転送してから処理を行う。ステップＳ１９０のバトル処理の内
容は、ステップＳ１００と同様であるが、追撃レベルが「１」であるため、追撃レベルが
「０」のときよりも上記式（１）におけるｋが増加し、ユーザＡＢＣは、恐竜キャラクタ
ＤＣ１に対してより多くのダメージ（Ｐａ×ｋ）を与えやすくなっている。

ユーザＡＢＣと恐竜キャラクタＤＣ１との間のバトル処理が終了すると、ＣＰＵ２１は
、バトル管理データを更新する（ステップＳ２００）。具体的には、ＣＰＵ２１は、図８
に例示したバトル管理データのユーザＡＢＣ（ユーザＩＤ：０００３３３）に対応付けて
記載されているように、ＨＰ低下量、残ＨＰ、追撃終了時刻、撃破フラグの値を書き込む
ことによってバトル管理データを更新する。ここでは、１番目の支援ユーザであるユーザ
ＡＢＣがバトルに敗北した場合が想定されており、撃破フラグには「０」が書き込まれる
。
仮に、ユーザＡＢＣがバトルに勝利した場合には（つまり、撃破フラグ＝１の場合には
）、支援要請フラグがリセットされるが（ステップＳ２１０）、この例では、撃破フラグ
＝０であるため、支援要請フラグはリセットされない。

図１６Ｂでは、ユーザＱＲＳが、ステップＳ１５０のユーザＫＮＭからの支援要請を受
諾するメニューを選択操作し（ステップＳ２２０：ＹＥＳ）、それによってユーザＱＲＳ
の通信端末１０は、その選択操作結果（支援要請の受諾）を含むＨＴＴＰリクエストをゲ
ームサーバ２０へ送信する（ステップＳ２３０）。このＨＴＴＰリクエストを受信すると
、ゲームサーバ２０は、バトル履歴の欄に２番目の支援ユーザであるユーザＱＲＳのユー
ザＩＤを書き込み、かつ追撃レベルを「２」と書き込むことによって、バトル管理データ
を更新する（ステップＳ２４０）。

その後、ユーザＱＲＳと恐竜キャラクタＤＣ１との間のバトル処理が行われる（ステッ
プＳ２５０）。ＣＰＵ２１は、ステップＳ２５０のバトル処理における恐竜キャラクタの
初期ＨＰとして、直前の１番目の支援ユーザであるユーザＡＢＣに対応する残ＨＰをバト
ル管理データから読み出し、ＲＡＭ２３に転送してから処理を行う。ステップＳ２５０の
バトル処理の内容は、ステップＳ１９０と同様であるが、追撃レベルが「２」であるため
、追撃レベルが「１」のときよりも上記式（１）におけるｋが増加し、ユーザＱＲＳは、
恐竜キャラクタＤＣ１に対してより一層多くのダメージ（Ｐａ×ｋ）を与えやすくなって
いる。

ユーザＱＲＳと恐竜キャラクタＤＣ１との間のバトル処理が終了すると、ＣＰＵ２１は
、バトル管理データを更新する（ステップＳ２６０）。具体的には、ＣＰＵ２１は、図８
に例示したバトル管理データのユーザＱＲＳ（ユーザＩＤ：１２３４５５）に対応付けて
記載されているように、ＨＰ低下量、残ＨＰ、追撃終了時刻、撃破フラグの値を書き込む
ことによってバトル管理データを更新する。ここでは、２番目の支援ユーザであるユーザ
ＱＲＳがバトルに勝利した場合が想定されており、撃破フラグには「１」が書き込まれ、
それによって支援要請フラグがリセットされる（ステップＳ２７０）。支援要請フラグが
リセットされると、発見ユーザ（この例では、ユーザＫＮＭ）以外のユーザ向けのＨＴＭ
Ｌデータに、発見ユーザからの支援要請を受諾するか否かの問い合わせが含まれないよう
になる。

恐竜キャラクタとのバトルが終了した（つまり、恐竜キャラクタとの勝敗が決定した）
ため、ＣＰＵ２１は、特典ポイントを算出し（ステップＳ２８０）、算出したポイントを
通知するためのＨＴＭＬデータを生成して、バトルに参加したユーザ（発見ユーザＫＮＭ
、１番目の支援ユーザＡＢＣ、２番目の支援ユーザＱＲＳ）の通信端末１０へ送信する（
ステップＳ２９０）。なお、ＣＰＵ２１は、例えば、バトル管理データにアクセスし、発
見ユーザＫＮＭ、１番目の支援ユーザＡＢＣ、２番目の支援ユーザＱＲＳの各々に対応付
けられたＨＰ低下量（つまり、恐竜キャラクタＤＣ１に与えたダメージ）のデータを読み
出し、そのＨＰ低下量に応じた特典ポイントを算出する。

以上説明したように、本実施形態のゲーム制御装置では、特定のバトル（イベント）に
支援ユーザとして対応付けられるユーザの数（あるいは、バトルに参加しているユーザ数
）に応じて、そのバトルにおいて恐竜キャラクタに与えたダメージに応じた特典ポイント
（イベント内の処理の実行に伴う特典）が付与される。つまり、支援ユーザの数が多いほ
どバトルにおける攻撃操作によって恐竜キャラクタに与えるダメージが大きくなり、それ
によって多くの特典ポイントがユーザに付与されることになる。支援ユーザの数が多いほ
ど有利となるため、バトルに参加していないユーザがバトルに参加することが動機付けら
れる。言い換えれば、固定化した仲間のユーザ同士でイベント内の処理を実行するよりも
、より多くのユーザがイベントに参加することが有利となる仕組みとなっている。そのた
め、本実施形態のゲーム制御装置によれば、複数のユーザが協力して恐竜キャラクタに対
するバトルを行う場合に、コミュニケーションの程度が低いユーザ同士、あるいは今まで
コミュニケーションをとったことがないユーザ同士で協力してゲームを行うように動機付
けることができる。

上述した実施形態では、例えば図１２のウェブページＰ９、及び図１３のウェブページ
Ｐ１２に示したように、発見ユーザからの支援要請を受諾するか否かの問い合わせを表示
するウェブページにおいて、現在の追撃レベルを含むバトルについての情報を表示する好
ましい表示形態の例を示しているが、このようなバトルについての情報は表示しなくても
よい。なお、このウェブページにおいて、現在の追撃レベルを表示することで、バトルに
参加する（支援ユーザとして対応付けられる）前にユーザは、既に支援ユーザとして対応
付けられているユーザの数がわかるため、これからバトルに参加しようとするときに、ユ
ーザの数に応じた特典ポイントの大小を推定できるようになる。そのため、ユーザがバト
ルに参加することに対する動機付けがより強く働かせることができるようになる。

この好ましい表示形態を実現するための機能ブロック図を図１７に示す。図１７の機能
ブロック図は、図１５に示したものと比較して、提示手段５７が追加された点が異なる。
提示手段５７は、ユーザを特定のバトル（イベント）の支援ユーザとして対応付けるた
めのユーザの入力を受け付けるタイミングで、取得手段５４によって取得された支援ユー
ザの数に関する情報、つまり追撃レベルの情報を、当該ユーザに提示する機能を備える。
この「ユーザの入力」は、例えば図１２のウェブページＰ９、及び図１３のウェブページ
Ｐ１２に示したように、他のユーザからの支援要請を受諾するか否かについての選択を行
うためのユーザの操作入力である。提示手段５７の機能を実現するために、ゲームサーバ
２０のＣＰＵ２１は、支援要請を含むＨＴＭＬデータを生成するに当たって、バトル管理
データの追撃レベルの値を読み出して、ＨＴＭＬデータに含めるようにする。

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

（８−１）変形例１
上述した実施形態では、支援ユーザの数を追撃レベルとしたが、単に支援ユーザの数に
よって追撃レベルを決定するのではなく、支援ユーザのうち、ある程度の攻撃ポイントを
消費して攻撃を行った支援ユーザの数を追撃レベルとしてもよい。例えば、支援ユーザが
恐竜キャラクタとのバトルを行うに当たって、攻撃チーム１（ユーザの攻撃ポイントの最
大値の１００％を消費）又は攻撃チーム２（ユーザの攻撃ポイントの最大値の６０％を消
費）を選択した支援ユーザの数を追撃レベルとしてもよい。つまり、攻撃チーム３（ユー
ザの攻撃ポイントの最大値の３０％を消費）を選択した支援ユーザは、恐竜キャラクタに
対する攻撃に積極的に関与しなかったものとして、追撃レベルを算出する上で除外する。
このような構成とすることで、積極的にバトルに参加するユーザ同士のコミュニケーシ
ョンを活性化させることができる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、追撃レベルを更新する
に当たって、支援ユーザの攻撃チームの選択結果に基づいて、バトル管理データにその支
援ユーザのユーザＩＤを書き込むか否かを決定する。あるいは、ＣＰＵ２１は、支援ユー
ザの攻撃チームの選択結果如何に関わらず、すべての支援ユーザのユーザＩＤと選択した
攻撃チームとをバトル管理データに書き込んでおき、攻撃チーム３を選択した支援ユーザ
を、追撃レベルの算出の基礎としないようにしてもよい。

（８−２）変形例２
上述した実施形態において、対応付け手段５３は、特定のバトル（イベント）の開始時
刻から所定時間が経過したときに、ユーザのバトルへの支援ユーザとしての対応付けを解
除してもよい。なお、「全ての支援ユーザとしての対応付けの解除」は、実質的に追撃レ
ベルをゼロにすることに等しい。
この構成により、バトル（イベント）に対応付けられたユーザの数に応じて特典を得ら
れるという有利な効果が持続する時間が制限されるため、限られた時間内でのユーザ間の
コミュニケーションが促進されるとともに、有利な効果が持続し過ぎることないようにゲ
ーム進行におけるユーザ間の公平性が担保される。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、例えば、発見ユーザが
恐竜キャラクタと遭遇した時刻、又は発見ユーザと恐竜キャラクタとのバトルの開始時刻
を起点として、所定時間後を追撃終了時刻として設定する。ＣＰＵ２１は、追撃終了時刻
までに支援要請を受諾したユーザを支援ユーザとして対応付け、それによって追撃レベル
を上昇させる。
また、ＣＰＵ２１は、所定時間が経過し追撃終了時刻に達した場合には、支援要請は行
わず、追撃レベルをリセットする（ゼロにする）。あるいは、ＣＰＵ２１は、所定時間が
経過し追撃終了時刻に達した場合には、追撃レベルを直ちにゼロにするのではなく、段階
的に低下させてもよい。例えば、ＣＰＵ２１は、追撃終了時刻に達してから所定時間毎に
追撃レベルを１つずつ低下させてもよいし、恐竜キャラクタと、当該バトルに支援ユーザ
として対応付けられるユーザをランダムに、又は、所定の規則(例えば、対応付けられた
順序等)に基づいて、解除しても良い。

（８−３）変形例３
上述した実施形態において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユー
ザが特定のバトル（イベント）に支援ユーザとして対応付けられ、かつ当該ユーザがＮ−
１番目にバトルに支援ユーザとして対応付けられたユーザと異なる場合に、Ｎ番目のユー
ザが対応付けられてから、又はＮ番目のユーザによる処理の実行が開始若しくは終了して
から所定時間が経過したときに、ユーザのバトルの支援ユーザとしての対応付けを解除し
てもよい。なお、「全ての支援ユーザとしての対応付けの解除」は、実質的に追撃レベル
をゼロにすることに等しい。
この構成により、バトル（イベント）に支援ユーザとして対応付けられるユーザが連続
して同一ユーザでない場合には、既に対応付けられている複数のユーザのバトルへの対応
付けは解除されず、バトルに支援ユーザとして対応付けられたユーザの数に応じて特典を
得られるという有利な効果が持続する。そのため、異なるユーザが入れ替わりバトル内の
処理を実行するように動機付けられることになり、例えばバトルに支援ユーザとして対応
付けられているユーザ間でコミュニケーションをとることが促進される。

この対応付け手段５３の機能によって実現されるバトル管理データの更新例について、
図１８を参照して説明する。図１８は、本変形例において、バトル管理データの更新例を
説明するための図である。図１８（ａ）は、特定のバトルにおいて発見ユーザ及び支援ユ
ーザの各々のバトル期間、及び追撃終了時刻の変化の一例を時間軸に沿って示しており、
図１８（ｂ）は、追撃レベルの変化の一例を時間軸に沿って示している。

図１８において、発見ユーザＵ０のバトル中における追撃レベルは初期値の「０」であ
る。ユーザＵ１が支援ユーザとして対応付けられると、追撃レベルが「１」に上昇すると
ともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時間）に設定され
る。
次に、ユーザＵ２が支援ユーザとして対応付けられると、追撃レベルが「１」から「２
」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時
間）に設定される。つまり、追撃レベルが上昇可能な追撃期間が延長される。ここで、ユ
ーザＵ２がバトルに敗北した後に再度自らバトルを行う場合を想定する。この場合には、
２番目と３番目の支援ユーザが同一であるため、追撃レベルは上昇せずに「２」のままで
あり、かつ追撃終了時刻が変更されない（＊１）。つまり、追撃期間が延長されない。

次に、ユーザＵ３が支援ユーザとして対応付けられると、追撃レベルが「２」から「３
」に上昇するとともに、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時
間）に設定される。つまり、追撃レベルが上昇可能な追撃期間がさらに延長される。
次の支援ユーザであるユーザＵ１は直前の支援ユーザであるユーザＵ３と異なるユーザ
であるため、追撃終了時刻が変更される（追撃期間が延長される）が、１番目の支援ユー
ザと同一であるため、追撃レベルは上昇せずに「３」のままである。最後に、ユーザＵ４
が支援ユーザとして対応付けられると、追撃レベルが「３」から「４」に上昇するととも
に、その対応付けの時点から追撃終了時刻が例えば１０分間（所定時間）に設定される。
つまり、追撃レベルが上昇可能な追撃期間がさらに延長される。

図１８に例示したように、本変形例では、新たに支援ユーザが対応付けられたときの追
撃期間は、その直前の支援ユーザと同一のユーザでない場合に延長してもよい。これによ
って、追撃レベルがリセットされない有利な状況を継続させることを目的として、異なる
ユーザが入れ替わり支援ユーザとなってバトルを行うように動機付けられる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、同一の支援ユーザが連
続してバトルを行う場合（例えば、図１２のメニューｍ２２が選択操作された場合）、又
は、同一のユーザが連続して支援ユーザとして対応付けられた場合には、追撃終了時刻を
変更せず、そうでない場合に追撃終了時刻を更新してバトル管理データに書き込む。更新
後の追撃終了時刻は、最新の支援ユーザが対応付けられてから、又は、その支援ユーザに
よる攻撃操作が行われたときから、若しくはその支援ユーザによるバトルが終了してから
所定時間が経過した時刻に設定される。

（８−４）変形例４
上述した変形例３において、取得手段５４によって取得されたユーザの数が多いほど、
すなわち追撃レベルが大きいほど、変形例３における所定時間を短くしてもよい。
上述した実施形態の構成では、バトル（イベント）に支援ユーザとして対応付けられて
いるユーザの数が多いほどより多くの特典が得られる状況となるが、そのような状況が長
く継続すると、ゲーム進行におけるユーザ間の公平性が担保されない場合がある。そのた
め、ユーザの数が多いほど変形例３における所定時間を短くすることで、ゲーム進行にお
けるユーザ間の公平性を担保することが好ましい。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、追撃終了時刻を更新し
てバトル管理データに書き込む場合に、追撃レベルの大きさに応じて追撃終了時刻までの
時間を設定する。追撃終了時刻までの時間を設定するに当たって、ＣＰＵ２１は、追撃レ
ベルと追撃終了時刻までの時間の予め既知の関係を参照してもよいし、追撃レベルを所定
の演算式に当てはめて追撃終了時刻までの時間を算出してもよい。

（８−５）変形例５
上述した実施形態において、ゲーム実行手段５２による特定のバトル（イベント）内の
処理の実行回数が多いほど、前記所定時間を短くしてもよい。
上述した実施形態の構成では、バトル（イベント）に支援ユーザとして対応付けられて
いるユーザの数が多いほど、つまりバトルの処理の実行回数が多くなるほど、より多くの
特典が得られる状況となるが、そのような状況が長く継続すると、ゲーム進行の公平性が
担保されない場合がある。そのため、バトルの処理の実行回数が多いほど上記所定時間を
短くすることで、ゲーム進行の公平性を担保することが好ましい。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、特定のバトルが開始さ
れてから攻撃操作結果を含むＨＴＴＰリクエストの受信回数をカウントする。そしてＣＰ
Ｕ２１は、追撃終了時刻を更新してバトル管理データに書き込む場合に、受信回数のカウ
ント値の大きさに応じて追撃終了時刻までの時間を設定する。追撃終了時刻までの時間を
設定するに当たって、ＣＰＵ２１は、受信回数のカウント値と追撃終了時刻までの時間の
予め既知の関係を参照してもよいし、受信回数のカウント値を所定の演算式に当てはめて
追撃終了時刻までの時間を算出してもよい。

（８−６）変形例６
上述した実施形態において、特典付与手段５５は、特定のバトル（イベント）の結果が
所定の条件を満たす場合に、当該バトルに対応付けられたユーザに対して、さらに特典を
付与してもよい。「所定の条件」は、本実施形態の場合、バトル相手の恐竜キャラクタを
撃破してバトルで勝利することである。
特典は、例えばゲーム上の特典ポイントとして付与することができる。特典ポイントは
、その大きさに応じて例えば体力ポイントやゲーム上の様々なアイテムと交換可能であっ
てもよい。
この構成では、バトルの結果次第でバトルに参加するユーザ（発見ユーザ及び支援ユー
ザ）に対して追加の特典が付与されるか否かが決定されるため、既にバトルに参加済みの
ユーザ間で、バトル相手の恐竜キャラクタを撃破してバトルで勝利するように、コミュニ
ケーションをとることが促進される。
本変形例における特典付与手段５５の機能は、例えば以下のようにして実現することが
できる。ゲームサーバ２０のＣＰＵ２１は、例えばバトルが終了したタイミングで、バト
ル管理データにアクセスし、撃破フラグを確認し、撃破フラグが「１」である場合には、
発見ユーザ及び支援ユーザの各々に追加の特典ポイントを付与することを決定する。特典
ポイントの量及び配分方法は、適宜決定することができる。１つのバトルについて勝利し
たときに付与される特典ポイントの量が固定である場合には、ＣＰＵ２１は、その特典ポ
イントを、発見ユーザ及び支援ユーザの各々に均等配分してもよいし、ＨＰ低下量に応じ
た比率（つまり、貢献度合い）に基づいて配分してもよい。

（８−７）変形例７
上述した変形例６において、特定のバトル（イベント）の結果が所定の条件を満たす場
合に付与される特典は、当該バトルが終了した時点において取得手段５４によって取得さ
れたユーザの数に関する情報、すなわち追撃レベルに応じた特典であってもよい。
この構成では、バトルが終了する時点までにできるだけ多くのユーザがバトルに参加す
る（対応付けられる）ことが、既にバトルに参加しているユーザにとって有利である。そ
のため、ユーザ間で、より多くのユーザがバトルに参加するよう働きかけが行われるよう
にコミュニケーションをとることが促進される。
本変形例では、ゲームサーバ２０のＣＰＵ２１は、１つのバトルについて勝利したとき
に付与される追加の特典ポイントの量を、バトル終了時点の追撃レベルによって決定する
。つまり、ＣＰＵ２１は、バトル終了時点の追撃レベルが大きいほど、特典ポイントの量
を多くする。ＣＰＵ２１は、特典ポイントを算出するに当たって、追撃レベルと特典ポイ
ントの予め既知の関係を参照してもよいし、追撃レベルを所定の演算式に当てはめて特典
ポイントを算出してもよい。ＣＰＵ２１は、算出した特典ポイントを、発見ユーザ及び支
援ユーザの各々に均等配分してもよいし、ＨＰ低下量に応じた比率（つまり、貢献度合い
）に基づいて配分してもよい。

（８−８）変形例８
上述した実施形態において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユー
ザが特定のバトル（イベント）に対応付けられ、かつ当該ユーザがＮ−１番目にバトルに
対応付けられたユーザと同一である場合に、当該ユーザのバトルへの対応付けを解除して
もよい。
この構成では、同一のユーザが連続してバトルに支援ユーザとして対応付けられた場合
には、当該ユーザのバトルへの対応付けが解除され、バトルに対応付けられたユーザの数
が低減することになる。そのため、より多くのユーザの間で入れ替わり対応付けが行われ
てバトルの処理を実行することが動機付けられ、ユーザ間でコミュニケーションをとるこ
とが促進される。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、バトル管理データにお
いて同一のユーザＩＤのユーザが連続して支援ユーザとして対応付けられた場合、そのユ
ーザＩＤのデータをバトル管理データから削除する（つまり、対応付けを解除する）。

（８−９）変形例９
上述した実施形態において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の整数）のユー
ザが特定のバトル（イベント）に対応付けられ、かつ当該ユーザがＮ−１番目までにバト
ルに対応付けられたユーザのうちいずれかのユーザと同一である場合に、当該ユーザのバ
トルへの対応付けを解除してもよい。
この構成では、既にバトルに参加済み（つまり、支援済み）のユーザが再度バトルに参
加して処理を実行した場合には、当該ユーザのバトルへの対応付けが解除され、バトルに
対応付けられたユーザの数が低減することになる。つまり、固定化した仲間のユーザ同士
で入れ替わりバトルに参加しても多くの特典を得ることができなくなるため、固定化した
仲間のユーザ同士でバトルの処理を実行することが回避される。結果として、複数のユー
ザが協力してバトルの処理を行う場合に、コミュニケーションの程度が低いユーザ同士、
あるいは今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行
うように動機付けることができる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザを新たに支援ユ
ーザとしてバトルに対応付けるときに、そのユーザのユーザＩＤと、それまでに支援ユー
ザとして既に対応付けられているユーザＩＤと順に比較する。その結果、一致するユーザ
ＩＤが存在する場合には、ＣＰＵ２１は、新たに支援ユーザとして対応付けることを許可
せず、かつ既に対応付けられている同一のユーザＩＤの対応付けを解除する。

（８−１０）変形例１０
上述した変形例２又は変形例３において、対応付け手段５３は、Ｎ番目（Ｎ：２以上の
整数）のユーザが特定のバトル（イベント）に対応付けられ、かつ当該ユーザがＮ−１番
目までにバトルに対応付けられたユーザのうちいずれかのユーザと同一である場合に、前
記所定時間を短くしてもよい。
この構成では、既にバトルに参加済み（つまり、支援済み）のユーザが再度バトルに参
加して処理を実行した場合、バトルに参加しているユーザの数に応じて特典を得られると
いう有利な効果が持続する時間が短くなる。そのため、固定化した仲間のユーザ同士で入
れ替わりバトルに参加しても多くの特典を得る機会が少なくなるため、固定化した仲間の
ユーザ同士でバトルの処理を実行することが回避される。結果として、複数のユーザが協
力してバトルの処理を行う場合に、コミュニケーションの程度が低いユーザ同士、あるい
は今までコミュニケーションをとったことがないユーザ同士で協力してゲームを行うよう
に動機付けることができる。
本変形例を実現するために、ゲームサーバ２０のＣＰＵ２１は、ユーザを新たに支援ユ
ーザとしてバトルに対応付けるときに、そのユーザのユーザＩＤと、それまでに支援ユー
ザとして既に対応付けられているユーザＩＤと順に比較する。その結果、一致するユーザ
ＩＤが存在する場合には、ＣＰＵ２１は、変形例２又は変形例３における所定時間を短く
して、追撃終了時刻を設定する。このとき、所定時間を短くする度合いは適宜予め決定し
ておくようにする。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定され
ない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更
をしてもよいのは勿論である。例えば、上記実施形態及び各変形例に記載された技術的事
項は適宜組合せて適用してもよい。
例えば、ウェブページを用いたユーザへの通知方法は、テキスト形式の視覚的情報に限
られず、音声などの聴覚的情報であってもよい。

上述した実施形態及び変形例では、カードを用いたバトルを行う場合を例として説明し
たが、これに限られない。カードでなく、例えば、ユーザのアバタ画像等の他のオブジェ
クトであってもよい。あるいは、カード等のオブジェクトを使用せずにバトル処理を行っ
てもよい。

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

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

上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３
０によって、図１５に示した各機能を実現する構成としたが、この構成に限られない。こ
れらのすべての手段を通信端末１０によって実現する構成としてもよいし、少なくとも一
部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサー
バ２０とでは実質的に同一のハードウエア構成を採るため、上記実施形態に記載したよう
にして通信端末１０によっても各機能を実現できる。図１９（ａ），（ｂ）には、本実施
形態のゲーム制御装置の各機能（図１５に示す各機能）について、通信端末１０と、ゲー
ムサーバ２０及びデータベースサーバ３０との間の分担例を示す。

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

Claims (3)

1. 複数のユーザが協力して共通の対戦相手に対するバトルを行うように構成されたゲームを進行させるサーバであって、
   複数のユーザの各々の通信端末から指示を受信する通信手段と、
   複数のユーザのうち前記対戦相手と最初にバトルを行う第１ユーザと、第１ユーザによる前記対戦相手とのバトルが終了した後に前記対戦相手とバトルを行う１又は複数の第２ユーザのいずれかの第２ユーザの通信端末から攻撃処理の実行指示を受信したときに前記攻撃処理を実行すると共に、第１ユーザと１又は複数の第２ユーザのいずれかの第２ユーザとが異なるときに、第１ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第１期間内においては、攻撃処理の実行指示を受信する度に所定の値のポイントを加算し、１又は複数の第２ユーザのいずれかの第２ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第２期間内においては、攻撃処理の実行指示を受信する度に前記所定の値よりも大きい値のポイントを加算するゲーム実行手段と、
   前記ポイントの累積値がしきい値を超えた場合に、複数のユーザのうち第１ユーザと１又は複数の第２ユーザの各々に特典を付与する特典付与手段と、
   を備えることを特徴とするサーバ。
2. 前記特典は、前記ゲーム上のアイテムに交換可能である、請求項１に記載のサーバ。
3. 複数のユーザが協力して共通の対戦相手に対するバトルを行うように構成されたゲームを進行させるサーバの制御プログラムであって、前記サーバに、
   複数のユーザの各々の通信端末から指示を受信し、
   複数のユーザのうち前記対戦相手と最初にバトルを行う第１ユーザと、第１ユーザによる前記対戦相手とのバトルが終了した後に前記対戦相手とバトルを行う１又は複数の第２ユーザのいずれかの第２ユーザの通信端末から攻撃処理の実行指示を受信したときに前記攻撃処理を実行すると共に、第１ユーザと１又は複数の第２ユーザのいずれかの第２ユーザとが異なるときに、第１ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第１期間内においては、攻撃処理の実行指示を受信する度に所定の値のポイントを加算し、１又は複数の第２ユーザのいずれかの第２ユーザによる前記対戦相手とのバトルの開始から終了までの期間である第２期間内においては、攻撃処理の実行指示を受信する度に前記所定の値よりも大きい値のポイントを加算し、
   前記ポイントの累積値がしきい値を超えた場合に、複数のユーザのうち第１ユーザと１又は複数の第２ユーザの各々に特典を付与することを実行させることを特徴とする制御プログラム。

Images