【課題】ゲームコミュニティの活性化を図ることによって興趣性の高いゲームサービスを提供することができるゲーム管理装置を提供する。
【解決手段】ゲーム管理装置は、各プレイヤの仲間の情報を管理する仲間管理手段５３と、プレイヤが１日に１回以上ゲームへアクセスしたか否かを管理するアクセス管理手段５５と、連続した規定日数のうちアクセスの欠落日が存在するプレイヤについて、仲間が所定の応援アクセス条件を満たしているか否かを判定する仲間応援アクセス判定手段５６と、連続した規定日数のアクセスを達成したプレイヤに対して連続アクセス達成特典を付与する連続アクセス特典付与手段５７とを備える。連続アクセス特典付与手段５７は、連続した規定日数の中に欠落日が存在するプレイヤであっても、当該プレイヤの仲間が応援アクセス条件を満たしている場合、当該プレイヤに連続アクセス達成特典を付与する。

【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲームサービスを受ける各プレイヤの端末装置からのネットワークを介したアクセスを受け付けて、各プレイヤのゲーム情報を管理するゲーム管理装置、ゲーム管理方法及びプログラムに関するものである。
【背景技術】
【０００２】
従来から、インターネット上に設置されたゲームサーバに、プレイヤの端末装置（パーソナルコンピュータ、携帯電話端末等）を接続することによって、プレイヤがゲームサーバから提供される各種ゲームサービスを受けることができるゲームシステムがある。
【０００３】
従来、上記のようなゲームシステムにおいて、プレイヤのゲームサービスの継続利用を促すために、プレイヤのゲームサーバへのアクセスレベルに応じてプレイヤに特典を付与するゲームシステムが提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１４４７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ところで近年、人と人とのつながりを促進・サポートするコミュニティ型のサービスであるソーシャルネットワーキングサービス（ＳＮＳ）のシステムに、前記ゲームシステムが組み込まれ、ＳＮＳのサービスの一つとして提供される、いわゆるソーシャルゲームが普及している。このようなソーシャルゲームにおいては、各プレイヤがゲームサービスを利用している他のプレイヤと仲間になったり、仲間のプレイヤとコミュニケーションをとったりすることでポイントを取得できる等、ゲーム上有利になるシステムになっている。このように、ソーシャルゲームでは、プレイヤ同士のコミュニケーションの促進を図ることにより、ゲームの興趣性を高めている。
【０００６】
そして、前記ソーシャルゲームのようなプレイヤ同士のつながりや交流関係を大切にするゲームサービスをプレイヤに提供する場合には、いかにゲームコミュニティの活性化を図るかということがゲームシステム構築の上で重要な要素となる。
【０００７】
しかしながら、前記従来のゲームシステムのように、プレイヤのゲームサーバへのアクセスレベルに応じて当該プレイヤに特典を付与するだけでは、ゲームサービスを受けているプレイヤ同士のコミュニケーションの促進を十分に図ることはできず、ゲームコミュニティの活性化には繋がり難い。
【０００８】
本発明は、上記の問題に鑑みてなされたものであり、その目的は、従来よりもゲームコミュニティの活性化を図ることによって興趣性の高いゲームサービスを提供することができるゲーム管理装置、ゲーム管理方法及びプログラムを実現することである。
【課題を解決するための手段】
【０００９】
（１）本発明の一局面によるゲーム管理装置は、ゲームサービスを受ける各プレイヤの端末装置からのネットワークを介したアクセスを受け付けて各プレイヤのゲーム情報を管理し、各プレイヤに前記ネットワークを介した前記ゲームサービスを提供するゲーム管理装置であって、（ａ）各プレイヤの前記アクセスの情報を記憶装置に記憶して、プレイヤ毎の前記アクセスを管理するアクセス管理手段と、（ｂ）連続した規定期間数の単位期間の全てについて前記アクセスを行った連続アクセス達成のプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する連続アクセス特典付与手段と、（ｃ）各プレイヤを中心とするグループに所属する仲間プレイヤの情報を記憶装置に保存してプレイヤ毎の仲間管理を行う仲間管理手段と、（ｄ）連続した規定期間数の前記単位期間のうちアクセスを行わなかった欠落単位期間が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する仲間応援アクセス判定手段と、を備えている。そして、前記連続アクセス特典付与手段は、連続した規定期間数の前記単位期間のうち前記欠落単位期間が存在するプレイヤであっても、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしていると前記仲間応援アクセス判定手段が判定した場合は、当該プレイヤに前記連続アクセス達成特典を付与する構成である。
【００１０】
この構成によれば、本ゲーム管理装置は、各プレイヤの端末装置からのネットワークを介したアクセスを受け付けて各プレイヤのゲーム情報を管理しながら、ネットワークを介して各プレイヤへゲームサービスを提供するものであり、例えばサーバなどのネットワーク接続可能な情報処理装置により構成される。本ゲーム管理装置により各プレイヤに提供されるゲームサービスとしては、例えばプレイヤ同士が協力したりコミュニケーションをとったりしながらプレイすることができるソーシャルゲーム等のサービスがある。
【００１１】
このゲーム管理装置は、各プレイヤの前記アクセスの情報を記憶装置に記憶して、プレイヤ毎の前記アクセスを管理するアクセス管理手段を備えている。そして、本ゲーム管理装置は、連続した規定期間数の単位期間の全てについてアクセスを行った連続アクセス達成のプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する連続アクセス特典付与手段を備えている。例えば、現実世界における１日を単位期間とし、連続した規定期間数を５とした場合、５日間連続でゲーム管理装置にアクセスしたプレイヤに対して、連続アクセス達成特典が付与される。
【００１２】
なお、前記の単位期間は、現実世界における１日に限らず、例えば半日（１２時間）や２日等であってもよく、任意の期間を単位期間として設定することができる。また、連続した規定期間数も、５に限らず任意の期間数を設定することができる。また、前記のアクセスとは、各プレイヤの端末装置からのネットワークを介したゲーム管理装置に対するアクセスであって、ゲーム管理装置が提供するゲームサービスの（Ａ）トップページ（ゲームのメイン画面ページ）、（Ｂ）実際のゲームを実行するための特定ページ、（Ｃ）全てのページの中の何れかのページという（Ａ）〜（Ｃ）のいずれのページに対するアクセスであってもよい。例えば、実際のゲームを実行する特定ページまで進んだことをもって、アクセスしたと判断し、トップページを見ただけで終了するケースはアクセスとはみなさない、というようにアクセスについての条件を若干厳しくしてもよい。
【００１３】
また、前記の連続アクセス達成特典は、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、ゲームの種類や内容に応じて様々な特典を適用できる。一例を挙げると、ポイントやアイテムが使用されるゲームであれば、ゲームを有利に進めることができるポイントやアイテムをプレイヤに付与するという連続アクセス達成特典が考えられる。また、野球ゲームやサッカーゲームなどのようにプレイヤ同士で対戦することができる対戦型ゲームでは、対戦ｎ回分（例えば対戦３回分）だけ戦力が向上し、対戦が有利になるという連続アクセス達成特典が考えられる。また、ゲームのシステムとして、アイテムを抽選によって獲得できるという構成が設けられている場合には、レアアイテム（通常のアイテムよりも抽選確率が低く、希少価値が高いアイテム）を抽選で獲得できる確率を所定回数（例えば１回）だけ上昇させるという連続アクセス達成特典も考えられる。
【００１４】
また、本ゲーム管理装置は、プレイヤ毎の仲間管理を行う仲間管理手段を備え、各プレイヤを中心とする「仲間」というグループに所属する仲間プレイヤの情報を、記憶装置に記憶して管理している。なお、ここでいうグループとは、あくまで１プレイヤの視点から見た自分の仲間の集団を示しており、これらの集団を構成する各プレイヤがこの集団のみに所属するわけではない。各プレイヤもまた、個々に自分を中心とする「仲間」のグループを有している。
【００１５】
さらに、本ゲーム管理装置は、連続した規定期間数の単位期間のうちアクセスを行わなかった欠落単位期間が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する仲間応援アクセス判定手段を備えている。ここで、応援アクセス条件は、仲間プレイヤのアクセスに関する条件であればよく、任意の条件を設定可能である。応援アクセス条件の例としては、後述のように、欠落単位期間と同一の単位期間内にアクセスを行った仲間プレイヤの人数または割合が、閾値を超えることである。そして、連続した規定期間数の単位期間の中にアクセスを欠落した欠落単位期間が存在するプレイヤであっても、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしていると仲間応援アクセス判定手段が判定した場合は、当該プレイヤに連続アクセス達成特典を付与するようになっている。例えば、プレイヤが何かの用で１日、ゲーム管理装置にアクセスできなかったとしても、当該プレイヤの仲間が応援アクセス条件を満たしていれば、当該１日の欠落単位期間をないものとし、この欠落単位期間の埋め合わせを含めて規定期間数の連続アクセスを達成しているならば、当該プレイヤには連続アクセス達成特典が付与されるのである。
【００１６】
これにより、プレイヤの仲間が応援アクセス条件を満たすような高いアクセス頻度を維持してくれることにより、プレイヤが何かの用でゲーム管理装置にアクセスできなかった場合でも、プレイヤが連続アクセス達成特典を獲得できるというメリットが生じる。また、プレイヤ自身も高いアクセス頻度を維持すれば、他の仲間がアクセスを欠落したときの応援アクセス条件の達成に貢献することができ、間接的に他の仲間を支援できることにもなる。これにより、各プレイヤは、仲間同士でお互いにアクセス頻度を高め合おうという意識付け、動機付けを与えられることになる。よって、各プレイヤは、仲間全体のアクセス頻度を高めようとして、自己の仲間プレイヤとコミュニケーションをとる動機付けを与えられることになる。例えば、各プレイヤは、仲間に対して「アクセス頑張ろう！」のようなメッセージを送って、自己の仲間プレイヤとの間のコミュニティを盛り上げようとする。
【００１７】
このように、本構成では、単に特典を受けることの面白さをプレイヤに提供するにとどまらず、仲間同士でお互いにアクセス頻度を高め合おうという動機付けおよび仲間とコミュニケーションをとろうとする動機付けをプレイヤに与え、これにより、ゲームコミュニティ全体の活性化を図ることができる。この結果、各プレイヤはゲーム内での仲間同士のつながりや交流を強め、延いてはゲームに対する関心と興味をより強めることとなるので、プレイヤにとって飽きのこない継続性を有するゲームを実現できる。
【００１８】
（２）上記の構成において、前記応援アクセス条件は、前記欠落単位期間と同一の単位期間内に前記アクセスを行った前記仲間プレイヤの人数または当該仲間プレイヤ全体に占める割合が、閾値を超えることであることが好ましい。
【００１９】
この構成によれば、プレイヤがアクセスできなかった欠落単位期間と同一の単位期間を対象として、応援アクセス条件を満たしたか否かの判定がなされる。例えば、欠落単位期間を現実世界の１日とした場合、プレイヤがアクセスを欠落した日と同じ日にゲーム管理装置にアクセスした仲間プレイヤの人数または割合（仲間プレイヤ全体に占める割合）が閾値を超えていることが応援アクセス条件となる。
【００２０】
このような応援アクセス条件にすることにより、プレイヤは、欠落単位期間と同一の単位期間（例えば、欠落日と同じ日）に、仲間による応援アクセス条件が満たされるように、何かの用でアクセスが欠落しそうな単位期間の予定を、予め他の仲間に連絡しておくことができる。例えば、プレイヤは、仲間に対して「明日はアクセスできないので応援アクセスお願いします！」のようなメッセージを送って、応援アクセス（仲間の具体的なアクションとしては、要するに単にゲームにアクセスすること）を事前依頼することができる。このように、応援アクセスを事前依頼することにより仲間同士のコミュニティが盛り上がる。また、応援アクセスを事前依頼した日（単位期間）に、実際に仲間が応援アクセス条件を満たしてくれることにより、仲間意識が高まって仲間同士のつながりがより強くなり、プレイヤはゲームに対する関心と興味をより一層強くする。
【００２１】
（３）上記の構成において、ゲーム管理装置は、前記欠落単位期間が存在するプレイヤにおける前記仲間プレイヤの前記アクセスの頻度に基づいて、当該プレイヤを中心とするグループの評価値を算出する評価値算出手段をさらに備え、前記応援アクセス条件は、前記評価値算出手段により算出された前記評価値が閾値を超えることであることが好ましい。すなわち、上記の（２）項の構成とは異なる応援アクセス条件の例である。
【００２２】
この構成によれば、欠落単位期間が存在するプレイヤの仲間プレイヤのアクセス頻度に基づいて、当該プレイヤを中心とするグループの評価値を算出し、当該評価値が閾値を超えることを応援アクセス条件としている。ここで、グループの評価値とは、プレイヤを中心とするグループに所属する仲間プレイヤのアクセス頻度の平均値や合計値、仲間うちの（仲間というグループ内の）最大値や最小値等を示す。
【００２３】
このような応援アクセス条件にすることにより、プレイヤの仲間プレイヤが応援アクセス条件を満たすためには、仲間プレイヤのアクセスの頻度を高めることによってグループの評価値を上げる必要がある。よって、各プレイヤは、グループに所属する仲間プレイヤのアクセスの頻度を高めようとして、自己の仲間プレイヤと積極的にコミュニケーションをとる動機付けを与えられることになる。これにより、ゲームコミュニティ全体の活性化を図ることができる。
【００２４】
（４）上記の（１）項ないし（３）項の何れかの構成において、前記単位期間は現実世界における１日であり、前記アクセスができない日程が予め分かっているプレイヤの前記端末装置から送信されたアクセス不可能予定日の情報を受信するとともに、当該アクセス不可能予定日の情報を当該プレイヤの仲間プレイヤ全員の端末装置へ送信し、当該アクセス不可能予定日を当該仲間プレイヤ全員へ伝達するアクセス不可能予定日伝達手段をさらに備えていることが好ましい。
【００２５】
上述のように、プレイヤがゲーム管理装置にアクセスできない欠落単位期間があっても、仲間が応援アクセス条件を満たしてくれることにより、欠落単位期間が埋め合わせされて連続アクセス達成特典を獲得できるようになっている。そこで、プレイヤは、予めゲーム管理装置にアクセスできない予定がわかっている場合、仲間が応援アクセス条件を満たしてくれるように、仲間に対してアクセス不可能予定日を通知することもある。ここで、上記の構成によれば、プレイヤは、簡単な操作によって、アクセス不可能予定日を自己の仲間全員に通知することができる。
【００２６】
すなわち、通常、プレイヤが自己の仲間にメッセージ等を送信する場合、仲間の一人ひとりに対しての送信操作が必要である。しかしながら、仲間の人数が多い場合には、アクセス不可能予定日等を記したメッセージを、プレイヤの仲間一人ひとりに送信するには多くの時間と労力を要することになる。これに対して、本構成では、プレイヤがアクセス不可能予定日をゲーム管理装置へ１回だけ送信する操作を行うだけで、アクセス不可能予定日伝達手段が、当該アクセス不可能予定日の情報を、当該プレイヤの仲間プレイヤ全員の端末装置へ送信する。よって、プレイヤは１回の操作で自己の仲間全員にアクセス不可能予定日を通知することが可能であり、プレイヤ側の操作の容易化が図られる。特に、ソーシャルゲーム等のプレイヤによる操作の容易化が強く求められるゲームサービスには、本構成が好適である。
【００２７】
（５）上記の（４）項の構成において、前記仲間応援アクセス判定手段は、プレイヤが前記アクセス不可能予定日伝達手段によって仲間プレイヤへアクセス不可能予定日を事前に伝達した上で当該アクセス不可能予定日と同じ日に前記アクセスを行わなかった場合に限り、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしているか否かを判定することが好ましい。
【００２８】
この構成によれば、以下に示すように、ゲーム管理装置の処理負担を大幅に軽減できる。すなわち、応援アクセス条件を満たしているか否かの判定は、原則、単位期間内にアクセスをしなかったプレイヤに対して、アクセスの欠落が生じる度に行われる処理である。よって、ゲーム管理装置が管理しているプレイヤ（ゲームサービスを受けているプレイヤ）が多くなるほど、アクセスの欠落を生じるプレイヤの数も多くなるため、ゲーム管理装置の処理負荷は大きくなる。例えば１００万人のゲームサービス利用者のうちの約１割にアクセスの欠落が生じただけでも、１０万人程度のプレイヤに対して応援アクセス条件を満たしているか否かの判定処理が実行されることになる。そして、この応援アクセス条件を満たしているか否かの判定処理は、プレイヤがゲーム管理装置にゲームサービス実行を積極的に要求して行われる処理ではなく、プレイヤがゲーム管理装置へアクセスしなかったという消極的な事実に対して行われる処理でもあることから、できるだけゲーム管理装置の処理負荷を軽減して実行したい処理でもある。
【００２９】
そこで、本構成では、プレイヤによるアクセス不可能予定日の仲間への事前通知を、応援アクセス条件を満たしているか否かの判定処理を実行するための条件とし、事前通知したアクセス不可能予定日と同じ日にプレイヤがアクセスを行わなかった場合に限り、応援アクセス条件を満たしているか否かの判定がなされるようにする。これにより、ゲーム管理装置は、アクセス不可能予定日を事前通知しているプレイヤに限定して、応援アクセス条件を満たしているか否かの判定処理や、当該条件を満たしている場合のその後の処理を行うことができるため、処理負担を大幅に軽減できる。
【００３０】
また、プレイヤにとっては、仲間プレイヤへアクセス不可能予定日を事前に通知していない日に、ゲーム管理装置へアクセスをしなかった場合、応援アクセス条件を満たしているか否かの判定を受けられず、よって欠落単位期間の埋め合わせがされることはない。よって、各プレイヤは、アクセスできそうにない日が予定されている場合、仲間に対して積極的にアクセス不可能予定日を通知して応援アクセスの事前依頼を行うようになり、これによって仲間同士のコミュニケーションの活性化も図れる。
【００３１】
（６）上記の（１）ないし（５）項の何れかの構成において、前記仲間応援アクセス判定手段は、連続した規定期間数の前記単位期間の中に前記欠落単位期間として第１欠落単位期間と当該第１欠落単位期間より後に生じた第２欠落単位期間とが存在する場合、前記第１欠落単位期間より前記第２欠落単位期間の方が前記応援アクセス条件を満たし難い条件に設定することが好ましい。
【００３２】
この構成によれば、時系列的に後に生じた欠落単位期間（第２欠落単位期間）の方が、それより前に生じた欠落単位期間（第１欠落単位期間）よりも厳しい応援アクセス条件を適用する。例えば、現実世界における１日を単位期間とした場合、アクセスの欠落日の１日目より２日目の方が、あるいは欠落日の２日目より３日目の方が、より厳しい応援アクセス条件を適用する。一例を挙げると、欠落日の１日目（第１欠落単位期間）を埋め合わせするための応援アクセス条件を「欠落日と同一の日にアクセスをした仲間プレイヤが８０％以上であること」とし、欠落日の２日目（第２欠落単位期間）を埋め合わせするための応援アクセス条件を「欠落日と同一の日にアクセスをした仲間プレイヤが９０％以上であること」とする。
【００３３】
このように、時系列的に後に生じた欠落単位期間（第２欠落単位期間）の方が、それより前に生じた欠落単位期間（第１欠落単位期間）よりも厳しい応援アクセス条件を適用することにより、複数の欠落単位期間に対する埋め合わせが容易になされることを回避することができる。また、時系列的に後に生じた第２欠落単位期間に対する応援アクセス条件を厳しくしながらも複数の欠落日に対する埋め合わせを許容することによって、厳しい条件を達成するために仲間同士でお互いにアクセス頻度を一層高めようという意識付け、動機付けをプレイヤに与えることができる。
【００３４】
（７）上記の（１）ないし（６）項の何れかの構成において、ゲーム管理装置は、前記欠落単位期間の経過後に、前記仲間プレイヤが前記応援アクセス条件を満たしていると前記仲間応援アクセス判定手段に判定されたプレイヤの端末装置に対して、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしたことによって連続アクセスが継続している旨を報知する報知手段をさらに備えていることが好ましい。
【００３５】
この構成によれば、プレイヤがゲーム管理装置にアクセスを行わなかったことにより欠落単位期間が生じても、仲間プレイヤが応援アクセス条件を満たすアクセスを行ったことによって当該プレイヤの連続アクセスが途切れることなく継続した状態となった場合に、欠落単位期間の経過後に、報知手段によって「仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している」旨が当該プレイヤに報知される。これにより、プレイヤは、欠落単位期間の経過後に、仲間の応援アクセスにより連続アクセスが継続している事実を明確に認識できる。よって、プレイヤは、仲間の存在を強く意識するとともに、以降も連続的にゲーム管理装置にアクセスして連続アクセス達成特典を獲得しようとする意識が強く働く。このため、プレイヤによる継続的なゲーム管理装置へのアクセスを、効果的に促すことができる。
【００３６】
（８）上記の（１）ないし（７）項の何れかの構成において、ゲーム管理装置は、前記欠落単位期間が存在するプレイヤの仲間プレイヤが前記応援アクセス条件を満たすことによって前記連続アクセス達成特典が付与されたプレイヤの仲間プレイヤであって、当該応援アクセス条件を満たす前記アクセスを行った仲間プレイヤに対して、ゲーム上有利になるように当該仲間プレイヤのゲーム情報を変更して応援アクセス特典を付与する応援アクセス特典付与手段をさらに備えていることが好ましい。
【００３７】
この構成によれば、アクセスを行わなかった欠落単位期間が存在するプレイヤの仲間プレイヤが応援アクセス条件を満たしたことにより当該プレイヤが連続アクセスを達成して連続アクセス達成特典を獲得した場合には、この連続アクセス達成に貢献した仲間プレイヤ（応援アクセス条件を満たすアクセスを行った仲間プレイヤ）に対しても、応援アクセス特典が付与される。ここで、応援アクセス特典とは、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、上述の連続アクセス達成特典と同様に、ゲームの種類や内容に応じて様々な特典を適用できる。
【００３８】
このように、プレイヤの連続アクセス達成に貢献した当該プレイヤの仲間プレイヤにも応援アクセス特典を付与することにより、各プレイヤは、仲間の応援アクセスを積極的に行おうとする意識付け、動機付けが与えられることになる。
【００３９】
（９）上記の（１）ないし（８）項の何れかの構成において、ゲーム管理装置は、プレイヤを中心とするグループの中に前記連続アクセス達成特典が付与された仲間プレイヤが所定の人数以上または所定の割合以上いる当該プレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して仲間特典を付与する仲間特典付与手段をさらに備えていることが好ましい。
【００４０】
この構成によれば、プレイヤを中心とする仲間のグループの中に、連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる場合、当該プレイヤに仲間特典が付与される。つまり、連続アクセス達成特典を獲得した仲間プレイヤを自己のグループ内に多く持つことによって、プレイヤは仲間特典という連続アクセス達成特典とは別の特典を獲得できる。ここで、仲間特典とは、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、上述の連続アクセス達成特典と同様に、ゲームの種類や内容に応じて様々な特典を適用できる。
【００４１】
そして、本構成が、「応援アクセスによる欠落単位期間の埋め合わせによって仲間が連続アクセス達成特典を獲得し易くなる」という上述の構成と相俟って、各プレイヤには、自己の仲間の多くが連続アクセス達成特典を獲得できるようにアクセス頻度を高めようとする意識付け、動機付けが与えられることになる。すなわち、各プレイヤには、連続アクセス達成特典と併せて仲間特典を獲得できるチャンスもあるので、自分が連続アクセス達成特典を獲得するためだけでなく、多くの仲間プレイヤが連続アクセス達成特典を獲得できるようにするために、プレイヤはゲーム管理装置へのアクセス頻度を高めようとする動機付けが与えられる。また、連続アクセスが途中で途絶えて連続アクセス達成特典を獲得できなくなったプレイヤにとっても、自己の仲間プレイヤの多くが連続アクセス達成特典を獲得すれば仲間特典を獲得できるチャンスがある。よって、応援アクセスにより多くの仲間プレイヤが連続アクセス達成特典を獲得できるようにするために、プレイヤはゲーム管理装置へのアクセス頻度を高めようとする動機付けが与えられる。
【００４２】
（１０）本発明の他の一局面によるゲーム管理方法は、ゲームサービスを受ける各プレイヤの端末装置からのネットワークを介したアクセスを受け付けて各プレイヤのゲーム情報を管理し、各プレイヤに前記ネットワークを介した前記ゲームサービスを提供するゲーム管理装置におけるゲーム管理方法であって、（ｅ）前記ゲーム管理装置が、各プレイヤの前記アクセスの情報を記憶装置に記憶して、プレイヤ毎の前記アクセスを管理するアクセス管理ステップと、（ｆ）前記ゲーム管理装置が、連続した規定期間数の単位期間の全てについて前記アクセスを行った連続アクセス達成のプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する連続アクセス特典付与ステップと、（ｇ）前記ゲーム管理装置が、各プレイヤを中心とするグループに所属する仲間プレイヤの情報を記憶装置に保存してプレイヤ毎の仲間管理を行う仲間管理ステップと、（ｈ）前記ゲーム管理装置が、連続した規定期間数の前記単位期間のうちアクセスを行わなかった欠落単位期間が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する仲間応援アクセス判定ステップと、を備えている。そして、前記連続アクセス特典付与ステップは、連続した規定期間数の前記単位期間のうち前記欠落単位期間が存在するプレイヤであっても、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしていると前記仲間応援アクセス判定ステップが判定した場合は、当該プレイヤに前記連続アクセス達成特典を付与する構成である。
【００４３】
（１１）本発明の更に他の一局面によるプログラムは、コンピュータを前記ゲーム管理装置として動作させるためのプログラムであって、当該コンピュータを、前記ゲーム管理装置が備えている前記各手段として機能させるためのものである。
【発明の効果】
【００４４】
本発明によれば、仲間とのコミュニケーションをとる動機付けを各プレイヤに与え、これにより、ゲームコミュニティ全体の活性化を図ることができる。この結果、各プレイヤはゲーム内での仲間同士のつながりや交流を強め、延いてはゲームに対する関心と興味をより強めることとなり、プレイヤにとって飽きのこない継続性を有する興趣性の高いゲームサービスを提供できる。
【図面の簡単な説明】
【００４５】
【図１】本発明の一実施の形態に係るゲームシステムの構成例を示す説明図である。
【図２】ゲーム管理装置のハード構成の一例を示すブロック図である。
【図３】端末装置のハード構成の一例を示すブロック図である。
【図４】ゲーム管理装置の機能的構成の一例を示す機能ブロック図である。
【図５】ゲーム情報管理手段の機能的構成の一例を示す機能ブロック図である。
【図６】ゲーム情報管理手段がデータベースサーバに保存して管理するゲーム情報の一例を示す説明図である。
【図７】仲間情報記憶部が記憶する各プレイヤの仲間に関する情報の一例を示す説明図である。
【図８】仲間情報記憶部が記憶する各プレイヤの仲間に関する情報の他の例を示す説明図である。
【図９】アクセス情報記憶部が記憶する各プレイヤのアクセス情報の一例を示す説明図である。
【図１０】特典の発生を報知するための画面例を示す説明図である。
【図１１】連続アクセス継続中を報知するための画面例を示す説明図である。
【図１２】メッセージ記憶部が記憶する受信メッセージ情報の一例を示す説明図である。
【図１３】仲間リスト画面の一例を示す説明図である。
【図１４】ゲームシステムの動作の一例を示すフローチャートである。
【図１５】プレイヤがアクセスを欠落したときの処理の一例を示すフローチャートである。
【図１６】連続アクセス達成特典の発生処理の一例を示すフローチャートである。
【図１７】ゲーム進行処理の一例を示すフローチャートである。
【図１８】プレイヤがアクセスを欠落したときの処理の他の例を示すフローチャートである。
【図１９】ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。
【図２０】ゲームサーバへのアクセス実績の一例を説明する説明図である。
【図２１】プレイヤがアクセスを欠落したときの処理の他の例を示すフローチャートである。
【図２２】ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。
【図２３】予定日情報記憶部が記憶する予定日情報の一例を示す説明図である。
【図２４】アクセス不可能予定通知画面の一例を示す説明図である。
【図２５】仲間の情報を表示する画面の一例を示す説明図である。
【図２６】プレイヤがアクセスを欠落したときの処理の他の例を示すフローチャートである。
【図２７】ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。
【図２８】応援アクセス特典の発生処理の一例を示すフローチャートである。
【図２９】仲間アクセス特典の発生処理の一例を示すフローチャートである。
【図３０】ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。
【図３１】仲間候補リスト画面の一例を示す説明図である。
【図３２】仲間リスト画面の他の例を示す説明図である。
【図３３】ゲーム管理装置の機能的構成の他の例を示す機能ブロック図である。
【図３４】仲間情報記憶部が記憶する各プレイヤの仲間に関する情報の他の例を示す説明図である。
【図３５】特典の付与調整処理を含むゲームサーバの動作例を示すフローチャートである。
【図３６】特典の付与調整処理を含むゲームサーバの他の動作例を示すフローチャートである。
【図３７】特典の付与調整処理を含むゲームサーバの他の動作例を示すフローチャートである。
【発明を実施するための形態】
【００４６】
以下、本発明の一実施の形態に係るゲーム管理装置、ゲーム管理方法及びプログラムについて、図面を参照しながら説明する。
【００４７】
〔ゲームシステムの概要〕
本発明の一実施の形態に係るゲーム管理装置が組み込まれたゲームシステムの構成例を、図１に示している。同図に示すように、このゲームシステムは、インターネットなどのネットワーク４上に設置されたゲームサーバ１と、当該ゲームサーバ１と通信可能に接続されたデータベースサーバ２と、ネットワーク４を介してゲームサーバ１と通信可能に接続できる各プレイヤの端末装置３とによって構成される。
【００４８】
本実施の形態のネットワーク４は、インターネットに限定されるものではなく、ゲームサーバ１と各プレイヤの端末装置３との間を通信可能に相互に接続できるものであれば、例えば、専用回線、公衆回線（電話回線、移動体通信回線等）、有線ＬＡＮ（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の個体識別番号が登録済みであるか否かを判断してログイン認証を行うことができる。
【０１１７】
次に、アクセス管理手段５５について説明する。アクセス管理手段５５は、各プレイヤのゲームサーバ１へのアクセスの情報を、データベースサーバ２（記憶装置）に記憶してプレイヤ毎のアクセスを管理する。ここで、アクセスの情報とは、各プレイヤのアクセス履歴（アクセスの日時等）、現実世界の１日のアクセス回数、現実世界の各日のアクセスの有無等の情報である。
【０１１８】
このアクセス管理手段５５は、所定の単位期間毎のゲームサーバ１へのアクセスの有無をプレイヤ毎に管理する機能を有する。この所定の単位期間毎のアクセスの有無の管理情報は、連続した規定期間数の単位期間の全てについてアクセスを行った連続アクセス達成のプレイヤに対して連続アクセス特典を付与する連続アクセス特典付与手段５７における連続アクセス達成の判定に用いられる。本実施の形態では、アクセス管理手段５５が所定の単位期間毎のアクセスの有無をプレイヤ毎に管理するようにしているが、アクセス管理手段５５では各プレイヤのアクセスの日時等のみを記憶したアクセス管理にとどめ、連続アクセス特典付与手段５７にて所定の単位期間毎のアクセスの有無を判断するようにしてもよい。
【０１１９】
以下の説明では、本実施の形態のアクセス管理手段５５が、現実世界における１日を単位期間とし、各日のゲームサーバ１へのアクセスの有無（１日に少なくとも１回以上のアクセスを行なったか否か）を、プレイヤ毎に管理する例について説明する。
【０１２０】
図９（ａ）には、アクセス情報記憶部５５ａがデータベースサーバ２に記憶して管理する、各プレイヤのアクセス情報の一例を示している。アクセス情報記憶部５５ａは、プレイヤＩＤと対応付けて、現実世界における本日、１日前、２日前、３日前、４日前、・・・、ｎ日前（本実施の形態の場合、ｎは５以上の自然数）の各日についてのゲームサーバ１へのアクセスの有無（単位期間内アクセスを達成したか否か）を示す情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。この情報が「１」の場合、１日に最低１回はゲームサーバ１へのアクセスがあったことを示す一方、この情報が「０」の場合、１日に１回もゲームサーバ１へのアクセスがなかったことを示している。本実施の形態の例では５日間連続アクセスにより特典が付与されるので、少なくとも前日までの直近５日間のアクセスの有無を示す情報が記憶されていればよい。
【０１２１】
なお、アクセス情報記憶部５５ａが記憶するアクセス情報は、図９（ａ）の例に限定されるものではなく、例えば、図９（ｂ）に示すように、現実世界における本日、１日前、２日前、・・・ｎ日前の各日についてのゲームサーバ１へのアクセス回数であってもよい。このアクセス回数の情報は、当該情報が「０」であるか否かにより、単位期間内アクセス（本実施の形態では１日に最低１回のアクセス）を達成したか否かを管理するための情報となる。
【０１２２】
また、アクセス情報記憶部５５ａは、プレイヤＩＤと対応付けて、プレイヤの仲間が応援アクセス条件を満たしたか否かを示す情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。この情報は、後述する仲間応援アクセス判定手段５６による判定結果を示す情報である。
【０１２３】
さらに、アクセス情報記憶部５５ａは、プレイヤＩＤと対応付けて、プレイヤがゲームサーバ１へアクセスした連続日数である連続アクセス日数も、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。この連続アクセス日数は、プレイヤがゲームサーバ１へアクセスした日、およびアクセスしたとみなされた日（プレイヤがアクセスしなかった欠落日と同じ日にプレイヤの仲間が応援アクセス条件を満たしたことによってアクセスしたとみなされた日）の連続日数をカウントしたものである。この連続アクセス日数は、プレイヤによる連続アクセス（アクセスしたとみなされた場合を含む）が途絶えたとき、および５日間の連続アクセス達成によりプレイヤに特典が付与されたときに初期化（リセット）される。
【０１２４】
連続５日間のうち埋め合わせ可能な欠落日を例えば１日のみとした場合、１日目の欠落日に対する応援アクセス条件が満たされたことによって連続アクセスの継続状態が維持されたとしても、その後２日目の欠落日が確定したとき、前記の連続アクセス日数は初期化される。すなわち、埋め合わせ可能な欠落日をｎ日とした場合、（ｎ＋１）日目の欠落日が確定したときには、その時点で連続アクセスが途切れることになり、連続アクセス日数が初期化される。
【０１２５】
埋め合わせ可能な欠落日の日数については、任意に設定することができる。ただし、埋め合わせ可能な欠落日を多く許容し過ぎると、プレイヤ自身が実際にはあまりゲームサーバ１へアクセスしていなくとも、欠落日が埋め合わされて連続アクセス達成特典を獲得してしまう可能性もあることから、埋め合わせ可能な欠落日には上限を設けることが望ましい。本実施の形態では、先ず、埋め合わせ可能な欠落日を１日に限定した例について、以下に説明し、埋め合わせ可能な欠落日を複数許容する場合については後述する。
【０１２６】
次に、仲間応援アクセス判定手段５６について説明する。仲間応援アクセス判定手段５６は、連続した５日間のうちゲームサーバ１へアクセスをしなかった欠落日が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する機能を有する。
【０１２７】
ここで、応援アクセス条件としては、様々な任意の条件を設定可能である。応援アクセス条件の一例としては、「欠落日と同一の日に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合が、閾値以上」とすることができる。プレイヤ自身を含む仲間プレイヤがｘ人、欠落日と同一の日に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの人数をｙ人、閾値をｚとすると、「ｙ／ｘ≧ｚ」が応援アクセス条件となる。例えば閾値を０．８（百分率で８０％）とした場合、プレイヤ自身を含む１０人の仲間のうち、８人以上の仲間プレイヤがゲームサーバ１にアクセスしていれば、この応援アクセス条件を満たす。
【０１２８】
ここで、前述のように仲間プレイヤとは、各プレイヤを中心とする仲間というグループに所属するプレイヤであり、基本的にはグループの中心をなすプレイヤ自身も仲間プレイヤに含まれる。ただし、プレイヤ自身は欠落日にはアクセスしていないので、当該プレイヤを仲間プレイヤから除外し、欠落日と同一の日にアクセスした仲間プレイヤの割合を算出してもよい。すなわち、「ｙ／（ｘ−１）≧ｚ」を応援アクセス条件としてもよい。
【０１２９】
仲間の人数が多いときは、「ｙ／ｘ≧ｚ」または「ｙ／（ｘ−１）≧ｚ」の何れを応援アクセス条件としても大きな違いはないが、仲間の人数が少なくなればその違いが顕著になる。例えば、プレイヤ自身を含む仲間プレイヤｘが４人で閾値ｚ＝０．８とした場合を考えると、「ｙ／ｘ≧ｚ」を条件としたとき、プレイヤ自身はアクセスしていないので、他の仲間プレイヤ３人が全員アクセスしたとしても、ｙ／ｘ＝３／４＝０．７５となって条件を満たさないことになる。一方、「ｙ／（ｘ−１）≧ｚ」を条件としたとき、プレイヤ自身を除く３人がアクセスすればｙ／（ｘ−１）＝３／３＝１．００となって条件を満たしてしまう。すなわち、「ｙ／ｘ≧ｚ」を条件としたとき、プレイヤ自身を含む仲間プレイヤｘが４人以下であれば決して条件を満たすことはない一方、「ｙ／（ｘ−１）≧ｚ」を条件としたときには、ｘが４人以下のときにも僅かな人数の仲間プレイヤのアクセスによって容易に条件を満たすこととなる。「ｙ／ｘ≧ｚ」を条件とすることにより、応援アクセス条件を満たすためにはまず仲間プレイヤｘの人数を５人以上にしなければならず、プレイヤは仲間を少なくとも５人以上は作ろうとする動機付けを与えられることになる。また、「ｙ／ｘ≧ｚ」を条件とすることにより、仲間の人数が少ないときに条件を容易に満たせる状態を回避できる。よって、「ｙ／（ｘ−１）≧ｚ」よりも「ｙ／ｘ≧ｚ」を応援アクセス条件とする方が望ましいと言える。
【０１３０】
応援アクセス条件の他の例としては、「欠落日と同一の日に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの人数が、閾値（例えば１０人）以上」とすることができる。この応援アクセス条件の場合、プレイヤの仲間の合計人数がそもそも閾値に満たない場合には、当該条件を満たすことはない。よって、プレイヤは応援アクセス条件を満たすように、仲間を少なくとも閾値（例えば１０人）以上は作ろうとする動機付けを与えられることになる。また、仲間を多く作る方が応援アクセス条件を満たしやすくなるため、プレイヤは応援アクセス条件をより満たし易くするため、より多くの仲間を作ろうとする動機付けを与えられることになる。なお、応援アクセス条件のさらに他の例については後述する。
【０１３１】
仲間応援アクセス判定手段５６による応援アクセス条件を満たすか否かの判定処理は、プレイヤによるその日のアクセスの有無が確定する午後１２時（２４時）以降、すなわちプレイヤの欠落日の翌日の所定時間に行われる。例えば、欠落日の翌日の０時に、仲間応援アクセス判定手段５６による判定処理が行われる。
【０１３２】
また、仲間応援アクセス判定手段５６による判定結果は、図９（ａ）に示すように、プレイヤの仲間が応援アクセス条件を満たしたか否かを示す１ビットの情報として、当該プレイヤのプレイヤＩＤと対応付けて記憶される。この情報が「１」の場合、プレイヤの仲間が応援アクセス条件を満たしたことを示す一方、この情報が「０」の場合、当該応援アクセス条件を満たさなかったことを示している。なお、本実施の形態では、連続５日間のうち埋め合わせ可能な欠落日を１日のみとしているので、１日目の欠落日に対してのみ仲間応援アクセス判定手段５６による判定処理が行われ、２日目の欠落日に対しては当該判定処理はなされない。プレイヤがアクセスした日（欠落日ではない日）や、欠落日が２日目に該当する場合のように、仲間応援アクセス判定手段５６による判定処理が行われない場合も、当該情報は「０」となる。
【０１３３】
仲間応援アクセス判定手段５６による判定の結果、プレイヤの仲間が応援アクセス条件を満たしている場合、プレイヤによるゲームサーバ１への連続アクセスは継続しているとみなされ、図９（ａ）に示す「連続アクセス日数」が１つインクリメントされることになる。
【０１３４】
次に、連続アクセス特典付与手段５７について説明する。連続アクセス特典付与手段５７は、５日間の連続アクセスを達成したプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する機能を有する。さらに、連続アクセス特典付与手段５７は、連続５日間の中にゲームサーバ１にアクセスしなかった欠落日が存在するプレイヤについても、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしていると仲間応援アクセス判定手段５６が判定した場合には、連続アクセス達成特典を付与するようになっている。
【０１３５】
この連続アクセス特典付与手段５７は、アクセス情報記憶部５５ａが記憶する図９（ａ）の連続アクセス日数の情報に基づいて、プレイヤに連続アクセス達成特典を付与するか否かを判定する特典発生判定部５７ａを備えている。そして、連続アクセス特典付与手段５７は、特典発生判定部５７ａが連続アクセス達成特典を発生させると判定したプレイヤのゲーム情報（ゲーム情報管理手段５１がデータベースサーバ２に記憶して管理しているゲーム情報）を、当該特典の内容に応じて変更する。
【０１３６】
ここで、連続アクセス特典付与手段５７がプレイヤに付与する連続アクセス達成特典について説明する。この連続アクセス達成特典は、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、ゲームの種類や内容に応じて様々な特典が考えられる。
【０１３７】
本実施の形態の野球ゲームにおける連続アクセス達成特典の一例としては、前述の行動力ポイント、運営コスト、強化ポイント、エールポイントなどのプレイヤがゲームを進行させる上で必要となる各種ポイントを、所定ポイント分だけボーナスポイントとしてプレイヤに付与するという特典が挙げられる。このようなボーナスポイントを特典として付与する場合、連続アクセス特典付与手段５７は、ゲーム情報管理手段５１の特典情報記憶部５１ｉが記憶しているプレイヤの特典に関する情報を、当該ボーナスポイントの内容に合わせて変更する。図６の下部には、プレイヤＩＤ＝“０００００１”のプレイヤに特典（ボーナスポイント）が付与された結果、当該プレイヤの特典情報として「強化ポイント＝＋２００」が記憶された例を示している。さらに、連続アクセス特典付与手段５７は、ゲーム情報管理手段５１の所有ポイント記憶部５１ｄが記憶しているプレイヤの所有ポイントを、ボーナスポイント分だけ増加させるようにゲーム情報を変更する。
【０１３８】
連続アクセス達成特典の他の例としては、前述の回復アイテムやフェイクカードなどのゲーム内で有利に使用される各種アイテムを、所定数（例えば３つ）だけプレイヤに付与するという特典も考えられる。ゲーム内で使用されるアイテムを特典として付与する場合、連続アクセス特典付与手段５７は、ゲーム情報管理手段５１の特典情報記憶部５１ｉが記憶しているプレイヤの特典に関する情報を、当該特典の内容に合わせて変更するとともに、所有アイテム記憶部５１ｆが記憶しているアイテムの所有数を、所定数だけ増加させるようにゲーム情報を変更する。
【０１３９】
その他の連続アクセス達成特典の例としては、次のようなものがある。すなわち、ゲーム中に消費されて減った行動力ポイントなどのポイントは、例えば３分経過する毎に１ポイントずつ回復するようになっているが、このポイント回復時間を短縮する（例えば、２分経過する毎に１ポイントずつ回復するようにする）ことが考えられる。この特典が付与される場合、特典情報記憶部５１ｉが記憶しているプレイヤの特典情報として、ポイント回復時間が短縮される有効期間の情報が記憶される。これにより、ゲームサーバ１のゲーム情報管理手段５１が、特典が有効な期間（例えば、プレイヤが特典の通知を受けてから２４時間以内）において、ポイント回復時間を通常時よりも短縮する処理を行うことになる。
【０１４０】
また、前述の選手抽選獲得モードにおいて、レアカード（通常の選手カードよりも抽選確率が低く、希少価値が高い選手カード）が抽選される確率を所定回数（例えば１回）だけ上昇させるという特典も考えられる。この特典が付与される場合、特典情報記憶部５１ｉが記憶しているプレイヤの特典情報として、抽選確率を上昇させる回数が記憶される。そして、ゲームサーバ１のゲーム進行手段５２が、特典対象の抽選実行時に、レアカードの抽選確率を一時的に高める処理を行うことになる。
【０１４１】
また、選手抽選獲得モードにおいて、通常は選手カードの抽選を実行するのにポイント（前記エールポイント等）を必要とするが、所定回数（例えば１回）だけ無料で（すなわちポイントの消費なしに）、選手カードの抽選を受けることができるという特典も考えられる。この特典が付与される場合、特典情報記憶部５１ｉが記憶しているプレイヤの特典情報として、無料（無ポイント）で選手カードの抽選を受けることができる回数が記憶される。
【０１４２】
また、ゲームサーバ１が乱数等により抽選で選んだ選手カードを、所定枚数（例えば１枚）だけプレイヤに付与するという特典も考えられる。ゲームサーバ１が選んだ選手カードを特典としてプレイヤに付与する場合、連続アクセス特典付与手段５７は、ゲーム情報管理手段５１の特典情報記憶部５１ｉが記憶しているプレイヤの特典に関する情報を、当該特典の内容に合わせて変更するとともに、所有選手カード記憶部５１ｃが記憶している選手カードＩＤに、特典として付与される選手カードＩＤを追加する。
【０１４３】
また、他のプレイヤのチームと対戦する対戦モードにおいて、対戦ｎ回分（例えば対戦３回分）だけ有利になるというゲーム上のメリットをプレイヤに付与するという特典も考えられる。対戦ｎ回分のゲーム運びを有利にする方法としては、プレイヤのチームの戦力を対戦ｎ回分だけ向上させる方法が考えられる。
【０１４４】
ここで、特典によってプレイヤのチームの戦力を向上させる場合にも、幾つかの方法がある。対戦モードにおいては、プレイヤが所有している選手カードの中から試合に出場するレギュラー選手の選手カードが選択されて対戦することになる（例えば、プレイヤは、所有している選手カードの中から予め試合に出場するレギュラー選手のカードを選択しておき、当該レギュラー選手のカードでチームオーダーを組んで対戦する）。よって、当然ながら、通常は、プレイヤの手持ち選手カード以外を自己チームの戦力とすることはできない。
【０１４５】
しかし、特典によりチームの戦力を向上させる場合、プレイヤの仲間全員の手持ちカードすべての中で、最強の選手カード（最も能力値が高い選手カード）１枚が、自動的に当該プレイヤのレギュラー選手のカードの１枚と入れ替わるようにする。この場合、ゲームサーバ１のゲーム進行手段５２が、特典対象の対戦の実行時に、自動的に上述の選手カードの入れ替え処理を行うことになる。なお、プレイヤの仲間全員の手持ちカードの中で最強の選手カードを当該プレイヤ自らが所有していた場合、当該最強の選手カードよりも能力値が高い助っ人選手カード（ゲームサーバ１が用意する特別な選手カード）１枚が、自動的に当該プレイヤのレギュラー選手のカードの１枚と入れ替わるようにしてもよい。
【０１４６】
特典によってプレイヤのチーム戦力を向上させる他の方法としては、対戦モードにおいて試合に出場するレギュラー選手の選手カードの一部または全部の能力値を、所定の割合（または所定の値）だけ向上させるという方法もある。この場合、ゲームサーバ１のゲーム進行手段５２が、特典対象の対戦の実行時に、特典を受けたプレイヤのチームの選手カードの能力値を向上させる処理を行なうことになる。
【０１４７】
また、対戦ｎ回分のゲーム運びを有利にする他の方法としては、特典が付与されたプレイヤのチームが勝利する確率を対戦ｎ回分だけ向上させる（よって、対戦相手のプレイヤのチームが勝利する確率をその分低下させる）方法も考えられる。例えば、対戦する両プレイヤのチームの能力が同一であったとすると、何れのプレイヤにも特典が付与されていなければ、両チームの勝利確率はともに５０％であるが、一方のプレイヤに特典が付与されている対戦においては、特典が付与されたプレイヤＸのチームの勝利確率を例えば１０％向上させて６０％とする一方、その対戦相手のプレイヤＹのチームの勝利確率を１０％低下させて４０％として、プレイヤＸの方がプレイヤＹよりも勝利確率の面で有利な状態にする。
【０１４８】
上述のようにチーム戦力の向上または勝利確率の向上等により対戦ｎ回分が有利になるという特典をプレイヤに付与する場合、ゲーム情報管理手段５１の特典情報記憶部５１ｉが記憶しているプレイヤの特典情報として、対戦が有利になる回数が記憶される。
【０１４９】
ところで、あまりに特典を大きくしてしまうと、本来ゲームを実行することで実現される選手カードの能力値の向上（すなわち選手の育成）等とのバランスが崩れる可能性もあるため、当該特典は、あくまでサブ的（副次的）な位置づけとして、プレイヤにとってある程度のお得感を与えるレベルとすることが好ましい。
【０１５０】
次に、報知手段５８について説明する。この報知手段５８は、連続アクセス達成特典が付与されたプレイヤの端末装置３に対して、特典が発生した旨を報知する機能を有する。本実施の形態においては、連続アクセス達成特典が発生するタイミングが大きく分けて２つあり、報知手段５８による特典の報知処理も、以下に示すように特典の発生タイミングに応じて若干異なる。
【０１５１】
連続アクセス達成特典が発生するタイミングの１つは、連続アクセスが達成される最終日（本実施の形態では５日目）にプレイヤがゲームサーバ１にアクセスしたことによって、連続アクセスが達成されたときである。この場合、プレイヤの端末装置３がゲームサーバ１と通信可能に接続されたログイン状態において連続アクセス達成特典が発生するので、報知手段５８は、特典の発生後、直ちに特典が発生した旨をプレイヤの端末装置３に報知することができる。
【０１５２】
連続アクセス達成特典が発生するもう一つのタイミングは、連続アクセスが達成される最終日（本実施の形態では５日目）にプレイヤがゲームサーバ１にアクセスしなかった（すなわち、当該最終日が欠落日になった）が、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが達成されたものとみなされたときである。この場合、プレイヤの端末装置３がゲームサーバ１と通信可能に接続されていない状態において連続アクセス達成特典が発生するので、報知手段５８は、特典の発生後、直ちに特典が発生した旨をプレイヤの端末装置３に報知することができないため、特典が発生した旨をプレイヤに報知したか否かを管理する必要が生じる。そこで、本実施の形態では、図６の下部に示す特典報知フラグによりこれを管理するようにしている。
【０１５３】
すなわち、連続アクセスが達成される最終日に仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが達成されたものとみなされた場合、報知手段５８がプレイヤに特典の報知を行うのは、特典の付与処理後にプレイヤの端末装置３がゲームサーバ１に最初にアクセスしたときであり、特典の付与処理からその報知までにはある程度の時間差がある。そこで、ゲームサーバ１の報知手段５８は、プレイヤに特典が付与されたとき、当該プレイヤのプレイヤＩＤと対応付けて図６に示す特典報知フラグを「１」に設定し、これによって当該プレイヤに特典付与を報知する必要がある状態を管理する。そして、その後、特典報知フラグとして「１」がセットされているプレイヤの端末装置３からゲームサーバ１へのアクセスがあったとき、報知手段５８は、当該プレイヤに特典が付与された旨を報知し、併せて特典報知フラグを「０」にする。
【０１５４】
報知手段５８による特典の報知の例を、図１０（ａ）（ｂ）に示している。図１０（ａ）は、特典が付与されたプレイヤの端末装置３の表示部３５に表示されるゲームのメイン画面の一例を示すものである。ゲームサーバ１における特典付与処理後に、ゲームサーバ１の報知手段５８からは、図１０（ａ）に示すメイン画面を表示させる画面データが、プレイヤの端末装置３へ送信される。このメイン画面には、プレイヤのチーム名７０、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード７１およびプレイヤのゲーム情報７２などが表示されるとともに、特典通知情報７３も表示される。なお、メイン画面の詳細については、後述する。
【０１５５】
図１０（ａ）に示すように、端末装置３のメイン画面に表示される特典通知情報７３は、例えば「５日間連続アクセス達成！特典確認画面へ」というような、連続アクセス達成特典が付与されたことが分かる内容である。また、当該特典通知情報７３にはハイパーリンクが設定されており（または、特典通知情報７３の全体またはその一部が選択可能なボタン形式となっていてもよい）、プレイヤが画面上の特典通知情報７３を選択可能になっている。
【０１５６】
ここで、プレイヤが端末装置３を操作して特典通知情報７３を選択する操作をすると、当該操作に応答して、ゲームサーバ１の報知手段５８からは、図１０（ｂ）に示す特典確認画面を表示させる画面データが端末装置３へ送信されてくる。この特典確認画面には、例えば、「連続アクセス達成ボーナス」という表示とともに、「強化ポイント ＋２００ポイント」というような具体的な特典が表示され、プレイヤは連続アクセス達成特典の内容を確認することができる。また、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセス達成特典が付与された場合には、例えば「アクセスしなかった日が１日ありましたが、仲間の応援アクセスによって５日間連続アクセスを達成できました！」といった内容の文章も、併せて特典確認画面に表示される。これにより、プレイヤは、仲間の応援アクセスにより連続アクセス達成特典が獲得できたことを明確に認識でき、仲間の存在を強く意識する。
【０１５７】
また、図１０（ｂ）に示すように、特典確認画面に「受け取る」ボタン７４を表示させ、プレイヤによって当該ボタン７４が選択されることによって、疑似的にプレゼント（ボーナスポイント）を受け取ることができるようにしてもよい。この場合、「受け取る」ボタン７４が選択されたときに特典としてのボーナスポイントが有効になるようにしてもよい。この特典確認画面において、例えば「メイン画面へ」ボタン７５が選択されると、前記のメイン画面へ戻ることができるようになっている。
【０１５８】
このように本実施の形態では、ゲームサーバ１からプレイヤの端末装置３に送信されるゲームのメイン画面データ内に特典通知情報７３を含ませることによって、特典の発生を各プレイヤに報知するようになっている。メイン画面はゲームの開始時に必ず表示される基本画面であり、このメイン画面内に特典通知情報７３が表示されるようにすることにより、特典の発生を、プレイヤに的確に報知することができる。
【０１５９】
また、このメイン画面にはその他のオブジェクトや情報も多く含まれるため、特典の詳細については、図１０（ｂ）に示す特典確認画面に遷移して確認できるようにしているが、これに限定されるものではない。例えば、プレイヤの端末装置３がゲームサーバ１にアクセスしたとき、メイン画面よりも先に、図１０（ｂ）に示す特典確認画面がプレイヤの端末装置３の表示部３５に表示されるようにし、当該確認画面でプレイヤが連続アクセス達成特典の発生を確認してから、プレイヤによる所定の操作によりメイン画面に遷移するようにしてもよい。
【０１６０】
このように報知手段５８は、メイン画面等に特典の発生情報を表示させてプレイヤへの報知を行うので、前記のゲーム画面生成手段５２ｂおよびゲーム画面送信手段５２ｃと協働して当該報知の処理を行うようになっている。
【０１６１】
また、報知手段５８は、プレイヤがアクセスを欠落した日の経過後（すなわち欠落日の確定後）、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしていると仲間応援アクセス判定手段５６が判定した場合、プレイヤの仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している旨をプレイヤの端末装置３に対して報知する機能を有する。報知手段５８がこの報知処理を行うのは、仲間応援アクセス判定手段５６が応援アクセス条件を満たしていると判定した後、プレイヤの端末装置３がゲームサーバ１に最初にアクセスしたときであり、仲間応援アクセス判定手段５６による判定から報知手段５８による報知までにはある程度の時間差がある。そこで、ゲームサーバ１の報知手段５８は、仲間応援アクセス判定手段５６が応援アクセス条件を満たしていると判定したとき、当該プレイヤのプレイヤＩＤと対応付けて、図９（ａ）に示す連続アクセス継続報知フラグ（同図では継続報知フラグと省略記載）を「１」に設定し、これによって当該プレイヤに連続アクセスが継続している旨を報知する必要がある状態を管理する。そして、アクセスを欠落した日の翌日中に、連続アクセス継続報知フラグとして「１」がセットされているプレイヤの端末装置３からゲームサーバ１へのアクセスがあったとき、報知手段５８は、当該プレイヤに、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している旨を報知し、併せて連続アクセス継続報知フラグを「０」にする。
【０１６２】
なお、仲間プレイヤの応援アクセスにより連続アクセスが一旦は継続した状態になったものの、アクセスを欠落した日の翌日中にプレイヤがゲームサーバ１にアクセスしなかったために、結局、連続アクセスが途切れてしまった場合、報知手段５８による連続アクセス継続中の報知は行われることはない。よって、連続アクセスが途切れたときも、連続アクセス継続報知フラグが「０」に設定されることになる。但し、このように連続アクセスが途切れた場合であっても、ゲームサーバ１の報知手段５８は、仲間プレイヤが応援アクセス条件を満たした事実についてはプレイヤの端末装置３へ報知するようにしてもよい。
【０１６３】
報知手段５８による連続アクセス継続中の旨の報知例を、図１１（ａ）（ｂ）に示している。図１１（ａ）は、ゲームのメイン画面中に連続アクセス継続中の旨を表示してプレイヤに報知する例を示すものである。プレイヤが連続アクセスを欠落した日の翌日において、仲間応援アクセス判定手段５６が仲間による応援アクセス条件を満たしていると判定した後、プレイヤの端末装置３がゲームサーバ１に最初にアクセスしたとき、ゲームサーバ１の報知手段５８からは、図１１（ａ）に示すメイン画面を表示させる画面データが、プレイヤの端末装置３へ送信される。このメイン画面には、前述のプレイヤのチーム名７０、選手カード７１、ゲーム情報７２などが表示されるとともに、連続アクセス継続通知情報７６も表示される。この連続アクセス継続通知情報７６は、例えば「仲間の応援アクセスにより連続アクセス継続中！残り２日の連続アクセスで特典獲得！」というような、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが途切れることなく継続していることが分かる内容である。
【０１６４】
これにより、プレイヤは、ゲームサーバ１へアクセスできなかった翌日に、仲間プレイヤの応援アクセスにより連続アクセスが継続している事実を認識できる。よって、プレイヤは、仲間の存在を強く意識するとともに、以降も連続的にゲームサーバ１にアクセスして連続アクセス達成特典を獲得しようとする意識が強く働く。このため、プレイヤによる継続的なゲームサーバ１へのアクセスを、効果的に促すことができる。
【０１６５】
図１１（ｂ）は、ゲームのメイン画面以外の画面中に連続アクセス継続中の旨を表示してプレイヤに報知する例を示すものである。プレイヤが連続アクセスを欠落した日の翌日に、プレイヤの端末装置３がゲームサーバ１に最初にアクセスしたとき、ゲームサーバ１の報知手段５８からは、例えばメイン画面よりも前に、図１１（ｂ）に示す画面データが、プレイヤの端末装置３へ送信される。この画面では、昨日（欠落日と同じ日）の仲間のゲームへのアクセス実績および応援アクセス条件を満たした旨が表示される。図１１（ｂ）では、「昨日、仲間１０人中８人がゲームにアクセスしました。応援アクセス条件（仲間の８割以上のアクセス）をクリア！」という仲間のアクセス実績等の表示例を示している。また、この画面には、図１１（ａ）と同様の連続アクセス継続通知情報７６が表示され、仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが途切れることなく継続している旨がプレイヤに報知される。図１１（ｂ）の画面において、例えば「メイン画面へ」ボタン７５がプレイヤにより選択されると、ゲームサーバ１からメイン画面データがプレイヤの端末装置３へ送信され、端末装置３の画面がメイン画面へと遷移する。
【０１６６】
次に、メッセージ伝達手段５９について説明する。メッセージ伝達手段５９は、各プレイヤの端末装置３から送信された他のプレイヤ宛のメッセージを受信するとともに、当該メッセージを当該他のプレイヤへ伝達する機能を有する。このメッセージ伝達手段５９は、メッセージ記憶部５９ａを備えている。
【０１６７】
図１２には、メッセージ記憶部５９ａがデータベースサーバ２に記憶して管理する、受信メッセージに関する情報の一例を示している。このメッセージ記憶部５９ａは、メッセージを受け取った受信側プレイヤのプレイヤＩＤと対応付けて、送信元のプレイヤＩＤ、メッセージの内容、送信日時などのメッセージに関する情報を、受信側のプレイヤのプレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。図１２の例では、プレイヤＩＤ＝“０００００２”の受信側プレイヤ１人分の受信メッセージに関する情報を示しており、当該プレイヤは、プレイヤＩＤ＝“０００００１”のプレイヤから「アクセス頑張ろう！」、プレイヤＩＤ＝“００００３８”のプレイヤから「明日はアクセスできないので応援アクセスお願いします！」、プレイヤＩＤ＝“０００１４５”のプレイヤから「今週もよろしく！」というメッセージをそれぞれ受け取っている。
【０１６８】
ここで、プレイヤが自分の仲間プレイヤに対してメッセージを送る操作の一例を説明する。図１３（ａ）には、ゲームサーバ１から送信された画面データに基づいて、プレイヤの端末装置３に表示される仲間リスト画面の一例を示している。この仲間リスト画面は、例えばプレイヤが端末装置３を操作してメイン画面中の「仲間メニュー」を選択することによって表示される画面である。この仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。なお、画面に表示しきれない仲間プレイヤの情報については、画面をスクロールするまたは仲間リストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。
【０１６９】
この仲間リスト画面内にはリストアップされた仲間プレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間プレイヤのゲーム情報８１（プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等）、当該プレイヤの分身的なキャラクタであるアバター８２、当該プレイヤが所有するリーダーの選手カード８３などとともに、エールボタン８４というオブジェクトも表示される。そして、プレイヤがこのエールボタン８４を選択することで、自分の仲間プレイヤに対してエール（応援）を送る（応援の意思表示をする）ことができるようになっている。プレイヤは、仲間プレイヤにエールのみを送ることもできるが、以下に説明するように、さらにメッセージも送ることができる。
【０１７０】
プレイヤの端末装置３における操作によりエールボタン８４が選択された場合、当該操作が端末装置３からゲームサーバ１へ伝えられる。その後、ゲームサーバ１からは、例えば図１３（ｂ）に示すメッセージ入力画面のデータが端末装置３へ送信され、端末装置３に当該メッセージ入力画面が表示される。このメッセージ入力画面には、例えば、仲間プレイヤ（図１３（ｂ）の例ではプレイヤＢ）に対してエールを送った旨を示す文章等が表示されるとともに、メッセージ入力領域８５および送信ボタン８６というオブジェクトも表示される。そして、プレイヤは、端末装置３を操作してメッセージ入力領域８５に任意のメッセージを入力し、送信ボタン８６を選択することによって、端末装置３からは仲間プレイヤ宛のメッセージがゲームサーバ１へ送信される。図１３（ｂ）では「アクセス頑張ろう！」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ２における記憶容量を考慮して、メッセージ入力領域８５に入力できる文字に制限（例えば全角３０文字以内）を設けてもよい。
【０１７１】
なお、メッセージ入力画面には、仲間プレイヤ（この例ではプレイヤＢ）のページへ遷移するためのハイパーリンク８７が表示されており、このリンクを選択することにより当該仲間プレイヤのゲーム情報の詳細が記載されたページを表示できる。また、メッセージ入力画面には、仲間リストへ遷移するためのハイパーリンク８８やメイン画面へ遷移するためのハイパーリンク８９なども表示されており、これらのリンクを選択することにより仲間リストやメイン画面に戻れるようになっている。
【０１７２】
このメッセージ入力画面でのプレイヤの操作により端末装置３からメッセージが送信された場合、ゲームサーバ１では、メッセージ伝達手段５９のメッセージ記憶部５９ａが、端末装置３から受信した仲間プレイヤ宛のメッセージを、当該仲間プレイヤのプレイヤＩＤと対応させてデータベースサーバ２に記憶する（図１２参照）。そして、当該仲間プレイヤの端末装置３がゲームサーバ１へアクセスしたとき、ゲームサーバ１のメッセージ伝達手段５９は、メッセージ、送信元のプレイヤ名、送信時間等を表示させる画面データを端末装置３に送信する。これにより、この画面データを受信したプレイヤの端末装置３にはメッセージ等が表示され、他の仲間から受け取ったメッセージを画面で確認できるようになっている。
【０１７３】
このように、本実施の形態のゲームシステムでは、前記図１３（ａ）（ｂ）に例示するようなコミュニケーションツールを使用して、仲間同士が何時でもコミュニケーションをとることができるようになっている。
【０１７４】
前記図１３（ａ）（ｂ）の例では、プレイヤの仲間に対してメッセージを送る例を説明したが、仲間関係にはない他のプレイヤに対しても、エールを送ったりメッセージを送ったりすることができる。例えば、後述する仲間候補リスト画面（図３１参照）にリストアップされた仲間ではない他のプレイヤに対して、仲間の場合と同様の操作により、エールやメッセージを送ることが可能である。
【０１７５】
ところで、上記の説明では、仲間管理手段５３が管理している各プレイヤの仲間情報、アクセス管理手段５５が管理している各プレイヤのアクセス情報、メッセージ伝達手段５９が管理しているメッセージに関する情報は、便宜上、ゲーム情報管理手段５１が管理している各種情報とは区別して記載しているが、これらの情報は何れもゲームサーバ１が管理するゲーム情報に含まれるものである。
〔ゲームシステムの動作〕
【０１７６】
上記の構成において、本発明の実施の形態に係るゲームシステムの動作例を、図１４のフローチャートを参照しながら以下に説明する。図１４は、プレイヤが端末装置３を操作してゲームサーバ１にアクセスしてゲームサービスを受けるときの、端末装置３およびゲームサーバ１の処理の基本的な流れを示すものである。
【０１７７】
プレイヤがゲームサービスを受ける場合、先ず、端末装置３の操作入力部４０を操作してウェブブラウザを起動する（Ｓ１１）。その後、プレイヤは、ゲームサーバ１が管理するゲームサイトにアクセスする操作を行い、これにより、端末装置３からゲームサーバ１へアクセスリクエストが送信される（Ｓ１２）。このとき、ゲームサーバ１は、端末装置３からのアクセスに対するログイン認証を行い（Ｓ２１）、ゲームサービスの利用登録がなされているプレイヤからのアクセスであることを確認する。その後、ゲームサーバ１は、ＨＴＭＬ等で記述されたメイン画面データを端末装置３に送信する（Ｓ２２）。そして、メイン画面データを受信した端末装置３では、ウェブブラウザが当該データを解釈し、メイン画面を表示部３５に表示させる（Ｓ１３）。
【０１７８】
図１０（ａ）に例示するように、メイン画面には、プレイヤのチーム名７０、プレイヤが所有する選手カードの中からリーダーとして選択された選手カード７１の画像、プレイヤのゲーム情報７２（プレイヤのレベル、行動力ポイント、運営コスト、強化ポイント、エールポイント、所有する選手カードの数、仲間人数など）が表示される。また、上述の特典通知情報７３なども表示される。さらに、このメイン画面には、端末装置３の方向キー等を操作して画面をスクロールさせることによって、図示しないゲームモードの選択ボタン、各種メニューボタン、仲間の動き情報、他のプレイヤからのメッセージなど、様々なオブジェクトや情報が表示されるようになっている。
【０１７９】
ここでプレイヤが、画面に表示されている選択可能なボタン等のオブジェクトやハイパーリンクを選択する操作をすると、当該操作に応じた画面のリクエストが端末装置３からゲームサーバ１へ送信される（Ｓ１４）。このリクエストを受信したゲームサーバ１は、プレイヤの操作に応じた演算処理やデータ処理を行ってゲームを実行し（Ｓ２３）、実行結果を反映させたゲーム画面データを端末装置３へ送信する（Ｓ２４）。そして、画面データを受信した端末装置３では、ウェブブラウザが当該データを解釈し、ゲーム画面を表示部３５に表示させる（Ｓ１５）。
【０１８０】
以降は、プレイヤの端末装置３においては前記のＳ１４およびＳ１５が繰り返され、ゲームサーバ１においては前記のＳ２３およびＳ２４が繰り返され、これにより、端末装置３の画面に表示されている選択可能なボタン等をプレイヤが選択する度に、端末装置３のゲーム画面が次々と切り替わり、ゲームを進行させることができる。
【０１８１】
その後、プレイヤが端末装置３を操作してゲーム画面を閉じた場合（Ｓ１６）、ゲームサーバ１はログアウト処理を行う（Ｓ２５）。例えば、プレイヤがウェブブラウザを閉じた場合、ゲームサーバ１はセッションタイムアウト後にログアウト処理を行う。
【０１８２】
ところで、本ゲームシステムにおいては、プレイヤがゲームサーバ１からログアウトした場合であっても、ゲームサーバ１側で当該プレイヤのゲーム情報を読み出してゲームを進行させることができる。例えば、ログアウトしているプレイヤのチームに対して、ログインしている他のプレイヤが対戦（個別対戦）を仕掛けてくることもあり、ゲームサーバ１のゲーム進行手段５２は、プレイヤがログインしているか否かに依らずに、各プレイヤのゲーム情報をデータベースサーバ２から読み出して対戦を実行し、その実行結果を反映させて各プレイヤのゲーム情報を更新する。また、リーグ戦モードでは、プレイヤによる端末装置３の操作なしに、ゲームサーバ１のゲーム進行手段５２が、各プレイヤのゲーム情報をデータベースサーバ２から読み出して、自動でリーグ戦の試合を実行する。このように、プレイヤがゲームサーバ１からログアウトしているときに実行された対戦の結果は、その後、プレイヤがゲームサーバ１にアクセスしたときに画面で確認することができる。
【０１８３】
〔ゲーム管理装置の動作〕
次に、本発明の実施の形態に係るゲーム管理装置のより詳細な動作例を、図１５ないし図１７のフローチャートを参照しながら説明する。図１５ないし図１７は、ある一人のプレイヤを対象としたゲームサーバ１の処理の流れを示すものであり、ゲームサーバ１が管理している各々のプレイヤに対して同様の処理が行われる。
【０１８４】
図１５のフローチャートは、現実世界の１日（単位期間）が終了する度に実行される処理を例示するものであり、例えば毎日午前０時に処理が開始される。この処理の開始時間になれば（Ｓ３１でＹＥＳ）、プレイヤが前日にゲームサーバ１へ少なくとも１回以上アクセスしたか否かが判断される（Ｓ３２）。この判断は、図９（ａ）に示すアクセス情報（１日前のアクセスの有無を示す情報）に基づいて行うことができる。
【０１８５】
プレイヤが前日にゲームサーバ１へアクセスしていなかった場合（Ｓ３２でＮＯ）、この前日のアクセスの欠落が、連続５日間の途中で生じたアクセス欠落日の１日目に該当するか否かが判断される（Ｓ３３）。本実施の形態では、連続５日間のうち埋め合わせ可能な欠落日を１日のみとしているので、もしも前日のアクセスの欠落が２日目の欠落日であった場合には（Ｓ３３でＮＯ）、プレイヤのゲームサーバ１への連続アクセスは途絶えたことになり、Ｓ４０に移行して図９（ａ）に示す連続アクセス日数が「０日」に初期化される。
【０１８６】
前日のアクセスの欠落が、連続５日間の途中で生じたアクセス欠落日の１日目であった場合（Ｓ３３でＹＥＳ）、プレイヤの仲間が応援アクセス条件を満たしているか否かの判定処理（Ｓ３４およびＳ３５）に移行する。図１５では、「欠落日と同一の日に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合が０．８以上」を応援アクセス条件とした例について示している。Ｓ３４において、前日（すなわち欠落日と同一の日）に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合Ｒを算出する。その後、Ｓ３５において、算出された割合Ｒが０．８以上という応援アクセス条件を満たすか否かが判定される。
【０１８７】
前記の応援アクセス条件を満たしていない場合（Ｓ３５でＮＯ）、プレイヤの連続アクセスは途絶えたことになり、Ｓ４０に移行して連続アクセス日数が「０日」に初期化される。一方、前記の応援アクセス条件を満たしている場合（Ｓ３５でＹＥＳ）、ゲームサーバ１は、プレイヤが前日にゲームサーバ１へアクセスしたとみなし、連続アクセス継続処理を行う（Ｓ３６）。この連続アクセス継続処理の具体的な処理例としては、図９（ａ）に示すプレイヤのアクセス情報を次のように設定・変更することである。すなわち、ゲームサーバ１は、応援アクセス条件を満たしたか否かを示す情報（１日前の情報）を「１」に設定し、連続アクセス日数のカウントを１つ増加させ、連続アクセス継続報知フラグを「１」に設定する。
【０１８８】
その後、５日間の連続アクセスを達成したか否かが判断される（Ｓ３７）。前日が連続５日間の最終日であった場合、プレイヤの仲間が応援アクセス条件を満たしたことによって、プレイヤが連続アクセスを達成する（Ｓ３７でＹＥＳ）。この場合、連続アクセス特典付与手段５７は、ゲーム上有利になるようにプレイヤのゲーム情報を変更して連続アクセス達成特典を付与する（Ｓ３８）。例えば、所定の強化ポイントをボーナスポイントとしてプレイヤに付与する場合、当該プレイヤのプレイヤＩＤに対応するゲーム情報（図６に例示するプレイヤの特典情報および強化ポイントの情報）が変更されることになる。この連続アクセス達成特典の付与処理後、ゲームサーバ１は、図６に示す特典報知フラグを「１」に設定するとともに（Ｓ３９）、図９（ａ）に示す連続アクセス日数を「０日」に初期化する（Ｓ４０）。
【０１８９】
一方、前日が連続５日間の最終日でなかった場合は、この時点では未だ５日間の連続アクセスが達成されていないので（Ｓ３７でＮＯ）、連続アクセス達成特典の付与処理が行われることなく図１５のルーチンを終了する。
【０１９０】
このように、本実施の形態では、プレイヤがゲームサーバ１へアクセスできなかった欠落日が存在しても、プレイヤの仲間が応援アクセス条件を満たすことによって、プレイヤの連続アクセスが継続される。
【０１９１】
次に、図１６のフローチャートを参照しながら、プレイヤがゲームサーバ１へアクセスした場合におけるゲーム管理装置（ゲームサーバ１）の動作について説明する。ゲームサーバ１の認証手段５４は、プレイヤの端末装置３からアクセス要求を受けたとき（Ｓ５１でＹＥＳ）、端末装置３から送信されてきたログインＩＤ・パスワード、または携帯電話端末の個体識別番号等に基づいて、アクセスを許可するか否かを判断するログイン認証を行う（Ｓ５２）。ここで、認証手段５４がアクセスを許可しない場合（Ｓ５２でＮＯ）、ゲームサーバ１は、端末装置３にゲームサービスの利用登録を促す画面データを送信する（Ｓ５３）。
【０１９２】
一方、認証手段５４がアクセスを許可する場合（Ｓ５２でＹＥＳ）、アクセス管理手段５５がプレイヤのアクセス情報を記憶する（Ｓ５４）。例えば、図９（ａ）に示すように、アクセス管理手段５５のアクセス情報記憶部５３ａが、プレイヤＩＤと対応付けて、プレイヤの当日のアクセス情報を更新する（すなわち、アクセスの有無を表す情報ビットを「１」に設定する）。さらに、ゲームサーバ１のアクセス管理手段５５は、図９（ａ）に示す連続アクセス日数のカウントを１つ増加させる（Ｓ５５）。
【０１９３】
その後、連続アクセス日数が５日に達しているか否かが判断される（Ｓ５６）。ここで、プレイヤの連続アクセス日数が５日に達している場合（Ｓ５６でＹＥＳ）、連続アクセス特典付与手段５７が、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する（Ｓ５７）。この連続アクセス達成特典の付与処理後は、図９（ａ）に示す連続アクセス日数が「０日」に初期化される（Ｓ５８）。そして、報知手段５８が、連続アクセス達成特典が付与された旨をプレイヤに報知するための画面データを生成する（Ｓ５９）。例えば、図１０（ａ）に示すように、ゲームのメイン画面内に特典通知情報７３を含ませた画面データが生成される。その後、ゲームサーバ１は、特典通知情報７３を含んだメイン画面データをプレイヤの端末装置３へ送信する（Ｓ６０）。これにより、プレイヤの端末装置３には、図１０（ａ）に例示されるような特典通知情報７３を含んだメイン画面が表示されるので、プレイヤは、連続アクセス達成特典を獲得したことを認識できる。
【０１９４】
一方、プレイヤの連続アクセス日数が５日に達していない場合（Ｓ５６でＮＯ）、特典報知フラグが「１」に設定されているか否かが判断される（Ｓ６１）。すなわち、本実施の形態では、上述のように、連続５日間の最終日にゲームサーバ１へアクセスできなかったプレイヤの仲間が応援アクセス条件を満たしたことによって、当該プレイヤが連続アクセスを達成することもあり、この場合、特典報知フラグが「１」に設定されている。よって、特典報知フラグが「１」に設定されている場合（Ｓ６１でＹＥＳ）、前記Ｓ５９に移行して、連続アクセス達成特典が付与された旨をプレイヤに報知するための画面データが生成されることになる（Ｓ５９）。なお、Ｓ６１経由でＳ５９が実行された場合は、フローチャートには図示していないが特典報知フラグが「０」に設定されることになる。その後、ゲームサーバ１は、例えば図１０（ａ）に示す特典通知情報７３を含んだメイン画面データをプレイヤの端末装置３へ送信する（Ｓ６０）。これにより、プレイヤの端末装置３には、特典通知情報７３を含んだメイン画面が表示されるので、プレイヤは、連続５日間の最終日にゲームサーバ１にアクセスできなかったにもかかわらず、仲間の応援アクセスにより連続アクセス達成特典を獲得したことを認識できる。
【０１９５】
また、Ｓ６１において特典報知フラグが「１」に設定されていない場合には、連続アクセス継続報知フラグが「１」に設定されているか否かが判断される（Ｓ６２）。すなわち、本実施の形態では、上述のように、プレイヤがゲームサーバ１へアクセスできなかった欠落日が存在しても、プレイヤの仲間が応援アクセス条件を満たすことによって、プレイヤの連続アクセスが継続され、この場合、連続アクセス継続報知フラグが「１」に設定されている。よって、連続アクセス継続報知フラグが「１」に設定されている場合（Ｓ６２でＹＥＳ）、プレイヤの仲間プレイヤが応援アクセス条件を満たしたことによって連続アクセスが継続している旨を報知するための画面データが、報知手段５８によって生成されることになる（Ｓ６３）。例えば、図１１（ａ）に示すように、ゲームのメイン画面内に連続アクセス継続通知情報７６を含ませた画面データが生成される。その後、ゲームサーバ１は、連続アクセス継続通知情報７６を含んだメイン画面データをプレイヤの端末装置３へ送信する（Ｓ６０）。これにより、プレイヤの端末装置３には、連続アクセス継続通知情報７６を含んだメイン画面が表示されるので、プレイヤは、前日にゲームサーバ１にアクセスできなかったにもかかわらず、仲間の応援アクセスにより連続アクセスが継続していることを認識できる。
【０１９６】
一方、特典報知フラグおよび連続アクセス継続報知フラグの何れもが「１」でない場合（Ｓ６１およびＳ６２でＮＯ）、ゲームサーバ１は、通常のメイン画面データをプレイヤの端末装置３へ送信する（Ｓ６０）。
【０１９７】
そして、ゲームサーバ１は、メイン画面データの送信後はゲーム進行処理を実行する（Ｓ６４）。このゲームサーバ１におけるゲーム進行処理を、図１７のフローチャートを参照しながら、以下に説明する。
【０１９８】
図１７に示すように、ゲームサーバ１は、プレイヤの端末装置３から送信されてくるプレイヤのゲーム操作に応じた画面リクエストを受信したとき（Ｓ７１でＹＥＳ）、ゲーム実行手段５２ａが、当該画面リクエストに応じた演算処理やデータ処理を行ってゲームを実行する（Ｓ７２）。
【０１９９】
その後、ゲームサーバ１は、ゲームの実行によりプレイヤのゲーム情報を更新する必要があるか否かを判断し（Ｓ７３）、更新の必要がある場合（Ｓ７３でＹＥＳ）、データベースサーバ２に記憶されているプレイヤのゲーム情報を更新する（Ｓ７４）。例えば、プレイヤのゲーム操作が他のプレイヤとの個別対戦を行う操作であった場合、当該対戦が実行された結果、試合結果の情報、運営コスト、強化ポイント、アイテム等のプレイヤのゲーム情報が更新されることになる。一方、例えば、プレイヤのゲーム操作がリーグ戦の結果確認の操作であった場合、当該操作に応じたゲームの実行処理としてはリーグ戦の結果情報をデータベースサーバ２から読み出すデータ処理だけであって、当該処理の前後でプレイヤのゲーム情報に変化はなく、よってプレイヤのゲーム情報を更新する必要はない（Ｓ７３でＮＯ）。
【０２００】
その後、ゲーム画面生成手段５２ｂがゲームの実行結果を反映させたゲーム画面データを生成し（Ｓ７５）、ゲーム画面送信手段５２ｃが当該ゲーム画面データをプレイヤの端末装置３へ送信する（Ｓ７６）。その後、プレイヤの端末装置３がログアウトしたか否かが判断され（Ｓ７７）、端末装置３がログアウトするまで、前記Ｓ７１〜Ｓ７６の処理が繰り返されることで、ゲームが進行していく。
【０２０１】
以上のように、本実施の形態では、連続５日間（連続した規定期間数の単位期間）の中にアクセスの欠落日（欠落単位期間）が存在するプレイヤであっても、当該プレイヤの仲間が所定の応援アクセス条件を満たすことによって、当該プレイヤに連続アクセス達成特典が付与される。よって、プレイヤが何かの用でゲームサーバ１にアクセスできなかった場合でも、プレイヤの仲間が応援アクセス条件を満たすような高いアクセス頻度を維持してくれることにより、連続アクセス達成特典を獲得できるというメリットが生じる。また、プレイヤ自身も高いアクセス頻度を維持すれば、他の仲間がアクセスを欠落したときの応援アクセス条件の達成に貢献することができ、間接的に他の仲間を支援できることにもなる。これにより、各プレイヤは、仲間同士でお互いにアクセス頻度を高め合おうという意識付け、動機付けを与えられることになる。よって、各プレイヤは、仲間全体のゲームサーバ１へのアクセス頻度を高めようとして、自己の仲間プレイヤとコミュニケーションをとる動機付けを与えられることになる。例えば、各プレイヤは、仲間に対して「アクセス頑張ろう！」のようなメッセージを送って、自己の仲間プレイヤとの間のコミュニティを盛り上げようとする。
【０２０２】
このように、本実施の形態では、単に特典を受けることの面白さをプレイヤに提供するにとどまらず、仲間同士でお互いにアクセス頻度を高め合おうという動機付けおよび仲間とコミュニケーションをとろうとする動機付けをプレイヤに与え、これにより、ゲームコミュニティ全体の活性化を図ることができる。この結果、各プレイヤはゲーム内での仲間同士のつながりや交流を強め、延いてはゲームに対する関心と興味をより強めることとなるので、プレイヤにとって飽きのこない継続性を有するゲームを実現できる。
【０２０３】
また、本実施の形態では、アクセスの欠落日（欠落単位期間）と同じ日（同一の単位期間内）に、少なくとも１回のアクセスを行なった仲間プレイヤ（単位期間内アクセスを達成した仲間プレイヤ）の人数または仲間プレイヤ全体に占める割合が、閾値を超えることを応援アクセス条件としている。この場合、プレイヤは、欠落日の当日に仲間による応援アクセス条件が満たされるように、何かの用で欠落日となりそうな日（アクセスができそうにない日）を予め他の仲間に連絡しておくことができる。例えば、プレイヤは、仲間に対して「明日はアクセスできないので応援アクセスお願いします！」のようなメッセージを送って、応援アクセスを事前依頼することができる。このように、応援アクセスを事前依頼することにより仲間との間のコミュニティが盛り上がる。また、応援アクセスを事前依頼した日に、実際に仲間が応援アクセス条件を満たしてくれることにより、仲間意識が高まって仲間同士のつながりがより強くなり、プレイヤはゲームに対する関心と興味をより一層強くする。
【０２０４】
ところで、上記の説明では、連続５日間のうち埋め合わせ可能な欠落日を１日のみとする例を示したが、埋め合わせ可能な欠落日を２日以上とすることもできる。但し、上述のように、連続アクセス達成特典は、本来、プレイヤ自身がゲームサーバ１へ連続アクセスして獲得できるものであることから、埋め合わせ可能な欠落日をあまり多く許容し過ぎない方がよい。よって、埋め合わせ可能な欠落日には上限を設けることが望ましく、例えば、埋め合わせ可能な欠落日を最大２日とし、３日以上の埋め合わせは不可とする。
【０２０５】
埋め合わせ可能な欠落日を最大２日とした場合、欠落日の１日目を埋め合わせするための応援アクセス条件と、欠落日の２日目を埋め合わせするための応援アクセス条件とを同じ条件とすることも可能である。その一方で、複数の欠落日に対する埋め合わせが容易になされることを回避するため、欠落日の１日目（第１欠落単位期間）より欠落日の２日目（第２欠落単位期間）の方が、応援アクセス条件を満たし難い条件に設定することが望ましい。例えば、欠落日の１日目を埋め合わせするための応援アクセス条件を「欠落日と同一の日に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合Ｒが０．８以上であること」とし、欠落日の２日目を埋め合わせするための応援アクセス条件を「前記割合Ｒが０．９以上であること（または、欠落日と同一の日に、アクセスを欠落したプレイヤ以外の仲間全員がゲームサーバ１に１回以上アクセスしていること）」とし、欠落日の２日目は１日目よりかなり厳しい条件とする。このように欠落日の２日目を１日目より厳しい応援アクセス条件とした場合のゲームサーバ１の動作を、図１８のフローチャートを参照しながら、以下に説明する。なお、図１５に示したフローチャートと同様の処理については、同一のステップ番号を付して、適宜その説明を省略する。
【０２０６】
処理の開始時間になれば（Ｓ３１でＹＥＳ）、プレイヤが前日にゲームサーバ１へ少なくとも１回以上アクセスしたか否かが判断され（Ｓ３２）、プレイヤが前日にアクセスしていなかった場合（Ｓ３２でＮＯ）、この前日のアクセスの欠落が、連続５日間の途中で生じたアクセス欠落日の３日目に該当するか否かが判断される（Ｓ８１）。ここで、前日のアクセスの欠落が３日目であった場合には（Ｓ８１でＹＥＳ）、プレイヤのゲームサーバ１への連続アクセスは途絶えたことになり、Ｓ４０に移行して連続アクセス日数が「０日」に初期化される。
【０２０７】
前日のアクセスの欠落が、連続５日間の途中で生じたアクセス欠落日の３日目でなかった場合、すなわち１日目または２日目の欠落日であった場合（Ｓ８１でＮＯ）、プレイヤの仲間が応援アクセス条件を満たしているか否かの判定処理（Ｓ３４以降の処理）に移行する。Ｓ３４では、前日（すなわち欠落日と同一の日）に、ゲームサーバ１に１回以上アクセスをした仲間プレイヤの当該仲間プレイヤ全体に占める割合Ｒを算出する。その後、Ｓ８２において、欠落日が１日目か否かによって、応援アクセス条件を異ならせる分岐処理が行われる。欠落日が１日目の場合（Ｓ８２でＹＥＳ）、算出された割合Ｒが０．８以上という応援アクセス条件を満たしているか否かが判定される（Ｓ３５）。一方、欠落日が１日目ではなく２日目の場合（Ｓ８２でＮＯ）、１日目より厳しい応援アクセス条件となるように、算出された割合Ｒが例えば０．９以上であるか否かが判定される（Ｓ８３）。ここで応援アクセス条件を満たしている場合（Ｓ３５またはＳ８３でＹＥＳ）、ゲームサーバ１は、プレイヤが前日にゲームサーバ１へアクセスしたとみなし、連続アクセス継続処理を行う（Ｓ３６）。一方、応援アクセス条件を満たしていない場合（Ｓ３５またはＳ８３でＮＯ）、プレイヤの連続アクセスは途絶えたことになり、Ｓ４０に移行して連続アクセス日数が「０日」に初期化される。なお、Ｓ３７〜Ｓ３９は、基本的には図１５のフローチャートで説明した処理と同様の処理である。
【０２０８】
このように、欠落日の１日目より２日目の方が厳しい応援アクセス条件を適用することにより、複数の欠落日に対する埋め合わせが容易になされることを回避する。また、２日目の厳しい応援アクセス条件を満たしたプレイヤに対して、複数の欠落日に対する埋め合わせを許容することによって、厳しい条件を達成するために仲間同士でお互いにアクセス頻度を一層高めようという意識付け、動機付けをプレイヤに与えることができる。
【０２０９】
また、欠落日の埋め合わせを３日以上許容する場合も、時系列的に後に生じた欠落日（第２欠落単位期間）の方が、それより前に生じた欠落日（第１欠落単位期間）よりも厳しい応援アクセス条件を適用することが望ましい。
【０２１０】
また、上記では、各プレイヤが任意の日に５日間の連続アクセスを達成すれば、連続アクセス達成特典が付与される例について説明したが、次のような期間限定のゲーム内イベントにおいて連続アクセス達成特典が付与されるようにしてもよい。
【０２１１】
すなわち、本実施の形態のゲームシステムは、ゲームサーバ１においてプレイヤのゲーム情報を管理してゲームを実行するので、基本的にゲーム実行プログラムはゲームサーバ１側に存在する。よって、ゲームサービスの運営者がゲームサーバ１側のゲーム実行プログラムを追加・変更することによって、全てのゲームサービスの利用者（プレイヤ）が追加・変更されたゲームサービスを受けることができる。このため、ゲームサーバ１側のゲーム実行プログラムを追加・変更して期間限定のゲーム内イベントを適宜開催し、プレイヤに色々なゲームサービスを提供することも容易にできる。そこで、例えば、毎月１日〜５日の５日間や毎月第１週の月曜日〜日曜日の７日間をマンスリーイベント期間としたり、クリスマスの週の７日間をクリスマスイベント期間としたりして、当該イベント期間中の連続アクセスの達成者に特典を付与するというゲームサービスを提供することもできる。特に期間限定のイベントを開催する場合、通常時に獲得できる連続アクセス達成特典よりも大きな特典をプレイヤが獲得できるようにすることも多いので、アクセスの欠落日を埋め合わせすることができる応援アクセス条件も、特典の大きさに応じて厳しくしてもよい。
【０２１２】
〔ゲーム管理装置の他の構成例〕
次に、前述の応援アクセス条件とは異なる条件を適用したゲーム管理装置の構成例を、図１９の機能ブロック図を参照しながら説明する。なお、既出の図面（図１〜図１８）において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態で説明する応援アクセス条件とは、連続５日（連続した規定期間数の単位期間）の中に欠落日（欠落単位期間）が存在するプレイヤの仲間というグループの評価値が、閾値を超えることである。このグループの評価値は、アクセス頻度に基づいて算出されるものであり、本実施の形態では、グループの評価値として、仲間のアクセスの頻度の平均値である仲間アクセス平均を適用した例について、以下に説明する。
【０２１３】
本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１〜５５・５７〜５９に加えて、アクセス平均算出手段６０および仲間アクセス平均算出手段６１（評価値算出手段）をさらに備えている。また、本ゲームサーバ１は、図４に示した仲間応援アクセス判定手段５６に代えて、仲間応援アクセス判定手段１５６を備えている。アクセス平均算出手段６０、仲間アクセス平均算出手段６１および仲間応援アクセス判定手段１５６は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
【０２１４】
アクセス平均算出手段６０は、プレイヤがゲームサーバ１にアクセスする頻度の目処として、各プレイヤのゲームサーバ１へのアクセス頻度の平均値である「アクセス平均」を算出する。ここで、アクセス平均の算出方法は無数に存在し、例えば、アクセス平均を算出する際の期間（以下、アクセス平均算出期間と称する）については任意に設定することができる。
【０２１５】
ただし、このアクセス平均算出手段６０が算出する各プレイヤのアクセス平均は、仲間アクセス平均算出手段６１が仲間アクセス平均を算出する際の基となる値であり、延いては応援アクセス条件に影響を与える値であるため、これを考慮してアクセス平均算出期間を決定することが望ましい。そこで、本実施の形態では、プレイヤがアクセスできなかった欠落日（欠落単位期間）の直前の所定期間（例えば欠落日の前日までの７日間）をアクセス平均算出期間とする。そして、このアクセス平均算出期間中におけるアクセス平均を、アクセス平均算出手段６０がプレイヤの仲間プレイヤのそれぞれについて算出し、さらに仲間アクセス平均算出手段６１が、当該プレイヤを中心とした仲間というグループを対象とした仲間アクセス平均を算出する。
【０２１６】
アクセス平均算出期間を設定する場合に考慮すべき点は幾つかある。先ず、その期間の長さであるが、プレイヤの入れ替わり（ゲームサービスを受けるのを止めるプレイヤおよび新規参入のプレイヤ）は、常時発生するので、アクセス平均算出期間を数か月単位の比較的長い期間とした場合、当該期間内で発生するプレイヤの入れ替わりは多くなり易い。アクセス平均算出期間の途中でゲームサービスを開始または中止したプレイヤは、アクセス平均を算出する期間的条件を満たさないため、その算出対象から除外することが望ましいことから、アクセス平均算出期間を１か月以内の期間、より好ましくは５日間〜１０日間程度に限定することで、期間的条件を満たさない算出対象の除外を低減できる。特に、ゲームサービスを開始した新規参入のプレイヤに対して、数か月間という長いアクセス平均算出期間が経過するまでアクセス平均の算出対象にならない（すなわち応援アクセス条件に何ら寄与しない）状態をつくるのは決して望ましくない。そこで、アクセス平均算出期間を１か月以内の期間とすることが好ましく、５日間〜１０日間程度に限定することがより好ましい。
【０２１７】
また、アクセス平均算出期間（アクセス平均を算出する際の母数）を１か月以内の期間、より好ましくは５日間〜１０日間程度に限定すれば、例えば当該期間を３ヶ月とした場合のように、平均値の変化が乏しくなってしまい冗長感が生じるという事態も回避できる。
【０２１８】
また、アクセス平均算出期間を「欠落日直前」の所定期間（例えば欠落日の前日までの７日間）とすることで、プレイヤの日々のゲームサーバ１へのアクセスがアクセス平均に反映されることとなる。例えば、アクセス平均算出期間を同じ７日間とした場合でも、欠落日の前日までの７日間（７日前から１日前までの７日間）ではなく、例えば先月の１日から７日までの７日間とした場合、欠落日の数週間前にはアクセス平均算出期間が終了しており、当該期間終了後のゲームサーバ１へのアクセスは、アクセス平均には反映されない。これに対して、アクセス平均算出期間を「欠落日直前」の所定期間とすれば、応援アクセス条件達成の有無の判断がなされる前日までの日々のアクセスが、アクセス平均の算出結果に反映されるので、プレイヤは、常時、アクセス平均を上げようとする動機付けを与えられることになる。
以下、本実施の形態では、アクセス平均算出期間を、欠落日の前日までの７日間とした例について説明する。
【０２１９】
図９（ａ）に示すように、アクセス管理手段５５のアクセス情報記憶部５５ａ（アクセス頻度記憶手段）は、プレイヤＩＤと対応付けて、現実世界におけるｎ日前までの各日についてのプレイヤのアクセスの有無（有＝“１”、無＝“０”の１ビット情報）を、アクセス頻度を表す情報としてプレイヤＩＤ毎に記憶している。あるいは、図９（ｂ）に示すように、アクセス管理手段５５のアクセス情報記憶部５５ａは、プレイヤＩＤと対応付けて、現実世界におけるｎ日前までの各日についてのアクセス回数を、アクセス頻度を表す情報としてプレイヤＩＤ毎に記憶している。
【０２２０】
ここで、アクセス回数とは、プレイヤの端末装置３がゲームサーバ１に接続されていない状態（セッションが確立されていない状態）からゲームサーバ１にアクセスしてログインした回数である。よって、原則的にはログイン後におけるゲームを進行させるためのゲームサーバ１へのアクセスは、アクセス回数のカウントには含めない。ログイン後、ゲームを一旦終了してログオフしてから時間をおいて、再度、ゲームサーバ１にアクセスしてログインした場合は、アクセス回数としてカウントされる。
【０２２１】
なお、ログイン時間が日付変更時間である午前０時より前であり、ログアウトの時間が午前０時を過ぎている場合、すなわち日付を跨いでゲームをプレイしている場合、日付変更時間を過ぎた後のゲームサーバ１へのアクセスは、ログイン中のアクセスであってもログインした日とは別の日のアクセスとみなしてアクセス回数をカウントしてもよい。
【０２２２】
また、ゲームサーバ１において、ゲーム管理上の日付変更時間を、午前０時とは異なる時間に設定してもよい。例えば、ゲーム管理上の１日を午前３時から開始し、翌日の午前３時になるまでとし、毎日、午前３時にゲーム管理上の日付が変更されるようにしてもよい。
【０２２３】
次に、アクセス平均算出期間を欠落日の前日までの７日間とした場合における、アクセス平均算出手段６０によるアクセス平均の具体的な算出例を例示する。アクセス平均の算出方法としては様々な方法が考えられるが、ここでは、代表的な算出方法として、算出例（１）〜（３）について説明する。
【０２２４】
算出例（１）は、単純に７日間のアクセス回数の合計を７日で割って、１日当たりのアクセス回数（回数／日）をアクセス平均として算出する。例えば、図２０（ａ）に示すように、プレイヤＡが欠落日の１日前〜７日前の各日に、０回、１回、４回、１回、３回、５回、０回のアクセスを行った場合、当該プレイヤＡのアクセス平均は、
（０＋１＋４＋１＋３＋５＋０）／７＝２（回／日）
として算出できる。
【０２２５】
算出例（２）では、１日に少なくとも１回でもゲームサーバ１にアクセスすれば、その日のカウントを「１」とする一方、一度もアクセスしなかった日はカウントを「０」とする。すなわち、１日に最低１回でもアクセスがあれば、アクセスがあったことを評価してカウントを「１」とするのである。そして、７日間のカウントの合計を７日で割って、１日当たりのカウント（カウント／日）をアクセス平均として算出する。この場合、７日間すべてについて１日１回以上のアクセスがあれば、アクセス平均＝１となる。また、上述した図１０（ａ）に示すプレイヤＡの例では、当該プレイヤＡのアクセス平均は、
（０＋１＋１＋１＋１＋１＋０）／７＝０．７１（カウント／日）
として算出できる。この算出例（２）の場合、７日間のアクセス頻度情報としては、各日のアクセスの有無が分かればよく、アクセスの有無は１ビット情報として記憶できるので、アクセスの回数を複数ビットの数値として記憶するよりも記憶容量の削減を図ることができる。
【０２２６】
算出例（３）は、上記の算出例（２）の変形例であり、１日に１回だけゲームサーバ１にアクセスした日と、１日に複数回アクセスした日とで、アクセス平均算出時の重みを変えた加重平均をとる。例えば、１日に１回だけアクセスした場合のカウントを「１」とし、１日に複数回アクセスした場合のカウントは１よりも大きくなるように重みを付け、各プレイヤのアクセス平均を算出する。重み付けの一例を示すと、ある日のアクセス回数をａとした場合、加重平均の重みｗを、
ｗ＝｛１＋（ａ−１）×０．１｝ ・・・（１）
とし、アクセス回数が多いほど重みが大きくなるようにすることができる。この加重平均による算出方法は、１日に最低１回でもアクセスがあれば、アクセスがあったことを高く評価してカウントを「１」とするとともに、１日に複数回のアクセスがあった場合はアクセスの多さも追加的に評価してカウントを１以上とするものである。上式（１）の重み付けの方法によると、１日に２回以上アクセスした場合、アクセスが１回増える毎に０．１ずつカウントが増加することになる。上述した図１０（ａ）に示すプレイヤＡの例では、当該プレイヤＡのアクセス平均（加重平均）は、
（０＋１＋１．３＋１＋１．２＋１．４＋０）／７＝０．８４（カウント／日）
として算出できる。
【０２２７】
なお、アクセス平均の算出方法は、上記の算出例（１）〜（３）に限定されるものではなく、例えば加重平均算出時の重みのつけ方を変更してもよい。
【０２２８】
ここで、図２０（ａ）〜（ｃ）に示すプレイヤＡ、Ｂ、Ｃのゲームサーバ１へのアクセス実績の例に基づいて、算出例（１）〜（３）を考察する。
図２０（ａ）のプレイヤＡは、７日のうち１回以上アクセスをした日は５日であり、日によってアクセス回数はバラバラである。図２０（ｂ）のプレイヤＢは、アクセス回数の合計についてはプレイヤＡと同じ１４回であるが、７日のうち１回以上アクセスをした日は３日だけであり、金曜日〜日曜日に集中的にアクセスしている。図２０（ｃ）のプレイヤＣは、アクセス回数の合計についてはプレイヤＡ・Ｂよりも少ないが、７日間にわたってコンスタントに毎日１回ずつアクセスしている。このように、三者三様のアクセス態様であり、算出例（１）〜（３）のいずれの算出方法を採用するかによって、アクセス平均の算出結果も大きく異なっている。
【０２２９】
例えば、ゲームサーバ１へのアクセス回数の多さに評価の重点を置く場合は、算出例（１）のアクセス平均の算出方法が適している。算出例（１）の算出方法では、プレイヤＣのアクセス平均は、プレイヤＡ・Ｂのアクセス平均より低い。
【０２３０】
一方で、単なるアクセス回数の多さよりも、平均算出期間内のコンスタントなアクセスに評価の重点を置く場合は、算出例（２）または（３）のアクセス平均の算出方法が適している。算出例（２）または（３）の算出方法では、プレイヤＣのアクセス平均は、プレイヤＡ・Ｂのアクセス平均より高くなる。例えば、基本のゲーム料金は無料であり、一部のアイテム等の使用についてのみ課金する、いわゆるアイテム課金制を採用するゲームサービスの場合、アクセスの多さも重要ではあるが、ゲームサービスの利用者に継続的にサービスを利用してもらうことがより求められることであるので、コンスタントなアクセスに評価の重点を置く算出例（２）または（３）の方が適していると言える。特に、算出例（３）は、コンスタントなアクセスに評価の重点を置きながら、アクセス回数の多さをも評価の対象にした加重平均を採用しており、最も適している。
【０２３１】
アクセス平均算出手段６０は、アクセスを欠落したプレイヤの仲間プレイヤのそれぞれについて、上述のごとくアクセス平均を算出する。そして、算出された各仲間プレイヤのアクセス平均に基づいて、仲間アクセス平均算出手段６１が、仲間というグループの評価値である仲間アクセス平均を算出する。
【０２３２】
ここで、各プレイヤを中心とする仲間（グループ）には、当該中心となるプレイヤが含まれていることから、仲間アクセス平均についても、当該中心となるプレイヤ（アクセスを欠落したプレイヤ本人）のアクセス平均を含めて算出してもよいし、当該中心となるプレイヤ以外の仲間のアクセス平均に基づいて、仲間アクセス平均を算出してもよい。
【０２３３】
なお、仲間を一人も作っていないプレイヤに関しては、当該プレイヤを中心とする仲間というグループ自体が存在しないため、仲間アクセス平均は算出されず、よって応援アクセス条件を満たすか否かの判定も行われない。
【０２３４】
また、上記では、アクセス平均算出手段６０が、基本的にプレイヤの仲間全員を対象として仲間アクセス平均を算出する例を説明したが、次に示す非アクティブプレイヤを除外して仲間アクセス平均を算出する構成としてもよい。ここで言う非アクティブプレイヤとは、ゲームサーバ１に対してゲームサービスの利用登録はしているものの実態としては全くゲームプレイをしていないか、ゲームプレイが基準より少ないプレイヤを示すものであり、「ゲームサーバ１へのアクセスの頻度が閾値に満たないプレイヤ」と定義されるものである。例えば、アクセス頻度の閾値を「１回／月」（すなわち、直近の１か月間に１回のアクセス）とした場合、直近の１か月間に１度もゲームサーバ１へアクセスしていないプレイヤは、当該閾値の条件を満たさない非アクティブプレイヤとなる。
【０２３５】
なお、アクセス頻度の閾値は、「１回／月」に限定されるものではなく、例えば、「２回／月」（直近の１か月間に２回のアクセス）、「１回／３週間」（直近の３週間に１回のアクセス）、「１回／２０日」（直近の２０日間に１回のアクセス）などのように、アクセス頻度を定める期間および当該期間中のアクセス回数を、任意に設定することができる。
【０２３６】
このように非アクティブプレイヤを除外して仲間アクセス平均を算出する理由は、非アクティブプレイヤを仲間アクセス平均の算出対象に入れると、実態にそぐわない算出データとなることもあるためである。例えば、ゲームに熱中して多数の仲間（例えば３０人程度の仲間）を作ったプレイヤであっても、たまたまその仲間の半数程度が非アクティブプレイヤであった場合、当該プレイヤの仲間アクセス平均が大きく低下してしまうことになるためである。
【０２３７】
そこで、仲間アクセス平均算出手段６０は、プレイヤの仲間の中からゲームサーバ１へのアクセス頻度が閾値に満たない非アクティブプレイヤを除外して、仲間アクセス平均をプレイヤ毎に算出する。ここで、プレイヤが非アクティブプレイヤであるか否かの判断は、アクセス管理手段５５が管理している各プレイヤのアクセス頻度の情報に基づいて行われる。
【０２３８】
本実施の形態では、図９（ａ）または（ｂ）に例示するように、アクセス管理手段５５のアクセス情報記憶部５５ａが、アクセス頻度を管理するためのアクセス情報として、ｎ日前までのアクセスの有無またはアクセス回数を、プレイヤＩＤ毎にデータベースサーバ２に記憶して管理している。ゲームサーバ１のＣＰＵ１１は、このアクセス情報に基づいて、例えばアクセス頻度の閾値＝「１回／月（３０日）」を満たすか否かを判断する。すなわち、本日から３０日前までのアクセスの有無またはアクセス回数の情報が全て「０」であるプレイヤＩＤに対応するプレイヤが、当該アクセス頻度の閾値の条件を満たさない非アクティブプレイヤであると判断できる。一方、本日から３０日前までのアクセスの有無またはアクセス回数の情報の何れか１つでも「０」以外の値となっているプレイヤＩＤに対応するプレイヤは、直近の３０日以内に少なくとも１回以上、ゲームサーバ１へアクセスしたプレイヤであり、非アクティブプレイヤではないと判断できる。
【０２３９】
また、非アクティブプレイヤの管理のために、図９（ｃ）に示すように、アクセス管理手段５５のアクセス情報記憶部５５ａがプレイヤＩＤ毎に記憶して管理する情報として、各プレイヤの最終アクセス時刻やアクティブフラグを含めてもよい。プレイヤの最終アクセス時刻からは、プレイヤがゲームサーバ１へ一度もアクセスしていない期間の長さ（最終アクセス時刻から現在時刻までの期間）が分かるので、ゲームサーバ１のＣＰＵ１１は、当該最終アクセス時刻に基づいて、アクセス頻度の閾値を満たさない非アクティブプレイヤか否かを判断することもできる。
【０２４０】
また、前記アクティブフラグは、アクティブなプレイヤであるか非アクティブプレイヤであるかを示す１ビットの情報であって、このアクティブフラグが「１」のプレイヤはアクティブであり、当該フラグが「０」のプレイヤは非アクティブプレイヤである。アクセス管理手段５５は、前述の非アクティブプレイヤか否かの判断に基づいてアクティブフラグを設定する。そして、仲間アクセス平均算出手段６０は、このアクティブフラグを参照して仲間アクセス平均を算出する対象の仲間プレイヤを抽出し（すなわち、非アクティブプレイヤを除外し）、各プレイヤの仲間アクセス平均を算出することができる。
【０２４１】
本実施の形態の仲間応援アクセス判定手段１５６は、仲間アクセス平均算出手段６１が算出した仲間アクセス平均と所定の閾値とを比較し、仲間アクセス平均が閾値（例えば０．８）を超えている場合に応援アクセス条件を満たしていると判定する。
【０２４２】
仲間アクセス平均と比較される閾値は、固定値とすることもできるが、次のように全体のアクセス頻度に応じて変動する値としてもよい。すなわち、ゲームサービスを受けている全プレイヤを対象としたアクセス頻度の平均値である全体アクセス平均を算出し、当該全体アクセス平均に所定値（例えば０．２）を加算した値を閾値とする。例えば、算出された全体アクセス平均が０．６であった場合、閾値は０．８（＝０．６＋０．２）となる。ここで、全体アクセス平均は、前記アクセス平均算出手段６０が算出する各プレイヤのアクセス平均の値を用いることができる。全体アクセス平均を算出する場合、アクセス平均算出手段６０は、全プレイヤを対象として前述した各プレイヤのアクセス平均の値を算出することになる。なお、全体アクセス平均を算出するに際しては、アクセス平均算出期間の途中でゲームサービスを開始または中止したプレイヤは、アクセス平均を算出する期間的条件を満たさないため、その算出対象から除外することが望ましい。また、前述の非アクティブプレイヤも全体アクセス平均の算出対象から除外してもよい。
【０２４３】
本実施の形態のゲームサーバ１の処理例を、図２１のフローチャートに示す。なお、図１５または図１８に示したフローチャートと同様の処理については、同一のステップ番号を付して、適宜その説明を省略する。
【０２４４】
Ｓ３１、Ｓ３２およびＳ８１については図１８と同様の処理である。プレイヤによる前日のアクセスの欠落が、連続５日間の途中で生じたアクセス欠落日の３日目でなかった場合、すなわち１日目または２日目の欠落日であった場合（Ｓ８１でＮＯ）、当該プレイヤの仲間が応援アクセス条件を満たしているか否かの判定処理（Ｓ９１以降の処理）に移行する。Ｓ９１では、アクセス平均算出手段６０が、欠落日の前日までの７日間のアクセス平均を、アクセスを欠落したプレイヤの仲間プレイヤのそれぞれについて算出する。その後、仲間アクセス平均算出手段６１が、アクセス平均算出手段６０により算出された各仲間プレイヤのアクセス平均に基づいて、アクセスを欠落したプレイヤの仲間アクセス平均ＡＶＡを算出する（Ｓ９２）。その後、Ｓ８２において、欠落日が１日目か否かによって、応援アクセス条件を異ならせる分岐処理が行われる。
【０２４５】
欠落日が１日目の場合（Ｓ８２でＹＥＳ）、算出された仲間アクセス平均ＡＶＡが、例えば０．８以上という応援アクセス条件を満たしているか否かが判定される（Ｓ９３）。一方、欠落日が１日目ではなく２日目の場合（Ｓ８２でＮＯ）、１日目より厳しい応援アクセス条件となるように、算出された仲間アクセス平均ＡＶＡが、例えば０．９以上であるか否かが判定される（Ｓ９４）。ここで応援アクセス条件を満たしている場合（Ｓ９３またはＳ９４でＹＥＳ）、ゲームサーバ１は、プレイヤが前日にゲームサーバ１へアクセスしたとみなし、連続アクセス継続処理を行う（Ｓ３６）。一方、応援アクセス条件を満たしていない場合（Ｓ９３またはＳ９４でＮＯ）、プレイヤの連続アクセスは途絶えたことになり、Ｓ４０に移行して連続アクセス日数が「０日」に初期化される。なお、Ｓ３７〜Ｓ３９は、基本的には図１５のフローチャートで説明した処理と同様の処理である。
図２１のフローチャートでは、埋め合わせ可能な欠落日を最大２日とした例を示したが、埋め合わせ可能な欠落日を１日のみまたは３日以上としてもよい。
【０２４６】
上記では、連続５日の中に欠落日が存在するプレイヤの仲間というグループの評価値として仲間アクセス平均を適用した例を説明したが、グループの評価値はこれに限定されない。例えば、グループの評価値を仲間プレイヤのアクセス頻度の合計値としてもよいし、仲間プレイヤの中のアクセス頻度の最大値または最小値としてもよい。グループの評価値を上記のような合計値、最大値または最小値とする場合、例えば、アクセス平均算出手段６０が算出した各仲間プレイヤのアクセス平均を、アクセス頻度を示す値として用いて、グループ内の仲間プレイヤのアクセス平均の合計値、最大値または最小値を求めることができる。
【０２４７】
グループの評価値として上記の最大値または最小値を適用した場合、グループ内の一人のアクセス頻度がグループを代表する値となるのに対して、仲間アクセス平均または合計値をグループの評価値とした場合には、グループ内の全員のアクセス頻度が評価値として反映されることになることから、仲間アクセス平均または合計値をグループの評価値とする方が好ましいといえる。すなわち、グループの評価値をグループ内のアクセス頻度の最大値とした場合を考えると、グループ内にアクセス頻度の高くないプレイヤが多数存在したとしても、グループ内にアクセス頻度の高い仲間プレイヤが一人でも存在すれば、グループの評価値としては高くなってしまう。この場合、プレイヤは自分の仲間全体のアクセス頻度を高めようとするのではなく、普段よりアクセス頻度が比較的高い特定の仲間プレイヤ数人のみに対して応援アクセスを働きかけることによりグループの評価値を高めようとする可能性がある。これに対して、グループの評価値をグループ内のアクセス頻度の平均値（仲間アクセス平均）または合計値とすることにより、評価値を高めるためにはグループ内の多くの仲間プレイヤのアクセス頻度を高める必要が生じるので、プレイヤにグループ内の多くの仲間プレイヤとコミュニケーションを図ろうとする動機付けを与えることができる。
【０２４８】
また、グループの評価値として上記の合計値を適用した場合、仲間の人数（グループの人数）が多くなるほど合計値も大きくなる傾向にあるので、グループ内の各仲間プレイヤのアクセス頻度としてはそれ程高くなくとも、グループの人数が多ければ、結果的にグループの評価値が高くなることもある。これに対して、グループの評価値をグループ内のアクセス頻度の平均値（仲間アクセス平均）とすることにより、グループ内の仲間プレイヤの人数等にかかわらずに仲間全員のアクセス頻度の高さが的確に評価値として反映されるので、仲間アクセス平均をグループの評価値とすることがより好ましいといえる。
【０２４９】
また、グループの評価値として上記の合計値を適用する場合、グループに所属する仲間プレイヤの人数が多い程、評価値と比較される基準値（閾値）を高くすることが望ましい。これにより、単純に仲間の人数を増やしただけでは応援アクセス条件を満たせなくなり、評価値を高めるためには仲間全体のアクセス頻度を高める必要が生じるので、プレイヤにグループ内の多くの仲間プレイヤとコミュニケーションを図ろうとする動機付けを与えることができる。
【０２５０】
以上のように、本実施の形態のゲームサーバ１は、欠落日（欠落単位期間）が存在するプレイヤの仲間プレイヤのアクセス頻度に基づいて、当該プレイヤを中心とするグループの評価値を算出する評価値算出手段を備えており、当該評価値が閾値を超えることを応援アクセス条件としている。このような応援アクセス条件にすることにより、プレイヤの仲間プレイヤが応援アクセス条件を満たすためには、仲間プレイヤのアクセスの頻度を高めることによってグループの評価値を上げる必要がある。よって、各プレイヤは、グループに所属する仲間プレイヤのアクセスの頻度を高めようとして、自己の仲間プレイヤと積極的にコミュニケーションをとる動機付けを与えられることになる。これにより、ゲームコミュニティ全体の活性化を図ることができる。
【０２５１】
また、欠落日（欠落単位期間）の直前の所定期間中のグループの評価値（仲間アクセス平均等）が閾値を超えることを応援アクセス条件とすることにより、仲間が応援アクセス条件を満たすためには、欠落日当日の仲間のアクセスではなく、欠落日の直前の所定期間中の仲間のアクセス頻度を高める必要がある。よって、各プレイヤは、応援アクセス条件を満たすために、平素から仲間同士でお互いにアクセス頻度を高めようという意識付け、動機付けを与えられることになる。
【０２５２】
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図２２の機能ブロック図を参照しながら説明する。なお、既出の図面（図１〜図２１）において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
【０２５３】
上述のように、本ゲームシステムでは、プレイヤがゲームサーバ１にアクセスできない日（欠落日）があっても、仲間プレイヤが応援アクセス条件を満たしてくれることにより、欠落日が埋め合わせされて連続アクセス達成特典を獲得できるようになっている。そこで、プレイヤは、予めゲームサーバ１にアクセスできない予定がわかっている場合、自己の仲間にアクセス不可能予定日を通知し、応援アクセス条件を満たしてくれるように仲間に応援アクセスを事前に依頼することもできる。前記の図４または図１９に例示した構成のゲームサーバ１は、メッセージ伝達手段５９を具備しているので、プレイヤは、当該メッセージ伝達手段５９を介して、自己の仲間にアクセス不可能予定日等を記したメッセージを送ることができる。しかしながら、仲間の人数が多い場合には、アクセス不可能予定日等を記したメッセージを、プレイヤの仲間一人ひとりに送信するには時間と労力を要することになる。そこで、本実施の形態のゲームシステムは、プレイヤがアクセス不可能予定日の情報をゲームサーバ１へ１回だけ送信すれば、ゲームサーバ１が当該プレイヤの仲間全員に、アクセス不可能予定日の情報を伝達する構成について説明する。本構成は、前記の図４または図１９に例示した何れのゲームサーバ１にも、あるいは後述するゲームサーバ１にも適用できるが、以下には図４のゲームサーバ１に本構成を適用した例について説明する。
【０２５４】
図２２に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１〜５９に加えて、予定日伝達手段６２（アクセス不可能予定日伝達手段）をさらに備えている。この予定日伝達手段６２は、アクセスができない日程が予め分かっているプレイヤの端末装置３から送信されたアクセス不可能予定日の情報を受信するとともに、当該アクセス不可能予定日の情報を当該プレイヤの仲間プレイヤ全員の端末装置３へ送信し、当該アクセス不可能予定日を当該仲間プレイヤ全員へ伝達する機能を有する。この予定日伝達手段６２は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
【０２５５】
この予定日伝達手段６２は、予定日情報記憶部６２ａを備えている。図２３には、予定日情報記憶部６２ａがデータベースサーバ２に記憶して管理する、予定日情報の一例を示している。この予定日情報記憶部６２ａは、プレイヤＩＤと対応付けて、アクセス不可能予定日の送信情報および受信情報を、プレイヤＩＤ毎にデータベースサーバ２の所定の記憶領域に記憶する。アクセス不可能予定日の送信情報は、プレイヤの端末装置３から送信された情報であって、図２３の例では、プレイヤが自己の仲間プレイヤに通知する「アクセス不可能予定日」に加えて、仲間プレイヤ宛の「メッセージ内容」の情報が含まれている。また、アクセス不可能予定日の受信情報としては、予定日送信側のプレイヤＩＤが記憶されるようになっている。予定日受信側のプレイヤＩＤと対応づけて、予定日送信側のプレイヤＩＤを記憶しておけば、当該予定日送信側のプレイヤＩＤと対応付けて記憶されている予定日送信情報（「アクセス不可能予定日」および「メッセージ内容」）を読み出すことができる。よって、アクセス不可能予定日の受信情報としては、予定日送信側のプレイヤＩＤのみを記憶しておくだけでよい。
【０２５６】
図２３の例では、プレイヤＩＤ＝“０００００１”のプレイヤ１人分の予定日情報を示しており、当該プレイヤは、アクセス不可能予定日＝“２０１１／１／１５”を、「応援アクセスお願いします！」というメッセージとともに、自己の仲間プレイヤ全員に送信している。また、プレイヤＩＤ＝“０００００１”のプレイヤは、プレイヤＩＤ＝“０００００２”およびプレイヤＩＤ＝“０００１１０”の２人の仲間プレイヤから、アクセス不可能予定日の情報を受け取っている。これら２人の仲間プレイヤから受け取った具体的な予定日情報（「アクセス不可能予定日」および「メッセージ内容」）は、当該２人の仲間プレイヤのプレイヤＩＤと対応付けて記憶されている予定日送信情報を参照して取得できる。
【０２５７】
ここで、プレイヤが自分の仲間プレイヤに対してアクセス不可能予定日を通知する操作の一例を説明する。図２４には、ゲームサーバ１から送信された画面データに基づいて、プレイヤの端末装置３に表示される「アクセス不可能予定日通知画面」の一例を示している。この画面は、例えばプレイヤが端末装置３を操作してメイン画面中の「アクセス不可能予定日通知メニュー」を選択することによって表示される画面である。このアクセス不可能予定日通知画面には、アクセス不可能予定日の入力を、プレイヤが簡単に行うことができる入力領域２０１が設けられている。
【０２５８】
この入力領域２０１の例としては、プルダウンメニュー（プルダウンリスト）がある。当該入力領域２０１にカーソルを合わせて端末装置３の決定ボタンを押せば、図２４に例示するように、「明日」、「２日後」、・・・「５日後」の選択項目の一覧リストが垂れ下がって表示されるようにする。この例では、明日〜５日後までのアクセス不可能予定日を選択入力できるようにしているが、これに限定されるものではなく、ｎ日後（ｎは正の整数）まで選択入力できるようにしてもよい。また、「明日」等ではなく、具体的な「日付（月日）」を選択項目として表示してもよい。入力領域２０１の他の例としては、明日〜ｎ日後までの複数の選択項目をラジオボタンとともにリスト表示しておき、選択項目の１つをラジオボタンにより選択入力できるようにしてもよい。あるいは、プレイヤが、アクセス不可能予定日の日付を、直接テキスト形式で入力領域２０１に入力できるようにしてもよい。
【０２５９】
また、このアクセス不可能予定日通知画面には、メッセージ入力領域２０２および送信ボタン２０３というオブジェクトも表示される。そして、プレイヤは、端末装置３を操作してメッセージ入力領域２０３に任意のメッセージを入力し、送信ボタン２０３を選択することによって、端末装置３からは全ての仲間宛のメッセージが、アクセス不可能予定日の情報とともにゲームサーバ１へ送信される。図２４では「応援アクセスお願いします！」というメッセージをプレイヤが入力した例を示している。なお、データベースサーバ２における記憶容量を考慮して、メッセージ入力領域２０２に入力できる文字に制限（例えば全角３０文字以内）を設けてもよい。なお、プレイヤが、入力領域２０１にアクセス不可能予定日を入力し、メッセージ入力領域２０２にはメッセージを入力することなく送信ボタン２０３を押した場合は、アクセス不可能予定日のみが仲間全員に伝達されることになる。また、アクセス不可能予定日通知画面には、仲間リスト画面へ遷移するためのハイパーリンク２０４やメイン画面へ遷移するためのハイパーリンク２０５などを表示してもよい。
【０２６０】
このアクセス不可能予定日通知画面でのプレイヤの操作により端末装置３からアクセス不可能予定日等の情報が送信された場合、ゲームサーバ１では、予定日伝達手段６２の予定日情報記憶部６２ａが、プレイヤの端末装置３から受信した情報（「アクセス不可能予定日」および「メッセージ内容」）を、当該プレイヤのプレイヤＩＤと対応付けてデータベースサーバ２に記憶する（図２３参照）。さらに、予定日情報記憶部６２ａは、予定日を送信したプレイヤの仲間プレイヤの全員を対象として、各仲間プレイヤのプレイヤＩＤと対応付けて、予定日送信側のプレイヤＩＤを記憶する（図２３参照）。
【０２６１】
そして、予定日の通知を受けた仲間プレイヤの端末装置３がゲームサーバ１へアクセスしたとき、ゲームサーバ１の予定日伝達手段６２は、予定日送信側のプレイヤＩＤと対応付けて記憶されている「アクセス不可能予定日」および「メッセージ内容」等を表示させる画面データを、当該仲間プレイヤの端末装置３に送信する。これにより、この画面データを受信したプレイヤの端末装置３には、例えば図２５に示す仲間の情報画面が表示され、プレイヤは、他の仲間のアクセス不可能予定日等を画面で確認できるようになっている。この仲間の情報画面は、ゲームのメイン画面の一部として、またはメイン画面にリンクした別画面として、端末装置３の表示部３５に表示される画面である。図２５の画面例では、仲間からの応援アクセス依頼情報として、アクセス不可能予定日を送信したプレイヤのアバター２０６、プレイヤ名２０７、アクセス不可能予定日２０８およびメッセージ２０９が表示されている。なお、画面に表示しきれない仲間の情報については、画面をスクロールすることにより表示することができる。また、この仲間の応援アクセス依頼情報は、アクセス不可能予定日が経過するまで、応援アクセス依頼を受けた仲間プレイヤの端末装置３の画面にて確認できるようになっている。
【０２６２】
このように、本実施の形態のゲームシステムでは、図２４に例示するようなコミュニケーションツールを使用して、プレイヤが簡単な操作によって、アクセス不可能予定日を仲間に通知できるようになっている。そして、本実施の形態では、プレイヤは、アクセス不可能予定日をゲームサーバ１へ１回だけ送信する操作を行うだけで、自己の仲間全員にアクセス不可能予定日やオリジナルメッセージを送信することが可能であり、プレイヤ側の操作の容易化が図られている。特に、ソーシャルゲーム等のプレイヤの操作の容易化が強く求められるゲームサービスには、本実施の形態の構成が好適である。
【０２６３】
ところで、応援アクセス条件を満たしているか否かの判定は、１日に一度もゲームサーバ１へアクセスしなかった（単位期間内アクセスを達成できなかった）プレイヤに対して、アクセスの欠落が生じる度に行われる処理である。ゲームサーバ１が管理しているゲームサービス利用登録者数が多くなるほど、アクセスの欠落を生じるプレイヤの数も多くなるため、ゲームサーバ１の処理負荷は大きくなる。例えば１００万人のゲームサービス利用登録者のうちの約１割にアクセスの欠落が生じただけでも、１０万人程度のプレイヤに対して応援アクセス条件を満たしているか否かの判定処理が実行されることになる。そして、この応援アクセス条件を満たしているか否かの判定処理は、プレイヤがゲームサーバ１にゲーム実行を要求して行われる処理ではなく、プレイヤがゲームサーバ１へアクセスしなかったという消極的な事実に対して行われる処理でもあることから、できるだけゲームサーバ１の処理負荷を軽減して実行したい処理でもある。
【０２６４】
そこで、図２２に示す仲間応援アクセス判定手段５６は、プレイヤが予定日伝達手段６２によって仲間プレイヤへアクセス不可能予定日を事前に伝達した上で当該アクセス不可能予定日と同じ日にアクセスをしなかった場合に限り、当該プレイヤの仲間プレイヤが応援アクセス条件を満たしているか否かを判定するようにしてもよい。すなわち、仲間プレイヤへのアクセス不可能予定日の事前通知を、応援アクセス条件を満たしているか否かの判定を受けるための必須条件とするのである。これを前記図１５のフローチャートの処理に適用した場合を例示すると、図２６のフローチャートに示すようになる。
【０２６５】
すなわち、現実世界の１日（単位期間）の終了後の処理の開始時間になれば（Ｓ３１でＹＥＳ）、先ず、前日が、プレイヤから仲間プレイヤへ事前通知されたアクセス不可能予定日であるか否かが判断される（Ｓ１０１）。そして、前日がアクセス不可能予定日であった場合（Ｓ１０１でＹＥＳ）、応援アクセス条件を満たしているか否かの判定処理（Ｓ３４およびＳ３５）を含むＳ３２〜Ｓ４０のルーチンに移行する。一方、前日がアクセス不可能予定日でなかった場合（Ｓ１０１でＮＯ）、応援アクセス条件を満たしているか否かの判定処理を含むルーチンに移行することなく、図２６のフローチャートの処理を終了する。
【０２６６】
このように、プレイヤによるアクセス不可能予定日の事前通知を、応援アクセス条件を満たしているか否かの判定処理を実行するための条件とすることにより、ゲームサーバ１は、アクセス不可能予定日に限定して、応援アクセス条件を満たしているか否かの判定処理や、当該条件を満たしている場合のその後の処理を行うため、ゲームサーバ１の処理負担を大幅に軽減できる。
【０２６７】
また、プレイヤにとっては、仲間プレイヤへアクセス不可能予定日を事前に通知していない日に、ゲームサーバ１へアクセスをしなかった場合、応援アクセス条件を満たしているか否かの判定を受けられず、よって欠落日の埋め合わせがされることはない。よって、各プレイヤは、アクセスできそうにない日が予定されている場合、仲間に対して積極的にアクセス不可能予定日を通知して応援アクセスの事前依頼を行うようになり、これによって仲間同士のコミュニケーションの活性化が図れる。
【０２６８】
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図２７の機能ブロック図を参照しながら説明する。なお、既出の図面（図１〜図２６）において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
【０２６９】
本実施の形態では、仲間の応援アクセスによりプレイヤに連続アクセス達成特典が付与された場合、この応援アクセスに寄与した仲間にも、何らかのメリットが与えられるようにする構成について説明する。本構成は、前記の図４、図１９または図２２に例示した何れのゲームサーバ１にも、あるいは後述するゲームサーバ１にも適用できるが、以下には図４のゲームサーバ１に本構成を適用した例について説明する。
【０２７０】
図２７に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１〜５９に加えて、応援アクセス特典付与手段６３をさらに備えている。この応援アクセス特典付与手段６３は、欠落日（欠落単位期間）が存在するプレイヤの仲間プレイヤが応援アクセス条件を満たすことによって連続アクセス達成特典が付与されたプレイヤの仲間プレイヤであって、当該応援アクセス条件を満たすアクセスを行った仲間プレイヤに対して、ゲーム上有利になるように当該仲間プレイヤのゲーム情報を変更して応援アクセス特典を付与する機能を有する。この応援アクセス特典付与手段６３は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
【０２７１】
ここで、応援アクセスに寄与した仲間プレイヤに付与される応援アクセス特典とは、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、連続アクセス達成特典と同様に、ゲームの種類や内容に応じて様々な特典を適用できる。ただし、特典の大きさ（メリットの程度）については、連続アクセス達成プレイヤに対して付与される連続アクセス達成特典よりも、連続アクセス達成の一助となった仲間プレイヤに対して付与される応援アクセス特典の方が、小さな特典とすることが望ましい。例えば、連続アクセス達成特典が２００ポイント分の強化ポイントであった場合、応援アクセス特典は５０〜１００ポイント分の強化ポイントとする。また、例えば、連続アクセス達成特典を回復アイテム３つとするのに対して、応援アクセス特典をフェイクカード１つとする等、連続アクセス達成特典と応援アクセス特典とで特典の種類を変えてもよい。
【０２７２】
次に、図２８のフローチャートを参照しながら、本実施の形態のゲーム管理装置（ゲームサーバ１）の動作について説明する。図２８は、ある一人のプレイヤを中心とした仲間というグループに対して実行される処理の流れを示すものであり、ゲームサーバ１が管理している各々のプレイヤを中心としたグループに対して同様の処理が行われる。
【０２７３】
あるプレイヤに連続アクセス達成特典が付与された場合（Ｓ１１１）、当該プレイヤが欠落日の埋め合わせなしに連続アクセスを達成したのか、それともアクセスの欠落日があったにもかかわらず仲間の応援アクセスにより欠落日が埋め合わされたことによって連続アクセスを達成したのかが判断される（Ｓ１１２）。この判断は、プレイヤＩＤと対応付けて記憶されている図９（ａ）に例示するアクセス情報（日々のアクセスの有無および応援アクセス条件達成を示す情報）に基づいて行うことができる。
【０２７４】
ここで、プレイヤが欠落日の埋め合わせなしに連続アクセスを達成していた場合（Ｓ１１２でＮＯ）、当該プレイヤの仲間プレイヤに応援アクセス特典を付与する処理を行うことなく図２８に示すルーチンを終了する。一方、欠落日が埋め合わされたことによってプレイヤが連続アクセスを達成していた場合（Ｓ１１２でＹＥＳ）、ゲームサーバ１の応援アクセス特典付与手段６３は、欠落日の埋め合わせに寄与した仲間プレイヤ、すなわち応援アクセス条件を満たすアクセスを行った仲間プレイヤを抽出する（Ｓ１１３）。
【０２７５】
このＳ１１３における仲間プレイヤの抽出処理は、応援アクセス条件が「欠落日と同じ日にゲームサーバ１へアクセスした仲間プレイヤの人数または当該仲間プレイヤ全体に占める割合が、閾値を超えること」であった場合、次のようにして実現できる。すなわち、応援アクセス条件が満たされた欠落日と同じ日に、ゲームサーバ１へアクセスした仲間プレイヤを、プレイヤＩＤと対応付けて記憶されている図９（ａ）に例示するアクセス情報（日々のアクセスの有無の情報）に基づいて抽出する。
【０２７６】
また、応援アクセス条件が「欠落日が存在するプレイヤの仲間というグループの評価値が、閾値を超えること」であった場合、Ｓ１１３の抽出処理は次のようにして実現できる。例えばグループの評価値が仲間アクセス平均であり、閾値が０．８であった場合、アクセス平均が０．８以上の仲間プレイヤを抽出する。
【０２７７】
また、グループの評価値が仲間プレイヤのアクセス頻度の合計値の場合、アクセス頻度が０ではない仲間プレイヤが応援アクセス条件を満たすために寄与したことになるので、アクセス頻度が０でない仲間プレイヤを全て抽出してもよい。但し、アクセス頻度の高さによって寄与の程度は大きく異なるので、アクセス頻度が高い仲間プレイヤほど、応援アクセス特典を高くする構成にしてもよい。また、その寄与の程度が極めて低いアクセス頻度が所定の値以下の仲間プレイヤについては、Ｓ１１３の抽出の対象から除外してもよい。
【０２７８】
また、グループの評価値が「グループ内のアクセス頻度の最大値」であった場合、当該最大値の仲間プレイヤのみを抽出する。この場合、抽出される仲間プレイヤは一人だけあり、その寄与の程度は大きいことから、他の応援アクセス条件のときに比べて応援アクセス特典を大きくしてもよい。また、グループの評価値が「グループ内のアクセス頻度の最小値」であった場合、全ての仲間プレイヤが応援アクセス条件を満たすために寄与したことになるので、仲間プレイヤを全て抽出してもよい。
【０２７９】
Ｓ１１３の後、応援アクセス特典付与手段６３は、ゲーム上有利になるように、抽出した仲間プレイヤのゲーム情報を変更して応援アクセス特典を付与する（Ｓ１１４）。例えば、所定の強化ポイントを応援アクセス特典として仲間プレイヤに付与する場合、当該仲間プレイヤのプレイヤＩＤに対応するゲーム情報（図６に例示するプレイヤの強化ポイントの情報）が変更されることになる。
【０２８０】
応援アクセス特典が付与されたプレイヤに対しては、当該特典の付与後にプレイヤの端末装置３がゲームサーバ１に最初にアクセスしたとき、ゲームサーバ１より当該特典が付与された旨を報知する画面データが、プレイヤの端末装置３へ送信される。これにより、プレイヤは、自分の応援アクセスによって仲間が連続アクセス達成特典を獲得したこと、およびそれによって自分にも応援アクセス特典が付与されたことを認識できる。
【０２８１】
以上のように、欠落日が存在するプレイヤの仲間プレイヤが応援アクセス条件を満たすことによって当該プレイヤに連続アクセス達成特典が付与された場合、応援アクセスに寄与した仲間プレイヤにも応援アクセス特典を付与することにより、各プレイヤは、仲間の応援アクセスを積極的に行おうとする意識付け、動機付けが与えられることになる。
【０２８２】
次に、プレイヤを中心とする仲間というグループの中に、連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる場合、当該プレイヤにさらなるメリットが与えられるようにする構成について説明する。本構成は、前記の図４、図１９または図２２に例示した何れのゲームサーバ１にも、あるいは後述するゲームサーバ１にも適用できるが、以下には図４のゲームサーバ１に本構成を適用した例について説明する。
【０２８３】
図２７に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１〜５９に加えて、仲間特典付与手段６４をさらに備えている。この仲間特典付与手段６４は、プレイヤを中心とする仲間というグループの中に連続アクセス達成特典が付与された仲間プレイヤが所定の人数以上または所定の割合以上いる当該プレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して仲間特典を付与する機能を有する。この仲間特典付与手段６４は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
【０２８４】
ここで、各プレイヤを中心とするグループ内の連続アクセス達成特典が付与された仲間プレイヤの人数または割合を求めるに際しては、当該中心となるプレイヤを含めてもよいし、当該中心となるプレイヤを除外してもよい。なお、仲間を一人も作っていないプレイヤに関しては、当該プレイヤを中心とする仲間というグループ自体が存在しないため、仲間特典が付与されることはない。
【０２８５】
ここで、仲間特典とは、当該特典が付与されなかった場合と比較してゲーム上有利になるものであればよく、連続アクセス達成特典と同様に、ゲームの種類や内容に応じて様々な特典を適用できる。この仲間特典は、自己の仲間グループ内に連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる必要がある達成難易度の高い特典であるため、その特典の大きさ（メリットの程度）については、連続アクセス達成プレイヤに対して付与される連続アクセス達成特典と同程度またはそれよりも大きい特典とすることもできる。例えば、連続アクセス達成特典が２００ポイント分の強化ポイントであった場合、仲間特典は２００〜３００ポイント分の強化ポイントとする。また、例えば、連続アクセス達成特典を２００ポイント分の強化ポイントとするのに対して、仲間特典を回復アイテム３つとする等、連続アクセス達成特典と仲間特典とで特典の種類を変えてもよい。
【０２８６】
この仲間特典を適用する例としては、前述の期間限定のゲーム内イベントにおいて適用することができる。すなわち、当該イベント期間中の連続アクセスの達成者に対して連続アクセス達成特典を付与するとともに、当該イベント期間中にグループ内に連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いるプレイヤに対して仲間特典を付与する。
【０２８７】
また、前記の期間限定のゲーム内イベントを開催していない通常時においても、所定の期間（例えば毎週月曜日から日曜日）を定めて、当該期間中にグループ内に連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いるプレイヤに対して、仲間特典を付与してもよい。
【０２８８】
次に、図２９のフローチャートを参照しながら、本実施の形態のゲーム管理装置（ゲームサーバ１）の動作について説明する。図２９は、ある一人のプレイヤに対して実行される処理の流れを示すものであり、ゲームサーバ１が管理している各々のプレイヤに対して同様の処理が行われる。
【０２８９】
仲間特典を付与するか否かを判定する所定の期間が終了すると（Ｓ１２１）、ゲームサーバ１は、プレイヤに仲間が存在するか否かを判断する（Ｓ１２２）。ここで、プレイヤが一人も仲間を作っていなかった場合（Ｓ１２２でＮＯ）、ゲームサーバ１は、当該プレイヤに対しては仲間特典を付与するか否かの判定を行うことなく処理を終了する。一方、プレイヤに仲間が存在する場合（Ｓ１２２でＹＥＳ）、ゲームサーバ１の仲間特典付与手段６４は、仲間管理手段５３が管理しているプレイヤの仲間情報および連続アクセス特典付与手段５７が連続アクセス達成特典をプレイヤに付与した情報（図６に例示する特典情報）に基づいて、プレイヤを中心とするグループ内の連続アクセス達成特典が付与された仲間プレイヤの人数または割合を求める（Ｓ１２３）。なお、図２９では、仲間プレイヤの人数Ｎを求める例を示している。
【０２９０】
その後、仲間特典付与手段６４は、Ｓ１２３で求めた人数Ｎが所定の閾値（図２９では閾値を１０とした例を示している）以上であるか否かを判定する。ここで、人数Ｎが閾値より小さい場合は（Ｓ１２４でＮＯ）、プレイヤに仲間特典が付与されることなく終了する。一方、人数Ｎが閾値以上の場合（Ｓ１２４でＹＥＳ）、仲間特典付与手段６４は、ゲーム上有利になるようにプレイヤのゲーム情報を変更して、仲間特典を付与する（Ｓ１２５）。例えば、所定の強化ポイントを仲間特典としてプレイヤに付与する場合、当該プレイヤのプレイヤＩＤに対応するゲーム情報（図６に例示するプレイヤの強化ポイントの情報）が変更されることになる。
【０２９１】
仲間特典が付与されたプレイヤに対しては、当該特典の付与後にプレイヤの端末装置３がゲームサーバ１に最初にアクセスしたとき、ゲームサーバ１より当該特典が付与された旨を報知する画面データが、プレイヤの端末装置３へ送信される。これにより、プレイヤは、自己の仲間グループの中に連続アクセス達成特典を獲得した仲間プレイヤが閾値以上いたことにより、仲間特典が付与されたことを認識できる。
【０２９２】
以上のように、本実施の形態では、プレイヤを中心とする仲間というグループの中に、連続アクセス達成特典を獲得した仲間プレイヤが所定の人数以上または所定の割合以上いる場合、当該プレイヤに仲間特典が付与されるという構成である。この構成が「応援アクセスによる欠落日の埋め合わせによって仲間が連続アクセス達成特典を獲得し易くなる」という構成と相俟って、各プレイヤには、自己の仲間の多くが連続アクセス達成特典を獲得できるようにアクセス頻度を高めようとする意識付け、動機付けが与えられることになる。すなわち、連続アクセス達成特典だけではなく、さらに仲間特典を獲得するチャンスがあり、自分が連続アクセス達成特典を獲得するためだけでなく、多くの仲間プレイヤが連続アクセス達成特典を獲得できるようにするために、プレイヤはゲームサーバ１へのアクセス頻度を高めようとする動機付けが与えられる。また、連続アクセスが途中で途絶えて連続アクセス達成特典を獲得できなくなったプレイヤにとっても、自己の仲間プレイヤの多くが連続アクセス達成特典を獲得すれば仲間特典を獲得するチャンスがある。よって、応援アクセスにより多くの仲間プレイヤが連続アクセス達成特典を獲得できるようにするために、プレイヤはゲームサーバ１へのアクセス頻度を高めようとする動機付けが与えられる。
【０２９３】
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置の他の構成例を、図３０の機能ブロック図を参照しながら説明する。なお、既出の図面（図１〜図２９）において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。本実施の形態の構成は、前記の図４、図１９、図２２または図２７に例示した何れのゲームサーバ１にも、あるいは後述するゲームサーバ１にも適用できるが、以下には図４のゲームサーバ１に本構成を適用した例について説明する。
【０２９４】
図３０に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１〜５９に加えて、アクセス頻度表示制御手段１００（表示制御手段）をさらに備えている。このアクセス頻度表示制御手段１００は、アクセスを受け付けたプレイヤの端末装置３に、他のプレイヤのアクセス頻度の情報を含む画面データ（表示制御情報）を送信することによって、プレイヤの端末装置３の画面に、他のプレイヤのアクセス頻度を表示させる機能を有する。このアクセス頻度表示制御手段１００は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
【０２９５】
本ゲームシステムにおいては、アクセスの欠落が生じたときに、プレイヤの仲間による応援アクセスの如何によって欠落日の埋め合わせがなされるか否かが決まるので、プレイヤにとっては、これから仲間になるプレイヤや既に仲間になっているプレイヤのアクセス頻度の情報は重要である。そこで、本実施の形態のアクセス頻度表示制御手段１００は、各プレイヤの便宜に供するための情報として、他のプレイヤのアクセス頻度の情報を、プレイヤの端末装置３の画面に表示させるようになっている。
【０２９６】
ここで、他のプレイヤのアクセス頻度が表示される画面の例としては、図３１に示すような仲間候補リスト画面が挙げられる。この仲間候補リスト画面は、仲間を作ろうとするプレイヤが、自己の端末装置３で仲間候補を検索するゲーム操作を行うことにより、ゲームサーバ１から送信されてくるゲーム画面の一つである。この仲間候補リスト画面には、ゲームサーバ１により抽出された、プレイヤとは未だ仲間関係にない複数のプレイヤが、仲間候補者としてリストアップされて表示される。なお、画面に表示しきれない仲間候補プレイヤの情報については、画面をスクロールして表示するか、または仲間候補リストの２ページ目以降をゲームサーバ１にリクエストして別画面として表示することができる。仲間候補リスト画面内には、リストアップされた仲間候補のプレイヤ毎の情報表示領域が設けられており、各情報表示領域には、仲間候補プレイヤのゲーム情報１１１（プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等）、仲間候補プレイヤの分身的なキャラクタであるアバター１１２、仲間候補プレイヤが所有するリーダーの選手カード１１３等とともに、仲間候補プレイヤのアクセス頻度１１４が表示される。
【０２９７】
プレイヤは、この仲間候補リスト画面でリストアップされた他のプレイヤの情報を確認し、仲間申請したいと思うプレイヤを見つけることになる。また、この仲間候補リスト画面で、例えばプレイヤ名のハイパーリンク１１１ａを選択する操作がなされれば、ゲームサーバ１が当該操作に応答し、当該プレイヤ名のプレイヤについてのより詳細なゲーム情報（例えば、リーダーの選手カード１１３の能力値など）を表示する画面データを端末装置３へ送信する。この画面データには、仲間申請ボタンやエールボタン（またはそれらのハイパーリンク）も含まれており、プレイヤは端末装置３を操作して仲間申請やメッセージの送信ができるようになっている。
【０２９８】
ここで、画面に表示されるアクセス頻度１１４の情報としては、例えば、所定期間中のプレイヤのアクセス平均（例えば直近７日間のアクセス平均）の値とすることができる。本実施の形態では、図９（ａ）または（ｂ）に例示するように、アクセス管理手段５５のアクセス情報記憶部５５ａが、ｎ日前までのアクセスの有無またはアクセス回数の情報を、プレイヤＩＤ毎に記憶しているので、この情報より直近ｎ日間のアクセス平均を算出し、算出したアクセス平均を画面に表示されるアクセス頻度１１４の情報とすることができる。
【０２９９】
画面に表示されるアクセス頻度１１４の情報は、直近ｎ日間のアクセス平均に限定されるものではなく、例えば、先週のアクセス平均、先月のアクセス平均、直近ｎ日間の合計アクセス回数、先週の合計アクセス回数、先月の合計アクセス回数など、プレイヤの過去のアクセス頻度が分かる情報であればよい。あるいは、アクセス頻度１１４の情報を多段階表示、例えばＡ〜Ｃの３段階（Ａ：アクセスが多い、Ｂ：アクセスが普通、Ｃ：アクセスが少ない）で表示してもよい。
【０３００】
このように、本実施の形態では、プレイヤが仲間を作ろうとするときに端末装置３の表示部３５に表示される仲間候補リスト画面において、リストアップされる各プレイヤの過去のアクセス頻度を表示する。これにより、プレイヤは、画面上で他のプレイヤのアクセス頻度を見て、仲間を作るときの一つの目安とすることができる。すなわち、本実施の形態では、アクセスの欠落が生じた際に仲間による応援アクセス条件を満たすためには、仲間のアクセス頻度が高いことが望まれるので、アクセス頻度が仲間を作るときの一つの目安となるのである。
【０３０１】
なお、仲間候補リスト画面には、アクセス頻度の情報以外にも、各プレイヤのレベルや能力を表す情報（プレイヤレベルや所属リーグのレベルなど）も併せて表示されるところ、上記の構成によれば、プレイヤは、他のプレイヤを仲間にするか否を判断する際に、当該プレイヤのレベルや能力等のみならず、アクセス頻度も考慮し、これらを総合的に判断して、仲間にしたい他のプレイヤを選ぶことができる。
【０３０２】
また、仲間申請を受けたプレイヤにおいても、当該プレイヤの端末装置３の図示しない画面には、仲間申請をしたプレイヤの情報の一つとしてアクセス頻度が表示されるようになっており、当該アクセス頻度を、仲間申請を承認するか否かを判断する際の一つの目安とすることもできる。
【０３０３】
他のプレイヤのアクセス頻度が表示される画面の他の例としては、図３２に示すような仲間リスト画面が挙げられる。上述したように仲間リスト画面には、プレイヤと仲間関係にある仲間プレイヤの情報がリストアップされて表示される。この仲間リスト画面には、仲間プレイヤのゲーム情報８１（プレイヤ名、チーム名、プレイヤのレベル、仲間の人数、所属リーグのレベル等）、アバター８２、所有するリーダーの選手カード８３、エールボタン８４等とともに、当該仲間プレイヤのアクセス頻度１１４が表示される。このアクセス頻度１１４は、前述したとおり、プレイヤの過去のアクセス頻度が分かる情報であればよく、例えばプレイヤの直近ｎ日間のアクセス平均等である。
【０３０４】
このように、仲間リスト画面に仲間プレイヤのアクセス頻度１１４が表示されることにより、次のような利用も可能になる。すなわち、アクセスを欠落したときに仲間が応援アクセス条件を満たしてくれるように、常日頃から自己のグループに所属する仲間プレイヤ全体のアクセス頻度を高めておくことが望ましい。そこで、仲間リスト画面に表示されたアクセス頻度１１４に基づいて、アクセス頻度が低い仲間プレイヤを把握し、当該仲間プレイヤに対し応援メッセージ等を送信してアクセス頻度を上げるように仕向けることにより、効率的にグループ全体のアクセス頻度を高めることができる。
【０３０５】
ここで、各仲間プレイヤのアクセス頻度１１４の把握をさらに容易化するために、アクセス頻度の低い方（または高い方）から順に仲間プレイヤの画面上の表示順序を並べかえるための表示順変更ボタン（その他の選択可能なオブジェクトであってもよい）を、プレイヤの端末装置３に表示してもよい。この表示順変更ボタンを選択する操作がプレイヤの端末装置３においてなされた場合、当該操作に応じてゲームサーバ１が、アクセス頻度の低い方（または高い方）から順に仲間プレイヤを並び替えた画面データを端末装置３へ送信する。この画面データを受信した端末装置３にはアクセス頻度順に並べられた仲間プレイヤが表示されるので、プレイヤは、アクセス頻度の低かった仲間プレイヤを迅速に把握でき、当該仲間プレイヤに対して即座に応援メッセージ等の送信ができるようになる。
【０３０６】
〔ゲーム管理装置の他の構成例〕
次に、ゲーム管理装置のさらに他の構成例を、図３３の機能ブロック図を参照しながら説明する。なお、既出の図面（図１〜図３２）において示した構成と同様の構成については同一の部材番号を付し、適宜その説明を省略する。
【０３０７】
本実施の形態では、プレイヤの仲間の一部または全部の仲間登録を、当該プレイヤの意思に基づいて解除することができるようになっているゲームシステムについて説明する。プレイヤがアクセスを欠落したときに、その欠落日の埋め合わせの可能性を高める（仲間プレイヤが応援アクセス条件を満たす可能性を高める）ためには、自己のグループ内の仲間プレイヤのアクセス頻度が高いことが望まれるが、プレイヤが仲間登録を自由に解除できる場合、次のような事態も考えられる。すなわち、アクセス頻度の低い仲間プレイヤに応援メッセージを送ってアクセス頻度を高めようとするのではなく、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって欠落日の埋め合わせの可能性を高めようとする、本来の目的とはかけ離れた方法を採ろうとするプレイヤが出てくる可能性も考えられる。そこで、この対策として、本実施の形態では、以下に説明するように、プレイヤが仲間登録を解除した場合、当該解除から一定期間、応援アクセス条件を厳しくすることによって連続アクセス達成特典が付与され難くする、又は本来得られる連続アクセス達成特典を小さくする構成を採用するものである。この構成は、前記の図４、図１９、図２２、図２７または図３０に例示した何れのゲームサーバ１にも適用できるが、以下には図４のゲームサーバ１に本構成を適用した例について説明する。
【０３０８】
図３３に示すように、本実施の形態のゲームサーバ１（ゲーム管理装置）は、図４に示した各手段５１〜５９に加えて、特典付与調整手段１２１をさらに備えている。また、本実施の形態の仲間管理手段５３は、仲間登録解除手段１２２をさらに備えている。前記の特典付与調整手段１２１および仲間登録解除手段１２２は、ゲームサーバ１のＣＰＵ１１が本実施の形態に係るプログラムを実行することにより実現されるものである。
前記の仲間登録解除手段１２２は、各プレイヤから仲間登録の解除を受け付ける機能を有する。この仲間登録解除手段１２２の動作例を以下に示す。
【０３０９】
例えば、プレイヤＡ（プレイヤＩＤ＝“０００００１”）が端末装置３を操作し、仲間プレイヤＢ（プレイヤＩＤ＝“０００００２”）の登録を解除する操作を行ったとき、当該操作に応じた通信データ（リクエスト）がゲームサーバ１へ送信される。この通信データを受信したゲームサーバ１では、仲間登録解除手段１２２が、プレイヤＡおよびプレイヤＢ相互間の仲間登録を解除する。
【０３１０】
すなわち、仲間情報記憶部５３ａが記憶している、図３４（ａ）に例示するプレイヤ毎の仲間情報について、仲間登録解除手段１２２は、プレイヤＡのプレイヤＩＤ＝“０００００１”と対応づけて記憶されている仲間プレイヤＩＤの情報欄から、プレイヤＢのプレイヤＩＤ＝“０００００２”を削除する（同図中では、便宜上、二重取り消し線でこれを示している）。さらに、仲間登録解除手段１２２は、プレイヤＡのプレイヤＩＤ＝“０００００１”と対応づけて、仲間登録解除情報を記録する。ここで記録される仲間登録解除情報とは、解除相手であるプレイヤＢのプレイヤＩＤ＝“０００００２”、解除日及び解除者フラグの情報等である。解除者フラグとは、例えば仲間登録を解除した側を「１」、解除された側を「０」として、両者を区別するための情報である。図３４（ａ）の例では、プレイヤＡが仲間登録を解除した側であるため、解除者フラグ＝１が設定されている。
【０３１１】
さらに、図３４（ｂ）に示すように、仲間登録解除手段１２２は、プレイヤＢのプレイヤＩＤ＝“０００００２”と対応づけて記憶されている仲間プレイヤＩＤの情報記憶欄からも、プレイヤＡのプレイヤＩＤ＝“０００００１”を削除する（同図中では、便宜上、二重取り消し線でこれを示している）。さらに、仲間登録解除手段１２２は、プレイヤＢのプレイヤＩＤ＝“０００００２”と対応づけて、仲間登録解除情報を記録する。この場合に記録される仲間登録解除情報は、解除相手であるプレイヤＡのプレイヤＩＤ＝“０００００１”、解除日および解除者フラグ＝０等の情報である。
【０３１２】
ゲームサーバ１は、上記の仲間登録解除処理後、仲間登録を解除された側のプレイヤＢの端末装置３がゲームサーバ１にアクセスしたとき、プレイヤＡから仲間登録が解除された旨を通知する。また、ゲームサーバ１は、プレイヤによる仲間登録の解除が安易に行われないようにするために、仲間登録を解除した側のプレイヤＡに対して、例えば所有ポイントを削減する等のペナルティを科してもよい。
【０３１３】
次に、特典付与調整手段１２１について説明する。この特典付与調整手段１２１は、仲間登録の解除をしたプレイヤに対して、当該仲間登録の解除から所定期間、当該仲間登録の解除がない場合に比べて、応援アクセス条件を厳しくして連続アクセス達成特典が付与され難くする、又は応援アクセス条件を満たして獲得した連続アクセス達成特典を小さくすることによって、特典の付与調整を行う機能を有する。この特典付与調整手段１２１を備えたゲームサーバ１の処理例を、図３５のフローチャートに示す。
【０３１４】
図３５において、Ｓ３１〜Ｓ３４については、基本的には図１５のフローチャートで説明した処理と同様の処理である。Ｓ３４の後、プレイヤが所定期間内、例えば直近の４週間以内に仲間登録の解除を行っているか否かが判断される（Ｓ１３０）。このＳ１３０の判断は、例えば図３４（ａ）に示すように、仲間管理手段５３が管理する各プレイヤの仲間登録解除情報（解除日及び解除者フラグ）に基づいて行うことができる。すなわち、４週間以内に仲間登録の解除を行っているプレイヤとは、当該プレイヤのプレイヤＩＤに対応付けられた仲間登録解除情報として、４週間以内の解除日および解除者フラグ＝１の情報を有するプレイヤである。
【０３１５】
プレイヤが４週間以内に仲間登録の解除を行っていない場合（Ｓ１３０でＮＯ）、Ｓ３４で算出された割合Ｒが例えば０．８以上という応援アクセス条件を満たしているか否かが判定される（Ｓ３５）。一方、プレイヤが４週間以内に仲間登録の解除を行っている場合（Ｓ１３０でＹＥＳ）、前記Ｓ３５より厳しい応援アクセス条件となるように、Ｓ３４で算出された割合Ｒが例えば０．９以上であるか否かが判定される（Ｓ１３１）。すなわち、特典付与調整手段１２１は、プレイヤが４週間以内に仲間登録の解除を行っている場合における応援アクセス条件の閾値を、その解除を行っていない場合よりも高く設定することによって、仲間登録を解除したプレイヤに対して欠落日の埋め合わせの困難性を高めている。なお、以降の処理（Ｓ３６〜Ｓ４０）は、基本的には図１５のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
【０３１６】
この図３５に例示した処理により、仲間登録の解除をしたプレイヤは、仲間登録の解除から４週間、仲間登録の解除がない場合に比べて、応援アクセス条件が厳しくなる。これにより、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって欠落日の埋め合わせの可能性を高めようとしても、仲間登録を解除したことによって、一定期間（この例では４週間）応援アクセス条件が厳しくなり、結果的にアクセスを欠落したときに連続アクセス達成特典を獲得し難くなる。よって、欠落日の埋め合わせの可能性を高めるために仲間登録を解除するといった、本来の目的とはかけ離れた行動をプレイヤがとることを効果的に抑制できる。
【０３１７】
また、特典付与調整手段１２１を備えたゲームサーバ１の他の処理例を、図３６のフローチャートを参照して、以下に説明する。
図３６において、Ｓ５１〜Ｓ５７については、基本的には図１６のフローチャートで説明した処理と同様の処理である。プレイヤの連続アクセス日数が５日に達している場合（Ｓ５６でＹＥＳ）、連続アクセス特典付与手段５７が、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する（Ｓ５７）。例えば、２００ポイント分の強化ポイントがボーナスポイントとしてプレイヤに付与される。
【０３１８】
その後、当該プレイヤが欠落日の埋め合わせなしに連続アクセスを達成したのか、それともアクセスの欠落日があったにもかかわらず仲間の応援アクセスにより欠落日が埋め合わされたことによって連続アクセスを達成したのかが判断される（Ｓ１４１）。ここで、欠落日が埋め合わされたことによってプレイヤが連続アクセスを達成していた場合（Ｓ１４１でＹＥＳ）、特典付与調整手段１２１は、プレイヤが所定期間内、例えば直近の４週間以内に仲間登録の解除を行っているか否かを判断する（Ｓ１４２）。ここで、プレイヤが４週間以内に仲間登録の解除を行っている場合（Ｓ１４２でＹＥＳ）、特典付与調整手段１２１は、プレイヤに付与される連続アクセス達成特典を、前記Ｓ５７で付与される特典（２００強化ポイント）よりも縮小して、例えば１００強化ポイントへと調整する（Ｓ１４３）。なお、以降の処理（Ｓ５８〜Ｓ６４）は、基本的には図１６のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
【０３１９】
この図３６に示した処理により、仲間登録の解除をしたプレイヤは、仲間登録の解除から４週間、仲間登録の解除がない場合に比べて、欠落日が埋め合わされたことによって獲得した連続アクセス達成特典が縮小される。これにより、アクセス頻度の低い仲間プレイヤの仲間登録を解除することによって欠落日の埋め合わせの可能性を高めようとしても、仲間登録を解除したことによって、一定期間（この例では４週間）、本来得られるはずの連続アクセス達成特典よりも小さい特典しか得られなくなる。よって、欠落日の埋め合わせの可能性を高めるために仲間登録を解除するといった、本来の目的とはかけ離れた行動をプレイヤがとることを効果的に抑制できる。
【０３２０】
なお、図３５および図３６に示した上記の例では、仲間登録の解除から４週間を、仲間登録を解除したペナルティの期間として、連続アクセス達成特典そのものを付与され難くする又は本来の連続アクセス達成特典よりも小さい特典を付与することにより特典の付与調整をしているが、これに限定されるものではなく、例えば、当該期間を１週間〜３週間程度に短縮してもよいし、逆に４週間よりも長く設定してもよく、任意の期間を設定可能である。
【０３２１】
また、上記の例では、所定期間内に１人でも仲間登録の解除を行えば、特典付与調整手段１２１による連続アクセス達成特典の付与調整が行われる例について説明したが、これに限定されるものではなく、例えば、所定期間内にｎ人以上（例えば１週間以内に２人以上）の仲間登録を解除した場合にのみ特典の付与調整が行われるようにしてもよい。
【０３２２】
ところで、プレイヤがアクセス頻度の低い仲間プレイヤに応援メッセージを送って仲間のアクセスを高める努力をしたにもかかわらず、当該仲間プレイヤのアクセス頻度が低いままであるため、やむなく仲間登録を解除する場合もあり得る。そこで、プレイヤが仲間登録を解除する場合でも、メッセージを所定回数送信したにも関わらずアクセス頻度が低いままの仲間プレイヤを仲間から外す場合と、そのようなメッセージの送信もなく仲間登録を解除する場合とでは、その効果を異ならせることが望ましい。
【０３２３】
そこで、本実施の形態に係るゲームサーバ１の特典付与調整手段１２１は、仲間登録の解除をしたプレイヤが、当該仲間登録の解除前の所定期間中（例えば、解除前の２週間以内）に、解除対象の仲間プレイヤ宛に所定回数以上（例えば２回以上）のメッセージを送信している場合は、前記の特典の付与調整を行わないように構成されている。このように構成された典付与調整手段１２１を備えたゲームサーバ１の処理例を、図３７のフローチャートに示す。
【０３２４】
図３７において、Ｓ３１〜Ｓ３４については、基本的には図１５のフローチャートで説明した処理と同様の処理である。Ｓ３４の後、プレイヤが所定期間内、例えば直近の４週間以内に仲間登録の解除を行っているか否かが判断される（Ｓ１５０）。このＳ１５０の処理は、基本的に図３５のＳ１３０と同様の処理である。ここで、プレイヤが４週間以内に仲間登録の解除を行っていない場合（Ｓ１５０でＮＯ）、Ｓ３４で算出された割合Ｒが例えば０．８以上という応援アクセス条件を満たしているか否かが判定されることになる（Ｓ３５）。
【０３２５】
一方、プレイヤが４週間以内に仲間登録の解除を行っている場合（Ｓ１５０でＹＥＳ）、特典付与調整手段１２１は、仲間登録の解除をしたプレイヤが、例えばその解除前の２週間以内に２回以上、解除対象の仲間プレイヤ宛にメッセージを送信しているか否かを判断する（Ｓ１５１）。
【０３２６】
前記Ｓ１５１における判断には、仲間管理手段５３の仲間情報記憶部５３ａが記憶している、例えば図３４（ａ）に示す各プレイヤの仲間登録解除情報（各プレイヤのプレイヤＩＤと対応付けて記憶されている、解除相手プレイヤＩＤ、解除日及び解除者フラグ）、およびメッセージ伝達手段５９のメッセージ記憶部５９ａが記憶している、例えば図１２に示すメッセージに関する情報（受信側プレイヤのプレイヤＩＤと対応付けて記憶されている、送信元のプレイヤＩＤおよび送信日時などの情報）が用いられる。すなわち、プレイヤが仲間登録を解除した「解除対象の仲間プレイヤ」については、図３４（ａ）に示す仲間登録解除情報の中の「解除相手プレイヤＩＤ」として特定できる。また、「解除前の２週間以内の期間」については、前記の仲間登録解除情報の中の「解除日」に基づいて特定できる。また、「解除対象の仲間プレイヤ宛に仲間登録を解除した側のプレイヤがメッセージを送信したか否か」については、図１２に示す「受信側プレイヤＩＤ」を解除相手プレイヤＩＤとした場合における、「送信元プレイヤＩＤ」として、仲間登録の解除をした側のプレイヤのプレイヤＩＤが含まれているか否かを確認することにより判断できる。また、前記の「送信元プレイヤＩＤ」とともに「送信日時」の情報も併せて記憶されているので、仲間登録の解除をしたプレイヤから解除対象の仲間プレイヤへのメッセージが、解除前の２週間以内に送信されたものか否かが判断できる。
【０３２７】
このＳ１５１において、仲間登録の解除をしたプレイヤが、その解除前２週間以内に２回以上、解除対象の仲間プレイヤ宛にメッセージを送信していなかった場合（Ｓ１５１でＮＯ）、前記Ｓ３５より厳しい応援アクセス条件となるように、Ｓ３４で算出された割合Ｒが例えば０．９以上であるか否かが判定される（Ｓ１３１）。すなわち、特典付与調整手段１２１は、応援アクセス条件の閾値を、Ｓ３５における閾値（０．８）よりも高い値（０．９）に設定することによって、仲間登録を解除したプレイヤであって、その解除前２週間以内に２回以上、解除対象の仲間プレイヤ宛にメッセージを送信していないプレイヤに対して、応援アクセス条件を厳しくして連続アクセス達成特典を発生し難くしている。
【０３２８】
一方、仲間登録の解除をしたプレイヤが、その解除前２週間以内に２回以上、解除対象の仲間プレイヤ宛にメッセージを送信していた場合（Ｓ１５１でＹＥＳ）、前記Ｓ１３１に移行することなく、前記Ｓ３５に移行する。すなわち、応援アクセス条件の閾値として０．８が使用され、特典の付与調整がされることはない。なお、以降の処理（Ｓ３６〜Ｓ４０）は、基本的には図１５のフローチャートで説明した処理と同様の処理であり、その説明を省略する。
【０３２９】
この図３７に示した処理により、仲間登録の解除をしたプレイヤは、原則、仲間登録の解除から４週間、仲間登録の解除がない場合に比べて、応援アクセス条件が厳しくなって連続アクセス達成特典が付与され難くなるが、例外として仲間登録の解除前２週間以内に２回以上、解除対象の仲間プレイヤへメッセージを送信している場合は、応援アクセス条件が厳しくなることはない。これにより、仲間登録を解除したプレイヤに対して、その解除前に応援メッセージを送って仲間のアクセスを高める努力をしたプレイヤが、特典の付与調整（連続アクセス達成特典を付与され難くする又は当該特典を小さくする処理）の対象となることを回避できる。よって、応援メッセージを仲間に送信して仲間のアクセスを高めようとすることもなく、欠落日の埋め合わせの可能性を高めるためにアクセス頻度の低い仲間プレイヤの仲間登録を解除するプレイヤのみを対象とした効果的な対策を講じることができ、そのような本来の目的とはかけ離れた行動をプレイヤがとることをより効果的に抑制できる。
【０３３０】
なお、図３７に示した例では、仲間登録の解除をしたプレイヤが、その解除前２週間以内に２回以上、解除対象の仲間プレイヤ宛にメッセージを送信していることを、特典の付与調整が行われない条件としているが、これに限定されるものではない。例えば、仲間登録解除前のメッセージの送信条件（特典の付与調整が行われないための条件）を、解除前１週間以内に１回以上に設定したり、あるいは解除前１か月以内に３回以上に設定したりしてもよく、仲間登録解除前の期間および当該期間中のメッセージ送信回数の条件については、任意に設定することができる。
【０３３１】
〔他の実施の形態〕
上述の実施の形態では、ゲーム実行プログラムがゲームサーバ１側に実装されており、各プレイヤの端末装置３における入力操作に応じて、ゲームサーバ１がゲーム進行のための演算処理やデータ処理を実行し、その実行結果を反映させた画面データを端末装置３へ送信することによって、ゲームが進行するゲームシステムへの適用例について説明したが、これに限定されるものではない。例えば、ゲームサーバ１が、プレイヤのアクセス情報、仲間情報、メッセージ情報、特典情報などのゲーム情報を管理し、ゲーム内でのプレイヤ間のメッセージのやり取りや特典付与等のゲームサービスをプレイヤに提供する一方、ゲームを進行させるゲーム実行処理については、基本的にはプレイヤの端末装置側にて行われるゲームシステムにも本発明を適用できる。
【０３３２】
すなわち、ゲーム実行プログラムの一部または全部をプレイヤの端末装置側にダウンロードまたはインストールし、端末装置においてもゲーム実行処理が行われるようなゲームシステムにも本発明を適用できる。よって、プレイヤの端末装置としては、ネットワーク経由でゲームサーバ（ゲーム管理装置）に接続してゲームサービスの提供を受けることができる様々なものが適用でき、前述の携帯電話端末、ＰＨＳ端末、携帯情報端末（ＰＤＡ）、スマートフォン、パーソナルコンピュータ、タブレット型コンピュータ以外にも、ネットワーク接続機能を有している家庭用ビデオゲーム装置（家庭用ビデオゲーム機を家庭用テレビジョンに接続することによって構成されるゲーム装置）や、携帯型のゲーム専用装置なども適用可能である。
【０３３３】
また、本実施の形態に係るコンピュータ読み取り可能なプログラムは、ハードディスク、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等）、フレキシブルディスク、半導体メモリ等のコンピュータ読み取り可能な各種記録媒体に記録され、当該記録媒体から読み出されてゲームサーバ１のＣＰＵ１１により実行される。また、プログラムをゲームサーバ１に提供する手段は、前述した記録媒体に限定されるものではなく、インターネット等の通信ネットワークを介して行うこともできる。
【符号の説明】
【０３３４】
１ ゲームサーバ（ゲーム管理装置）
２ データベースサーバ（ゲーム管理装置）
３ 端末装置
４ ネットワーク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 補助記憶装置
１５ 通信制御部
５１ ゲーム情報管理手段
５１ｉ 特典情報記憶部
５２ ゲーム進行手段
５３ 仲間管理手段
５５ アクセス管理手段
５６ 仲間応援アクセス判定手段
５７ 連続アクセス特典付与手段
５８ 報知手段
５９ メッセージ伝達手段
６０ アクセス平均算出手段
６１ 仲間アクセス平均算出手段（評価値算出手段）
６２ 予定日伝達手段（アクセス不可能予定日伝達手段）
６３ 応援アクセス特典付与手段
６４ 仲間特典付与手段
１００ アクセス頻度表示制御手段（表示制御手段）
１２１ 特典付与調整手段
１５６ 仲間応援アクセス判定手段

