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

Abstract

【課題】あるゲームを実行中のユーザが別のゲームについての自らの情報を知ることができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供すること。
【解決手段】ゲーム制御装置は、第１ゲームを実行する実行手段と、ユーザに関するゲーム上の情報であるユーザ情報が前記第１ゲームにおいて所定の条件を満たすか否かを判定する判定手段と、前記判定手段により前記所定の条件を満たすと判定された場合に、前記ユーザについて前記第１ゲームとは異なる第２ゲームを実行する第２ゲーム制御装置に前記ユーザ情報を提供するか、又は前記第２ゲーム制御装置が前記ユーザ情報を取得可能な状態とする提供手段と、を備える。
【選択図】図１２

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)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。

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

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

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

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

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

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

ＡＰＩサーバ２６は、ＷｅｂＡＰＩが実装されており、他のゲームサーバのＡＰＩサーバとの間でＨＴＴＰに従った通信を行う。例えば、ＡＰＩサーバ２６は、ＨＴＴＰを利用して他のゲームサーバのＡＰＩサーバ宛に、ユーザ情報等の所定の情報を受け付けるようにリクエストを行い、リクエストを受けたＡＰＩサーバが、その所定の情報を正しく受け付けたか（取得したか）否かの結果をリクエストの要請元のＡＰＩサーバ２６に対して返すように構成されている。
なお、図４では、ＡＰＩサーバ２６がゲームサーバ２０に組み込まれた場合について示しているが、ＡＰＩサーバ２６は、ゲームサーバ２０とは別体で構成してもよい。

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

本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、ゲームキャラクタの画像が表示されるカードを使用するデジタルカードゲームを採り上げる。つまり、ゲームサーバ２０ａ，２０ｂ，…はそれぞれ、デジタルカードゲームであるゲームＡ，ゲームＢ，…をそれぞれ実行するものとする。
以下では、理解の容易のために、各ゲームが同一の機能（後述するクエスト、バトル、自動探索）を備えている場合について説明する。

図６に、本実施形態のデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）において適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、進行レベル、体力ポイント、経験値、仲間のユーザＩＤ、保有カード、保有アイテム、プレゼント、仲間申請、救援要請、探索開始時刻の各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
本実施形態のゲームシステムでは、複数のゲームサーバ２０ａ，２０ｂ，２０ｃ，…が共通のプラットフォーム上に実装されており、複数のゲームＡ，Ｂ，Ｃ，…において同一のユーザは同一のユーザＩＤによって管理される。
・ユーザ名
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。ユーザ名は、ユーザＩＤと同様に、複数のゲームＡ，Ｂ，Ｃ，…において同一のユーザは同一のユーザ名によって管理されてもよいし、ゲーム毎に異なるユーザ名が設定できるようにしてもよい。
・進行レベル
各ゲーム上のユーザの進行レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。経験値が所定値に達すると進行レベルが１つ上昇する。
・体力ポイント
本実施形態のゲームにおいて、後述するクエストを行う上で必要となるポイントである。体力ポイントは、クエストを行う度に低減し、所定の時間が経過する毎に回復（増加）する値である。
・経験値
本実施形態のゲームにおいて、後述するクエストを行う上で増加する値である。経験値が所定の値（例えば、１００）に達すると、進行レベルが１増加して経験値はリセットされる（つまりゼロになる）。
・仲間のユーザＩＤ
ユーザがゲーム上で仲間（後述する）の関係にあるユーザＩＤである。
・保有カード
保有カードは、ゲーム上でユーザが保有しているカードのデータ（Ｃ１等）である。各カードは、例えばゲーム内のバトル等で参照されるパラメータ（つまり、攻撃力と防御力等の能力値）が対応付けられてもよい。
・保有アイテム
保有アイテムは、ゲーム上でユーザが保有しているアイテムのデータ（Ｉｍ１等）である。
・プレゼント
ユーザの仲間、あるいはゲームの運営者からのプレゼントのうち未だ受け取っていないプレゼントの内容（例えばカードやアイテム等）を示すデータである。
・仲間申請
ユーザと仲間になりたい他のユーザからの申請（仲間申請）がある場合に、申請元のユーザＩＤを含む。
・救援要請
本実施形態のゲームのバトルを行う仲間からの救援要請がある場合に、要請元のユーザＩＤを含む。救援要請とは、要請元のユーザのバトルにおいて、要請元のユーザの攻撃力及び防御力が高くなるようにしてバトルに参加することに対する要請である。
・探索開始時刻
本実施形態のゲームには、ユーザがゲーム上で使用する所定数のカードを指定して所定時間の間、自動的に探索を行う機能（自動探索）が設けられている。探索開始時刻は、自動探索が開始された時刻である。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうるが、例えば、後述するクエストやバトルの結果等についての情報を含む。

（５）本実施形態のゲーム
以下、本実施形態のゲームについて、図７〜１１を参照しながら説明する。なお、以下では、ユーザがゲームＢを実行している場合について説明するが、他のゲーム（ゲームＡ，Ｃ，…）についても同様の機能があるものとする。
図７は、ユーザがゲームＢについてのクエストを実行するときの一連のウェブページの一例を示す図ある。図８は、ユーザがゲームＢについてのバトルを実行するときの一連のウェブページの一例を示す図ある。図９は、ユーザがゲームＢについての自動探索を実行するときの一連のウェブページの一例を示す図ある。図１０及び図１１は、ユーザがゲームＢを実行中（クエストを実行中）において、そのユーザのゲームＡにおけるユーザ情報が通知される場合のウェブページの表示例を示す図である。
なお、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネル操作によるウェブページのスクロール操作によって変化しうる。

（５−１）トップページの表示
図７のウェブページＰ１は、本実施形態のゲームＢのトップページの一例であり、個々のユーザＩＤに応じて構成される。図７の例では、キャラクタ画像表示領域１０１、ユーザデータ表示領域１０２、及びメニュー表示領域１０３を含む。
キャラクタ画像表示領域１０１は、対象となるユーザＩＤのユーザデータに含まれる複数のカードに対応するキャラクタ画像のうちユーザによって予め指定されたキャラクタ画像が表示される領域である。
ユーザデータ表示領域１０２は、対象となるユーザＩＤのユーザデータに含まれる、進行レベル、体力ポイント、カード、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域１０２内の「カード」には、ユーザの保有カードの枚数が表示される。また、図８に例示するように、カード数が「４３／５０」と表記されている場合、ユーザの保有カードの枚数が４３枚であり、最大で保有可能なカードの枚数が５０枚であることを示す。体力ポイントが「１００／１００」と表記されている場合、ユーザの現在の体力ポイントが１００であり、現時点でユーザの体力ポイントの最大値も１００であることを示す。ユーザデータ表示領域１０２内の「仲間」には、ユーザの仲間の数が表示される。図８に例示するように、仲間の数が「１２／２０」と表記されている場合、ユーザの現在の仲間の数が１２であり、現時点でユーザが登録可能な仲間の数が２０であることを示す。
メニュー表示領域１０３は、本実施形態のゲームＡに設けられる複数の機能に対応するメニューを表示する領域である。ここでは、メニューの例として、メニューｍ１（「クエスト」）、メニューｍ２（「バトル」）、及びメニューｍ３（「自動探索」）が表示される場合が示されているが、これらに限定されるものではなく、他の処理を実行するメニューを適宜表示してよい。

