(57)【特許請求の範囲】
【請求項１】
ユーザ同士を関係付ける関係付け手段と、
ユーザの通信端末の位置を示す位置情報を取得する取得手段と、
前記通信端末が、イベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別する判別手段と、
第１のユーザの通信端末が第１のイベント期間内に第１の所定領域に存在すると判別された後の所定の時刻から所定期間、前記第１のユーザに対してゲーム上の特典を付与する付与手段と、を備え、
前記付与手段は、前記第１のユーザと関係付けられた第２のユーザの通信端末が、第２のイベントが行われる第２のイベント期間内に前記第２のイベントが行われる第２の所定領域に存在すると判別された場合に、前記所定期間を延長する、
ゲーム制御装置。
【請求項２】
前記第１のユーザの通信端末及び前記第２のユーザの通信端末において実行されるゲームが同じゲームであることを特徴とする、
請求項１に記載されたゲーム制御装置。
【請求項３】
前記付与手段は、前記所定期間の延長回数を所定回数に制限することを特徴とする、
請求項１または２に記載されたゲーム制御装置。
【請求項４】
前記付与手段は、前記第２のユーザが複数存在する場合に、同一の第２のユーザに基づく前記所定期間の延長回数を所定回数に制限することを特徴とする、
請求項３に記載されたゲーム制御装置。
【請求項５】
前記付与手段は、前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在せず、且つ、前記第２のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された場合に、前記第１のユーザに対してゲーム上の特典を付与することを特徴とする、
請求項１〜４のいずれかに記載されたゲーム制御装置。
【請求項６】
前記付与手段は、前記第１のユーザと前記第２のユーザとの前記ゲーム上の関係度合を示す親密度が所定レベル以上の場合に、前記第１のユーザに対して前記特典を付与することを特徴とする、
請求項５に記載されたゲーム制御装置。
【請求項７】
ユーザに付与するオブジェクトを抽選により決定する抽選手段を備え、
前記ゲーム上の特典は、前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された後の所定の時刻から前記所定期間、前記第１の所定領域に存在すると判別されなかった場合よりも、前記第１のユーザに対して希少価値の高いオブジェクトを付与する確率を高くすることである、請求項１〜６のいずれか一項に記載のゲーム制御装置。
【請求項８】
通信端末からアクセスされるサーバが、
ユーザ同士を関係付けるステップと、
ユーザの通信端末の位置を示す位置情報を取得するステップと、
前記通信端末が、イベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別するステップと、
第１のユーザの通信端末が第１のイベント期間内に第１の所定領域に存在すると判別された後の所定の時刻から所定期間、前記第１のユーザに対してゲーム上の特典を付与するステップと、
の各ステップを実行するゲーム制御方法であって、
前記付与するステップは、前記第１のユーザと関係付けられた第２のユーザの通信端末が、第２のイベントが行われる第２のイベント期間内に前記第２のイベントが行われる第２の所定領域に存在すると判別された場合に、前記所定期間を延長する、
ゲーム制御方法。
【請求項９】
ゲームの実行を制御するために、コンピュータに、
ユーザ同士を関係付ける機能、
ユーザの通信端末の位置を示す位置情報を取得する機能、
前記ユーザの通信端末が、イベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別する機能、及び
第１のユーザの通信端末が第１のイベント期間内に第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、前記第１のユーザに対してゲーム上の特典を付与する機能、を実現させるためのプログラムであって、
前記付与する機能は、前記第１のユーザと関係付けられた第２のユーザの通信端末が、第２のイベントが行われる第２のイベント期間内に前記第２のイベントが行われる第２の所定領域に存在すると判別された場合に、前記所定期間を延長する、
プログラム。
【請求項１０】
通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
ユーザ同士を関係付ける関係付け手段、
ユーザの通信端末の位置を示す位置情報を取得する取得手段、
前記ユーザの通信端末が、イベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別する判別手段、
第１のユーザの通信端末が第１のイベント期間内に第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、前記第１のユーザに対してゲーム上の特典を付与する付与手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備え、
前記付与手段は、前記第１のユーザと関係付けられた第２のユーザの通信端末が、第２のイベントが行われる第２のイベント期間内に前記第２のイベントが行われる第２の所定領域に存在すると判別された場合に、前記所定期間を延長する、
ゲームシステム。 
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザによるゲームの実行を制御する技術に関する。
【背景技術】
【０００２】
近年、特定のサービス提供者によるソーシャルネットワーキングサービス（ＳＮＳ）においてウェブブラウザ上で動作するＡＰＩ(Application Programming Interface)などの動作環境を基に作成されるゲーム用アプリケーションによって実行される、いわゆるソーシャルゲーム（Social Game）が普及している。ソーシャルゲームは、不特定多数のユーザ間でコミュニケーションをとりながらプレイするオンラインゲームの一種であると言える。ユーザは、インターネットに接続可能であり、かつウェブブラウザが搭載された通信端末を備えていれば、時間と場所を問わずソーシャルゲームを楽しむことができる。
【０００３】
上述したソーシャルゲームの一例として、非特許文献１に開示されているデジタルカードゲーム（ドラゴンコレクション（登録商標））が知られている。この公知のデジタルカードゲームは、ユーザが様々なエリアを探索して新たなカードやアイテムを取得するクエスト処理を行うメニューが設けられている。このようなソーシャルゲームは、従来のオンラインゲームよりも、ユーザ間の交流を図るためのコミュニケーション機能が充実している点が特徴の１つとなっている。ソーシャルゲームでは、例えば、他のユーザ（仲間）との協力プレイのほか、仲間との挨拶や連絡など仲間とコミュニケーションを取ることによる情報交換、仲間との間のゲーム上のアイテムのプレゼントあるいはアイテムの交換が行なわれている。
【０００４】
また、ＧＰＳ(Global Positioning System)機能を搭載した通信端末を用いて、通信端末の位置情報を利用するゲームが知られている。例えば、特許文献１には、ユーザが、ＧＰＳ機能を搭載した通信端末を携帯しながら現実世界の所定領域を移動することにより、ゲーム上のアイテムを獲得できるように構成されたゲームが開示されている。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】アプリＳＴＹＬＥ  Vol.2（株式会社イースト・プレス）、26-27頁
【特許文献】
【０００６】
【特許文献１】特開２００２−２７３０３４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１に記載のゲームは、ユーザがＧＰＳ機能を搭載した携帯端末を持って、現実世界の所定領域を移動することで仮想アイテムを獲得できるものである。しかしながら、これはユーザ一人が単独で行うものであり、単にアイテムを獲得したか否かを認識できるに留まり、ゲーム性の展開に乏しいものとなっている。
【０００８】
本発明は上述した観点に鑑みてなされたもので、通信端末の位置情報を利用する場合に、興趣性の高いゲームを実現することができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の観点は、ゲーム制御装置である。
当該ゲーム制御装置は、
ユーザの通信端末の位置を示す位置情報を取得する取得手段と、
第１のユーザの通信端末が、第１のイベントが行われる第１のイベント期間内に前記第１のイベントが行われる第１の所定領域に存在するか否かを、前記位置情報に基づいて判別する判別手段と、
前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、前記第１のユーザに対してゲーム上の特典を付与する付与手段と、
を備える。
【００１０】
ここで、「イベント」とは、例えば、ゲームにおいて模擬された現実世界のイベントであってもよく、具体的には、野球ゲームの場合には野球の試合であってよいし、サッカーゲームの場合にはサッカーの試合であってよいし、音楽ゲームの場合には音楽の演奏会であってよい。また、「所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。
また、「特典」とは、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。さらに、「アイテム」とは、例えば、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。また、「アイテム」とは、通信端末が第１の所定領域に存在する場合にのみ与えられる特殊なアイテムであってもよい。さらに、「ゲーム上の有利な効果」とは、例えば、ユーザがゲーム上保有するアイテムのパラメータを上昇させたり、キャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、「ゲーム上の有利な効果」とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作などに応じて消費するゲーム上のポイントの消費量を通常よりも低減させることであってもよいし、ポイントを入手できることであってもよい。なお、仲間を作ることでポイントを入手できる構成が既に設けられている場合には、そのポイントよりも多くのポイントを入手できるようにすればよい。さらにまた、「ゲーム上の有利な効果」とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、アイテムのパラメータが大幅に上昇する確率を上昇させることであってもよい。
また、「所定の時刻」は、通信端末がイベント期間内に所定領域に存在すると判別された直後の時刻であってもよいし、イベント期間の終了時刻、さらにはイベント期間が終了した後の所定時刻であってもよい。
【００１１】
このゲーム制御装置では、第１のユーザは、自身の通信端末が第１のイベント期間内に第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、特典を得ることができる。この場合、ユーザは、特典を得るために、現実に第１のイベントが行われている第１の所定領域に積極的に出向き、第１のイベントに対して参加または観戦などすることが動機付けられる。そして、このように、第１のイベントが行われている第１の所定領域に出向くことにより、第１のユーザは、第１のイベントとゲームが連動しているような感覚を得ることができる。これにより、通信端末の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。また、例えば、スタジアムやイベント会場等の運営側にとっては、ユーザを来場させる誘因力あるシステムを構築することができる。
【００１２】
上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記付与手段は、前記第１のユーザと関係付けられた第２のユーザの通信端末が、第２のイベントが行われる第２のイベント期間内に前記第２のイベントが行われる第２の所定領域に存在すると判別された場合に、前記所定期間を延長してもよい。
ここで、「第２のイベント」は、「第１のイベント」と同じ種類のイベントであってもよいし、異なる種類のイベントであってもよい。例えば、第１のイベントが野球の試合の場合には、第２のイベントは、野球の試合であってもよいし、サッカーの試合であってもよいし、音楽の演奏会などであってもよい。また、「第２のイベント」の「第２のイベント期間」及び「第２の所定領域」は、「第１のイベント」の「第１のイベント期間」及び「第１の所定領域」と同一であってもよいし、異なっていてもよい。例えば、第１のイベント及び第２のイベントは、同じ日時に同じスタジアムで行われる野球の試合であってもよいし、同じ日時に異なるスタジアムで行われる野球の試合であってもよいし、異なる日時に同じスタジアムで行われる野球の試合であってもよいし、異なる日時に異なるスタジアムで行われる野球の試合であってもよい。なお、ここで、同じ種類のイベントとしては、広く野球観戦としてもよいし、自分が観戦したチーム同士の対戦、あるいは自分が観戦した対戦のいずれか一方のチームの対戦に限定してもよい。
なお、「第１のイベント」と「第２のイベント」が同じ種類のイベントであることを所定期間延長の条件としてもよい。この場合、ユーザにとって、自分が野球観戦をし、後日、自分の仲間が野球観戦に行けば、特典付与の期間が延長する、というように、特典入手の構成を把握し易くなるため有用である。
また、「第１の所定領域」と「第２の所定領域」が同一であることを所定期間延長の条件としてもよい。この場合、位置情報の取得範囲を絞ることができるため、ゲーム制御装置のシステムを簡易なものとすることができる。また、例えば野球観戦したスタジアムと同じスタジアムに、自分の仲間が後日行けば、特典付与の期間が延長する、というように、特典入手の構成を把握し易くなるため有用である。
また、「第１のイベント期間」と「第２のイベント期間」が異なる場合、その前後関係は問わないが、第２のイベント期間の方が第１のイベント期間より時間的に後であれば、ユーザにとって以下のような利点が生じる。すなわち、ユーザは、例えば野球観戦（第１のイベント）に行った後に、自分の仲間に対して野球観戦（第２のイベント）に行くよう依頼したり、促すといった行動をとることで、所定期間延長への働きかけを行うことができる。
なお、「第１のイベント期間」と「第２のイベント期間」の間は、第１のユーザに対してゲーム上の特典を付与する所定期間よりも短い期間であることが好ましい。例えば、第１のユーザに対してゲーム上の特典を付与する所定期間が２週間であり、「第１のイベント期間」と「第２のイベント期間」の間は２週間未満である場合、所定期間と「第２のイベント期間」が重なるため、第２のイベント期間内に所定期間が延長されるように第２のユーザがイベントに行くことを第１のユーザに促すことができる。
また、「第２のイベント」は、複数存在してもよい。さらに、第１のユーザの通信端末及び第２のユーザの通信端末において実行されるゲームは、同じゲームであってもよいし、異なるゲームであってもよい。
このゲーム制御装置では、第１のユーザと関係付けられた第２のユーザ（仲間のユーザ）の通信端末が、第２のイベント期間内に第２の所定領域に存在すると判別された場合に、第１のユーザは、特典が付与される期間が延長されるというメリットを得ることができる。この場合、第１のユーザは、このメリットを得るために、他のユーザと関係付けられる（仲間になる）こと、及び仲間のユーザに対して第２のイベント期間内に第２の所定領域に出向くことを誘導することが動機付けられる。これにより、仲間関係の構築及び仲間同士の交流が活性化されるため、ゲームのソーシャル性を向上させることができる。
【００１３】
上記ゲーム制御装置において、前記第１のユーザの通信端末及び前記第２のユーザの通信端末において実行されるゲームが同じゲームであってもよい。
このゲーム制御装置では、第１のユーザの通信端末及び第２のユーザの通信端末において実行されるゲームが同じゲームである場合に、ユーザは、特典が付与される期間が延長されるというメリットを得ることができる。これにより、ユーザは、このメリットを得るために、他のユーザと同じゲーム上で関係付けられる（仲間になる）ことが動機付けられる。しかも、この場合、ユーザ及び他のユーザは、同じゲームをプレイしていることにより互いに共感し、仲間として協力してゲームをプレイすることが動機付けられることから、仲間関係の構築をさらに活性化することができる。
【００１４】
上記ゲーム制御装置において、前記付与手段は、前記所定期間の延長回数を所定回数に制限してもよい。
例えば、第２のユーザの通信端末の位置についての判別が１回行われる毎に所定期間が延長される場合、第２のユーザの通信端末の位置についての判別が繰り返し行われることにより、所定期間が無制限に延長されることが考えられる。この場合、第１のユーザに対して特典を付与する状況が常に設定されることになる。これにより、第１のユーザが他のユーザと比べて突出して有利になることから、他のユーザとの間で公平性を損なうおそれがある。
このゲーム制御装置によれば、所定期間の延長回数が所定回数に制限されるため、第１のユーザに対して特典を付与する状況が常に設定されることを抑制することができる。このため、所定期間が延長されることに起因してユーザ間で公平性を損なうことのない仕組みとすることができる。
【００１５】
上記ゲーム制御装置において、前記付与手段は、前記第２のユーザが複数存在する場合に、同一の第２のユーザに基づく前記所定期間の延長回数を所定回数に制限してもよい。
例えば、同一の第２のユーザ（仲間のユーザ）に基づく所定期間の延長回数を制限しない場合、第１のユーザは、特典が付与される所定期間をより長くするために、同一の仲間のユーザ（例えば、非常に仲の良い仲間のユーザ）に対して第２のイベント期間内に第２の所定領域に出向くことを誘導することが考えられる。このとき、第１のユーザにとっては、当該仲間のユーザとの交流を活性化することができる一方で、他の仲間のユーザとの交流が疎かになる場合があることから、ユーザ間の幅広い交流を促進する仕組みとならないおそれがある。
このゲーム制御装置によれば、第１のユーザは、特典が付与される所定期間をより長くするために、より多くの仲間のユーザに対して、第２のイベント期間内に第２の所定領域に出向くことを誘導することが動機付けられる。このため、第１のユーザと、多くの仲間のユーザとの交流を活性化させることができることから、ユーザ間の幅広い交流を促進する仕組みとすることができる。
【００１６】
上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記付与手段は、前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在せず、且つ、前記第１のユーザと関係付けられた第２のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された場合に、前記第１のユーザに対してゲーム上の特典を付与してもよい。
このゲーム制御装置によれば、例えば、第１のユーザの通信端末が第１のイベント期間内に第１の所定領域に存在しない場合であっても、第１のユーザと関係付けられた第２のユーザ（仲間のユーザ）の通信端末が第１のイベント期間内に第１の所定領域に存在すれば、第１のユーザは、特典を得ることができる。この場合、第１のユーザには、特典を得る可能性を高めるために、他のユーザと関係付けられる（仲間になる）ことが動機付けられる。これにより、仲間関係の構築が活性化されるため、ゲームのソーシャル性を向上させることができる。
【００１７】
上記ゲーム制御装置において、前記付与手段は、前記第１のユーザと前記第２のユーザとの前記ゲーム上の関係度合を示す親密度が所定レベル以上の場合に、前記第１のユーザに対して前記特典を付与してもよい。
このゲーム制御装置によれば、例えば、第１のユーザの通信端末が第１のイベント期間内に第１の所定領域に存在しない場合であっても、第１のユーザと親密度の高い第２のユーザ（仲間のユーザ）の通信端末が第１のイベント期間内に第１の所定領域に存在すれば、第１のユーザは、特典を得ることができる。この場合、第１のユーザには、特典を得るために、仲間のユーザとの親密度を高めることが動機付けられる。これにより、仲間関係にあるユーザ間の関係性を高めることができる仕組みとすることができ、ゲームのソーシャル性のさらなる向上が期待できる。
上記ゲーム制御装置において、ユーザに付与するオブジェクトを抽選により決定する抽選手段を備え、
前記ゲーム上の特典は、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された後の所定の時刻から第１の所定期間、前記所定領域に存在すると判別されなかった場合よりも、ユーザに対して希少価値の高いオブジェクトを付与する確率を高くすることであってもよい。
本発明において「オブジェクト」とは、例えば、ゲーム上のキャラクタやアイテム等を含む。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。
このゲーム制御装置によれば、ユーザは、希少価値の高いオブジェクトを得るために、イベントが行われている所定領域に積極的に出向くことが動機付けられる。
【００１８】
本発明の第２の観点は、ゲーム制御方法であって、
ユーザの通信端末の位置を示す位置情報を取得するステップと、
第１のユーザの通信端末が、第１のイベントが行われる第１のイベント期間内に前記第１のイベントが行われる第１の所定領域に存在するか否かを、前記位置情報に基づいて判別するステップと、
前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、前記第１のユーザに対してゲーム上の特典を付与するステップと、
を備える。
【００１９】
本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、
ユーザの通信端末の位置を示す位置情報を取得する機能、
第１のユーザの通信端末が、第１のイベントが行われる第１のイベント期間内に前記第１のイベントが行われる第１の所定領域に存在するか否かを、前記位置情報に基づいて判別する機能、及び
前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、前記第１のユーザに対してゲーム上の特典を付与する機能、
を実現させるためのプログラムである。
【００２０】
コンピュータは、例えばネットワークサーバ、大型計算機等であってよい。また、このプログラムは、ＤＶＤ−ＲＯＭやＣＤ−ＲＯＭ等のコンピュータが読み取り可能な情報記憶媒体に格納されてもよい。
【００２１】
本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
ユーザの通信端末の位置を示す位置情報を取得する取得手段、
第１のユーザの通信端末が、第１のイベントが行われる第１のイベント期間内に前記第１のイベントが行われる第１の所定領域に存在するか否かを、前記位置情報に基づいて判別する判別手段、
前記第１のユーザの通信端末が前記第１のイベント期間内に前記第１の所定領域に存在すると判別された後の所定の時刻から所定期間の間、前記第１のユーザに対してゲーム上の特典を付与する付与手段、
の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。
【００２２】
通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機、通信機能付きゲーム装置等であってよい。
【発明の効果】
【００２３】
本発明のゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムによれば、通信端末の位置情報を利用する場合に、興趣性の高いゲームを実現することができる。
【図面の簡単な説明】
【００２４】
【図１】実施形態のゲームシステムの基本構成を示す図。
【図２Ａ】実施形態の通信端末の外観の例を示す図。
【図２Ｂ】実施形態の通信端末の外観の別の例を示す図。
【図３】実施形態の通信端末の構成を示すブロック図。
【図４】実施形態のゲームサーバの構成を示すブロック図。
【図５】実施形態のデータベースサーバの構成を示すブロック図。
【図６】データベースサーバに含まれるユーザデータベースの構成例を示す図。
【図７】実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図。
【図８】トップページを表示する通信端末の表示画面の一例を示す図。
【図９】ユーザがスカウトメニューを選択したときのウェブページの一例を示す図。
【図１０Ａ】ユーザが強化メニューを選択したときのウェブページの一例を示す図。
【図１０Ｂ】ユーザが強化メニューを選択したときのウェブページの一例を示す図。
【図１１】ユーザが試合メニューを選択したときのウェブページの一例を示す図。
【図１２】現在位置データの構成例を示す図。
【図１３】特典付与データの構成例を示す図。
【図１４】特典が付与されたときのウェブページの一例を示す図。
【図１５】実施形態のゲーム制御装置の主要な処理の一例を示すフローチャート。
【図１６】変形例におけるゲームシステムの構成例を示す図。
【図１７】変形例におけるゲーム制御装置の主要な処理の一例を示すシーケンスチャート。
【図１８】変形例における特典付与データの構成例を示す図。
【図１９】変形例における特典付与データの構成例を示す図。
【図２０】親密度データの構成例を示す図。
【図２１Ａ】通信端末及びゲームサーバの各々における各機能の構成例を示す図。
【図２１Ｂ】通信端末及びゲームサーバの各々における各機能の構成例を示す図。
【発明を実施するための形態】
【００２５】
以下、本発明の実施形態について説明する。
【００２６】
（１）ゲームシステムの構成
図１は、実施形態のゲームシステムのシステム構成例を示している。図１に示すように、このゲームシステムは、例えばインターネットなどの通信網ＮＷ（ネットワーク）に接続可能な通信端末１０ａ，１０ｂ，１０ｃ，…と、通信網ＮＷに接続されているゲームサーバ２０と、データベースサーバ３０とによって構成されている。各通信端末１０ａ，１０ｂ，１０ｃ，…はそれぞれ、個々のユーザによって操作される端末であり、例えば、携帯端末、スマートフォン、ＰＤＡ(Personal Digital Assistant)、パーソナルコンピュータ、双方向の通信機能を備えたテレビジョン受像機（いわゆる多機能型のスマートテレビも含む。）などの通信端末である。なお、以下の説明において、各通信端末１０ａ，１０ｂ，１０ｃ，…に共通して言及するときには、通信端末１０と表記する。
このゲームシステムにおいて、ゲームサーバ２０は、クライアントである通信端末１０と通信可能に構成されており、通信端末１０に対してゲーミングサービスを提供する。ゲームサーバ２０には、ゲーム用アプリケーションとしてウェブブラウザ上で動作可能なアプリケーションが実装されている。データベースサーバ３０は、ゲームを実行する上での後述する様々な情報を格納しており、それらの情報の読み書きのためにゲームサーバ２０と例えば有線で接続される。
通信端末１０は、ゲームサーバ２０によって提供されるウェブページを表示可能なウェブブラウザを備えており、ユーザは、通信端末１０をウェブページ上で操作してゲームを実行する。
【００２７】
また、図１には図示していないが、ゲームサーバ２０とは別に各通信端末１０のユーザを認証するための認証サーバを設けてもよい。また、多くの通信端末１０からのアクセスを受け入れるために複数のゲームサーバ２０を設ける場合は、その複数のゲームサーバ２０間の負荷を調整するためのロードバランサを設けてもよい。また、ゲームサーバ２０は単一のサーバ装置として構成してもよいが、機能を分散させた複数のサーバ装置として構成してもよい。
【００２８】
（２）通信端末の構成
図２Ａ、図２Ｂ及び図３を参照して通信端末１０について説明する。
図２Ａ、図２Ｂは、通信端末１０の外観の例を示す図である。図２Ａは、例えば折り畳み式の携帯端末（携帯電話機）などの釦入力方式の通信端末を例示したものであり、図２Ｂは、例えばスマートフォンなどのタッチパネル入力方式の通信端末を例示したものである。図３は、通信端末１０の内部構成を示すブロック図である。
図３に示すように、通信端末１０は、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ(Read Only Memory)１２、ＲＡＭ(Random Access Memory)１３、画像処理部１４、指示入力部１５、表示部１６、通信インタフェース部１７及びＧＰＳ(Global Positioning System)測位部１８を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス１９が設けられている。
【００２９】
ＣＰＵ１１は、ＲＯＭ１２内のウェブブラウザをＲＡＭ１３にロードして実行する。そして、ＣＰＵ１１は、指示入力部１５等によってユーザに入力されるＵＲＬ(Uniform Resource Locator)の適切な指定に基づき、通信インタフェース部１７を介して、ゲームサーバ２０からウェブページを表示するためのデータ、すなわち、ＨＴＭＬ(HyperText Markup Language)文書や当該文書と関連付けられた画像などのオブジェクトのデータ（以下、総称して適宜「ＨＴＭＬデータ」と表記する。）を、通信インタフェース部１７を介して取得し、そのＨＴＭＬデータを解釈する。なお、通信端末１０には、ウェブブラウザのブラウザ機能を拡張するための様々なプラグインが実装されていてよい。
なお、ＨＴＭＬデータの取得に当たって、ＣＰＵ１１は、予め登録されたユーザＩＤ（ユーザ識別情報）、あるいは指示入力部１５を介して入力されるユーザＩＤを含むアクセス要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０へ通知する。
【００３０】
ウェブブラウザは、画像処理部１４を介して、取得したＨＴＭＬデータに基づき、ゲームサーバ２０から提供されるウェブページを表示部１６に表示する。また、ウェブブラウザは、ユーザが指示入力部１５の操作によってウェブページ上のハイパーリンク(Hyperlink)またはメニューが選択されると、その選択に応じたウェブページを表示するための新たなＨＴＭＬデータの送信（つまり、ウェブページの更新）をゲームサーバ２０へ要求する。
【００３１】
画像処理部１４は、ＨＴＭＬデータの解析結果としてＣＰＵ１１から与えられる表示用画像データに基づいて、表示部１６にウェブページを表示する。表示部１６は、例えば、マトリクス状に画素単位で配置された薄膜トランジスタを含むＬＣＤ(Liquid Cristal Display)モニタであり、表示用画像データに基づいて薄膜トランジスタを駆動することでウェブページの画像を表示画面１６ａに表示する。
【００３２】
通信端末１０が釦入力方式の通信端末（図２Ａに示す）である場合、指示入力部１５は、ユーザの操作入力を受け入れるための方向指示釦と決定釦などの複数の指示入力釦を含む釦群１５ａ、及び、テンキーなどの複数の指示入力釦を含む釦群１５ｂを備え、各釦の押下（操作）入力を認識してＣＰＵ１１へ出力するためのインタフェース回路を含む。例えば、方向指示釦は、表示部１６に表示されているウェブページをスクロールして表示することをＣＰＵ１１へ指示するために設けられる。また、決定釦は、例えばウェブページ上で複数のハイパーリンクまたはメニューが表示されるときに、アクティブ表示（例えば強調表示）されている１つのハイパーリンクまたはメニューをユーザが選択することをＣＰＵ１１へ指示するために設けられる。なお、通信端末１０を小型の携帯端末によって構成する場合には、これらの釦は、ユーザが通信端末１０を片手で保持したままその親指で操作（クリック）しやすいように、通信端末１０の前面に配置されていることが好ましい。図２Ａに示す例では、釦群１５ｂは、釦群１５ａの下方に配置され、「０」〜「９」、「＊」、「＃」（テンキー）が表記された複数の指示入力釦を含む。
【００３３】
通信端末１０がタッチパネル入力方式の通信端末（図２Ｂに示す）である場合、指示入力部１５は、主として表示画面１６ａに指先あるいはペンで触れることによるタッチパネル方式の入力を受け付ける。タッチパネル入力方式は、静電容量方式などの公知の方式でよい。なお、図２Ｂに示すように、通信端末１０がタッチパネル入力方式の場合であっても釦群１５ａが設けられる場合もある。
【００３４】
通信端末１０に表示されるウェブページ上のメニューの選択操作は、例えば通信端末１０が携帯端末である場合には、方向指示釦の押下操作によってメニューを選択し、決定釦の押下操作によって、選択したメニューを確定することによって行われる。また、選択操作は、例えば通信端末１０がタッチパネル入力方式の場合には、ウェブページが表示されている表示画面１６ａ上のメニューの位置を指あるいはペンで指示（タッチ操作）することによって行われる。
【００３５】
ＧＰＳ測位部１８は、ＧＰＳ衛星からの測位用電波信号を受信することにより、通信端末１０の現在位置を測位する。ＣＰＵ１１は、例えば、位置情報の送信要求メッセージをゲームサーバ２０から受信した等の場合に、通信端末１０の現在位置をＧＰＳ測位部１８に測位させ、ＧＰＳ測位部１８の測位によって得られた位置情報（緯度、経度、測位時刻などを含む）をＲＡＭ１３などの記憶装置に記憶する。なお、ＣＰＵ１１は、例えば、ユーザによる所定の操作入力が行われたとき、あるいは所定の周期で、通信端末１０の現在位置をＧＰＳ測位部１８に測位させてもよい。
ＣＰＵ１１は、位置情報の送信要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０から受信すると、記憶装置に記憶された位置情報をユーザＩＤ（あるいは通信端末１０固有の端末識別情報）と対応付けて、通信インタフェース部１７を介してゲームサーバ２０に送信する。
【００３６】
（３）ゲームサーバの構成
図４を参照してゲームサーバ２０の構成について説明する。
ゲームサーバ２０は、例えば階層構造の複数のウェブページからなるゲームのウェブサイトを管理しており、通信端末１０に対してゲームのウェブサービスを提供する。図４に示すように、ゲームサーバ２０は、ＣＰＵ２１、ＲＯＭ２２、ＲＡＭ２３、データベース（ＤＢ）アクセス部２４、及び、通信インタフェース部２５を備えており、各部間の制御信号あるいはデータ信号を伝送するためのバス２６が設けられている。なお、ゲームサーバ２０は、ハードウエアに関しては汎用のウェブサーバと同一の構成をとることができる。
【００３７】
ＲＯＭ２２には、クライアントである通信端末１０のウェブブラウザに対してＨＴＭＬ文書や画像などのオブジェクトの表示（ウェブページの表示）のサービスを提供するアプリケーションプログラムが格納されている。ＲＯＭ２２には、アプリケーションプログラム以外にもＣＰＵ２１によって参照される各種データが格納されている。
ＣＰＵ２１は、ＲＯＭ２２内のゲームプログラムをＲＡＭ２３にロードして実行し、通信インタフェース部２５を介して、各種の処理を行う。
【００３８】
例えば、ＣＰＵ２１は、通信インタフェース部２５を介して、ＨＴＭＬデータを通信端末１０宛に送信する。なお、ゲームサーバ２０が通信端末１０のユーザの認証処理を行う場合には、ＣＰＵ２１はその認証処理を行う。
ＣＰＵ２１は、通信端末１０で表示されるウェブページ上でユーザにより選択されたハイパーリンクまたはメニューに応じた処理を行う。その処理は、例えば、新たなＨＴＭＬデータの送信、または、ゲームサーバ２０内の演算処理あるいはデータ処理などを含む。
データベースアクセス部２４は、ＣＰＵ２１がデータベースサーバ３０に対してデータの読み書きを行うときのインタフェースである。
【００３９】
（４）データベースサーバの構成
データベースサーバ３０は、大容量のハードディスク装置やＲＡＩＤ（Redundant Arrays of Inexpensive Disks）等の形態の装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。
【００４０】
本実施形態のゲームサーバ２０によって実現されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、ゲームサーバ２０によって実現されるゲームの一例として、野球形式のデジタルカードゲームを採り上げる。
野球形式のデジタルカードゲームは、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦を行う、あるいは技能レベルごとの野球のリーグ戦を戦うように構成されているゲームである。野球形式のデジタルカードゲームには、自らのチームを作り上げていくために選手カードを探索するスカウト処理や、抽選によって選手カードを入手することを可能とする抽選処理、あるいは２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理等が設けられている。
野球形式のデジタルカードゲームに実装されている各機能については、後述する。
【００４１】
図６に、上述した野球形式のデジタルカードゲームにおいて適用されるユーザデータベース３１の一例を示す。この例では、ユーザデータベース３１は、ユーザＩＤ（ユーザ識別情報）ごとに、ユーザ名／表示画像、チーム、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間のユーザＩＤ、保有カードの画像データ、及び保有カードのパラメータの各項目についての情報を含む。ユーザデータベース３１に含まれる情報は、ゲームサーバ２０によって逐次更新されうる。なお、ユーザ毎に行動ポイント、運営ポイントの上限値を定めてもよい。
【００４２】
以下の説明では、ユーザデータベース３１に含まれるユーザＩＤ、あるいはユーザを特定するユーザ名（後述する）ごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ゲームの実行時に通信端末１０にユーザを特定するために表示されるユーザ名及び表示画像である。ユーザ名はユーザによって予め指定される所定長以下のテキストであり、表示画像は例えばユーザによって予め選択されるアバタ画像である。ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。
・チーム
上記野球形式のデジタルカードゲームにおいて、ユーザ登録時に、ユーザが指定するチームである。このゲームでは、例えば、Ｐ１〜Ｐ６の６チームからなるＰリーグ、Ｑ１〜Ｑ６の６チームからなるＱリーグが設けられており、ユーザはこの１２チームの中からいずれかのチームをユーザ登録時に選択する。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えばゲームにおけるスカウト処理を継続的に行うことで、順次技能レベルが上がるように構成される。
・行動ポイント
上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上のスカウトを行う上で必要となるポイントである。行動ポイントは、スカウトを行うことで低減し、所定の時間が経過する毎に回復（増加）する値である。
・運営ポイント
上記野球形式のデジタルカードゲームにおいて、例えばユーザによるゲーム上の対戦を行う上で必要となるポイントである。運営ポイントは、他のユーザとの対戦等によって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
上記野球形式のデジタルカードゲームにおいて、例えばユーザによる選手カードの強化を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの対戦で勝利するか、あるいは所定の時間が経過する毎に回復（増加）する値である。
・エールポイント
上記野球形式のデジタルカードゲームにおいて、仲間のユーザへ応援メッセージを送信することでユーザが取得するポイントである。なお、所定の時間が経過する毎にエールポイントを増加させてもよい。
・選手数
ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
対象とするユーザＩＤの仲間である他のユーザＩＤのデータである。
・保有カードの画像データ
上記野球形式のデジタルカードゲームの場合、保有カードの画像データは、ユーザが保有する選手カードについての画像を含むデータである。
・保有カードのパラメータ
保有カードのパラメータには、ユーザが保有する選手カードの能力値を示すデータが含まれる。例えば、図６に示すように、パラメータの項目として「打力」，「走力」，「守備力」等の能力値が含まれてもよい。図６の例では、能力値は０〜１０００の範囲の値であって、能力値が大きい値であるほど能力が高いことを示している。図６では、能力の指標としての項目として、「打力」，「走力」，「守備力」を例示しているが、選手が投手であれば別の項目、例えば「球速」，「制球力」，「スタミナ」等としてもよい。
なお、選手カードのパラメータには、「レア度」が含まれてもよい。ここで、「レア度」とは、選手カードの希少価値の度合を示す値であり、その値が高いほどゲーム内で出現する確率が非常に低く設定されている。なお、本実施形態のゲームでは、レア度を１〜５の５段階で表しており、技術能力の際立った選手や人気のある選手に対応する選手カードのレア度は高く設定されている。
また、選手カードには、チーム（Ｐ１〜Ｐ６、Ｑ１〜Ｑ６のいずれか）、ポジション（投手、捕手、一塁手、左翼手など）、選手カードがゲームに及ぼす影響度（典型的にはポジティブな影響度）等を設定してもよい。
【００４３】
図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されるゲームの設定についての情報や、ゲームの結果（ゲーム結果）に関する情報を記憶、更新する。ゲーム結果に関する情報は、ゲームの性質によって多様な情報を含みうる。野球形式のデジタルカードゲームの場合を例に挙げれば、ゲーム結果に関する情報は、異なるユーザＩＤ同士の対戦の結果（スコア等）、特定の技能レベルの複数のユーザＩＤの間のリーグ戦の結果（スコア、ランキング等）などを含む。
【００４４】
（５）ゲーム制御装置における各機能の概要
本実施形態では、ゲームサーバ２０及びデータベースサーバ３０によってゲーム制御装置が構成されている。以下では、上述した野球形式のデジタルカードゲーム（以下、適宜単に「ゲーム」という。）が適用される場合を例として、本実施形態のゲーム制御装置で実現される機能について、図７を参照して説明する。図７は、本実施形態のゲーム制御装置で主要な役割を果たす機能を説明するための機能ブロック図である。
なお、図７の機能ブロック図において、取得手段５３、判別手段５４及び付与手段５５が本発明の主要な構成に対応している。その他の手段は必ずしも必須の構成ではないが、本発明をさらに好ましくするための構成である。
また、以下の説明において、通信端末１０に表示されるウェブページ上で表示されるメニュー、マーク等はウェブページ上で所望の位置に配置されるものであって、通信端末１０で視認されるメニュー、マーク等の表示画面上の位置は、ユーザの方向指示釦あるいはタッチパネルの操作によるウェブページのスクロール操作によって変化しうる。
【００４５】
登録手段５１は、例えば通信端末１０に提供するウェブページ上での通信端末１０への適切な操作入力に基づいてユーザの要求を認識し、登録処理（ユーザ登録）を行う機能を備える。
なお、登録手段５１は、本発明に必須の構成要素ではないが、本発明をさらに好ましくするための構成要素である。
【００４６】
登録手段５１の機能は、例えば以下のとおり実現される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して通信端末１０から登録要求メッセージを受信する。登録要求メッセージは、ゲームサーバ２０から提供されるウェブページ上での通信端末１０に対する所定の操作（例えば、所定のメニューの選択操作、テキスト入力等）によって自動的に生成されるように、ウェブページが構成されていてもよい。登録要求メッセージには、送信元の通信端末１０を特定するための情報（例えば、端末識別情報、ＩＰアドレス、メールアドレス等）が含まれていてもよく、あるいは、ユーザが既に同一のサービス提供者による他のゲームを利用している場合には、そのユーザＩＤが含まれていてもよい。
ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれていない場合には、ユーザＩＤを新規に発行してそのユーザＩＤの登録処理を行った後、登録処理が完了した旨のメッセージを通信端末１０へ送信する。ＣＰＵ２１は、登録要求メッセージを受信し、登録要求メッセージにユーザＩＤが含まれている場合には、そのユーザＩＤの登録処理を行った後、登録処理が完了したことを示す登録完了メッセージを通信端末１０へ送信する。
登録が完了すると、ＣＰＵ２１は、所定のデフォルトのデータが記述された新規のユーザＩＤについてのユーザデータを、ユーザデータベース３１に格納する。
【００４７】
また、登録手段５１は、ユーザ同士を関係付ける機能を備えてもよい。例えば、登録手段５１は、ユーザＩＤに基づく申請を契機として当該ユーザＩＤを他のユーザＩＤと関係付けて登録してもよい。すなわち、登録手段５１は、ユーザＩＤに基づく申請を契機として、他のユーザＩＤを「仲間」として登録する。なお、以下の説明では、ユーザＩＤが仲間の関係にあることと、対応するユーザが仲間の関係にあることとは、同義である。
この場合の登録手段５１は例えば、以下のとおり実行される。ゲームサーバ２０のＣＰＵ２１は、通信インタフェース部２５を介して、あるユーザＩＤに対応するユーザの通信端末１０から、仲間になりたいユーザＩＤ（あるいは、対応するユーザ名）を指定した申請メッセージ（申請）を受け付ける。この申請メッセージの送信は、ユーザの通信端末１０に提供されるウェブページの機能として予め設定されている。ＣＰＵ２１は、申請メッセージを受け付けると、申請メッセージに含まれるユーザＩＤに基づくアクセスがあったタイミングで、そのユーザＩＤに対応する通信端末１０宛に、他のユーザＩＤに基づく申請を承認するか否かを返信することを要求するためのウェブページを表示させるＨＴＭＬデータを送信する。その申請を承認することが返信されれば、ＣＰＵ２１は、両者を仲間として登録する。具体的には、ＣＰＵ２１は、ユーザデータベース３１内の対応する２つのユーザＩＤのユーザデータの「仲間」の箇所（図６参照）にデータを書き込む。
なお、ユーザ同士を関係付ける条件は、上記のような申請と承認を必要とする形式に限られず、同一のゲーム上のステージを実行するユーザや対戦を行ったユーザを、ユーザとゲーム内で関係付けられたユーザ、つまり仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で対戦を行うゲーム上のモードが存在する場合には、所定回数以上対戦を行ったユーザ同士を自動的に仲間として登録してもよい。
また、ユーザ同士を関係付ける条件は、同一のゲーム上のステージ若しくはエリアを実行するユーザや試合を行ったユーザ同士を仲間として登録してもよい。あるいは、所定回数の挨拶メッセージを送信するユーザ同士を自動的に仲間として登録してもよいし、ユーザ間で対戦（バトル）を行うゲーム上のモードが存在する場合には、所定回数以上対戦を行ったユーザ同士や、協力して敵キャラクタと対戦をしたユーザ同士を自動的に仲間として登録してもよい。
本実施形態では、ユーザ同士の仲間関係の登録をユーザデータベース３１にデータを書き込むことによって実現する例を示したが、この例に限られない。仲間関係に関するデータは、ゲームサーバ２０からアクセス可能なネットワーク上の外部の記憶装置に書き込まれるようにしてもよい。
【００４８】
ゲーム進行手段５２は、通信端末１０に対するユーザの操作に応じて、通信端末１０に表示されるウェブページを逐次更新するためのＨＴＭＬデータを送信することで、ゲームを進行させる。前述したように、野球形式のデジタルカードゲームには、ゲームを進行させる上で以下の処理が設けられている。
・スカウト処理：
自らのチームを作り上げていくために選手カードを探索する処理である。スカウトを実行することで行動ポイントは消費するが、強化ポイントは増加する。
・強化処理：
強化ポイントを消費することで、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理である。この場合、特定の選手カードの能力は上昇するが、一体化に用いられた選手カードは消失する。つまり、一体化に用いられた選手カードの数だけ選手数が減少する。
・試合処理：
他のユーザのチームと野球の試合を行う処理である。試合を行うことで運営ポイントは消費するが、試合に勝利すれば強化ポイントが増加する。
・抽選処理：
エールポイントを消費して、抽選によって選手カードを入手する処理である。
・オーダー処理：
ユーザが選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行するための処理である。
上述したように、本実施形態のゲームでは、スカウト処理、強化処理、試合処理及び抽選処理の各処理の実行に伴ってゲーム上のポイントが消費される。
【００４９】
なお、ゲーム進行手段５２を実現するに当たり、ゲームサーバ２０のＣＰＵ２１は、ウェブページ上に表示される各メニューに、ゲームを進行させるためのいずれかの処理を予め割り当てている。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。
【００５０】
ゲーム進行手段５２は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。
【００５１】
ゲーム進行手段５２によって通信端末１０に表示されるゲームのトップページの例を図８に示す。このトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８に例示されるトップページは、ユーザ名、チームのテキストのほか、ユーザデータ表示領域、選手画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、Ｘ／Ｙの形式で表記されているポイントまたは数は、Ｘがユーザの保有するポイントまたは数であり、Ｙがそのポイントまたは数の最大値であることを示す。例えば、選手数が「４０／６０」と表記されていれば、ユーザが保有する選手数が４０人であり、最大で保有可能な選手数が６０人であることを示す。
選手画像表示領域は、ユーザによって予め選択された選手カードの画像データが表示される領域である。
メニュー表示領域は、野球形式のデジタルカードゲームに設けられる複数の処理（スカウト処理、強化処理、試合処理、抽選処理、オーダー処理）に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「抽選」、「オーダー」の各メニューｍ１〜ｍ５が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。なお、オーダー処理は、ユーザの指示の下、選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行する処理である。
ゲーム進行手段５２は、通信端末１０に表示されたメニューに対するユーザの選択操作に応じた処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるようにして、階層的に各処理が実行される。
【００５２】
例えば、図８に示すトップページをユーザの通信端末１０に表示する場合について、ゲーム進行手段５２の機能は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。次にＣＰＵ２１は、図８に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。
【００５３】
［スカウト処理］
ゲーム進行手段５２は、ユーザが自らのチームを作り上げていくために選手カードを探索できるようにするスカウト処理を実行する。
図９は、スカウト処理が実行された場合に通信端末１０に表示されるウェブページの例を示す。図９は、トップページにおいてスカウトメニュー（図８のメニューｍ１）が選択操作されたときのウェブページの表示例である。
【００５４】
図９に例示するウェブページでは、表示領域１００において、複数の地域（エリア）に分けられた日本地図が、探索の対象となるエリアが強調表示された状態で表示される。
このスカウト処理では、ユーザは、探索の対象となるエリア（図９の例では、エリア９（サブエリア９−１，９−２，…））ごとに設けられる「探索する」と表記されたメニューｍ１０を選択操作する。この操作を契機として、探索の対象となるエリアについての探索が行われ、選手が発掘された場合に表示領域１０２にその選手の選手カードが表示される仕組みになっている。このとき、メニューｍ１０が選択操作されて探索が行われる度に、表示領域１０１に表示されている「探索率」（％）の値が増加する。また、表示領域１０１には、１回の探索に要する行動力の値（図９の例では「５」）、１回の探索で得られる強化ポイントの値（図９の例では「１０」）が表示される。１回の探索につき、表示されている行動力の値だけ行動ポイントが減少し、表示されている量の強化ポイントが増加するように構成されている。ゲーム進行手段５２では、探索を行う度に、ＣＰＵ２１がユーザデータベース３１にアクセスし、対象となるユーザＩＤの行動ポイント及び強化ポイントの値を更新する。
【００５５】
スカウト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、スカウト用に予め設けられた複数の選手の中から所定の、あるいはランダムな確率で抽選を行う。ＣＰＵ２１は、抽選により選手を得た（発掘した）場合には、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのデータに対して、発掘された新たな選手のデータを追加して、選手数の値を１だけ増加させる。さらにＣＰＵ２１は、発掘された選手の選手カードを表示領域１０２に表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。なお、このＨＴＭＬデータは、表示領域１０１の探索率のデータが更新されるようにして構成されている。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図９においてサブエリア９−１，９−２，…のすべてのエリアの探索率が１００％に達すると、エリア９についての探索は終了し、探索対象は次のエリア（この場合、エリア１０）に移る。なお、後述するように、探索率が１００％に達したとしても、表示領域１０２に表示可能な最大の枚数（図９のサブエリア９−１では、４枚）に相当する数の選手が発掘できたとは限らない。
【００５６】
スカウト処理では、探索対象となるエリアごとに、１回の探索に要する行動ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）行動ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される行動ポイントの量を多くしてもよい。
スカウト処理では、メニューｍ１０に対する選択操作を行う度に行動ポイントが減少していくため、スカウト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される行動ポイントがスカウト処理の実行前よりも減少されて表示されることになる。ユーザが保有する行動ポイントが０になれば、それ以上、探索を実行することはできない。但し、行動ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）するので、所定時間経過すれば、再び、探索を行うことが可能になる。
【００５７】
［強化処理］
ゲーム進行手段５２は、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理を実行する機能を有する。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
この一体化の処理は、例えば以下のように行われてよい。強化対象となる選手カード（ユーザによって指定された、残留する選手カード）を選手Ａの選手カードとし、選手Ａの選手カードに一体化させられて消失する選手カードを選手Ｂの選手カードとする。この場合、一体化の処理では、ＣＰＵ２１が選手Ａの選手カードの「打力」，「走力」，「守備力」の能力値を示すパラメータに対して、選手Ｂの選手カードの「打力」，「走力」，「守備力」の能力値を示すパラメータの一定比率をそれぞれ加算することで、新たな選手Ａの選手カードのパラメータを算出するようにしてもよい。この強化処理によって、選手Ｂの選手カードの能力上の特徴が選手Ａの選手カードに反映されることになる。
強化処理後には、ＣＰＵ２１は、強化処理の後にユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータから選手Ｂの選手カードのデータを削除し、選手数の値を１だけ減少させ、選手Ａの選手カードのパラメータを書き換え、対象となるユーザＩＤの強化ポイントを所定量減少させる。なお、強化ポイントは、上記スカウト処理を実行したり、以下に説明する試合処理を実行したりすることによって増加する。
【００５８】
強化処理についての通信端末１０における表示例について図１０Ａ及び図１０Ｂを参照して説明する。図１０Ａ及び図１０Ｂは、通信端末１０に対する操作に応じて一連に表示される表示例である。
ゲームサーバ２０のＣＰＵ２１は、例えば図８のウェブページ上でメニューｍ２が選択されたことを認識すると、一体化の対象となる複数の選手カードの選択を促すウェブページを表示するためのＨＴＭＬデータを通信端末１０宛に送信する。このとき最初に表示されるウェブページの一例は、図１０ＡのウェブページＰ１に示すように、強化指定選手（強化対象となる選手カードに対応する選手キャラクタ）の一覧であり、選択操作によって強化指定選手を選択できるように構成されている。強化指定選手が選択されると次に、図１０ＡのウェブページＰ２に示すように、一体化させる選手（消失する選手カードに対応する選手キャラクタ）の一覧が表示される。図１０Ａに示す各ウェブページは、選択操作によっていずれかの選手を選択できるように構成されている。図１０ＢのウェブページＰ３は確認用画面であり、例えば強化指定選手として選手Ａ、一体化させる選手として選手Ｂが選択された例が示されている。ここで、「強化する」というメニューを選択する操作が行われると、その選択結果がゲームサーバ２０へ通知される。ゲームサーバ２０のＣＰＵ２１は、受信した選択結果に基づいて、選手Ａの選手カードの新たな能力値を示すパラメータを算出するとともに、ユーザデータベース３１にアクセスして、選手Ｂの選手カードのデータを、対象となるユーザＩＤのデータから削除する。ＣＰＵ２１は、新たなパラメータの増加度合いを示す値を含むＨＴＭＬデータを通信端末１０宛に送信する。このＨＴＭＬデータの受信により、通信端末１０は、図１０ＢのウェブページＰ４及びＰ５に示すように、選択された選手Ａの選手カードと選手Ｂの選手カードが重なり合い、合体して選手Ａの選手カードのみが表示されるような演出表示を行う。図１０ＢのウェブページＰ５に示すように、強化対象の選手Ａの選手カードの能力値の増加度合い（図１０ＢのウェブページＰ５の例では、打力が２８、走力が５０、守備力が２４）を定量的に表示することが好ましい。
【００５９】
［試合処理］
ゲーム進行手段５２は、ユーザによる通信端末１０の操作入力を契機として、他のユーザのチームと野球の試合を行う試合処理を実行する機能を有する。
このゲームでは、試合処理を実行するには運営ポイントを必要とし、試合に勝利することで強化ポイントを得ることができる。つまり、試合処理の実行によって、ユーザＩＤに対応する運営ポイント、強化ポイントの値が変化しうる。１回の試合で必要となる（消費する）運営ポイントは、ユーザのチームで組まれるオーダーによって定まる値である。ユーザは、ユーザが保有する選手カードの中から試合に出場させたい選手カードをオーダー処理によって組み替えることができるが、試合に出場させたい所定数の選手カードによって、運営ポイントの消費量が決定される。例えば、選手カードごとに１回の試合で必要となるコスト（必要ポイント）が予め割り当てられており、試合に出場させたい所定数の選手の必要ポイントの合計が運営ポイントとなる。運営ポイントは、例えば所定時間（例えば1分）が経過する度に１ポイントずつ回復（増加）する。
【００６０】
ゲーム進行手段５２が試合処理を実行する機能は、例えば以下のとおり実現される。図１１は、ゲーム進行手段５２の機能により実現される、ユーザの通信端末１０上に表示されるウェブページの例を示す図である。
【００６１】
あるユーザＩＤに対応するユーザの通信端末１０のトップページ上でメニューｍ３（図８参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、そのユーザＩＤの試合相手の複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに決定する。このとき、試合相手の候補の技能レベルは、メニューｍ３を選択操作したユーザと同一の技能レベルであることが好ましい。ＣＰＵ２１は、複数の試合相手の候補のリストからいずれかの候補を選択可能とするウェブページを表示するためのＨＴＭＬデータをユーザの通信端末１０宛に送信する。
複数の試合相手の候補のリストからいずれかの候補を選択する操作がユーザによってなされると、図１１のウェブページＰ６に示すように、試合相手（対戦相手）ととともに試合開始の指示を促すメニューを含むウェブページが表示される。ここで、ユーザが「試合開始」のメニューを選択すると、ＣＰＵ２１は試合結果を決定する処理を行う。試合結果を決定するに当たって、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、対象となるユーザＩＤの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるとともに、試合相手となる２つのユーザＩＤに対応付けられた複数の選手カードの能力を示すパラメータを読み出す。そして、ＣＰＵ２１は、読み出したパラメータに基づいてユーザ間の試合結果を決定する。
【００６２】
試合結果の決定方法は、選手カードの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、試合相手となる２人のユーザが保有する複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、能力値の差が大きいほど高い確率としてもよい。このとき、図６に示したように、能力値を示すパラメータの項目が複数存在する場合には、各選手カードのパラメータを代表する値として、各項目のパラメータの値に対して所定の重み付け（例えば、図６の例では、「打力」を０．４、「走力」を０．２、「守備力」を０．４の重み付けにする等）をもって総合的な能力値を設定してもよい。
【００６３】
ＣＰＵ２１は、試合結果を決定すると、試合結果をユーザに通知するために、その試合結果を含むウェブページを表示させるＨＴＭＬデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末１０宛に送信する。「試合開始」のメニューを選択する操作が行われてから、試合結果を含むウェブページが表示されるまでの時間は極めて短時間（例えば数秒）であるため、ユーザは、簡易な操作のみで極めて短期間で試合結果を知ることができる。図１１のウェブページＰ７は、試合処理の実行によって表示されるウェブページを示す図である。図１１のウェブページＰ７では、例えばスコア等を含む試合結果が表示される。
【００６４】
［抽選処理］
ゲーム進行手段５２は、抽選によって選手カードをユーザに付与することを可能とする抽選処理を実行する。抽選処理は、好ましくは、選手カードを抽選箱の中から１枚を取り出す（引く）ような演出を経て実行される。抽選によって出現する選手カードは基本的にランダムであるが、レア度の高い選手カード（いわゆるレアカード）が抽選で出現する確率は非常に低く設定されている。抽選処理は、所定量のエールポイントと引き換えに行われてもよい。
【００６５】
以上、ゲーム進行手段５２の主要な機能（スカウト処理、強化処理、試合処理、及び抽選処理）について説明した。
ゲーム進行手段５２はさらに、ユーザが保持する各ポイントあるいは選手数に基づいて、ユーザによって選択されたメニューに応じた機能（スカウト処理、強化処理、試合処理、及び抽選処理）が実行できるか否かを判定し、選択されたメニューに応じた機能が実行できない場合には、機能が実行できないことをユーザに報知するためのテキストを含むページを通信端末１０上に表示する。例えば、ポイントが所定の閾値より低い場合にゲームの進行が制限されるように構成されている場合、具体的には、１回の探索に行動力が「５」必要となるエリアについてスカウト処理を実行しようとする場合に、ユーザの行動ポイントが「３」のときには、スカウト処理が実行できないため、例えば「行動ポイントが足りません。行動ポイントは３分ごとに１回復します。ゆっくり待ちましょう。」などといったテキストを表示させる。このとき、ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザの行動ポイントのデータと、探索対象のエリアに要する行動力（既定値）との比較処理を行って、スカウト処理の実行可否を判定する。
【００６６】
ここで、本実施形態のゲームでは、ユーザの通信端末１０が、野球の試合が行われる試合時間帯に当該試合が行われる野球場（スタジアム）内に存在する場合に、当該ユーザに対して特典を付与する処理が行われるようになっている。この処理は、取得手段５３、判別手段５４及び付与手段５５によって実行される。以降では、各手段の詳細について説明する。
【００６７】
取得手段５３は、ユーザの通信端末１０の現在位置（位置）を示す位置情報を取得する機能を備える。取得手段５３の機能は、以下のように実現される。
例えば、ユーザが、図８に示すトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューを選択すると、通信端末１０のＣＰＵ１１は、ウェブページを表示するためのＨＴＭＬデータの送信要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０に送信する。
一方、ゲームサーバ２０のＣＰＵ２１は、ＨＴＭＬデータの送信要求メッセージを、通信インタフェース部２５を介して受信すると、位置情報の送信要求メッセージを、通信インタフェース部２５を介して通信端末１０に送信する。
通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、ユーザＩＤと対応付けて、ゲームサーバ２０に送信する。
ゲームサーバ２０のＣＰＵ２１は、位置情報を受信する（取得する）毎に、取得した位置情報をユーザデータベース３１内の現在位置データに記録する。図１２に現在位置データの構成例を示す。図１２に示すように、現在位置データは、複数のユーザ（ユーザＩＤ）ごとに設けられている。現在位置データは、位置情報の取得日時（位置情報に含まれる測位時刻）、位置情報に含まれる緯度及び経度が、位置情報を取得する毎に記述されたデータである。そして、ＣＰＵ２１は、ユーザが選択したメニューに応じたウェブページを表示するためのＨＴＭＬデータを生成し、通信端末１０宛に送信する。
【００６８】
なお、上述した取得手段５３の機能の実現例では、ゲームサーバ２０のＣＰＵ２１は、図８に示すトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューが選択された場合に位置情報の送信要求メッセージを送信することとしているが、この場合に限られない。例えば、ゲームサーバ２０のＣＰＵ２１は、位置情報の送信要求メッセージを送信するためのメニューを予め設定（例えば、位置情報の送信要求メッセージを送信するのは、メニューｍ１が選択操作された場合のみ等）してもよいし、各メニューｍ１〜ｍ５の選択回数が所定回数（例えば５回）に達する毎に位置情報の送信要求メッセージを送信してもよい。また、ゲームサーバ２０のＣＰＵ２１は、例えば、図８に示すトップページを表示するためのＨＴＭＬデータの送信要求メッセージを受信した場合に、位置情報の送信要求メッセージを送信してもよいし、通信端末１０との間で所定の認証処理（例えば、ログイン認証など）を行う際に、位置情報の送信要求メッセージを送信してもよい。
【００６９】
判別手段５４は、ユーザ（第１のユーザ）の通信端末１０が、野球の試合（第１のイベント）が行われる試合時間帯（第１のイベント期間内）に当該試合が行われるスタジアム（第１の所定領域）内に存在するか否かを、位置情報に基づいて判別する機能を備える。ここで、「試合時間帯」には、試合開始から試合終了までの時間だけではなく、例えば、試合開始前の練習時間や試合終了後のファンサービスの時間等が含まれてもよい。また、「イベント」とは、例えば、ゲームにおいて模擬された現実世界のイベントであってもよく、具体的には、野球ゲームの場合には野球の試合（イベント）であってよいし、サッカーゲームの場合にはサッカーの試合（イベント）であってよいし、音楽ゲームの場合には音楽の演奏会（イベント）であってよい。さらに、「所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。
【００７０】
判別手段５４の機能は、以下のようにして実現できる。
ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０の位置情報を取得し、取得した位置情報を現在位置データに記録すると、当該ユーザの通信端末１０が、野球の試合の試合時間帯にスタジアム内に存在するか否かを判別する。具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザのユーザＩＤに対応する現在位置データを参照する。そして、ＣＰＵ２１は、現在位置データに記録された位置情報のうち最新の位置情報の緯度及び経度がスタジアム内に含まれるか否か、及び、最新の位置情報の取得日時が野球の試合時間帯に含まれるか否かを判別する。なお、通信端末１０の現在位置がスタジアム内に存在するか否かを判別するために、スタジアムの外縁の緯度及び経度は、ゲームデータベース３２に予め記録されていてもよい。また、野球の試合時間帯などの情報（例えば、練習開始時刻、試合開始時刻、各イニングの開始及び終了時刻、試合終了時刻、試合終了後のイベント（例えばファンサービスなど）の開始及び終了時刻など）は、ゲームデータベース３２に逐次記録されるようにしてもよい。
最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、ＣＰＵ２１は、ユーザの通信端末１０が、試合時間帯にスタジアム内に存在すると判別する。
【００７１】
付与手段５５は、ユーザ（第１のユーザ）の通信端末１０が試合時間帯（第１のイベント期間内）にスタジアム（第１の所定領域）に存在すると判別された後、所定の時刻から所定期間、前記ユーザに対してゲーム上の特典を付与する機能を備える。
ここで、「ユーザに対してゲーム上の特典を付与する」とは、特典（例えば、ポイント、アイテムなど）に関する情報をユーザのユーザＩＤに対応付けた状態で所定の記憶装置（例えばユーザデータベース３１など）に記憶させることであってよい。また、所定の記憶装置は、例えばゲームサーバ２０に設けられていてもよいし、ユーザの通信端末１０などに設けられていてもよい。
また、「特典」とは、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。さらに、「アイテム」とは、例えば、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。また、「アイテム」とは、通信端末１０がスタジアムに存在する場合にのみ与えられる特殊なアイテムであってもよい。さらに、「ゲーム上の有利な効果」とは、例えば、ユーザがゲーム上保有するアイテム（例えば選手カード）のパラメータを上昇させたり、キャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、「ゲーム上の有利な効果」とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作に応じて消費するゲーム上の各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の消費量を通常よりも低減させることであってもよいし、ユーザが上記の各種ポイントを入手できることであってもよい。なお、仲間を作ることでポイントを入手できる構成が既に設けられている場合には、そのポイントよりも多くのポイントを入手できるようにすればよい。さらに、「ゲーム上の有利な効果」とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、強化処理において選手カードの能力値が大幅に上昇する確率を上昇させることであってもよい。
また、「ゲーム上の有利な効果」とは、ユーザ毎の行動ポイント、運営ポイントの上限値を、通常の値である第１の値から、通常よりも高い第２の値まで上昇させることであってもよい。この場合、行動ポイント、運営ポイントの上限値を第２の値まで上昇させるだけでなく、すなわち、ポイントの枠を大きくするだけでなく、実際にユーザが保有している現状の行動ポイント、運営ポイントを第２の値まで上昇させてもよい。行動ポイント、運営ポイントの上限値を上昇させた場合、第１の所定期間が経過するまで上昇させた上限値を維持してもよい。例えば、３日間のみ行動ポイント、運営ポイントを第２の値まで上昇させ、その後は第１のポイントに戻すようにしてもよい。あるいは、ゲームの実行により行動ポイント、運営ポイントが第１の値またはそれ以下にまで低減したときに、上限値を元（第１の値）に戻してもよい。
例えば、通常の行動ポイントの上限値が８０（第１の値）、通常の運営ポイントの上限値が１００（第１の値）であるときに、ユーザが試合時間帯にスタジアムにいた場合、行動ポイントの上限値を１００（第２の値）、運営ポイントの上限値を１２０（第２の値）でまで上昇させてもよい。その際、行動ポイントや運営ポイントを消費していて、仮に両方とも１０であったとしても、行動ポイントを１００（第２の値）まで、運営ポイントを１２０（第２の値）まで上昇させてもよい。その後、行動ポイントや運営ポイントを消費し、行動ポイントが８０（第１の値）を下回ったときや、運営ポイントが１００（第１の値）を下回ったときに、上限値を元に戻してもよい。
また、「ゲーム上の有利な効果」とは、例えば、所定時間の経過により各種ポイントが付与される場合において、各種ポイントの量を所定の割合だけ増加させることであってもよい。
また、「ゲーム上の有利な効果」とは、例えば、抽選処理において、レア度の高い選手カードが出現する確率を通常よりも高くすることであってもよい。抽選処理を実行するゲーム進行手段５２は、抽選手段の一例である。
【００７２】
付与手段５５の機能は、以下のようにして実現できる。なお、以下では、ユーザに付与される特典が、各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の付与量を通常（つまり、特典が付与されない状態）よりも増加させることである場合を一例として説明する。ここで、各種ポイントのうち少なくとも一種類のポイントの付与量が増加するようにしてもよい。
この場合、ユーザは、特典を得ることにより、ゲームを有利に進めることができる。例えば、特典が、行動ポイントの付与量を増加させることである場合、通常であれば所定時間（例えば３分）が経過する度に行動ポイントが１ポイントずつ回復（増加）するのに対し、特典付与期間では、行動ポイントが３ポイントずつ回復（増加）してもよい。この場合、ユーザは、スカウト処理を実行する際に、１回の探索を行うために必要な行動ポイントを通常よりも早期に得ることができるので、ゲームの進行度を通常よりも早く上げることができるというメリットが得られる。ユーザは、このメリットを得るために、野球の試合が行われているスタジアムに積極的に出向くことが動機付けられる。
また、例えば、特典が、ユーザの保有する選手カードの能力値を、特典付与期間の間上昇させることである場合、特典付与期間において、ユーザは、試合処理における他のユーザとの対戦に勝利する可能性を高めることができる。これにより、ユーザは、ゲーム上の有利な効果を得ることができる。
【００７３】
ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０が、試合時間帯にスタジアム内に存在すると判別すると、当該ユーザに対して特典を付与する処理を行う。ここで、特典を付与する処理について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザデータベース３１内の特典付与データに所定の情報を記録する。図１３に特典付与データの構成例を示す。図１３に示すように、特典付与データは、複数のユーザ（ユーザＩＤ）ごとに設けられており、特典が付与された日時である特典付与日時と、特典が付与される期間である特典付与期間（第１の所定期間）などが含まれるデータである。特典付与期間に記述されるデータは、例えば、特典付与日時からの所定の期間（例えば、特典付与日時から２４時間など）であってもよいし、特典の付与が終了する時期（例えば、試合日の翌日の午前０時までなど）であってもよい。また、特典付与期間の終了時期は、例えば、試合時間帯以内（例えば、試合中）の所定のタイミングであってもよいし、試合時間帯以降（例えば、試合が終了してから所定時間経過後）のタイミングであってもよい。ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別すると、当該ユーザのユーザＩＤに対応する特典付与データに、特典付与日時（ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別されたときの日時）及び特典付与期間を記録する。
【００７４】
ＣＰＵ２１は、上述したスカウト処理及び試合処理を実行する際に、ユーザのユーザＩＤに対応する特典付与データを参照し、スカウト処理及び試合処理の実行するタイミングが特典付与期間内である場合には、付与される強化ポイントの量を所定の割合だけ増加させる。また、ＣＰＵ２１は、所定時間の経過により各種ポイント（行動ポイント、強化ポイント、運営ポイント、エールポイント）を付与するタイミングで、ユーザのユーザＩＤに対応する特典付与データを参照し、特典付与期間内である場合には、付与される各種ポイントの量を所定の割合だけ増加させる。なお、ＣＰＵ２１は、各処理（スカウト処理、強化処理、試合処理、及び抽選処理）の実行するタイミングが特典付与期間内である場合には、各処理で消費される各種ポイントの量を所定の割合だけ低減させてもよい。この所定の割合は任意に設定されてもよい。また、所定の割合は、予めＲＯＭ２２やＲＡＭ２３などに記憶されてもよい。
ＣＰＵ２１は、図１４に示すウェブページを表示するためのＨＴＭＬデータを生成し、通信端末１０宛に送信する。図１４に示すウェブページの例では、特典付与日時から所定期間（図の例では１週間）の間、ゲーム上の各処理の実行により、あるいは所定時間が経過する毎に得られる各種ポイントの量が増加することを表すテキストなどが含まれる。
【００７５】
なお、特典としてアイテムやポイントなどをユーザに付与する場合には、ＣＰＵ２１は、特典を付与する処理において、付与対象となるユーザのユーザＩＤと、付与されるポイントやアイテムとを関連付けてユーザデータベース３１に記憶するようにしてもよい。例えば、特典として所定量の強化ポイントがユーザに付与される場合には、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（所定量のポイントを加算する処理）を行ってよい。また、特典としてアイテムやポイントなどがユーザに付与される場合には、特典付与期間内にアイテムやポイントなどが付与される回数は、１回であってもよいし、複数回であってもよい。
また、特典が、ユーザの保有する選手カードの能力値を、特典付与期間の間上昇させることである場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける保有カードの能力値を所定の割合だけ加算する処理を行ってよい。この場合、ＣＰＵ２１は、特典付与期間が終了すると、保有カードの能力値を元の値に戻す。
【００７６】
（６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１５のフローチャートを参照して説明する。図１５のフローチャートは、主として取得手段５３、判別手段５４及び付与手段５５によって実行される処理である。
【００７７】
先ず、図８に示すトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューを選択すると、通信端末１０のＣＰＵ１１は、ウェブページを表示するためのＨＴＭＬデータの送信要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０に送信する。一方、ゲームサーバ２０のＣＰＵ２１は、ＨＴＭＬデータの送信要求メッセージを、通信インタフェース部２５を介して受信すると（ステップＳ１００：ＹＥＳ）、位置情報の送信要求メッセージを、通信インタフェース部２５を介して通信端末１０に送信する（ステップＳ１１０）。
【００７８】
次に、通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、ユーザＩＤと対応付けて、ゲームサーバ２０に送信する。
一方、ゲームサーバ２０のＣＰＵ２１は、位置情報を通信端末１０から受信する（取得する）と（ステップＳ１２０：ＹＥＳ）、取得した位置情報をユーザデータベース３１内の現在位置データに記録する（ステップＳ１３０）。なお、ステップＳ１２０において、通信端末１０から位置情報を受信しない状態で所定時間経過した場合には（ステップＳ１２０：ＮＯ）、ＣＰＵ２１は、処理を終了してもよい。
【００７９】
次に、ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０が、野球の試合の試合時間帯にスタジアム内に存在するか否かを判別する。ＣＰＵ２１は、現在位置データを参照し、最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別する。そして、ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別した場合（ステップＳ１４０：ＹＥＳ）、当該ユーザに対して特典を付与する処理を行う（ステップＳ１５０）。具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザのユーザＩＤに対応する特典付与データに特典付与日時及び特典付与期間を記録する。また、ＣＰＵ２１は、特典を付与したことを通知するためのウェブページを表示させるＨＴＭＬデータを生成して、ユーザの通信端末１０に送信する（ステップＳ１６０）。この場合、ユーザの通信端末１０上には、図１４に例示したウェブページが表示される。
また、ステップＳ１４０において、ユーザの通信端末１０が試合時間帯にスタジアム内に存在しないと判別した場合（ステップＳ１４０：ＮＯ）、ＣＰＵ２１は、処理を終了してもよい。
【００８０】
ＣＰＵ２１は、スカウト処理及び試合処理を実行する際に、ユーザのユーザＩＤに対応する特典付与データを参照し、スカウト処理及び試合処理の実行するタイミングが特典付与期間内である場合には、付与される強化ポイントの量を所定の割合だけ増加させる。また、ＣＰＵ２１は、所定時間の経過により各種ポイントを付与するタイミングで、ユーザのユーザＩＤに対応する特典付与データを参照し、特典付与期間内である場合には、付与される各種ポイントの量を所定の割合だけ増加させる。なお、ＣＰＵ２１は、各処理の実行するタイミングが特典付与期間内である場合には、各処理で消費される各種ポイントの量を所定の割合だけ低減させてもよい。
【００８１】
上述したように、実施形態のゲーム制御装置によれば、ユーザは、自身の通信端末１０が試合時間帯にスタジアムに存在すると判別された後の所定の時刻から特典付与期間の間に、特典を得ることができる。この場合、ユーザは、特典を得るために、現実に野球の試合が行われているスタジアムに積極的に出向き、野球の試合を観戦することが動機付けられる。そして、このように、野球の試合が行われているスタジアムに出向くことにより、ユーザは、野球の試合とゲームが連動しているような感覚を得ることができる。これにより、通信端末の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。また、例えば、スタジアムやイベント会場等の運営側にとっては、ユーザを来場させる誘因力あるシステムを構築することができる。
【００８２】
（７）変形例
（７−１）変形例１
上記実施形態において、ユーザ同士を関係付ける登録手段５１（関係付け手段）を備え、付与手段５５は、ユーザ（第１のユーザ）の仲間のユーザ（第１のユーザと関係付けられた第２のユーザ）の通信端末１０が、第２のイベントが行われる第２のイベント期間内に前記第２のイベントが行われる第２の所定領域に存在すると判別された場合に、特典付与期間（所定期間）を延長してもよい。
ここで、「第２のイベント」は、「第１のイベント」と同じ種類のイベントであってもよいし、異なる種類のイベントであってもよい。例えば、第１のイベントが野球の試合の場合には、第２のイベントは、野球の試合であってもよいし、サッカーの試合であってもよいし、音楽の演奏会などであってもよい。また、「第２のイベント」の「第２のイベント期間」及び「第２の所定領域」は、「第１のイベント」の「第１のイベント期間」及び「第１の所定領域」と同一であってもよいし、異なっていてもよい。例えば、第１のイベント及び第２のイベントは、同じ日時に同じスタジアムで行われる野球の試合であってもよいし、同じ日時に異なるスタジアムで行われる野球の試合であってもよいし、異なる日時に同じスタジアムで行われる野球の試合であってもよいし、異なる日時に異なるスタジアムで行われる野球の試合であってもよい。なお、ここで、同じ種類のイベントとしては、広く野球観戦としてもよいし、自分が観戦したチーム同士の対戦、あるいは自分が観戦した対戦のいずれか一方のチームの対戦に限定してもよい。
なお、「第１のイベント」と「第２のイベント」が同じ種類のイベントであることを所定期間延長の条件としてもよい。この場合、ユーザにとって、自分が野球観戦をし、後日、自分の仲間が野球観戦に行けば、特典付与の期間が延長する、というように、特典入手の構成を把握し易くなるため有用である。
また、「第１の所定領域」と「第２の所定領域」が同一であることを所定期間延長の条件としてもよい。この場合、位置情報の取得範囲を絞ることができるため、ゲーム制御装置のシステムを簡易なものとすることができる。また、例えば野球観戦したスタジアムと同じスタジアムに、自分の仲間が後日行けば、特典付与の期間が延長する、というように、特典入手の構成を把握し易くなるため有用である。
また、「第１のイベント期間」と「第２のイベント期間」が異なる場合、その前後関係は問わないが、第２のイベント期間の方が第１のイベント期間より時間的に後であれば、ユーザにとって以下のような利点が生じる。すなわち、ユーザは、例えば野球観戦（第１のイベント）に行った後に、自分の仲間に対して野球観戦（第２のイベント）に行くよう依頼したり、促すといった行動をとることで、所定期間延長への働きかけを行うことができる。
なお、「第１のイベント期間」と「第２のイベント期間」の間は、第１のユーザに対してゲーム上の特典を付与する所定期間よりも短い期間であることが好ましい。例えば、第１のユーザに対してゲーム上の特典を付与する所定期間が２週間であり、「第１のイベント期間」と「第２のイベント期間」の間は２週間未満である場合、所定期間と「第２のイベント期間」が重なるため、第２のイベント期間内に所定期間が延長されるように第２のユーザがイベントに行くことを第１のユーザに促すことができる。
また、「第２のイベント」は、複数存在してもよい。
さらに、第１のユーザの通信端末及び第２のユーザの通信端末において実行されるゲームは、同じゲームであってもよいし、異なるゲームであってもよい。ここで、異なるゲームとは、同じジャンルのゲームであるがゲームのタイトルが異なる場合なども含む。例えば、ゲーム自体は異なるものであるが、ともに野球という同じスポーツを題材にしたゲームが二つ以上存在する場合には、野球そのもののルールや遊び方がほぼ共通しているため、これらのゲーム間に本変形例の構成を適用することが可能である。野球以外でも、サッカー、アメリカンフットボール、バスケットボール等のスポーツゲーム、競馬等、ユーザがそのルールや遊び方を共通認識できる対象であれば何でもよい。特に、ゲーム制作メーカー、あるいはゲームのプラットフォームが同じである場合には、本変形例の構成を容易に実現し得る。
本変形例では、野球ゲームＡにおいてユーザと関係付けられた仲間のユーザが、野球ゲームＡと異なる野球ゲームＢをプレイすることによって、当該ユーザの特典付与期間が延長される場合を一例として説明する。ここで、野球ゲームＡでは、野球ゲームＡの登録ユーザが野球の試合ＡをスタジアムＡで観戦すると、当該登録ユーザに対して特典が付与されるように構成されている。また、野球ゲームＡでは、野球ゲームＡの登録ユーザの仲間のユーザであり、且つ野球ゲームＢの登録ユーザが、野球の試合ＢをスタジアムＢで観戦すると、当該野球ゲームＡの登録ユーザの特典付与期間が所定期間（例えば１日）延長されるように構成されている。なお、ここでは、試合Ｂは、試合Ａの翌日に行われ、スタジアムＢは、スタジアムＡと異なるスタジアムであることとする。また、本変形例では、ゲームが野球ゲームである場合について説明しているが、ゲームの種類は野球ゲームに限定されず、例えばサッカーゲームや競馬ゲームなどであってよい。
本変形例では、例えば、仲間のユーザの通信端末１０が、試合Ｂの試合時間帯（第２のイベント期間内）にスタジアムＢ（第２の所定領域）に存在すると判別された場合に、ユーザは、特典付与期間が付与されるというメリットを得ることができる。この場合、ユーザは、このメリットを得るために、他のユーザと関係付けられる（仲間になる）こと、及び仲間のユーザに対して試合Ｂの試合時間帯にスタジアムＢに出向くこと（つまり、試合Ｂを観戦すること）を誘導することが動機付けられる。これにより、仲間関係の構築及び仲間同士の交流が活性化されるため、ゲームのソーシャル性を向上させることができる。
【００８３】
ここで、本変形例のゲームシステムのシステム構成の一例について図１６を参照して説明する。図１６に示すように、本変形例のゲームシステムは、実施形態のゲームシステムにおける通信端末と同様に構成された通信端末１０（図の例では１０ａ，１０ｂ，１０ｃ，…）と、通信網ＮＷに接続されているゲームサーバ２０ａ，２０ｂ，…と、データベースサーバ３０ａ，３０ｂ，…とによって構成されている。ここで、ゲームサーバ２０ａ及びゲームサーバ２０ｂは、実施形態のゲームシステムにおけるゲームサーバ２０と同様に構成されている。また、データベースサーバ３０ａ及びデータベースサーバ３０ｂは、実施形態のゲームシステムにおけるデータベースサーバ３０と同様に構成されている。また、ゲームサーバ２０ａ及びデータベースサーバ３０ａは、野球ゲームＡについての実行を制御する（あるいは、管理対象とする）サーバであるとする。ゲームサーバ２０ｂ及びデータベースサーバ３０ｂは、野球ゲームＢについての実行を制御する（あるいは、管理対象とする）サーバであるとする。なお、野球ゲームＡ及び野球ゲームＢは、実施形態のゲームと同様に構成されていることとする。
【００８４】
本変形例における付与手段５５（ここでは、ゲームサーバ２０ａの付与手段５５）の機能は、図１７のシーケンスチャートを参照して、以下のようにして実現される。図１７は、本変形例のゲームサーバ２０ａ，２０ｂの主要な処理の一例を示すシーケンスチャートである。
ここで、前提として、ユーザは、野球ゲームＡの登録ユーザであって、野球の試合ＡをスタジアムＡで観戦したことにより、特典付与期間の間、特典が付与されていることとする。また、ユーザの仲間のユーザは、野球ゲームＡ及び野球ゲームＢの登録ユーザであって、野球ゲームＡにおいてユーザと関係付けられている（仲間関係にある）こととする。
図１７において、先ず、仲間のユーザが、野球ゲームＢのトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューを選択すると、仲間のユーザの通信端末１０のＣＰＵ１１は、ウェブページを表示するためのＨＴＭＬデータの送信要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０ｂに送信する（ステップＳ２００）。
一方、ゲームサーバ２０ｂの取得手段５３では、ＣＰＵ２１は、ＨＴＭＬデータの送信要求メッセージを、通信インタフェース部２５を介して受信すると、位置情報の送信要求メッセージを、通信インタフェース部２５を介して、仲間のユーザの通信端末１０に送信する（ステップＳ２０２）。
仲間のユーザの通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる（ステップＳ２０４）。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、仲間のユーザのユーザＩＤと対応付けて、ゲームサーバ２０ｂに送信する（ステップＳ２０６）。
【００８５】
ゲームサーバ２０ｂの判別手段５４では、ＣＰＵ２１は、仲間のユーザの通信端末１０が、野球の試合Ｂの試合時間帯にスタジアムＢに存在するか否かを判別する（ステップＳ２０８）。そして、ＣＰＵ２１は、仲間のユーザの通信端末１０が試合Ｂの試合時間帯にスタジアムＢに存在すると判別した場合、仲間のユーザの通信端末１０が試合Ｂの試合時間帯にスタジアムＢに存在することを通知するための通知メッセージを、ゲームサーバ２０ａに送信する（ステップＳ２１０）。
一方、ゲームサーバ２０ａの付与手段５５では、ＣＰＵ２１は、通知メッセージを受信すると、ユーザの特典付与期間の延長処理を行う（ステップＳ２１２）。具体的には、ゲームサーバ２０ａのＣＰＵ２１は、データベースサーバ３０ａのユーザデータベース３１にアクセスし、ユーザのユーザＩＤに対応する特典付与データの特典付与期間が所定期間（例えば１日）延長されるように更新を行う。
なお、ゲームサーバ２０ａのＣＰＵ２１は、ユーザの特典付与期間の延長処理を行った後に、仲間のユーザによって特典付与期間が延長されたことを通知するウェブページを表示するためのＨＴＭＬデータを生成して、ユーザの通信端末１０に送信してもよい（ステップＳ２１４）。
【００８６】
上述した例では、仲間のユーザ（第２のユーザ）が１名の場合について説明したが、仲間のユーザ（第２のユーザ）が複数存在する場合であっても本変形例の構成を適用し得る。例えば、特典付与期間内に野球の試合が行われる毎に、複数の仲間のユーザが連続してスタジアムに出向いた場合には、当該特典付与期間が継続的に延長され得る。具体的に説明すると、上記説明において、仲間のユーザ（ここでは、仲間のユーザＸとする）の通信端末１０が野球の試合Ｂの試合時間帯にスタジアムＢに存在すると判別されることにより、ユーザの特典付与期間が延長されている間に、仲間のユーザＸとは別の仲間のユーザＹ（第２のユーザ）が、野球の試合Ｂの翌日にスタジアムＣ（第２の所定領域）で行われる野球の試合Ｃ（第２のイベント）を観戦した場合、ユーザの特典付与期間がさらに延長（例えば１日）されてもよい。この場合、野球ゲームＡでは、野球ゲームＡの登録ユーザの仲間のユーザが、野球の試合ＣをスタジアムＣで観戦すると、当該野球ゲームＡの登録ユーザの特典付与期間が所定期間（例えば１日）延長されるように構成されてもよい。したがって、この時点で、ユーザの特典付与期間は、仲間のユーザＸ，Ｙによって２日間延長されたことになる。
さらに、ユーザの特典付与期間（延長された期間も含む）の間に、仲間のユーザＸ，Ｙとは別の仲間のユーザＺ（第２のユーザ）がスタジアム（第２の所定領域）で野球の試合（第２のイベント）を観戦した場合には、当該特典期間がさらに１日延長されてもよい。これにより、ユーザの特典付与期間は、結果として３日間延長されることになる。以下、同様にして、複数の仲間のユーザが連続してスタジアムに出向くことにより、ユーザの特典付与期間が継続的に延長され得る。
また、仲間のユーザＸ，Ｙの通信端末１０が、同一の試合が行われるスタジアム（例えば、野球の試合Ｂが行われるスタジアムＢ）に存在すると判別された場合には、判別された仲間のユーザの通信端末１０の数（この場合、２つ）に応じて、ユーザの特典付与期間が延長（この場合、２日延長）されてもよい。
なお、上述した特典付与期間の継続的な延長は、以下に説明する変形例においても適用され得る。
【００８７】
（７−２）変形例２
上記変形例１において、ユーザ（第１のユーザ）の通信端末１０及び当該ユーザの仲間のユーザ（第２のユーザ）の通信端末１０において実行されるゲームが同じゲームであってもよい。
本変形例では、野球ゲームＡにおいてユーザと関係付けられた仲間のユーザが、野球ゲームＡをプレイすることによって、当該ユーザの特典付与期間が延長される場合を一例として説明する。ここで、野球ゲームＡでは、野球ゲームＡの登録ユーザが野球の試合ＡをスタジアムＡで観戦すると、当該登録ユーザに対して特典が付与されるように構成されている。また、野球ゲームＡでは、野球ゲームＡの登録ユーザの仲間のユーザが、野球の試合ＢをスタジアムＡで観戦すると、当該野球ゲームＡの登録ユーザの特典付与期間が所定期間（例えば１日）延長されるように構成されている。なお、本変形例では、試合Ｂは、試合Ａの翌日に行われることとする。また、本変形例では、ゲームが野球ゲームである場合について説明しているが、ゲームの種類は野球ゲームに限定されず、例えばサッカーゲームや競馬ゲームなどであってよい。
本変形例では、ユーザ（第１のユーザ）の通信端末１０及び当該ユーザの仲間のユーザ（第２のユーザ）の通信端末１０において実行されるゲームが同じ野球ゲームＡである場合に、ユーザは、特典付与期間が延長されるというメリットを得ることができる。これにより、ユーザは、このメリットを得るために、他のユーザと同じゲーム上で関係付けられる（仲間になる）ことが動機付けられる。しかも、この場合、ユーザ及び他のユーザは、同じゲームをプレイしていることにより互いに共感し、仲間として協力してゲームをプレイすることが動機付けられることから、仲間関係の構築をさらに活性化することができる。
【００８８】
本変形例における付与手段５５（ここでは、ゲームサーバ２０ａの付与手段５５）の機能は、以下のようにして実現される。なお、本変形例では、野球ゲームＡについての実行を制御するゲームサーバ２０ａ及びデータベースサーバ３０ａを用いればよく、野球ゲームＢについての実行を制御するゲームサーバ２０ｂ及びデータベースサーバ３０ｂを設けなくてもよい。
例えば、ゲームサーバ２０ａのＣＰＵ２１は、ＨＴＭＬデータの送信要求を仲間のユーザの通信端末１０から受信したことに基づいて、仲間のユーザの通信端末１０の位置情報を取得する。そして、ＣＰＵ２１は、仲間のユーザの通信端末１０が、試合Ｂの試合時間帯にスタジアムＡに存在すると判別した場合に、ユーザのユーザＩＤに対応する特典付与データの特典付与期間が所定期間（例えば１日）延長されるように更新を行う。
【００８９】
（７−３）変形例３
上記変形例１または２において、付与手段５５は、特典付与期間（所定期間）の延長回数を所定回数に制限してもよい。
例えば、仲間のユーザ（第２のユーザ）の通信端末１０の位置についての判別が１回行われる毎に特典付与期間が延長される場合、複数の仲間のユーザが連続して所定のイベント会場に出向くことにより、特典付与期間が継続して無制限に延長されることが考えられる。この場合、ユーザ（第１のユーザ）に対して特典を付与する状況が常に設定されることになる。これにより、ユーザが他のユーザと比べて突出して有利になることから、他のユーザとの間で公平性を損なうおそれがある。
本変形例によれば、特典付与期間の延長回数が所定回数に制限されるため、ユーザに対して特典を付与する状況が常に設定されることを抑制することができる。このため、特典付与期間が延長されることに起因してユーザ間の公平性が損なわれることのない仕組みとすることができる。
【００９０】
本変形例における判別手段５４の機能は、以下のようにして実現される。以降では、ユーザの仲間のユーザＸが出向いたイベント（第２のイベント）が、スタジアムＡ（第２の所定領域）で行われた野球の試合Ｂであって、ユーザの仲間のユーザＹが出向いたイベント（第２のイベント）が、試合Ｂの翌日にスタジアムＡ（第２の所定領域）で行われた野球の試合Ｃである場合を一例として説明する。
ゲームサーバ２０のＣＰＵ２１は、例えば、図１８に例示した特典付与データをユーザデータベース３１に予め格納してもよい。図１８に本変形例における特典付与データの構成例を示す。図１８に示すように、本変形例の特典付与データには延長回数が含まれてもよい。ＣＰＵ２１は、仲間のユーザＸの通信端末１０が、試合Ｂの試合時間帯にスタジアムＡに存在すると判別された場合、ユーザのユーザＩＤに対応する特典付与データの特典付与期間を延長するとともに、延長回数を１つ増加する。また、ＣＰＵ２１は、仲間のユーザＹの通信端末１０が、試合Ｃの試合時間帯にスタジアムＡに存在すると判別された場合、ユーザのユーザＩＤに対応する特典付与データの特典付与期間を延長するとともに、延長回数を１つ増加する。そして、延長回数が所定回数（例えば３回）に達した場合、ＣＰＵ２１は、仲間のユーザの通信端末１０の現在位置に基づく特典付与期間の延長を行わなくてよい。
【００９１】
（７−４）変形例４
上記変形例３において、付与手段５５は、仲間のユーザ（第２のユーザ）が複数存在する場合に、同一の仲間のユーザに基づく特典付与期間（所定期間）の延長回数を所定回数に制限してもよい。
例えば、同一の仲間のユーザ（例えば仲間のユーザＸ）に基づく特典付与期間の延長回数を制限しない場合、ユーザは、特典付与期間をより長くするために、仲間のユーザＸ（例えば、非常に仲の良い仲間のユーザ）に対して試合Ｂ，Ｃに出向くことを誘導することが考えられる。このとき、ユーザにとっては、仲間のユーザＸとの交流を活性化することができる一方で、他の仲間のユーザとの交流が疎かになる場合があることから、ユーザ間の幅広い交流を促進する仕組みとならないおそれがある。
本変形例によれば、ユーザは、特典付与期間をより長くするために、より多くの仲間のユーザに対して、試合Ｂ，Ｃの試合時間帯にスタジアムＡに出向くこと（つまり、試合Ｂ，Ｃを観戦すること）を誘導することが動機付けられる。このため、ユーザと、多くの仲間のユーザとの交流を活性化させることができることから、ユーザ間の幅広い交流を促進する仕組みとすることができる。
【００９２】
ゲームサーバ２０のＣＰＵ２１は、例えば、図１９に例示した特典付与データをユーザデータベース３１に予め格納してもよい。図１９に本変形例における特典付与データの構成例を示す。図１９に示すように、本変形例の特典付与データには、それぞれ一つの特典付与日時及び特典付与期間ごとに、仲間のユーザＩＤが延長回数と対応付けられるように含まれてもよい。ＣＰＵ２１は、仲間のユーザＸの通信端末１０が、試合Ｂの試合時間帯にスタジアムＡに存在すると判別された場合、ユーザのユーザＩＤに対応する特典付与データの特典付与期間を延長するとともに、当該特典付与データのうち仲間のユーザＸのユーザＩＤに対応する延長回数を１つ増加する。また、ＣＰＵ２１は、仲間のユーザＹの通信端末１０が、試合Ｃの試合時間帯にスタジアムＡに存在すると判別された場合、ユーザのユーザＩＤに対応する特典付与データの特典付与期間を延長するとともに、当該特典付与データのうち仲間のユーザＹのユーザＩＤに対応する延長回数を１つ増加する。そして、仲間のユーザのユーザＩＤに対応する延長回数が所定回数（例えば１回）に達した場合、ＣＰＵ２１は、当該ユーザＩＤに対応する仲間のユーザの通信端末１０の現在位置に基づく特典付与期間の延長を行わなくてよい。
【００９３】
（７−５）変形例５
上記実施形態において、ユーザ同士を関係付ける登録手段５１（関係付け手段）を備え、付与手段５５は、ユーザ（第１のユーザ）の通信端末１０が試合Ａ（第１のイベント）の試合時間帯（第１のイベント期間内）にスタジアムＡ（第１の所定領域）に存在せず、且つ、当該ユーザの仲間のユーザ（第２のユーザ）の通信端末１０が試合Ａの試合時間帯（第１のイベント期間内）にスタジアムＡ（第１の所定領域）に存在すると判別された場合に、ユーザ（第１のユーザ）に対してゲーム上の特典を付与してもよい。
本変形例によれば、例えば、ユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在しない場合であっても、仲間のユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在すれば、ユーザは、特典を得ることができる。この場合、ユーザには、特典を得る可能性を高めるために、他のユーザと関係付けられる（仲間になる）ことが動機付けられる。これにより、仲間関係の構築が活性化されるため、ゲームのソーシャル性を向上させることができる。
【００９４】
本変形例における付与手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、ユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在しないと判別した場合に、当該ユーザの仲間ユーザのユーザＩＤをユーザデータから抽出し、仲間ユーザのユーザＩＤに対応する通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在するか否かを判別する。そして、ＣＰＵ２１は、仲間ユーザのユーザＩＤに対応する通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在すると判別した場合に、ユーザに対して特典を付与する処理を行う。
【００９５】
（７−６）変形例６
上記変形例５において、付与手段５５は、ユーザ（第１のユーザ）と仲間のユーザ（第２のユーザ）とのゲーム上の関係度合を示す親密度が所定レベル以上の場合に、当該ユーザ（第１のユーザ）に対して特典を付与してもよい。
ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものである。親密度のデータ（親密度データ）の一例を図２０に示す。図２０に示す親密度データの例では、各ユーザの仲間のユーザ（ユーザＩＤ）と対応付けて、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などが記録され、これらの頻度や回数に基づいて一定の基準で親密度の値が設定される。応援頻度やプレゼント回数が多いほど親密度が高く設定される。また、一定の基準では、親密度の設定の基礎となる項目（図２０では、応援頻度やプレゼント回数など）ごとに、重み付けを考慮したものであってもよい。例えば、応援頻度が少なくてもプレゼント回数が多い場合に親密度を高く設定してもよい。このような親密度データは、例えば、ユーザデータベース３１内に記録される。
本変形例によれば、例えば、ユーザがスタジアムで野球の試合を観戦していない場合であっても、当該ユーザと親密度の高い仲間のユーザが当該スタジアムで野球の試合を観戦していれば、当該ユーザは特典を得ることができる。このため、ユーザには、特典を得るために、仲間のユーザとの親密度を高めることが動機付けられる。これにより、仲間関係にあるユーザ間の関係性を高めることができる仕組みとすることができ、ゲームのソーシャル性の向上が期待できる。
【００９６】
本変形例における付与手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１内のユーザデータと親密度データをユーザＩＤごとに紐付けて管理している。ＣＰＵ２１は、例えば応援メッセージの送受信やプレゼントの仲間の間での送受信を、通信インタフェース部２５を介して送信先のユーザの要請に基づいて行っている。このような送受信が生ずると、ＣＰＵ２１は、対象となる親密度データを逐次更新する。
ＣＰＵ２１は、例えば、ユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在しないと判別した場合に、当該ユーザの仲間のユーザのユーザＩＤをユーザデータから抽出し、仲間のユーザのユーザＩＤに対応する通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在するか否かを判別する。そして、ＣＰＵ２１は、仲間のユーザのユーザＩＤに対応する通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在すると判別した場合に、親密度データを参照して、その仲間のユーザとユーザとの親密度が所定の閾値（例えば５）以上であれば、ユーザに対して特典を付与する処理を行う。例えば、図２０に例示した親密度データを用いた場合、ＣＰＵ２１は、ユーザＩＤが「０００００１」のユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在しないと判別した場合であっても、ユーザＩＤが「００３４２１」の仲間のユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在すると判別したときには、ユーザＩＤが「０００００１」のユーザに対して特典を付与する処理を行ってもよい。一方、ＣＰＵ２１は、ユーザＩＤが「０００００１」のユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在せず、且つ、ユーザＩＤが「０１２３４５」の仲間のユーザの通信端末１０が試合Ａの試合時間帯にスタジアムＡに存在すると判別した場合であっても、ユーザＩＤが「０００００１」のユーザに対して特典を付与する処理を行わなくてもよい。
【００９７】
以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。
例えば、上述した実施形態では、適用されるゲームが野球形式のデジタルカードゲームである場合を想定したが、ゲームの種別は如何なるものでもよい。例えば、サッカーやアメリカンフットボールなどの競技を模したゲームや、映画やテレビドラマなどの動画作品を模したゲームや、架空のキャラクタ（例えばモンスターキャラクタなど）が登場するゲームなどであってもよい。
【００９８】
例えば、上述した実施形態では、ユーザと通信端末１０が１対１の関係である場合について説明したが、これに限られない。例えば、ユーザは、自身の保有する通信端末と異なる他の通信端末（例えば、複数のユーザが共有して使用する通信端末など）を用いてもよい。つまり、上述した実施形態では、現在位置データがユーザＩＤに対応付けられて管理されているので、ユーザが他の通信端末を用いた場合であっても、他の通信端末によって測位された位置情報を当該ユーザのユーザＩＤと対応付けることにより、ユーザの現在位置を認識することができる。
【００９９】
また、上述した実施形態では、通信端末１０のＧＰＳ測位部１８が、通信端末１０の位置情報を取得する構成例を示しているが、これに限定されるものではない。
例えば、通信端末１０が無線電話機能（携帯電話機能またはＰＨＳ（Personal Handy-phone System）機能）を備える場合には、無線電話基地局の有する基地局識別情報を、通信端末１０の位置情報として用いることもできる。すなわち、携帯電話やＰＨＳの各基地局は、所定の通信エリアを有してセル状に配置されており、各基地局から受信した基地局識別情報に基づいて、当該基地局の通信エリア内に通信端末１００が存在することを認識できる。この場合、ＧＰＳ測位部１８を用いたときと比較して、位置情報としての精度が低いものの、基地局識別情報を位置情報として利用することが可能である。
【０１００】
また、例えば、通信端末１０がＷｉ−Ｆｉ（wireless fidelity、登録商標）等の無線ＬＡＮ通信機能を備える場合には、無線通信親機（無線ＬＡＮアクセスポイント又はルータ等）の識別情報（例えば、ＭＡＣ（Media Access Control）アドレスまたはＩＰ（Internet Protocol）アドレス）を位置情報として用いることもできる。すなわち、所定のエリアを無線通信範囲とする無線通信親機（一つまたは複数の無線ＬＡＮアクセスポイント又はルータ等）を設置し、ユーザが、通信端末１０を無線ＬＡＮアクセスポイント等の無線通信親機にアクセスしたときに、通信端末１０が、無線通信親機の識別情報を位置情報として取得するように構成する。この場合、ゲームサーバ２０は、取得した無線通信親機の識別情報に基づいて、当該無線通信親機の通信エリア内に通信端末１０が存在することを認識できるので、無線通信親機の識別情報を位置情報として利用することが可能である。
【０１０１】
さらに、取得手段５３は、例えば、撮像装置（カメラ）が通信端末１０に搭載されている場合、ユーザが所定の場所に存在しないと撮像することができない画像情報やバーコード情報などを位置情報として取得してもよい。また、取得手段５３は、ユーザが所定の場所に存在しないと確認することができない合言葉やパスワード等の文字・数字・記号情報等を位置情報として取得してもよい。
なお、ユーザが所定の場所に存在しないと撮像あるいは確認することができない画像情報等は、その画像情報等を取得したユーザによって他のユーザに転送される場合がある。この場合、所定の場所に存在していない他のユーザが、当該画像情報等を入手することが可能となるため、通信端末１０の正確な現在位置を取得することが困難になる。
そこで、所定の場所で撮像あるいは確認できる画像情報等を所定時間毎（例えば１分毎）に変化させて、撮像あるいは確認した画像情報等に有効期限を設けてもよい。この場合、所定時間毎に変化する画像情報等を生成する情報生成部を備えるとともに、所定の場所を含むエリアを無線通信範囲とする無線通信親機（一つまたは複数の無線ＬＡＮアクセスポイント又はルータ等）を設置し、ユーザが通信端末１０を無線ＬＡＮアクセスポイント等にアクセスすれば、無線ＬＡＮアクセスポイント等に接続された情報生成部から所定時間毎に変化する画像情報等を取得できるように構成してもよい。なお、この構成を実現するために、情報生成部とゲームサーバ２０とは時刻同期をしており、両者は同じアルゴリズムを用いて画像情報等を所定時間毎に変化させながら生成することが好ましい。
【０１０２】
上述した実施形態では、ソーシャルゲームに適用される場合を例として説明したが、これに限られない。例えば、ネットワーク上に置かれたサーバ装置と家庭用オンラインゲーム機とを接続した、いわゆるオンラインゲームシステムにおいても、上述した実施形態と同様に、各ユーザによるゲームの進行を制御できることは言うまでもない。
【０１０３】
例えば、上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、取得手段５３、判別手段５４及び付与手段５５の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、例えば、図２１Ａ，図２１Ｂに示すように、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。通信端末１０は、ゲーム終了時には、ゲームの結果についてのデータをゲームサーバ２０へ送信し、ゲームサーバ２０は、受信したゲームの結果のデータをユーザと関連付けてゲームデータベース３２に記録するようにしてもよい。
【符号の説明】
【０１０４】
１０…通信端末
１１…ＣＰＵ
１２…ＲＯＭ
１３…ＲＡＭ
１４…画像処理部
１５…指示入力部
１６…表示部
１７…通信インタフェース部
１８…ＧＰＳ測位部
１９…バス
２０，２０ａ，２０ｂ…ゲームサーバ
２１…ＣＰＵ
２２…ＲＯＭ
２３…ＲＡＭ
２４…データベースアクセス部
２５…通信インタフェース部
２６…バス
３０，３０ａ，３０ｂ…データベースサーバ
３１…ユーザデータベース
３２…ゲームデータベース
５１…登録手段
５２…ゲーム進行手段
５３…取得手段
５４…判別手段
５５…付与手段
【図１】
0005383936.tif 000002
【図２Ａ】
0005383936.tif 000003
【図２Ｂ】
0005383936.tif 000004
【図３】
0005383936.tif 000005
【図４】
0005383936.tif 000006
【図５】
0005383936.tif 000007
【図６】
0005383936.tif 000008
【図７】
0005383936.tif 000009
【図８】
0005383936.tif 000010
【図９】
0005383936.tif 000011
【図１０Ａ】
0005383936.tif 000012
【図１０Ｂ】
0005383936.tif 000013
【図１１】
0005383936.tif 000014
【図１２】
0005383936.tif 000015
【図１３】
0005383936.tif 000016
【図１４】
0005383936.tif 000017
【図１５】
0005383936.tif 000018
【図１６】
0005383936.tif 000019
【図１７】
0005383936.tif 000020
【図１８】
0005383936.tif 000021
【図１９】
0005383936.tif 000022
【図２０】
0005383936.tif 000023
【図２１Ａ】
0005383936.tif 000024
【図２１Ｂ】
0005383936.tif 000025