JP5529924B2 - ゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置 - Google Patents

Description

本発明は、ユーザの操作に応じて、当該ユーザによるゲームやアプリケーション等のソフトウェアの利用を制御する技術に関する。

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

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

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

従来のソーシャルゲームでは、例えばゲームを初めて実行するユーザに対して、当該ゲームの仕様を説明するためのチュートリアルを行うように構成されている。ところで、従来のソーシャルゲームでは、例えば単なる釦の押下操作などの簡易な操作でゲームを進行させるものが多く存在し、それ故、ユーザは、例えば操作手順などの仕様が関連又は共通する複数のゲームの各々を、同じような操作手順で実行することができる。このような状況において、ユーザに対してチュートリアルが行われる場合に、当該ユーザが実行対象のゲームの仕様を容易に理解し得る仕組みが求められている。

本発明は上述した観点に鑑みてなされたもので、ユーザが、利用対象のゲームやアプリケーション等のソフトウェアの仕様を容易に理解することができるようにしたゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置を提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段と、
前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段と、
前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段と、
を備える。

ここで、「仕様」には、例えば、ゲームの操作手順に関する情報や、ゲームの構成に関する情報（例えば、ゲームのコンセプト、ゲーム上の世界観、ゲームのルールなど）や、ゲームの内容に関する情報（例えば、ゲーム上のエリア、キャラクタ、アイテムなどに関する情報）などが含まれてもよい。また、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。さらに、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。

このゲーム制御装置では、第１ゲームを実行するユーザに対して第１ゲームの仕様を説明するための第１情報が提供される際に、当該ユーザには、第１ゲームと第２ゲームとの間の仕様の関連度に関する情報に応じて、第２ゲームに関する第２情報が提供される。この場合、ユーザは、例えば操作手順などの仕様が第１ゲームと関連又は共通する第２ゲームについての情報を得ることができる。このため、例えば、ユーザが第２ゲームの仕様を理解していた場合には、ユーザは、第１情報が提供される際に、第２ゲームの仕様に基づいて第１ゲームの仕様を想定することが可能となる。これにより、ユーザは、実行対象の第１ゲームの仕様を容易に理解することができる。
また、例えば、ユーザが第２ゲームの仕様を理解していない場合であっても、ユーザは、第１ゲームと仕様が関連する第２ゲームについての情報を得ることができる。この場合、ユーザは、第１情報に基づき第１ゲームの仕様を理解することで第２ゲームの仕様も理解し得るので、当該ユーザの第２ゲームに対する興味を喚起することができる。これにより、ユーザに対して第２ゲームを実行するように動機付けることができるので、第２ゲームのユーザ数を増やすことができ、ひいてはゲームコミュニティを活性化させることができる。

上記ゲーム制御装置において、前記第２ゲームは、前記ユーザが実行経験を有するゲームであってもよい。
このゲーム制御装置では、ユーザには、第１ゲームと、当該ユーザが実行経験を有する第２ゲームとの間の仕様の関連度に関する情報に応じて、第２ゲームに関する第２情報が提供される。この場合、ユーザは、第２ゲームの実行経験を有することにより、第２ゲームの仕様を理解していると考えられる。このため、ユーザは、第１情報が提供される際に、第２ゲームの仕様に基づいて第１ゲームの仕様の理解度を高めることができる。

上記ゲーム制御装置において、前記第２情報提供手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行状況とに応じて、前記第２情報を前記ユーザに提供してもよい。
ここで、「第２ゲームの実行状況」とは、例えば、ユーザが、第２ゲーム上で制覇（クリア）したパートの数であってもよいし、ユーザが、第２ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、「第２ゲームの実行状況」とは、例えば、ユーザが第２ゲーム上で獲得した特定のアイテムの数であってもよいし、第２ゲームの進行度や技能レベルの高さなどであってもよい。
例えば、第１ゲームと第２ゲームとの仕様の関連度が高く、且つ、ユーザによる第２ゲームの実行状況がある程度進んでいる場合、当該ユーザに対して第１情報が提供される際に、当該ユーザは、第２情報を得ることができる。この場合、ユーザは、実行状況がある程度進んでいることにより第２ゲームの仕様の理解度が高いと考えられる。このため、ユーザは、仕様の理解度の高い第２ゲームに基づいて、第１ゲームの仕様の理解度をさらに高めることができる。

上記ゲーム制御装置において、前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの実行回数を含み、前記第２情報提供手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行回数とに応じて、前記第２情報を前記ユーザに提供してもよい。
例えば、ユーザによる第２ゲームの実行回数が多いほど、第２ゲームの仕様に対する当該ユーザの理解度が高いと考えられる。このため、ユーザに対して第１情報が提供される際に、第１ゲームと仕様が関連し、且つ、当該ユーザによる仕様の理解度の高い第２ゲームについての情報が当該ユーザに提供されることにより、当該ユーザは、第２ゲームの仕様に基づいて、第１ゲームの仕様の理解度をさらに向上させることができる。

上記ゲーム制御装置において、前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間を含み、前記第２情報提供手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間とに応じて、前記第２情報を前記ユーザに提供してもよい。
例えば、ユーザによる第２ゲームの最新の実行時期からの経過時間が短いほど、当該ユーザは第２ゲームの仕様の記憶の程度が高いと考えられる。このため、ユーザに対して第１情報が提供される際に、第１ゲームと仕様が関連し、且つ、当該ユーザによる仕様の記憶の程度の高い第２ゲームについての情報が当該ユーザに提供されることにより、当該ユーザは、第２ゲームの仕様に基づいて、第１ゲームの仕様の理解度をさらに向上させることができる。

上記ゲーム制御装置において、前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の情報量を制限する制限手段を備えてもよい。
例えば、ユーザが第２ゲームの仕様を理解していた場合には、ユーザは、第２情報が提供されることにより、第２ゲームの仕様に基づいて第１ゲームの仕様を想定することが可能となる。この場合、ユーザにとっては、第１情報が不要であり、逆に第１情報が提供されることによって煩わしさを感じることが考えられる。
このゲーム制御装置によれば、関連度に関する情報に応じて、第１情報の情報量を制限することができるので、ユーザは、煩わしさを感じることなく、第２ゲームの仕様に基づいて第１ゲームの仕様を容易に理解することができる。

上記ゲーム制御装置において、前記関連度に関する情報に応じて、前記ユーザに対して前記第１情報を提供するか否かの選択を受け付ける受付手段を備え、前記制限手段は、前記ユーザに対して前記第１情報を提供しないように選択された場合に、前記ユーザに対する前記第１情報の情報量を制限してもよい。
この場合、例えばユーザが第２ゲームの仕様を理解していた場合であっても、ユーザは、第１情報の提供を受けるか否かを自ら選択することができる仕組みとすることができる。

上記ゲーム制御装置において、前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記第１ゲームの仕様との関連度が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供してもよい。
例えば、ユーザが複数の第２ゲームの仕様を理解していた場合には、複数の第２ゲームのうち第１ゲームの仕様との関連度が高い（所定の条件を満たす）ゲームについての第２情報が提供されることにより、ユーザは、複数の第２ゲームの中から第１ゲームの仕様との関連度が高い第２ゲームを絞り込むことができる。これにより、ユーザは、絞り込まれた第２ゲームの仕様に基づいて第１ゲームの仕様を早期に想定することができる。

上記ゲーム制御装置において、前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記ユーザによる実行状況が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供してもよい。
例えば、ユーザに対して、複数の第２ゲームのうちユーザによる実行状況がある程度進んだ（所定の条件を満たす）ゲームについての第２情報が提供されることにより、ユーザは、複数の第２ゲームの中から、仕様を理解している第２ゲームを絞り込むことができる。これにより、ユーザは、第２ゲームの仕様に基づいて第１ゲームの仕様を早期に想定することができる。

本発明の第２の観点は、ゲーム制御方法である。
当該ゲーム制御方法は、
第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供するステップと、
前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を取得するステップと、
前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供するステップと、
を備える。

本発明の第３の観点は、コンピュータに、
コンピュータに、
第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する機能、
前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を記憶する記憶装置から前記関連度に関する情報を取得する機能、及び
前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する機能、
を実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段、
前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段、
前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

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

本発明の第５の観点は、情報処理装置である。
当該情報処理装置は、
第１ソフトウェアを利用するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する第１情報提供手段と、
前記第１ソフトウェアと、前記第１ソフトウェアと異なる第２ソフトウェアとの間の仕様の関連度に関する情報を取得する取得手段と、
前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ソフトウェアに関する第２情報を前記ユーザに提供する第２情報提供手段と、
を備える。

本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステム、情報処理装置によれば、ユーザは、利用対象のゲームやアプリケーション等のソフトウェアの仕様を容易に理解することができる。

実施形態のゲームシステムの基本構成を示す図。 実施形態の通信端末の外観の例を示す図。 実施形態の通信端末の構成を示すブロック図。 実施形態のゲームサーバの構成を示すブロック図。 実施形態のデータベースサーバの構成を示すブロック図。 ゲームＡのユーザデータベースの構成例を示す図。 ゲームＢのユーザデータベースの構成例を示す図。 仕様データのデータ構成例を示す図。 実施形態の統括サーバの構成を示すブロック図。 関連度データのデータ構成例を示す図。 実行状況管理データのデータ構成例を示す図。 ゲームＡのトップページを表示する通信端末の表示画面の一例を示す図。 ゲームＡの実行中にユーザの通信端末に表示されるウェブページを例示する図。 ゲームＢのトップページを表示する通信端末の表示画面の一例を示す図。 ゲームＢの実行中にユーザの通信端末に表示されるウェブページを例示する図。 ゲームＡのチュートリアルにおいてユーザの通信端末に表示される一連のウェブページを例示する図。 ゲームＡのチュートリアルにおいてユーザの通信端末に表示されるウェブページを例示する図。 実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。 変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例においてゲームＡのチュートリアル中にユーザの通信端末に表示されるウェブページを例示する図。 変形例のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。 変形例においてユーザの通信端末に表示されるウェブページを例示する図。 通信端末及びゲームサーバの各々における各機能の構成例を示す図。