（５−２）クエスト（図７）
図７のウェブページＰ１上でメニューｍ１（「クエスト」）が選択操作されると、Ｐ２に示すようにウェブページが更新される。このウェブページＰ２には、ユーザがエリアを探索するためのメニューｍ１０（「クエスト実行」）が含まれる。メニューｍ１０が選択操作されると、Ｐ３に示すようにウェブページが更新される。ウェブページＰ３には、メニューｍ１１（「もう一度実行」）が表示され、探索が続行できるようになっている。メニューｍ１０又はメニューｍ１１が選択操作される度に一定の、あるいはランダムな増加量で達成率の値が増加し、達成率が１００％に達するとエリアの探索が終了して次のエリアに進むことができる。メニューｍ１０又はメニューｍ１１が選択操作される度に、ユーザの体力ポイントが所定量（図７の例では、８）だけ消費され、ユーザの経験値が所定量（図７の例では、８）だけ増加する。探索対象のエリアは、複数設けられてもよい。なお、クエスト処理では、メニューｍ１０又はメニューｍ１１が選択操作される度に、所定の、あるいはランダムな確率で、ゲーム上で用意されている様々なカードやアイテムをユーザが入手できるように構成してもよい。入手したカードやアイテムは、例えばウェブページの表示領域２０２に表示される。

クエストを実行する度に体力ポイントが所定量だけ消費（低下）するが、低下後のユーザが保持する体力ポイントを表示するポイント表示領域２０３が設けられている。例えばウェブページＰ２→Ｐ３では体力ポイントが１００→９２に低下したことがわかる。
上述したように、クエストは、体力ポイントを消費しながらゲーム上のエリアをユーザが探索する操作を行って、エリア内のカードやアイテムを入手する処理である。

（５−３）バトル（図８）
図８のウェブページＰ１上でメニューｍ２（「バトル」）が選択操作されると、Ｐ６に示すようにウェブページが更新される。このウェブページＰ６には、カードを用いたバトル相手となる他のユーザの一覧が表示される。この一覧の中からいずれかのユーザが選択されると、Ｐ７に示すようにウェブページが更新される。この例では、ユーザ：ＫＮＭとユーザ：ＡＢＣとの間でバトルが行われる例が示されている。ウェブページＰ７では、メニューｍ１２（「バトル開始」）とメニューｍ１３（「救援要請する」）の２つのメニューが設けられる。例えば、メニューｍ１２が選択操作されると、例えばＰ８に示すようにウェブページが更新される。ウェブページＰ８には、ユーザ：ＫＮＭがバトルで勝利した場合の表示例が示されている。他方、ウェブページＰ７において、メニューｍ１３が選択操作されると、ユーザ：ＫＮＭのすべての仲間に救援要請のメッセージが送信され、その救援要請を受諾した仲間からバトルにおける支援（例えば、バトルに使用するカードの貸し出し等）を受けられるように構成されている。

（５−４）自動探索（図９）
図９のウェブページＰ１上でメニューｍ３（「自動探索」）が選択操作されると、Ｐ１０に示すようにウェブページが更新される。このウェブページＰ６では、例えば予めユーザによって選択された所定数のカードを用いて一定時間（例えば６時間）の探索を実行（開始）するためのメニューｍ１４（「探索開始」）が設けられる。ここでメニューｍ１４を選択操作して一定時間経過すると、Ｐ１１に示すようにウェブページが更新される。その結果、探索に用いられた所定数のカードが例えば６時間後に帰還し、所定数以内のランダムな数のアイテムが入手できるように構成されている。なお、自動探索に使用するカードは、自動探索中の一定時間の間は、例えばバトルでの使用を制限してもよい。

（５−５）ユーザ情報の表示例（図１０、図１１）
本実施形態では、ゲームＢをユーザが実行中に（例えばクエストを実行中に）、ゲームＡにおいてそのユーザのユーザ情報が所定の条件を満たした場合、ゲームＢのウェブページ（ゲーム画像）上で、そのユーザ情報（テキスト）が表示されるように構成されている。
例えば、図１０の（ａ），（ｂ）と図１１の（ａ），（ｂ）はそれぞれ、ユーザがゲームＢにおいてクエストを実行中のウェブページＰ３ｎの案内領域３０１において、ゲームＡにおけるユーザ情報が表示される例が示されている。図１０の（ａ）において、ゲームＡにおけるユーザ情報は、仲間から救援要請が来ているか否かについての情報である。図１０の（ｂ）において、ゲームＡにおけるユーザ情報は、自動探索が終了したか（カードが帰還したか）否かについての情報である。図１１の（ａ）において、ゲームＡにおけるユーザ情報は、ユーザにプレゼントが届いているか否かについての情報である。図１１の（ｂ）において、ゲームＡにおけるユーザ情報は、仲間申請が来ているか否かについての情報である。
なお、図１０及び図１１の各ウェブページの案内領域には、ユーザ情報に加えてゲームＡを実行（開始）するためのバナーＢＮ（操作対象）が表示される好ましい例が示されている。

（６）ゲーム制御装置が備える機能の概要
次に、上述した本実施形態のゲームを実現するためゲーム制御装置が備える機能について、図１２を参照して説明する。図１２は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。なお、登録手段５１、関連付け手段５２、取得手段５６、及び通知手段５７はそれぞれ、本発明に必須の構成要素ではなく、本実施形態のゲーム制御装置を好適にする構成要素である。
本実施形態では、例えば、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した実施形態のゲームが適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、ゲームＡを実行するゲームサーバ２０ａとデータベースサーバ３０ａの場合を例にして説明する。また、ユーザのゲームＡにおけるユーザ情報が、ゲームＢを実行するゲームサーバ２０ｂに提供される場合を想定する。
以下の各機能の説明は、他のゲームサーバ２０ｂ，２０ｃ，…、及びデータベースサーバ３０ｂ，３０ｃ…についても同様の機能を備える。

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

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

