JP2013255526A - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム - 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）などの端末の個体識別情報、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。登録処理は、ＣＰＵ２１が、ユーザＩＤに対応するユーザデータを生成し、ユーザデータベース３１に格納する処理を含む。登録が完了すると、ユーザは、本実施形態のゲームを実行することが可能となる。登録が完了後、ＣＰＵ２１は、各ユーザの通信端末１０からログインのためのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。

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

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

ＨＴＴＰリクエストによって要求される処理の実行内容は、ゲームに設けられている機能によって異なるが、例えば以下のとおりである。
例えば図７に関連付けて説明したクエストを実行する場合、ゲームサーバ２０ａのＣＰＵ２１は、ユーザによる所定の選択操作内容（例えば、メニューｍ１０又はｍ１１の選択操作結果）を含むＨＴＴＰリクエストを受信すると、処理対象のユーザの達成率、体力ポイント、及び経験値を更新する処理を行う。ＣＰＵ２１は、ユーザの達成率、体力ポイント、及び経験値のデータを、クエストの実行開始時（メニューｍ１の選択時）にデータベースサーバ３０からＲＡＭ２３に転送し、クエスト中はＲＡＭ２３内のデータに対して更新処理を行い、クエスト終了時に、ＲＡＭ２３内の更新後のデータをデータベースサーバ３０内のデータに上書きするようにしてよい。
例えば他のユーザとの間でのカードを用いたバトルを実行する場合には、ゲームサーバ２０ａのＣＰＵ２１は、バトル対象となるユーザのバトルにおける使用カードのパラメータ（例えば、攻撃力及び防御力の値等）の値を比較し、その比較結果に基づいてバトルの勝敗を決定してもよい。

第１判定手段５４は、ユーザによるゲームＡ（第１ゲーム）の実行状況が第１条件を満たすか否かを判定する機能を備える。本実施形態では、第１条件は、例えばユーザが実行中のゲームＡの体力ポイントが所定値以下となり、クエストを実行することができない場合である。
第１判定手段５４の機能を実現するために、ゲームサーバ２０ａのＣＰＵ２１は、ユーザによる所定の選択操作内容（例えば、メニューｍ１０又はｍ１１の選択操作結果）を含むＨＴＴＰリクエストを受信すると、前述したように体力ポイントを更新する処理を行う。この処理において、ユーザの体力ポイントとクエスト実行に必要な体力ポイントを比較して、ユーザの体力ポイントの方が小さい（体力ポイントがマイナスの値になるため低下させることができない）場合には、第１条件を満たしたと判定する。例えば、ユーザの体力ポイントが「６」であって、かつ１回のクエストの実行に「８」の体力ポイントを要する場合には、体力ポイントがマイナスの値になるため体力ポイントを低下させることができず、第１条件を満たしたことになる。

なお、図９には図示していないが、本実施形態のゲーム制御装置は、ゲームＡ（第１ゲーム）におけるユーザの実行状況を取得する状況取得手段を備えてもよい。ゲームサーバ２０ａのＣＰＵ２１は、ユーザの体力ポイントとクエスト実行に必要な体力ポイントを比較するために、ユーザの体力ポイントを例えば処理対象のユーザのユーザデータから読み出して取得するが、このＣＰＵ２１による体力ポイントの取得処理は、状況取得手段の機能の一実現例である。

情報取得手段５５は、第１判定手段５４により第１条件を満たすと判定された場合に、ゲームＡ（第１ゲーム）とは異なるゲームＢ，Ｃ，…のいずれか（第２ゲーム）におけるユーザのユーザ情報を、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）を実行する他のゲームサーバ（装置）から取得する機能を備える。
ユーザ情報は、本実施形態のゲームの例では体力ポイントであってよい。ユーザ情報の取得対象となるゲームは、予め決定しておいてもよい。例えば、第１条件の判定対象となるゲームがゲームＡである場合、ユーザ情報の取得先となるゲーム（第２ゲーム）をゲームＢに予め決定しておいてもよい。

情報取得手段５５の機能は、以下のようにして実現できる。ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報の取得先のゲームが例えばゲームＢに予め決定されている場合、ゲームＢを実行するサーバであるゲームサーバ２０ｂのＡＰＩサーバ２６に対して、処理対象となるユーザのゲームＢにおける体力ポイント（ユーザ情報の例）を取得するためのリクエストを行うように、ゲームサーバ２０ａのＡＰＩサーバ２６を制御する。ゲームサーバ２０ａのＡＰＩサーバ２６からのリクエストに応じて、ゲームサーバ２０ｂのＡＰＩサーバ２６は、データベースサーバ３０ｂのユーザデータベース３１が記憶する、処理対象となるユーザのゲームＢにおける体力ポイントの値を含むレスポンスを、ゲームサーバ２０ａのＡＰＩサーバ２６に返す。このような処理を経て、ゲームサーバ２０ａのＣＰＵ２１は、処理対象のユーザのゲームＢにおける体力ポイントを取得する。

情報取得手段５５は、異なるゲーム間の関連付けに関する情報を記憶する記憶装置を参照して、ゲームＡ（第１ゲーム）に関連付けられたゲームとして、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）を特定し、その第２ゲームにおけるユーザのユーザ情報を取得してもよい。つまり、情報取得手段５５において、ユーザ情報の取得対象となるゲームは、ゲームＡ（第１ゲーム）に関連付けられたゲームであってもよい。この場合、ゲームデータベース３２には、例えば図１０（ａ）に例示するように、ゲームとそのゲームに関連付けられたゲームとの関係を記述するテーブルを設けておき、ＣＰＵ２１がこのテーブルにアクセスすることで、ユーザ情報の取得対象となるゲームを決定することができる。例えば、図１０（ａ）の例では、ゲームＡに関連付けられたゲームには、ゲームＢとゲームＥが含まれているため、ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報の取得対象となるゲームを、ゲームＢとゲームＥの中から同じ確率で、あるいはゲームＡとの関連度合いに応じた確率でいずれかのゲームを選択する。このように、ユーザ情報の取得対象となるゲームとして、ゲームＡ（第１ゲーム）に関連付けられたゲームを選択することで、例えば、ゲームＡと同じ嗜好性のゲーム、あるいはゲームＡとゲームの構成の類似度合いが高いゲームが選択されるため、ゲームＡから、選択されたゲームへユーザを効果的に誘導することができる。
なお、図１０（ａ）に示すテーブル、つまり、異なるゲーム間の関連付けに関する情報を記憶する記憶装置は、上述したようにゲームデータベース３２であってもよいし、ネットワークを介して接続可能な外部の記憶装置（ストレージ）に設けてもよい。

