WO2013099335A1

WO2013099335A1 - ゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラム及び記録媒体

Info

Publication number: WO2013099335A1
Application number: PCT/JP2012/068399
Authority: WO
Inventors: 正能鈴木; 暢也北村; 浩之冨田
Original assignee: 株式会社コナミデジタルエンタテインメント
Priority date: 2011-12-28
Filing date: 2012-07-19
Publication date: 2013-07-04
Also published as: JP2013138728A; JP5124682B1

Abstract

　ゲーム管理装置は、各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置であって、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段とを備えている。

Description

ゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラム及び記録媒体

　本出願は、２０１１月１２月２８日提出の日本国特許出願第２０１１－２８９９９０号を基礎として優先権を主張するものであり、その記載内容の全てを、ここに援用する。

　本発明は、各ユーザのゲーム情報を管理するゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラム及び記録媒体に関するものである。

　従来から、インターネット上に設置されたゲームサーバに、ユーザの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、ユーザがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある。

　また、インターネットを介して共通のゲームをプレイするユーザ同士が、仲間関係を構築することができるゲームシステムも提案されている（特許文献１参照）。

　そして近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）のシステムに、前記ゲームシステムが組み込まれ、ＳＮＳのサービスの一つとして提供される、いわゆるソーシャルゲームが普及している。このようなソーシャルゲームにおいては、各ユーザがゲームサービスを利用している他のユーザと仲間になり、仲間のユーザとコミュニケーションをとったり、協力して対戦したりすることで、ユーザ同士が交流を行うことができるようになっている。そして、各ユーザは、複数の他のユーザと仲間になって、これらの仲間と交流を持ちながらゲームを楽しむことができるようになっている。

　従来のゲーム、特にソーシャルゲームにおいては、比較的高いレベルのユーザは、自分と同レベルまたは自分より高いレベルの他のユーザと仲間になることを希望する傾向にある。但し、ユーザは、自分よりも低いレベルの他のユーザから仲間申請を受けた場合に、無碍にその申請を断りづらいこともあり、その申請を承認して仲間になるケースがある。しかし、高いレベルのユーザにとって、自分よりも低いレベルの仲間が多くなると、ゲームにおける協力対戦等について不公平感が生じてしまうこともある。その理由は、高いレベルのユーザにとっては、他のユーザに対して協力対戦等における貢献度が大きいのに対して、同様の貢献を低いレベルのユーザからは受けられないためである。

　具体的には、ソーシャルゲームにおいては、ユーザが他のユーザと対戦する場合に、自分の仲間に協力を求めることができる（協力対戦と呼称されることがある）。そして協力を求める対象の仲間のレベルが高いほど、対戦が有利になるのである。逆に、仲間のレベルが低いと、有利になる度合いも低いものとなる。従って、概ね、レベルの高いユーザは、レベルの低いユーザから協力を求められることが多くなり、他のユーザに貢献するケースが多くなる一方で、仲間内に自分よりレベルの高いユーザがいない場合には、同様のメリットを自分は享受できないという不満が生じることになる。

　高いレベルのユーザは、さらに高いレベルのユーザを仲間とすればよいのであるが、各ユーザが他のユーザと仲間関係を構築することができる人数に上限が設定されている場合がある。この場合、上限（例えば５０人）に達した仲間が既に存在するユーザにとっては、新たな仲間申請を行うことはできない。特に高いレベルのユーザは既に長期間、ゲームを継続していることが多く、仲間数が上限に達している場合が多い。

　なお、現状の仲間関係を解消すれば、その分、上限まで余裕ができるので、その場合は新たな仲間申請を行うことができる。しかし、そのためには、ユーザが今まで仲間であった相手との関係を切る操作を行う必要があり、心理的な抵抗がある上に、この操作を行った場合には、ペナルティ的に保有ポイントの削減というシステムが設けられている場合もあり、実際には行い難い。

　したがって、仲間数が上限まで達したユーザは、実質的には仲間が固定された状態にあり、新たな仲間との交流が生まれることがなく、また自分の希望する仲間のグループ構成にすることもできないという状況にある。このような状況が継続すると、ユーザはゲーム自体にマンネリ感を持ち、ゲームへの積極的な関与が失われる可能性もある。

特開２００３－４７７７８号公報

　本発明は、上記の問題に鑑みてなされたものであり、その目的は、仲間数の上限が設定されているゲームにおいても、他のユーザと新たな仲間関係を構築し易くして、マンネリ感が発生しにくいゲーム環境をユーザに提供することができるゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラム及び記録媒体を実現することである。

　本発明の一局面に係るゲーム管理装置は、各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置であって、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段と、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段と、を備える構成である。

　本発明の他の一局面に係るゲームシステムは、ゲームサービスを受ける各ユーザの端末装置と、前記端末装置と通信し各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置と、を含むゲームシステムであって、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段の各手段を、前記ゲーム管理装置又は前記端末装置のいずれか一方が備えている。

　本発明のさらに他の局面に係るゲーム管理方法は、各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、前記ゲーム管理装置が、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理ステップと、前記ゲーム管理装置が、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定ステップと、前記ゲーム管理装置が、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除ステップと、を含んでいる。

　本発明のさらに他の局面に係るプログラムは、コンピュータを、各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段、として機能させるためのプログラムである。

　本発明によれば、仲間数の上限が設定されているゲームにおいても他のユーザと新たな仲間関係を構築し易くし、マンネリ感が発生しにくいゲーム環境をユーザに提供できる。

　なお、本発明のゲーム管理装置及びゲームシステムは、コンピュータによって実現してもよく、この場合には、コンピュータを上記各手段として動作させることにより、上記ゲーム装置をコンピュータにて実現させるプログラム及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。

　本発明の目的、特徴及び利点は、以下の詳細な説明と添付図面とによって、より明白となる。

本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。ゲーム管理装置のハード構成の一例を示すブロック図である。端末装置のハード構成の一例を示すブロック図である。ゲーム管理装置の機能的構成の一例を示す機能ブロック図である。ゲーム情報管理手段の機能的構成の一例を示す機能ブロック図である。交流手段の機能的構成の一例を示す機能ブロック図である。ゲーム情報管理手段がデータベースサーバに保存して管理するゲーム情報の一例を示す説明図である。仲間情報記憶制御手段が記憶装置に記憶する仲間情報の一例を示す説明図である。仲間情報記憶制御部が記憶装置に記憶する各ユーザの仲間に関する情報の一例を示す説明図である。仲間情報記憶制御部が記憶装置に記憶する各ユーザの仲間に関する情報の他の例を示す説明図である。仲間情報記憶制御部が記憶装置に記憶する各ユーザの仲間に関する情報の他の例を示す説明図である。仲間情報記憶制御部が記憶装置に記憶する各ユーザの仲間に関する情報の他の例を示す説明図である。仲間期間記憶制御手段が記憶装置に記憶する仲間期間の一例を示す説明図である。メッセージ記憶制御部が記憶装置に記憶する受信メッセージ情報の一例を示す説明図である。メイン画面の一例を示す説明図である。仲間リスト画面の一例を示す説明図である。メッセージ入力画面の一例を示す説明図である。対戦モードにおけるゲーム画面の一例を示す説明図である。助っ人選択画面の一例を示す説明図である。対戦モードにおけるゲーム画面の他の例を示す説明図である。交流履歴記憶制御手段が記憶装置に記憶する交流履歴の情報の一例を示す説明図である。ユーザ間のレベル差と仲間期間との関係を表すテーブルの一例を示す説明図である。ゲームシステムの動作の一例を示すフローチャートである。ゲーム進行処理の一例を示すフローチャートである。仲間関係が成立した２人のユーザを対象としたゲームサーバの処理の一例を示すフローチャートである。仲間期間決定処理の一例を示すフローチャートである。仲間期間決定処理の他の例を示すフローチャートである。ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。レベル差記憶制御手段が記憶装置に記憶するレベル差の一例を示す説明図である。レベル差記憶制御手段が記憶装置に記憶するレベル差の他の例を示す説明図である。仲間期間の再設定処理の一例を示すフローチャートである。ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。仲間情報記憶制御手段が記憶装置に記憶する仲間情報の他の例を示す説明図である。過去の仲間リスト画面の一例を示す説明図である。承認・拒否選択画面の一例を示す説明図である。仲間復活申請を管理するための記憶情報の一例を示す説明図である。ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。仲間リスト画面の他の例を示す説明図である。仲間継続申請を管理するための記憶情報の一例を示す説明図である。ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。仲間期間記憶制御手段が記憶装置に記憶する仲間期間の情報の他の例を示す説明図である。仲間期間の延長処理の一例を示すフローチャートである。仲間期間の延長処理の他の例を示すフローチャートである。親密度記憶制御手段が記憶装置に記憶する親密度の情報の一例を示す説明図である。延長時の仲間期間の補正処理の一例を示すフローチャートである。仲間関係が成立した２人のユーザを対象としたゲームサーバの処理の他の例を示すフローチャートである。仲間リスト画面の他の例を示す説明図である。

　以下、本発明の一実施の形態に係るゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラムおよび記録媒体について、図面を参照しながら説明する。

　〔ゲームシステムの概要〕
　本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各ユーザの端末装置３とによって構成される。

　本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各ユーザの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（Local Area Network）、無線ＬＡＮ等であってもよく、或いはインターネットとこれらを組み合わせたものであってもよい。

　このゲームシステムの例において、本発明の一実施の形態に係るゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。ゲームサーバ１は、ゲームサービスを受ける各ユーザの端末装置３からのネットワーク４を介したアクセスを受け付けて、各ユーザのゲーム情報をデータベースサーバ２（記憶装置）に蓄積して管理し、各ユーザにネットワーク４を介したゲームサービスを提供する。

　本実施の形態では、ゲームサーバ１によるゲームサービスの提供の一形態として、各ユーザの端末装置３に搭載されたウェブブラウザによってゲームがプレイできる、いわゆるブラウザゲームを提供する例について説明する。このブラウザゲームを提供するサービス形態では、ユーザの端末装置３にゲーム専用のソフトウェアをダウンロード又はインストールする必要がなく、端末装置３をネットワーク４に接続できる環境であれば、ユーザはどこでも気軽にゲームサーバ１から提供されるゲームサービスを楽しむことができる。

　このゲームシステムでは、ブラウザゲーム用のプログラム（アプリケーションソフトウェア）がゲームサーバ１に実装されており、ゲームサーバ１が、各ユーザの端末装置３における入力操作に応じてゲーム進行のための演算処理やデータ処理を実行する。そして、ゲームサーバ１は、演算処理等の実行結果に基づいてデータベースサーバ２内の各ユーザのゲーム情報を更新するとともに、当該実行結果をユーザの端末装置３の画面に表示させるためのウェブページ情報（ゲーム画面データ）を各ユーザの端末装置３に送信する。

　各ユーザの端末装置３には、ユーザーエージェントとしてウェブサイト閲覧機能を有するウェブブラウザが搭載されており、ゲームサーバ１から送信されたウェブページ情報を端末装置３の画面に表示することができるようになっている。この端末装置３としては、例えば、携帯電話端末、ＰＨＳ（Personal Handy-phone System）端末、携帯情報端末（ＰＤＡ：Personal Digital Assistant）、携帯電話と携帯情報端末とを融合させた携帯端末であるスマートフォン、パーソナルコンピュータまたはタブレット型コンピュータなど、ネットワーク４経由でゲームサーバ１に接続してゲームサービスの提供を受けることができる様々な端末が適用できる。

　また、本実施の形態で提供されるゲームは、ユーザが、ゲームサービスを受けている他のユーザとコミュニケーションをとりながらプレイすることができる、いわゆるソーシャルゲームの要素を有する。例えば、本実施の形態のゲームサーバ１およびデータベースサーバ２をソーシャルネットワーキングサービス（ＳＮＳ）のシステムに組み込むことによって、ＳＮＳのサービスの一つとしてソーシャルゲームサービスを提供するゲームシステムとすることができる。このようにＳＮＳのプラットフォーム上で動作するゲームシステムによりゲームサービスをユーザに提供することもできるが、ゲームサーバ１およびデータベースサーバ２をＳＮＳのシステムに組み込まずに、独立したゲームシステムとして構築してもよい。

　このゲームシステムにおいて、各ユーザは、ゲームサービスを受けている１人又は複数の他のユーザと「仲間」という特別な関係を構築できる。あるユーザが他のユーザと仲間関係を構築するための一形態としては、２人のユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行い、当該仲間申請を受けたユーザがゲームサーバ１を介して仲間になることを承認するという、両ユーザ間においてなされる仲間申請とその承認の操作が挙げられる。２人のユーザ間で仲間関係が成立した場合、ゲームサーバ１は当該２人のユーザの識別情報（ユーザＩＤ）を関係付けてデータベースサーバ２に登録する。そして、ゲームサーバ１は、各ユーザを中心とする仲間グループに所属する仲間関係にある仲間ユーザの情報をデータベースサーバ２に記憶して、ユーザ毎の仲間管理を行う。この仲間申請、その承認およびゲームサーバ１による仲間管理の詳細については後述する。

　そして、本実施の形態のゲームサーバ１は、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定するようになっている。また、ゲームサーバ１は、仲間関係が成立している２人のユーザに対して設定された仲間期間の終了により、原則的に、当該２人のユーザの仲間関係を自動的に解除するという特徴的な構成を有する。

　この本実施の形態の特徴的な構成によって、ユーザは、心理的にも行い難い仲間解除の操作をすることなく、仲間期間の終了により仲間関係の解除が可能となる。これにより、仲間数が一旦上限まで達したユーザであっても、上限までに余裕ができ、他のユーザと新たな仲間関係を構築するための機会が与えられる。よって、ユーザは、例えば殆ど交流等もなく一緒にゲームを楽しめないような下位レベルの仲間に対しては、仲間期間の終了により仲間関係を断ち、改めて、自分の好みの新たな仲間を探すことができるのである。したがって、従来のように、仲間数が上限まで達したユーザが、あまり交流のない下位レベルの仲間ユーザを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。

　もっとも、ユーザが仲間関係を継続したい相手については、仲間関係を継続するための所定の操作（例えば、仲間期間中における仲間継続申請、または仲間期間終了後における仲間復活申請など）をすれば、仲間関係を継続することができる。あるいは、仲間期間中に２人のユーザ間で所定の交流が行われることにより、仲間期間が自動延長される構成により、所定の交流を続けている２人のユーザ間では、仲間関係が自動的に継続されるようにすることができる。

　上記のように、本ゲームサーバ１は、仲間関係にある両ユーザに仲間期間を設定するとともに、仲間期間の終了により仲間関係を自動解除するという斬新な機能を導入して、仲間数の上限が設定されているゲームにおいても他のユーザと新たな仲間関係を構築し易くし、マンネリ感が発生しにくいゲーム環境をユーザに提供できるのである。

　以下に、上記のように仲間数の上限が設定されているゲームにおいても他のユーザとの新たな仲間関係を構築し易いゲーム環境を提供できる、本実施の形態に係るゲーム管理装置（ゲームサーバ１等）の構成の詳細を説明する。

　〔ゲーム管理装置の構成〕
　上述のように本実施の形態では、ゲーム管理装置は、ゲームサーバ１およびデータベースサーバ２から構成される。図２にゲームサーバ１のハード構成の一例を示している。同図に示すように、ゲームサーバ１は、主に、ＣＰＵ（Central Processing Unit）１１と、主記憶装置としてのＲＯＭ（Read Only Memory）１２及びＲＡＭ（Random Access Memory）１３と、補助記憶装置１４と、通信制御部１５と、入出力制御部１６とを備えており、これらはアドレスバス、データバス及びコントロールバス等を含むバスライン１７を介して相互に接続されている。なお、バスライン１７と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

　ＣＰＵ１１は、システムソフトウェアやゲームプログラム等のアプリケーションソフトウェアの命令を解釈して実行し、ゲームサーバ１全体の制御を行う。ＲＯＭ１２は、ゲーム管理装置１の基本的な動作制御に必要なプログラム等を記憶している。ＲＡＭ１３は、各種プログラム及びデータを記憶し、ＣＰＵ１１に対する作業領域を確保する。

　補助記憶装置１４は、ゲームプログラム等のアプリケーションソフトウェアや各種データ等を格納する記憶装置である。補助記憶装置１４としては、例えばハードディスクドライブなどを用いることができる。ゲームサーバ１（コンピュータ）をゲーム管理装置として動作させるための本実施の形態のプログラムも、この補助記憶装置１４に記憶されており、当該プログラムはゲームサーバ１の起動時に補助記憶装置１４からバスライン１７を介してＲＡＭ１３へとロードされ、当該ＣＰＵ１１によって実行される。

　通信制御部１５は、ネットワーク４と接続される通信インタフェース１５ａを備え、ネットワーク４を介した各ユーザの端末装置３との間の通信を制御する。また、通信制御部１５は、ネットワーク４に接続されている図示しないサーバとの通信も制御するようになっている。例えば、ゲームサーバ１をＳＮＳに組み込んだシステム構成とした場合、ゲームサーバ１の通信制御部１５は、ＳＮＳサーバとの間の通信を制御する。

　入出力制御部１６は、データベースサーバ２と通信可能に接続されており、ＣＰＵ１１がデータベースサーバ２に対してデータ（レコード）の読み書きを実行するときの入出力制御を行うデータベースインタフェースである。

　データベースサーバ２は、ゲームサーバ１が管理する各ユーザのゲーム情報を記憶する領域を有する記憶装置として、例えばＲＡＩＤ（Redundant Arrays of Inexpensive Disks）構成の大容量ハードディスク装置を具備する。このデータベースサーバ２は、例えば、各ユーザを一意に識別する識別情報（ユーザＩＤ）と対応付けて、各ユーザの各種ゲーム情報（ユーザ名、レベル、ゲーム内ポイント、所持アイテムなど）を記憶するリレーショナルデータベース、オブジェクトデータベース又はオブジェクト関係データベース等として構築することができる。

　本実施の形態では、ゲーム管理装置がゲームサーバ１およびデータベースサーバ２から構成される例を示すが、これに限定されるものではない。例えば、ゲームサーバ１にデータベースサーバ２の機能を持たせて、ゲーム管理装置をゲームサーバ１のみで構成することもできる。また、ゲームサーバ１の有する各機能を複数のサーバに分散して持たせて、ゲームサーバ１を複数台のサーバとして構成することもできる。例えば、ユーザが端末装置３を操作してゲームサーバ１へアクセスした場合に、当該ユーザが正規のユーザかどうかを判別する認証機能を有する認証サーバを、ゲームサーバ１のメインサーバとは別に設け、メインサーバと認証サーバとでゲームサーバ１を構成してもよい。他の構成例としては、ユーザが課金対象のアイテムをゲーム内で購入した場合に課金管理を行う課金管理サーバを、ゲームサーバ１のメインサーバ等とは別に設け、メインサーバ、認証サーバおよび課金管理サーバによりゲームサーバ１を構成してもよい。

　また、本ゲームサービスを利用するユーザ数が数十万人、数百万人、あるいはそれ以上となると、多数のユーザの端末装置３からの巨大なアクセスにも耐え得るサーバシステムの構築が求められるため、ネットワーク４上に複数のゲームサーバ１を設けて冗長化（多重化）を図ることにより、負荷分散型のシステム構成としてもよい。この場合、複数のゲームサーバ１間の負荷を調整するためのロードバランサを設けることが望ましい。

　次に、本実施の形態に係るゲームサーバ１にアクセスしてゲームサービスの提供を受けるユーザの端末装置３の構成を説明する。

　〔端末装置の構成〕
　ユーザが操作する端末装置３としては、上述のように携帯電話端末やスマートフォンをはじめとして、ウェブサイト閲覧機能を有する様々な端末を適用できるが、本実施の形態では、携帯電話端末を例示してその構成を説明する。なお、携帯電話端末以外の端末装置３についても、ウェブサイト閲覧機能を用いてゲーム画面を表示したり、ゲームを実行するための入力操作を行うといった、ゲームをプレイする上で必要となる基本的な構成は、携帯電話端末と同様である。

　ウェブサイト閲覧機能等を有する携帯電話端末は、フィーチャーフォン（Feature phone）やスマートフォン（smartphone）とも呼称され、図３にその構成例を示している。同図に示すように、端末装置３は、主に、ＣＰＵ３１と、主記憶装置としてのＲＯＭ３２及びＲＡＭ３３と、画像処理部３４と、表示部３５と、サウンド処理部３６と、音声入力部３７と、音声出力部３８と、補助記憶装置３９と、操作入力部４０と、通信制御部４１とを備えており、構成要素３１～３４、３６および３９～４１はバスライン４２を介して相互に接続されている。なお、バスライン４２と各構成要素との間には必要に応じてインタフェース回路が介在しているが、ここではインタフェース回路の図示を省略している。

