JP5939974B2 - ゲーム制御装置、プログラム、ゲームシステム - 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）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース（ユーザＤＢ）３１と、ゲームデータベース（ゲームＤＢ）３２と、メンテナンスデータベース（メンテナンスＤＢ）３３を備える。

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

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

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

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

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

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

図８は、ゲーム上のアイテムの例として、回復アイテムの情報が記述されている回復アイテムデータベースのデータ構成の一例を示す図である。図８に例示する回復アイテムデータベースは、本実施形態のゲームで用意される全ての回復アイテムの情報が記述されているデータベースである。図８に例示する回復アイテムデータベースは、回復アイテムの識別コード（図の例では、ＲＥ００１，ＲＥ００２，…）ごとに、使用したときにユーザの体力ポイントに加算する値（体力回復値）のデータを含む。また、図示しないが、使用したユーザの体力ポイントがユーザの上限値に対して所定の割合（体力回復率）で回復する回復アイテムがあってもよく、回復アイテムデータベースは体力回復率のデータを含んでもよい。

図９は、メンテナンスデータベース３３に含まれる共通制限時間テーブルの一例である。図９に示すように、共通制限時間テーブルには、共通制限時間ＩＤ毎に、開始時刻、終了時刻等が記録されている。なお、ゲームの実行を制限する理由（例えばメンテナンス）、目的（例えば新規イベントの準備）等を記録してもよい。
図１０は、メンテナンスデータベース３３に含まれるアクセス時刻テーブルの一例である。図１０に示すように、アクセス時刻テーブルには、ユーザＩＤごとに、ユーザがゲームにアクセスした時刻（アクセス時刻）が記録され、保存される。なお、共通制限時間にユーザがアクセスした場合に限ってアクセス時刻をアクセス時刻テーブルに記録してもよいし、共通制限時間であるか否かを問わず、アクセス時刻を記録してもよい。
なお、共通制限時間テーブル及びアクセス時刻テーブルを、ゲームサーバ２０のＲＡＭ２３に記憶させてもよい。

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

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

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

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

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

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

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

〔共通制限時間中、及び、共通制限時間後の処理〕
新規のイベントを導入する際や、ゲームの仕様を変更する際には、ユーザデータベース３１、ゲームデータベース３２のメンテナンスが行われる。メンテナンスを行う期間は、ユーザデータベース３１、ゲームデータベース３２を用いるゲームの機能の一部または全てが、一部のユーザ又は全ユーザにとって実行不能となる場合がある。このようなゲームの実行が一部のユーザ又は全ユーザに共通に制限される期間（共通制限時間）にユーザがゲームにアクセスした場合、ユーザの通信端末１０には、トップページＰ１が表示されずに、図１３に示すようなウェブページＰ５が表示される。ウェブページＰ５は、例えば、現在（ユーザのアクセス時刻）、ゲームが実行不能であること（「ゲームができません」）、ゲームが実行可能となる予定時刻（「終了予定：Ｘ月Ｘ日15:00」）を示すテキスト等を含む。また、ゲームの実行を制限することに対する謝罪（「ご迷惑おかけします」）や、ゲームの実行を制限する理由（「只今、メンテナンス中のため」）、目的（「新規イベント開始準備」）を示すテキストを含んでもよい。
なお、本実施形態では、共通制限時間内にゲームにアクセスしたユーザ：Ａが、共通制限時間の終了後に再びゲームにアクセスした場合、後述するように、ユーザ：Ａに対し、特典としてアイテムが付与（プレゼント）される。

ユーザ：Ａがシステムや他のユーザからゲーム上のアイテム等のプレゼントを譲り受けた場合、図１４に示すように、ユーザ：ＡのトップページＰ６には、アイテム等が譲渡(プレゼント)された事を示すメニューｍ３（「プレゼントが届いています」）が表示される。共通制限時間内にゲームにアクセスしたユーザが共通制限時間の終了後にゲームにアクセスした場合には、ユーザ：Ａがメニューｍ３の選択操作を行うと、図１４のＰ７に示すようなウェブページが表示される。ウェブページＰ７は、共通制限時間内にアクセスしたユーザに対し、システムから特典として付与されたアイテム（以下、特典アイテムという）に関する情報を表示する。特典アイテムは共通制限時間内にゲームにアクセスした全てのユーザで同一であってもよいし、後述するようにユーザのアクセス時刻に応じて特典アイテムを変更してもよい。
なお、特典アイテムをユーザ：Ａの操作によらずに付与してもよいし、ウェブページＰ７に表示されるようなメニューｍ３０（「受け取る」）をユーザ：Ａが選択操作することにより特典アイテムをユーザに付与してもよい。
また、ゲームが実行不能であったことに対する謝罪（「ご迷惑おかけしました」）を示すテキスト等を表示してもよい。
また、ユーザ：Ａが複数のプレゼントを譲り受けている場合には、ユーザ：Ａに譲渡された複数のプレゼントのリストを表示し、そのうちの１つに特典アイテムに関する情報を表示してもよい。
なお、共通制限時間内にゲームにアクセスしていないユーザでも、当該ユーザがシステムや他のユーザからプレゼントを譲り受け、その後ゲームにアクセスした場合には、メニューｍ３が表示されたトップページが表示される。この場合、ユーザがメニューｍ３の選択操作を行うと、ユーザに譲渡されたプレゼントのリストを表示するようにウェブページが更新されてもよい（図示せず）。

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

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

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

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

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

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

取得手段５３は、例えばユーザによるゲームの実行のためのアクセス時刻を取得する機能を備える。取得手段５３の機能は、例えば以下のとおり実現される。
ユーザがゲームサーバ２０にアクセスしたとき、ゲームサーバ２０のＣＰＵ２１は、ＣＰＵ２１内部のリアルタイムクロックを参照して現在時刻を取得し、現在時刻をアクセス時刻として、メンテナンスデータベース３３のアクセス時刻テーブルにユーザＩＤごとに記録する。アクセス時刻の取得は、共通制限時間に限ってもよいし、共通制限時間であるか否かを問わず、ユーザがゲームサーバ２０にアクセスする度に行ってもよい。なお、リアルタイムクロックを参照する代わりに、通信網ＮＷを経由して取得したネットワークタイムプロトコル（Network Time Protocol）や標準電波（標準周波数報時電波）を用いてアクセス時刻を取得してもよい。

制限手段５４は、所定の共通制限時間においてユーザによるゲームの実行を制限する機能を備える。制限手段５４の機能は、例えば以下のとおり実現される。
ユーザがゲームサーバ２０にアクセスしたとき、ゲームサーバ２０のＣＰＵ２１は、現在時刻を取得するとともに、メンテナンスデータベース３３の共通制限時間テーブルを参照する。現在時刻がいずれかの共通制限時間ＩＤにおける開始時刻と終了時刻との間（共通制限時間内）の時刻であれば、ＣＰＵ２１は、図１２に示すようなウェブページＰ５のＨＴＭＬデータを生成しユーザの通信端末に送信する。つまり、トップページが表示されず、ユーザのゲームの実行が制限される。一方、現在時刻がいずれの共通制限時間ＩＤにおいても共通制限時間内になければ、ＣＰＵ２１は、ユーザデータベース３１やゲームデータベース３２にアクセスし、通常のゲームを実行させる。