別の観点では、情報取得手段５５は、ユーザとゲームの関連付けに関する情報を記憶する記憶装置を参照して、そのユーザに関連付けられたゲームとして、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）を特定し、その第２ゲームにおけるユーザのユーザ情報を取得してもよい。つまり、情報取得手段５５において、ユーザ情報の取得対象となるゲームは、処理対象となるユーザに関連付けられたゲームであってもよい。この場合、ゲームデータベース３２には、例えば図１０（ｂ）に例示するように、ユーザとそのユーザに関連付けられたゲームとの関係を記述するテーブルを設けておき、ＣＰＵ２１がこのテーブルにアクセスすることで、ユーザ情報の取得対象となるゲームを決定することができる。例えば、図１０（ｂ）の例では、例えばユーザ：ＫＮＭ（ユーザＩＤ：０００００１）に関連付けられたゲームには、ゲームＡ、Ｂ、Ｆが含まれているため、ゲームサーバ２０ａのＣＰＵ２１は、ユーザ情報の取得対象となるゲームを、ゲームＢとゲームＦの中から同じ確率で、あるいはユーザとの関連度合いに応じた確率でいずれかのゲームを選択する。ゲームサーバ２０ａのＣＰＵ２１は、ユーザと関連付けられたゲーム、及びユーザの各ゲームとの関連度合いについて、例えばユーザの各ゲームの進行レベルやログイン回数の頻度等を他のサーバからＡＰＩサーバ２６を経由して取得し、一定の基準に基づいて決定してもよい。このように、ユーザ情報の取得対象となるゲームとして、処理対象のユーザに関連付けられたゲームを選択することで、例えば、ユーザが頻繁に実行しているゲーム、あるいはユーザの進行度合いが高いゲームが選択されるため、ゲームＡから、選択されたゲームへユーザを効果的に誘導することができる。
なお、図１０（ｂ）に示すテーブル、つまり、ユーザとゲームの関連付けに関する情報を記憶する記憶装置は、上述したようにゲームデータベース３２であってもよいし、ネットワークを介して接続可能な外部の記憶装置（ストレージ）に設けてもよい。

通知手段５６は、情報取得手段５５により取得したゲームＢ，Ｃ，…のいずれか（第２ゲーム）におけるユーザ情報をユーザに通知する機能を備える。
情報取得手段５５が例えばゲームＢの体力ポイント（ユーザ情報）を取得した場合、通知手段５６の機能を実現するために、ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザのゲームＢにおける体力ポイントを取得すると、例えば、ユーザによる所定の選択操作内容（例えば、メニューｍ１０又はｍ１１の選択操作結果）を含むＨＴＴＰリクエストに応じて、ゲームＢにおける体力ポイントを含むＨＴＭＬデータをユーザの通信端末１０宛に送信する。これによって、ユーザの通信端末１０には、ゲームＢにおける体力ポイントを含むウェブページが表示される。なお、ユーザの通信端末１０宛に送信するＨＴＭＬデータには、ゲームＢにおける体力ポイントに加えて、ゲームＢの実行を開始するためのバナー（操作対象）を含むことが好ましい。

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

例えば特定のユーザＵ１がクエストの実行を繰り返し行っている場合を想定する。ここで、ユーザＵ１によるメニューｍ１１（図７参照）の選択操作によって、通信端末１０のＣＰＵ１１は、メニューｍ１１の選択操作結果を含むＨＴＴＰリクエストをゲームサーバ２０ａ宛に送信する（ステップＳ１００）。ゲームサーバ２０ａのＣＰＵ２１は、ステップＳ１００のＨＴＴＰリクエストを受信すると、処理対象のユーザＵ１の達成率、体力ポイント、及び経験値を更新する処理を行うが、この処理において、体力ポイントを低下させることができない場合に第１条件を満たしたと判定する（ステップＳ１１０：ＹＥＳ）。体力ポイントを低下させることができる場合には（ステップＳ１１０：ＮＯ）、ステップＳ１６０へ進み、更新後の体力ポイント等を表示するためのＨＴＭＬデータを生成する（ステップＳ１６０）。

ステップＳ１１０で第１条件を満たしたと判定した場合には、ゲームサーバ２０ａのＣＰＵ２１は、ゲームＢを実行するサーバであるゲームサーバ２０ｂのＡＰＩサーバ２６に対して、処理対象となるユーザＵ１のゲームＢにおける体力ポイント（ユーザ情報の例）を取得するためのリクエストを生成するように、ゲームサーバ２０ａのＡＰＩサーバ２６を制御する（ステップＳ１２０）。これにより、ゲームサーバ２０ａのＡＰＩサーバ２６からゲームサーバ２０ｂのＡＰＩサーバ２６に対して上記リクエストが送られる（ステップＳ１３０）。このリクエストには、処理対象となるユーザＵ１のユーザＩＤが含まれる。リクエストを受けたゲームサーバ２０ｂのＣＰＵ２１は、そのリクエストの対象となるユーザＩＤをキーとしてユーザデータから、ユーザ情報として体力ポイントを抽出する（ステップＳ１４０）。ゲームサーバ２０ｂのＡＰＩサーバ２６は、処理対象となるユーザＵ１のゲームＢにおける体力ポイント（ユーザ情報）の値を含むレスポンスを、ゲームサーバ２０ａのＡＰＩサーバ２６に返す（ステップＳ１５０）。

ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザＵ１のゲームＢにおける体力ポイントを取得すると、ステップＳ１００のＨＴＴＰリクエストに応じた、ゲームＢにおける体力ポイントを含むＨＴＭＬデータを生成して（ステップＳ１６０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。これによって、ユーザＵ１の通信端末１０には、ゲームＡのウェブページが更新される（ステップＳ１８０）。更新されたゲームＡのウェブページには、ゲームＢにおける体力ポイントが含まれることになる。なお、ステップＳ１５０のレスポンスを受信した場合、ステップＳ１６０で生成されるＨＴＭＬデータには、ゲームＢの実行を開始するためのバナー（操作対象）を含むことが好ましい。

なお、ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザＵ１のゲームＢにおける体力ポイントが取得できない場合は（ステップＳ１５０に代えてステップＳ１５５）、ステップＳ１００のＨＴＴＰリクエストに応じた、ゲームＢの実行を開始するためのバナーを含むＨＴＭＬデータを生成して（ステップＳ１６０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。これによって、ユーザＵ１の通信端末１０には、ゲームＡのウェブページが更新される（ステップＳ１８０）。更新されたゲームＡのウェブページには、ユーザＵ１のゲームＢにおける体力ポイントは表示されないが、ゲームＢの実行を開始するためのバナーが表示されることになる。

以上説明したように、本実施形態のゲーム制御装置では、ユーザによるゲームＡ（第１ゲーム）の実行状況が第１条件を満たす場合に、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）における体力ポイント（ユーザ情報）がユーザの通信端末１０に通知される。そのため、ゲームＡを実行中、あるいは実行しようとするユーザは別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）についての自らの体力ポイントを知ることができ、別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）を進行又は実行させることができるか否かを適切に判断できる。
本実施形態において、第１条件は適宜設定することができるが、好ましくは、上述した実施形態のように、体力ポイントが足りないためにクエストを実行できない場合など、ゲームＡ（第１ゲーム）の少なくとも一部を実行又は進行させることができないことであってよい。その場合、ユーザは、例えば、ゲームＡを進行させることができなくなった時点で別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）を進行させることができるか否かについて適切に判断することができる。