　ＣＰＵ３１は、ウェブブラウザを含む各種プログラムの命令を解釈して実行し、端末装置３全体の制御を行う。ＲＯＭ３２には、端末装置３の基本的な動作制御に必要なプログラム等が記憶されている。また、ＲＡＭ３３には、ＲＯＭ３２または補助記憶装置３９からロードされた各種プログラムやデータが記憶され、ＣＰＵ３１に対する作業領域を確保する。ＨＴＭＬ等で記述されたゲーム画面データを表示するウェブブラウザは、ＲＯＭ３２または補助記憶装置３９に記憶されており、ＲＡＭ３３にロードされてＣＰＵ３１によって実行される。また、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインソフトウェアを、ウェブブラウザと共にＲＯＭ３２または補助記憶装置３９に記憶していてもよい。

　画像処理部３４は、ＣＰＵ３１からの画像表示命令に基づいて表示部３５を駆動し、当該表示部３５の画面に画像を表示させる。表示部３５には、液晶ディスプレイまたは有機ＬＥ（Electro-Luminescence）ディスプレイ等の既知の種々の表示装置が適用できる。

　サウンド処理部３６は、音声入力部３７から音声が入力されたときにアナログ音声信号をデジタル音声信号に変換するとともに、ＣＰＵ３１からの発音指示に基づいてアナログ音声信号を生成して音声出力部３８に出力する。音声入力部３７は、端末装置３に内蔵されたマイクロフォンからなり、電話通信する場合や録音を行う場合などに用いられる。音声出力部３８は、電話通信時の受話スピーカおよび電話着信音やゲーム実行時の効果音などを出力するスピーカからなる。

　補助記憶装置３９は、各種プログラムやデータ等を格納する記憶装置である。補助記憶装置３９としては、携帯電話端末の内部メモリとして、例えばフラッシュメモリドライブ等を用いることができ、また、携帯電話端末の外部メモリとして、例えばメモリカードリーダライタ等を用いることができる。

　操作入力部４０は、ユーザの操作入力を受け入れて当該操作入力に対応した入力信号を、バスライン４２を介してＣＰＵ３１に出力するものである。操作入力部４０の例としては、端末装置３の本体に設けられた方向指示ボタン、決定ボタン、英数文字等入力ボタンなどの物理的ボタンがある。また、表示部３５の画面にタッチパネル（接触入力式のインタフェース）を搭載することによって表示部３５をいわゆるタッチスクリーンとして構成している端末装置３の場合、当該タッチパネルも操作入力部４０となる。

　通信制御部４１は、通信インタフェース４１ａを備え、ゲーム操作時等にデータ通信するための通信制御機能および携帯電話端末として音声データを送受信するための通信制御機能等を有している。ここで、データ通信用の通信制御機能には、例えば、無線ＬＡＮ接続機能、無線ＬＡＮや携帯電話回線網を介したインターネット接続機能、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信機能などが含まれる。通信制御部４１は、ＣＰＵ３１からの命令に基づいてゲーム装置１を無線ＬＡＮやインターネット等に接続するための接続信号を発信するとともに、通信相手側から送信されてきた情報を受信してＣＰＵ３１へ供給する。

　なお、端末装置３には、その他にもＧＰＳ（Global Positioning System）信号受信回路、ＣＣＤ（Charge Coupled Device）イメージセンサ等の撮像装置（カメラ）、３軸加速度センサなどが備えられていてもよく、例えば、ＧＰＳ位置情報などをゲーム内で活用してもよい。

　上記構成の端末装置３において、ゲームサービスを受けようとするユーザは、ウェブブラウザを立ち上げてゲームサーバ１が管理するゲームサイトにアクセスする操作を行う。このアクセスがゲームサーバ１に認証された場合、端末装置３の通信制御部４１がゲームサーバ１から送信されてくるＨＴＭＬ等で記述されたゲーム画面データを受信し、ＣＰＵ３１がウェブブラウザを実行してゲーム画面を表示部３５に表示させる。ここでユーザは、ゲーム画面に表示されている選択可能なボタンオブジェクトやハイパーリンクを、操作入力部４０を操作して選択入力する。この選択入力に応じてゲームサーバ１がゲームを進行させ、新たなゲーム画面データを端末装置３に送信する。そして、この新たなゲーム画面が端末装置３の表示部３５に表示され、以下、同様に、ユーザは、表示部３５に表示されているゲーム画面で選択可能なボタンオブジェクト等を選択する操作により、ゲームサーバ１が提供するゲームをプレイすることができるようになっている。

　〔ゲーム管理装置の機能的構成〕
　次に、上記のように構成されたゲーム管理装置（ゲームサーバ１およびデータベースサーバ２）の主要な機能について説明する。図４は、ゲーム管理装置の主要機能ブロック図である。

　ゲーム管理装置は、主に、ゲーム情報管理手段５１、ゲーム進行手段５２、認証手段５３、仲間管理手段５４、交流手段５５、仲間期間設定手段５６、仲間関係解除手段５７、仲間期間報知手段５８および仲間成立ポイント付与手段５９を備えている。これらの各手段５１～５９は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

　ゲーム情報管理手段５１は、各ユーザのゲーム情報をデータベースサーバ２に蓄積して管理する。ゲーム情報管理手段５１で管理されるゲーム情報の項目は、本ゲームサーバ１がユーザに提供するゲームサービスの内容によって異なる。

　本ゲームサーバ１によって提供されるゲームの例としては、野球、サッカー、ゴルフなどの各種スポーツを題材としたスポーツゲーム、戦闘を題材とした戦闘ゲーム、音楽シミュレーションゲーム、その他種々のロールプレイングゲーム・育成ゲーム・シミュレーションゲームといったように、ゲーム形式・ジャンルを問わず様々なゲームを挙げることができる。その一例として、本実施の形態では、ゲームサーバ１がゲームサービスとして野球ゲームを提供する場合について、以下に説明する。

　本実施の形態では、ユーザがゲーム内において選手キャラクタを所有し、当該選手キャラクタを用いてゲーム内で他のユーザと試合（対戦）を行うことができる野球ゲームを例に挙げる。ユーザが所有する選手キャラクタは、当該選手キャラクタの形態を端末装置３の画面上で視認可能としたカード形式とすることができる。すなわち、選手キャラクタは、デジタル選手カードとしてゲームサーバ１で管理されるとともに、ユーザの端末装置３の画面に表示される。図１３には、ユーザの端末装置３の画面に表示される選手カード７１を例示しており、選手キャラクタの形態およびカードのレア度（希少価値の高さを☆の多さで示したもの）などを表記したデジタル選手カードとして画面上に表示される。ユーザは、ゲームを進行させながら選手カードを集め、自分だけのオリジナルチームを結成し、他のユーザと対戦してランキングを競うことができる。また、ユーザは、集めた選手カード同士を合成することによって選手カード（選手キャラクタ）の能力を向上させる（すなわち、選手を育成する）ことができ、より強いチーム作りを目指してゲームを楽しむことができるようになっている。

　このような野球ゲームにおいて、各ユーザのゲーム情報を管理するゲーム情報管理手段５１は、図５に示すように、ユーザ情報記憶制御手段５１ａ、レベル情報記憶制御手段５１ｂ（ゲームレベル記憶制御手段）、所有選手カード記憶制御手段５１ｃ、所有ポイント記憶制御手段５１ｄ、所有コイン記憶制御手段５１ｅ、所有アイテム記憶制御手段５１ｆ、試合結果記憶制御手段５１ｇおよびランキング記憶制御手段５１ｈなどを備えている。図７には、ゲーム情報管理手段５１の各記憶制御手段５１ａ～５１ｈがデータベースサーバ２に記憶して管理する、各ユーザのゲーム情報の一例（この例ではユーザＩＤ＝“０００００１”の１人分のゲーム情報）を示している。

　ユーザ情報記憶制御手段５１ａは、各ユーザを一意に識別するユーザＩＤと対応付けて、ログインＩＤ、パスワード、ユーザ名（ゲーム内で使用するニックネーム等）、チーム名等の各ユーザに関するユーザ情報を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。ここで、ログインＩＤおよびパスワードは、各ユーザが端末装置３を操作してゲームサーバ１にアクセスしたときのログイン認証に用いられる。ユーザ名およびチーム名は、ユーザがゲームサービスを受けるための会員登録をした際や、ゲームを初めて実行した際に、ユーザが自ら設定した任意の情報である。ユーザ名およびチーム名は、必要に応じてゲーム画面に表示される。

　レベル情報記憶制御手段５１ｂは、ユーザＩＤと対応付けて、ゲームレベルとしてのユーザのレベルや所属リーグのレベル等のレベル情報を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。本野球ゲームでは、例えば、ユーザがゲームを進行させることにより経験値が蓄積され、当該経験値が一定量に達することによりユーザのレベルがアップするようになっている。また、本野球ゲームでは、例えば、複数の異なるレベルのリーグが存在し、各ユーザのチームが何れかのリーグに所属して、同リーグの他のユーザのチームと自動で試合（リーグ戦）を行うようになっている。また、このリーグ戦の成績に応じて、異なるリーグに所属するユーザのチーム同士の入替戦が自動で実行され、ユーザのチームが所属するリーグレベルが変化するようになっている。レベル情報記憶制御手段５１ｂは、このユーザのレベルや所属リーグのレベルを、ユーザＩＤと対応付けて記憶領域に記憶する。

　所有選手カード記憶制御手段５１ｃは、ユーザＩＤと対応付けて、ゲーム内でユーザが獲得して所有している選手カードの情報を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。この選手カードの情報の例としては、選手カードを一意に識別するための識別情報（選手カードＩＤ）、選手の能力の高さを示す能力値およびレギュラー選手フラグなどがある。

　図７では、３つの能力項目（能力１～３）に対して選手の能力値を設定できる例を示している。能力項目の例としては、選手カードが野手の場合は、能力１～３を「打撃」、「走力」、「守備」等とすることができ、また選手カードが投手の場合は、能力１～３を「球威」、「制球」、「変化」等とすることができる。能力項目はこの例に限らず、増減可能である。レギュラー選手フラグとは、ユーザが所有している選手カードのうち、他のユーザのチームとの試合に出場するレギュラー選手（チームオーダーに組み込まれた選手）であるか、それともレギュラー選手以外の控え選手であるかを判別するフラグであり、これが「１」のときレギュラー選手の選手カードとして登録されていることを示す。ユーザは、端末装置３を操作することにより、所有している選手カードからレギュラー選手を選択したり、チームオーダーを設定したりすることができるようになっている。

　また、データベースサーバ２には、選手カードＩＤと対応付けられて、選手カードの画像データ、選手名、ポジション、所属球団、能力値（合成により強化されていない初期値）などが記憶された選手カードデータベースが存在し、ゲーム情報管理手段５１は、所有選手カード記憶制御手段５１ｃが記憶領域に記憶している選手カードＩＤに基づいて、当該選手カードＩＤに対応する選手カードの画像データ等を取得できるようになっている。

　所有ポイント記憶制御手段５１ｄは、ユーザＩＤと対応付けて、ゲーム内でユーザが所有している各種ポイント（ポイントに準ずる値などを含む）を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。本ゲームにおいては、様々なゲームモードが存在し、ゲームモードに応じて様々なポイントを獲得したり、獲得したポイントを使用したりできるようになっている。

　図７に示すように、ポイントの例としては、上述の経験値の他、行動力ポイント、運営コスト、強化ポイント、交流ポイントなどがある。行動力ポイントは、当該行動力ポイントを消費しながら選手カードを探索して選手をスカウトするという「スカウトモード」で使用される。運営コストは、他のユーザを指定して個別対戦の試合を行う「試合モード」で使用されるものであり、試合を運営する場合に必要なコスト（ポイント）という位置付けで、当該個別対戦を行うことにより消費される。例えば、ゲーム中に消費されて減った行動力ポイントや運営コストは、時間の経過により回復する（例えば、３分経過する毎に１ポイントずつ回復する）ようにしたり、前記経験値が一定量に達してユーザのレベルがアップすることにより回復するようにしたりできる。

　また、前記の強化ポイントは、ユーザが所有する選手カード同士を合成することによって選手カードの能力を向上させる「強化モード」で使用されるものであり、当該合成を行うことにより消費される。この強化ポイントは、例えばスカウトモードの実行や試合モードの実行等によって獲得できるようにすることができる。

　また、前記交流ポイントは、ユーザが他のユーザ（特に仲間ユーザ）と挨拶等の交流を行うことによって獲得できるポイントである。交流の具体例等の詳細については後述する。この交流ポイントは、例えば、ゲームサーバ１が管理している全ての選手カードの中から乱数等に基づく抽選で所定枚数（例えば１枚）の選手カードを獲得できる「抽選モード」で使用可能であり、所定の交流ポイントにつき１回の選手カード抽選を受けることができる。

　所有コイン記憶制御手段５１ｅは、ユーザＩＤと対応付けて、ゲーム内でユーザが所有しているコイン（前記ポイントとは別のゲーム内通貨）を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。このコインは、例えば、課金対象のアイテムを獲得する等の際に必要となるものである。

　所有アイテム記憶制御手段５１ｆは、ユーザＩＤと対応付けて、ゲーム内でユーザが獲得したアイテムを、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。図７に示すように、アイテムの例としては、回復アイテム、パズルカードのピース、フェイクカードなどがある。回復アイテムは、ゲーム中に消費して減った前述の行動力ポイントおよび／または運営コストを、時間の経過を待たずに一瞬で最大値まで回復させるアイテムである。例えば、回復アイテムは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。

　パズルカードのピースは、所定数のピース（例えばＰ１～Ｐ６の６つのピース）を全部集めてパズルカードを完成させることで強力な（能力値の高い）選手カードを入手することができるアイテムである。例えば、パズルカードのピースは、前記スカウトモードの実行時に乱数等に基づく抽選で当選した場合に獲得でき、また前記試合モードで他のユーザが所有しているピースを狙って対戦して勝利した場合に、当該対戦相手のユーザから奪取できるようになっている。

　フェイクカードは、前記パズルカードのピースにセットしておくことにより、前記試合モードの対戦で他のユーザに負けても、狙われたピースを一度だけ奪取されないようにできるアイテムである。例えば、フェイクカードは、前記コインを消費して購入したり、ゲーム内で所定のボーナス条件を満たしたりすることにより獲得できる。

　試合結果記憶制御手段５１ｇは、ユーザＩＤと対応付けて、ユーザのチームが他のユーザのチームと対戦した試合を一意に特定するための試合ＩＤを、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。ここで、試合ＩＤにより一意に特定される試合は、ユーザが対戦相手を指定して行う個別対戦の試合、およびゲームサーバ１により自動で行われるリーグ戦の試合を含む。

　また、データベースサーバ２は、試合ＩＤと対応付けられて、試合日時（現実世界の試合開始または終了の時間）、勝利したチームのユーザＩＤ、敗北したチームのユーザＩＤ、対戦スコア、勝利投手キャラクタ、敗戦投手キャラクタ、本塁打を打った選手キャラクタ、試合寸評情報などの試合結果に関する情報が記憶された試合データベースを備えている。そして、ゲーム情報管理手段５１は、試合結果記憶制御手段５１ｇが記憶領域に記憶している試合ＩＤに基づいて、当該試合ＩＤに対応する試合結果に関する情報を、試合データベースから取得できるようになっている。

　ランキング記憶制御手段５１ｈは、ユーザＩＤと対応付けて、前記リーグ戦や入れ替え戦におけるユーザのチームの勝利数および敗戦数、ならびに勝利数・敗戦数に基づく所属リーグ内の順位などのランキング情報を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。例えば、リーグ戦が現実世界における月曜日～金曜日の各日の所定時間に所定の試合数（例えば各日１２試合）自動的に行われ、また、入れ替え戦が現実世界における土曜日および日曜日の所定時間に所定の試合数（例えば各日１２試合）自動的に行われるものとする。この場合、図７に示すように、ランキング記憶制御手段５１ｈは、現実世界の月曜日～日曜日の各日についてのランキング情報を記憶し、毎週、ランキング情報を最新の情報に更新する。

　次に、図４に示すゲーム進行手段５２について説明する。ゲーム進行手段５２は、ユーザによる端末装置３に対する操作に応じてゲームを実行し、当該実行結果に応じたゲーム画面データを生成してこれを端末装置３に送信し、端末装置３にユーザの操作に応じたゲーム画面を表示させることによってゲームを進行させる機能を有する。図４に示すように、このゲーム進行手段５２は、ゲーム実行手段５２ａと、ゲーム画面生成手段５２ｂと、ゲーム画面送信手段５２ｃとを備えている。

　ユーザの端末装置３のウェブブラウザによってゲーム画面が表示されているとき、ユーザがゲーム画面上の選択可能なボタンオブジェクトやハイパーリンクが設定された文字列等を選択する操作を行った場合、当該操作に応じたゲーム画面のリクエストが端末装置３のウェブブラウザによってゲームサーバ１へ送信される。このリクエストを受信したゲームサーバ１では、ゲーム実行手段５２ａが、当該リクエストに応じてユーザのゲーム情報を読み出して演算やデータ処理を行うことによってゲームを実行する。

　例えば、対戦モードで他のユーザのチームと対戦するという操作がユーザによって行われた場合を例に挙げると、ゲーム実行手段５２ａは、対戦を行う両ユーザのユーザＩＤに対応した両チームの選手カード情報（試合に出場するレギュラー選手の選手カード情報）をデータベースサーバ２から読み出す。そして、ゲーム実行手段５２ａは、両チームの選手カードの能力値等に基づいて、勝敗を決定する演算を行う。この勝敗決定の演算の例としては、単純に両チームの選手カードの能力値の合計が高い方を勝利チームとしてもよいし、能力値の合計が高い方のチームが勝利する確率を高くして勝利チームを確率演算により求めてもよい。また、ゲーム実行手段５２ａは、勝敗を決定する演算の前に、チームを構成する選手カードの組み合わせに基づいて、勝敗に影響を与える様々な効果演出を発生させるか否かを決定する演算を行ってもよい。

　ゲーム画面生成手段５２ｂは、ゲーム実行手段５２ａによる実行結果に応じて、例えばＨＴＭＬデータからなるゲーム画面データを生成する。ＨＴＭＬデータには、データベースサーバ２から読み出された選手カード等の画像データを含めてもよい。また、ＨＴＭＬデータには、端末装置３のウェブブラウザのプラグインによって動作するスクリプト（プログラム）が埋め込まれていてもよい。ゲームサーバ１から提供されたスクリプトが端末装置３で実行される場合は、端末装置３で表示されるゲーム画面を動画とすることも可能である。

　ゲーム画面送信手段５２ｃは、ゲーム画面生成手段５２ｂにより生成されたゲーム画面データ（ＨＴＭＬデータ等）を、ゲーム画面のリクエストに対するレスポンスとしてユーザの端末装置３へ送信する。このゲーム画面データを受信したユーザの端末装置３では、ウェブブラウザによって表示部３５にゲーム画面が表示される。

　次に、認証手段５３について説明する。認証手段５３は、ゲームサービスを受けようとするユーザが端末装置３を操作してゲームサーバ１にアクセス（ログイン）しようとした際、当該ユーザのゲーム参加資格の有無を判断してログイン認証を行う。この認証の例としては、ユーザＩＤと対応付けられたログインＩＤおよびパスワードに基づく認証がある。例えば、ユーザが初めてゲームサービスを利用するときに、会員情報としてログインＩＤ（任意の英数文字やメールアドレス等）およびパスワードをゲームサーバ１に登録する。そして、次回からのゲームサーバ１へのログイン時には、ユーザが端末装置３を操作してログインＩＤおよびパスワードをゲームサーバ１へ送信する。このとき、ゲームサーバ１の認証手段５３が、ユーザの端末装置３から受信したログインＩＤおよびパスワードの組み合わせが登録済みであるか否かを判断し、ログイン認証を行う。

　また、ＳＮＳのシステムに本ゲームシステムを組み込む場合、ＳＮＳの会員登録情報（ログインＩＤおよびパスワード）をそのまま本ゲームシステムのゲームサービスを受けるための利用登録情報としてもよい。例えば、ユーザの端末装置３がＳＮＳサーバにログインしている状態で、ゲームサーバ１が管理するゲームサイトに最初にアクセスした際、ＳＮＳサーバからゲームサーバ１へ自動的にユーザのログインＩＤおよびパスワードが転送され、これによってユーザが改めてログインＩＤおよびパスワードを登録することなくゲームサービスの利用登録ができるようにしてもよい。