ゲーム実行手段５３は、ゲームＡを実行する機能を備える。
本実施形態の場合、ゲームＡの実行は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することでなされる。このとき、ゲームサーバ２０ａのＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０からＨＴＴＰリクエストを受信し、そのＨＴＴＰリクエストによって要求される処理を実行し、その実行結果であるＨＴＭＬデータを含むＨＴＴＰレスポンスを通信端末１０宛に返す。

ＨＴＴＰリクエストによって要求される処理の実行内容は、ゲームに設けられている機能によって異なるが、ゲームＢについて図７〜９に示したのと同様に、ゲームＡについても、クエスト処理、バトル処理、及び自動探索処理を含む。よって、以下の説明では、ゲームＡについて図７〜９を適宜参照する。
［クエスト処理］
例えば図７に関連付けて説明したクエストを実行する場合、ゲームサーバ２０ａのＣＰＵ２１は、ユーザによる所定の選択操作内容（例えば、メニューｍ１０又はｍ１１の選択操作結果）を含むＨＴＴＰリクエストを受信すると、処理対象のユーザの達成率、体力ポイント、及び経験値を更新する処理を行う。ＣＰＵ２１は、ユーザの達成率、体力ポイント、及び経験値のデータを、クエストの実行開始時（メニューｍ１の選択時）にデータベースサーバ３０からＲＡＭ２３に転送し、クエスト中はＲＡＭ２３内のデータに対して更新処理を行い、クエスト終了時に、ＲＡＭ２３内の更新後のデータをデータベースサーバ３０内のデータに上書きするようにしてよい。

［バトル処理］
バトル処理では、ＣＰＵ２１は、バトルの対象となるユーザのカードの攻撃力及び防御力の値に基づく限り、如何なる方法でバトルの勝敗を決定してよい。例えば、ＣＰＵ２１は、ユーザが予め指定したカードの攻撃力と防御力の値の和の大小に応じて勝敗を決定してもよいし、ユーザが保有する一定数のカードの攻撃力と防御力の値の総和の大小に応じて勝敗を決定してもよい。後者の場合、ＣＰＵ２１は、バトルで使用するユーザの一定数のカードについて、ユーザが保有するカードのうち攻撃力と防御力の値の和が大きい順に選択してもよいし、ユーザによる一定数のカードの選択操作の結果に基づいて選択してもよい。なお、ＣＰＵ２１は、バトル相手となる他のユーザの一覧を作成するときには（図８のウェブページＰ６）、処理対象のユーザ（図８では、ユーザ：ＫＮＭ）と同じか、あるいは近い進行レベルのユーザを選択することが好ましい。なお、図８のウェブページＰ６では、バトル相手をユーザが選択する場合を例として説明したが、これに限られない。バトル相手をＣＰＵ２１が自動的に選択するようにしてもよい。

ＣＰＵ２１は、バトル処理中において、ユーザが仲間に対して救援要請を行ったことを認識すると（つまり、図８のメニューｍ１３（「救援要請する」）が選択操作されたことを認識すると）、そのユーザの仲間全員、あるいはゲームＡにログイン中の仲間に対して、救援要請メッセージを含むＨＴＭＬデータを送信するとともに、仲間のユーザデータの「救援要請」の項目に、救援要請元のユーザＩＤを書き込む。ＣＰＵ２１は、仲間から救援要請に対する承諾メッセージを受信すると、要請元のユーザに有利となるようにバトル結果を調整する。例えば、仲間から要請元ユーザへのカードの貸し出しが行われ、バトルにおいて要請元ユーザの攻撃力等のパラメータを増加させる処理が行われる。

［自動探索処理］
自動探索処理では、ＣＰＵ２１は、探索開始のメニュー（例えば、図９のメニューｍ１４）の選択操作を認識すると、その時刻を探索開始時刻として、処理対象のユーザのユーザデータに書き込む。また、ＣＰＵ２１は、逐次各ユーザについて書き込まれている探索開始時刻から一定時間（例えば６時間）が経過したか否かを判定し、一定時間が経過したと判定した場合には、ユーザデータの探索開始時刻のデータを消去するとともに、所定数以下のアイテムについての抽選処理を行って、自動探索によってユーザに付与するアイテムを決定する。付与するアイテムを決定すると、ＣＰＵ２１は、処理対象のユーザのユーザデータの保有アイテムの項目にそのアイテムを書き込む。

判定手段５４は、ユーザに関するゲーム上の情報であるユーザ情報がゲームＡ（第１ゲーム）において所定の条件を満たすか否かを判定する機能を備える。「所定の条件」は、例えばユーザに通知しようとするユーザ情報に基づいて適宜設定することができる。例えば、ユーザ情報が、ユーザ宛にゲーム上の救援要請が届いているか否かについての情報である場合、ユーザ宛にゲーム上の救援要請が届いているときに所定の条件を満たすと判定してもよい。ユーザデータに含まれるいずれかの情報はすべてユーザ情報となりうる。
判定手段５４の機能を実現するために、ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報として例えばユーザデータに含まれるデータのうち予め特定されたデータが所定の条件を満たすか否か、ユーザ毎に逐次判定する。ＣＰＵ２１は、例えば、ユーザ情報として、ユーザデータ内の救援要請の情報（他のユーザからの救援要請がある場合にはその要請元のユーザＩＤ）を参照して、救援要請がある場合には、所定の条件を満たしたと判定する。

提供手段５５は、判定手段５４により所定の条件を満たすと判定された場合に、ユーザについてゲームＡ（第１ゲーム）とは異なるゲームとして例えばゲームＢ（第２ゲーム）を実行するゲームサーバ２０ｂ（第２ゲーム制御装置）にユーザ情報を提供するか、又はゲームサーバ２０ｂ（第２ゲーム制御装置）がユーザ情報を取得可能な状態とする機能を備える。
「ユーザ情報をゲームサーバ２０ｂが取得可能な状態とする」とは、ゲームサーバ２０ａがゲームサーバ２０ｂに対してユーザ情報へのアクセスを許可する場合や、ゲームサーバ２０ａが特定の装置（例えば上位サーバ）にユーザ情報を転送し、ゲームサーバ２０ｂがその特定の装置からユーザ情報を取得する（つまり、間接的に取得する）場合を含む。
ゲームサーバ２０ａからゲームサーバ２０ｂへゲームＡにおけるユーザ情報を提供する方法は様々な方法を採ることができるが、例えば、ゲームサーバ２０ａのＡＰＩサーバ２６が、ＨＴＴＰを利用してゲームサーバ２０ｂのＡＰＩサーバ２６宛に、所定のユーザ情報を受け付けるようにリクエストを行い、リクエストを受けたゲームサーバ２０ｂのＡＰＩサーバ２６が、その所定の情報を正しく受け付けたか（取得したか）否かの結果をリクエストの要請元のゲームサーバ２０ａのＡＰＩサーバ２６に対して返すようにする。
特定の装置を介して間接的に、ゲームサーバ２０ａからゲームサーバ２０ｂへゲームＡにおけるユーザ情報を提供する場合には、同様にＷｅｂＡＰＩを利用してゲームサーバ２０ａのＡＰＩサーバ２６から特定の装置に対してユーザ情報を転送しておき、ゲームサーバ２０ｂのＡＰＩサーバ２６は逐次、特定の装置にアクセスして、その特定の装置に置かれているゲームＡにおけるユーザ情報を取得するようにする。あるいは、ユーザ情報を受信した特定の装置がゲームサーバ２０ｂへ転送するようにしてもよい。