上述したように、ゲームＡ（第１ゲーム）のユーザ情報は、体力ポイントであってもよい。つまり、ゲームＡのユーザ情報は、ゲーム進行に応じて変動する体力ポイント（パラメータ）を含み、ゲームＡは、体力ポイントの値が、クエスト処理を行うのに必要な体力ポイント以下（所定の範囲）である場合にゲーム進行が妨げられるゲームであって、第１判定手段５４における第１条件は、ゲームＡ（第１ゲーム）におけるユーザの体力ポイントの値が上記所定の範囲にあることであってもよい。このとき、第１条件を満たすと判定された場合には、ユーザはゲームＡの進行ができなくなる。このような状況下では特に、ユーザにとってはゲームＡとは別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）についての体力ポイントなどのユーザ情報が重宝することになり、そのユーザ情報次第では、別のゲームを開始する契機となる。

上述した実施形態において述べたように、通知手段５６は、アクセス対象とは別のゲーム（第２ゲーム）のユーザ情報を、アクセス対象のゲームＡ（第１ゲーム）のゲーム画像に表示させてもよい。これにより、ゲームＡにアクセスしたタイミング、ゲームＡを実行中のタイミング、あるいはゲームＡの進行させることができなくなったタイミングで、直ちにゲームＡとは別のゲームの体力ポイントなどのユーザ情報を認識することができる。
また、上述した実施形態において述べたように、通知手段５６は、例えば別のゲームＢ（第２ゲーム）の実行を開始するためのバナー（操作対象）をさらに表示させてもよい。これによって、ユーザは、ゲームＢを直ちに開始することができる。例えば、ユーザは、ゲームＡを進行させることができなくなった時点でゲームＡからゲームＢに、より一層円滑に移行することができるようになる。

＜第２の実施形態＞
次に、第２の実施形態について説明する。本実施形態のゲームシステムを構成する各要素（通信端末１０、ゲームサーバ２０及びデータベースサーバ３０）のハードウエア構成は、第１の実施形態と同じでよい。また、機能ブロック図は、図９に示したものと同一の機能構成でよいが、後述するように第１判定条件５４の機能の内容が第１の実施形態とは異なる。

第１の実施形態においては、ユーザによるゲームＡの体力ポイントがクエスト処理を行うのに必要な体力ポイント以下の場合に別のゲームのユーザ情報を通知するようにしているが、本実施形態では、ゲームＡ（第１ゲーム）の実行ができない状況にあるときに別のゲームのユーザ情報を通知する。「ゲームＡの実行ができない状況」とは、例えば、ユーザがアクセスしたゲームＡがゲーム運営者によるメンテナンス等によってゲームＡの実行を開始することができない状況（ゲームＡの実行についてのサービスが停止されている状況）である。このような状況下では特に、ユーザにとってはゲームＡとは別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）についての体力ポイントなどのユーザ情報が重宝することになり、そのユーザ情報次第では、別のゲームを開始する契機となる。

本実施形態において、第１判定手段５４は、ユーザによるゲームＡ（第１ゲーム）の状況が第１条件を満たすか否かを判定する機能を備える。本実施形態では、第１条件は、上述したように、例えば、ユーザがアクセスしたゲームＡがゲーム運営者によるメンテナンス等によってゲームＡの実行を開始することができない場合である。
本実施形態の第１判定手段５４の機能を実現するために、ゲームサーバ２０ａのＣＰＵ２１は、ユーザの通信端末１０からログインのためのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストに含まれる個体識別情報、あるいはユーザＩＤ及びパスワードに基づいて認証処理を行うが、ゲームＡの実行ができない状況である場合には、第１条件を満たしたと判定する。例えば、上述したように、ゲームＡがゲーム運営者によるメンテナンス等によってゲームＡの実行を開始することができない状況（ゲームＡの実行についてのサービスが停止されている状況）である場合には、第１条件を満たしたことになる。また、ゲームの実行中にメンテナンスが開始されるなど、ログイン時以外にもゲームができない状況が発生した場合には、第１条件を満たしたと判定する。

なお、図９には図示していないが、本実施形態のゲーム制御装置は、ゲームＡ（第１ゲーム）の状況を取得する状況取得手段を備えてもよい。例えば、ゲームサーバ２０内部において、ゲームＡの運営状態を示すフラグ（１：メンテナンスにより停止中、０：運営中）を設けており、フラグの状態が例えばゲーム運営者のオペレータにより設定される場合には、ゲームサーバ２０ａのＣＰＵ２１は、そのフラグの状態を読み出すことで、ゲームＡがメンテナンス中であるか否かを判別する。このとき、ＣＰＵ２１による上記フラグの状態を読み出す処理は、状況取得手段の機能の一実現例である。

本実施形態においても第１の実施形態と同様に、情報取得手段５５は、異なるゲーム間の関連付けに関する情報を記憶する記憶装置を参照して、ゲームＡ（第１ゲーム）に関連付けられたゲームとして、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）を特定し、その第２ゲームにおけるユーザのユーザ情報を取得してもよい。つまり、情報取得手段５５において、ユーザ情報の取得対象となるゲームは、ゲームＡ（第１ゲーム）に関連付けられたゲームであってもよいし、処理対象となるユーザに関連付けられたゲームであってもよい。
別の観点では、情報取得手段５５は、ユーザとゲームの関連付けに関する情報を記憶する記憶装置を参照して、そのユーザに関連付けられたゲームとして、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）を特定し、その第２ゲームにおけるユーザのユーザ情報を取得してもよい。つまり、情報取得手段５５において、ユーザ情報の取得対象となるゲームは、処理対象となるユーザに関連付けられたゲームであってもよい。

以下、本実施形態のゲームシステムにより行われる主要な処理のフローの一例について、再度図１１のシーケンスチャートを参照して説明する。なお、本実施形態では、図１１のシーケンスチャートは、ユーザがゲームＡにログインしたときの状況を示しており、ユーザ情報の取得先がゲームＢである場合の例である。

図１１において、例えば特定のユーザＵ１がゲームＡにログインするためのＵＲＬ(Uniform Resource Locator)を指定したＨＴＴＰリクエストをゲームサーバ２０ａ宛に送信する（ステップＳ１００）。ゲームサーバ２０ａのＣＰＵ２１は、ステップＳ１００のＨＴＴＰリクエストを受信すると、ゲームＡがメンテナンスのために実行できないため、第１条件を満たしたと判定する（ステップＳ１１０：ＹＥＳ）。ゲームＡが実行可能である場合には（ステップＳ１１０：ＮＯ）、ステップＳ１６０へ進み、ゲームサーバ２０ａのＣＰＵ２１は、ユーザＵ１のユーザデータを参照してユーザＵ１のゲームＡのトップページを表示するためのＨＴＭＬデータを生成する（ステップＳ１６０）。