　また、ユーザがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できるように、端末装置３である携帯電話やスマートフォンの個体識別番号（電話番号とは別の端末を一意に識別するための情報）、または契約者固有ＩＤ（端末の契約者を一意に識別するための情報であって、機種変更を行っても契約者が同一である限りは変更されないＩＤ）を利用した認証を行ってもよい。すなわち、ユーザが端末装置３を操作して会員登録した際に、当該端末装置３から送信されてくるデータに含まれる個体識別番号または契約者固有ＩＤをゲームサーバ１が取得し、ログインＩＤおよびパスワードとともに、当該個体識別番号または契約者固有ＩＤもユーザＩＤと対応付けてデータベースサーバ２に記憶しておくのである。そして、認証手段５３は、端末装置３からアクセス要求を受けた際には、個体識別番号または契約者固有ＩＤが登録済みであるか否かを判断してログイン認証を行う。これにより、ゲームサーバ１へのアクセス時には、ユーザはログインＩＤおよびパスワードの入力を省略してログインすることが可能となる。

　また、ユーザがゲームサーバ１にアクセスする度にログインＩＤおよびパスワードを入力する手間を省略できる別の方法としては、HTTP cookieの情報（以下、Cookieと称する）を利用する方法もある。すなわち、ユーザが端末装置３を操作して会員登録した際に、ゲームサーバ１がログインＩＤおよびパスワードに対応した個体識別情報を発行してデータベースサーバ２へ登録するとともに、当該個体識別情報をCookieとして端末装置３へ送信する。このとき、端末装置３のブラウザは、受信したCookieを端末装置３内へ記憶する。次回からのゲームサーバ１へのアクセスの際には、端末装置３のブラウザがページ閲覧要求とともにCookieをゲームサーバ１へ送信するので、認証手段５３は、端末装置３からアクセス要求を受けた際には、Cookieの個体識別番号が登録済みであるか否かを判断してログイン認証を行うことができる。

　次に、仲間管理手段５４について説明する。仲間管理手段５４は、仲間関係が成立している２人のユーザを関係付けた仲間情報をデータベースサーバ２（記憶装置）に記憶する仲間情報記憶制御手段５４ａを備えている。図８には、仲間情報記憶制御手段５４ａがデータベースサーバ２に記憶する仲間情報の一例を示している。

　図８に示すように、仲間情報記憶制御手段５４ａは、ある２人のユーザ間で仲間関係が成立したときに、仲間申請をしたユーザのユーザＩＤと当該仲間申請を承認したユーザのユーザＩＤとを関係付けた仲間情報をデータベースサーバ２へ記憶する。そして、仲間管理手段５４は、各仲間情報にこれらを一意に識別するための仲間情報ＩＤを付加し、仲間情報ＩＤに基づいて仲間管理を行う。

　図８の例では、仲間申請したユーザＩＤ＝“０００００１”のユーザＡと、それを承認したユーザＩＤ＝“０００００２”のユーザＢとの２人のユーザを関係付けた仲間情報が、仲間情報ＩＤ＝“１”の仲間情報としてデータベースサーバ２に登録されている。これにより、ユーザＡにとってユーザＢは仲間関係にある仲間ユーザであり、ユーザＢにとってもユーザＡは仲間ユーザとなる。

　また、各ユーザは複数の仲間を作ることができ、各ユーザを中心とする仲間グループを構成することが可能である。図８の例では、ユーザＩＤ＝“０００００１”のユーザＡは、ユーザＩＤ＝“０００００５”および“００００３５”のユーザとも仲間関係を構築している。そして、仲間管理手段５４は、各ユーザを中心とする仲間グループに所属する仲間関係にある仲間ユーザの情報をデータベースサーバ２に記憶して、ユーザ毎の仲間管理を行う。

　図９Ａには、仲間管理手段５４がデータベースサーバ２に記憶している仲間情報等に基づいて管理している、各ユーザの仲間に関する情報の一例を示している。仲間管理手段５４の仲間情報記憶制御手段５４ａは、ユーザＩＤと対応付けて、仲間数の上限の情報、すでに仲間の関係になっている仲間ユーザのユーザＩＤ、仲間申請中のユーザのユーザＩＤ、および仲間申請を受けているが未承認のユーザのユーザＩＤなどの仲間に関する情報を、ユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。図９Ａの例では、ユーザＩＤ＝“０００００１”のユーザ１人分の仲間に関する情報を示しており、仲間数の上限は４５人、当該ユーザの仲間ユーザは１０人、仲間申請中のユーザは１人、仲間申請を受けているが未承認のユーザは０人である。

　本実施の形態の野球ゲームでは、仲間をつくることによって、後述の仲間成立ポイント付与手段５９により、仲間関係になった両ユーザにボーナスポイントが付与される（例えば、前記行動力ポイントや運営コストの最大値を所定ポイントだけ増加させることができる）。また、仲間ユーザと協力して試合をしたり、仲間同士で選手カードのプレゼントや応援を行ったりすることで、ゲームを有利に進めることができるゲーム仕様となっている。このようにゲーム内で仲間をつくることによるメリットをユーザに付与することにより、仲間を作ることを促進している。

　但し、各ユーザが他のユーザと仲間関係を構築することができる仲間数には上限を設定することができる。仲間数の上限としては、各ユーザに共通の１つの上限（例えば、５０人）を設けることができる。あるいは、各ユーザのゲームの進行度合いに応じて、仲間数の上限が所定範囲（例えば１０人～９９人の範囲）で変動するようにしてもよい。本実施の形態では、仲間数の上限が１０人～９９人の範囲で変動し、ユーザのレベルが高くなるほど、仲間数の上限が大きくなるようにしている。これにより、ユーザは、より多くの仲間を作ってゲームを有利にするために、ゲームを継続的に進めてレベルアップを図ろうとする動機付けを与えられることになる。仲間情報記憶制御手段５４ａは、ユーザＩＤと対応付けて、各ユーザの仲間数の上限を記憶しており、仲間管理手段５４が各ユーザの仲間数の上限を管理する。

　本実施の形態において、２人のユーザが仲間になるには、両ユーザの何れか一方が、他方のユーザに対してゲームサーバ１を介して仲間申請を行う。この仲間申請の操作例としては、先ず、仲間を作ろうとするユーザが、端末装置３の画面上に仲間候補の対象者をリストアップする操作を行う。このとき、ユーザは、仲間候補のユーザレベルを指定することができる。このユーザによる操作に応じて、ゲームサーバ１が仲間候補の対象者をリストアップした画面データを送信することにより、複数の仲間候補がリストアップされた画面がユーザの端末装置３に表示される。ここで、ユーザは、画面上にリストアップされた対象者のユーザレベルや所属リーグレベル等を確認し、仲間にしたいユーザを選択して仲間申請の操作を行う。

　例えば、ユーザＩＤ＝“０００００１”のユーザＡが、ユーザＩＤ＝“０００００２”のユーザＢに対して仲間申請の操作を行った場合を考える。図９Ａに示すように、この操作に応じてゲームサーバ１の仲間情報記憶制御手段５４ａは、仲間申請を行ったユーザＡのゲーム情報として、当該ユーザＡのユーザＩＤ＝“０００００１”と対応付けて、被申請者であるユーザＢのユーザＩＤ＝“０００００２”を、「申請中のユーザＩＤ」として記憶領域に記憶する。

　さらに、図１０Ａに示すように、仲間情報記憶制御手段５４ａは、被申請者であるユーザＢのゲーム情報として、当該ユーザＢのユーザＩＤ＝“０００００２”と対応付けて、仲間申請を行ったユーザＡのユーザＩＤ＝“０００００１”を、「未承認のユーザＩＤ」として記憶領域に記憶する。そして、ゲームサーバ１は、その後、ユーザＢの端末装置３がゲームサーバ１にログインしたときに、ユーザＡから仲間申請があった旨を通知する。

　そして、仲間申請を受けたユーザＢは、ゲームサーバ１から受信したユーザＡのユーザレベルや所属リーグレベル等の情報を、端末装置３の画面上で確認し、仲間として承認するか拒否するかを選択する操作を行う。ここで、ユーザＢが仲間として承認する操作を行った場合、この操作に応じてゲームサーバ１の仲間管理手段５４は、ユーザＡとユーザＢとの仲間関係を成立させ、図８に示すように両ユーザＡ・ＢのユーザＩＤを関係付けた仲間情報をデータベースサーバ２に登録する。そして、仲間情報記憶制御手段５４ａは、図９Ｂに示すように、ユーザＡのゲーム情報として、当該ユーザＡのユーザＩＤ＝“０００００１”と対応付けて、ユーザＢのユーザＩＤ＝“０００００２”を、「仲間ユーザＩＤ」として記憶領域に記憶し、「申請中のユーザＩＤ」からユーザＢのユーザＩＤを削除する。

　さらに、図１０Ｂに示すように、仲間情報記憶制御手段５４ａは、ユーザＢのユーザＩＤ＝“０００００２”と対応付けて、ユーザＡのユーザＩＤ＝“０００００１”を、「仲間ユーザＩＤ」として記憶領域に記憶し、「未承認のユーザＩＤ」からユーザＡのユーザＩＤを削除する。そして、ゲームサーバ１は、その後、ユーザＡの端末装置３がゲームサーバ１にログインしたときに、ユーザＢから仲間の承認があった旨を通知する。

　次に、交流手段５５について説明する。交流手段５５は、ユーザの端末装置３から、他のユーザ（特に、仲間ユーザ）に対して所定の交流を行う情報を受信し、受信した情報に基づいて、当該ユーザから当該他のユーザに対しての交流処理を実行する機能を備えている。図６に示すように、本実施の形態の交流手段５５は、挨拶手段５５ａ、メッセージ伝達手段５５ｂ、メッセージ記憶制御部５５ｃ、プレゼント手段５５ｄ、対戦協力手段５５ｅおよび交流履歴記憶制御手段５５ｆ等を具備する。

　挨拶手段５５ａは、各ユーザの端末装置３から送信された他のユーザ宛の挨拶情報を受信して、当該他のユーザへ挨拶情報を伝達する機能を有する。また、メッセージ伝達手段５５ｂは、各ユーザの端末装置３から送信された他のユーザ宛のメッセージを受信するとともに、当該メッセージを当該他のユーザへ伝達する機能を有する。このメッセージ伝達手段５５ｂは、メッセージ記憶制御部５５ｃを備えている。

　図１２には、メッセージ記憶制御部５５ｃがデータベースサーバ２に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶制御部５５ｃは、メッセージを受け取った受信側ユーザのユーザＩＤと対応付けて、送信元のユーザＩＤ、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のユーザのユーザＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。また、各メッセージに関する情報には、各メッセージを一意に識別するためのメッセージＩＤが付加されている。図１２の例では、ユーザＩＤ＝“０００００２”の受信側ユーザ１人分の受信メッセージに関する情報を示しており、当該ユーザは、ユーザＩＤ＝“０００００１”のユーザから「プレゼントありがとう！」、ユーザＩＤ＝“００００３８”のユーザから「おはよう！今週のイベント頑張ろう！」、ユーザＩＤ＝“０００１４５”のユーザから「今週もよろしく！」というメッセージをそれぞれ受け取っている。

　ここで、ユーザが、自分の仲間ユーザに対して、挨拶したりメッセージを送ったりする操作の一例を説明する。例えば、ユーザが端末装置３を操作してメイン画面中の「仲間リスト」ボタンを選択すれば、端末装置３から仲間リスト要求がゲームサーバ１へ送信される。ゲームサーバ１は、ユーザの端末装置３からこの要求を受信して、当該ユーザの仲間リストを表示させる情報を端末装置３へ送信する。これにより端末装置３には、例えば図１４に示すような仲間リスト画面が表示される。この仲間リスト画面には、ユーザと仲間関係にある仲間ユーザの情報がリストアップされて表示される。なお、画面に表示しきれない仲間ユーザの情報については、画面をスクロールするまたは仲間リストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。

　この仲間リスト画面内にはリストアップされた仲間ユーザ毎の情報表示領域が設けられており、各情報表示領域には、仲間ユーザのゲーム情報８１（ユーザ名、チーム名、ユーザのレベル、仲間の人数、所属リーグのレベル等）、当該ユーザの分身的なキャラクタであるアバター８２、当該ユーザが所有するリーダーの選手カード８３などとともに、挨拶ボタン８４というオブジェクトも表示される。そして、ユーザがこの挨拶ボタン８４を選択操作することで、自分の仲間ユーザに対してゲーム内で仮想的に挨拶することができるようになっている。例えば、ユーザＡが仲間ユーザＢの挨拶ボタン８４を選択操作した場合、端末装置３から挨拶情報が送信され、この挨拶情報を受信した挨拶手段５５ａが、仲間ユーザＢの端末装置３へユーザＡから挨拶があったことを伝達する。

　ここで、挨拶とは、上記のようにゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール（応援）を送る、ガッツ（やる気）を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。ユーザは、仲間ユーザに挨拶だけすることもできるが、以下に説明するように、挨拶と同時にメッセージを送ることもできる。

　ユーザの端末装置３における操作により挨拶ボタン８４が選択された場合、当該操作が端末装置３からゲームサーバ１へ伝えられる。その後、ゲームサーバ１からは、例えば図１５に示すメッセージ入力画面のデータが端末装置３へ送信され、端末装置３に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間ユーザ（図１５の例ではユーザＢ）に対して挨拶した旨を示す文章等が表示されるとともに、メッセージ入力領域８５および送信ボタン８６というオブジェクトも表示される。そして、ユーザは、端末装置３を操作してメッセージ入力領域８５に任意のメッセージを入力し、送信ボタン８６を選択することによって、端末装置３からは仲間ユーザ宛のメッセージがゲームサーバ１へ送信される。図１５では「プレゼントありがとう」というメッセージをユーザが入力した例を示している。なお、データベースサーバ２における記憶容量を考慮して、メッセージ入力領域８５に入力できる文字に制限（例えば全角３０文字以内）を設けてもよい。

　なお、メッセージ入力画面には、仲間ユーザ（この例ではユーザＢ）のページへ遷移するためのハイパーリンク８７が表示されており、このリンクを選択することにより当該仲間ユーザのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク８８やメイン画面へ遷移するためのハイパーリンク８９なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。

　このメッセージ入力画面でのユーザの操作により端末装置３からメッセージが送信された場合、ゲームサーバ１では、メッセージ伝達手段５５ｂのメッセージ記憶制御部５５ｃが、端末装置３から受信した仲間ユーザ宛のメッセージを、当該仲間ユーザのユーザＩＤと対応させてデータベースサーバ２に記憶する（図１２参照）。そして、当該仲間ユーザの端末装置３がゲームサーバ１へアクセスしたとき、ゲームサーバ１のメッセージ伝達手段５５ｂは、メッセージ、送信元のユーザ名、送信時間等を表示させる画面データを端末装置３に送信する。これにより、この画面データを受信したユーザの端末装置３にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。

　このように、本実施の形態のゲームシステムでは、前記図１４および図１５に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。

　前記図１４および図１５の例では、ユーザの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のユーザに対しても、挨拶したりメッセージを送ったりすることもできる。例えば、仲間候補リストにリストアップされた仲間ではない他のユーザに対して、仲間の場合と同様の操作により、挨拶やメッセージを送ることも可能である。

　プレゼント手段５５ｄは、各ユーザの端末装置３から送信された他のユーザ宛のプレゼントの情報を受信して、当該他のユーザへプレゼントを届ける機能を有する。プレゼントの対象としては、ユーザがゲーム内で所有している選手カードや各種アイテムなどが挙げられる。

　対戦協力手段５５ｅは、ユーザ（ユーザＡとする）の端末装置３から、仲間ユーザに対して対戦協力を要請する情報を受信し、ユーザＡのキャラクタ（複数のキャラクタからなるグループやチームでもよい）が他のキャラクタと対戦するときに、仲間ユーザのキャラクタ（例えば、リーダーの選手カード）を、「助っ人」としてユーザＡ側に加担させて対戦協力を実行する機能を有する。このように、仲間ユーザのキャラクタが助っ人としてユーザＡ側に加担して対戦協力することにより、ユーザＡ側の戦力が向上するので、当該対戦協力がない場合に比べて、ユーザＡの対戦が有利になる。

　なお、ユーザのキャラクタが他のキャラクタと対戦する場合の「他のキャラクタ」とは、他のユーザのキャラクタ（複数のキャラクタからなるグループやチームでもよい）又はゲームサーバ１のＣＰＵが用意したキャラクタ（例えば、各ステージの最後に登場するボスキャラクタ等）のいずれであってもよい。

　ユーザが端末装置３を操作して、助っ人にしたい仲間ユーザのキャラクタ（または仲間ユーザ）を選択すれば、端末装置３からは、選択された仲間ユーザのキャラクタ（または仲間ユーザ）の情報を含む対戦協力要請情報がゲームサーバ１へ送信される。そして、ゲームサーバ１の対戦協力手段５５ｅは、ユーザの端末装置３から送信された対戦協力要請情報を受信して、当該ユーザが選択した仲間ユーザのキャラクタを助っ人として受け付ける。

　図１６Ａに、対戦モードにおけるゲーム画面の一例を示している。このゲーム画面には、ユーザが指定した対戦相手のチーム（敵軍）の情報９１およびユーザのチーム（自軍）の情報９２が表示される。対戦相手のチーム（敵軍）の情報９１としては、例えば、対戦相手のユーザ名、アバター、選手カード、戦力に関する情報などが表示される。また、ユーザのチーム（自軍）の情報９２としては、当該ユーザのユーザ名、アバター、選手カード、戦力に関する情報などが表示される。さらに、このゲーム画面の助っ人表示領域９３には、助っ人として自軍に協力するキャラクタ等の情報が表示されるようになっている。このゲーム画面は、ゲームサーバ１のゲーム画面生成手段５２ｂにより生成されるとともに、ゲーム画面送信手段５２ｃによりユーザの端末装置３へ送信されるものであり、端末装置３の表示部３５に表示される。

　また、助っ人表示領域９３には、「助っ人を呼ぶ」ボタン９３ａ（またはハイパーリンクが設定された文字列等）が表示され、任意の仲間のキャラクタを助っ人として要請できるようになっている。ユーザが「助っ人を呼ぶ」ボタン９３ａを選択することにより、例えば図１６Ｂに示す助っ人選択画面に遷移する。この助っ人選択画面には、ユーザと仲間関係にある仲間ユーザおよび当該仲間ユーザが有するキャラクタ（選手カード）がリストアップされて表示される。なお、画面に表示しきれない情報については、画面をスクロールするまたは助っ人選択画面の２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。

　この助っ人選択画面内にはリストアップされた仲間ユーザ毎の情報表示領域が設けられており、各情報表示領域には、仲間ユーザの名前９４ａ、仲間ユーザのアバター９４ｂ、仲間ユーザが有する選手カード９４ｃ、選手名９４ｄ、当該選手カードの情報（選手カードに設定されているレベルや攻撃力等）９４ｅなどが表示される。図１６Ｂでは、仲間ユーザが有する複数の選手カードのうち、リーダーとして設定されている選手カードを助っ人のキャラクタとして選択可能な例を示している。これに限らず、例えば、エース投手や４番打者として設定されている選手カードなどの代表的なキャラクタを、仲間の助っ人として選択可能としてもよい。そして、ユーザが端末装置３を操作して、例えば仲間ユーザの名前９４ａに設定されたハイパーリンク表示部分を選択することにより、助っ人にしたい仲間のキャラクタを選択できるようになっている。

　例えば、図１６Ｂの助っ人選択画面において、ユーザＡが端末装置３を操作して仲間ユーザＢのキャラクタを助っ人として選択した場合、図１６Ｃに例示するゲーム画面に遷移し、助っ人表示領域９３には、ユーザＢの選手カード９５が助っ人として表示される。また、助っ人表示領域９３には、対戦協力する仲間ユーザのアバターや対戦協力による戦力アップ情報等も併せて表示される。図１６Ｃの画面例では、対戦協力による戦力アップ情報として「攻撃力＋２００」が表示されている。本形態においては、助っ人として選択されたユーザ側の承認は不要であり、ユーザＡは相手の意図を気にすることなく任意に選択できる。

　なお、ユーザが仲間の助っ人を選択すれば、ゲームサーバ１において当該仲間の助っ人の情報を当該ユーザのユーザＩＤと対応付けてデータベースサーバ２（記憶装置）に記憶する。よって、ユーザが仲間の助っ人を選択する操作を行えば、次回の対戦においても、前回選択した仲間のキャラクタが助っ人として設定されるようにすることができる。また、仲間のキャラクタが助っ人として設定されているとき、助っ人表示領域９３には、「助っ人を変更する」ボタン９６（またはハイパーリンクが設定された文字列等）が表示されるようになっている。ユーザがこのボタン９６を選択することにより、図１６Ｂの助っ人選択画面に遷移し、助っ人にしたい仲間のキャラクタを選択し直すことができるようになっている。