取得手段５６は、処理対象のユーザについて、ゲームＡ（第１ゲーム）と異なるゲームとして例えばゲームＣ（第３ゲーム）を実行するゲームサーバ２０ｃ（第３ゲーム制御装置）から、ゲームＣにおけるユーザ情報の提供を受けるか、又は当該ユーザ情報を取得する機能を備える。
「ユーザ情報をゲームサーバ２０ｃから取得する」とは、ゲームサーバ２０ａがゲームサーバ２０ｃからユーザ情報の提供を受ける場合や、ゲームサーバ２０ｃが特定の装置（例えば上位サーバ）にユーザ情報を転送し、ゲームサーバ２０ａがその特定の装置からユーザ情報を取得する（つまり、間接的に取得する）場合を含む。
ゲームサーバ２０ｃからゲームサーバ２０ａへゲームＣにおけるユーザ情報を提供する方法は様々な方法を採ることができるが、例えば、ゲームサーバ２０ｃのＡＰＩサーバ２６が、ＨＴＴＰを利用してゲームサーバ２０ａのＡＰＩサーバ２６宛に、所定のユーザ情報を受け付けるようにリクエストを行い、リクエストを受けたゲームサーバ２０ａのＡＰＩサーバ２６が、その所定の情報を正しく受け付けたか（取得したか）否かの結果をリクエストの要請元のゲームサーバ２０ｃのＡＰＩサーバ２６に対して返すようにする。
特定の装置を介して間接的に、ゲームサーバ２０ｃからゲームサーバ２０ａへゲームＣにおけるユーザ情報を提供する場合には、同様にＷｅｂＡＰＩを利用してゲームサーバ２０ｃのＡＰＩサーバ２６から特定の装置に対してユーザ情報を転送しておき、ゲームサーバ２０ａのＡＰＩサーバ２６は逐次、特定の装置にアクセスして、その特定の装置に置かれているゲームＣにおけるユーザ情報を取得するようにする。あるいは、ユーザ情報を受信した特定の装置がゲームサーバ２０ａへ転送するようにしてもよい。

通知手段５７は、取得手段５６がゲームＡ（第１ゲーム）と異なるゲームとして例えばゲームＣ（第３ゲーム）におけるユーザ情報の提供を受けるか、又は当該ユーザ情報を取得した場合、当該ユーザ情報をゲームＡ（第１ゲーム）のゲーム画像に表示させる（つまり、通知する）機能を備える。
例えば、通知手段５７の機能は、以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｃ（第３ゲーム制御装置）から、処理対象となるユーザのユーザ情報を取得すると、例えば、ユーザによる所定の選択操作内容を含むＨＴＴＰリクエストに応じて、ゲームＣにおけるユーザ情報を含むＨＴＭＬデータをユーザの通信端末１０宛に送信する。これによって、ユーザの通信端末１０には、ゲームＣにおけるユーザ情報を含むウェブページ（ゲーム画像）が表示される。なお、ユーザの通信端末１０宛に送信するＨＴＭＬデータには、ゲームＣにおけるユーザ情報に加えて、ゲームＣを実行（開始）するためのバナー（操作対象）を含むことが好ましい。

（７）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲームシステムにより行われる主要な処理のフローの一例について、図１３のシーケンスチャートを参照して説明する。なお、図１３のシーケンスチャートでは、ユーザがゲームＢを実行中に、ゲームＢのウェブページ（ゲーム画像）にユーザＡにおけるユーザ情報が表示される場合の例である。

図１３では、特定のユーザＵ１がゲームＢを実行中であることが想定されており、ユーザＵ１の通信端末１０からゲームサーバ２０ｂ宛に、ウェブページを更新するためのＨＴＴＰリクエストがユーザの所望のタイミングで送信される（ステップＳ１００）。
ゲームサーバ２０ａでは、ユーザＵ１からのアクセスはないが、ゲームＡで発生する様々なイベントによって、ユーザＵ１のゲームＡにおけるユーザ情報が更新される。例えば、図１０及び図１１で示したように、例えば、以下のユーザ情報が更新される場合がある。

・ユーザＵ１の仲間から救援要請が来ている場合にその要請元ユーザＩＤの情報
・ユーザＵ１による自動探索が終了したか否かについての情報
・ユーザＵ１にプレゼントが届いているか否かについての情報
・ユーザＵ１に対して仲間申請が来ている場合にその申請元ユーザＩＤの情報

ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報として、ユーザＵ１のユーザデータに含まれるデータのうち予め特定されたデータ（上述した例では、「救援要請」、「探索開始時刻」、「プレゼント」、「仲間申請」；図６参照）を読み出し（ステップＳ１１０）、所定の条件を満たすか否かについて逐次判定する（ステップＳ１２０）。

ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報が所定の条件を満たすと判定した場合には（ステップＳ１２０：ＹＥＳ）、他のゲームサーバ２０ｂ，２０ｃ，…に対してゲームＡにおけるユーザ情報を提供する（ステップＳ１３０）。ステップＳ１３０のユーザ情報の提供に対して、ユーザＵ１からのアクセスがないゲームサーバ２０（この場合、ゲームサーバ２０ｂ以外のゲームサーバ）は実質的に何も行わない。このシーケンスチャートの例では、ゲームサーバ２０ｂがユーザＵ１の通信端末１０からアクセスがなされているため、以降の処理を行う。
なお、ゲームサーバ２０ａからゲームサーバ２０ｂへのユーザ情報の受け渡しは、例えば以下のように行われる。ゲームサーバ２０ｂへ例えば、ゲームサーバ２０ａのＡＰＩサーバ２６が、ＨＴＴＰを利用してゲームサーバ２０ｂのＡＰＩサーバ２６宛に、所定のユーザ情報を受け付けるようにリクエストを行い、リクエストを受けたゲームサーバ２０ｂのＡＰＩサーバ２６が、その所定の情報を正しく受け付けたか（取得したか）否かの結果をリクエストの要請元のゲームサーバ２０ａのＡＰＩサーバ２６に対して返すようにする。
他方、ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報が所定の条件を満たさないと判定した場合には（ステップＳ１２０：ＮＯ）、何も実行しない。