ステップＳ１１０で第１条件を満たしたと判定した場合には、ゲームサーバ２０ａのＣＰＵ２１は、ゲームＢを実行するサーバであるゲームサーバ２０ｂのＡＰＩサーバ２６に対して、処理対象となるユーザＵ１のゲームＢにおける体力ポイント（ユーザ情報の例）を取得するためのリクエストを生成するように、ゲームサーバ２０ａのＡＰＩサーバ２６を制御する（ステップＳ１２０）。これにより、ゲームサーバ２０ａのＡＰＩサーバ２６からゲームサーバ２０ｂのＡＰＩサーバ２６に対して上記リクエストが送られる（ステップＳ１３０）。このリクエストには、処理対象となるユーザＵ１のユーザＩＤが含まれる。リクエストを受けたゲームサーバ２０ｂのＣＰＵ２１は、そのリクエストの対象となるユーザＩＤをキーとしてユーザデータから、ユーザ情報として体力ポイントを抽出する（ステップＳ１４０）。ゲームサーバ２０ｂのＡＰＩサーバ２６は、処理対象となるユーザＵ１のゲームＢにおける体力ポイント（ユーザ情報）の値を含むレスポンスを、ゲームサーバ２０ａのＡＰＩサーバ２６に返す（ステップＳ１５０）。

ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザＵ１のゲームＢにおける体力ポイントを取得すると、ステップＳ１００のＨＴＴＰリクエストに応じた、ゲームＢにおける体力ポイントを含むＨＴＭＬデータを生成して（ステップＳ１６０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。なお、このＨＴＭＬデータには、ゲームＡがメンテナンス中のために実行できないことを通知するテキストも含まれる。ＨＴＭＬデータを受信すると、ユーザＵ１の通信端末１０には、ゲームＡのウェブページが表示される（ステップＳ１８０）。
図１２には、ステップＳ１８０で表示されるウェブページの一例を示す。図１２に例示するウェブページには、ゲームＡがメンテナンス中であることをユーザに通知するための表示領域４０１と、案内領域４０２とが表示される。図９のウェブページの案内領域４０２の表示形態は、例えば、図８（ａ）のそれと同じであり、ゲームＢの実行を開始するためのバナー（操作対象）を含むことが好ましい。

なお、ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザＵ１のゲームＢにおける体力ポイントが取得できない場合は（ステップＳ１５０に代えてステップＳ１５５）、ステップＳ１００のＨＴＴＰリクエストに応じた、ゲームＢの実行を開始するためのバナーを含むＨＴＭＬデータを生成して（ステップＳ１６０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。これによって、ユーザＵ１の通信端末１０には、ゲームＡのウェブページが表示される（ステップＳ１８０）。表示されたゲームＡのウェブページには、ユーザＵ１のゲームＢにおける体力ポイントは表示されないが、ゲームＢの実行を開始するためのバナーが含まれることになる。

以上説明したように、本実施形態のゲーム制御装置では、ゲームＡ（第１ゲーム）の状況が第１条件を満たす場合（例えば、ゲームＡがメンテナンス中などで実行できない場合）に、ゲームＢ，Ｃ，…のいずれか（第２ゲーム）における体力ポイント（ユーザ情報）がユーザの通信端末１０に通知される。そのため、ゲームＡを実行しようとするユーザは別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）についての自らの体力ポイントを知ることができ、ゲームＡの代わりに別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）を進行又は実行させることができるか否かを適切に判断できる。

＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。本実施形態のゲームシステムを構成する各要素（通信端末１０、ゲームサーバ２０及びデータベースサーバ３０）のハードウエア構成は、第１の実施形態と同じでよい。

（１）ゲーム制御装置が備える機能の概要
本実施形態のゲーム制御装置の機能ブロック図を、図１３に示す。図１３に示すように、本実施形態は、第１の実施形態（図９）と比較して、選択手段５７が追加された点で異なる。選択手段５７は、ユーザに関する登録情報を記憶する記憶装置からユーザの登録情報を取得し、登録情報を参照して、ユーザのアクセス対象であるゲームＡ（第１ゲーム）とは別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）の中から１又は複数のゲームを選択する機能を備える。ここで、登録情報は、例えばユーザの性別や年令などのユーザの属性を示す情報であってよく、特にユーザの性別に関する情報であるのが好適である。
本実施形態のゲームシステムにおいて、ユーザの登録情報を記憶する記憶装置の所在は、適宜設定することができる。例えば、各ゲームに対応するゲームサーバ２０がユーザ登録を行うときにユーザの選択操作入力に基づいて取得する場合には、ユーザの登録情報を記憶する記憶装置は、データベースサーバ３０（ユーザデータベース３１）であってもよい。また、各ゲームに対応するゲームサーバ２０に接続される上位サーバ（図１に図示せず）が設けられ、この上位サーバが各ゲームサーバで認識可能な共通のユーザＩＤを発行し、このユーザＩＤとユーザの属性などの登録情報とが上位サーバにおいて対応付けられて記憶される場合には、ユーザの登録情報を記憶する記憶装置は、その上位サーバ内のＨＤＤ(Hard Disk Drive)等の大容量記憶装置であってもよい。

選択手段５７の機能の実現方法の一例を、図１４のフローチャートを参照して説明する。図１４は、登録情報に基づく選択処理の一例を示すフローチャートである。以下、図１４のフローチャートの処理が、ゲームサーバ２０ａのＣＰＵ２１によって実行される場合について説明する。なお、ユーザの登録情報には、ユーザの性別に関する情報が含まれているものとする。
ユーザデータベース３１がユーザの登録情報を記憶している場合、ゲームサーバ２０ａのＣＰＵ２１は、ユーザデータベース３１にアクセスして、処理対象のユーザの登録情報を読み出す（ステップＳ２００）。なお、上述したように上位サーバにユーザの登録情報が記憶されている場合には、ゲームサーバ２０ａのＣＰＵ２１は、その上位サーバとの通信によって登録情報を取得する。その場合、上位サーバから各ゲームサーバ２０が定期的に（例えば１日１回）ユーザの登録情報を受信するか、又は必要に応じて各ゲームサーバ２０から上位サーバに対してユーザの登録情報についてのリクエストを送り、そのリクエストに応じて上位サーバが各ゲームサーバ２０に対してユーザの登録情報を含むレスポンスを返すように構成してもよい。その場合、各ゲームサーバ２０と上位サーバの間の通信は、ＨＴＴＰに基づくＷｅｂＡＰＩを利用してもよい。

次いでゲームサーバ２０ａのＣＰＵ２１は、登録情報に含まれるユーザの性別に関する情報を判定する。ゲームサーバ２０ａのＣＰＵ２１は、処理対象のユーザが男性である場合には（ステップＳ２１０：ＹＥＳ）、男性用又は性別によらない複数のゲームの中から所定の確率でゲームを選択する（ステップＳ２２０）。例えば、男性用又は性別によらない複数のゲームがゲームＤ，Ｅ，Ｆである場合、ゲームサーバ２０ａのＣＰＵ２１は、ゲームを選択する確率は任意に設定できるが、例示すると以下の通りである。

［ゲームを１つ選択する場合］
・ゲームＤが選択される確率：１／３
・ゲームＥが選択される確率：１／３
・ゲームＦが選択される確率：１／３

［ゲームを２つ選択する場合］
・ゲームＤ，Ｅが選択される確率：１／３
・ゲームＥ，Ｆが選択される確率：１／３
・ゲームＤ，Ｆが選択される確率：１／３

上述した例では、各選択候補に対して選択される確率が同じである場合を示したが、これに限られない。ユーザを案内（誘導）したいゲームが選択される確率が高くなるように、確率を適宜調整するようにしてもよい。