以下、本発明の実施形態について説明する。
ここで、本実施形態では、ユーザが、自ら保有する通信端末を用いて、ソフトウェアの一例であるゲーム用アプリケーションを利用する場合を例に挙げて説明する。なお、ソフトウェアは、ゲーム用アプリケーションに限られず、例えばＯＳ(Operating System)や文書作成用ソフトウェアなどのように、コンピュータ上で何らかの処理を行うように構成されたものであれば何でもよい。

（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０ａ及びデータベースサーバ３０ａ，ゲームサーバ２０ｂ及びデータベースサーバ３０ｂ，…と、統括サーバ４０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。

このゲームシステムにおいて、ゲームサーバ２０ａ及びデータベースサーバ３０ａは、ゲームＡ（第１ゲーム）の実行について、ネットワークを介したサービスを通信端末１０に提供するために設けられている。ゲームサーバ２０ｂ及びデータベースサーバ３０ｂは、ゲームＡと異なるゲームＢ（第２ゲーム）の実行について、ネットワークを介したサービスを通信端末１０に提供するために設けられている。ここで、「第１ゲーム」は、本発明の「第１ソフトウェア」の一例であり、「第２ゲーム」は、本発明の「第２ソフトウェア」の一例である。
なお、以下の説明において、各ゲームサーバ２０ａ，２０ｂ，…に共通して言及するときには、ゲームサーバ２０と表記する。同様に、各データベースサーバ３０ａ，３０ｂ，…に共通して言及するときには、データベースサーバ３０と表記する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのために、対応するゲームサーバ２０と例えば有線で接続される。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０でウェブページに対する操作を行うことにより、ゲームを実行する。

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

統括サーバ４０は、複数のゲームサーバ２０ａ，２０ｂ，…を管理するために設けられている。各ゲームサーバ２０は、処理対象となるゲームについて登録したユーザの情報を保持しているが、統括サーバ４０は、特定のゲームに依存しないユーザの情報や、ゲームごとのユーザの情報を一元的に管理することによって、例えば、ユーザによる新たなゲームの登録サービスや、ゲームコミュニティの形成を支援する等のために設けられている。
なお、本実施形態のゲームシステムでは、統括サーバ４０を含む場合を一例として説明しているが、例えば複数のゲームサーバ２０ａ，２０ｂ，…の何れかが統括サーバ４０の機能を実現可能に構成されている場合には、統括サーバ４０をゲームシステムに設けなくてもよい。

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

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

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

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

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

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

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

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

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

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

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

本実施形態のゲームサーバ２０ａ及びデータベースサーバ３０ａによって提供されるゲームＡのタイプは特に限定されるものではないが、以下では、説明の便宜上、戦士カードを用いたデジタルカードゲームとする。ゲームＡは、ユーザの実行対象となる以下の処理を含む。
・クエスト処理：
少なくとも一枚の戦士カードからなる自らのチームを作り上げていくために、ゲームＡ上で設定されている複数のエリアを探索して戦士カードを得る処理である。ゲームＡでは、クエスト処理を実行することで一定量の体力ポイント（後述する）を消費するが、合成ポイント（後述する）が得られるようになっている。
・合成処理：
２枚以上の戦士カードを一体化して特定の戦士カードの能力を上昇させる処理である。ゲームＡでは、ユーザが合成処理を実行するには一定量の合成ポイント（後述する）が必要となる。
・バトル処理：
他のユーザのチームとバトル（対戦）を行う処理である。ゲームＡでは、バトル処理を実行することで攻撃ポイント（後述する）を消費するが、バトルに勝利すれば合成ポイントが例えば一定量増加する。なお、バトル処理については、ここでは詳しく述べないが、例えばユーザがバトルで使用する戦士カードの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）の大小に応じて、バトルの結果が決定されるように構成される。例えば、パラメータの値の大きい戦士カードをバトルに使用したユーザが、それよりパラメータの値の小さい戦士カードをバトルに使用した他のユーザに対して勝利する可能性が高くなるように設定されてもよい。この場合、ユーザの保有する戦士カードのパラメータの値が大きいほど、他のユーザと比べてゲームＡをより優位に進められるようになる。

また、本実施形態のゲームサーバ２０ｂ及びデータベースサーバ３０ｂによって提供されるゲームＢのタイプは特に限定されるものではないが、以下では、説明の便宜上、野球形式のデジタルカードゲームとする。ゲームＢは、ユーザの実行対象となる以下の処理を含む。
・スカウト処理：
自らのチームを作り上げていくために、ゲームＢ上で設定されている複数のエリアを探索して選手カードを得る処理である。ゲームＢでは、スカウト処理を実行することで一定量の行動ポイント（後述する）を消費するが、強化ポイント（後述する）が得られるようになっている。なお、後述するように、本実施形態では、スカウト処理の操作手順などの仕様は、ゲームＡのクエスト処理の仕様と関連又は共通するように構成されている。
・強化処理：
２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理である。ゲームＢでは、ユーザが強化処理を実行するには一定量の強化ポイント（後述する）が必要となる。なお、ここでは詳しく述べないが、本実施形態では、強化処理の操作手順などの仕様は、ゲームＡの合成処理の仕様と関連又は共通するように構成されている。
・試合処理：
他のユーザのチームと試合を行う処理である。ゲームＢでは、試合処理を実行することで攻撃ポイント（後述する）を消費するが、試合に勝利すれば強化ポイントが例えば一定量増加する。なお、試合処理については、ここでは詳しく述べないが、例えばユーザが試合で使用する選手カードの能力を示すパラメータ（例えば、走力、打力、守備力などを示す値）の大小に応じて、試合の結果が決定されるように構成される。例えば、試合で使用する選手カードのパラメータの合計の大きいユーザが、それよりパラメータの合計の小さい他のユーザに対して勝利する可能性が高くなるように設定されてもよい。この場合、ユーザは、選手カードのパラメータの合計が大きいほど、他のユーザと比べてゲームＢをより優位に進められるようになる。
また、本実施形態では、試合処理の操作手順などの仕様は、ゲームＡのバトル処理の仕様と関連又は共通するように構成されている。

図６に、本実施形態のゲームＡにおいて適用されるデータベースサーバ３０ａ内のユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、表示画像、技能レベル、体力ポイント、攻撃ポイント、合成ポイント、戦士数、仲間のユーザＩＤ及び保有カードのデータの各項目についての情報を含む。図６に例示したユーザデータベース３１に含まれる情報は、ゲームサーバ２０ａによって逐次更新されうる。
なお、ユーザが複数のゲーム（ゲームＡ、ゲームＢ、…）の各々を実行する場合、当該ユーザのユーザＩＤは、各ゲーム間で共通に用いられてもよい。

データベースサーバ３０ａ内のユーザデータベース３１に含まれる各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・技能レベル
ゲームＡ上のユーザの技能レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。例えば、クエスト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・体力ポイント
ゲームＡにおいて、クエスト処理を実行する上で必要となるポイントである。体力ポイントは、クエスト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・攻撃ポイント
ゲームＡにおいて、バトル処理を実行する上で必要となるポイントである。攻撃ポイントは、他のユーザのチームとのバトルによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・合成ポイント
ゲームＡにおいて、合成処理を実行する上で必要となるポイントである。合成ポイントは、戦士カードの強化を行うことで低減し、他のユーザのチームとのバトルで勝利することで増加する値である。
・戦士数
ユーザが保有する戦士カードの数である。戦士数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
仲間のユーザのユーザＩＤのデータである。
・保有カードのデータ
ユーザが保有する戦士カードごとに、例えば、戦士のキャラクタの画像や、戦士のキャラクタの能力を示すパラメータ（例えば、攻撃力、防御力を示す値）等のデータが含まれる。

図７に、本実施形態のゲームＢにおいて適用されるデータベースサーバ３０ｂ内のユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名、表示画像、技能レベル、行動ポイント、運営ポイント、強化ポイント、選手数、仲間のユーザＩＤ及び保有カードのデータの各項目についての情報を含む。図７に例示したユーザデータベース３１に含まれる情報は、ゲームサーバ２０ｂによって逐次更新されうる。