　図１６Ａまたは図１６Ｃの対戦モードの画面において、ユーザが「対戦開始」ボタン９７を選択する操作を行うことにより、ユーザの端末装置３からは対戦コマンドがゲームサーバ１へ送信され、ゲームサーバ１において対戦処理が実行される。そして、助っ人表示領域９３に仲間のキャラクタが助っ人として表示されているときに「対戦開始」ボタン９７を選択する操作が行われることにより、対戦コマンドと併せて仲間ユーザに対して対戦協力を要請する情報が、端末装置３からゲームサーバ１に送信される。この場合、仲間ユーザのキャラクタを助っ人としてユーザ側に加担させる対戦協力が実行されることになる。

　なお、交流手段５５が実行する交流処理の対象となる交流は、上述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼に限定されるものではなく、仲間のユーザ同士で行われる様々な交流を含めることができる。交流のその他の例としては、合同練習などがある。合同練習とは、交流の一種であり、ユーザがゲーム内で仮想的に仲間ユーザとともに行う練習である。合同練習を希望するユーザは、仲間ユーザを指定して合同練習を申込み、当該仲間ユーザが所定期間内に（例えば、申込みがあったその日のうちに）ゲームにアクセス（ログイン）した場合に合同練習が成立する。また、交流のその他の例としては、チャットなどの、ユーザ同士がリアルタイムで行うことができる交流もある。チャットの場合、２人または３人以上のユーザの端末装置３において、文字情報（チャットメッセージ）等を交換しあってリアルタイムでコミュニケーションを図ることができる。

　つぎに、交流履歴記憶制御手段５５ｆについて説明する。交流履歴記憶制御手段５５ｆは、各ユーザの交流履歴をデータベースサーバ２（記憶装置）に記憶する。交流手段５５において、ユーザから他のユーザに対しての交流処理が実行されたとき、交流履歴記憶制御手段５５ｆは、交流履歴として、例えば図１７に示すように、交流情報ＩＤ、交流をしたユーザＩＤ、交流相手のユーザＩＤ、交流種別、交流処理実行時の時間情報等を記憶領域に記憶する。交流種別とは、挨拶、メッセージ、プレゼント、対戦協力、合同練習、チャット等の、具体的な交流の内容を示すものである。交流処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。

　なお、この交流履歴記憶制御手段５５ｆにより記憶される情報は、後述する延長手段６１において延長の条件を満たすか否かの判断にも使用される。延長の条件としては、交流回数、交流時間、または交流回数及び交流時間が規定される。ここで、延長の条件として交流時間を含む所定条件が規定される場合には、例えばユーザ同士がリアルタイムで行うことができるチャット等の交流について、ユーザ間の交流時間の情報も、交流履歴記憶制御手段５５ｆにより記憶される。ユーザ間の交流時間の情報としては、例えば、チャット開始時間およびチャット終了時間の情報であってもよいし、チャット開始から終了までの時間の長さの情報であってもよい。ゲームサーバ１は、例えばＣＰＵ１１の内部時計に基づく計時によりユーザ間の交流時間を計時することができる。

　次に、仲間期間設定手段５６について説明する。仲間期間設定手段５６は、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する機能を有する。仲間期間が終了すれば、原則、２人の仲間関係は自動的に解除されることになる。

　ここで、仲間期間設定手段５６が設定する仲間期間の長さとしては、例えば１週間、１０日、２週間、１ヶ月など、任意の期間長さに設定可能である。また、仲間期間の長さは固定であってもよいし、例えば設定時にランダムに期間長さを変えてもよい。さらには、ユーザ間のレベル関係に応じた適切な期間長さを設定するようにしてもよい。

　本実施の形態では、ユーザ間のレベル関係に応じた期間長さを設定する構成の仲間期間設定手段５６について、以下に説明する。

　仲間期間設定手段５６は、仲間申請をしたユーザ（第１のユーザ）および当該仲間申請を承認したユーザ（第２のユーザ）の２人のユーザ間での仲間関係の成立時に、第１のユーザのゲームレベルと第２のユーザのゲームレベルとの関係を含む所定条件に基づいて、仲間期間を設定する機能を有する。

　ここで、仲間期間を決定するために用いられる「ゲームレベル」とは、ユーザのゲームの進行度合い、熟練度、力量等を直接的または間接的に示す指標情報である。このゲームレベルとしては、（ａ）ユーザ自身のレベル、（ｂ）ユーザのゲーム内の所有物のレベル（所有物の例：キャラクタ、キャラクタの集合体であるグループ・チーム・ユニット、アイテム等）、（ｃ）ユーザのゲーム内の所有物の数・所有物の能力値等から算出される値、（ｄ）ユーザが達成したステージのレベルや現在所属しているリーグのレベル、等を挙げることができる。

　前記（ａ）の具体例としては、ユーザがゲームを進行させて経験値を蓄積することによりレベルアップするゲームにおけるユーザのレベルがある。また、前記（ｂ）の具体例としては、ユーザが所有するキャラクタを練習モード、試合モード、育成モード、合成モード等で使用することによりキャラクタの強化・レベルアップを図るゲームにおけるキャラクタのレベルがある。ここで、キャラクタのレベルとは、キャラクタの成長度合い、能力の高さ、強さ等を表す値であればよく、キャラクタの能力値であってもよい。

　また、前記（ｃ）の具体例としては、ユーザがゲームを進行させることによりキャラクタやアイテムを取得するゲームにおいて、ユーザが所有するキャラクタやアイテムの数の多さを評価する値がある。例えば、ユーザが所有する所定の能力値以上のキャラクタ（選手カード）の数をユーザのゲームレベルとすることができる。

　また、前記（ｄ）の具体例としては、ゲーム内にレベル（難易度）の異なる複数のステージが設けられており、１つのステージをクリアしたら１つ難易度の高い別のステージに進むようなゲームにおけるユーザが達成したステージのレベルがある。また、前記（ｄ）の他の具体例としては、ユーザがリーグ戦で上位の成績を獲得することによって、よりレベルの高いリーグに所属できるようなゲームにおける現在所属しているリーグのレベルがある。

　本実施の形態では、仲間期間を決定するために用いられるゲームレベルとして、前記（ａ）ユーザ自身のレベルを適用した例について以下に説明する。

　仲間期間設定手段５６は、仲間申請をした第１のユーザとそれを承認した第２のユーザとのレベル関係を含む所定条件に基づいて仲間期間を決定するのであるが、その例を次に説明する。仲間期間設定手段５６は、第１のユーザよりもゲームレベルが高い第２のユーザが仲間申請を承認した場合に設定する仲間期間を、第１のユーザとゲームレベルが同じ又は第１のユーザよりもゲームレベルが低い第２のユーザが仲間申請を承認した場合に設定する仲間期間よりも短くする。その具体例としては、仲間申請をした第１のユーザのレベルをＬ１、それを承認した第２のユーザのレベルをＬ２とした場合、仲間期間設定手段５６は、Ｌ１＜Ｌ２のときには５日、Ｌ１＝Ｌ２のときには７日、Ｌ１＞Ｌ２のときには１０日の仲間期間とする。なお、仲間期間の日数はこれらに限定されるものではなく、例えばＬ１＜Ｌ２のときには１週間、Ｌ１＝Ｌ２のときには２週間、Ｌ１＞Ｌ２のときには３週間とするなど、任意の期間を設定できる。

　Ｌ１＜Ｌ２の場合とは、第１のユーザよりもゲームレベルが高い第２のユーザが仲間申請を承認した場合である。この場合は、承認した第２のユーザにとって、自分よりも下位レベルのユーザ（即ち、対戦協力等の貢献度の低いユーザ）と仲間になるのであるから、自分が望むような交流等ができない仲間であった場合には短期間で仲間関係を解消したいと希望することが多い。そこで、Ｌ１＝Ｌ２の場合（同レベル間で仲間成立）またはＬ１＞Ｌ２の場合よりも仲間期間を短くしている。

　一方、Ｌ１＞Ｌ２の場合とは、第１のユーザよりもゲームレベルが低い第２のユーザが仲間申請を承認した場合である。この場合は、承認した第２のユーザにとって、自分よりも上位レベルのユーザ（即ち、対戦協力等の貢献度の高いユーザ）と仲間になるのであるから、Ｌ１＝Ｌ２またはＬ１＜Ｌ２の場合よりも仲間関係を長く継続したいと希望することが多い。そこで、Ｌ１＝Ｌ２またはＬ１＜Ｌ２の場合よりも仲間期間を長くしている。

　上記のように、仲間申請を承認した側が申請した側よりも上位レベルであるか否かによって仲間期間を変えることにより、承認した側のユーザの希望に沿った適切な仲間期間の設定が可能となる。このように、仲間申請をした側のユーザではなく、仲間申請を承認した側のユーザからみた適切な仲間期間の設定を行う理由は、次の通りである。すなわち、仲間申請をした側のユーザにとっては、相手のユーザのレベルにかかわらずその相手と仲間になりたいと考えて仲間申請しているはずである。一方、仲間申請を受けたユーザにとっては、それを拒否することもできるが、下位ユーザからの申請だからといって無碍に断れずにその申請を承認してしまい、後で後悔することも従来は多かった。そこで、仲間申請を承認した側のユーザからみた適切な仲間期間の設定を行うのである。

　次に、仲間期間設定手段５６による仲間期間決定処理の他の例を説明する。仲間期間設定手段５６は、仲間関係が成立したユーザ間のレベル差に応じて、仲間期間を設定するようになっている。以下、仲間申請をした第１のユーザのレベルをＬ１、それを承認した第２のユーザのレベルをＬ２、Ｌ１とＬ２との差をレベル差Ｄとして説明を続ける。また、図１８には、レベル差Ｄと仲間期間との関係を表すテーブルを例示している。このテーブルの情報は、ゲームサーバ１の記憶装置（ＲＡＭ１３または補助記憶装置１４等）に記憶されており、仲間期間設定手段５６による処理中に参照される。

　まず、仲間申請した第１のユーザよりもレベルが高い第２のユーザが仲間申請を承認した場合を考える（Ｌ１＜Ｌ２の場合）。この場合、図１８に例示するテーブルに示すように、仲間期間設定手段５６は、レベル差Ｄが大きいほど、仲間期間を段階的に短く設定する。図１８のテーブルの例では、レベル差Ｄが１～９のとき７日、１０～２９のとき６日、３０～４９のとき５日、５０～６９のとき４日、７０～９９のとき３日、１００以上のとき２日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Ｄが大きいほど仲間期間が短くなるという条件を満たせば、任意の期間を設定できる。

　このように、仲間申請した第１のユーザよりもレベルが高い第２のユーザが仲間申請を承認した場合は、承認した第２のユーザにとって、自分よりも下位レベルの第１のユーザとのレベル差Ｄが大きいほど、第１のユーザから受ける対戦協力等による貢献の程度は小さくなる。そこで、この場合には、レベル差Ｄが大きいほど仲間期間を短く設定することにより、承認した第２のユーザにとって望ましい仲間期間の設定を実現しているのである。

　次に、仲間申請した第１のユーザよりもレベルが低い第２のユーザが仲間申請を承認した場合を考える（Ｌ１＞Ｌ２の場合）。この場合、図１８に例示するテーブルに示すように、仲間期間設定手段５６は、レベル差Ｄが大きいほど、仲間期間を段階的に長く設定する。図１８のテーブルの例では、レベル差Ｄが１～９のとき７日、１０～２９のとき８日、３０～４９のとき９日、５０～６９のとき１０日、７０～９９のとき１１日、１００以上のとき１２日に設定される。なお、仲間期間の日数はこれらに限定されるものではなく、レベル差Ｄが大きいほど仲間期間が長くなるという条件を満たせば、任意の期間を設定できる。

　このように、仲間申請した第１のユーザよりもレベルが低い第２のユーザが仲間申請を承認した場合は、承認した第２のユーザにとって、自分よりも上位レベルの第１のユーザとのレベル差Ｄが大きいほど、第１のユーザから受ける対戦協力等による貢献の程度は大きくなる。そこで、この場合には、レベル差Ｄが大きいほど仲間期間を長く設定することにより、承認した第２のユーザにとって有利な仲間期間の設定を実現しているのである。

　また、仲間申請した第１のユーザとそれを承認した第２のユーザのレベルが同じ場合（Ｌ１＝Ｌ２の場合）、図１８に例示するように、仲間期間設定手段５６は、仲間期間を７日に設定する。

　仲間期間設定手段５６は、仲間関係が成立した２人のユーザに対して設定した仲間期間をデータベースサーバ２（記憶装置）に記憶する仲間期間記憶制御手段５６ａを備えている。図１１に、仲間期間記憶制御手段５６ａが記憶領域に記憶する仲間期間の例を示している。仲間期間記憶制御手段５６ａは、仲間情報ＩＤと対応づけて、仲間期間（期間の長さ）および仲間期間終了予定時間等を記憶領域に記憶する。ここで、仲間期間終了予定時間とは、仲間期間の最終時刻にあたる現実世界の時間情報であり、年、月、日、時、分、秒等の時間が記憶される。ここで時間の単位は任意に設定できる。本実施の形態では、仲間期間記憶制御手段５６ａが、仲間期間終了予定時間として、仲間期間の最終時刻にあたる現実世界の日付（年月日）を記憶する例を示す。また、仲間期間記憶制御手段５６ａが、仲間情報ＩＤと対応づけて、仲間期間が設定された日時や仲間関係が成立した日時等の時間情報を併せて記憶してもよい。

　次に、仲間関係解除手段５７について説明する。仲間関係解除手段５７は、仲間関係が成立している２人のユーザに対して設定された仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する機能を有する。ここで、自動的に解除するとは、ユーザによる自主的な解除操作がなくとも、ゲームサーバ１側で仲間関係の解除処理を実行することを意味する。仲間関係解除手段５７は、データベースサーバ２に登録されている図８に示す仲間情報のうち、仲間関係が解除された仲間情報に該当する情報に解除フラグを付加したり当該情報を削除したりすることにより、仲間関係の解除処理を実行する。

　次に、仲間期間報知手段５８について説明する。ユーザは、端末装置３に表示される仲間リスト等の画面で、自分の仲間ユーザとの間に設定されている仲間期間がいつまでなのかを確認できるようになっている。これを実現するために、仲間期間報知手段５８は、仲間期間記憶制御手段５６ａによって記憶されている仲間期間の情報を読み出し、ユーザと仲間ユーザとの間に設定されている仲間期間を表示させるための情報を、当該ユーザの端末装置３へ送信し、ユーザに仲間期間を報知する機能を有する。すなわち、仲間期間報知手段５８は、仲間期間を含む画面データをユーザの端末装置３へ送信して、端末装置３の画面に仲間期間を表示させる制御を行う。

　仲間期間を含む画面の例としては、図１４に示すような仲間リスト画面が挙げられる。仲間リスト画面には、リストアップされた各仲間との間に設定されている仲間期間を表示するための仲間期間表示領域８０が設けられている。

　図１４には、仲間期間表示領域８０に、仲間期間の終了予定日（１／１７まで等）が表示される画面例を示している。なお、仲間期間表示領域８０に表示される仲間期間の情報は、仲間期間の終了予定日に限定されるものではなく、仲間期間の終了予定時間（年、月、日、時、分、秒等の任意の単位の時間情報）としてもよい。あるいは、例えば仲間期間の残日数（あと１０日間等）や残時間（あと２０時間１０分１５秒等）が仲間期間表示領域８０に表示されるようにしてもよい。

　次に、仲間成立ポイント付与手段５９について説明する。仲間成立ポイント付与手段５９は、２人のユーザ間で仲間関係が成立したときに、ボーナスとして当該２人のユーザに所定の仲間成立ポイントを付与する機能を有する。本実施の形態では、仲間成立ポイント付与手段５９が、仲間関係が成立した２人のユーザに、３ポイントずつ仲間成立ポイントを付与するようになっている。例えば、仲間成立ポイントは、上述の行動力ポイントまたは運営コストの最大値を高めるポイントとして利用できるようになっている。仲間関係が成立した２人のユーザに仲間成立ポイントが付与されたことにより、ゲーム情報管理手段５１の所有ポイント記憶制御手段５１ｄが記憶領域に記憶している当該２人のポイントが更新される。

　また、本実施の形態では、２人のユーザに設定されている仲間期間の終了により自動的に仲間関係が解除された場合には、仲間成立ポイントの増減を回避するため、仲間関係成立時に当該２人のユーザに対して付与された仲間成立ポイントと同じポイントがゲーム情報管理手段５１により削減されるようになっている。

　なお、ユーザは、仲間期間の終了を待たずに仲間関係を自主的に解除することも可能である。ユーザが仲間関係を自主的に解除した場合、解除した側のユーザにはペナルティとして仲間関係成立時に付与されたポイント（例えば３ポイント）より多いポイント（例えば５ポイント）が削減されるようにしてもよい。この場合、解除された側のユーザは、仲間関係成立時に付与されたポイントと同じポイントが削減されるようにしてもよい。もっとも、ユーザが仲間関係を自主的に解除した場合であっても、仲間期間の終了により自動的に仲間関係が解除された場合と同様に、仲間関係成立時に付与されたポイントと同じポイントが削減されるようにしてもよい。

　〔ゲームシステムの動作〕
　上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図１９のフローチャートを参照しながら以下に説明する。図１９は、ユーザが端末装置３を操作してゲームサーバ１にアクセスしてゲームサービスを受けるときの、端末装置３およびゲームサーバ１の処理の流れを示すものである。

　ユーザがゲームサービスを受ける場合、先ず、端末装置３の操作入力部４０を操作してウェブブラウザを起動する（Ｓ１１）。その後、ユーザは、ゲームサーバ１が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置３からゲームサーバ１へアクセスリクエストが送信される（Ｓ１２）。このとき、ゲームサーバ１は、端末装置３からのアクセスに対するログイン認証を行い（Ｓ２１）、ゲームサービスの利用登録がなされているユーザからのアクセスであることを確認する。その後、ゲームサーバ１は、ＨＴＭＬ等で記述されたメイン画面データを端末装置３に送信する（Ｓ２２）。なお、メイン画面とは別のトップ画面がある場合は、まずトップ画面を送信してもよい。そして、メイン画面データを受信した端末装置３では、ウェブブラウザが当該データを解釈し、メイン画面を表示部３５に表示させる（Ｓ１３）。

　図１３に例示するように、メイン画面には、ユーザのチーム名７０、ユーザが所有する選手カードの中からリーダーとして選択された選手カード７１の画像、ユーザのゲーム情報７２（ユーザのレベル、行動力ポイント、運営コスト、強化ポイント、交流ポイント、所有する選手カードの数、仲間人数など）が表示される。また、スカウト、オーダー、強化、抽選、試合の各モードを選択するためのボタン群７３なども表示される。さらに、このメイン画面には、端末装置３の方向キーやタッチパネル等を操作して画面をスクロールさせることによって、図示しない各種メニューボタン、仲間の動き情報、他のユーザからのメッセージなど、様々なオブジェクトや情報が表示されるようになっている。

　ここでユーザが、画面に表示されている選択可能なボタン等のオブジェクトやハイパーリンクを選択する操作をすると、当該操作に応じた画面のリクエストが端末装置３からゲームサーバ１へ送信される（Ｓ１４）。このリクエストを受信したゲームサーバ１は、ユーザの操作に応じた演算処理やデータ処理を行ってゲームを実行し（Ｓ２３）、実行結果を反映させたゲーム画面データを端末装置３へ送信する（Ｓ２４）。そして、画面データを受信した端末装置３では、ウェブブラウザが当該データを解釈し、ゲーム画面を表示部３５に表示させる（Ｓ１５）。

　以降は、ユーザの端末装置３においては前記のＳ１４およびＳ１５が繰り返され、ゲームサーバ１においては前記のＳ２３およびＳ２４が繰り返され、これにより、端末装置３の画面に表示されている選択可能なボタン等をユーザが選択する度に、端末装置３のゲーム画面が次々と切り替わり、ゲームを進行させることができる。

　その後、ユーザが端末装置３を操作してゲーム画面を閉じた場合（Ｓ１６）、ゲームサーバ１はログアウト処理を行う（Ｓ２５）。例えば、ユーザがウェブブラウザを閉じた場合、ゲームサーバ１はセッションタイムアウト後にログアウト処理を行う。