ゲームサーバ２０ａのＣＰＵ２１は、処理対象のユーザが女性である場合には（ステップＳ２１０：ＮＯ）、女性用又は性別によらない複数のゲームの中から所定の確率でゲームを選択する（ステップＳ２３０）。なお、選択方法は、ステップＳ２２０と同様でよい。

図１４に示したフローチャートでは、ユーザの登録情報には、ユーザの性別に関する情報が含まれている場合を想定したが、ユーザの登録情報は性別に限られない。ユーザの登録情報は年令に関する情報とすることもできる。この場合のゲームの選択についてのフローチャートは、図１４と同様の構成を採ることができる。つまり、ゲームサーバ２０ａのＣＰＵ２１は、所定の閾値を基準としてユーザの年令が高い場合には、年令が高い人用、又は年令によらない複数のゲームの中から所定の確率でゲームを選択し、ユーザの年令が低い場合には、年令が低い人用、又は年令によらない複数のゲームの中から所定の確率でゲームを選択する。ゲームを選択する確率は、上述した例と同様とすることができる。

（２）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲームシステムにより行われる主要な処理のフローの一例について、図１５を参照して説明する。図１５は、本実施形態のゲーム制御装置において、実行中のゲームとは異なるゲームの情報をユーザに提示する処理の一例を示すシーケンスチャートである。
なお、図１５のシーケンスチャートは、図１１と同様に、ユーザがゲームＡを実行中であり、ユーザ情報の取得先がゲームＢである場合の例であり、図１１とはステップＳ１１５が追加された点が異なる。図１５のシーケンスチャートでは、ステップＳ１１０で第１条件を満たしたと判定した場合に、ゲームサーバ２０ａのＣＰＵ２１は、例えば図１４に示した処理により、処理対象となるユーザＵ１の登録情報に基づいてゲームを選択する（ステップＳ１１５）。ここでは、ゲームＢが選択された場合が想定される。その場合、ゲームサーバ２０ａのＣＰＵ２１は、ゲームＢを実行するサーバであるゲームサーバ２０ｂのＡＰＩサーバ２６に対して、処理対象となるユーザＵ１のゲームＢにおける体力ポイント（ユーザ情報の例）を取得するためのリクエストを行うように、ゲームサーバ２０ａのＡＰＩサーバ２６を制御する。その後の処理は、図１１と同じである。

本実施形態のゲームシステムでは、ユーザのアクセス対象のゲームＡ（第１ゲーム）のゲームサーバ２０ａが別のゲームＢ，Ｃ，…のいずれか（第２ゲーム）をそのユーザの登録情報に基づいて選択することによって、そのユーザに適したゲームを実行するようにユーザを誘導することができるようになる。これによって、例えば、ゲームＡを進行させることができなくなった時点でゲームＡから別のゲームに円滑に移行させることができるようになる。

＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。本実施形態のゲームシステムを構成する各要素（通信端末１０、ゲームサーバ２０及びデータベースサーバ３０）のハードウエア構成は、第１の実施形態と同じでよい。

（１）ゲーム制御装置が備える機能の概要
本実施形態のゲーム制御装置の機能ブロック図を、図１６に示す。図１６に示すように、本実施形態は、第１の実施形態（図９）と比較して、第２判定手段５８が追加された点で異なる。第２判定手段５８は、情報取得手段５５により取得された、ユーザのアクセス対象のゲームとは別のゲーム（第２ゲーム）のユーザの体力ポイント（ユーザ情報）が第２条件を満たすか否かを判定する機能を備える。

第２判定手段５８の機能を実現するために、ゲームサーバ２０ａのＣＰＵ２１は、ユーザのアクセス対象のゲームとは別のゲームのユーザの体力ポイント（ユーザ情報）を取得すると、その体力ポイントが第２条件を満たすか否かを判定する。例えば、別のゲームにおいて、１回のクエストの実行に「８」の体力ポイントを要し、かつ別のゲームにおけるユーザの体力ポイントが「８」以上である場合には、体力ポイントを消費して少なくとも１回のクエストを実行できるため、第２条件を満たしたことになる。
なお、ここでは、ユーザのアクセス対象のゲーム（第１ゲーム）と別のゲーム（第２ゲーム）とがそれぞれクエストの処理を行うように構成されている場合を例示したが、この例に限られない。それぞれ別々のゲームであり、そのゲームに設けられる機能は異なってもよいため、第１判定手段５４における第１条件と、第２判定手段５８における第２条件の判定の基礎となるデータはそれぞれ異なっていてよい。

本実施形態において、通知手段５６は、第２判定手段５８により第２条件を満たすと判定された場合に、ユーザのアクセス対象のゲームとは別のゲーム（第２ゲーム）のユーザの体力ポイント（ユーザ情報）をユーザに通知してもよい。

（２）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲームシステムにより行われる主要な処理のフローの一例について、図１７を参照して説明する。図１７は、本実施形態のゲーム制御装置において、実行中のゲームとは異なるゲームの情報をユーザに提示する処理の一例を示すシーケンスチャートである。
なお、図１７のシーケンスチャートは、図１１と同様に、ユーザがゲームＡを実行中である場合の例である。
特定のユーザＵ１の通信端末１０からのＨＴＴＰリクエスト（ステップＳ１００）に応じて、ゲームＡを実行するゲームサーバ２０ａのＣＰＵ２１は、ステップＳ１１０で第１条件を満たした（つまり、体力ポイントを低下させることができずクエストを実行できない）と判定した場合には、別のゲームＢ，Ｃ，Ｄ，…を実行するゲームサーバ２０ｂ，２０ｃ，２０ｄ，…のＡＰＩサーバ２６に対して、処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイント（ユーザ情報の例）を取得するためのリクエストを生成するように、ゲームサーバ２０ａのＡＰＩサーバ２６を制御する（ステップＳ１２０）。これにより、ゲームサーバ２０ａのＡＰＩサーバ２６からゲームサーバ２０ｂ，２０ｃ，２０ｄ，…のＡＰＩサーバ２６に対して上記リクエストが送られる（ステップＳ１３０）。このリクエストには、処理対象となるユーザＵ１のユーザＩＤが含まれる。リクエストを受けたゲームサーバ２０ｂ，２０ｃ，２０ｄ，…の各々のＣＰＵ２１は、そのリクエストの対象となるユーザＩＤをキーとしてユーザデータから、ユーザ情報として体力ポイントを抽出する（ステップＳ１４０）。ゲームサーバ２０ｂ，２０ｃ，２０ｄ，…の各々のＡＰＩサーバ２６は、処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…おける体力ポイントの値を含むレスポンスを、ゲームサーバ２０ａのＡＰＩサーバ２６に返す（ステップＳ１５０）。

ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザＵ１のゲームＢ，Ｃ，Ｄ，…における体力ポイントを取得すると、第２条件を満たすか否かを判定する（ステップＳ１５５）。例えば、ゲームＢ，Ｃ，Ｄ，…におけるユーザＵ１の体力ポイントが、各ゲームの１回のクエストの実行に要する体力ポイント以上である場合に、第２条件を満たしたと判定する。第２条件を満たすゲームが存在する場合（ステップＳ１５５：ＹＥＳ）、ゲームサーバ２０ａのＣＰＵ２１は、例えば、第２の実施形態で例示した選択方法で、第２条件を満たすゲームの中から、いずれかのゲーム、又は所定数のゲームを選択してもよい（ステップＳ１５７）。次いでゲームサーバ２０ａのＣＰＵ２１は、ステップＳ１００のＨＴＴＰリクエストに応じた、ステップＳ１５７で選択されたゲーム（ゲームＢ，Ｃ，Ｄ，…のうち１又は複数のゲーム）における体力ポイントを含むＨＴＭＬデータを生成して（ステップＳ１６０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。これによって、ユーザの通信端末１０には、ゲームＡのウェブページが更新される（ステップＳ１８０）。更新されたゲームＡのウェブページには、ステップＳ１５７で選択されたゲームにおける体力ポイントが含まれることになる。なお、ステップＳ１５０のレスポンスを受信した場合、ステップＳ１６０で生成されるＨＴＭＬデータには、ステップＳ１５７で選択されたゲームの実行を開始するためのバナー（操作対象）を含むことが好ましい。
なお、ステップＳ１５７でゲームを選択することは必ずしも必要ではなく、第２条件を満たすすべてのゲームにおける体力ポイントと、そのすべてのゲームにおけるバナーをＨＴＭＬデータに含めてもよい。