データベースサーバ３０ｂ内のユーザデータベース３１に含まれる各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０のユーザを特定するために表示されるユーザ名及び表示画像である。なお、ユーザが複数のゲーム（ゲームＡ、ゲームＢ、…）の各々を実行する場合、当該ユーザのユーザ名／表示画像は、各ゲーム間で共通に用いられてもよい。
・技能レベル
ゲームＢ上のユーザの技能レベルを示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値である。例えば、スカウト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・行動ポイント
ゲームＢにおいて、スカウト処理を実行する上で必要となるポイントである。行動ポイントは、スカウト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・運営ポイント
ゲームＢにおいて、試合処理を実行する上で必要となるポイントである。運営ポイントは、他のユーザと試合を行うことによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
ゲームＢにおいて、強化処理を実行する上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの試合で勝利することで増加する値である。
・選手数
ユーザが保有する選手カードの数である。選手数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
仲間のユーザのユーザＩＤのデータである。なお、ユーザがゲームＡとゲームＢに登録している場合、当該ユーザの仲間は各々のゲームで異なっていてもよい。つまり、当該ユーザの仲間のユーザＩＤは、図６に例示したユーザデータベース３１内の当該ユーザのユーザＩＤに対応する仲間のユーザＩＤと異なっていてもよい。
・保有カードのデータ
ユーザが保有する選手カードごとに、例えば、選手のキャラクタの画像や、選手のキャラクタの能力を示すパラメータ（例えば、選手が野手である場合には、走力、打力、守備力を示す値であってもよいし、選手が投手である場合には、球速、制球力、スタミナを示す値であってもよい）等のデータが含まれる。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ユーザによるゲームの実行状況に関する情報を記憶、更新する。ゲームの実行状況に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームＡの場合を例に挙げれば、ゲームの実行状況に関する情報は、クエスト処理の進行状況を示す情報や、他のユーザとのバトル結果についての情報などを含む。また、本実施形態のゲームＢの場合を例に挙げれば、ゲームの実行状況に関する情報は、スカウト処理の進行状況を示す情報や、他のユーザとの試合の結果についての情報などを含む。
また、後述するように、本実施形態のゲームでは、ゲームを実行するユーザに対して、当該ゲームの仕様を説明するためのチュートリアルが行われるようになっている。そのため、ゲームデータベース３２には、ゲームの仕様を説明するための説明情報（第１情報）が記述された仕様データが記憶されている。ゲームＡの仕様データの例を図８に示す。

仕様データは、ゲーム上でチュートリアルが行われる際に例えばＲＡＭ２３にロードされ、記憶されるデータである。仕様データは、ゲームに含まれる処理ごとに、当該処理の仕様を説明するための説明情報を含む。ここで、「仕様」には、例えば、ゲームの操作手順に関する情報や、ゲームの構成に関する情報（例えば、ゲームのコンセプト、ゲーム上の世界観、ゲームのルールなど）や、ゲームの内容に関する情報（例えば、ゲーム上のエリア、キャラクタ、アイテムなどに関する情報）などが含まれてもよい。また、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。さらに、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。
なお、図８に例示した仕様データは、ゲームに含まれる処理（図の例では、クエスト処理、合成処理、バトル処理）ごとに説明情報が対応付けられるように構成されているが、仕様データは、例えば一つのゲーム全体の仕様が一つの説明情報としてまとめられた状態で構成されてもよい。また、図８に例示した仕様データの説明情報は、テキストデータで構成されているが、例えば、画像データや音声データなどで構成されてもよい。

（５）統括サーバの構成
図９を参照して統括サーバ４０の構成について説明する。
統括サーバ４０は、複数のゲームサーバ２０ａ，２０ｂ，…と通信可能に接続されている。図９に示すように、統括サーバ４０は、ＣＰＵ４１、ＲＯＭ４２、ＲＡＭ４３、ＨＤＤ(Hard Disk Drive)４４、及び、通信インタフェース部４５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス４６が設けられている。なお、統括サーバ４０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。

ＲＯＭ４２には、ＣＰＵ４１によって実行される各種プログラムのほか、プログラムの実行に伴ってＣＰＵ４１によって参照される各種データが格納されている。
ＣＰＵ４１は、ＲＯＭ４２内のプログラムをＲＡＭ４３にロードして実行し、各種の処理を行う。ＣＰＵ４１によって実行される処理には、通信インタフェース部４５を介して、各ゲームサーバ２０から、対象となるゲームの情報と、対象となるユーザの情報（ユーザＩＤ及び／又はユーザ名、ユーザによるゲームの実行状況など）とを取得し、取得した情報をＨＤＤ４４内の実行状況管理データ（後述する）に書き込む処理や、ゲームサーバ２０からの要求に応じて関連度データ（後述する）内の情報を要求元のゲームサーバ２０宛に送信する処理などが含まれる。

図１０に、関連度データのデータ構成例を示す。図１０に示すように、関連度データは、複数のゲームサーバ２０ａ，２０ｂ，…で実行されるゲームごとに、当該ゲームの処理と、当該処理と仕様が関連又は共通する他のゲームの処理とが対応付けて記述されているデータである。図１０の例を参照して説明すると、ゲームＡの「クエスト」処理の仕様は、ゲームＢの「スカウト」処理の仕様、及びゲームＣの「ミッション」処理の仕様の各々と関連している。なお、ここでは、ゲームＣについての詳細な説明は省略する。また、図１０の例では、ゲームＡの「合成」処理の仕様はゲームＢの「強化」処理の仕様と関連しており、ゲームＡの「バトル」処理の仕様はゲームＢの「試合」処理の仕様と関連している。ここで、複数のゲーム間における処理の関連付けは、例えば、ゲーム提供者などによって任意に設定されてもよい。
また、関連度データには、複数のゲームサーバ２０ａ，２０ｂ，…で実行されるゲームごとに、他のゲームの仕様との関連度合いを示す関連度が対応付けて記述されている。この関連度は、例えば、他のゲームの仕様との関連性が高いほど大きくなるように設定されてもよい。本実施形態のゲームの場合を例に挙げれば、関連度は、ゲームに含まれる処理数に対する、他のゲームの処理との間で仕様が関連する処理の数の割合としてもとめられてもよい。図１０の例を参照して説明すると、ゲームＡに含まれる処理数は３つ（クエスト処理、合成処理、バトル処理）であり、各処理の仕様は何れもゲームＢに含まれる処理（スカウト処理、強化処理、試合処理）の仕様と関連している。この場合、ゲームＡとゲームＢの仕様の関連度は、３／３＝１となる。また、図１０の例では、ゲームＡの処理のうち、ゲームＣとの間で仕様が関連する処理の数が１つ（クエスト処理）であるため、ゲームＡとゲームＣの仕様の関連度は、１／３≒０．３となる。また、関連度は、所定の演算式等を用いて、ゲームに含まれる処理数と、他のゲームの処理との間で仕様が関連する処理の数とを当該演算式に当てはめることで求められてもよい。
なお、本実施形態では、関連度の最大値が１となる場合を一例として説明したが、関連度の最大値は任意に設定されてもよい。また、ゲーム間の仕様の関連度は、例えば、ゲーム提供者などによって任意に設定されてもよい。

図１１に、実行状況管理データのデータ構成例を示す。図１１に示すように、実行状況管理データは、ユーザ（ユーザＩＤ）ごとに、複数のゲームサーバ２０ａ，２０ｂ，…で実行されるゲームの実行状況が対応付けて記述されているデータである。ここで、ゲームの実行状況とは、例えば、ユーザがゲーム上で制覇（クリア）したパートの数であってもよいし、ユーザが、ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、ゲームの実行状況とは、例えば、ユーザがゲーム上で獲得した特定のアイテムの数であってもよいし、ゲームの進行度や技能レベルの高さなどであってもよい。
なお、実行状況管理データは、本発明に必須のデータではないが、本発明をさらに好ましくするためのデータである。
統括サーバ４０のＣＰＵ４１は、例えば、所定時間が経過するごとに、複数のゲームサーバ２０ａ，２０ｂ，…に対し、各ユーザによるゲームの実行状況に関する情報の送信を要求する。そして、ＣＰＵ４１は、各ユーザによるゲームの実行状況に関する情報を各ゲームサーバ２０ａ，２０ｂ，…から受信すると、当該情報に含まれるゲームの実行状況を実行状況管理データ内の対応するユーザＩＤごとに記録する。
また、ＣＰＵ４１は、各ユーザによるゲームの実行状況に関する情報の送信を要求しない場合であっても、当該情報が各ゲームサーバ２０ａ，２０ｂ，…から任意のタイミングで送信されたときには、当該情報を受信し、当該情報に含まれるゲームの実行状況を実行状況管理データ内の対応するユーザＩＤごとに記録してもよい。
なお、ＣＰＵ４１は、ユーザがゲームの実行経験を有していない場合には、実行状況管理データ内の対応するユーザＩＤの当該ゲームの実行状況の項目にＮＵＬＬデータを記録してもよい。

（６）本実施形態のゲーム
次に、本実施形態のゲームＡについて、図１２〜１３を参照しながら説明する。図１２は、本実施形態のゲームＡにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１３は、クエスト処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。
図１２に例示するゲームＡのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図１２の例では、ユーザデータ表示領域、戦士画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、体力ポイント、攻撃ポイント、合成ポイント、戦士数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、図１２において、戦士数の一例として「５／６０」と表記されているが、これは、ユーザが保有する戦士カードが５枚であり、最大で保有可能な戦士カードの枚数が６０枚であることを示す。
戦士画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の戦士カードのうちユーザによって予め指定された戦士カードの画像が表示される領域である。
メニュー表示領域は、ゲームＡに設けられる複数の機能（クエスト処理、合成処理、バトル処理）に対応した基本メニューとして、「クエスト」、「合成」、「バトル」のテキストが表記された各メニューｍ１〜ｍ３が表示される領域である。
このトップページ上で、メニューｍ１〜ｍ３の何れかが選択操作されることで、ゲームＡの実行が開始される。
なお、ゲームＡでは、ユーザがゲームＡに登録した後に初めてゲームＡを実行する場合に、当該ユーザに対してゲームＡの仕様を説明するためのチュートリアルが行われるようになっている。チュートリアルの詳細については、後述する。