ゲームサーバ２０ｂのＣＰＵ２１は、ゲームサーバ２０ａから、ユーザＵ１のゲームＡにおけるユーザ情報を取得すると、その時点でユーザＵ１の通信端末１０から受信しているＨＴＴＰリクエスト（ステップＳ１００）に応じた、ゲームＢのユーザＵ１向けのウェブページに反映される。すなわち、ゲームサーバ２０ｂのＣＰＵ２１は、ステップＳ１３０で受信した、ユーザＵ１のゲームＡにおけるユーザ情報を含むようにして、ＨＴＭＬデータを生成し（ステップＳ１４０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１５０）。これによって、ユーザＵ１の通信端末１０には、ゲームＡにおけるユーザ情報を含むウェブページ（ゲーム画像）が表示される（ステップＳ１６０）。ユーザＵ１の通信端末１０宛に送信するＨＴＭＬデータには、ゲームＡにおけるユーザ情報に加えて、ゲームＡを実行（開始）するためのバナー（操作対象）を含むことが好ましい。

なお、ステップＳ１３０においてユーザ情報を受信した時点で、ゲームサーバ２０ｂに対してユーザＵ１の通信端末１０からアクセスがない場合には、そのユーザ情報はデータベースサーバ３０ｂに一時的に記憶させておくことが好ましい。その場合、ユーザＵ１の通信端末１０からゲームサーバ２０ｂに対してアクセスが生じた後に送信するＨＴＭＬデータに、一時的に記憶させておいたユーザ情報を含ませるようにする。

以上説明したように、本実施形態のゲームシステムでは、ユーザＵ１についてのユーザ情報がゲームＡ（第１ゲーム）において所定の条件を満たす場合、そのユーザ情報は、そのユーザについてゲームＡとは別のゲームＢ（第２ゲーム）を実行するゲームサーバ２０ｂ（第２ゲーム制御装置）に提供される。そのため、ゲームＢを実行中のユーザＵ１は、ゲームＡについての自らの情報（ユーザ情報）を知ることができる。なお、ユーザＵ１がゲームＢを実行していない場合でも、その後にゲームＢを実行（開始）してから、ゲームＡについてのユーザ情報を知ることができる。よって、ユーザは、ゲームＡについて適時に情報を得ること、あるいはゲームＡにアクセスして適時に所要の操作を行うことができる。例えばゲームＡが、ユーザが実行を指示してから結果が出るまでに所定の時間を要するゲームの場合、ゲームＢを実行中にゲームＡの結果が出た旨の通知を受けると、ゲームＢを一時中断してゲームＡを実行し、その後再びゲームＢを実行しながらゲームＡの結果が出るのを待つ、といった具合に、プレイ中のゲームと異なる他のゲームの情報を得ることができるからこそ可能な効率の良いプレイをユーザは実行することができる。

（８）特記事項
上述した実施形態において、通知手段５７を設けることは必須ではない。つまり、上述したように、処理対象となるユーザの通信端末１０からのアクセスが生じていない場合には、ユーザ情報を取得したゲームサーバ２０は、そのユーザ情報をデータベースサーバ３０に一時的に記憶しておけばよい。
上述した実施形態で説明したように、ゲームサーバ２０が特定のユーザのユーザ情報を取得した時点で、そのユーザがアクセスしている場合には、取得したユーザ情報をそのユーザの通信端末１０宛に通知することが好ましい。これにより、特定のゲームを実行中のユーザは、直ちにそのゲームとは異なるゲームにおけるユーザ情報を認識することができる。すなわち、実行中のゲームと異なる他のゲームの情報を有効に活用できる可能性があるユーザに他のゲームの情報を提供することができる。

上述した実施形態において、ユーザ情報は、体力ポイント（ユーザに関連付けられ、ゲームの実行によって消費され、時間の経過とともに回復し、かつユーザのゲーム上の進行レベルが上昇する度に完全に回復するゲーム上のパラメータ）であってもよい。その場合、判定手段５４における「所定の条件」は、体力ポイントがユーザのゲーム上の進行レベルを上昇可能とする値まで回復したことであってもよい。
ユーザは、ゲームＡ（第１ゲーム）とは別のゲームＢ（第２ゲーム）を実行することでゲームＡにおける体力ポイントが回復するのを待ち、体力ポイントが完全に回復したらゲームＡを再度実行したいと考えている場合がある。その場合に、この構成によれば、ゲーム上の進行レベルが上昇すれば体力ポイントが完全に回復されるため、ゲーム上の進行レベルが上昇可能とする値まで待ってからゲームＡを再開すれば、時間の経過によって体力ポイントが完全に回復するまで待たずに済むため、無駄なく効率的にゲームＡを再開することができる。上記構成によれば、ゲームＢを実行中に、ゲームＡのパラメータが効率良くゲームを実行するに必要な値まで回復したことを通知することができる。これによってユーザはゲームＡを無駄なく実行することができる。

「所定の条件」を体力ポイントがユーザのゲーム上の進行レベルを上昇可能とする値まで回復したことにする場合、ゲームサーバ２０ａのＣＰＵ２１は、以下のようにして条件を満足したか否か判定する。例えば、上述したゲームＡにおいて、ユーザがクエストを１回実行する度に体力ポイントを１０消費し、経験値が１０上昇し、経験値が１００になった場合には、進行レベルが１上昇して経験値がゼロにリセットされる場合を想定する。進行レベルが１上昇する度に、体力ポイントが最大値の８０まで完全に回復する。ここで、ユーザのゲームＡにおける現在の経験値が６０であった場合には、クエストを４回実行する（体力ポイントを４０消費し、経験値を４０上昇させる）ことで、経験値が１００に到達して体力ポイントが完全に回復することになる。このような場合には、ゲームＡにおいてクエストを４回実行可能な程度の体力ポイント（この場合、４０）まで回復した場合に、ゲームＢを実行中のユーザに、ゲームＡにおいてレベルアップが可能になった程度の体力ポイントまで回復したことが通知される。つまり、体力ポイントが最大値の８０まで（つまり、完全に）回復するまでゲームＡを再開せずにゲームＢを実行しつつ待機する必要がない。