　ところで、本ゲームシステムにおいては、ユーザがゲームサーバ１からログアウトした場合であっても、ゲームサーバ１側で当該ユーザのゲーム情報を読み出してゲームを進行させることができる。例えば、ログアウトしているユーザのチームに対して、ログインしている他のユーザが対戦（個別対戦）を仕掛けてくることもある。この場合も、ゲームサーバ１のゲーム進行手段５２は、ユーザがログインしているか否かに依らずに、各ユーザのゲーム情報をデータベースサーバ２から読み出して対戦を実行し、その実行結果を反映させて各ユーザのゲーム情報を更新する。また、リーグ戦モードでは、ユーザによる端末装置３の操作なしに、ゲームサーバ１のゲーム進行手段５２が、各ユーザのゲーム情報をデータベースサーバ２から読み出して、自動でリーグ戦の試合を実行する。このように、ユーザがゲームサーバ１からログアウトしているときに実行された対戦の結果は、その後、ユーザがゲームサーバ１にアクセスしたときに画面で確認することができる。

　〔ゲーム管理装置の動作〕
　次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図２０ないし図２３のフローチャートを参照しながら説明する。図２０は、ある１人のユーザを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している各々のユーザに対して同様の処理が行われる。

　図２０に示すように、ゲームサーバ１の認証手段５３は、ユーザの端末装置３からアクセス要求を受けたとき（Ｓ３１でＹＥＳ）、端末装置３から送信されてきたログインＩＤ・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う（Ｓ３２）。ここで、アクセスを許可しない場合（Ｓ３２でＮＯ）、ゲームサーバ１は、端末装置３にゲームサービスの利用登録を促す画面データを送信する（Ｓ３３）。一方、アクセスを許可する場合（Ｓ３２でＹＥＳ）、アクセス情報（ログ）を記憶する（Ｓ３４）。

　そして、ゲームサーバ１は、アクセスを許可したユーザの端末装置３に、メイン画面データ（またはトップ画面データ）を送信する（Ｓ３５）。その後、ユーザの端末装置３から送信されてくるユーザのゲーム操作に応じた画面リクエストを受信すると（Ｓ３６でＹＥＳ）、ゲーム実行手段５２ａは、当該画面リクエストに応じた演算処理やデータ処理を行ってゲームを実行する（Ｓ３７）。

　その後、ゲームサーバ１はゲームの実行によりユーザのゲーム情報を更新する必要があるか否かを判断し（Ｓ３８）、更新の必要がある場合（Ｓ３８でＹＥＳ）、データベースサーバ２に記憶されているユーザのゲーム情報を更新する（Ｓ３９）。例えば、ユーザのゲーム操作が他のユーザとの個別対戦を行う操作であった場合、当該対戦が実行された結果、試合結果の情報、運営コスト、強化ポイント、アイテム等のユーザのゲーム情報が更新されることになる。一方、例えば、ユーザのゲーム操作がリーグ戦の結果確認の操作であった場合、当該操作に応じたゲームの実行処理としてはリーグ戦の結果情報をデータベースサーバ２から読み出すデータ処理だけであって、当該処理の前後でユーザのゲーム情報に変化はなく、よってユーザのゲーム情報を更新する必要はない（Ｓ３８でＮＯ）。

　その後、ゲーム画面生成手段５２ｂがゲームの実行結果を反映させたゲーム画面データを生成し（Ｓ４０）、ゲーム画面送信手段５２ｃが当該ゲーム画面データをユーザの端末装置３へ送信する（Ｓ４１）。その後、ユーザの端末装置３がログアウトしたか否かが判断され（Ｓ４２）、端末装置３がログアウトするまで、前記Ｓ３６～Ｓ４１の処理が繰り返されることで、ゲームが進行していく。

　次に、図２１ないし図２３を参照して、ゲームサーバ１における仲間期間設定および仲間解除処理について説明する。図２１ないし図２３のフローチャートは、仲間関係が成立したある２人のユーザを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。

　図２１に示すように、第１のユーザから仲間申請を受けた第２のユーザがそれを承認することによって、２人のユーザ間で仲間関係が成立した場合（Ｓ５１でＹＥＳ）、仲間期間設定手段５６が、第１のユーザのレベルと第２のユーザのレベルとの関係を含む所定条件に基づいて仲間期間を決定する（Ｓ５２）。

　このＳ５２の仲間期間決定処理の一例を、図２２に示す。図２２中において、仲間申請をした第１のユーザのレベルをＬ１、それを承認した第２のユーザのレベルをＬ２として表している。仲間期間設定手段５６は、Ｌ１＜Ｌ２のとき（Ｓ６１でＹＥＳ）、仲間期間を５日とする（Ｓ６２）。また、仲間期間設定手段５６は、Ｌ１＞Ｌ２のとき（Ｓ６１でＮＯおよびＳ６３でＹＥＳ）、仲間期間を１０日とする（Ｓ６４）。また、仲間期間設定手段５６は、Ｌ１＝Ｌ２のとき（Ｓ６１でＮＯおよびＳ６３でＮＯ）、仲間期間を７日とする（Ｓ６５）。

　図２１のＳ５２の仲間期間決定処理の他の例を、図２３に示す。仲間期間設定手段５６は、仲間申請をした第１のユーザのレベルＬ１と、それを承認した第２のユーザのレベルＬ２との差であるレベル差Ｄを算出する（Ｓ７１）。そして、仲間期間設定手段５６は、Ｌ１＜Ｌ２のとき（Ｓ７２でＹＥＳ）、レベル差Ｄが大きいほど仲間期間を短くする（Ｓ７３）。例えば、図１８に例示するテーブルを参照し、レベル差Ｄに応じた仲間期間（Ｌ１＜Ｌ２の場合）を取得する。また、仲間期間設定手段５６は、Ｌ１＞Ｌ２のとき（Ｓ７２でＮＯおよびＳ７４でＹＥＳ）、レベル差Ｄが大きいほど仲間期間を長くする（Ｓ７５）。例えば、図１８に例示するテーブルを参照し、レベル差Ｄに応じた仲間期間（Ｌ１＞Ｌ２の場合）を取得する。また、仲間期間設定手段５６は、Ｌ１＝Ｌ２のとき（Ｓ７２でＮＯおよびＳ７４でＮＯ）、仲間期間を７日とする（Ｓ７６）。

　図２１に戻って説明を続けると、仲間期間設定手段５６は、上記のように仲間関係成立時に決定した仲間期間を、第１のユーザおよび第２のユーザに対して設定する（Ｓ５３）。例えば、仲間期間設定手段５６は、図１１に示すように、仲間関係が成立している２人のユーザを関係付けた仲間情報と対応付けて、仲間期間を記憶する。

　その後、仲間関係が成立している２人のユーザに設定された仲間期間が終了した場合（Ｓ５４でＹＥＳ）、仲間関係解除手段５７は、当該２人のユーザの仲間関係を自動的に解除する（Ｓ５５）。例えば、仲間関係解除手段５７は、データベースサーバ２に登録されている２人の仲間情報に解除フラグを付加することにより、仲間関係の解除処理を実行する。

　その後、ゲームサーバ１は、仲間関係が解除された２人のユーザの端末装置３に対して、仲間関係が解除された旨を報知するための情報（解除の旨を含む画面データ等）を送信し、当該２人のユーザに仲間関係が解除されたことを報知する（Ｓ５６）。報知の例としては、ゲーム画面の中に仲間関係が解除された旨を表示することの他に、音声による報知や画面表示と音声とを併用した報知も考えられる。音声による報知は、ゲームサーバ１からユーザの端末装置３へ送信する画面データ（ＨＴＭＬデータ等）に音声データを含ませることにより実現できる。なお、ゲームサーバ１が、仲間関係が解除されたことを報知するためには、ユーザの端末装置３がゲームサーバ１にアクセスしている必要がある。よって、ゲームサーバ１は、Ｓ５５の仲間関係の解除処理を実行した後、仲間関係が解除された各ユーザの端末装置３がゲームサーバ１に最初にアクセスしたときに、Ｓ５６の報知処理を実行することになる。

　次に、仲間期間設定手段５６が、仲間関係が成立した２人のユーザ間のレベル差に応じて仲間期間を設定する構成において、仲間期間中にレベル差が変動した場合に、変動後のレベル差に応じた仲間期間に再設定する構成について説明する。ここでは、図１８に示すテーブルに基づいて、仲間期間設定手段５６がユーザ間のレベル差に応じた仲間期間を設定する場合を例に挙げて説明する。

　図２４に示すように、ゲームサーバ１は、レベル差記憶制御手段６０を備えている。このレベル差記憶制御手段６０は、仲間期間設定時（再設定時を含む）における、仲間申請した第１のユーザのレベルＬ１とそれを承認した第２のユーザのレベルＬ２との差であるレベル差を、データベースサーバ２（記憶装置）に記憶する機能を有する。例えば、図２５Ａに示すように、レベル差記憶制御手段６０は、両ユーザの仲間情報を一意に示す仲間情報ＩＤと対応付けて、仲間期間設定時のユーザ間のレベル差を記憶装置に記憶するようになっている。この例では、レベル差をＬ１－Ｌ２として算出し、Ｌ１＞Ｌ２のときのレベル差はプラスの値、Ｌ１＜Ｌ２のときのレベル差はマイナスの値として管理できるようにしている。このレベル差記憶制御手段６０は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

　そして、仲間期間設定手段５６は、仲間期間中のユーザ間のレベル差が、レベル差記憶制御手段６０によって記憶されている仲間期間設定時におけるレベル差から変動した場合に、変動後のレベル差に応じて仲間期間を再設定する機能を有する。この仲間期間の再設定処理について、図２６のフローチャートを参照しながら以下に説明する。なお、既出のフローチャートにおいて示したステップと同様のステップについては同一のステップ番号を付し、詳細な説明を省略する（以降のフローチャートにおいても同様である）。

　仲間期間設定手段５６が仲間関係成立時に２人のユーザに対して仲間期間を設定した場合（Ｓ１０１でＹＥＳ）、レベル差記憶制御手段６０が仲間期間設定時におけるユーザ間のレベル差を記憶装置に記憶する（Ｓ１０２）。

　その後、仲間期間設定手段５６は、仲間期間中に（Ｓ１０３でＮＯ）、少なくとも一方のユーザのレベルが変化することによりユーザ間のレベル差の変動を検出した場合（Ｓ１０４でＹＥＳ）、変動後のレベル差に応じて仲間期間の再設定の必要性を判断する（Ｓ１０５）。すなわち、図１８に示すテーブルに基づいて取得した変動後のレベル差に応じた仲間期間が、仲間期間設定時における仲間期間から変化しているか否かを判断する。具体例を挙げると、仲間成立時において、仲間申請したユーザのレベルＬ１が３０であり、それを承認したユーザのレベルＬ２が５７であったとする。よって、図２５Ａの仲間情報ＩＤ＝“２０”に示すように、ユーザ間のレベル差－２７（＝３０－５７）に応じた仲間期間として６日が設定されたとする。その後、仲間期間中に、承認した側のユーザのレベルＬ２が１つ向上して５８になり、ユーザ間のレベル差が－２８になっても、図１８のテーブルに基づけば、Ｌ１＜Ｌ２の場合、レベル差が１０～２９の範囲では仲間期間は６日のままであることから、仲間期間の再設定の必要性はないことになる。例えば、仲間期間中にレベル差が－３０になった場合、図１８のテーブルに基づけば、変動後のレベル差に応じた仲間期間は５日になり、仲間期間を再設定する必要性が生じる。

　仲間期間の再設定が必要である場合（Ｓ１０５でＹＥＳ）、仲間期間設定手段５６は、変動後のレベル差に応じた仲間期間を再設定する（Ｓ１０６）。例えば、図２５Ａに示す仲間情報ＩＤ＝“２０”の仲間期間および仲間期間終了予定時間を、図２５Ｂに示す情報に更新する。すなわち、仲間期間設定手段５６は、データベースサーバ２に記憶している仲間期間を、６日から５日に短縮し、それに伴って仲間期間終了予定時間も１日早くする（１１／１／１０から１１／１／９へ更新する）。

　上記では、再設定された仲間期間が元の期間よりも短くなる例を示したが、当然、再設定された仲間期間が元の期間よりも長くなる場合もある。仲間期間の再設定が実行されたときは、Ｓ１０２に戻って、レベル差記憶制御手段６０が再設定時におけるユーザ間のレベル差を記憶装置に記憶（更新）する。

　なお、仲間期間が終了した場合は（Ｓ１０３でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ５５）、仲間関係が解除されたことが２人のユーザの端末装置３に報知される（Ｓ５６）。

　このように、ユーザ間のレベル差に応じて適切な仲間期間を設定した後、その仲間期間中にユーザ間のレベル差が変動した場合、変動後のレベル差に応じた仲間期間に再設定することにより、仲間期間設定後のユーザ間のレベル差変動に追従した適切な仲間期間の調整を実現できる。

　以上のように、本実施の形態では、２人のユーザ間での仲間関係の成立時に仲間期間を設定し、仲間期間の終了により、原則的に、当該２人のユーザの仲間関係を自動的に解除するようになっている。これにより、例えば、下位レベルのユーザからの仲間申請を承認して仲間になっても、仲間になった時点で仲間期間が設定されるので、ユーザは、心理的にも行い難い仲間解除の操作をすることなく、仲間期間の終了により仲間関係の解除が可能となる。そして、ユーザは、仲間関係の成立から仲間期間の終了までの間に、相手との交流の程度等から判断して仲間関係を継続すべきかどうかを判断することができる。そして、仲間関係を継続したいと思うような相手であれば、例えば、仲間期間終了後に改めて仲間申請を行う等の所定の操作をして仲間関係を継続すればよい。

　すなわち、仲間関係成立時に設定される仲間期間をお試し期間として捉えて、例えば自分より下位レベルのユーザから仲間申請を受けたような場合でも、これを積極的に承諾して試しに仲間になり、仲間期間終了までに自分が望むような交流等ができる相手かどうかを検討することも可能となる。

　また、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームにおいて、ユーザの仲間数が上限に達していた場合でも、仲間期間終了に伴う仲間関係の自動解除により、上限までに余裕ができる。すなわち、仲間数が一旦上限まで達したユーザであっても、従来のように実質的に仲間が固定された状態に陥ることはなく、他のユーザと新たな仲間関係を構築するための機会が与えられる。

　そして、ユーザは、仲間期間中に交流が持てなかった下位レベルのユーザとは、自動解除された仲間関係を終え、再度、仲間申請や承認をしたりすることはないと考えられる。その一方、ユーザが望むような相手（上位レベルのユーザや楽しく交流が持てるようなユーザ）とは、仲間関係を継続するために、再度、仲間申請や承認等の操作をすることが考えられる。よって、本実施の形態の構成により、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、を繰り返しながら、ユーザの好むような仲間グループの構成に収束されていく環境が整えられる。したがって、ユーザが、あまり交流のない下位レベルの仲間ユーザを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。

　特に、仲間数に上限が設定されているゲームの場合、従来では、比較的レベルの高いユーザが、あまり交流のない下位レベルの仲間を何人も抱えた状態で仲間数が上限まで達し、仲間が固定されてしまうことが多かった。これに対し、本ゲームサーバ１を適用した場合、仲間数に上限が設定されているゲームであっても、他のユーザと新たな仲間関係を構築し易すい環境がユーザに提供されるので、継続的に新たな仲間との交流を楽しめるようになる。よって、長期間にわたりゲームを継続しても、ゲームに対するマンネリ感が発生しにくい。

　ところで、上述のように、仲間期間の終了により仲間関係が解除されても、ユーザが仲間関係を継続したい相手については、仲間関係を継続するための所定の操作をすれば、仲間関係を継続することができる。仲間関係解除後の操作としては、過去の仲間に対する再度の仲間申請（これを「仲間復活申請」と呼称する）がある。以下に、この仲間復活申請を容易に行うことができる構成について説明する。

　図２７に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４または図２４に示した各手段に加えて、仲間履歴送信手段１０１および仲間復活申請手段１０２をさらに備えている。これらの手段１０１および１０２は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

　図２７に示すゲームサーバ１の仲間情報記憶制御手段５４ａは、仲間関係成立中の２人のユーザを関係付けた仲間情報を記憶領域に記憶するとともに、当該２人の仲間関係が解除された後も、当該２人のユーザを関係付けた過去の仲間情報を保持する。例えば、図２８に示すように、仲間情報記憶制御手段５４ａは、仲間関係が解除された２人の仲間情報に、仲間解除フラグを立てて、過去の仲間情報として記憶領域に保持するようになっている。図２８の例では、仲間解除フラグとして“１”が設定されている仲間情報が過去の仲間情報であり、仲間解除フラグが“０”の仲間情報が現在成立中の仲間情報である。

　仲間履歴送信手段１０１は、ユーザが操作する端末装置３からの要求に応じて、仲間情報記憶制御手段５４ａによって記憶されている当該ユーザの過去の仲間情報を読み出し、当該ユーザと過去に仲間関係にあった過去の仲間ユーザを表示させるための情報を当該端末装置３へ送信する機能を有する。

　例えば、ユーザが端末装置３を操作してメイン画面中の「過去の仲間リスト」ボタンを選択すれば、端末装置３から過去の仲間リスト要求がゲームサーバ１へ送信される。仲間履歴送信手段１０１は、ユーザの端末装置３からこの要求を受信して、当該ユーザの過去の仲間リストを表示させる情報（過去の仲間リストの画面データ）を端末装置３へ送信する。仲間履歴送信手段１０１が送信した情報を受信した端末装置３には、例えば図２９に示すような過去の仲間リスト画面が表示される。この過去の仲間リスト画面には、ユーザと過去に仲間関係にあった仲間ユーザの情報がリストアップされて表示される。なお、画面に表示しきれない過去の仲間ユーザの情報については、画面をスクロールするまたはリストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。

　この過去の仲間リスト画面内には、リストアップされた過去の仲間ユーザ毎の情報表示領域が設けられており、各情報表示領域には、過去の仲間ユーザの現在のゲーム情報２０１（ユーザ名、チーム名、ユーザのレベル、仲間の人数、所属リーグのレベル等）、当該ユーザの分身的なキャラクタであるアバター２０２、当該ユーザが所有するリーダーの選手カード２０３などとともに、復活申請ボタン２０４というオブジェクトも表示される。そして、ユーザが仲間関係を復活させたい過去の仲間ユーザの復活申請ボタン２０４を選択する操作を行うことにより、当該操作の情報が端末装置３からゲームサーバ１へと送信される。この操作の情報をユーザの端末装置３から受信した仲間復活申請手段１０２は、当該ユーザから選択された過去の仲間ユーザへの仲間関係復活の申請処理を実行するようになっている。

　図３１には、仲間復活申請を管理するための記憶情報の一例を示している。仲間関係復活の申請処理を実行する仲間復活申請手段１０２は、図３１に例示するように、仲間情報を管理するための仲間情報ＩＤと対応づけて、復活申請をしたユーザのユーザＩＤをデータベースサーバ２に登録する。図３１における仲間情報ＩＤ＝“１”の例では、ユーザＩＤ＝“０００００１”のユーザＡが復活申請した例を示している。そして、仲間復活申請手段１０２は、申請相手の過去の仲間ユーザＢの端末装置３に対して、ユーザＡから復活申請があったことを表示させるための情報を送信する。なお、この送信は、ユーザＡが復活申請をした後、過去の仲間ユーザＢの端末装置３がゲームサーバ１に最初にアクセスしたときに行われる。

　仲間復活申請手段１０２が送信した情報を受信した過去の仲間ユーザＢの端末装置３では、例えば、図３０に示すような承認・拒否選択画面が表示される。この画面には、仲間復活申請をしたユーザＡの現在のゲーム情報２１１（ユーザ名、チーム名、ユーザのレベル、仲間の人数、所属リーグのレベル等）、当該ユーザのアバター２１２、当該ユーザが所有するリーダーの選手カード２１３などとともに、承認ボタン２１４、拒否ボタン２１５というオブジェクトも表示される。ここで、拒否ボタン２１５を選択することにより、仲間関係の復活を拒否することもできる。一方、ユーザＢがユーザＡとの仲間関係の復活を承認する場合、承認ボタン２１４を選択する操作を行うことにより、当該操作の情報がユーザＢの端末装置３からゲームサーバ１へと送信される。この操作の情報を受信したゲームサーバ１の仲間管理手段５４は、ユーザＢからの承認を受け付け、仲間関係復活処理を実行するようになっている。

　仲間関係復活処理を実行する仲間管理手段５４は、例えば図３１に示すように、仲間情報を管理するための仲間情報ＩＤと対応づけて記憶されている仲間解除フラグを“０”に設定する（図３１中の仲間情報ＩＤ＝“２２”を参照）。また、このとき、復活承認したユーザのユーザＩＤおよび仲間関係の復活時間（復活日等）の情報を併せてデータベースサーバ２に記憶していてもよい。