図１２のトップページ上でメニューｍ１が選択操作されると、クエスト処理が実行される。この場合、図１３に示すようにウェブページが更新される。図１３のウェブページには、探索の対象となるエリア（図１３の例では、エリア１）の進行度合いを示す探索率のゲージ、探索処理を実行するための「探索する」と表記されたメニューｍ１０などが含まれる。
クエスト処理では、メニューｍ１０が選択操作されると、この操作を契機として、探索の対象となるエリアについての戦士カードの探索が行われる。このとき、メニューｍ１０が選択操作されて探索が行われる度に、「探索率」（％）の値が一定の、あるいはランダムな増加量で増加する。探索率が１００％に達した場合には、対象となるエリアの探索が終了したことになり、次のエリア（ここでは、エリア２）の探索に移る。上述したように、ゲームＡでは、１回の探索につき、所定量（例えば５ポイント）の体力ポイントが減少するように構成されており、体力ポイントの値が所定量よりも少なくなった場合には、探索処理を実行することができない。この場合、ユーザは、体力ポイントの値が回復（増加）するまで待機する必要がある。なお、図１３に例示したウェブページは、１回の探索に要する体力ポイントの値や、１回の探索で得られた合成ポイントの値などが表示されるように構成されてもよい。

次に、本実施形態のゲームＢについて、図１４〜１５を参照しながら説明する。図１４は、本実施形態のゲームＢにおいて通信端末１０上に表示されるトップページの一例を示す図である。図１５は、スカウト処理が実行されるときの通信端末１０上に表示されるウェブページの例を示す図である。
図１４に例示するゲームＢのトップページは、個々のユーザＩＤに応じたウェブページで構成される。図１４の例では、ユーザデータ表示領域、選手画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、選手数、仲間の各項目のデータ（図７参照）が表示される領域である。
選手画像表示領域は、対象となるユーザＩＤのユーザデータに含まれる複数の選手カードのうちユーザによって予め指定された選手カードの画像が表示される領域である。
メニュー表示領域は、ゲームＢに設けられる複数の機能（スカウト処理、強化処理、試合処理）に対応した基本メニューとして、「スカウト」、「強化」、「試合」のテキストが表記された各メニューｍ２１〜ｍ２３が表示される領域である。
このトップページ上で、メニューｍ２１〜ｍ２３の何れかが選択操作されることで、ゲームＢの実行が開始される。

図１４のトップページ上でメニューｍ２１が選択操作されると、スカウト処理が実行される。この場合、図１５に示すようにウェブページが更新される。図１５のウェブページには、探索の対象となるエリア（図１５の例では、エリア９）の進行度合いを示す探索率のゲージ、探索処理を実行するための「探索する」と表記されたメニューｍ２４などが含まれる。
スカウト処理では、メニューｍ２４が選択操作されると、この操作を契機として、探索の対象となるエリアについての選手カードの探索が行われる。このとき、メニューｍ２４が選択操作されて探索が行われる度に、「探索率」（％）の値が一定の、あるいはランダムな増加量で増加する。探索率が１００％に達した場合には、対象となるエリアの探索が終了したことになり、次のエリア（ここでは、エリア１０）の探索に移る。上述したように、ゲームＢでは、１回の探索につき、所定量（例えば５ポイント）の行動ポイントが減少するように構成されており、行動ポイントの値が所定量よりも少なくなった場合には、探索処理を実行することができない。この場合、ユーザは、行動ポイントの値が回復（増加）するまで待機する必要がある。なお、図１５に例示したウェブページは、１回の探索に要する行動ポイントの値や、１回の探索で得られる強化ポイントの値が表示されるように構成されてもよい。
図１３及び図１５を参照して説明したように、ゲームＢのスカウト処理の仕様は、ゲームＡのクエスト処理の仕様と関連又は共通するように構成されている。

次に、ゲームＡにおいて行われるチュートリアルについて、図１６〜１７を参照しながら説明する。図１６〜１７は、本実施形態のゲームＡのチュートリアルにおいて通信端末１０上に表示される一連のウェブページの一例を示す図である。
例えば、ユーザがゲームＡに登録した後に初めてゲームＡを実行する場合、図１２に示すトップページ上でユーザがメニューｍ１〜ｍ３の何れかの選択操作を行うと、図１６のステップＳ１に例示するウェブページが当該ユーザの通信端末１０上に表示される。ステップＳ１のウェブページは、クエスト処理の仕様の説明が行われるように構成されている。ステップＳ１のウェブページには、クエスト処理の仕様を説明するための説明情報（図８参照）が表示される表示領域１０１と、ゲームＡと異なる他のゲーム（図の例ではゲームＢ）に関する関連ゲーム情報（第２情報）が表示される表示領域１０２と、「次へ」と表記されたメニューｍ１１などが含まれる。関連ゲーム情報は、図に例示したように、説明対象の処理（図の例ではクエスト処理）と仕様が関連又は共通する他のゲーム（図の例ではゲームＢ）の処理（図の例ではスカウト処理）を通知するメッセージなどで構成されてもよい。
この場合、ユーザは、ゲームＡのクエスト処理と仕様（例えば操作手順など）が関連又は共通するスカウト処理を含むゲームＢについての情報を得ることができる。このため、例えば、ユーザがスカウト処理の仕様を理解していた場合には、ユーザは、クエスト処理の説明情報が提供される際に、ゲームＢのスカウト処理の仕様に基づいてゲームＡのクエスト処理の仕様を容易に理解することができる。

次に、ステップＳ１のウェブページ上でユーザがメニューｍ１１を選択操作すると、図１６のステップＳ２に示すように、合成処理の仕様の説明が行われるウェブページに更新される。ステップＳ２に示すウェブページの表示領域１０１には、合成処理の仕様を説明するための説明情報（図８参照）が表示される。また、表示領域１０２に表示される関連ゲーム情報は、ステップＳ１と同様に、説明対象の処理（図の例では合成処理）と仕様が関連又は共通する他のゲーム（図の例ではゲームＢ）の処理（図の例では強化処理）を通知するメッセージなどで構成されてもよい。
例えば、ユーザがゲームＢの強化処理の仕様を理解していた場合には、ユーザは、合成処理の説明情報が提供される際に、ゲームＢの強化処理の仕様に基づいてゲームＡの合成処理の仕様を容易に理解することができる。

さらに、ステップＳ２のウェブページ上でユーザがメニューｍ１１を選択操作すると、図１７のステップＳ３に示すように、バトル処理の仕様の説明が行われるウェブページに更新される。ステップＳ３に示すウェブページの表示領域１０１には、バトル処理の仕様を説明するための説明情報（図８参照）が表示される。また、表示領域１０２に表示される関連ゲーム情報は、ステップＳ１，Ｓ２と同様に、説明対象の処理（図の例ではバトル処理）と仕様が関連又は共通する他のゲーム（図の例ではゲームＢ）の処理（図の例では試合処理）を通知するメッセージなどで構成されてもよい。
例えば、ユーザがゲームＢの試合処理の仕様を理解していた場合には、ユーザは、バトル処理の説明情報が提供される際に、ゲームＢの試合処理の仕様に基づいてゲームＡのバトル処理の仕様を容易に理解することができる。

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

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

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

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

ゲーム実行手段５２は、ゲームを実行する機能を備える。例えば、ゲーム実行手段５２は、通信端末１０に対するユーザのウェブページ上の選択操作に応じてＨＴＴＰリクエストを受信し、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータ（つまり、ＨＴＴＰレスポンス）を送信することで、ウェブサービスにより本実施形態のゲームを実行する。
なお、ゲーム実行手段５２は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。

また、ゲーム実行手段５２は、ユーザが本実施形態のゲームを実行するに当たって、ユーザのログイン時の認証処理を実行する機能を備えてもよい。
この機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、各ユーザの通信端末１０からのＨＴＴＰリクエストを受信すると、当該ＨＴＴＰリクエストから個体識別情報、あるいはユーザＩＤ及びパスワードを取得し、その個体識別情報、あるいはユーザＩＤ及びパスワードを、例えばユーザデータベース３１に記録済みのデータと照合して認証処理を行う。

ここでは、ゲーム実行手段５２がゲームＡを実行する場合を一例として説明する。
ゲーム実行手段５２は、通信端末１０に表示されたメニューｍ１〜ｍ３のいずれかに対するユーザの選択操作に応じて、クエスト処理、合成処理あるいはバトル処理を実行する。好ましくは、各処理が実行された場合、さらに細分化された複数のメニューを含む新たなウェブページが表示されるように、階層的に各処理が実行される。

ゲーム実行手段５２がクエスト処理を実行する機能は、以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、図１２のトップページ上でメニューｍ１が選択操作されたことを認識すると、図１３に示すウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。また、ＣＰＵ２１は、メニューｍ１０が選択操作されることを認識すると、ユーザデータベース３１にアクセスし、対象となるユーザＩＤの体力ポイントの値を更新する（減少させる）。なお、クエスト処理において、探索対象となるエリアごとに、１回の探索に要する体力ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）体力ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される体力ポイントの量を多くしてもよい。

クエスト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、クエスト処理用に予め設けられた複数の戦士カードの中から所定の、あるいはランダムな確率で戦士カードを抽選して出現させる。ＣＰＵ２１は、戦士カードを出現させた（発掘した）場合には、データベースサーバ３０ａ内のユーザデータベース３１にアクセスし、対象となるユーザＩＤのデータに対して、出現した新たな戦士カードのデータを追加して、戦士数の値を１だけ増加させる。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図１５のウェブページにおいてエリアの探索率が１００％に達すると、探索対象となるエリア（この場合、エリア１）についての探索は終了し、探索対象は次のエリア（この場合、エリア２）に移る。