上述したように本実施形態では、アクセス対象のゲームＡ（第１ゲーム）とは別のゲームＢ，Ｃ，Ｄ，…（第２ユーザ）の体力ポイント（ユーザ情報）を闇雲にユーザに通知するのではなく、第２条件を満たす場合にその体力ポイントを通知することで、適切な第２ゲームについての体力ポイントをユーザに通知することができるようになる。これにより、クエストを実行可能な第２ゲームの体力ポイントを通知するようにすることができ、ゲームＡを進行させることができなくなった時点で、別のゲームを進行させることができることをユーザが認識することができる。

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

なお、第１〜第４の実施形態に示したように、一方のゲーム制御装置における情報取得手段５５が他方のゲーム制御装置からユーザ情報を取得する場合、つまり、ゲーム制御装置間で直接的にユーザ情報の授受が行われる場合、他の装置を介さずに情報の授受が行われるため、トラフィックが低減する利点がある。
また、第５の実施形態に示したように、ゲーム制御装置における情報取得手段５５が、複数のゲームにおけるユーザ情報を有する情報管理装置を介して他のゲーム制御装置で管理するユーザ情報を取得する場合、例えばゲーム制御装置間の通信が妨げられているときでも、ユーザ情報を情報管理装置から確実に取得することができる利点がある。

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

上述した各実施形態では、ユーザ情報のユーザへの通知の態様として、ウェブページ等のゲーム画像にユーザ情報（例えば、体力ポイント）が表示される場合について説明したが、ユーザ情報の通知の態様は表示に限られない。ユーザへのユーザ情報の通知方法は、ユーザ情報を音声によって出力する方法などでもよい。その場合、各ゲームサーバ２０から通信装置１０宛に、ユーザ情報の圧縮音声信号を含むＨＴＭＬデータを送信し、通信装置１０において圧縮音声信号を伸長・増幅して音声出力するようにしてもよい。なお、通知の態様としては、上述した各実施形態で示したように、ユーザ情報を表示させることが好ましい。ユーザ情報をゲーム画像に表示する方法を採ることで、例えば音声の出力が制限される環境（例えば、公共交通機関内）においてもユーザがゲーム画像を認識することができる。さらに、音声でユーザ情報を出力する場合はユーザが聞き逃す場合等が生じうるが、ユーザ情報の表示することで情報伝達の不確実性を抑制することもできる。

上述した各実施形態について、ユーザ情報の一例としてゲームを進行させる上での体力ポイントを挙げたが、取得対象となるユーザ情報は、ゲームの性質や第１判定手段における第１条件の内容に応じて適宜設定されてよい。
例えば、ゲームキャラクタの攻撃力及び防御力がゲームの進行に応じて変動するバトルゲームの場合、ユーザ情報は、その攻撃力及び防御力を示すゲームキャラクタのパラメータの値であってもよい。
また、上述した実施形態では、第１条件として、クエストを実行できないためにゲームを進行させることができないことを条件とした場合を例示したが、このような条件に限られない。例えばユーザがアクセス中のゲームＡを進行させることができる場合（例えば、クエストを実行できる場合）であっても、ゲームＡの区切りのタイミング（例えば、クエストの特定のエリアの探索が終了するタイミング）や、ゲームＡにアクセスしてから定期的なタイミング（例えば、１０分間隔のタイミング）毎に、ゲームＡ以外の他のゲームのユーザ情報を取得し、そのユーザ情報をユーザに通知するようにしてもよい。つまり、第１条件は、所定時間が経過したことや、ユーザによるゲームの進行によってゲームＡの区切りの位置に達したことであってよい。
例えば、ゲームＡ以外の他のゲームにおいて、ゲームＡにアクセスしているユーザ宛の仲間申請を受けている場合や、そのユーザ宛のトレードの申請・返答がある場合、プレゼントが届いている場合など、ゲームＡ以外のゲームにおいてユーザ向けのイベントが生じている場合には、そのイベントの内容をユーザ情報として通知してもよい。このような通知によって、ゲームＡにアクセスしているユーザが適時に他のゲームにアクセスして所要の操作を行うことができる。

また、ユーザ情報は、ゲームに応じて適宜設定することができる。例えば、作物をユーザが肥料等を用いて成長させていくゲームの場合には、ユーザが保有する肥料が尽きた場合に（ゲームを進行させることができない場合に）、ゲームの実行状況が第１条件を満たしたと判定してもよい。

上述した実施形態では、理解の容易のために、各ゲームサーバ２０で実行されるゲームの機能が共通する場合について説明したが、各ゲームサーバ２０で実行されるゲームは、それぞれ異なる機能（つまり、異なる性質のゲーム）であってよい。つまり、一方のゲームサーバ２０によって判定される第１条件と、他方のゲームサーバ２０によって抽出されるユーザ情報はそれぞれ独立に設定可能であり、各ゲームサーバ２０で実行されるゲームは、共通する機能を備えている必要はない。例えば、ゲームサーバ２０ａにおいて体力ポイントが第１条件を満たすと判定された場合に、ゲームサーバ２０ｂから提供されるユーザ情報は、クエストとは全く関連のないゲームについてのユーザ情報（例えば、上述した作物の成長度合い）であってよい。

上記ゲーム制御装置において、通知手段５６は、ユーザ情報をゲーム画像に表示する場合にさらに、第１条件を満たしたことを示す情報をウェブページ（ゲーム画像）に表示させてもよい。表示方法としては、例えば、上述した実施形態で示したようにテキストによる表示や、マークなどの絵柄による表示など、任意の方法を用いることができる。これにより、ユーザは、単一のゲーム画像上で必要な情報が表示されるため、便利である。また、実行していたゲームを継続して実行できなくなったときは、他のゲームで遊ぶ（他のゲームを実行する）タイミングであるが、この際に、実行していたゲームが継続できないことが通知されると、次にどのゲームを代わりに実行するかを考える上で、他のゲームの情報が表示される重要性が増す。

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

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

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

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

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