判定手段５５は、ユーザのアクセス時刻が前記共通制限時間に含まれるか否かを判定する機能を備える。判定手段５５の機能は、例えば以下のとおり実現される。
ＣＰＵ２１は、メンテナンスデータベース３３のアクセス時刻テーブルを参照し、ユーザＩＤに対応するアクセス時刻の情報を取得する。次に、ＣＰＵ２１は、メンテナンスデータベース３３の共通制限時間テーブルを参照し、取得したアクセス時刻がいずれかの共通制限時間ＩＤにおける開始時刻と終了時刻との間（共通制限時間内）の時刻であるか否かを判定する。例えば、図１０のアクセス時刻テーブルにおけるユーザＩＤ：０００００１に対応するユーザは、図９の共通制限時間テーブルを参照すると、共通制限時間ＩＤ：００１の開始時刻（Ｘ年Ｘ月Ｘ日14:00）と終了時刻（Ｘ年Ｘ月Ｘ日15:00）の間のアクセス時刻（Ｘ年Ｘ月Ｘ日14:05）にアクセスしているため、ユーザＩＤ：０００００１に対応するユーザのアクセス時刻が共通制限時間ＩＤ：００１の共通制限時間（メンテナンス期間）に含まれると判定される。一方、ユーザＩＤ：０００００２に対応するユーザのアクセス時刻は、いずれの共通制限時間ＩＤの開始時刻と終了時刻の間にもないため、ユーザＩＤ：０００００２に対応するユーザのアクセス時刻が共通制限時間に含まれると判定されない。

特典付与手段５６は、ユーザのアクセス時刻が共通制限時間に含まれると判定された場合に、当該ユーザに特典を付与する機能を備える。特典付与手段５６の機能は、例えば以下のとおり実現される。
上述のようにユーザのアクセス時刻が共通制限時間に含まれると判定されると、ＣＰＵ２１は、当該ユーザに、特典アイテムを付与する。特典アイテムの付与は、例えば、特典アイテムの識別コードを当該ユーザのユーザＩＤに対応するユーザデータベースに書き込むことで行うことができる。

ここで、特典アイテムは、アクセス時刻が共通制限時間に含まれるユーザに一律に付与してもよい。また、アクセス時刻が共通制限時間に含まれないユーザに対しても、一律に特典アイテムを付与してもよい。この場合、アクセス時刻が共通制限時間に含まれないユーザに対する特典アイテムよりも、アクセス時刻が共通制限時間に含まれるユーザに対する特典アイテムを多くしてもよい。例えば、全てのユーザに対して同一のオブジェクトを付与するとともに、アクセス時刻が共通制限時間に含まれるユーザに対して特典アイテムを付与してもよい。
あるいは、アクセス時刻が共通制限時間に含まれないユーザに対して付与する特典アイテムよりも有益な特典アイテムを、アクセス時刻が共通制限時間に含まれるユーザに付与してもよい。

また、ユーザのアクセス時刻に応じて特典アイテムを変更してもよい。例えば、特典アイテムが回復アイテムである場合、ＣＰＵ２１は、当該アクセス時刻が含まれる共通制限時間の開始時刻に近いアクセス時刻が記録されたユーザに対して、より体力回復値が大きい回復アイテムを付与し、終了時刻に近いアクセス時刻が記録されたユーザに対して、より体力回復値が小さい回復アイテムを付与してもよい。
あるいは、ＣＰＵ２１は、ユーザ毎に、ユーザがゲームの実行を制限されたとみなす時間（個別制限時間）を算出し、算出された個別制限時間に基づいた特典を当該ユーザに付与してもよい。例えば、当該アクセス時刻と当該終了時刻との間の時間を個別制限時間とすることができる。例えば、個別制限時間の長さに比例する体力回復値の回復アイテムを当該ユーザに付与してもよい。例えば、ＣＰＵ２１は、図８の回復アイテムデータベースを参照し、算出した個別制限時間に所定の係数を乗じた値に最も近い体力回復値の回復アイテムを当該ユーザに付与してもよい。例えば、体力ポイントが時間の経過によって回復するように設定されている場合、その回復率（ポイント／時間）を所定の係数として、個別制限時間に乗じた値に最も近い体力回復値の回復アイテムを当該ユーザに付与してもよい。
あるいは、個別制限時間と特典アイテムとを対応付けたテーブルをあらかじめ設け、当該テーブルを参照し、算出した個別制限時間に対応する特典アイテムを決定してもよい。
例えば、体力ポイントが３分間に１ポイント回復するように設定されている場合、回復率は１／３（ポイント／分）であるので、個別制限時間に１／３を乗じた値に最も近い体力回復値の回復アイテムを当該ユーザに付与してもよい。例えば個別制限時間が４０分であれば、個別制限時間に１／３を乗じた値は１３．３３３…であるので、体力回復値が１３である回復アイテムを当該ユーザに付与してもよい。なお、端数は四捨五入してもよいし、切り上げてもよいし、切り下げてもよい。

なお、共通制限時間内のアクセス時刻の数、つまり、アクセス回数に応じて特典を付与してもよいし、いずれか１つのアクセス時刻に応じて特典を付与してもよい。例えば、共通制限時間内の最初または最後のアクセス時刻に応じた特典をユーザに付与してもよい。例えば、共通制限時間内の最初または最後のアクセス時刻を用いて算出された個別制限時間に基づいて特典をユーザに付与してもよい。

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

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

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

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

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

〔アクセス処理〕
次に、図１８を参照して、アクセス処理を行うときのフローチャートの一例を説明する。
通信網ＮＷを通じてユーザ：Ａがゲームサーバ２０へアクセスした場合、ＣＰＵ２１は、アクセス処理を行う。すなわち、ＣＰＵ２１は、現在時刻を取得し、現在時刻をユーザ：Ａのアクセス時刻として、図１０に示すアクセス時刻テーブルに書き込む（ステップＳ３０２）。次に、ＣＰＵ２１は、メンテナンスデータベース３３にアクセスし、図９に示す共通制限時間テーブルを参照する（ステップＳ３０４）。次に、ＣＰＵ２１は、現在時刻がいずれかの共通制限時間内であるか否かを判定する（ステップＳ３０６）。例えば、共通制限時間ＩＤ毎に、現在時刻と開始時刻、終了時刻を比較し、開始時刻と終了時刻の間に現在時刻があれば、現在時刻が当該共通制限時間ＩＤの共通制限時間内であると判定する。
現在時刻が共通制限時間内であると判定した場合（ステップＳ３０６：ＹＥＳ）、ＣＰＵ２１は、ユーザによるゲームの実行を制限する（ステップＳ３０８）。すなわち、ＣＰＵ２１は、アクセス時刻テーブルに記録された終了時刻に基づき、図１３に示すウェブページＰ５のＨＴＭＬデータを生成して当該ユーザの通信端末１０に送信し、アクセス処理を終了する。
現在時刻が共通制限時間内でないと判定した場合（ステップＳ３０６：ＮＯ）、ＣＰＵ２１は、アクセス処理を終了する。

〔特典付与処理〕
次に、図１９を参照して、特典付与処理を行うときのフローチャートの一例を説明する。
まず、ＣＰＵ２１は、メンテナンスデータベース３３にアクセスしてアクセス時刻テーブルを参照する（ステップＳ４００）。次に、ＣＰＵ２１は、アクセス時刻テーブルに記録されているユーザ：Ａのアクセス時刻が、いずれかの共通制限時間内に含まれているか否かを判定する（ステップＳ４０２）。アクセス時刻が共通制限時間に含まれていない場合（ステップＳ４０２：ＮＯ）、ＣＰＵ２１は、特典付与処理を終了し、通常のゲームの実行を開始する。
アクセス時刻が共通制限時間に含まれている場合（ステップＳ４０２：ＹＥＳ）、ＣＰＵ２１は、既に特典アイテムが付与されているか否かを判定する（ステップＳ４０４）。既に特典アイテムが付与されている場合（ステップＳ４０４：ＹＥＳ）は、特典付与処理を終了する。まだ特典アイテムが付与されていない場合（ステップＳ４０４：ＮＯ）、共通制限時間に含まれるアクセス時刻に基づき特典アイテムを決定し、ユーザ：Ａに付与する（ステップＳ４０６）。その後、ＣＰＵ２１は、通常のゲームの実行を開始し、図１４のＰ６に示すようにメニューｍ３を含むトップページのＨＴＭＬデータを当該ユーザの通信端末１０に送信し、特典付与処理を終了する。