クエスト処理では、メニューｍ１０に対する選択操作を行う度に体力ポイントが減少していくため、クエスト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される体力ポイントがクエスト処理の実行前よりも減少されて表示されることになる。なお、体力ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）する。

また、ゲーム実行手段５２は、ユーザによるゲームの実行状況をゲームデータベース３２に記憶する機能を備えてもよい。この場合、ＣＰＵ２１は、ユーザがクエスト処理、合成処理、あるいはバトル処理を実行するごとに、その実行結果（例えば、エリアの探索率、合成処理の実行回数、バトル処理の実行回数、バトルの結果など）を、当該ユーザのユーザＩＤと対応付けてゲームデータベース３２に記憶する。
また、ＣＰＵ２１は、各ユーザによるゲームの実行状況に関する情報の送信要求を統括サーバ４０から受け付けた場合、ゲームデータベース３２に記憶された各ユーザの実行結果を抽出して、統括サーバ４０に送信する。なお、ＣＰＵ２１は、所定時間が経過するごとに、ゲームデータベース３２に記憶された各ユーザの実行結果を抽出して、統括サーバ４０に送信してもよい。

第１情報提供手段５３は、ゲームＡ（第１ゲーム）を実行するユーザに対して、ゲームＡの仕様を説明するための説明情報（第１情報）を提供する機能を備える。
第１情報提供手段５３の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１２のトップページ上でメニューｍ１〜ｍ３の何れかが選択操作されたことを認識すると、選択操作を行ったユーザがゲームＡを初めて実行したか否かを判別する。この判別処理の一例を説明すると、ＣＰＵ２１は、データベースサーバ３０ａ内のゲームデータベース３２にアクセスして、選択操作を行ったユーザによるゲームＡの実行結果が記憶されていない場合には、当該ユーザがゲームＡを初めて実行したと判別してもよい。
ＣＰＵ２１は、選択操作を行ったユーザがゲームを初めて実行したことを判別すると、仕様データからスカウト処理の説明情報を抽出し、図１６のステップＳ１のウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。ここで、ステップＳ１〜Ｓ３のウェブページの表示領域１０２に表示される関連ゲーム情報は、後述する第２情報提供手段５５の機能により生成される情報である。また、ＣＰＵ２１は、ステップＳ１のウェブページ上でメニューｍ１１が選択操作されると、仕様データから合成処理の説明情報を抽出し、図１６のステップＳ２のウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。さらに、ＣＰＵ２１は、ステップＳ２のウェブページ上でメニューｍ１１が選択操作されると、仕様データからバトル処理の説明情報を抽出し、図１７のステップＳ３のウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。
なお、本実施形態では、ユーザがゲームを初めて実行した場合に説明情報を提供する場合を一例として説明したが、説明情報を提供するタイミングはこれに限られない。例えば、第１情報提供手段５３は、ユーザの必要に応じて説明情報を提供するようにしてもよい。この場合、ゲームの仕様を説明するためのメニューを例えば図１２のトップページに設け、ＣＰＵ２１は、ユーザが当該メニューの選択操作を行ったときに、図１６のステップＳ１のウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。

取得手段５４は、ゲームＡ（第１ゲーム）と、ゲームＡと異なるゲームＢ（第２ゲーム）との間の仕様の関連度に関する情報を取得する機能を備える。
取得手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、ユーザに対して説明情報を提供する場合（本実施形態の例では、ユーザがゲームを初めて実行したことを判別した場合）、通信インタフェース部２５を介して、統括サーバ４０に対し関連度データ（仕様の関連度に関する情報）の送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から関連度データを取得すると、関連度データをＲＡＭ２３、あるいはデータベースサーバ３０ａ内のゲームデータベース３２に記憶する。

また、ゲームＢが、ユーザが実行経験を有するゲームである場合に、取得手段５４は、ゲームＡ（第１ゲーム）と、ゲームＢ（第２ゲーム）との間の仕様の関連度に関する情報を取得してもよい。
この場合、ユーザには、ゲームＡ、当該ユーザが実行経験を有するゲームＢとの間の仕様の関連度に関する情報に応じて、ゲームＢに関する関連ゲーム情報（第２情報）が提供される。ここで、ユーザは、ゲームＢの実行経験を有することにより、ゲームＢの仕様を理解していると考えられる。このため、ユーザは、ゲームＡの仕様についての説明情報が提供される際に、ゲームＢの仕様に基づいてゲームＡの仕様の理解度を高めることができる。
この場合における取得手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、ユーザに対して説明情報を提供する場合、通信インタフェース部２５を介して、統括サーバ４０に対し実行状況管理データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、ユーザがゲームＢの実行経験を有するか否かを判別する。例えば、ＣＰＵ２１は、当該ユーザのユーザＩＤに対応するゲームＢの実行状況の項目にＮＵＬＬデータが記録されていない場合に、当該ユーザがゲームＢの実行経験を有すると判別してもよい。
そして、ＣＰＵ２１は、ユーザがゲームＢの実行経験を有すると判別すると、通信インタフェース部２５を介して、統括サーバ４０に対し関連度データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から関連度データを受信すると、関連度データをＲＡＭ２３、あるいはデータベースサーバ３０ａ内のゲームデータベース３２に記憶する。

第２情報提供手段５５は、関連度に関する情報に応じて、ユーザに対するゲームＡの説明情報（第１情報）の提供の際に、ゲームＢ（第２ゲーム）に関する関連ゲーム情報（第２情報）を前記ユーザに提供する機能を備える。
第２情報提供手段５５の機能は、例えば以下のようにして実現される。
ゲームサーバ２０ａのＣＰＵ２１は、関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上であるか否かを判別する。そして、ＣＰＵ２１は、仕様の関連度が所定の閾値以上であると判別した場合に、関連ゲーム情報を生成する。ここで、関連ゲーム情報は、ゲームＡとゲームＢの間で仕様が関連又は共通する処理を対応付けるように生成されてもよく、例えば『「クエスト」の進め方は、ゲームＢの「スカウト」と同じです。』などのメッセージが含まれるように生成されてもよい。また、関連ゲーム情報は予め生成された状態でデータベースサーバ３０ａ内のゲームデータベース３２に記憶されていてもよく、ＣＰＵ２１は、仕様の関連度が所定の閾値以上であると判別した場合に、ゲームデータベース３２から関連ゲーム情報を取得してもよい。
また、ＣＰＵ２１は、関連ゲーム情報を生成すると、第１情報提供手段５３の機能により表示されるウェブページの表示領域１０２内に関連ゲーム情報を含むようにＨＴＭＬデータを生成する。
なお、本実施形態では、関連ゲーム情報がテキストデータで構成された場合を一例として説明したが、関連ゲーム情報は、例えば、画像データや音声データなどで構成されてもよい。

（８）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１９のフローチャートを参照して説明する。図１９のフローチャートは、ゲームＡにおいて、ゲームＡの仕様を説明するためのチュートリアルが行われる場合の処理の一例を示すフローチャートである。なお、ここでは、ユーザがゲームＡに登録した後に初めてゲームＡを実行するときに、ゲームＡのチュートリアルが行われる場合を一例として説明する。

先ず、図１２に示すトップページ上でユーザがメニューｍ１〜ｍ３の何れかの選択操作を行うと（ステップＳ１００：ＹＥＳ）、ゲームサーバ２０ａのＣＰＵ２１は、選択操作を行ったユーザがゲームＡを初めて実行したか否かを判別する（ステップＳ１１０）。この判別処理の一例を説明すると、ＣＰＵ２１は、データベースサーバ３０ａ内のゲームデータベース３２にアクセスして、選択操作を行ったユーザによるゲームＡの実行結果が記憶されていない場合には、当該ユーザがゲームＡを初めて実行したと判別してもよい。

ＣＰＵ２１は、選択操作を行ったユーザがゲームＡを初めて実行したことを判別すると（ステップＳ１１０：ＹＥＳ）、通信インタフェース部２５を介して、統括サーバ４０に対し実行状況管理データの送信を要求する。そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、ユーザが実行経験を有する他のゲームを抽出する（ステップＳ１２０）。例えば、ＣＰＵ２１は、当該ユーザのユーザＩＤに対応するゲームＢの実行状況の項目にＮＵＬＬデータが記録されていない場合に、当該ユーザがゲームＢの実行経験を有すると判別し、ゲームＢを抽出してもよい。
そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０に対し関連度データの送信を要求する。次に、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から関連度データを取得すると、関連度データをＲＡＭ２３、あるいはデータベースサーバ３０ａ内のゲームデータベース３２に記憶する（ステップＳ１３０）。

次に、ＣＰＵ２１は、仕様データから各処理（本実施形態の例では、クエスト処理、合成処理、バトル処理）の説明情報を抽出する（ステップＳ１４０）。そして、ＣＰＵ２１は、関連度データを参照して、ゲームＡと他のゲーム（ここでは、ゲームＢとする。）との間の仕様の関連度に応じて、ゲームＢに関する関連ゲーム情報を生成する。具体的に説明すると、ＣＰＵ２１は、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上であるか否かを判別し（ステップＳ１５０）、関連度が所定の閾値以上であると判別した場合に（ステップＳ１５０：ＹＥＳ）、ゲームＢに関する関連ゲーム情報を生成する（ステップＳ１６０）。ここで、関連ゲーム情報は、ゲームＡとゲームＢの間で仕様が関連する処理を対応付けるように生成されてもよく、例えば『「クエスト」の進め方は、ゲームＢの「スカウト」と同じです。』などのメッセージが含まれるように生成されてもよい。
なお、ＣＰＵ２１は、関連度が所定の閾値未満であると判別すると（ステップＳ１５０：ＮＯ）、ステップＳ１６０の処理を行わずに（つまり、関連ゲーム情報を生成せずに）、ステップＳ１７０の処理に移行する。