　上記のようにして仲間関係の復活により、再度、仲間関係が成立した場合、改めて仲間期間設定手段５６により仲間期間が設定されることになる。すなわち、仲間期間設定手段５６は、仲間復活申請をしたユーザ（第１のユーザ）および当該仲間復活申請を承認したユーザ（第２のユーザ）の２人のユーザ間での仲間関係の成立時に、第１のユーザのゲームレベルと第２のユーザのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定し、当該２人のユーザに対して仲間期間を設定するのである。

　２人のユーザ間で上記のようにして仲間関係が復活した場合、初めて仲間関係が成立した場合よりも、当該２人のユーザは仲間関係の継続を望んでいる可能性が高い。そこで、仲間期間設定手段５６は、申請した第１のユーザとそれを承認した第２のユーザとのレベル関係の条件が同じであれば、復活により仲間関係が成立した場合の仲間期間を、初めて仲間関係が成立した場合の仲間期間よりも長くすることが望ましい。例えば、２人のユーザのレベル関係に基づいて、初めて仲間関係が成立した場合の仲間期間が５日間に設定されるのであれば、同じレベル関係の条件で復活により仲間関係が成立した場合には、仲間期間が前記の２倍の１０日間に設定されようにする。

　また、仲間期間設定手段５６は、申請した第１のユーザとそれを承認した第２のユーザとのレベル関係の条件が同じであれば、仲間関係復活の回数が多い程、仲間期間をより長く設定することが望ましい。

　また、仲間関係の復活を何度も繰り返しているユーザ同士は、仲間関係が自動的に解除されることを望んでいない可能性が極めて高いと考えられる。そこで、仲間期間設定手段５６は、所定回数以上（例えば３回以上）、仲間関係の復活が実行された２人のユーザについては、仲間期間を設定しない（または、仲間期間を無制限とする）ことが望ましい。

　上記のように、仲間期間の終了後において仲間関係の復帰申請を行う場合の他に、仲間期間中に仲間関係の継続申請を行うことによって、仲間関係再構築の予約を可能とし、仲間期間の終了と同時に仲間期間が再度設定されるようにすることも可能である。以下に、この仲間継続申請を容易に行うことができる構成について説明する。

　図３２に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１～５９に加えて、仲間継続申請手段１１０をさらに備えている。この手段１１０は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

　例えば、ユーザが端末装置３を操作してメイン画面中の「仲間リスト」ボタンを選択すれば、ゲームサーバ１からは、図３３に示すような仲間リスト画面のデータが送られてくる。この仲間リスト画面には、リストアップされた仲間ユーザ毎の情報表示領域が設けられており、仲間期間表示領域８０、仲間ユーザのゲーム情報８１、アバター８２、選手カード８３などとともに、継続申請ボタン２２０というオブジェクトも表示される。そして、ユーザが、仲間関係を継続させたい仲間ユーザに対応した継続申請ボタン２２０を選択する操作を行うことにより、当該操作の情報が端末装置３からゲームサーバ１へと送信される。この操作の情報をユーザの端末装置３から受信した仲間継続申請手段１１０は、当該ユーザから選択された仲間ユーザへの仲間関係継続の申請処理を実行するようになっている。

　図３４には、仲間継続申請を管理するための記憶情報の一例を示している。仲間関係継続の申請処理を実行する仲間継続申請手段１１０は、図３４に例示するように、仲間情報を一意に識別する仲間情報ＩＤと対応づけて、継続申請をしたユーザのユーザＩＤをデータベースサーバ２に登録する。図３４における仲間情報ＩＤ＝“１”の例では、ユーザＩＤ＝“０００００１”のユーザＡが継続申請した例を示している。そして、仲間継続申請手段１１０は、申請相手の仲間ユーザＢの端末装置３に対して、ユーザＡから継続申請があったことを表示させるための情報を送信する。なお、この送信は、ユーザＡが継続申請をした後、仲間ユーザＢの端末装置３がゲームサーバ１に最初にアクセスしたときに行われる。

　仲間継続申請手段１１０が送信した情報を受信した仲間ユーザＢの端末装置３では、例えば図３０と同様の承認・拒否選択画面が表示される。ここで、ユーザＢがユーザＡとの仲間関係の継続を承認する操作を行うことにより、当該操作の情報がユーザＢの端末装置３からゲームサーバ１へと送信される。この操作の情報を受信したゲームサーバ１の仲間管理手段５４は、ユーザＢからの承認を受け付け、仲間関係継続処理を実行するようになっている。

　仲間関係継続処理を実行する仲間管理手段５４は、例えば図３４に示すように、仲間情報を管理するための仲間情報ＩＤと対応づけて記憶されている継続フラグを“１”に設定する（図３４中の仲間情報ＩＤ＝“２２”を参照）。また、このとき、継続承認したユーザのユーザＩＤの情報を併せてデータベースサーバ２に記憶していてもよい。

　上記のようにして仲間関係の継続が成立した場合、図３３に例示するように、仲間リスト画面には、継続申請ボタン２２０に代えて「継続成立」のステータス２２１が表示される。なお、継続申請後、相手から承認が得られていない場合には、「継続申請中」等のステータス２２１が表示され、相手から継続申請を受けているが未だ承認していない場合には、「継続承認未」等のステータス２２１が表示される。

　また、仲間関係の継続が成立している場合、仲間管理手段５４は、仲間期間の終了と同時に、仲間関係を復活させることになるとともに、仲間期間設定手段５６が、仲間期間を再度設定することになる。すなわち、仲間期間設定手段５６は、仲間継続申請をしたユーザ（第１のユーザ）および当該仲間継続申請を承認したユーザ（第２のユーザ）の２人のユーザ間での仲間関係の継続が成立した場合、第１のユーザのゲームレベルと第２のユーザのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定し、当該２人のユーザに対して仲間期間を設定するのである。

　上記のようにして仲間期間中に仲間継続申請およびその承認の操作を行うことにより、ブランク期間を作ることなく、仲間関係を継続することができるようになる。

　ところで、上記のような仲間復活申請や仲間継続申請のような操作をユーザが行うことなく、仲間関係を継続できるようにする構成について、以下に説明する。

　〔ゲーム管理装置の他の構成例〕
　ゲーム管理装置の他の構成例を、図３５の機能ブロック図を参照しながら説明する。なお、既出の図面において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１～５９に加えて、延長手段６１をさらに備えている。この延長手段６１は、仲間期間が設定されている２人のユーザの少なくとも一方から相手のユーザに対して、仲間期間が終了するまでに「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流処理が実行された場合に、当該仲間期間を延長する機能を有する。この延長手段６１は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

　仲間になったユーザ間で交流が持たれないということは、お互いに相手への関心が希薄であると考えられる。一方、仲間同士で交流を行っている場合には、ユーザが仲間関係の維持を望んでいる可能性が高いと考えられる。そこで、仲間期間が終了するまでに条件を満たす交流があった場合に、仲間期間を自動的に延長し、仲間関係が継続されるようにするのである。

　そして、延長手段６１は、仲間期間が延長された２人のユーザの少なくとも一方から相手のユーザに対して、延長された仲間期間が終了するまでに「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流処理が実行される毎に、仲間期間を延長することを繰り返すようになっている。これにより、条件を満たす交流を継続的に行っている仲間同士については、仲間期間の自動延長が繰り返されることにより仲間関係が継続して維持される。

　また、２人のユーザの少なくとも一方から相手のユーザに対して「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流があったことを、延長の条件とする。この条件を満たす形態には、いずれか一方から相手に対して「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流があれば条件を満たすとする形態と、両者とも互いに相手に対して「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流を行うことを条件とする形態とを含む。何れの形態を延長の条件として設定してもよい。特に、従来の課題であるところの、上位レベルのユーザにとって、仲間のユーザのレベルが自分よりも低い場合に、ゲームにおける協力対戦等について不公平感が生じていたということをより積極的に解消するために、少なくとも下位レベルのユーザが上位レベルのユーザに対して、「所定回数」、「所定時間」、または「所定回数及び所定時間」の交流を行うことを条件とすることが望ましい。

　延長の対象となる交流については、前述の挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習、チャットなど、仲間のユーザ同士で行われる様々な交流を含めることができる。また、挨拶は延長の対象とはせず、メッセージの送信、プレゼント、協力対戦の助っ人依頼、合同練習、チャットのみを延長の対象とするといったように、ゲーム内に用意された複数の交流から一部の交流のみを延長の対象としてもよい。

　延長の条件に関しては、「所定回数」、「所定時間」、または「所定回数及び所定時間」の何れの条件を満たす交流が行われたことを延長の条件としてもよい。挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、チャット等の全ての交流については、これらの交流が「所定回数」行われたことを延長の条件とすることができる。また、チャット等の、ユーザ同士がリアルタイムで行うような交流については、「所定時間」の交流が行われたことを延長の条件としたり、「所定回数及び所定時間」の交流が行われたことを延長の条件としたりすることができる。また、挨拶等の交流およびチャット等の交流を含む様々な交流が可能なゲームについては、「所定回数」、「所定時間」、または「所定回数及び所定時間」の何れを延長の条件としてもよい。

　ここで、仲間期間が終了するまでに「所定回数」の交流処理が実行されたことを延長の条件とする場合、「所定回数」として任意の回数を設定可能である。例えば、この所定回数を１回としてもよいし、２回以上の複数回としてもよい。また、仲間期間が終了するまでに「所定時間」の交流が行われたことを延長の条件とする場合、「所定時間」として例えば５分、１０分、３０分、または１時間等、任意の時間を設定可能である。また、仲間期間が終了するまでに「所定回数及び所定時間」の交流が行われたことを延長の条件とする場合、例えば３回および１０分、２回および１５分等、任意の回数および時間を設定可能である。

　なお、本実施の形態においては、仲間期間が終了するまでに「所定回数」の交流が行われたことを延長の条件とする形態を例に挙げて、以下の説明を続ける。

　相対的にゲームレベルが低いユーザから相手のユーザに対して交流処理が実行される場合の所定回数Ｎ１は、相対的にゲームレベルが高いユーザから相手のユーザに対して交流処理が実行される場合の所定回数Ｎ２よりも多い設定とすることが望ましい。一例としては、前記所定回数Ｎ１を３回とし、前記所定回数Ｎ２を２回とする。そして、いずれか一方から相手に対して前記所定回数の交流があれば延長条件を満たすものとする。または、両者とも互いに相手に対して前記所定回数の交流があれば延長条件を満たすものとする。

　この構成によれば、レベルの異なる２人のユーザが仲間になった場合、下位レベルのユーザは上位レベルのユーザとの仲間関係を維持するためには、上位レベルのユーザよりも多くの回数の交流を必要とする。よって、上位レベルのユーザは、下位レベルのユーザとの仲間関係を終了させ易くなることから、自分好みの仲間グループをより構築し易くなる。

　また、延長手段６１が、ユーザ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成としてもよい。この場合、相対的にゲームレベルが低いユーザから相手のユーザに対して交流処理が実行される場合の所定回数Ｎ１を、両ユーザ間のレベル差Ｄが大きいほど多い設定とすることが望ましい。一例としては、レベル差Ｄが２９以下であれば所定回数Ｎ１を３回、レベル差Ｄが３０～６９であれば所定回数Ｎ１を４回、レベル差Ｄが７０～９９であれば所定回数Ｎ１を５回、レベル差Ｄが１００以上であれば所定回数Ｎ１を６回とする。これにより、下位レベルのユーザは上位レベルのユーザとのレベル差が大きいほど、仲間関係を維持するために多くの回数の交流を必要とする。よって、上位レベルのユーザにとっては、レベルが離れた下位レベルのユーザほど仲間関係を終了させ易くなる。

　逆に、相対的にゲームレベルが高いユーザから相手のユーザに対して交流処理が実行される場合の所定回数Ｎ２を、両ユーザ間のレベル差が大きいほど少ない設定としてもよい。一例としては、レベル差Ｄが２９以下であれば所定回数Ｎ２を３回、レベル差Ｄが３０～６９であれば所定回数Ｎ２を２回、レベル差Ｄが７０以上であれば所定回数Ｎ２を１回とする。これにより、上位レベルのユーザから下位レベルのユーザへ交流を行なうのであれば、レベル差が大きいほど少ない回数の交流で仲間関係を容易に維持できるようになる。

　上記のように、延長手段６１がユーザ間のレベル差に応じて延長の条件を満たすための交流の所定回数を設定する構成において、延長手段６１がユーザ間のレベル差の変動を検出したとき、変動後のレベル差に応じた所定回数に再設定するようにしてもよい。これにより、ユーザ間のレベル差変動に追従して、延長の条件を満たすための交流の所定回数を適切に調整することができる。

　ここで、延長手段６１が延長する期間の長さについては、一定の期間とすることができる。延長期間の長さを一定期間とする場合、例えば、１週間、１０日間、２週間等、任意の期間を設定可能である。なお、延長の期間の長さは一定期間に限定されるものではない。例えば、延長が行われる毎にランダムに延長の期間を決定してもよい。また、交流回数によって延長の期間を変動させる（交流回数が多いほど延長の期間を長く設定する）構成であってもよい。あるいは、仲間期間設定手段５６がユーザ間のレベル差に基づいて決定した仲間期間（仲間期間記憶制御手段５６ａが記憶領域に記憶している仲間期間）と同じ期間を、延長手段６１が延長の期間として設定してもよい。

　あるいは、延長手段６１が延長処理を実行するときのユーザ間のレベル差に基づいて、延長の期間を設定する構成にすることもできる。例えば、図１８に例示したユーザ間のレベル差と仲間期間との関係を表すテーブルを、ユーザ間のレベル差と延長の期間との関係を表すテーブルとして援用（または共用）し、延長処理実行時のユーザ間のレベル差に応じた延長の期間を、当該テーブルに基づいて取得するようにする。もちろん、ユーザ間のレベル差と延長の期間との関係を表す専用のテーブルを別途用意して、ゲームサーバ１の記憶装置（ＲＡＭ１３または補助記憶装置１４等）に記憶しておいてもよい。この構成の場合、延長処理が実行される毎に、その都度、延長処理実行時のユーザ間のレベル差に基づいた適切な延長の期間を設定することができる。

　また、延長手段６１が延長処理実行時のユーザ間のレベル差に基づいて、延長の期間を設定する構成において、延長手段６１がユーザ間のレベル差の変動を検出したとき、変動後のレベル差に応じた延長の期間に再設定するようにしてもよい。これにより、ユーザ間のレベル差変動に追従して、延長の期間を適切に調整することができる。

　延長手段６１による延長処理の実行は、データベースサーバ２に記憶されている仲間期間の情報を、延長後の情報に更新する等により行うことができる。例えば、延長手段６１は、図３６に示すように、仲間期間記憶制御手段５６ａが記憶仲間情報ＩＤと対応づけて記憶領域に記憶している仲間期間終了予定時間を、延長後の日付に更新することにより、延長処理を実行する。このとき、仲間情報ＩＤと対応づけて、延長処理実行時の時間情報として仲間期間を延長した日等を併せて記憶する。延長処理実行時の時間情報としては、年、月、日、時、分、秒等の時間情報を記憶するが、ここで記憶する時間の単位は任意に設定できる。また、延長された仲間期間の情報管理のために、仲間情報ＩＤと対応づけて、延長フラグを設定するようにしてもよい。

　延長手段６１による処理形態の１つとしては、仲間期間の途中で延長条件を満たす毎に、仲間期間の延長処理を実行する形態がある。この形態の延長処理について、図３７を参照して、以下に説明する。なお、図３７およびそれ以降のフローチャートは、仲間関係にある２人のユーザを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している全ての仲間同士のペアに対して同様の処理が行われることになる。

　図３７に示すように、延長手段６１は、２人のユーザに設定された仲間期間が終了する前に（Ｓ８１でＮＯ）、交流に関する延長条件が達成されたか否かを判定する（Ｓ８２）。例えば、この判定は、図３６に示す仲間期間の情報（仲間期間終了予定時間等）、および図１７に示すユーザの交流履歴の情報に基づいて行うことができる。すなわち、データベースサーバ２には、各ユーザの交流履歴が記憶されているので、仲間期間が設定されてから仲間期間が終了するまでに（または、仲間期間が延長されてから延長された仲間期間が終了するまでに）、延長条件として定められた所定回数の交流をユーザが行った状態を検出可能である。

　交流に関する延長条件が達成された場合（Ｓ８２でＹＥＳ）、延長手段６１は、仲間期間の延長処理を実行する（Ｓ８３）。例えば、図３６に示す仲間期間終了予定時間を、延長後の日付に更新する。このとき、延長処理実行時の時間情報を記憶（または更新）する。

　ここで、具体的な延長例を挙げる。１月１日に設定された仲間期間が例えば７日間（１月７日まで）であり、３日目の１月３日に交流の延長条件が達成された場合、１月３日の時点で例えば７日間の延長が発生し、仲間期間の終了日は１月７日（現終了日）から７日後の１月１４日になる。よって、１月３日の時点での仲間期間の残期間（残日数）は１１日間になる。例えば、その後、１月６日に交流の延長条件が再度達成された場合、１月６日の時点で７日間の追加延長が発生し、仲間期間の終了日は１月１４日（現終了日）から７日後の１月２１日になる。よって、１月６日の時点での仲間期間の残期間は１７日間になる。

　この延長例の場合、交流に関する延長条件が連続して早期に達成されると、仲間期間の残期間は増加する傾向にある。例えば、短期間に多数の交流を行って仲間期間の残期間が急激に増加した場合を考えると、その後交流が長期間途絶えた場合でも、仲間関係が長期間維持されることになる。そこで、仲間期間の残期間に上限を設けてもよい。例えば、仲間期間の残期間の上限を３０日に設定すれば、３０日以上交流に関する延長条件が満たされなければ、仲間期間は終了してしまう。よって、仲間関係を維持するためには、最長３０日の期間以内に交流に関する延長条件を満たすことが必要となり、長期間交流が途絶えているのに仲間関係が維持されることを回避できる。

　そこで、Ｓ８３の後、延長手段６１は、仲間期間の残期間が上限を超えている場合（Ｓ８４でＹＥＳ）、仲間期間の残期間を上限に制限する（Ｓ８５）。すなわち、図３６に示す仲間期間終了予定時間を、仲間期間の残期間の上限に合致する日付に更新する。

　延長後の仲間期間の残期間が上限を超えていない場合（Ｓ８４でＮＯ）、または仲間期間の残期間を上限に制限した後（Ｓ８５）、Ｓ８１に戻り、以降、仲間期間が終了するまでＳ８１～Ｓ８５の処理が繰り返される。

　ここで、他の具体的な延長例を挙げる。１月１日に設定された仲間期間が例えば７日間（１月７日まで）であり、３日目の１月３日に交流の延長条件が達成された場合、１月３日の時点で例えば７日間の延長が発生するのであるが、仲間期間の終了日は１月３日（延長発生日）から７日後の１月１０日になる。よって、１月３日の時点での仲間期間の残期間は７日になる。例えば、その後、１月６日に交流の延長条件が再度達成された場合、１月６日の時点で７日間の再延長が発生し、仲間期間の終了日は１月６日（延長発生日）から７日後の１月１３日になる。よって、１月６日の時点での仲間期間の残期間は７日になる。この延長例では、仲間期間の残期間は最大でも延長期間（この例では７日間）となるので、仲間期間の残期間に上限を設ける必要はない。仲間期間の残期間に上限を設けない場合は、前記Ｓ８４およびＳ８５の処理を省くことができる。

　また、交流に関する延長条件を満たすことなく仲間期間が終了した場合（Ｓ８１でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ５５）、仲間関係が解除されたことが２人のユーザの端末装置３に報知される（Ｓ５６）。このＳ５５およびＳ５６の詳細は、図２１において説明したとおりである。

　このように、仲間関係にある２人のユーザに対して設定された仲間期間は、交流に関する所定の延長条件を満たす毎に延長される。そして、前述の仲間期間報知手段５８は、仲間期間（延長された場合、延長後の仲間期間）を表示させるための情報を、ユーザの端末装置３へ送信し、ユーザに仲間期間を報知する機能を有する。よって、各ユーザは、図１４に例示する仲間リスト画面で、自分の各仲間ユーザとの間に設定されている仲間期間（延長後の仲間期間）がいつまでなのかを確認できるようになっている。そして、ユーザは、仲間関係を終了させたくない仲間ユーザについては、仲間リストで確認した仲間期間が終了するまでに延長条件を満たす交流を行うことにより、仲間関係を継続できる。このように、ユーザの端末装置３に表示される仲間リスト画面に仲間期間（延長後の仲間期間）の情報を含めることにより、ユーザ自身による仲間管理を容易にすることができる。