〔特典アイテム受領処理〕
次に、図２０を参照して、特典アイテムを受領する受領処理の一例を説明する。
まず、ＣＰＵ２１は、メニューｍ３の選択操作が行われたか否かを判定する（ステップＳ５００）。メニューｍ３以外の選択操作が行われた場合（ステップＳ５００：ＮＯ）、ＣＰＵ２１は、処理を終了する。
メニューｍ３の選択操作が行われた場合（ステップＳ５００：ＹＥＳ），ＣＰＵ２１は、図１４のウェブページＰ７のＨＴＭＬデータを当該ユーザの通信端末１０に送信する。その後、ＣＰＵ２１は、メニューｍ３０の選択操作が行われたか否かを判定する（ステップＳ５０２）。メニューｍ３０の選択操作が行われた場合（ステップ５０２：ＹＥＳ）、ＣＰＵ２１は、ユーザ：Ａに対応するユーザＩＤのユーザデータベースに、特典アイテムの識別コードを書き込み（ステップＳ５０４）、処理を終了する。メニューｍ３０以外の選択操作が行われた場合（ステップＳ５０２：ＮＯ）、ＣＰＵ２１は、処理を終了する。

なお、特典アイテムが付与されない場合でも、ユーザ：Ａが他のユーザ等から特典アイテム以外のアイテム（プレゼント）を譲り受けている場合、ユーザ：Ａの通信端末１０にメニューｍ３と同様のメニューを含むトップページが表示される。この場合、メニューｍ３の選択操作後、譲り受けたアイテムの一覧ととともに、各アイテムの識別コードをユーザ：Ａに対応するユーザＩＤのユーザデータベースに書き込むためのメニューを含むウェブページ（図示せず）が表示される。

以上説明したように、このゲーム装置では、共通制限時間にユーザのアクセス時刻が含まれる場合に、当該ユーザに特典を付与するため、共通制限時間にアクセスしてゲームの実行を制限されたユーザの不満を緩和することができる。さらに、アクセス時刻が共通制限時間に含まれるユーザに対して、アクセス時刻が共通制限時間に含まれないユーザよりも多くの特典を付与する場合には、全てのユーザに一律に特典を付与する場合よりも、ゲームの実行を制限されたユーザが優遇されたと感じるため、さらにゲームの実行を制限されたユーザの不満を緩和することができる。

また、ゲームの実行を制限されたユーザの不満は、ゲームの実行を制限された個別制限時間に応じて増加すると考えられるため、個別制限時間に基づいて特典をユーザに付与した場合には、不満の程度に応じた特典をユーザに付与することができ、ユーザの不満をさらに緩和することができる。

上記実施形態において、クエスト処理において体力ポイントを減少させ、減少した体力ポイントを時間の経過とともに上限値まで増加（回復）するように設定してもよいが、本発明はこれに限られず、時間に応じて任意に変動するパラメータを設定してもよい。例えば、ゲーム内で消費され、かつ、時間の経過とともに上限値まで増加（回復）する他のパラメータを設定してもよい。例えば、カードに消費コストを設定するとともに、ユーザに使用可能コストを設定し、対戦処理においてユーザがカードを使用したときに使用可能コストを減少させ、減少した使用可能コストを時間の経過とともに上限値まで増加（回復）するように設定し、使用可能コストを回復させるアイテムを特典として付与してもよい。
また、上記実施形態では、共通制限時間内にゲームにアクセスしたユーザが、共通制限時間の終了後に再びゲームにアクセスした場合に特典アイテムを付与することとしたが、本発明はこれに限られない。例えば、共通制限時間内にゲームにアクセスしたユーザに対し、共通制限時間内の最先のアクセス時に特典アイテムを付与してもよいし、ユーザのアクセスとは無関係に共通制限時間の終了時に特典アイテムを付与してもよい。また、共通制限時間の経過後のアクセスやプレゼントの受領処理を付与の条件としなくてもよい。

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

（８−１）変形例１
本変形例に係るゲーム制御装置の機能ブロック図を、図２１に示す。図２１に示すように、本変形例では、図１５の機能ブロック図と比較して、予告提示手段５７が追加された点で異なる。
予告提示手段５７は、共通制限時間に関する情報を、前記共通制限時間の開始時刻よりも前の予告期間にユーザに提示する機能を備える。

本変形例を実現するための共通制限時間テーブルの一例について、図２２を用いて説明する。図２２に示すように、共通制限時間テーブルには、共通制限時間ＩＤ毎に、メンテナンスの予告を事前に行う予告時刻、メンテナンスの開始時刻、終了時刻等が記録されている。

本変形例を実現するためのウェブページの一例について、図２３を用いて説明する。ユーザ：Ａがいずれかの共通制限時間ＩＤの予告時刻と開始時刻の間にゲームにアクセスした場合、図２３に示すように、ユーザ：Ａの通信端末１０に表示されるトップページＰ８は、メンテナンスが予定されていることを提示するメニューｍ４（「メンテナンス予定」）を含む。ユーザ：Ａがメニューｍ４を選択操作すると、図２３のＰ９に示すウェブページがユーザ：Ａの通信端末１０に表示される。ウェブページＰ９は、現在時刻が予告時刻と開始時刻の間にある共通制限時間の予定開始時刻及び予定終了時刻（「Ｘ月Ｘ日14:00〜15:00」）、ゲームが実行不能であること（「ゲームができません」）を示すテキストを含む。また、ゲームの実行を制限する理由（「メンテナンス」）、ゲームの実行を制限する目的（「新規イベント開始準備」）を示すテキストを含んでもよい。

〔アクセス処理〕
次に、図２４を参照して、本変形例におけるアクセス処理を行うときのフローチャートの一例を説明する。
通信網ＮＷを通じてユーザ：Ａがゲームサーバ２０へアクセスした場合、ＣＰＵ２１は、アクセス処理を開始する。すなわち、ＣＰＵ２１は、現在時刻を取得し、現在時刻をユーザ：Ａのアクセス時刻として、図１０に示すアクセス時刻テーブルに書き込む（ステップＳ６０２）。次に、ＣＰＵ２１は、メンテナンスデータベース３３にアクセスし、図２２に示す共通制限時間テーブルを参照する（ステップＳ６０４）。次に、ＣＰＵ２１は、現在時刻がいずれかの予告期間内であるか否かを判定する（ステップＳ６０６）。例えば、共通制限時間ＩＤ毎に、現在時刻と予告時刻、開始時刻を比較し、予告時刻と開始時刻の間に現在時刻があれば、現在時刻が当該共通制限時間ＩＤの予告期間内であると判定する。現在時刻がいずれかの予告期間内であると判定した場合（ステップＳ６０６：ＹＥＳ）、ＣＰＵ２１は、予告提示処理を行う（ステップＳ６０８）とともに、アクセス処理を終了し、通常のゲームの実行を開始する。
すなわち、ＣＰＵ２１は、図２３に示すようにメンテナンスが予定されていることを提示するメニューｍ４（「メンテナンス予定」）を含むトップページＰ８のＨＴＭＬデータをユーザ：Ａの通信端末１０に送信する。ユーザ：Ａがメニューｍ４を選択操作した場合、ＣＰＵ２１は、図２３に示すように、現在時刻が予告時刻と開始時刻の間にある共通制限時間の予定開始時刻及び予定終了時刻（「Ｘ月Ｘ日14:00〜15:00」）、ゲームが実行不能であること（「ゲームができません」）を示すテキスト等を含むウェブページＰ９のＨＴＭＬデータをユーザ：Ａの通信端末１０に送信する。
現在時刻が予告期間内でないと判定した場合（ステップＳ６０６：ＮＯ）、ＣＰＵ２１は、現在時刻がいずれかの共通制限時間内であるか否かを判定する（ステップＳ６１０）。以後、図１８に示すフローチャートと同様の処理が行われる。
すなわち、現在時刻が共通制限時間内であると判定した場合（ステップＳ６１０：ＹＥＳ）、ＣＰＵ２１は、ユーザによるゲームの実行を制限する（ステップＳ６１２）。すなわち、ＣＰＵ２１は、図１３に示すウェブページＰ５のＨＴＭＬデータをユーザ：Ａの通信端末１０に送信し、アクセス処理を終了する。
現在時刻が共通制限時間内でないと判定した場合（ステップＳ６１０：ＮＯ）、ＣＰＵ２１は、アクセス処理を終了する。