そして、ＣＰＵ２１は、クエスト処理について、ステップＳ１４０で抽出したクエスト処理の説明情報と、ステップＳ１６０で生成した関連ゲーム情報とを含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する（ステップＳ１７０）。この場合、図１６のステップＳ１に示すウェブページがユーザの通信端末１０上に表示される。なお、関連度が所定の閾値未満である場合には（ステップＳ１５０：ＮＯ）、関連ゲーム情報を含まない（つまり、表示領域１０２が設けられていない）ウェブページがユーザの通信端末１０上に表示される。また、ＣＰＵ２１は、メニューｍ１１が選択操作されると（ステップＳ１８０：ＹＥＳ）、全ての処理について説明情報が提供されたか否かを判別する（ステップＳ１９０）。ここでは、各処理のうちクエスト処理についての説明情報しか提供されていないので、ＣＰＵ２１は、全ての処理の説明情報を提供していないと判別し、ステップＳ１７０の処理に移行する。
ＣＰＵ２１は、ステップＳ１７０の処理に移行すると、合成処理について、ステップＳ１４０で抽出した合成処理の説明情報と、ステップＳ１６０で生成した関連ゲーム情報とを含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。この場合、図１６のステップＳ２に示すウェブページがユーザの通信端末１０上に表示される。なお、関連度が所定の閾値未満である場合には（ステップＳ１５０：ＮＯ）、関連ゲーム情報を含まない（つまり、表示領域１０２が設けられていない）ウェブページがユーザの通信端末１０上に表示される。また、ＣＰＵ２１は、メニューｍ１１が選択操作されると（ステップＳ１８０：ＹＥＳ）、全ての処理について説明情報が提供されたか否かを判別する（ステップＳ１９０）。ここでは、各処理のうちバトル処理についての説明情報が提供されていないので、ＣＰＵ２１は、全ての処理の説明情報を提供していないと判別し、ステップＳ１７０の処理に移行する。
ＣＰＵ２１は、ステップＳ１７０の処理に再度移行すると、バトル処理について、ステップＳ１４０で抽出したバトル処理の説明情報と、ステップＳ１６０で生成した関連ゲーム情報とを含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。この場合、図１７のステップＳ３に示すウェブページがユーザの通信端末１０上に表示される。なお、関連度が所定の閾値未満である場合には（ステップＳ１５０：ＮＯ）、関連ゲーム情報を含まない（つまり、表示領域１０２が設けられていない）ウェブページがユーザの通信端末１０上に表示される。また、ＣＰＵ２１は、メニューｍ１１が選択操作されると（ステップＳ１８０：ＹＥＳ）、全ての処理について説明情報が提供されたか否かを判別する（ステップＳ１９０）。ここで、ＣＰＵ２１は、全ての処理の説明情報を提供した判別する（ステップＳ１９０：ＹＥＳ）。
次に、ＣＰＵ２１は、全ての処理の説明情報を提供した判別すると、ステップＳ１００で選択操作されたメニューに対応する処理の実行を開始する。なお、ＣＰＵ２１は、ステップＳ１１０においてユーザがゲームＡの実行経験を有すると判別した場合（ステップＳ１１０：ＮＯ）、ステップＳ１００で選択操作されたメニューに対応する処理の実行を開始する。

なお、上述したフローのステップＳ１２０では、ユーザが実行経験を有する他のゲーム（ゲームＢ）に関する情報を取得した後に、他のゲームとゲームＡとの仕様の関連度に応じて関連ゲーム情報を提供する場合を一例として説明したが、処理内容はこの場合に限られず、上記フローと異なっていてもよい。先ず、上記フローと異なる処理内容の第１の例について説明する。例えば、ゲームＡとの仕様の関連度の高い他のゲームを関連度データから抽出し、ユーザが当該他のゲームの実行経験を有する場合に、当該他のゲームに関する関連ゲーム情報を生成して、当該関連ゲーム情報を提供するようにしてもよい。次に、上記フローと異なる処理内容の第２の例について説明する。例えば、上記フローのステップＳ１２０の処理を行わなくてもよい。つまり、ユーザによる他のゲームの実行経験の有無にかかわらず、関連度データを取得するようにしてもよい。

上述したように、実施形態のゲーム制御装置によれば、ゲームＡを実行するユーザに対してゲームＡの仕様を説明するための説明情報が提供される際に、当該ユーザには、ゲームＡとゲームＢとの間の仕様の関連度に関する情報に応じて、ゲームＢに関する関連ゲーム情報が提供される。この場合、ユーザは、例えば操作手順などの仕様がゲームＡと関連又は共通するゲームＢについての情報を得ることができる。このため、例えば、ユーザがゲームＢの仕様を理解していた場合には、ユーザは、説明情報が提供される際に、ゲームＢの仕様に基づいてゲームＡの仕様を想定することが可能となる。これにより、ユーザは、実行対象のゲームＡの仕様を容易に理解することができる。
また、例えば、ユーザがゲームＢの仕様を理解していない場合であっても、ユーザは、ゲームＡと仕様が関連するゲームＢについての情報を得ることができる。この場合、ユーザは、説明情報に基づきゲームＡの仕様を理解することでゲームＢの仕様も理解し得るので、当該ユーザのゲームＢに対する興味を喚起することができる。これにより、ユーザに対してゲームＢを実行するように動機付けることができるので、ゲームＢのユーザ数を増やすことができ、ひいてはゲームコミュニティを活性化させることができる。

（９）変形例
上述した実施形態では、ゲームＡにおけるチュートリアルにおいてゲームＢに関する関連ゲーム情報を提供する場合を例として説明したが、これに限られない。例えば、ゲームＢにおけるチュートリアルにおいてゲームＡに関する関連ゲーム情報が提供されてもよい。

また、上述した実施形態では、ゲーム制御装置を情報処理装置の一例として説明したが、これに限られない。例えば、ユーザがソフトウェアＣを利用する場合に、ソフトウェアＣにおけるチュートリアルにおいて、ソフトウェアＣとソフトウェアＤとの間の仕様の関連度に応じて、ソフトウェアＤに関する情報（例えば、「ソフトウェアＣの処理Ｅの操作手順は、ソフトウェアＤの処理Ｆの操作手順と同じです。」など）が提供されるように構成されてもよい。ここで、ソフトウェアの仕様についての説明情報には、例えば、当該ソフトウェアの利用手順や操作手順などに関する情報や、ソフトウェアの構成（例えば、対応する周辺機器、ユーザインタフェースなど）、機能、性能、アルゴリズムなどが含まれてもよい。
以下、上述した実施形態の変形例について説明する。

（９−１）変形例１
上記実施形態において、第２情報提供手段５５は、関連度に関する情報と、ユーザによるゲームＢ（第２ゲーム）の実行状況とに応じて、関連ゲーム情報（第２情報）を前記ユーザに提供してもよい。
ここで、「ゲームＢの実行状況」とは、例えば、ユーザが、ゲームＢ上で制覇（クリア）したパートの数であってもよいし、ユーザが、ゲームＢ上の対戦において他のユーザあるいはキャラクタに勝利した数であってもよい。また、「ゲームＢの実行状況」とは、例えば、ユーザがゲームＢ上で獲得した特定のアイテムの数であってもよいし、ゲームＢの進行度や技能レベルの高さなどであってもよい。
例えば、ゲームＡとゲームＢとの仕様の関連度が高く、且つ、ユーザによるゲームＢの実行状況がある程度進んでいる場合、当該ユーザに対してゲームＡの仕様の説明情報が提供される際に、当該ユーザは、ゲームＢについての情報を得ることができる。この場合、ユーザは、実行状況がある程度進んでいることによりゲームＢの仕様の理解度が高いと考えられる。このため、ユーザは、仕様の理解度の高いゲームＢに基づいて、ゲームＡの仕様の理解度をさらに高めることができる。

本変形例における第２情報提供手段５５の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１９のフローのステップＳ１２０の処理において、通信インタフェース部２５を介して、統括サーバ４０に対し実行状況管理データの送信を要求する。
そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、当該ユーザによるゲームＢの実行状況が所定の条件を満たすか否かを判別する。ここで、所定の条件とは、例えば、ゲームＢ上で制覇（クリア）したパートが所定数以上であることとしてもよいし、ユーザが、ゲームＢ上の対戦において他のユーザあるいはキャラクタに勝利した数が所定数以上であることとしてもよい。また、所定の条件とは、例えば、ユーザがゲームＢ上で獲得した特定のアイテムの数が所定数以上であることとしてもよいし、ゲームＢの進行度や技能レベルの高さなどが所定の閾値以上であることとしてもよい。
ＣＰＵ２１は、ユーザによるゲームＢの実行状況が所定の条件を満たし、且つ、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上である場合に、ゲームＢに関する関連ゲーム情報を生成すればよい。