　延長手段６１による処理形態としては、仲間期間の終了時刻に延長条件を満たしているか否かを判定し、延長条件を満たしている場合に仲間期間の延長処理を実行する形態もある。換言すれば、設定されている仲間期間の全期間の経過を待って延長の要否を判定し、延長処理を実行する形態である。この形態の延長処理について、図３８を参照して、以下に説明する。

　延長手段６１は、２人のユーザに設定された仲間期間の終了時刻になったときに（Ｓ９１でＹＥＳ）、交流に関する延長条件が達成されたか否かを判定する（Ｓ９２）。このＳ９２の処理は、前述のＳ８２と同様の処理である。

　交流に関する延長条件を満たしている場合（Ｓ９２でＹＥＳ）、延長手段６１は、仲間期間の延長処理を実行する（Ｓ９３）。一方、交流に関する延長条件を満たしていない場合（Ｓ９３でＹＥＳ）、仲間期間の終了に伴い、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ５５）、仲間関係が解除されたことが２人のユーザの端末装置３に報知される（Ｓ５６）。

　上記のように、本実施の形態の構成では、ユーザが仲間復活申請や仲間継続申請のような特別な操作を行うことなく、ゲーム内で仲間同士が延長条件を満たす交流を楽しむだけで自動的に仲間期間が延長され、仲間関係を継続できるようになっている。特に、ソーシャルゲーム等のユーザの操作の容易化・簡素化が強く求められるゲームサービスを提供する場合には、特別な操作を要することなく仲間関係を継続できる本構成が好適である。

　一方、延長条件を満たすような交流が行われなかった場合、お互いの関心が希薄であり、交流を楽しめるような仲間同士ではなかったということが考えられる。この場合、仲間期間が延長されることなく仲間期間の終了により仲間関係が自動的に解除されるので、やはり仲間解除のための特別な操作は不要である。

　また、本実施の形態では、仲間期間の延長の概念を、仲間との交流を楽しむというソーシャル要素を取り入れたゲームに導入したことにより、現実世界の仲間関係（対人関係）に近い関係を、ゲーム内で仮想的に実現できる。すなわち、現実世界では、仲間（知り合い）になってから継続的に交流が保たれていればその仲間関係は維持されるが、一旦仲間になっても、その後、あまり交流が持たれなかった場合には、両者が親密な関係を構築できないまま仲間関係は自然消滅する。そして、本実施の形態では、交流が持たれたときの仲間関係の維持を仲間期間の延長およびその繰り返しにより実現し、交流が持たれなかった場合の仲間関係の自然消滅を、仲間期間の延長がなされないまま仲間期間が終了することによる仲間関係の自動解消により実現している。

　一方、従来では、仲間関係を解除する操作が必要である等の理由により、全く交流がない又は殆ど交流がない仲間であっても、仲間として維持しているケースが殆どであり、現実世界の仲間関係とゲーム内の仲間関係とは大きく乖離しているのが現状である。

　本実施の形態の構成を適用したゲームでは、ユーザが仲間と交流を持ちながら普通にゲームをプレイしてさえいれば、実際に交流を楽しんでいる仲間で構成された仲間グループが自然に構築されることになる。

　ところで、延長手段６１による仲間期間の延長が何度も繰り返されているユーザ同士は、仲間関係が自動的に解除されることを望んでいない可能性が高いと考えられる。そこで、延長手段６１は、仲間期間が終了するまでに所定回数（または所定回数以上）の交流があった場合に仲間期間を延長する延長処理に加え、仲間期間の延長処理自体が所定回数以上（例えば３回以上）実行された２人のユーザに対しては、仲間期間を無制限にする（換言すれば、仲間期間を無期限に延長する）ことが望ましい。但し、下位のユーザが上位のユーザに対して一方的に交流を行った結果として仲間期間の延長処理が所定回数以上実行された場合までを含めて、仲間期間を無制限にすると、上位ユーザから不満が出る可能性もある。そこで、この場合、２人のユーザの両方とも互いに相手に対して所定回数（または所定回数以上）の交流を行うことを延長の条件とすることが望ましい。両方とも互いに相手に対して所定回数以上の交流があった場合に仲間期間の延長処理が実行され、この延長処理が所定回数以上繰り返されるということは、お互いに継続的に仲間関係を維持したいと考えていることが想定されるためである。

　なお、２人のユーザの仲間期間を無制限にするということは、仲間関係が自動的に解除されることがない状態にするという観点から、２人のユーザに仲間期間を設けないことと実質的に同じである。よって、２人のユーザの仲間期間を無制限にすることには、２人のユーザの仲間期間の設定を解除することも含まれる。

　次に、仲間関係が成立している２人に親密度というパラメータを設定し、親密度の値に応じて延長時の仲間期間を調整する構成について説明する。親密度とは、仲間関係が成立している２人のユーザの親密さを示すものであり、２人の友好度合い、友情の深さ、絆の深さ等として表現することもできる。

　図３５に示すように、ゲームサーバ１は、親密度付与手段６２および補正手段６３を備えている。これらの手段６２および６３は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。

　親密度付与手段６２は、交流手段５５により仲間関係が成立している２人のユーザ間で交流処理が実行された場合に、当該２人のユーザに対して親密度を付与する機能を有する。本実施の形態の親密度付与手段６２は、２人のユーザ間で交流処理が実行される毎に、所定値（例えば１ポイント）の親密度を付与するようになっている。なお、交流の内容により付与する親密度の値を変えてもよい。例えば、挨拶は１ポイント、メッセージ送信は２ポイント、プレゼントおよび対戦協力は３ポイント等としてもよい。また、本実施の形態では、２人の親密度の値に応じて、例えば５段階のランクが設けられている。例えば、親密度が０～２４ポイントで知り合いランク、２５～４９ポイントで友人ランク、５０～７４ポイントで親友ランク、７５～９９ポイントで相棒ランク、１００ポイント以上で盟友ランクとなる。

　親密度付与手段６２は、親密度記憶制御手段６２ａを備えている。この親密度記憶制御手段６２ａは、例えば図３９に示すように、仲間情報を一意に識別する仲間情報ＩＤと対応づけて、２人のユーザに付与された親密度の値データベースサーバ２に記憶している。また、親密度のランクも併せて記憶していてもよい。

　仲間同士の２人のユーザが交流を重ねた結果として、２人の親密度の値が高くなることから、親密度の値が高いほど、お互いに仲間関係の維持を望んでいると考えられる。そこで、親密度の値が高いほど、延長処理における仲間期間を長く設定することにより、親密度に応じた適切な仲間期間を設定することができる。

　そこで、補正手段６３は、２人のユーザの親密度の値が高いほど、延長手段６１により延長される仲間期間（延長期間）が長くなるように補正する機能を有する。一例を挙げると、２人のユーザの親密度の値が知り合いランクのときに延長される仲間期間の長さをｎ（日）とした場合、友人ランクではｎ×１．５、親友ランクではｎ×２．０、相棒ランクではｎ×２．５、盟友ランクではｎ×３．０の期間補正を行う。

　また、補正手段６３は、２人のユーザの親密度の値が閾値以上の場合（例えば、１００ポイント以上の盟友ランクに達している場合）、仲間期間を無期限に設定（すなわち仲間期間をなくす）ようにしてもよい。これは、２人のユーザの親密度の値が閾値以上まで高まった場合には、もはや何れのユーザも仲間関係の解除を望んでいない可能性が極めて高いと考えられるからである。
　この親密度の値に応じて延長時の仲間期間を補正する処理について、図４０を参照して以下に説明する。

　２人のユーザに設定された仲間期間が終了する前に（Ｓ８１でＮＯ）、交流に関する延長条件が達成された場合（Ｓ８２でＹＥＳ）、２人のユーザの親密度の値が閾値以上か否かが判定される（Ｓ１１１）。ここで、親密度の値が閾値以上の場合（Ｓ１１１でＹＥＳ）、補正手段６３は、仲間期間を無期限に設定する（Ｓ１１２）。また、親密度の値が閾値未満の場合（Ｓ１１１でＮＯ）、補正手段６３は、親密度の値に応じて延長手段６１により延長される仲間期間（延長期間）を補正する（Ｓ１１３）。すなわち、補正手段６３は、親密度の値が高いほど、延長期間が長くなるように補正する。Ｓ１１３の後、延長手段６１は、補正手段６３により補正された延長期間により仲間期間を延長する（Ｓ１１４）。また、Ｓ１１４の後は前記Ｓ８１に戻り、仲間期間が終了するか又は親密度が閾値以上になるまでループ処理（Ｓ８１、Ｓ８２、Ｓ１１１～Ｓ１１４）を繰り返す。

　なお、仲間期間が終了した場合は（Ｓ８１でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ５５）、仲間関係が解除されたことが２人のユーザの端末装置３に報知される（Ｓ５６）。

　〔ゲーム管理装置の他の構成例〕
　上述の実施の形態では、仲間期間設定手段５６がユーザ間での仲間関係の成立時に、仲間期間を設定する構成について説明したが、これに限定されるものではなく、仲間期間設定手段５６が仲間期間を設定するタイミングについては、任意に定めることができる。

　例えば、仲間期間設定手段５６による仲間期間の設定タイミングは、ユーザ間で仲間関係が成立してから一定期間経過後とすることができる。ここで、一定期間としては、例えば、３日、１週間、１０日、２週間、１か月等、任意の期間を設定することができる。このように、仲間関係の成立直後の一定期間を猶予期間として、仲間期間が設定されることにより仲間関係が自動解除され得る状態には移行しないようにしてもよい。

　あるいは、次に示す好ましい構成により、仲間期間の設定タイミングを可変とすることもできる。すなわち、ユーザ間で行われた交流の履歴を交流履歴記憶制御手段５５ｆが記憶領域に記憶しており、仲間期間設定手段５６は、交流履歴記憶制御手段５５ｆによって記憶された交流の履歴に基づいて、仲間関係が成立している２人のユーザ間で所定期間、交流が行われていない状態を検出したとき、当該２人のユーザに対して仲間期間を設定する。この構成は、仲間期間の延長処理を実行しないゲームサーバ１および延長手段６１を具備して仲間期間の延長処理を実行可能なゲームサーバ１の何れにも適用できる。

　上記の構成によれば、仲間関係が成立してからユーザ間で交流が行われている状態では、仲間期間が設定されることもなく、従って仲間期間の終了による自動解除も生じることがない。こうする理由は、仲間関係の成立後にユーザ間で交流が行われているということは、ユーザが仲間関係の維持を望んでいる可能性が高いと考えられるからである。一方、ユーザ間で所定期間、交流が行われない状態が発生すると、これを契機として仲間期間が設定され、期間終了をもって仲間関係が自動解除され得る状態に移行する。こうする理由は、所定期間、交流が行われないということは、お互いに相手への関心が希薄になっていると考えられるからである。

　上記の構成を有するゲームサーバ１の動作例を、図４１のフローチャートを参照して以下に説明する。図４１では、延長処理を実行可能なゲームサーバ１に適用した例を示している。なお、延長処理を実行しないゲームサーバ１の場合、図４１中のＳ８１～Ｓ８３の処理を省略できる。

　図４１に示すように、ユーザ間で仲間関係が成立した後（Ｓ１２１でＹＥＳ）、当該ユーザ間で交流が行われた場合（Ｓ１２２でＹＥＳ）、交流履歴記憶制御手段５５ｆが交流の履歴を記憶領域に記憶する（Ｓ１２３）。例えば、交流履歴記憶制御手段５５ｆは、図１７に例示する交流履歴の情報をデータベースサーバ２に記憶する。その後もユーザ間で交流が行われる毎に、交流の履歴が記憶されることになる。

　そして、仲間期間設定手段５６は、交流履歴記憶制御手段５５ｆが記憶領域に記憶している交流の履歴に基づいて、所定期間（例えば１週間）、仲間同士のユーザ間で交流が行われていない状態を検出したとき（Ｓ１２４でＹＥＳ）、仲間期間を設定する（Ｓ１２５）。Ｓ１２４の検出処理は、処理対象となるユーザ間で行われた最後の交流時間（交流履歴として記録された交流処理実行時の時間情報）から所定期間が経過しているか否かを判定することにより実現できる。また、Ｓ１２５の仲間期間設定手段５６による仲間期間の設定処理は、既に説明したとおりである。

　その後、ゲームサーバ１は、仲間期間が設定された２人のユーザの端末装置３に対して、仲間期間が設定された旨を報知するための情報（画面データ等）を送信する（Ｓ１２６）。なお、ゲームサーバ１が、仲間期間が設定されたことを報知するためには、ユーザの端末装置３がゲームサーバ１にアクセスしている必要がある。よって、ゲームサーバ１は、Ｓ１２５の仲間期間の設定処理を実行した後、各ユーザの端末装置３がゲームサーバ１に最初にアクセスしたときに、Ｓ１２６の報知処理を実行することになる。

　なお、Ｓ１２６の報知処理は省くことができるが、ユーザが気付かないうちに、いつの間にか仲間期間が設定されているという状態を回避するため、当該報知処理を実行することが望ましい。

　その後、仲間期間が終了するまでに（Ｓ８１でＮＯ）、交流に関する延長条件が達成された場合（Ｓ８２でＹＥＳ）、延長手段６１は、仲間期間の延長処理を実行する（Ｓ８３）。一方、仲間期間が終了した場合（Ｓ８１でＹＥＳ）、仲間関係解除手段５７により仲間関係が自動的に解除され（Ｓ５５）、仲間関係が解除されたことが２人のユーザの端末装置３に報知される（Ｓ５６）。

　上記のように、所定期間、交流が行われない状態の発生を契機として仲間期間を設定する構成により、仲間関係成立後に交流を持っている仲間同士の仲間関係が自動解除され得る状態になることを回避し、お互いの関心が希薄になっていると考えられる仲間同士に絞って仲間関係が自動解除され得るゲーム環境を効果的に構築できる。

　ところで、上記の構成では、仲間期間が設定されている仲間と設定されていない仲間が混在することになるが、各ユーザは、図４２に例示する仲間リスト画面を端末装置３に表示させることにより、仲間期間が設定されている仲間を容易に視認することができる。図４２の例では、仲間期間が設定されている仲間の仲間期間表示領域８０にのみ仲間期間の情報が表示され、これにより仲間期間が設定されている仲間とそうでない仲間とを区別できるようになっている。なお、仲間期間が設定されていない仲間については、仲間期間表示領域８０に、「仲間期間の設定なし」等のステータス表示を行ってもよい。

　よって、前記Ｓ１２６の仲間期間設定の報知処理がなくても、あるいは報知処理から時間が経過していても、ユーザは、いつでも仲間期間が設定されている仲間およびその仲間期間を確認することができる。なお、仲間リスト画面等に仲間期間を表示させる処理は、前述の仲間期間報知手段５８により実現される。

　ユーザは、仲間リスト画面等で仲間期間が設定された仲間を確認しながら、仲間関係を継続するか否かを検討することができる。そして、ユーザが仲間関係を継続したいと思う仲間がいた場合、仲間期間の延長処理が可能な構成では、その仲間に対して、仲間期間が終了するまでに、延長条件を満たす交流を行うようにすればよい。

　〔他の実施の形態〕
　上述の実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各ユーザの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明した。これはいわゆるクライアントサーバ型のゲームシステムであるが、これに限定されるものではない。例えば、ゲームサーバ１が、ユーザの仲間情報を含むゲーム情報を管理し、ゲーム内での仲間管理等のゲームサービスをユーザに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはユーザの端末装置側にて行われるゲームシステムにも本発明の実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムを適用できる。

　すなわち、ゲーム実行プログラムの一部または全部をユーザの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも適用できる。例えば、ユーザの端末装置が、インターネット通信、無線ＬＡＮ通信、所定の周波数帯（例えば２．４ＧＨｚの周波数帯）を用いた近距離無線通信、または有線ＬＡＮ通信などにより他のユーザの端末装置とピア・ツー・ピア接続し、ピア・ツー・ピア型のゲームを実行することも可能である。

　よって、ユーザの端末装置としては、ゲームサーバ（ゲーム管理装置）に接続して仲間管理等のゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、スマートフォン、ＰＨＳ端末、携帯情報端末（ＰＤＡ）、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置（家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置）や、携帯型のゲーム専用装置なども適用可能である。

　すなわち、ゲーム管理装置と端末装置とを含むゲームシステムにおいて、上述の各実施の形態で説明したゲーム管理装置が具備する各手段は、ゲーム管理装置又は端末装置のいずれか一方が備えていればよい。

　また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ１のＣＰＵ１１により実行される。また、プログラムをゲームサーバ１に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。
　〔実施の形態の概要〕

　（１）本発明の一局面に係るゲーム管理装置は、各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置であって、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段と、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段と、を備える構成である。

　この構成のゲーム管理装置は、各ユーザの端末装置と通信を行うことができる、例えばサーバなどの情報処理装置により構成することができる。そして、本ゲーム管理装置は、ユーザ同士が仲間関係を構築することができるゲーム、例えばユーザ同士が仲間になって交流を楽しむことができるソーシャルゲーム等のゲームの仲間管理を行うようになっている。

　本ゲーム管理装置は、仲間管理手段を備え、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う。なお、各ユーザが他のユーザと仲間関係を構築することができる仲間数には、上限が設定されている。ここで、仲間関係とは、ゲーム内で構築されるユーザ同士の仮想的な関係の総称であり、知人、友人、友達、クラスメイト、相棒、親類、家族、兄弟、姉妹、会社や組織の同僚などの様々なゲーム内の関係を含む。

　そして、本ゲーム管理装置は、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段を備えている。ここで、仲間期間設定手段が設定する仲間期間の長さとしては、例えば１週間、１０日、２週間、１ヶ月など、任意の期間長さに設定可能である。また、仲間期間の長さは固定であってもよいし、例えば設定時にランダムに期間長さを変えてもよいし、後述するようにユーザ間のレベル関係に応じて適切な期間長さを決定するようにしてもよい。

　また、仲間期間設定手段が仲間期間を設定するタイミングについても、任意に定めることができる。例えば、仲間期間の設定タイミングは、仲間関係の成立時であってもよいし、仲間関係が成立してから一定期間（例えば１週間）経過後であってもよいし、後述するように２人のユーザ間で所定期間、交流が行われなかった状態が発生したときであってもよい。

　そして、仲間関係解除手段は、仲間関係が成立している２人のユーザに対して設定された仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除するようになっている。よって、ユーザは、心理的にも行い難い仲間解除の操作を行うことなく、仲間期間の終了により仲間関係の解除が可能となる。これにより、ユーザの仲間数が上限に達していた場合でも、この仲間関係の自動的な解除により、上限までに余裕ができる。すなわち、仲間数が一旦上限まで達したユーザであっても、従来のように実質的に仲間が固定された状態に陥ることはなく、他のユーザと新たな仲間関係を構築するための機会が与えられる。したがって、ユーザは、例えば殆ど交流等もなく一緒にゲームを楽しめないような下位レベルの仲間に対しては、仲間期間の終了により仲間関係を断ち、改めて、自分の好みの新たな仲間を探すことができる。

　もっとも、ユーザが仲間関係を継続したいと思うような相手であれば、例えば、仲間期間終了後に改めて同じ相手に仲間申請を行う等の所定の操作により、仲間関係を継続することができるようにすればよい。

　そして、ユーザは、一緒にゲームを楽しめなかった下位レベルの仲間とは、仲間期間の終了により仲間関係を終え、再度、仲間申請や承認をしたりすることはないと考えられる。その一方、ユーザが望むような相手（例えば、上位レベルのユーザや下位レベルであっても交流等により一緒にゲームを楽しめるようなユーザ）とは、仲間関係を継続するために、再度、仲間申請や承認等の所定の操作をすることが考えられる。よって、本構成により、仲間数の上限内で、仲間関係成立による仲間期間設定と、仲間期間終了による仲間関係の自動解除と、を繰り返しながら、ユーザの好むような仲間グループの構成に収束されていく環境が整えられる。したがって、従来のように、仲間数が上限まで達したユーザが、あまり交流等のない下位レベルの仲間ユーザを何人も抱え、自分好みの仲間のグループ構成になっていない状態で実質的に仲間が固定されてしまうことへの不満を解消できる。

　以上のように、本ゲーム管理装置は、仲間期間を設定するとともに、仲間期間の終了により仲間関係を自動解除するという斬新な機能を導入し、仲間数の上限が設定されているゲームにおいても、他のユーザと新たな仲間関係を構築し易やすい環境をユーザに提供できるので、ユーザは継続的に新たな仲間との交流等を楽しめるようになる。よって、長期間にわたりゲームを継続しても、ゲームに対するマンネリ感が発生しにくい環境をユーザに提供できる。