図２５は、本変形例における特典付与処理のフローチャートである。
まず、ＣＰＵ２１は、メンテナンスデータベース３３にアクセスしてアクセス時刻テーブルを参照する（ステップＳ７００）。次に、ＣＰＵ２１は、アクセス時刻テーブルに記録されているユーザ：Ａのアクセス時刻が、いずれかの予告期間又は共通制限時間内に含まれているか否かを判定する（ステップＳ７０２）。アクセス時刻が予告期間、共通制限時間のいずれにも含まれていない場合（ステップＳ７０２：ＮＯ）、ＣＰＵ２１は、特典付与処理を終了し、通常のゲームの実行を開始する。
アクセス時刻が予告期間又は共通制限時間に含まれている場合（ステップＳ７０２：ＹＥＳ）、ＣＰＵ２１は、既に特典アイテムが付与されているか否かを判定する（ステップＳ７０４）。既に特典アイテムが付与されている場合（ステップＳ７０４：ＹＥＳ）は、特典付与処理を終了する。まだ特典アイテムが付与されていない場合（ステップＳ７０４：ＮＯ）、予告期間又は共通制限時間に含まれるアクセス時刻に基づき特典アイテムを決定し、ユーザ：Ａに付与する（ステップＳ７０６）。その後、ＣＰＵ２１は、通常のゲームの実行を開始し、図１４のＰ６に示すようにメニューｍ３を含むトップページのＨＴＭＬデータを当該ユーザの通信端末１０に送信し、特典付与処理を終了する。

ここで、ステップＳ７０６において、予告期間又は共通制限時間に含まれるアクセス時刻に基づき特典アイテムを決定するにあたり、様々な付与態様があってもよい。予告期間または共通制限時間内のアクセス時刻の数に応じて特典を付与してもよいし、いずれか１つのアクセス時刻に応じて特典を付与してもよい。例えば、共通制限時間内の最初または最後のアクセス時刻に応じた特典をユーザに付与してもよい。例えば、共通制限時間にアクセスしたユーザの最初または最後のアクセス時刻を用いて算出された個別制限時間に基づいて特典をユーザに付与してもよい。

また、アクセス時刻が予告期間内にある場合とアクセス時刻が共通制限時間にある場合とで異なる特典を付与してもよい。
また、（ａ）予告期間にアクセス時刻が記録されているが共通制限時間にはアクセス時刻が記録されていない場合、（ｂ）予告期間にアクセス時刻が記録されており、かつ、共通制限時間にも別のアクセス時刻が記録されている場合、（ｃ）共通制限時間にアクセス時刻が記録されているが予告期間にはアクセス時刻が記録されていない場合、（ｄ）予告期間及び共通制限時間のいずれにもアクセス時刻が記録されていない場合、の４つの場合で、異なる方式で特典を付与してもよい。

例えば、（ａ）、（ｂ）の場合は共通制限時間に応じた特典、（ｃ）の場合は個別制限時間に応じた特典を付与し、（ｄ）の場合は特典を付与しない、と設定してもよい。このように特典付与の設定を行うことで、（ａ）予告期間にアクセスした後、共通制限時間にアクセスしない場合の特典が、（ｂ）予告期間にアクセスした後、共通制限時間にもアクセスした場合の特典と同じとなるため、ユーザが共通制限時間にアクセスする必要性が低下し、ユーザが共通制限時間にアクセスする頻度を低下させることができる。メンテナンス中にアクセスがあるとゲームサーバ２０に負荷がかかるが、このような設定にすることで、ゲームサーバ２０の負荷を軽減することができる。

また、（ａ）の場合は共通制限時間に応じた特典、（ｂ）、（ｃ）の場合は個別制限時間に応じた特典を付与し、（ｄ）の場合は特典を付与しない、と設定してもよい。このように特典付与の設定を行うことで、（ａ）予告期間にアクセスした後、共通制限時間にアクセスしない場合の特典が、（ｂ）予告期間にアクセスした後、共通制限時間にもアクセスした場合の特典よりも多くなるため、ユーザが共通制限時間にアクセスする頻度をさらに低下させることができる。メンテナンス中にアクセスがあるとゲームサーバ２０に負荷がかかるが、このような設定にすることで、ゲームサーバ２０の負荷をさらに軽減することができる。

（８−２）変形例２
本変形例に係るゲーム制御装置の機能ブロック図を、図２６に示す。図２６に示すように、本変形例では、図１５の機能ブロック図と比較して、延期手段５８が追加された点で異なる。
延期手段５８は、共通制限時間の終了時刻を延期する機能を備える。延期手段５８の機能は、例えば、指示入力部２５から入力される管理者の指示に従って、ＣＰＵ２１が共通制限時間テーブルの内容を書き換えることで、実現される。本変形例においても、図１８に示すアクセス処理、図１９に示す特典付与処理を行うことで、アクセス時刻及び延期後の終了時刻に基づく特典を付与することができる。

なお、本変形例において、延期前の共通制限時間におけるアクセスの有無、及び、終了時刻が延期された後、延期された終了時刻までの間のユーザのアクセスの有無により、特典を変更することができる。これを実現する形態の一例について、図２７〜図２９を用いて説明する。
図２７は本変形例におけるアクセス時刻テーブルの一例である。図２７に示すように、アクセス時刻テーブルには、ユーザＩＤごとに、共通制限時間ＩＤと対応付けてユーザがゲームにアクセスした時刻（アクセス時刻）が記録されるとともに、ユーザがゲームにアクセスした時刻における共通制限時間の終了時刻が「終了予定時刻」として保存される。すなわち、各ユーザの共通制限時間ＩＤ：001の行には、後述する図２８の共通制限時間ＩＤ：001の行の「開始時刻」と「終了時刻」の間のアクセス時刻が記録される。また、後述するように、図２８に示す共通制限時間テーブルに共通制限時間ＩＤ：001aの行が追加された場合、その後ユーザがゲームにアクセスしたときは、アクセス時刻テーブルに共通制限時間ＩＤ：001aの行が追加される。その時のアクセス時刻は、追加された共通制限時間ＩＤ：001aの行に記録されるとともに、図２８（ｂ）の共通制限時間ＩＤ：001aに対応する「終了時刻」がアクセス時刻テーブルの共通制限時間ＩＤ：001aの行の「終了予定時刻」に記録される。

本変形例においては、管理者が指示入力部２５から指示を入力することにより、共通制限時間テーブルの内容を変更することができる。図２８（ａ）、（ｂ）はいずれも共通制限時間テーブルの一例である。図２８（ａ）は内容を書き加える前の共通制限時間テーブルであり、図２８（ａ）では共通制限時間ＩＤ：001の「開始時刻」の欄が「X年X月X日14:00」、「終了時刻」の欄が「Ｘ年Ｘ月Ｘ日15:00」である。これに対し、図２８（ｂ）は、X年X月X日14:50（変更時刻）に、共通制限期間ＩＤ：001の終了時刻を同日の16:00に延期するため、共通制限時間テーブルの内容を変更した後の共通制限時間テーブルである。図２８（ｂ）では、共通制限時間ＩＤ：001aの行が追加されており、共通制限時間ＩＤ：001aの行の「終了時刻」の欄に延長後の終了時刻である「Ｘ年Ｘ月Ｘ日16:00」が記録されるとともに、「開始時刻」の欄に延長後の共通制限期間の開始時刻「X年X月X日15:00」が記録されている。同様に、さらに終了時刻が延期される場合は、順次、共通制限時間ＩＤ：001b、001c、…の行が追加される。