（９−２）変形例２
上記変形例１において、ゲームＢ（第２ゲーム）の実行状況は、ユーザによるゲームＢの実行回数を含み、第２情報提供手段５５は、関連度に関する情報と、前記ユーザによるゲームＢの実行回数とに応じて、関連ゲーム情報（第２情報）を前記ユーザに提供してもよい。
例えば、ユーザによるゲームＢの実行回数が多いほど、ゲームＢの仕様に対する当該ユーザの理解度が高いと考えられる。このため、ユーザに対してゲームＡの仕様の説明情報が提供される際に、ゲームＡと仕様が関連し、且つ、当該ユーザによる仕様の理解度の高いゲームＢについての情報が当該ユーザに提供されることにより、当該ユーザは、ゲームＢの仕様に基づいて、ゲームＡの仕様の理解度をさらに向上させることができる。

本変形例における第２情報提供手段５５の機能を実現するに当たり、実行状況管理データには、ユーザＩＤごとに、複数のゲーム（ゲームＡ、ゲームＢ、…）それぞれの処理の実行回数が記録されてもよい。例えば、ゲームＡのクエスト処理の実行回数は、図１３に示すウェブページにおけるメニューｍ１０の選択回数を計数することによりもとめられてもよいし、ゲームＢのスカウト処理の実行回数は、図１５に示すウェブページにおけるメニューｍ２４の選択回数を計数することによりもとめられてもよい。
ゲームサーバ２０ａのＣＰＵ２１は、上記変形例１と同様に、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得する。そして、ＣＰＵ２１は、実行状況管理データを参照して、当該ユーザによるゲームＢの実行回数が所定回数以上であるか否かを判別する。ここで、ゲームＢの実行回数は、例えば、ゲームＢに含まれる複数の処理（スカウト処理、強化処理、試合処理）の実行回数の合計であってもよいし、当該複数の処理のうち少なくとも一つの処理の実行回数の合計であってもよい。
ＣＰＵ２１は、ユーザによるゲームＢの実行回数が所定回数以上であり、且つ、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上である場合に、ゲームＢに関する関連ゲーム情報を生成すればよい。

（９−３）変形例３
上記変形例１または変形例２において、ゲームＢ（第２ゲーム）の実行状況は、ユーザによるゲームＢの最新の実行時期からの経過時間を含み、第２情報提供手段５５は、関連度に関する情報と、前記ユーザによるゲームＢ（第２ゲーム）の最新の実行時期からの経過時間とに応じて、関連ゲーム情報（第２情報）を前記ユーザに提供してもよい。
例えば、ユーザによるゲームＢの最新の実行時期からの経過時間が短いほど、当該ユーザはゲームＢの仕様の記憶の程度が高いと考えられる。このため、ユーザに対してゲームＡの仕様の説明情報が提供される際に、ゲームＡと仕様が関連し、且つ、当該ユーザによる仕様の記憶の程度の高いゲームＢについての情報が当該ユーザに提供されることにより、当該ユーザは、ゲームＢの仕様に基づいて、ゲームＡの仕様の理解度をさらに向上させることができる。

本変形例における第２情報提供手段５５の機能を実現するに当たり、実行状況管理データには、ユーザＩＤごとに、複数のゲーム（ゲームＡ、ゲームＢ、…）それぞれの処理の最新の実行時期が記録されてもよい。例えば、ゲームＡのクエスト処理の最新の実行時期は、図１３に示すウェブページにおけるメニューｍ１０の最新の選択日時であってもよいし、ゲームＢのスカウト処理の最新の実行時期は、図１５に示すウェブページにおけるメニューｍ２４の最新の選択日時であってもよい。
ゲームサーバ２０ａのＣＰＵ２１は、上記変形例１と同様に、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得する。そして、ＣＰＵ２１は、実行状況管理データを参照して、当該ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間（例えば７２時間）以下であるか否かを判別する。ここで、ゲームＢの最新の実行時期からの経過時間は、例えば、ゲームＢに含まれる複数の処理（スカウト処理、強化処理、試合処理）の実行時期のうち最新の実行時期からの経過時間であってもよい。
ＣＰＵ２１は、ユーザによるゲームＢの最新の実行時期からの経過時間が所定時間以下であり、且つ、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上である場合に、ゲームＢに関する関連ゲーム情報を生成すればよい。

（９−４）変形例４
上記実施形態のゲーム制御装置の変形例４の機能ブロック図を図２０に示す。図２０に示すように、この機能ブロック図は、図１８に示したものとは制限手段５６が追加された点で異なる。制限手段５６は、関連度に関する情報に応じて、ユーザに対する説明情報（第１情報）の情報量を制限する機能を備える。
例えば、ユーザがゲームＢの仕様を理解していた場合には、ユーザは、関連ゲーム情報が提供されることにより、ゲームＢの仕様に基づいてゲームＡの仕様を想定することが可能となる。この場合、ユーザにとっては、ゲームＡの仕様についての説明情報が不要であり、逆に説明情報が提供されることによって煩わしさを感じることが考えられる。
このゲーム制御装置によれば、関連度に関する情報に応じて、説明情報の情報量を制限することができるので、ユーザは、煩わしさを感じることなく、ゲームＢの仕様に基づいてゲームＡの仕様を容易に理解することができる。

制限手段５６の機能は、例えば以下のようにして実現できる。ゲームサーバ２０ａのＣＰＵ２１は、図１９のフローのステップＳ１７０の処理において、先ず、ゲームＡとゲームＢの仕様の関連度に応じて説明情報の情報量を制限する。具体的には、ＣＰＵ２１は、例えば、ゲームＡとゲームＢの仕様の関連度が高い（実施形態の例では、仕様が関連又は共通する処理の数が多い）ほど、説明情報の情報量を制限してもよい。より詳細には、例えば、ゲームＡとゲームＢとの間で仕様が関連する処理の数が２つの場合には、仕様が関連する処理の数が１つの場合と比較して、説明情報の情報量が制限されるようにしてもよい。さらに、仕様が関連する処理の数が３つの場合には、仕様が関連する処理の数が２つの場合と比較して、説明情報の情報量がさらに制限されるようにしてもよい。例えば、ＣＰＵ２１は、ゲームＡとゲームＢとの間で仕様が関連する処理ごとに、当該処理の説明情報の情報量を制限してもよい。これにより、仕様が関連する処理の数が多いほど、ゲームＡ全体の説明情報の情報量を制限することができる。
また、１つの処理の説明情報のうち制限される情報の量は、ゲームＡとゲームＢとの間の仕様の関連度が高いほど、多くなるように構成されてもよい。
なお、説明情報の情報量を制限するとは、伝達される説明情報の情報量を小さくする（説明情報を簡略化する）ことであってもよく、例えば、説明情報がテキストデータで構成されている場合には、テキストの長さを短くすることであってもよいし、説明情報がテキストデータと音声データ又は画像データとの組み合わせによって構成されている場合には、音声データ又は画像データを省略することであってもよい。
ＣＰＵ２１は、説明情報の情報量を制限すると、情報量が制限された説明情報と、関連ゲーム情報とを含むウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。この場合、通信端末１０上に表示されるウェブページの例を、図２１（ａ），（ｂ）にそれぞれ示す。図２１（ａ）に例示したウェブページでは、クエスト処理に対応する説明情報の情報量が制限されることにより、表示領域１０１に表示されるメッセージは、図１６のステップＳ１のウェブページと比較して簡略化される（ここでは、メッセージの長さが短くなる）。また、例えば、説明情報の情報量がゼロになるように制限された場合には、図２１（ｂ）に示すように、説明情報をウェブページに含まなくてもよい。

（９−５）変形例５
上記実施形態のゲーム制御装置の変形例５の機能ブロック図を図２２に示す。図２２に示すように、この機能ブロック図は、図２０に示したものとは受付手段５７が追加された点で異なる。受付手段５７は、関連度に関する情報に応じて、ユーザに対して説明情報（第１情報）を提供するか否かの選択を受け付ける機能を備える。
また、本変形例において、制限手段５６は、ユーザに対して説明情報を提供しないように選択された場合に、前記ユーザに対する説明情報の情報量を制限する機能を備える。
この場合、例えばユーザがゲームＢの仕様を理解していた場合であっても、ユーザは、ゲームＡの仕様についての説明情報の提供を受けるか否かを自ら選択することができる仕組みとすることができる。

本変形例における受付手段５７の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、例えば、図１９のフローのステップＳ１３０の処理において関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＢの仕様の関連度が所定の閾値（例えば０．５）以上であるか否かを判別する（ステップＳ１５０）。そして、ＣＰＵ２１は、関連度が所定の閾値以上であると判別した場合に（ステップＳ１５０：ＹＥＳ）、図２３に例示するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０宛に送信する。図２３に例示したウェブページには、ゲームＡの仕様を説明するためのチュートリアルを省略するか否かの選択を促すためのメッセージと、「省略する」と表記されたメニューｍ１２と、「省略しない」と表記されたメニューｍ１３などが含まれる。なお、図２３のウェブページには、例えば「ゲームＡの進め方はゲームＢと同じです。」などのように、ゲームＡとゲームＢの仕様が関連していることを通知するためのメッセージなどが含まれてもよい。
ここで、ユーザがメニューｍ１２を選択操作した場合には、本変形例の制限手段５６では、ＣＰＵ２１は、例えばチュートリアルを終了して、ステップＳ１００で選択操作されたメニューに対応する処理の実行を開始してもよい。
一方、ユーザがメニューｍ１３を選択操作した場合には、ＣＰＵ２１は、ステップＳ１３０の処理に移行してもよい。