このような通知方法を実現するために、ゲームサーバ２０ａのＣＰＵ２１は、体力ポイントがユーザのゲーム上の進行レベルを上昇可能とする値まで回復したか否かについて、以下のようにして判断する。ゲームサーバ２０ａのＣＰＵ２１は、処理対象のユーザのユーザデータベースにアクセスしてユーザの体力ポイントと経験値のデータを読み出し、当該データと、処理対象のユーザが直近で実行していたクエストのデータ（１回の実行によって消費する体力ポイントと増加する経験値のデータ）とに基づいて、現在の経験値が最大値に達するのに要するクエストの実行回数を算出する。次いでゲームサーバ２０ａのＣＰＵ２１は、算出した実行回数に対して、１回の実行によって消費する体力ポイントを乗算することで、処理対象のユーザのゲーム上の進行レベルを上昇可能とする体力ポイントの値を算出する。ゲームサーバ２０ａのＣＰＵ２１は、算出した体力ポイントの値まで回復したか否かを逐次判断する。以上の処理がユーザ毎に行われる。
なお、「体力ポイントが回復する条件」は、進行レベルの上昇に限られるものではない。例えば、複数のステージで構成されたゲームにおいて、体力ポイントを消費しながらクエストを実行し、クエストを実行する度に達成度を積み重ねて１００％に達すると体力ポイントが完全に回復して次のステージに進むことが可能なゲームの場合、体力ポイントが回復する条件は、次のステージに進むことであってもよい。

上述した実施形態において、通知手段５７は、ゲームＣ（第３ゲーム）の体力ポイント（パラメータ）がユーザのゲーム上の進行レベルを上昇可能とする値まで回復した時刻、又は当該時刻からの経過時間をゲームＡ（第１ゲーム）のウェブページ（ゲーム画像）に表示させてもよい。
この構成では、ゲームＡをユーザが実行している場合に、ゲームＣの体力ポイントがユーザのゲーム上のレベルを上昇可能とする値まで回復した時刻、又は当該時刻からの経過時間がゲームＡのウェブページに表示される。そのためユーザは、ゲームＡを止めてゲームＣを実行すべきか否かについて、適時に検討することができる。この場合、ゲームサーバ２０ｃのＣＰＵ２１は、ユーザデータに逐次アクセスして、体力ポイントがユーザのゲーム上のレベルを上昇可能とする値まで回復したと判断すると、その時刻を記憶しておき、当該時刻、又は当該時刻からの経過時間についての情報を定期的に、ＡＰＩサーバ２６経由でゲームサーバ２０ａへ送信する。情報を受信したゲームサーバ２０ａのＣＰＵ２１は、対象となるユーザ向けのＨＴＭＬデータに、当該時刻、又は経過時間の情報を含ませるようにする。
時刻の表示、又は経過時間のウェブページ上の表示の例として、「xx時xx分に体力が十分に回復しました」や、「体力が十分に回復してからxx分経過しました」などが挙げられる。

なお、通知手段５７は、ゲームＣ（第３ゲーム）を実行するためのバナー（操作対象）を、上述した経過時間（ゲームＣの体力ポイントがゲーム上の進行レベルを上昇可能とする値まで回復してからの経過時間）に応じて表示態様が変化するようにして表示してもよい。これにより、ゲームＡを実行中のユーザが、ゲームＡを止めてゲームＣを実行する場合の操作性を向上させることができる。表示態様の変化として、経過時間が長くなるにつれてバナーをより目立つように変化させてもよい。例えば、バナーの表示サイズを大型化する、バナーの表示色数を増加させる等が考えられる。

上述した実施形態では、通知手段５７が、他のゲーム（第３ゲーム）のユーザ情報をゲームＡ（第１ゲーム）のウェブページ（ゲーム画像）に表示させる場合について説明したが、通知方法はこれに限られない。ユーザへの通知方法は、ゲーム情報をウェブページに表示する方法以外にも、ゲーム情報を音声によって出力する方法であってよい。なお、ユーザ情報をウェブページに表示させる通知方法を採った場合には、音声出力が制限される環境（例えば、電車内等の公共交通機関内）においても、ユーザがユーザ情報を認識することができるという利点がある。

上述したように、通知手段５７は、他のゲーム（第３ゲーム）のユーザ情報をゲームＡ（第１ゲーム）を実行しているユーザに通知するとともに、他のゲーム（第３ゲーム）を実行（開始）するためのバナー（操作対象）を表示させてもよい。これによって、ユーザは、実行中のゲームＡとは異なる他のゲーム（第３ゲーム）の実行を直ちに開始することができる。例えば、ユーザは、ゲームＡを実行中に他のゲームについてのユーザ情報の通知を受けた結果、他のゲームを実行（開始）したいと考えた場合には、ユーザは、その通知を受けた時点で第１ゲームから他のゲーム（第３ゲーム）に円滑に移行することができるようになる。

上述した実施形態において例示したが、判定手段５４における所定の条件は、本実施形態のゲームにおいて自動探索が終了したことであってよい。つまり、所定の条件は、例えばユーザが実行していないゲームＡ（第１ゲーム）において所定時間を要する処理が完了したことであってもよい。ゲームＡ（第１ゲーム）において自動探索処理が行われているときには、ユーザは、ゲームＡとは異なる、例えばゲームＢ（第２ゲーム）を実行することでゲームＡにおける自動探索が終了するのを待ち、その自動探索が終了したらゲームＡを再度実行したいと考えている場合がある。その場合に、本実施形態のゲーム制御装置では、ゲームＢを実行中に、ゲームＡの処理が完了したことを通知することができる。

上述した実施形態において、関連付け手段５２を設けることは必須でないが、関連付け手段５２を設けた場合には、ユーザ情報を、仲間から救援要請等、仲間からの通知が来ているか否かについての情報とすることができる。この場合、判定手段５４における所定の条件は、例えばユーザが実行していないゲームＡ（第１ゲーム）において救援要請等の仲間からの通知が行われたことであってもよい。仲間からの通知があった場合には、その通知に対して迅速に応答することをユーザが望んでいる場合がある。その場合に、本実施形態のゲーム制御装置では、他のゲーム（第２ゲーム）を実行中に、ゲームＡ（第１ゲーム）の仲間からの通知があったことをユーザに適時に知らせることができる。同様にして、ゲームＡ（第１ゲーム）を実行中に、他のゲーム（第３ゲーム）の仲間からの通知が行われたことをユーザに適時に知らせることができる。