〔アクセス処理〕
次に、図２９を参照して、本変形例におけるアクセス処理を行うときのフローチャートの一例を説明する。
通信網ＮＷを通じてユーザ：Ａがゲームサーバ２０へアクセスした場合、ＣＰＵ２１は、アクセス処理を行う。すなわち、ＣＰＵ２１は、現在時刻を取得し、現在時刻をユーザ：Ａのアクセス時刻として、図１０に示すアクセス時刻テーブルに書き込む（ステップＳ８０２）。次に、ＣＰＵ２１は、メンテナンスデータベース３３にアクセスし、図２８に示す、現在時刻（ユーザ：Ａがアクセスした時刻）における共通制限時間テーブルを参照する（ステップＳ８０４）。次に、ＣＰＵ２１は、現在時刻がいずれかの共通制限時間内であるか否かを判定する（ステップＳ８０６）。例えば、共通制限時間ＩＤ毎に、現在時刻と開始時刻、終了時刻を比較し、開始時刻と終了時刻の間に現在時刻があれば、現在時刻が当該共通制限時間ＩＤの共通制限時間内であると判定する。なお、共通制限時間テーブルに延長後の終了時刻が記録されている場合は、延長前の開始時刻と、延長後の終了時刻の間に現在時刻があれば、現在時刻が当該共通制限時間ＩＤの共通制限時間内であると判定する。
現在時刻が共通制限時間内であると判定した場合（ステップＳ８０６：ＹＥＳ）、ＣＰＵ２１は、ユーザによるゲームの実行を制限する（ステップＳ８０８）。すなわち、ＣＰＵ２１は、共通制限時間テーブルに記録された共通制限時間ＩＤをアクセス時刻テーブルの「共通制限時間ＩＤ」に書き込むとともに、共通制限時間ＩＤに対応する終了時刻を、アクセス時刻テーブルの「終了予定時刻」に書き込む（ステップＳ８１０）。その後、ＣＰＵ２１は、終了予定時刻に基づき、図１３に示すウェブページＰ５のＨＴＭＬデータを生成して当該ユーザの通信端末１０に送信し、アクセス処理を終了する。
現在時刻が共通制限時間内でないと判定した場合（ステップＳ８０６：ＮＯ）、ＣＰＵ２１は、アクセス処理を終了する。

ここで、図２７のユーザＩＤ：０００００１のアクセス時刻が「Ｘ年Ｘ月Ｘ日14:30」のときの共通制限時間テーブルが図２８（ａ）の状態であったとき、ユーザＩＤ：０００００１の「終了予定時刻」には「Ｘ年Ｘ月Ｘ日15:00」が書き込まれる。その後、共通制限時間テーブルが図２８（ｂ）の状態に書き換えられ、「終了時刻」が「Ｘ年Ｘ月Ｘ日16:00」に変更されたとしても、その後、ユーザＩＤ：０００００１のユーザがＸ年Ｘ月Ｘ日16:00までにアクセスしなかった場合は、ユーザＩＤ：０００００１の「終了予定時刻」は「Ｘ年Ｘ月Ｘ日15:00」のままである。
一方、図２７のユーザＩＤ：０００００２のアクセス時刻が「Ｘ年Ｘ月Ｘ日15:05」のときの共通制限時間テーブルが図２８（ｂ）の状態であったとき、ユーザＩＤ：０００００２のアクセス時刻テーブルには「共通制限時間ＩＤ」が「001a」の行が追加され、その行の「終了予定時刻」に「Ｘ年Ｘ月Ｘ日16:00」が書き込まれる。

〔特典付与処理〕
次に、本変形例における特典付与処理の一例を説明する。
本変形例においては、図１９のステップＳ４０２において、共通制限時間テーブルに延長後の終了時刻が記録されていない場合は、延長前の開始時刻と、延長前の終了時刻の間にアクセス時刻が記録されていれば、共通制限時間にアクセス時刻があると判定する。一方、共通制限時間テーブルに延長後の終了時刻が記録されている場合は、延長前の開始時刻と、延長後の終了時刻の間にアクセス時刻が記録されていれば、共通制限時間にアクセス時刻があると判定する。
また、本変形例においては、図１９のステップＳ４０６において、ＣＰＵ２１が、アクセス時刻テーブルに記録された共通制限時間内のアクセス時刻、及び、終了予定時刻に基づき特典アイテムを決定し、ユーザ：Ａに付与する。共通制限時間テーブルに延長後の終了時刻が記録されている場合は、アクセス時刻テーブルに記録されている共通制限時間ＩＤ毎のアクセス時刻、及び、終了予定時刻に基づき特典アイテムを決定してもよい。また、共通制限時間に複数のアクセス時刻が含まれている場合は、最も早い又は最も遅いアクセス時刻、及び、終了予定時刻に基づき特典アイテムを決定してもよい。
例えば、特典付与処理において、共通制限時間に含まれると判断されたアクセス時刻のうち、最も早いアクセス時刻、及び、アクセス時刻テーブルに記録された、最も遅い終了予定時刻に基づき特典アイテムを決定する場合、ユーザＩＤ：０００００１のユーザでは、個別制限時間が３０分と算定され、ユーザＩＤ：０００００２のユーザでは、個別制限時間が９０分と算定され、それぞれの時間に対応する特典が付与される。

このように、ユーザのアクセス時刻における終了予定時刻に基づき特典アイテムを決定することで、終了時刻の延期を知らなかったユーザ、終了時刻の延期を知っていたユーザのいずれにも、ユーザが認識していた終了予定時刻に基づき、ユーザが実質的にゲームを実行できなかったと考えられる個別制限時間が算定され、特典が付与される。そのため、ユーザの不満に応じた特典の付与をすることができる。

（８−３）変形例３
本変形例に係るゲーム制御装置の機能ブロック図を、図３０に示す。図３０に示すように、本変形例では、図２６の機能ブロック図と比較して、延長予告提示手段５９が追加された点で異なる。
延長予告提示手段５９は、延期後の終了時刻に関する情報を、延期前の終了時刻よりも前の期間である延長予告期間にユーザに提示する機能を備える。

本変形例を実現するための共通制限時間テーブルの一例について、図３１（ａ）、図３１（ｂ）を用いて説明する。図３１（ａ）、図３１（ｂ）に示すように、共通制限時間テーブルには、共通制限時間ＩＤ毎に、開始時刻／延長予告時刻、終了時刻等が記録されている。ここで、「開始時刻」はメンテナンスの開始時刻であり、「延長予告時刻」は共通制限時間の終了時刻の延期予告を行う時刻である。

本変形例においては、管理者が指示入力部２５から指示を入力することにより、共通制限時間テーブルの内容を変更することができる。
図３１（ａ）は内容を書き加える前の共通制限時間テーブルであり、図３１（ａ）では共通制限時間ＩＤ：001の「開始時刻／延長予告時刻」の欄に、共通制限時間の開始時刻「X年X月X日14:00」、「終了時刻」の欄に共通制限時間の終了時刻「Ｘ年Ｘ月Ｘ日15:00」が記録されている。
これに対し、図３１（ｂ）は、共通制限期間ＩＤ：001の終了時刻を同日の16:00に延期するため、共通制限時間テーブルの内容を変更した後の共通制限時間テーブルである。図３１（ｂ）では、共通制限時間ＩＤ：001aの行が追加されており、共通制限時間ＩＤ：001aの行の「終了時刻」の欄に延長後の終了時刻である「Ｘ年Ｘ月Ｘ日16:00」が記録されるとともに、「開始時刻／延長予告時刻」の欄に延長予告時刻「X年X月X日14:50」が記録されている。同様に、さらに終了時刻が延期される場合は、順次、共通制限時間ＩＤ：001b、001c、…の行が追加され、「開始時刻／延長予告時刻」の欄にそれぞれの延長予告時刻が、「終了時刻」の欄に延期後の終了時刻が記録される。