【特許請求の範囲】
【請求項１】
ゲームサービスを受ける各プレイヤの端末装置からのネットワークを介したアクセスを受け付けて各プレイヤのゲーム情報を管理し、各プレイヤに前記ネットワークを介した前記ゲームサービスを提供するゲーム管理装置であって、
各プレイヤの前記アクセスの情報を記憶装置に記憶して、プレイヤ毎の前記アクセスを管理するアクセス管理手段と、
連続した規定期間数の単位期間の全てについて前記アクセスを行った連続アクセス達成のプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する連続アクセス特典付与手段と、
各プレイヤを中心とするグループに所属する仲間プレイヤの情報を記憶装置に保存してプレイヤ毎の仲間管理を行う仲間管理手段と、
連続した規定期間数の前記単位期間のうちアクセスを行わなかった欠落単位期間が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する仲間応援アクセス判定手段と、を備え、
前記連続アクセス特典付与手段は、連続した規定期間数の前記単位期間のうち前記欠落単位期間が存在するプレイヤであっても、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしていると前記仲間応援アクセス判定手段が判定した場合は、当該プレイヤに前記連続アクセス達成特典を付与するゲーム管理装置。
【請求項２】
前記応援アクセス条件は、前記欠落単位期間と同一の単位期間内に前記アクセスを行った前記仲間プレイヤの人数または当該仲間プレイヤ全体に占める割合が、閾値を超えることである請求項１に記載のゲーム管理装置。
【請求項３】
前記欠落単位期間が存在するプレイヤにおける前記仲間プレイヤの前記アクセスの頻度に基づいて、当該プレイヤを中心とするグループの評価値を算出する評価値算出手段をさらに備え、
前記応援アクセス条件は、前記評価値算出手段により算出された前記評価値が閾値を超えることである請求項１に記載のゲーム管理装置。
【請求項４】
前記単位期間は現実世界における１日であり、
前記アクセスができない日程が予め分かっているプレイヤの前記端末装置から送信されたアクセス不可能予定日の情報を受信するとともに、当該アクセス不可能予定日の情報を当該プレイヤの仲間プレイヤ全員の端末装置へ送信し、当該アクセス不可能予定日を当該仲間プレイヤ全員へ伝達するアクセス不可能予定日伝達手段をさらに備えている請求項１ないし３の何れか１項に記載のゲーム管理装置。
【請求項５】
前記仲間応援アクセス判定手段は、プレイヤが前記アクセス不可能予定日伝達手段によって仲間プレイヤへアクセス不可能予定日を事前に伝達した上で当該アクセス不可能予定日と同じ日に前記アクセスを行わなかった場合に限り、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしているか否かを判定する請求項４に記載のゲーム管理装置。
【請求項６】
前記仲間応援アクセス判定手段は、連続した規定期間数の前記単位期間の中に前記欠落単位期間として第１欠落単位期間と当該第１欠落単位期間より後に生じた第２欠落単位期間とが存在する場合、前記第１欠落単位期間より前記第２欠落単位期間の方が前記応援アクセス条件を満たし難い条件に設定する請求項１ないし５の何れか１項に記載のゲーム管理装置。
【請求項７】
前記欠落単位期間の経過後に、前記仲間プレイヤが前記応援アクセス条件を満たしていると前記仲間応援アクセス判定手段に判定されたプレイヤの端末装置に対して、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしたことによって連続アクセスが継続している旨を報知する報知手段をさらに備える請求項１ないし６の何れか１項に記載のゲーム管理装置。
【請求項８】
前記欠落単位期間が存在するプレイヤの仲間プレイヤが前記応援アクセス条件を満たすことによって前記連続アクセス達成特典が付与されたプレイヤの仲間プレイヤであって、当該応援アクセス条件を満たす前記アクセスを行った仲間プレイヤに対して、ゲーム上有利になるように当該仲間プレイヤのゲーム情報を変更して応援アクセス特典を付与する応援アクセス特典付与手段をさらに備える請求項１ないし７の何れか１項に記載のゲーム管理装置。
【請求項９】
プレイヤを中心とするグループの中に前記連続アクセス達成特典が付与された仲間プレイヤが所定の人数以上または所定の割合以上いる当該プレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して仲間特典を付与する仲間特典付与手段をさらに備える請求項１ないし８の何れか１項に記載のゲーム管理装置。
【請求項１０】
ゲームサービスを受ける各プレイヤの端末装置からのネットワークを介したアクセスを受け付けて各プレイヤのゲーム情報を管理し、各プレイヤに前記ネットワークを介した前記ゲームサービスを提供するゲーム管理装置におけるゲーム管理方法であって、
前記ゲーム管理装置が、各プレイヤの前記アクセスの情報を記憶装置に記憶して、プレイヤ毎の前記アクセスを管理するアクセス管理ステップと、
前記ゲーム管理装置が、連続した規定期間数の単位期間の全てについて前記アクセスを行った連続アクセス達成のプレイヤに対して、ゲーム上有利になるように当該プレイヤのゲーム情報を変更して連続アクセス達成特典を付与する連続アクセス特典付与ステップと、
前記ゲーム管理装置が、各プレイヤを中心とするグループに所属する仲間プレイヤの情報を記憶装置に保存してプレイヤ毎の仲間管理を行う仲間管理ステップと、
前記ゲーム管理装置が、連続した規定期間数の前記単位期間のうちアクセスを行わなかった欠落単位期間が存在するプレイヤについて、当該プレイヤの仲間プレイヤが所定の応援アクセス条件を満たしているか否かを判定する仲間応援アクセス判定ステップと、を備え、
前記連続アクセス特典付与ステップは、連続した規定期間数の前記単位期間のうち前記欠落単位期間が存在するプレイヤであっても、当該プレイヤの仲間プレイヤが前記応援アクセス条件を満たしていると前記仲間応援アクセス判定ステップが判定した場合は、当該プレイヤに前記連続アクセス達成特典を付与するゲーム管理方法。
【請求項１１】
コンピュータを請求項１ないし９の何れか１項に記載のゲーム管理装置として動作させるためのプログラムであって、前記コンピュータを前記ゲーム管理装置が備えている各手段として機能させるためのプログラム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【公開番号】特開２０１３−５１９９４（Ｐ２０１３−５１９９４Ａ）
【公開日】平成２５年３月２１日（２０１３．３．２１）
【国際特許分類】
【出願番号】特願２０１１−１９０１６４（Ｐ２０１１−１９０１６４）
【出願日】平成２３年８月３１日（２０１１．８．３１）
【特許番号】特許第５０８０６７３号（Ｐ５０８０６７３）
【特許公報発行日】平成２４年１１月２１日（２０１２．１１．２１）
【出願人】（５０６１１３６０２）株式会社コナミデジタルエンタテインメント (1,441)
【Ｆターム（参考）】