上述した実施形態の説明では、図１３のステップＳ１３０，Ｓ１４０に示したように、他のゲーム（この場合は、ゲームＡ）についてのユーザ情報を受信したゲームサーバ２０ｂ（ユーザが実行中のゲームＢのゲームサーバ）のＣＰＵ２１は、その受信したユーザ情報を、対象となるユーザ宛の直近のＨＴＭＬデータに含ませるようにしたが、これに限られない。ユーザ情報を反映させるタイミングは、適宜設定することができる。図１３において、ゲームサーバ２０ｂのＣＰＵ２１は、受信したユーザ情報を直ちに反映させるのではなく、ユーザが現在実行中のクエストの区切りのタイミングで、ＨＴＭＬデータにユーザ情報を含ませるようにしてもよい。この場合のユーザ情報の表示態様を図１４に例示する。図１４では、ゲームＢにおいて、例えばエリア３−１におけるクエストが完了した（達成率が１００％になった）タイミングで、ユーザ情報（ゲームＡにおいて、プレゼントが届いているか否かについての情報）が表示される。このように、ゲームＢの区切りのタイミングでユーザ情報が表示されると、ユーザは、ゲームＢの進行を妨げられずに済む。

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

（１）ゲームシステムの構成
本実施形態では、第１の実施形態のゲームシステムとは異なるシステム構成について説明する。
図１５は、本実施形態のゲームシステムのシステム構成例を示している。図１５に示すゲームシステムにおいて、図１に示したゲームシステムの構成要素と同じものについては同一の符号を付してある。本実施形態のゲームシステムにおいて、統括サーバ１００は、各ゲームサーバ２０ａ，２０ｂ，２０ｃ，…と直接接続されるか、あるいはネットワーク（図示せず）を介して接続可能に構成されている。
本実施形態では、統括サーバ１００は、各ゲームサーバ２０のユーザ情報を一元的に管理している。例えば、各ゲームサーバ２０において、ユーザ情報が更新されると、逐次統括サーバ１００に送信されて、統括サーバ１００内のＨＤＤ(Hard Disk Drive)等の大容量記憶装置（図示せず）等に記憶・更新される。ゲームサーバ２０間でユーザ情報の授受を行うときには、ユーザ情報を取得しようとするゲームサーバ２０は、統括サーバ１００に対して、ユーザＩＤとユーザ情報の取得対象となるゲームとを含むリクエストを送信し、統括サーバ１００がそのリクエストに応じてレスポンスを返すようにする。従って、ゲームサーバ２０のＡＰＩサーバ２６を通した直接的なデータ授受を行わない点で、第１の実施形態のゲームシステムとは異なる。

（２）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲームシステムにより行われる主要な処理のフローの一例について、図１６のシーケンスチャートを参照して説明する。なお、図１６のシーケンスチャートは、図１３と同様に、ユーザがゲームＢを実行中に、ゲームＢのウェブページ（ゲーム画像）にユーザＡにおけるユーザ情報が表示される場合の例である。

図１６では、特定のユーザＵ１がゲームＢを実行中であることが想定されており、ユーザＵ１の通信端末１０からゲームサーバ２０ｂ宛に、ウェブページを更新するためのＨＴＴＰリクエストがユーザの所望のタイミングで送信される（ステップＳ１００）。
ゲームサーバ２０ａでは、ユーザＵ１からのアクセスはないが、ゲームＡで発生する様々なイベントによって、ユーザＵ１のゲームＡにおけるユーザ情報が更新される。ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報として、ユーザＵ１のユーザデータに含まれるデータのうち予め特定されたデータを読み出し（ステップＳ１１０）、所定の条件を満たすか否かについて逐次判定する（ステップＳ１２０）。

ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報が所定の条件を満たすと判定した場合には（ステップＳ１２０：ＹＥＳ）、統括サーバ１００へゲームＡにおけるユーザ情報を送信する（ステップＳ１３２）。統括サーバ１００は、ユーザ情報を受信するとそのユーザ情報をユーザＩＤと対応付けてＨＤＤに記憶させる（ステップＳ１３４）。
ゲームサーバ２０ｂは、統括サーバ１００に記憶されているユーザＵ１のゲームＡにおけるユーザ情報を取得する。このユーザ情報の取得方法は、例えば、例えば、ゲームサーバ２０ｂのＡＰＩサーバ２６が、ＨＴＴＰを利用して統括サーバ１００のＡＰＩサーバ（図示せず）宛に、ユーザＵ１のユーザ情報に対するリクエストを行い（ステップＳ１３４）、そのリクエストを受けた統括サーバ１００のＡＰＩサーバが、そのユーザ情報を含むレスポンスを返す（ステップＳ１３６）方法であってよい。
あるいは、統括サーバ１００は、各ゲームサーバ２０のうちいずれのゲームサーバにユーザＵ１がアクセスしているか逐次認識するように構成し、ユーザＵ１のゲームＡにおけるユーザ情報を取得すると、ユーザＵ１がアクセスしているゲームサーバ２０宛にユーザ情報を転送するようにしてもよい。この場合、統括サーバ１００は、ユーザのゲームサーバ２０へのログイン及びログアウトの度に各ゲームサーバ２０から統括サーバ１００宛に通知することで、統括サーバ１００が、ユーザＵ１がアクセスしているゲームサーバ２０を認識できるようにしておけばよい。
ステップＳ１４０以降の処理は、図１３と同一であるため重複説明を省略する。

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

上述した各実施形態において、ユーザ情報の例をいくつか挙げたがユーザ情報はこれらに限られない。例えば、ユーザ情報は、体力ポイントでもよい。また、ゲームキャラクタの攻撃力及び防御力がゲームの進行に応じて変動するバトルゲームの場合には、ユーザ情報は、その攻撃力及び防御力を示すゲームキャラクタのパラメータの値であってもよい。
また、ユーザ情報は、ゲームに応じて適宜設定することができる。例えば、作物をユーザが成長させていくゲームの場合には、ユーザが保有する特定の作物が一定の成長度合いに達した場合に、ユーザ情報が所定の条件を満たしたと判定してもよい。

上述した実施形態では、理解の容易のために、各ゲームサーバ２０で実行されるゲームの機能が共通する場合について説明したが、各ゲームサーバ２０で実行されるゲームは、それぞれ異なる機能（つまり、異なる性質のゲーム）であってよい。つまり、ユーザ情報の定義とユーザ情報の判定条件は、ゲーム毎に設定できるため、各ゲームサーバ２０で実行されるゲームは、共通する機能を備えている必要はない。

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