図３２は本変形例におけるアクセス時刻テーブルの一例である。図３２のアクセス時刻テーブルが図２７と異なるのは、共通制限時間テーブルが図３１（ｂ）のように変更された後にアクセスした場合には、変更後の共通時間ＩＤ：001aの「開始時刻／延長予告時刻」後、延長前の終了時刻前のアクセス時刻が、アクセス時刻テーブルの変更後の共通時間ＩＤ：001aの行に記録される点である。例えば、図３２に示すように、ユーザＩＤ：000002のアクセス時刻テーブルの共通制限時間ＩＤ：001aの行には、共通時間ＩＤ：001aの「開始時刻／延長予告時刻」である「X年X月X日14:50」と延長前の終了時刻である「X年X月X日15:00」の間のアクセス時刻の一例として、「X年X月X日14:55」が記録されている。
また、延長予告時刻（Ｘ月Ｘ日14:50）よりも前にアクセスしたユーザＩＤ：０００００１に対応するユーザは、図３１の共通制限時間テーブルを参照すると、共通制限時間ＩＤ：００１の延長予告時刻（Ｘ年Ｘ月Ｘ日14:50）よりも前のアクセス時刻（Ｘ年Ｘ月Ｘ日14:30）にのみアクセスしているため、ユーザＩＤ：０００００１のアクセス時刻テーブルでは、共通制限時間ＩＤ：001に対応する「終了予定時刻」である「Ｘ年Ｘ月Ｘ日15:00」のみが記録されている。一方、ユーザＩＤ：０００００２に対応するユーザは、共通制限時間ＩＤ：００１の延長予告時刻（Ｘ年Ｘ月Ｘ日14:50）よりも後のアクセス時刻（Ｘ年Ｘ月Ｘ日14:55）にアクセスしているため、ユーザＩＤ：０００００２のアクセス時刻テーブルには、共通制限時間ＩＤ：001aに対応する「終了予定時刻」である「Ｘ年Ｘ月Ｘ日16:00」も記録されている。

〔アクセス処理〕
次に、図３３を参照して、本変形例におけるアクセス処理を行うときのフローチャートの一例を説明する。
通信網ＮＷを通じてユーザ：Ａがゲームサーバ２０へアクセスした場合、ＣＰＵ２１は、アクセス処理を行う。すなわち、ＣＰＵ２１は、現在時刻を取得し、現在時刻をユーザ：Ａのアクセス時刻として、図１０に示すアクセス時刻テーブルに書き込む（ステップＳ９０２）。次に、ＣＰＵ２１は、メンテナンスデータベース３３にアクセスし、図３１に示す共通制限時間テーブルを参照する（ステップＳ９０４）。次に、ＣＰＵ２１は、現在時刻がいずれかの延長予告期間内であるか否かを判定する（ステップＳ９０５）。
例えば、共通制限時間テーブルが図３１（ａ）のように、終了時刻の延長がされていない状態であれば、現在時刻は延長予告期間内でないと判定する。
また、共通制限時間テーブルが図３１（ｂ）のように、終了時刻の延長がされた後の状態であれば、延長後の共通制限時間ＩＤ：001aの「開始時刻／延長予告時刻」と、延長前の共通制限時間ＩＤ：001の「終了時刻」の間（延長予告期間）に現在時刻があれば、現在時刻は延長予告期間内であると判定する。一方、延長予告期間に現在時刻がなければ、現在時刻は延長予告期間内ではないと判定する。
現在時刻が延長予告期間内でないと判定した場合（ステップ９０５：ＮＯ）、ＣＰＵ２１は、現在時刻がいずれかの共通制限時間内であるか否か、すなわち、共通制限時間ＩＤにおける「開始時刻／延長予告時刻」と「終了時刻」の間（共通制限時間）に現在時刻があるか否かを判定する（ステップＳ９０６）。現在時刻が共通制限時間内でないと判定した場合（ステップＳ９０６：ＮＯ）、ＣＰＵ２１は、アクセス処理を終了する。
現在時刻が延長予告期間内であると判定した場合（ステップＳ９０５：ＹＥＳ）、または、現在時刻が共通制限時間内であると判定した場合（ステップＳ９０６：ＹＥＳ）、ユーザによるゲームの実行を制限する（ステップＳ９０８）。すなわち、ＣＰＵ２１は、共通制限時間テーブルに記録された終了時刻を、アクセス時刻テーブルの「終了予定時刻」に書き込む（ステップＳ９１０）。その後、ＣＰＵ２１は、終了予定時刻に基づき、図１３に示すウェブページＰ５のＨＴＭＬデータを生成して当該ユーザの通信端末１０に送信し、処理を終了する。その後、ＣＰＵ２１は、終了予定時刻に基づき、図１３に示すウェブページＰ５のＨＴＭＬデータを生成して当該ユーザの通信端末１０に送信し、処理を終了する。

〔特典付与処理〕
次に、本変形例における特典付与処理の一例を説明する。
本変形例においては、図１９のステップＳ４０２において、共通制限時間テーブルに延長後の終了時刻が記録されていない場合は、延長前の開始時刻／延長予告時刻と、延長前の終了時刻の間にアクセス時刻が記録されていれば、共通制限時間にアクセス時刻があると判定する。一方、共通制限時間テーブルに延長後の終了時刻が記録されている場合は、延長前の開始時刻／延長予告時刻と、延長後の終了時刻の間にアクセス時刻が記録されていれば、共通制限時間にアクセス時刻があると判定する。
また、本変形例においては、図１９のステップＳ４０６において、ＣＰＵ２１が、アクセス時刻テーブルに記録された共通制限時間内のアクセス時刻、及び、終了予定時刻に基づき特典アイテムを決定し、ユーザ：Ａに付与する。共通制限時間テーブルに延長後の終了時刻が記録されている場合は、アクセス時刻テーブルに記録されている共通制限時間ＩＤ毎のアクセス時刻、及び、終了予定時刻に基づき特典アイテムを決定してもよい。また、共通制限時間に複数のアクセス時刻が含まれている場合は、最も早い又は最も遅いアクセス時刻、及び、終了予定時刻に基づき特典アイテムを決定してもよい。

例えば、特典付与処理において、共通制限時間内に含まれる最も早いアクセス時刻、及び、アクセス時刻テーブルに記録された、最も遅い終了予定時刻に基づき特典アイテムを決定し、付与する場合、ユーザＩＤ：０００００１のユーザでは、個別制限時間が３０分と算定され、ユーザＩＤ：０００００２のユーザでは、個別制限時間が９０分と算定され、対応する特典が付与される。

このように、ユーザのアクセス時刻における終了予定時刻に基づき特典アイテムを決定することで、終了時刻の延期を知らなかったユーザ、終了時刻の延期を知っていたユーザのいずれにも、ユーザが知っていた終了予定時刻に基づき、ユーザが実質的にゲームを実行できなかったと考えられる個別制限時間が算定され、特典が付与されるため、ユーザの不満に応じた特典の付与をすることができる。