（９−６）変形例６
上記実施形態において、第２情報提供手段５５は、ゲームＡ（第１ゲーム）と異なる他のゲーム（第２ゲーム）が複数存在する場合に、複数の他のゲームのうちゲームＡの仕様との関連度が所定の条件を満たすゲームについての関連ゲーム情報（第２情報）を、ユーザに提供してもよい。
例えば、ユーザが複数の他のゲームの仕様を理解していた場合には、複数の他のゲームのうちゲームＡの仕様との関連度が高い（所定の条件を満たす）ゲームについての関連ゲーム情報が提供されることにより、ユーザは、複数の他のゲームの中からゲームＡの仕様との関連度が高い他のゲームを絞り込むことができる。これにより、ユーザは、絞り込まれた他のゲームの仕様に基づいてゲームＡの仕様を早期に想定することができる。

本変形例における第２情報提供手段５５の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１９のフローのステップＳ１３０の処理において関連度データを取得すると、関連度データを参照して、ゲームＡとゲームＡ以外の他のゲームの仕様の関連度が所定の条件を満たすか否かを判別する。ここで、所定の条件とは、例えば、ゲームＡとの間の仕様の関連度が所定の閾値（例えば０．５）以上であることとしてもよいし、ゲームＡとの間の仕様の関連度が大きい順に所定番目位内であることとしてもよい。
そして、ＣＰＵ２１は、ゲームＡとの間の仕様の関連度が所定の条件を満たす他のゲームを抽出する。また、ＣＰＵ２１は、抽出した他のゲームについての関連ゲーム情報を生成する。なお、ゲームＡとの間の仕様の関連度が所定の条件を満たす他のゲームが複数存在する場合には、それぞれの他のゲームに関する関連ゲーム情報を生成して、ユーザに提供してもよい。

（９−７）変形例７
上記実施形態において、第２情報提供手段５５は、ゲームＡ（第１ゲーム）と異なる他のゲーム（第２ゲーム）が複数存在する場合に、複数の他のゲームのうち、ユーザによる実行状況が所定の条件を満たすゲームについての関連ゲーム情報（第２情報）を、前記ユーザに提供してもよい。
例えば、ユーザに対して、複数の他のゲームのうちユーザによる実行状況がある程度進んだ（所定の条件を満たす）ゲームについての関連ゲーム情報が提供されることにより、ユーザは、複数の他のゲームの中から、仕様を理解しているゲームを絞り込むことができる。これにより、ユーザは、仕様を理解している他のゲームの仕様に基づいてゲームＡの仕様を早期に想定することができる。

本変形例における第２情報提供手段５５の機能は、例えば以下のようにして実現される。ゲームサーバ２０ａのＣＰＵ２１は、図１９のフローのステップＳ１２０の処理において、通信インタフェース部２５を介して、統括サーバ４０に対し実行状況管理データの送信を要求する。
そして、ＣＰＵ２１は、通信インタフェース部２５を介して、統括サーバ４０から実行状況管理データを取得すると、実行状況管理データを参照して、当該ユーザによるゲームＡ以外の他のゲームの実行状況が所定の条件を満たすか否かを判別する。ここで、所定の条件とは、例えば、ゲーム上で制覇（クリア）したパートが所定数以上であることとしてもよいし、ユーザが、ゲーム上の対戦において他のユーザあるいはキャラクタに勝利した数が所定数以上であることとしてもよい。また、所定の条件とは、例えば、ユーザがゲーム上で獲得した特定のアイテムの数が所定数以上であることとしてもよいし、ゲームの進行度や技能レベルの高さなどが所定の閾値以上であることとしてもよい。
ＣＰＵ２１は、ユーザによる他のゲームの実行状況が所定の条件を満たし、且つ、当該他のゲームとゲームＡの仕様の関連度が所定の閾値（例えば０．５）以上である場合に、当該他のゲームに関する関連ゲーム情報を生成すればよい。なお、実行状況が所定の条件を満たし、且つ、ゲームＡとの間の仕様の関連度が前記閾値以上の他のゲームが複数存在する場合には、それぞれの他のゲームに関する関連ゲーム情報を生成して、ユーザに提供してもよい。

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

例えば、上述した実施形態では、実行対象のゲームがデジタルカードゲームである場合の例について説明したが、これに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいて、ゲームを実行するユーザに対して、当該ゲームの仕様を説明するための情報が提供されるように構成されている場合には、上記実施形態の構成を好適に適用することができる。

上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインコミュニケーションシステムにおいても、上述した実施形態と同様に、ユーザによるゲームの進行を制御できることは言うまでもない。
また、例えば、家庭用ゲーム機がオフライン状態の場合であっても、上述した実施形態と同様に、ユーザによるゲームの進行を制御することができる。この場合における一つの具体例を説明すると、例えば、ゲームＸのソフトウェア、及びゲームＸとゲームＹとの間の仕様の関連度に関する情報が記憶された記憶媒体（例えば半導体メモリや光ディスクなど）と、家庭用ゲーム機とを用いて、ユーザがゲームＸを実行する場合、家庭用ゲーム装置は、例えば、ゲームＸのソフトウェアの実行に基づいて、当該家庭用ゲーム機に設けられた記憶装置を参照して、ゲームＹの実行履歴が存在するか否かを判別するように動作してもよい。そして、ゲームＹの実行履歴が存在する場合には、ゲームＸとゲームＹとの間の仕様の関連度に関する情報に応じて、ゲームＸのチュートリアルにおいて、ゲームＹに関する情報が提供されてもよい。このように、家庭用ゲーム機がオフライン状態の場合であっても、上記実施形態と同様の制御を行うことが可能である。

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

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

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

Claims (15)

1. 第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段と、
   前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段と、
   前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段と、
   を備えた、ゲーム制御装置。
2. 前記第２ゲームは、前記ユーザが実行経験を有するゲームであることを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記第２情報提供手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行状況とに応じて、前記第２情報を前記ユーザに提供することを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの実行回数を含み、
   前記第２情報提供手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの実行回数とに応じて、前記第２情報を前記ユーザに提供することを特徴とする、
   請求項３に記載されたゲーム制御装置。
5. 前記第２ゲームの実行状況は、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間を含み、
   前記第２情報提供手段は、前記関連度に関する情報と、前記ユーザによる前記第２ゲームの最新の実行時期からの経過時間とに応じて、前記第２情報を前記ユーザに提供することを特徴とする、
   請求項３または４に記載されたゲーム制御装置。
6. 前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の情報量を制限する制限手段を備えたことを特徴とする、
   請求項１、３〜５のいずれかに記載されたゲーム制御装置。
7. 前記関連度に関する情報に応じて、前記ユーザに対して前記第１情報を提供するか否かの選択を受け付ける受付手段を備え、
   前記制限手段は、前記ユーザに対して前記第１情報を提供しないように選択された場合に、前記ユーザに対する前記第１情報の情報量を制限することを特徴とする、
   請求項６に記載されたゲーム制御装置。
8. 前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記第１ゲームの仕様との関連度が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供することを特徴とする、
   請求項１〜７のいずれかに記載されたゲーム制御装置。
9. 前記第２情報提供手段は、前記第２ゲームが複数存在する場合に、複数の第２ゲームのうち前記ユーザによる実行状況が所定の条件を満たすゲームについての前記第２情報を、前記ユーザに提供することを特徴とする、
   請求項１〜８のいずれかに記載されたゲーム制御装置。
10. コンピュータに、
    第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する機能、
    前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を記憶する記憶装置から前記関連度に関する情報を取得する機能、及び
    前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する機能、
    を実現させるためのプログラム。
11. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    第１ゲームを実行するユーザに対して、前記第１ゲームの仕様を説明するための第１情報を提供する第１情報提供手段、
    前記第１ゲームと、前記第１ゲームと異なる第２ゲームとの間の仕様の関連度に関する情報を取得する取得手段、
    前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    ゲームシステム。
12. 第１ソフトウェアを利用するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する第１情報提供手段と、
    前記第１ソフトウェアと、前記第１ソフトウェアと異なる第２ソフトウェアとの間の仕様の関連度に関する情報を取得する取得手段と、
    前記関連度に関する情報に応じて、前記ユーザに対する前記第１情報の提供の際に、前記第２ソフトウェアに関する第２情報を前記ユーザに提供する第２情報提供手段と、
    を備えた、情報処理装置。
13. 第１ソフトウェアを実行するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する第１情報提供手段と、
    前記第１ソフトウェアと、前記第１ソフトウェアと異なる第２ソフトウェアとの間の仕様の関連を示す情報が用いられることにより、前記ユーザに対する前記第１情報の提供の際に、前記第２ゲームに関する第２情報を前記ユーザに提供する第２情報提供手段と、
    を備えた、情報処理装置。
14. 通信端末と、当該通信端末からアクセスされるサーバとを含む情報処理システムであって、
    第１ソフトウェアを実行するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する第１情報提供手段、
    前記第１ソフトウェアと、前記第１ソフトウェアと異なる第２ソフトウェアとの間の仕様の関連を示す情報が用いられることにより、前記ユーザに対する前記第１情報の提供の際に、前記第２ソフトウェアに関する第２情報を前記ユーザに提供する第２情報提供手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    情報処理システム。
15. コンピュータに、
    第１ソフトウェアを実行するユーザに対して、前記第１ソフトウェアの仕様を説明するための第１情報を提供する機能、
    記憶装置に記憶された、前記第１ソフトウェアと、前記第１ソフトウェアと異なる第２ソフトウェアとの間の仕様の関連を示す情報が用いられることにより、前記ユーザに対する前記第１情報の提供の際に、前記第２ソフトウェアに関する第２情報を前記ユーザに提供する機能、
    を実現させるためのプログラム。

Images