上記ゲーム制御装置において、前記情報取得手段により取得された前記第２ゲームにおける前記ユーザのユーザ情報が第２条件を満たすか否かを判定する第２判定手段をさらに備え、前記通知手段は、前記第２判定手段により前記第２条件を満たすと判定された場合に、前記第２ゲームの前記ユーザのユーザ情報を前記ユーザに通知してもよい。
闇雲に第２ゲームのユーザ情報をユーザに通知するのではなく、第２条件を満たす場合にそのユーザ情報を通知することで、適切な第２ゲームについてのユーザ情報をユーザに通知することができるようになる。例えば、第２ゲームのユーザ情報として、第２ゲームをユーザが進行させることが可能か否かについての情報（例えば、ゲームを進行させるための体力ポイント等の情報）を含む場合には、第２条件に基づいて、進行させることが可能な第２ゲームのユーザ情報を通知するようにすることができ、第１ゲームを進行させることができなくなった時点で第２ゲームを進行させることができることをユーザが認識することができる。

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

ゲームサーバ２０ａのＣＰＵ２１は、ゲームサーバ２０ｂから、処理対象となるユーザＵ１のゲームＢにおける体力ポイントを取得すると、ステップＳ１００のＨＴＴＰリクエストに応じた、ゲームＢにおける体力ポイントを含むＨＴＭＬデータを生成して（ステップＳ１６０）、ユーザＵ１の通信端末１０宛に送信する（ステップＳ１７０）。なお、このＨＴＭＬデータには、ゲームＡがメンテナンス中のために実行できないことを通知するテキストも含まれる。ＨＴＭＬデータを受信すると、ユーザＵ１の通信端末１０には、ゲームＡのウェブページが表示される（ステップＳ１８０）。
図１２には、ステップＳ１８０で表示されるウェブページの一例を示す。図１２に例示するウェブページには、ゲームＡがメンテナンス中であることをユーザに通知するための表示領域４０１と、案内領域４０２とが表示される。図１２のウェブページの案内領域４０２の表示形態は、例えば、図８（ａ）のそれと同じであり、ゲームＢの実行を開始するためのバナー（操作対象）を含むことが好ましい。

上述したように本実施形態では、アクセス対象のゲームＡ（第１ゲーム）とは別のゲームＢ，Ｃ，Ｄ，…（第２ゲーム）の体力ポイント（ユーザ情報）を闇雲にユーザに通知するのではなく、第２条件を満たす場合にその体力ポイントを通知することで、適切な第２ゲームについての体力ポイントをユーザに通知することができるようになる。これにより、クエストを実行可能な第２ゲームの体力ポイントを通知するようにすることができ、ゲームＡを進行させることができなくなった時点で、別のゲームを進行させることができることをユーザが認識することができる。

Claims (25)

1. 第１ゲームを実行する実行手段と、
   前記第１ゲームにおけるユーザの実行状況が第１条件を満たすか否かを判定する第１判定手段と、
   前記第１判定手段により前記第１条件を満たすと判定された場合に、前記第１ゲームに関連付けられた第２ゲームにおける前記ユーザのユーザ情報を取得する情報取得手段と、
   前記情報取得手段により取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する通知手段と、
   を備えた、ゲーム制御装置。
2. 前記第１ゲームにおける前記ユーザの実行状況を取得する状況取得手段、をさらに備え、
   前記第１判定手段は、前記状況取得手段で取得した前記ユーザの実行状況に基づいて、前記第１条件を満たすか否かを判定し、
   前記情報取得手段は、第１ゲームと異なるゲームを関連付けた情報を記憶する記憶装置を参照して、前記第１ゲームに関連付けられたゲームとして前記第２ゲームを特定し、前記第２ゲームにおける前記ユーザのユーザ情報を取得することを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 第１ゲームを実行する実行手段と、
   ユーザが前記第１ゲームを実行するに当たって、前記第１ゲームの状況が第１条件を満たすか否かを判定する第１判定手段と、
   前記第１判定手段により前記第１条件を満たすと判定された場合に、前記第１ゲームに関連付けられた第２ゲームにおける前記ユーザのユーザ情報を取得する情報取得手段と、
   前記情報取得手段により取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する通知手段と、
   を備えた、ゲーム制御装置。
4. 前記第１ゲームの状況を取得する状況取得手段、をさらに備え、
   前記第１判定手段は、前記状況取得手段で取得した第１ゲームの状況に基づいて、前記第１条件を満たすか否かを判定し、
   前記情報取得手段は、第１ゲームと異なるゲームを関連付けた情報を記憶する記憶装置を参照して、前記第１ゲームに関連付けられたゲームとして前記第２ゲームを特定し、前記第２ゲームにおける前記ユーザのユーザ情報を取得することを特徴とする、
   請求項３に記載されたゲーム制御装置。
5. 前記ユーザに関する登録情報を記憶する記憶装置から前記ユーザの登録情報を取得し、
   当該登録情報に基づいて前記第１ゲームに関連付けられたゲームの中から前記第２ゲームを１又は複数選択する選択手段をさらに備えた、
   請求項２又は４に記載されたゲーム制御装置。
6. 前記登録情報は、前記ユーザの性別又は年齢に関する情報を含む、
   請求項５に記載されたゲーム制御装置。
7. 第１ゲームを実行する実行手段と、
   前記第１ゲームにおけるユーザの実行状況が第１条件を満たすか否かを判定する第１判定手段と、
   前記第１判定手段により前記第１条件を満たすと判定された場合に、前記ユーザに関連付けられた第２ゲームにおけるユーザ情報を取得する情報取得手段と、
   前記情報取得手段により取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する通知手段と、
   を備えた、ゲーム制御装置。
8. 前記ユーザの第１ゲームにおける実行状況を取得する状況取得手段、をさらに備え、
   前記第１判定手段は、前記状況取得手段で取得した前記ユーザの実行状況に基づいて、前記第１条件を満たすか否かを判定し、
   前記情報取得手段は、前記ユーザとゲームの関連付けに関する情報を記憶する記憶装置を参照して、前記ユーザに関連付けられたゲームとして前記第２ゲームを特定し、前記第２ゲームにおける前記ユーザのユーザ情報を取得することを特徴とする、
   請求項７に記載されたゲーム制御装置。
9. 第１ゲームを実行する実行手段と、
   ユーザが前記第１ゲームを実行するに当たって、前記第１ゲームの状況が第１条件を満たすか否かを判定する第１判定手段と、
   前記第１判定手段により前記第１条件を満たすと判定された場合に、前記ユーザに関連付けられた第２ゲームにおけるユーザ情報を取得する情報取得手段と、
   前記情報取得手段により取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する通知手段と、
   を備えた、ゲーム制御装置。
10. 前記第１ゲームの状況を取得する状況取得手段、をさらに備え、
    前記第１判定手段は、前記状況取得手段で取得した第１ゲームの状況に基づいて、前記第１条件を満たすか否かを判定し、
    前記情報取得手段は、前記ユーザとゲームの関連付けに関する情報を記憶する記憶装置を参照して、前記ユーザに関連付けられたゲームとして前記第２ゲームを特定し、前記第２ゲームにおける前記ユーザのユーザ情報を取得することを特徴とする、
    請求項９に記載されたゲーム制御装置。