なお、アクセス時刻が延長予告期間内にある場合と、延長前の終了時刻から延長後の終了時刻までの間（延長時間）にある場合とで異なる特典を付与してもよい。
また、（ａ）延長予告期間にアクセス時刻が記録されているが延長時間にはアクセス時刻が記録されていない場合、（ｂ）延長予告期間にアクセス時刻が記録されており、かつ、延長時間にも別のアクセス時刻が記録されている場合、（ｃ）延長時間にアクセス時刻が記録されているが延長予告期間にはアクセス時刻が記録されていない場合、（ｄ）延長予告期間及び延長時間のいずれにもアクセス時刻が記録されていない場合、の４つの場合で、異なる方式で特典を付与してもよい。
例えば、（ａ）、（ｂ）の場合は延長時間に応じた特典、（ｃ）の場合は個別制限時間に応じた特典を付与し、（ｄ）の場合は特典を付与しない、と設定してもよい。このように特典付与の設定を行うことで、（ａ）延長予告期間にアクセスした後、延長時間にアクセスしない場合の特典が、（ｂ）延長予告期間にアクセスした後、延長時間にもアクセスした場合の特典と同じとなるため、ユーザが延長時間にアクセスする必要性が低下し、ユーザが延長時間にアクセスする頻度を低下させることができる。メンテナンス中にアクセスがあるとゲームサーバ２０に負荷がかかるが、このような設定にすることで、ゲームサーバ２０の負荷を軽減することができる。
また、（ａ）の場合は延長時間に応じた特典、（ｂ）、（ｃ）の場合は個別制限時間に応じた特典を付与し、（ｄ）の場合は特典を付与しない、と設定してもよい。このように特典付与の設定を行うことで、（ａ）延長予告期間にアクセスした後、延長時間にアクセスしない場合の特典が、（ｂ）延長予告期間にアクセスした後、延長時間にもアクセスした場合の特典よりも多くなるため、ユーザが延長時間にアクセスする頻度をさらに低下させることができる。メンテナンス中にアクセスがあるとゲームサーバ２０に負荷がかかるが、このような設定にすることで、ゲームサーバ２０の負荷をさらに軽減することができる。

（８−４）変形例４
本変形例を実現するための共通制限時間テーブルの一例について、図３４を用いて説明する。図３４に示すように、本変形例においては、複数の共通制限時間が連続するように設定されている。すなわち、共通制限時間ＩＤ：００１の共通制限時間がＸ年Ｘ月Ｘ日14:00〜15:00、共通制限時間ＩＤ：００２の共通制限時間がＸ年Ｘ月Ｘ日15:00〜16:00、共通制限時間ＩＤ：００３の共通制限時間がＸ年Ｘ月Ｘ日16:00〜17:00に設定されている。本変形例においても、図１８に示すアクセス処理、図１９に示す特典付与処理により、共通制限時間ＩＤごとに特典が付与される。例えば、ユーザ：Ａのアクセス時刻がＸ年Ｘ月Ｘ日14:30分、Ｘ年Ｘ月Ｘ日15:20分、Ｘ年Ｘ月Ｘ日16:40分であれば、共通制限時間ＩＤ：００１に対応する個別制限時間が３０分、共通制限時間ＩＤ：００２に対応する個別制限時間が４０分、共通制限時間ＩＤ：００３に対応する個別制限時間が２０分と算出され、それぞれに対応する特典が付与される。なお、各共通制限時間における最初のアクセス時刻のみに基づいて特典を付与してもよいし、最後のアクセス時刻のみに基づいて特典を付与してもよい。
また、特典付与処理の際に、共通制限時間ＩＤ毎に算出した個別制限時間の合計値に基づき、特典を付与してもよい。また、共通制限時間ＩＤ毎に異なる特典を付与してもよい。例えば、共通制限時間の制限理由や長さに応じて、共通制限時間ＩＤ毎に算出した個別制限時間に対応する特典の比率等を変更してもよい。
なお、変形例１と同様に、予告提示手段５７を設けてもよい。

（８−５）変形例５
なお、共通制限時間の終了時刻がユーザに提示されない場合は、アクセス時刻テーブルに記録されたアクセス時刻のうち、共通制限時間内にあるアクセス時刻の数、すなわち、ユーザのアクセス回数に応じた特典を付与してもよい。
ここで、終了時刻がユーザに提示されない場合には、終了時刻は定まっているが、ユーザには終了時刻を提示しない場合、及び、ユーザに終了時刻を提示するタイミングで、共通制限時間の終了時刻が定まっていない場合が含まれる。またここで、ユーザに終了時刻を提示するタイミングとは、共通制限時間、予告期間、延長予告期間にユーザからアクセスがあった時である。
共通制限時間の終了時刻がユーザに提示されないにもかかわらず、頻繁にアクセスするユーザの不満は、アクセスする度に増加すると考えられる。このため、共通制限時間内にアクセスした回数に応じて特典を付与することで、不満の程度に応じた特典がユーザに付与され、ユーザの不満を緩和することができる。
なお、共通制限時間の終了時刻が定まっていない場合は、終了時刻が定まった後、特典付与処理が行われる。

（８−６）変形例６
ゲーム内で消費され、かつ、時間の経過とともに上限値まで増加（回復）する所定のパラメータを設定したゲームにおいて、個別制限時間の長さに比例するパラメータの回復アイテムを特典アイテムとしてユーザに付与してもよい。この場合、アクセス時刻におけるパラメータの値に応じた特典を付与してもよい。
例えば、ユーザ毎に体力ポイントの上限値が定められるとともに、体力ポイントが時間の経過によって上限値まで増加（回復）するように設定されたゲームにおいて、個別制限時間の長さに比例する体力回復値の回復アイテムを当該ユーザに付与する場合、アクセス時刻における体力ポイントの値に応じた特典を付与してもよい。
あるいは、カードに消費コストを設定するとともに、ユーザに使用可能コストを設定し、対戦処理においてユーザがカードを使用したときに使用可能コストを減少させ、減少した使用可能コストを時間の経過とともに上限値まで増加（回復）するように設定し、使用可能コストを回復させるアイテムを特典として付与してもよい。

例えば、ゲームデータベース３２がメンテナンス中のためゲームの実行はできないが、ユーザデータベース３１はアクセス可能である場合、ユーザ：Ａがゲームサーバ２０にアクセスしたとき、ＣＰＵ２１はユーザデータベース３１にアクセスし、ユーザ：Ａの体力ポイントの上限値と、アクセス時刻におけるユーザ：Ａの体力ポイントの差分Δを算出し、差分Δを控除した特典を付与してもよい。

例えば、所定のパラメータの単位時間当たりの回復率（パラメータ回復率（ポイント／時間））を個別制限時間に乗じた値に対応する特典を付与してもよい。
具体的には、例えば、個別制限時間にパラメータ回復率を乗じた値から差分Δを控除した値に最も近い値分のパラメータを回復させる回復アイテムをユーザ：Ａに付与してもよい。例えば、パラメータ回復率が１／３（ポイント／分）の場合、個別制限時間が６０分であれば、個別制限時間（６０分）にパラメータ回復率（１／３）を乗じた値は２０であるが、アクセス時間におけるユーザ：Ａのパラメータが９０、パラメータの上限値が１００であれば、個別制限時間（６０分）にパラメータ回復率（１／３）を乗じた値（２０）から差分Δ＝１０（＝１００−９０）を控除した値は１０であるので、パラメータの回復値が１０である回復アイテムをユーザ：Ａに付与してもよい。なお、端数は四捨五入してもよいし、切り上げてもよいし、切り下げてもよい。

時間の経過に応じてユーザに関連するゲーム上のパラメータが変動するゲームにおいては、予期せずゲームの実行を制限されたユーザの不満は、より高いと考えられる。このゲーム装置によれば、共通制限時間にアクセスしたユーザに特典を付与することで、ユーザの不満を緩和することができる。
また、変形例１における、予告期間にアクセスしたが共通制限時間にアクセスしなかったユーザに付与する特典についても、例えば、ユーザ：Ａの体力ポイントの上限値と、共通制限時間の開始時刻におけるユーザの体力ポイントの値との差分Δを算出し、共通制限時間に応じた特典から差分Δを控除してもよい。例えば、共通制限時間に体力回復率（ポイント／時間）を個別制限時間に乗じた値から、差分Δを控除した値に対応する特典を付与してもよい。

なお、ユーザデータベース３１へのアクセスも制限される場合でも、ユーザデータベース３１のバックアップとなるデータベースがある場合は、バックアップとなるデータベースにアクセスしてユーザ：Ａの体力ポイントを参照してもよい。