上述した実施形態では、ゲームサーバ２０間の通信や、ゲームサーバ２０と統括サーバ１００の間の通信がＷｅｂＡＰＩによるＨＴＴＰを利用して行われる場合について説明したが、これに限られない。公知の有線又は無線の通信プロトコルを適宜利用してよい。

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

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

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

Claims (15)

1. 第１ゲームを実行する実行手段と、
   ユーザに関するゲーム上の情報であるユーザ情報が前記第１ゲームにおいて所定の条件を満たすか否かを判定する判定手段と、
   前記判定手段により前記所定の条件を満たすと判定された場合に、前記ユーザについて前記第１ゲームとは異なる第２ゲームを実行する第２ゲーム制御装置に前記ユーザ情報を提供するか、又は前記第２ゲーム制御装置が前記ユーザ情報を取得可能な状態とする提供手段と、
   を備えた、ゲーム制御装置。
2. 前記ユーザについて、前記第１ゲームと異なる第３ゲームを実行する第３ゲーム制御装置から、前記第３ゲームのユーザ情報の提供を受けるか、又は当該ユーザ情報を取得する取得手段と、
   前記取得手段が前記第３ゲームのユーザ情報の提供を受けるか、又は当該ユーザ情報を取得した場合、当該第３ゲームのユーザ情報を前記ユーザに通知する通知手段、をさらに備えた、
   請求項１に記載されたゲーム制御装置。
3. 前記通知手段は、前記第３ゲームのユーザ情報を前記第１ゲームのゲーム画像に表示させる、
   請求項２に記載されたゲーム制御装置。
4. 前記通知手段は、前記第１ゲームの区切りのタイミングで、前記第３ゲームのユーザ情報を前記第１ゲームのゲーム画像に表示させる、
   請求項３に記載されたゲーム制御装置。
5. 前記通知手段は、前記第３ゲームのユーザ情報を前記ユーザに通知するとともに、当該第３ゲームを実行するための操作対象を表示する、
   請求項３または４に記載されたゲーム制御装置。
6. 前記所定の条件は、前記第１ゲームにおいて所定時間を要する処理が完了したことである、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記ユーザ情報は、前記ユーザに関連付けられ、ゲームの実行によって消費され、時間の経過とともに回復し、かつゲームの実行によってゲーム上の回復条件を充足する度に回復するゲーム上のパラメータであって、
   前記所定の条件は、前記パラメータが、前記回復条件を充足するまで前記ゲームを実行可能な値に回復したことである、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
8. 前記ユーザ情報は、前記ユーザに関連付けられ、ゲームの実行によって消費され、時間の経過とともに回復し、かつゲームの実行によってゲーム上の回復条件を充足する度に回復するゲーム上のパラメータであって、
   前記通知手段は、前記第３ゲームの前記パラメータが、前記第３ゲームの実行によって前記回復条件を充足可能とする値まで回復した時刻、又は当該時刻からの経過時間を、前記第１ゲームのゲーム画像に表示させる、
   請求項２〜５のいずれかに記載されたゲーム制御装置。
9. 前記回復条件は、ユーザのゲーム上のレベルが上昇することであり、
   前記所定の条件は、前記パラメータがユーザのゲーム上のレベルを上昇可能とする値まで回復したことである、
   請求項７又は８に記載されたゲーム制御装置。
10. 前記通知手段は、前記第３ゲームを実行するための操作対象を、前記経過時間に応じて表示態様が変化するようにして表示する、
    請求項８に記載されたゲーム制御装置。
11. ユーザ間を関連付ける関連付け手段をさらに備え、
    前記所定の条件は、前記第１ゲームにおいて、前記関連付け手段によって前記ユーザと関連付けられた他のユーザによる通知が行われたことである、
    請求項１〜５のいずれかに記載されたゲーム制御装置。
12. ユーザ間を関連付ける関連付け手段をさらに備え、
    前記第３ゲームのユーザ情報は、前記第３ゲームにおいて、前記関連付け手段によって前記ユーザと関連付けられた他のユーザによる通知が行われたことを示す情報である、
    請求項２〜５のいずれかに記載されたゲーム制御装置。
13. コンピュータに、
    第１ゲームを実行する機能、
    ユーザに関するゲーム上の情報であるユーザ情報が前記第１ゲームにおいて所定の条件を満たすか否かを判定する機能、及び、
    前記所定の条件を満たすと判定された場合に、前記ユーザ情報を、前記ユーザについて前記第１ゲームとは異なる第２ゲームを実行する第２ゲーム制御装置に提供するか、又は第２ゲーム制御装置が取得可能な状態とする機能、
    を実現させるためのプログラム。
14. 通信端末からのアクセスに応じて第１ゲームを実行し、第１ゲーム上でユーザに関連する情報であるユーザ情報をユーザ毎に記憶装置に記憶し、又は更新する第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行し、第２ゲーム上でユーザに関連する情報であるユーザ情報をユーザ毎に記憶装置に記憶し、又は更新する第２サーバと、
    を含むゲームシステムにおけるゲーム制御方法であって、
    第１サーバが、ユーザの前記第１ゲームのユーザ情報が所定の条件を満たすか否かを判定するステップと、
    前記所定の条件を満たすと判定された場合に、第１サーバが、前記ユーザの前記第１ゲームのユーザ情報を、第２サーバに提供するか、又は第２サーバが取得可能な状態とするステップと、
    第２サーバが、第１サーバによって提供され、又は取得可能な状態とされた前記ユーザの前記第１ゲームのユーザ情報を、前記ユーザの通信端末に送信するステップと、
    を含む、ゲーム制御方法。
15. 通信端末からのアクセスに応じて第１ゲームを実行し、第１ゲーム上でユーザに関連する情報である第１ユーザ情報をユーザ毎に記憶装置に記憶し、又は更新する第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行し、第２ゲーム上でユーザに関連する情報である第２ユーザ情報をユーザ毎に記憶装置に記憶し、又は更新する第２サーバと、
    を含むゲームシステムあって、
    第１サーバは、
    ユーザの第１ゲームのユーザ情報が所定の条件を満たすか否かを判定する判定手段と、
    前記判定手段により前記所定の条件を満たすと判定された場合に、前記ユーザの第１ゲームのユーザ情報を、第２サーバに提供するか、又は第２サーバが取得可能な状態とする提供手段と、を備え、
    第２サーバは、
    第１サーバによって提供され、又は取得可能な状態とされた前記ユーザの前記第１ゲームのユーザ情報を、前記ユーザの通信端末に送信する通知手段、を備えた、
    ゲームシステム。

Images