　（２）上記の構成において、ゲーム管理装置は、各ユーザのゲームレベルを記憶装置に記憶するゲームレベル記憶制御手段をさらに備えることが好ましい。そして、前記仲間期間設定手段は、仲間関係を構築するための仲間申請を行った第１のユーザのゲームレベルと当該仲間申請を承認した第２のユーザのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定することが好ましい。

　この構成によれば、本ゲーム管理装置は、各ユーザのゲームレベルをゲームレベル記憶制御手段により記憶している。このゲームレベルは、ユーザ間の仲間関係が継続される仲間期間を決定するために用いられる情報である。ここで、ゲームレベルとは、ユーザのゲームの進行度合い、熟練度、力量等を直接的または間接的に示す指標情報であり、例えば下記（ａ）～（ｄ）等を含む。

　（ａ）ユーザ自身のレベル。例えば、ユーザがゲームを進行させて経験値を蓄積することによりレベルアップするゲームにおけるユーザのレベルがこれに該当する。

　（ｂ）ユーザのゲーム内の所有物のレベル（所有物の例：キャラクタ、キャラクタの集合体であるグループ・チーム・ユニット、アイテム等）。例えば、ユーザが所有するキャラクタを育成モード等で使用することによりキャラクタのレベルアップを図るゲームにおけるキャラクタのレベルや能力値がこれに該当する。

　（ｃ）ユーザのゲーム内の所有物の数・所有物の能力値等から算出される値。例えば、ユーザが所有する所定の能力値以上のキャラクタの数をユーザのゲームレベルとすることができる。

　（ｄ）ユーザが達成したステージ等のレベル。例えば、ゲーム内にレベル（難易度）の異なる複数のステージが設けられており、１つのステージをクリアしたら１つ難易度の高い別のステージに進むようなゲームにおけるユーザが達成したステージのレベルがこれに該当する。

　また、ゲームレベルは、数値で表されるレベルに限らず、例えばＡ、Ｂ、Ｃ・・等で表されるような様々な表現のレベルを含む。

　そして、仲間期間設定手段は、仲間関係を構築するための仲間申請を行った第１のユーザのゲームレベルと当該仲間申請を承認した第２のユーザのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定するようになっている。ユーザ間のレベル関係を含む所定条件に基づいた仲間期間の設定例としては、仲間申請を行った第１のユーザのレベルがそれを承認した第２のユーザのレベルより低い場合に５日、両ユーザのレベルが同一の場合に７日、第１のユーザのレベルが第２のユーザのレベルより高い場合に１０日の各仲間期間を設定するといったように、両ユーザのレベルの高低に応じた仲間期間の設定がある。また、後述のように、両ユーザのレベルの高低だけではなく、ユーザ間の高低のレベル差をも考慮して仲間期間を設定してもよい。

　このように、仲間申請を行った側とそれを承認した側の両ユーザのレベル関係を含む条件に基づいて仲間期間を決定することにより、両ユーザのレベルの高低に応じた適切な仲間期間を設定することができる。

　（３）上記（２）の構成において、前記仲間期間設定手段は、前記第１のユーザよりもゲームレベルが高い前記第２のユーザが仲間申請を承認した場合に設定する前記仲間期間を、前記第１のユーザとゲームレベルが同じ又は前記第１のユーザよりもゲームレベルが低い前記第２のユーザが仲間申請を承認した場合に設定する前記仲間期間よりも短くすることが好ましい。

　上記のように、仲間申請した第１のユーザよりも上位レベルの第２のユーザが仲間申請を承認した場合、承認した第２のユーザにとって、自分よりも下位レベルのユーザ（即ち、対戦協力等の貢献度の低いユーザ）と仲間になるのであるから、交流等も少なく一緒にゲームを楽しめない仲間であった場合には短期間で仲間関係を解消したいと希望することが多い。そこで、この場合、仲間申請した第１のユーザと同レベルか又はそれより下位レベルの第２のユーザが仲間申請を承認した場合よりも、仲間期間を短くするのである。これにより、承認した側のユーザの希望に沿った適切な仲間期間の設定が可能となる。

　なお、このように仲間申請をした側ではなく、仲間申請を承認した側からみた適切な仲間期間の設定を行う理由は、次の通りである。すなわち、仲間申請をした側のユーザにとっては、相手のレベルにかかわらずその相手と仲間になりたいと考えて仲間申請しているはずである。一方、仲間申請を受けた側のユーザにとっては、それを拒否することもできるが、下位ユーザからの申請だからといって無碍に断れずにその申請を承認してしまい、後で後悔することも従来は多かった。そこで、仲間申請を承認した側のユーザからみた適切な仲間期間の設定を行うのである。

　（４）上記の（２）または（３）の構成において、前記仲間期間設定手段は、（ｉ）前記第１のユーザよりもゲームレベルが高い前記第２のユーザが仲間申請を承認した場合には、前記第１のユーザのゲームレベルと前記第２のユーザのゲームレベルとのレベル差が大きいほど前記仲間期間を短く設定し、（ｉｉ）前記第１のユーザよりもゲームレベルが低い前記第２のユーザが仲間申請を承認した場合には、前記レベル差が大きいほど前記仲間期間を長く設定することが好ましい。

　上記のように、仲間申請した第１のユーザよりも上位レベルの第２のユーザが仲間申請を承認した場合は、承認した第２のユーザにとって、自分よりも下位レベルの第１のユーザとのレベル差が大きいほど、第１のユーザから受ける対戦協力等による貢献の程度は小さくなる。そこで、この場合には、ユーザ間のレベル差が大きいほど仲間期間を短く設定することにより、承認した第２のユーザにとって望ましい仲間期間の設定を実現できる。

　一方、仲間申請した第１のユーザよりも下位レベルの第２のユーザが仲間申請を承認した場合は、承認した第２のユーザにとって、自分よりも上位レベルの第１のユーザとのレベル差が大きいほど、第１のユーザから受ける対戦協力等による貢献の程度は大きくなる。そこで、この場合には、ユーザ間のレベル差が大きいほど仲間期間を長く設定することにより、承認した第２のユーザにとって有利な仲間期間の設定を実現できる。

　（５）上記の（１）ないし（４）の何れかの構成において、ゲーム管理装置は、ユーザ間で行われた交流の履歴を記憶装置に記憶する交流履歴記憶制御手段と、前記仲間期間が設定されている２人のユーザの少なくとも一方から相手のユーザに対して、当該仲間期間が終了するまでに所定回数及び／又は所定時間の前記交流が行われた場合に、当該仲間期間を延長する延長手段と、をさらに備えていることが好ましい。

　この構成によれば、交流履歴記憶制御手段がユーザ間で行われた交流の履歴を記憶している。ここで、交流には、挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、チャットなど、仲間同士で行われる様々な交流を含めることができる。なお、挨拶とは、ゲーム内で仮想的に行うことができる簡易的な交流の総称であり、エール（応援）を送る、ガッツ（やる気）を送る、ウインクする、微笑む、手を振る等、別の表現を用いた簡易的な交流も含まれる。

　そして、仲間期間が設定されている２人のユーザの少なくとも一方から相手のユーザに対して、仲間期間が終了するまでに所定回数及び／又は所定時間の交流が行われたことを条件として、延長手段が仲間期間を延長する。この条件を満たす形態には、いずれか一方から相手に対して所定回数及び／又は所定時間の交流があれば条件を満たすとする形態と、両者とも互いに相手に対して所定回数及び／又は所定時間の交流を行うことを条件とする形態とを含む。何れの形態を延長の条件として設定してもよい。

　なお、従来の課題であるところの、上位レベルのユーザにとって、仲間のユーザのレベルが自分よりも低い場合に、ゲームにおける協力対戦等について不公平感が生じていたということをより積極的に解消するために、少なくとも下位レベルのユーザが上位レベルのユーザに対して、所定回数及び／又は所定時間の交流を行うことを条件としてもよい。

　ここで、「所定回数及び／又は所定時間」の交流が行われたことを延長の条件とすることに関し、「所定回数」の交流が行われたことを延長の条件としてもよいし、「所定時間」の交流が行われたことを延長の条件としてもよいし、あるいは「所定回数及び所定時間」の交流が行われたことを延長の条件としてもよい。例えば、挨拶、メッセージの送信、プレゼント、協力対戦の助っ人依頼、チャット等の全ての交流について、これらの交流が「所定回数」行われたことを延長の条件とすることができる。また、チャット等の、ユーザ同士がリアルタイムで行うような交流については、「所定時間」の交流が行われたことを延長の条件としたり、「所定回数及び所定時間」の交流が行われたことを延長の条件としたりすることができる。また、挨拶等の交流およびチャット等の交流を含む様々な交流が可能なゲームについては、「所定回数」、「所定時間」、または「所定回数及び所定時間」の何れを延長の条件としてもよい。

　また、仲間期間が終了するまでに「所定回数」の交流が行われたことを延長の条件とすることに関し、「所定回数」として任意の回数を設定可能である。例えば、この所定回数を１回としてもよいし、２回以上の複数回としてもよい。

　また、仲間期間が終了するまでに「所定時間」の交流が行われたことを延長の条件とすることに関し、「所定時間」として例えば５分、１０分、３０分、または１時間等、任意の時間を設定可能である。

　また、仲間期間が終了するまでに「所定回数及び所定時間」の交流が行われたことを延長の条件とすることに関し、例えば３回および１０分、２回および１５分等、任意の回数および時間を設定可能である。

　また、延長手段が延長する期間の長さについては、任意に設定可能である。例えば、一定の期間（例えば、１週間、１０日間、２週間等）としてもよいし、延長が行われる毎にランダムに期間を決定してもよいし、交流回数によって延長期間を変動させる（交流回数が多いほど延長期間を長く設定する）ようにしてもよい。

　ところで、仲間になったユーザ間で仲間期間中に所定の交流が持たれないということは、お互いに相手への関心が希薄であると考えられる。一方、仲間期間中に仲間同士で所定の交流が行われた場合には、ユーザが仲間関係の維持を望んでいる可能性が高いと考えられる。そこで、仲間期間が終了するまでに条件を満たす交流があった場合に、延長手段が仲間期間を自動的に延長し、仲間関係が維持されるようにするのである。

　上記のように本構成では、ユーザが仲間関係を継続するための特別な操作を行うことなく、ゲーム内で仲間同士が延長条件を満たす交流を楽しむだけで、自動的に仲間期間が延長され、仲間関係を継続できるようになっている。特に、ソーシャルゲーム等のユーザの操作の容易化・簡素化が強く求められるゲームの場合には、特別な操作を要することなく仲間関係を継続できる本構成が好適である。

　（６）上記の（５）の構成において、前記延長手段は、前記仲間期間が延長された２人のユーザの少なくとも一方から相手のユーザに対して、延長された前記仲間期間が終了するまでに所定回数及び／又は所定時間の前記交流が行われる毎に、前記仲間期間を延長することを繰り返すことが好ましい。

　この構成によれば、条件を満たす交流を継続的に行っている仲間同士については、仲間期間の自動延長が繰り返されることにより仲間関係が継続して維持される。

　本構成により、現実世界の仲間関係（対人関係）に近い関係を、ゲーム内で仮想的に実現できる。すなわち、現実世界では、仲間（知り合い）になってから継続的に交流が保たれていればその仲間関係は維持されるが、一旦仲間になっても、その後、あまり交流が持たれなかった場合には、両者が親密な関係を構築できないまま仲間関係は自然消滅する。これを本構成では、所定の交流が持たれたときの仲間関係の維持を仲間期間の延長およびその繰り返しにより実現し、所定の交流が持たれなかった場合の仲間関係の自然消滅を、仲間期間の延長がなされないまま仲間期間が終了することによる仲間関係の自動解消により実現しているのである。

　そして、本構成により、仲間同士で交流を楽しむというソーシャル要素を有するゲームにおいて、ユーザが仲間と交流を持ちながら普通にゲームをプレイしてさえいれば、実際に交流を楽しんでいる仲間で構成された仲間グループが自然に構築される。

　（７）上記の（５）または（６）の構成において、相対的にゲームレベルが低いユーザから相手のユーザに対して前記交流が行われる場合の前記所定回数は、相対的にゲームレベルが高いユーザから相手のユーザに対して前記交流が行われる場合の前記所定回数よりも多く設定されていることが好ましい。

　（８）上記の（１）ないし（７）の何れかの構成において、ゲーム管理装置は、前記仲間期間設定時における、前記第１のユーザのゲームレベルと前記第２のユーザのゲームレベルとのレベル差を記憶装置に記憶するレベル差記憶制御手段をさらに備えていることが好ましい。そして、前記仲間期間設定手段は、前記ユーザ間のレベル差に応じて前記仲間期間を設定し、且つ前記仲間期間中の前記レベル差が、前記レベル差記憶制御手段によって記憶されている前記仲間期間設定時のレベル差から変動した場合に、変動後のレベル差に応じて前記仲間期間を再設定することが好ましい。

　この構成によれば、レベル差記憶制御手段が仲間期間設定時におけるユーザ間のレベル差を記憶装置に記憶している。そして、仲間期間設定手段がユーザ間のレベル差に応じて適切な仲間期間を設定した後、その仲間期間中にユーザ間のレベル差が変動した場合、仲間期間設定手段は変動後のレベル差に応じた仲間期間に再設定するようになっている。これにより、仲間期間設定後のユーザ間のレベル差変動に追従した適切な仲間期間の調整を実現できる。

　（９）上記の（１）ないし（８）の何れかの構成において、ゲーム管理装置は、ユーザ間で行われた交流の履歴を記憶装置に記憶する交流履歴記憶制御手段を備え、前記仲間期間設定手段は、前記交流履歴記憶制御手段が記憶装置に記憶している前記交流の履歴に基づいて、仲間関係が成立している２人のユーザ間で所定期間、前記交流が行われていない状態を検出したとき、当該２人のユーザに対して前記仲間期間を設定することが好ましい。

　この構成によれば、仲間関係にある２人のユーザ間で、所定期間（例えば１週間）、交流が行われない状態が発生すると、これを契機として仲間期間が設定されることになる。よって、仲間関係が成立してからユーザ間で交流が行われている状態では、仲間期間が設定されることもなく、従って仲間期間の終了による自動解除も生じることがない。これは、仲間関係の成立後にユーザ間で交流が行われているということは、ユーザが仲間関係の維持を望んでいる可能性が高いと考えられるからである。一方、ユーザ間で所定期間、交流が行われない状態が発生すると、その時点で仲間期間が設定され、期間終了をもって仲間関係が自動解除され得る状態に移行する。これは、所定期間、交流が行われないということは、お互いに相手への関心が希薄になっていると考えられるからである。

　このように、所定期間、交流が行われない状態の発生を契機として仲間期間を設定することにより、仲間関係成立後に交流を持っている仲間同士の仲間関係が自動解除され得る状態になることを回避し、お互いの関心が希薄になっていると考えられる仲間同士に絞って仲間関係が自動解除され得るゲーム環境を効果的に構築できる。

　（１０）本発明の他の一局面に係るゲームシステムは、ゲームサービスを受ける各ユーザの端末装置と、前記端末装置と通信し各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置と、を含むゲームシステムであって、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段の各手段を、前記ゲーム管理装置又は前記端末装置のいずれか一方が備えている。

　（１１）本発明の他の一局面に係るゲーム管理方法は、各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、前記ゲーム管理装置が、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理ステップと、前記ゲーム管理装置が、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定ステップと、前記ゲーム管理装置が、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除ステップと、を含んでいる。

　（１２）本発明の更に他の一局面に係るプログラムは、コンピュータを上記の（１）ないし（９）の何れかの構成のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラムである。

　なお、発明を実施するための形態においてなされた具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の技術思想と特許請求事項との範囲内で、種々変更して実施することができるものである。

　本発明は、特に、ユーザが、ゲームサービスを受けている他のユーザとコミュニケーションをとりながらプレイすることができる、いわゆるソーシャルゲーム等を対象としたゲーム管理装置、ゲームシステム、ゲーム管理方法、プログラム、及び記録媒体に好適に適用され、興趣性の高いゲームサービスを提供できるので、産業上利用可能である。

Claims

　各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置であって、
　仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段と、
　仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段と、
　仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段と、を備えるゲーム管理装置。
　各ユーザのゲームレベルを記憶装置に記憶するゲームレベル記憶制御手段をさらに備え、
　前記仲間期間設定手段は、仲間関係を構築するための仲間申請を行った第１のユーザのゲームレベルと当該仲間申請を承認した第２のユーザのゲームレベルとの関係を含む所定条件に基づいて仲間期間を決定する請求項１に記載のゲーム管理装置。
　前記仲間期間設定手段は、前記第１のユーザよりもゲームレベルが高い前記第２のユーザが仲間申請を承認した場合に設定する前記仲間期間を、前記第１のユーザとゲームレベルが同じ又は前記第１のユーザよりもゲームレベルが低い前記第２のユーザが仲間申請を承認した場合に設定する前記仲間期間よりも短くする請求項２に記載のゲーム管理装置。
　前記仲間期間設定手段は、
　前記第１のユーザよりもゲームレベルが高い前記第２のユーザが仲間申請を承認した場合には、前記第１のユーザのゲームレベルと前記第２のユーザのゲームレベルとのレベル差が大きいほど前記仲間期間を短く設定し、
　前記第１のユーザよりもゲームレベルが低い前記第２のユーザが仲間申請を承認した場合、前記レベル差が大きいほど前記仲間期間を長く設定する請求項２に記載のゲーム管理装置。
　ユーザ間で行われた交流の履歴を記憶装置に記憶する交流履歴記憶制御手段と、
　前記仲間期間が設定されている２人のユーザの少なくとも一方から相手のユーザに対して、当該仲間期間が終了するまでに所定回数及び／又は所定時間の前記交流が行われた場合に、当該仲間期間を延長する延長手段と、をさらに備えている請求項１に記載のゲーム管理装置。
　前記延長手段は、前記仲間期間が延長された２人のユーザの少なくとも一方から相手のユーザに対して、延長された前記仲間期間が終了するまでに所定回数の前記交流及び／又は所定時間が行われる毎に、前記仲間期間を延長することを繰り返す請求項５に記載のゲーム管理装置。
　相対的にゲームレベルが低いユーザから相手のユーザに対して前記交流が行われる場合の前記所定回数は、相対的にゲームレベルが高いユーザから相手のユーザに対して前記交流が行われる場合の前記所定回数よりも多く設定されている請求項５に記載のゲーム管理装置。
　前記仲間期間設定時における、前記第１のユーザのゲームレベルと前記第２のユーザのゲームレベルとのレベル差を記憶装置に記憶するレベル差記憶制御手段をさらに備え、
　前記仲間期間設定手段は、前記ユーザ間のレベル差に応じて前記仲間期間を設定し、且つ前記仲間期間中の前記レベル差が、前記レベル差記憶制御手段によって記憶されている前記仲間期間設定時のレベル差から変動した場合に、変動後のレベル差に応じて前記仲間期間を再設定する請求項１に記載のゲーム管理装置。
　ユーザ間で行われた交流の履歴を記憶装置に記憶する交流履歴記憶制御手段を備え、
　前記仲間期間設定手段は、前記交流履歴記憶制御手段が記憶装置に記憶している前記交流の履歴に基づいて、仲間関係が成立している２人のユーザ間で所定期間、前記交流が行われていない状態を検出したとき、当該２人のユーザに対して前記仲間期間を設定する請求項１ないし８の何れか１項に記載のゲーム管理装置。
　ゲームサービスを受ける各ユーザの端末装置と、前記端末装置と通信し各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置と、を含むゲームシステムであって、
　仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段、
　仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段、
　仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段の各手段を、前記ゲーム管理装置又は前記端末装置のいずれか一方が備えているゲームシステム。
　各ユーザの端末装置と通信し、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置におけるゲーム管理方法であって、
　前記ゲーム管理装置が、仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理ステップと、
　前記ゲーム管理装置が、仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定ステップと、
　前記ゲーム管理装置が、仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除ステップと、を備えるゲーム管理方法。
　コンピュータを、各ユーザが他のユーザと仲間関係を構築することができる仲間数に上限が設定されているゲームの仲間管理を行うゲーム管理装置として動作させるためのプログラムであって、
　前記コンピュータを、
　仲間関係が成立している２人のユーザを関係付けた情報を記憶して仲間管理を行う仲間管理手段、
　仲間関係が成立している２人のユーザに対して、ユーザ間の仲間関係が継続される仲間期間を設定する仲間期間設定手段、
　仲間関係が成立している２人のユーザに対して設定された前記仲間期間の終了により、当該２人のユーザの仲間関係を自動的に解除する仲間関係解除手段、
　として機能させるためのプログラム。
　請求項１２に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。