また、個別制限時間に応じて特典を付与するのではなく、共通制限時間のアクセスの有無のみに基づいて、特典を付与してもよい。例えば、体力回復率（ポイント／時間）を共通制限時間に乗じた値から差分Δを控除した値に対応する特典を付与してもよい。また、差分Δを算出する際に、共通制限時間の開始時刻または終了時刻におけるユーザ：Ａの体力ポイントを基にしてユーザ：Ａの体力ポイントの上限値との差分Δを算出してもよい。

なお、共通制限時間にアクセスしなかったユーザに対しても、共通制限時間にアクセスしたユーザに対する特典と同様に、共通制限時間に応じた特典を付与してもよい。この場合にも、例えば、共通制限時間の開始時刻または終了時刻におけるユーザの体力ポイント、または、前記開始時刻または終了時刻における体力ポイントの当該ユーザの体力ポイントの上限値に対する割合に応じて特典を付与してもよい。

また、共通制限時間内にパラメータが上限値まで到達する場合、その時刻（到達時刻）を考慮した特典を付与してもよい。
例えば、アクセス時のパラメータが上限値ではない場合、個別制限時間からパラメータが上限値に達するまでの時間を控除して特典を付与してもよい。個別制限時間からパラメータが上限値に達するまでの時間を控除した時間が、ユーザが実際にゲーム中の利益を享受できない時間と考えられるからである。
具体的には、個別制限時間から以下の時間δを控除してもよい。
δ＝（パラメータの上限値−アクセス時のパラメータ値）÷パラメータ回復率
すなわち、（個別制限時間−δ）と、時間に応じた特典比率との積に応じた特典を付与してもよい。
また、共通制限時間におけるアクセスの有無にかかわらず、共通制限時間内にパラメータが上限値まで到達する場合、その時刻（到達時刻）に応じた特典を付与してもよい。
例えば、個別制限時間を、アクセス時刻と共通制限時間の終了時刻との間の時間とする代わりに、到達時刻から共通制限時間の終了時刻までの時間を個別制限時間として特典を付与してもよい。すなわち、到達時刻から共通制限時間の終了時刻までの時間に、所定の係数を乗じた値に対応する特典を付与してもよい。到達時刻に応じた特典を付与することで、到達時刻にユーザがアクセスしていたならば使用できたであろうパラメータの逸失分を補填することができる。
なお、到達時刻については、ユーザ毎の体力ポイントが上限値に到達している時間を記録する、若しくは、イベント開始時刻におけるユーザの体力ポイントをユーザ毎に記録し、到達時刻を算出することで、共通制限時間内の到達時刻を取得することが出来る。
また、共通制限時間にアクセスしなかったユーザのパラメータに応じた特典を、共通制限時間にアクセスしたユーザよりも少なくしてもよいし、多くしてもよい。例えば、共通制限時間におけるアクセスの有無により、前記所定の係数を変更してもよい。

（８−７）変形例７
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。本発明は、ユーザの行動を制限する制限時間を設定できるゲーム、及び／又は、ゲーム中に消費するゲームポイントが時間経過とともに補充されるゲームであればいかなるゲームにも適用でき、例えば、ネットワーク上に置かれたサーバ装置とオンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
また、ユーザの通信端末上でゲームを表示するために当該通信端末との間で無線又は有線による通信を確立できるサーバ等の情報処理装置であってもよいし、相互に無線又は有線による通信を確立できる通信端末であってもよい。
また、例えば、ネットワーク上に置かれたサーバ装置と通信端末（コンピュータ）を接続したオンラインシステムによるサービスの提供、例えばインターネットショッピングサービス、インターネットオークションサービス等においても、上述した実施形態と同様に、当該サービスの実行が制限されている期間におけるユーザによるサーバへのアクセスの有無、または、ユーザによるアクセス時刻に応じて特典、例えば、当該サービスで使用することができるポイントやアイテム等を付与することができる。

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

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

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

Claims (11)

1. 時間の経過に応じて増加し、かつ、ユーザによるゲームの実行に伴い減少する前記ゲーム上のパラメータを用いて、前記ゲームの実行を制御するゲーム制御装置であって、
   ユーザによるゲームの実行のためのアクセス時刻を取得する取得手段、
   所定の共通制限時間においてユーザによるゲームの実行を制限する制限手段、
   ユーザのアクセス時刻が前記共通制限時間に含まれるか否かを判定する判定手段、
   ユーザのアクセス時刻が前記共通制限時間に含まれる場合に、当該ユーザに対して、前記共通制限時間に含まれるアクセス時刻における前記パラメータに応じた特典を付与する特典付与手段、
   を備えたゲーム制御装置。
2. 前記特典付与手段は、前記共通制限時間に含まれるアクセス時刻における前記パラメータが所定の上限値に達しているユーザに対して、前記共通制限時間に含まれるアクセス時刻における前記パラメータが前記上限値に達していないユーザよりも多くの特典を付与する、請求項１に記載のゲーム制御装置。
3. 前記特典付与手段は、前記パラメータを増加させるための前記ゲーム上のオブジェクトを前記ユーザに付与する、請求項１またが２に記載のゲーム制御装置。
4. 前記特典付与手段は、アクセス時刻が前記共通制限時間に含まれるユーザに対して、アクセス時刻が前記共通制限時間に含まれないユーザよりも多くの特典を付与する、請求項１〜３のいずれかに記載のゲーム制御装置。
5. 前記特典付与手段は、ユーザが前記制限手段によりゲームの実行を制限される時間であって、少なくとも、前記ユーザの前記共通制限時間内のアクセス時刻から前記共通制限時間の終了時刻までの時間である個別制限時間に基づく特典を当該ユーザに付与する、請求項１〜４のいずれかに記載のゲーム制御装置。
6. ユーザによるゲームの実行のためのアクセス時刻を取得する取得手段、
   所定の共通制限時間においてユーザによるゲームの実行を制限する制限手段、
   ユーザのアクセス時刻が前記共通制限時間に含まれるか否かを判定する判定手段、
   ユーザのアクセス時刻が前記共通制限時間に含まれる場合に、当該ユーザに特典を付与する特典付与手段、
   前記共通制限時間に関する情報を、前記共通制限時間の開始時刻よりも前の期間である予告期間にユーザに提示する予告提示手段を備え、
   前記特典付与手段は、ユーザのアクセス時刻が前記予告期間に含まれる場合に、当該ユーザに前記特典を付与する、ゲーム制御装置。
7. 前記共通制限時間の終了時刻を延期する延期手段を備える、請求項１〜６のいずれか一項に記載のゲーム制御装置。
8. 前記延期手段による延期後の終了時刻に関する情報を、延期前の終了時刻よりも前の期間である延長予告期間にユーザに提示する延長予告提示手段を備え、
   前記特典付与手段は、ユーザのアクセス時刻が前記延長予告期間に含まれる場合に、当該ユーザに特典を付与する、請求項７に記載のゲーム制御装置。
9. ユーザによるゲームの実行のためのアクセス時刻を取得する取得手段、
   所定の共通制限時間においてユーザによるゲームの実行を制限する制限手段、
   ユーザのアクセス時刻が前記共通制限時間に含まれるか否かを判定する判定手段、
   ユーザのアクセス時刻が前記共通制限時間に含まれる場合に、当該ユーザに特典を付与する特典付与手段を備え、
   前記特典付与手段は、前記共通制限時間の終了時刻がユーザに提示されない場合には、
   当該共通制限時間内に前記ユーザがアクセスした回数に応じた特典を付与する、ゲーム制御装置。
10. コンピュータを、請求項１〜９のいずれかに記載のゲーム制御装置の各手段として機能させるためのプログラム。
11. 複数のユーザの通信端末と、当該通信端末からアクセスされるサーバとを含む、ゲームシステムであって、
    請求項１〜９のいずれかに記載のゲーム制御装置の各手段を、前記通信端末または前記サーバのいずれか一方が備えた、ゲームシステム。

Images