11. 前記第１ゲームは、ゲーム進行に応じて変動するパラメータを備えたユーザ情報を有し、
    前記第１ゲームは、前記パラメータの値が所定の範囲である場合にゲーム進行が妨げられるゲームであって、
    前記第１条件は、前記第１ゲームにおける前記ユーザのパラメータの値が前記所定の範囲にあることである、
    請求項１又は７に記載されたゲーム制御装置。
12. 前記第１条件は、前記第１ゲームの実行ができない状況であることである、
    請求項３又は９に記載されたゲーム制御装置。
13. 前記情報取得手段により取得された前記第２ゲームにおける前記ユーザのユーザ情報が第２条件を満たすか否かを判定する第２判定手段をさらに備え、
    前記通知手段は、前記第２判定手段により前記第２条件を満たすと判定された場合に、前記第２ゲームの前記ユーザのユーザ情報を前記ユーザに通知する、
    請求項１〜１２のいずれかに記載されたゲーム制御装置。
14. 前記情報取得手段は、前記第２ゲームを実行するゲーム制御装置から当該第２ゲームのユーザ情報を取得することを特徴とする、
    請求項１〜１３のいずれかに記載されたゲーム制御装置。
15. 前記情報取得手段は、複数のゲームにおけるユーザ情報を有する情報管理装置から前記第２ゲームのユーザ情報を取得することを特徴とする、
    請求項１〜１３のいずれかに記載されたゲーム制御装置。
16. 前記通知手段は、前記第２ゲームのユーザ情報を、前記第１ゲームのゲーム画像に表示させる、
    請求項１〜１５のいずれかに記載されたゲーム制御装置。
17. 前記通知手段は、前記第１条件を満たしたことを示す情報を前記ゲーム画像に表示させる、
    請求項１６に記載されたゲーム制御装置。
18. 前記通知手段は、前記第２ゲームの実行を開始するための操作対象を前記第１ゲームのゲーム画像にさらに表示させる、
    請求項１６又は１７に記載されたゲーム装置。
19. コンピュータに、
    第１ゲームを実行する機能、
    前記第１ゲームにおけるユーザの実行状況が第１条件を満たすか否かを判定する機能、
    前記第１判定手段により前記第１条件を満たすと判定された場合に、前記第１ゲームに関連付けられた第２ゲームにおける前記ユーザのユーザ情報を取得する機能、及び、
    取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する機能、
    を実現させるためのプログラム。
20. コンピュータに、
    第１ゲームを実行する機能、
    ユーザが前記第１ゲームを実行するに当たって、前記第１ゲームの状況が第１条件を満たすか否かを判定する機能、
    前記第１条件を満たすと判定された場合に、前記第１ゲームに関連付けられた第２ゲームにおける前記ユーザのユーザ情報を取得する機能、及び、
    取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する機能、
    を実現させるためのプログラム。
21. コンピュータに、
    第１ゲームを実行する機能、
    前記第１ゲームにおけるユーザの実行状況が第１条件を満たすか否かを判定する機能、
    前記第１条件を満たすと判定された場合に、前記ユーザに関連付けられた第２ゲームにおけるユーザ情報を取得する機能、及び、
    取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する機能、
    を実現させるためのプログラム。
22. コンピュータに、
    第１ゲームを実行する機能、
    ユーザが前記第１ゲームを実行するに当たって、前記第１ゲームの状況が第１条件を満たすか否かを判定する機能、
    前記第１条件を満たすと判定された場合に、前記ユーザに関連付けられた第２ゲームのユーザ情報を取得する機能、及び、
    取得した前記第２ゲームにおけるユーザ情報を前記ユーザに通知する機能、
    を実現させるためのプログラム。
23. 通信端末からのアクセスに応じて第１ゲームを実行し、第１ゲーム上でユーザに関連する情報であるユーザ情報をユーザ毎に記憶装置に記憶又は更新させる第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行し、第２ゲーム上でユーザに関連する情報であるユーザ情報をユーザ毎に記憶装置に記憶又は更新させる第２サーバと、
    を含むゲームシステムにおけるゲーム制御方法であって、
    第１サーバが、ユーザによる前記第１ゲームの実行状況、あるいは前記第１ゲームの状況が第１条件を満たすか否かを判定するステップと、
    前記第１条件を満たすと判定された場合に、第１サーバが、前記ユーザの第２ゲームのユーザ情報に対する要求を行うステップと、
    第２サーバが、前記要求に応じて、前記ユーザの前記第２ゲームのユーザ情報を、第１サーバに提供するステップと、
    第１サーバが、前記ユーザの前記第２ゲームのユーザ情報を、前記ユーザの通信端末に送信するステップと、
    を含む、ゲーム制御方法。
24. 通信端末からのアクセスに応じて第１ゲームを実行し、第１ゲーム上でユーザに関連する情報であるユーザ情報をユーザ毎に記憶装置に記憶又は更新させる第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行し、第２ゲーム上でユーザに関連する情報であるユーザ情報をユーザ毎に記憶装置に記憶又は更新させる第２サーバと、
    を含むゲームシステムあって、
    第１サーバは、
    ユーザによる前記第１ゲームの実行状況、あるいは前記第１ゲームの状況が第１条件を満たすか否かを判定する第１判定手段と、
    前記第１判定手段により前記第１条件を満たすと判定された場合に、前記第１ゲームとは異なる第２ゲームにおける前記ユーザのユーザ情報を、前記第２サーバから取得する情報取得手段と、
    前記情報取得手段により取得した前記第２ゲームにおけるユーザ情報を、前記ユーザの通信端末に送信する通知手段と、を備え、
    第２サーバは、
    第１サーバからの前記要求に応じて、前記ユーザの前記第２ゲームにおけるユーザ情報を第１サーバに提供する提供手段、を備えた、
    ゲームシステム。
25. 通信端末からのアクセスに応じて第１ゲームを実行する第１サーバと、
    通信端末からのアクセスに応じて第２ゲームを実行する第２サーバと、
    前記第１サーバ及び前記第２サーバと接続されており、第１ゲーム上でユーザに関連する情報であるユーザ情報と、第２ゲーム上でユーザに関連する情報であるユーザ情報とを、ユーザ毎に記憶する記憶装置を備えた統括サーバと、を含むゲームシステムあって、
    第１サーバは、
    ユーザによる前記第１ゲームの実行状況、あるいは前記第１ゲームの状況が第１条件を満たすか否かを判定する第１判定手段と、
    前記第１判定手段により前記第１条件を満たすと判定された場合に、前記第１ゲームとは異なる第２ゲームにおける前記ユーザのユーザ情報を、前記統括サーバから取得する情報取得手段と、
    前記情報取得手段により取得した前記第２ゲームにおけるユーザ情報を、前記ユーザの通信端末に送信する通知手段と、を備え、
    統括サーバは、
    第２サーバから、前記ユーザの前記第２ゲームにおけるユーザ情報を取得し、前記記憶装置に記憶又は更新させる記憶手段と、
    第１サーバからの前記要求に応じて、前記ユーザの前記第２ゲームにおけるユーザ情報を第１サーバに提供する提供手段と、を備えた、
    ゲームシステム。

Images