JP5918203B2 - ゲーム制御装置、プログラム、ゲームシステム - Google Patents

Description

本発明は、ユーザによるゲームの実行を制御する技術に関する。

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

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

また、ＧＰＳ(Global Positioning System)機能を搭載した通信端末を用いて、通信端末の位置情報を利用するゲームが知られている。例えば、特許文献１には、ユーザが、ＧＰＳ機能を搭載した通信端末を携帯しながら現実世界の所定領域を移動することにより、ゲーム上のアイテムを獲得できるように構成されたゲームが開示されている。

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

特開２００２−２７３０３４号公報

特許文献１に記載のゲームは、ユーザがＧＰＳ機能を搭載した携帯端末を持って、現実世界の所定領域を移動することで仮想アイテムを獲得できるものである。しかしながら、これはユーザ一人が単独で行うものであり、単にアイテムを獲得したか否かを認識できるに留まり、ゲーム性の展開に乏しいものとなっている。

本発明は上述した観点に鑑みてなされたもので、通信端末の位置情報を利用する場合に、興趣性の高いゲームを実現することができるゲーム制御装置、ゲーム制御方法、プログラム、ゲームシステムを提供することを目的とする。

本発明の第１の観点は、ゲーム制御装置である。 当該ゲーム制御装置は、 ユーザの通信端末の位置を示す位置情報を取得する取得手段と、 前記通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別する判別手段と、 前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された後の所定の時刻から第１の所定期間内に前記ユーザに対してゲーム上の第１の特典を付与する付与手段と、 を備える。

ここで、「所定のイベント」とは、例えば、ゲームにおいて模擬された現実世界のイベントであってもよく、具体的には、野球ゲームの場合には野球の試合であってよいし、サッカーゲームの場合にはサッカーの試合であってよいし、音楽ゲームの場合には音楽の演奏であってよい。また、「イベントが行われる所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。さらに、所定領域を複数設けてもよい。例えば、サッカー、アメリカンフットボールの試合等が行われるスタジアムを、対戦する一方のチーム側の領域と、他方のチーム側の領域に分け、両者をそれぞれ所定領域としてもよい。あるいは、野球場の観客席を、例えば、内野席と外野席とで別の所定領域としてもよい。 また、「特典」とは、ゲーム上のポイント若しくはアイテム、ユーザのパラメータの有利な変動、又はゲーム上の有利な効果などであってよい。さらに、「アイテム」とは、例えば、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。また、「アイテム」とは、通信端末が所定領域に存在する場合にのみ与えられる特殊なアイテムであってもよい。さらに、「ゲーム上の有利な効果」とは、例えば、ユーザがゲーム上保有するアイテムのパラメータを上昇させたり、キャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、「ゲーム上の有利な効果」とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作などに応じて消費するゲーム上のポイントの消費量を通常よりも低減させることであってもよいし、ポイントを入手できることであってもよい。なお、仲間を作ることでポイントを入手できる構成が既に設けられている場合には、そのポイントよりも多くのポイントを入手できるようにすればよい。さらにまた、「ゲーム上の有利な効果」とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、アイテムのパラメータが大幅に上昇する確率を上昇させることであってもよい。 また、「所定の時刻」は、通信端末がイベント期間内に所定領域に存在すると判別された直後の時刻であってもよいし、イベント期間の終了時刻、さらにはイベント期間が終了した後の所定時刻であってもよい。

このゲーム制御装置では、ユーザは、自身の通信端末がイベント期間内に所定領域に存在すると判別された後の所定の時刻から第１の所定期間内に第１の特典を得ることができる。この場合、ユーザは、第１の特典を得るために、現実にイベントが行われている所定領域に積極的に出向き、そのイベントに参加または観戦などすることが動機付けられる。そして、このように、イベントが行われている所定領域に出向くことにより、ユーザは、イベントとゲームが連動しているような感覚を得ることができる。これにより、通信端末の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。また、例えば、スタジアムやイベント会場等の運営側にとっては、ユーザを来場させる誘因力あるシステムを構築することができる。

上記ゲーム制御装置において、前記付与手段は、前記イベント期間内の第２の所定期間に前記ユーザに対して前記第１の特典を付与してもよい。 ここで、「イベント期間内の第２の所定期間」とは、例えば、イベントの進行が停止している期間（例えば、攻守が交替する間や、投手や打者などが交替する間など）とすることができる。また、例えば、イベントがサッカーやアメリカンフットボールなどの時間制競技の場合には、競技の進行が停止している期間（例えば、ハーフタイムなどの休憩期間）などであってもよい。 例えば、イベントの進行に注目するあまり、ユーザは、イベントの進行中に第１の特典を得ることが困難になるおそれがある。その一方で、ユーザは、第１の特典を得ることに気を取られ、イベント自体を楽しむことができない場合もある。 このゲーム制御装置では、例えば、イベントの進行の停止中に第２の所定期間が設定されている場合には、ユーザは、イベントの進行の停止中に第１の特典を得ることができる。このため、ユーザの利便性を考慮したゲームを実現することができる。なお、ゲームによっては、イベントの進行の停止中以外であっても、イベントの盛り上がりが比較的低いと想定される期間を第２の所定期間に設定することも考えられる。例えば、イベントが野球の試合の場合には、所定のイニング（例えば1回〜２回）を第２の所定期間として設定するようにしてもよい。

上記ゲーム制御装置において、前記判別手段は、前記イベント期間内で、前記通信端末についての判別を複数回行ってもよい。ここで、判別手段は、通信端末が所定領域に存在するか否かを、所定時間（例えば３０分や１時間）が経過する毎に判別してもよい。 例えば、ユーザの通信端末が、イベント期間内に所定領域に存在すると１回判別されると、当該ユーザに対して第１の特典が付与されるように構成されている場合、ユーザは、前記第１の特典を得るために、例えばイベントの最初のみ参加または観戦などしただけで、直ちにイベント会場を去るといったことが考えられる。このような行為は、ユーザが自らの利益を得ることのみを目的としてイベントに参加又は観戦などすることになるため、好ましくない。 このゲーム制御装置によれば、通信端末についての判別をイベント期間内で複数回行うことにより、例えば、ユーザの通信端末がイベント期間内に所定領域に存在しないと少なくとも１回判別された場合には、当該ユーザに対して第１の特典を付与しない仕組みとすることができる。また、通信端末がイベント期間内に所定領域に存在すると判別された回数に応じた第１の特典を付与してもよい。例えば、通信端末がイベント期間内に所定領域に存在すると判別された回数が多いほど、すなわち、ユーザの通信端末がより長く所定領域に存在すると判断された場合に、より多くの特典を付与してもよい。これにより、ユーザは、第１の特典を得るために、イベント期間中には所定領域に留まることが動機付けられる。したがって、上記の行為を抑制することができ、興趣性が高く、また、ユーザにイベント参加、観戦等を十分行ってもらえることにより、イベント運営側にとっても有益なゲームを実現することができる。

上記ゲーム制御装置において、ユーザ同士を関係付ける関係付け手段を備え、前記取得手段は、互いに関係付けられた複数のユーザの通信端末について前記位置情報を取得し、前記付与手段は、前記互いに関係付けられた複数のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記互いに関係付けられた
複数のユーザに対してゲーム上の第２の特典を付与してもよい。ここで、「第２の特典」の内容は、「第１の特典」の内容と同じであってもよいし、異なっていてもよい。 また、所定領域が複数ある場合に、同一の所定領域内に存在する、互いに関係付けられた複数のユーザの通信端末の数に応じて、第２の特典を付与してもよい。 あるいは、取得した位置情報から、互いに関係付けられたユーザ同士の通信端末の距離を求め、求めた距離に応じて第２の特典を付与してもよい。 このゲーム制御装置によれば、互いに関係付けられた（仲間関係にある）複数のユーザの通信端末がイベント期間内に所定領域に存在する場合に、当該複数のユーザに対して第１の特典だけではなく第２の特典も付与される。これにより、ユーザは、第２の特典をさらに得るために、自身と関係付けられた他のユーザと所定領域に出向くことが動機付けられる。これにより、ゲーム上及び現実世界のユーザ間の交流を促進することができるため、ソーシャル性の高いゲームを実現することができる。

上記ゲーム制御装置において、前記付与手段は、前記ユーザと関係付けられた他のユーザのうち、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された他のユーザの数に応じて、前記第２の特典を変動させてもよい。 例えば、通信端末がイベント期間内に所定領域に存在すると判別された仲間のユーザ（ユーザと関係付けられた他のユーザ）が多いほど、ユーザと仲間のユーザ（所定領域に存在している仲間のユーザ）に対して多くの第２の特典（例えば、多くのポイント、価値の高いアイテム、ユーザのパラメータの有利な変動、より有利なゲーム上の効果など）が付与されるように構成されてもよい。この場合、ユーザは、多くの第２の特典を得るために、より多くの他のユーザと関係付けられる（仲間になる）こと、及び仲間のユーザと所定領域に出向くことが動機付けられる。これにより、仲間関係の構築が活性化され、ソーシャル性のさらなる向上が期待できる。

上記ゲーム制御装置において、付与手段は、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別されてから経過した時間に応じて、前記第１の特典を変動させてもよい。 例えば、ユーザの通信端末がイベント期間内に所定領域に存在すると判別されてから経過した時間が長くなるほど、ユーザに対して付与される第１の特典が少なくなる（例えば、ポイントの量、アイテムの価値、又はゲーム上の効果が低減する等）ように構成されてもよい。また、所定時間経過後には（例えばイベント終了時から６時間経過後には）、第１の特典が付与されないようにしてもよい。 この場合、ユーザは、多くの第１の特典を得るために、イベント期間内に所定領域でゲームをプレイするか、若しくはゲームを極力早めにプレイすることが動機付けられる。これにより、イベントの進行中にゲームをプレイすることが困難な場合であっても、イベント終了後の早いタイミングでゲームをプレイすることによって第１の特典が付与され得ることから、ユーザの利便性を考慮したゲームを実現することができる。

上記ゲーム制御装置において、所定の操作入力に関する情報に基づいて、ユーザがゲーム上保有するポイントが消費されるとともに前記ゲームが進行されるように制御し、前記第１の特典は、前記ポイントの消費量を、前記通信端末が前記イベント期間内に前記所定領域に存在すると前記判別手段によって判別されなかった場合よりも低減することであってもよい。 ここで、「所定の操作入力に関する情報」とは、ゲーム制御装置に対して直接操作入力されることにより得られる情報に限られず、例えば、ゲーム制御装置にアクセス可能な外部装置に対して操作入力されることにより得られる情報であってもよい。 例えば、ポイントの量が所定の閾値より低いとゲームの進行が制限されるように、当該ゲームが制御される場合、第１の特典がユーザに付与されると、第１の所定期間内における１回の操作当たりのポイントの消費量が低減される。このため、ユーザは、第１の所定期間において、操作回数を通常（つまり、ユーザの通信端末がイベント期間内に所定領域に存在しない場合）よりも増やすことができるので、ゲームの進行度を通常よりも早く上げることができるというメリットが得られる。ユーザは、このメリットを得るために、イベントが行われている所定領域に積極的に出向くことが動機付けられる。 上記ゲーム制御装置において、ユーザに付与するオブジェクトを抽選により決定する抽選手段を備え、 前記第１の特典は、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された後の所定の時刻から第１の所定期間、前記所定領域に存在すると判別されなかった場合よりも、ユーザに対して希少価値の高いオブジェクトを付与する確率を高くすることであってもよい。 本発明において「オブジェクト」とは、例えば、ゲーム上のキャラクタやアイテム等を含む。キャラクタは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカードに表示されているものをも含む。 このゲーム制御装置によれば、ユーザは、希少価値の高いオブジェクトを得るために、イベントが行われている所定領域に積極的に出向くことが動機付けられる。

本発明の第２の観点は、ゲーム制御装置におけるゲーム制御方法であって、 ユーザの通信端末の位置を示す位置情報を取得するステップと、 前記通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別するステップと、 前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された後の所定の時刻から第１の所定期間内に前記ユーザに対してゲーム上の第１の特典を付与するステップと、 を備える。

本発明の第３の観点は、ゲームの実行を制御するために、コンピュータに、 ユーザの通信端末の位置を示す位置情報を取得する機能、 前記通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別する機能、及び 前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された後の所定の時刻から第１の所定期間内に前記ユーザに対してゲーム上の第１の特典を付与する機能、 を実現させるためのプログラムである。

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

本発明の第４の観点は、通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、 ユーザの通信端末の位置を示す位置情報を取得する取得手段、 前記通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、前記位置情報に基づいて判別する判別手段、 前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された後の所定の時刻から第１の所定期間内に前記ユーザに対してゲーム上の第１の特典を付与する付与手段、 の各手段を、前記通信端末又は前記サーバのいずれか一方が備える。

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(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分）が経過する度に１ポイントずつ回復（増加）する。

ゲーム進行手段５２が試合処理を実行する機能は、例えば以下のとおり実現される。図１１は、ゲーム進行手段５２の機能により実現される、ユーザの通信端末１０上に表示されるウェブページの例を示す図である。

あるユーザＩＤに対応するユーザの通信端末１０のトップページ上でメニューｍ３（図８参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、そのユーザＩＤの試合相手の複数の候補を、ユーザデータベース３１に含まれる他のユーザＩＤの中からランダムに決定する。このとき、試合相手の候補の技能レベルは、メニューｍ３を選択操作したユーザと同一の技能レベルであることが好ましい。ＣＰＵ２１は、複数の試合相手の候補のリストからいずれかの候補を選択可能とするウェブページを表示するためのＨＴＭＬデータをユーザの通信端末１０宛に送信する。 複数の試合相手の候補のリストからいずれかの候補を選択する操作がユーザによってなされると、図１１のウェブページＰ６に示すように、試合相手（対戦相手）ととともに試合開始の指示を促すメニューを含むウェブページが表示される。ここで、ユーザが「試合開始」のメニューを選択すると、ＣＰＵ２１は試合結果を決定する処理を行う。試合結果を決定するに当たって、ＣＰＵ２１は、データベースアクセス部２４を介してデータベースサーバ３０のユーザデータベース３１にアクセスし、対象となるユーザＩＤの運営ポイントが試合の実行に必要とする所定量以上である場合に、運営ポイントからその所定量を減少させるとともに、試合相手となる２つのユーザＩＤに対応付けられた複数の選手カードの能力を示すパラメータを読み出す。そして、ＣＰＵ２１は、読み出したパラメータに基づいてユーザ間の試合結果を決定する。

試合結果の決定方法は、選手カードの能力値がその勝敗に影響を与える方法である限り如何なる方法を採ることができる。例えば、試合相手となる２人のユーザが保有する複数の選手カードのパラメータの合計値を比較し、合計値が大きな方のユーザが高い確率（例えば、６０〜９０％の範囲内の所定の確率）をもって勝利するように設定してもよい。この勝率は、能力値の差が大きいほど高い確率としてもよい。このとき、図６に示したように、能力値を示すパラメータの項目が複数存在する場合には、各選手カードのパラメータを代表する値として、各項目の
パラメータの値に対して所定の重み付け（例えば、図６の例では、「打力」を０．４、「走力」を０．２、「守備力」を０．４の重み付けにする等）をもって総合的な能力値を設定してもよい。

ＣＰＵ２１は、試合結果を決定すると、試合結果をユーザに通知するために、その試合結果を含むウェブページを表示させるＨＴＭＬデータを、「試合開始」のメニューの選択操作を行ったユーザの携帯端末１０宛に送信する。「試合開始」のメニューを選択する操作が行われてから、試合結果を含むウェブページが表示されるまでの時間は極めて短時間（例えば数秒）であるため、ユーザは、簡易な操作のみで極めて短期間で試合結果を知ることができる。図１１のウェブページＰ７は、試合処理の実行によって表示されるウェブページを示す図である。図１１のウェブページＰ７では、例えばスコア等を含む試合結果が表示される。

［抽選処理］ ゲーム進行手段５２は、抽選によって選手カードをユーザに付与することを可能とする抽選処理を実行する。抽選処理は、好ましくは、選手カードを抽選箱の中から１枚を取り出す（引く）ような演出を経て実行される。抽選によって出現する選手カードは基本的にランダムであるが、レア度の高い選手カード（いわゆるレアカード）が抽選で出現する確率は非常に低く設定されている。抽選処理は、所定量のエールポイントと引き換えに行われてもよい。

以上、ゲーム進行手段５２の主要な機能（スカウト処理、強化処理、試合処理、及び抽選処理）について説明した。ゲーム進行手段５２は、メニューの選択操作（所定の操作入力）に関する情報に基づいて、ユーザがゲーム上保有するポイントが消費されるとともにゲームが進行されるように、ゲームを制御する。ここで、「所定の操作入力に関する情報」とは、ゲーム制御装置に対して直接操作入力されることにより得られる情報に限られず、例えば、ゲーム制御装置にアクセス可能な外部装置に対して操作入力されることにより得られる情報であってもよい。 ゲーム進行手段５２はさらに、ユーザが保持する各ポイントあるいは選手数に基づいて、ユーザによって選択されたメニューに応じた機能（スカウト処理、強化処理、試合処理、及び抽選処理）が実行できるか否かを判定し、選択されたメニューに応じた機能が実行できない場合には、機能が実行できないことをユーザに報知するためのテキストを含むページを通信端末１０上に表示する。例えば、ポイントが所定の閾値より低い場合にゲームの進行が制限されるように構成されている場合、具体的には、１回の探索に行動力が「５」必要となるエリアについてスカウト処理を実行しようとする場合に、ユーザの行動ポイントが「３」のときには、スカウト処理が実行できないため、例えば「行動ポイントが足りません。行動ポイントは３分ごとに１回復します。ゆっくり待ちましょう。」などといったテキストを表示させる。このとき、ゲームサーバ２０のＣＰＵ２１は、ユーザデータベース３１にアクセスして、ユーザの行動ポイントのデータと、探索対象のエリアに要する行動力（既定値）との比較処理を行って、スカウト処理の実行可否を判定する。

ここで、本実施形態のゲームでは、ユーザの通信端末１０が、野球の試合が行われる試合時間帯に当該試合が行われる野球場（スタジアム）内に存在する場合に、当該ユーザに対して特典を付与する処理が行われるようになっている。この処理は、取得手段５３、判別手段５４及び付与手段５５によって実行される。以降では、各手段の詳細について説明する。

取得手段５３は、ユーザの通信端末１０の現在位置（位置）を示す位置情報を取得する機能を備える。取得手段５３の機能は、以下のように実現される。 例えば、ユーザが、図８に示すトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューを選択すると、通信端末１０のＣＰＵ１１は、ウェブページを表示するためのＨＴＭＬデータの送信要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０に送信する。 一方、ゲームサーバ２０のＣＰＵ２１は、ＨＴＭＬデータの送信要求メッセージを、通信インタフェース部２５を介して受信すると、位置情報の送信要求メッセージを、通信インタフェース部２５を介して通信端末１０に送信する。 通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、ユーザＩＤと対応付けて、ゲームサーバ２０に送信する。 ゲームサーバ２０のＣＰＵ２１は、位置情報を受信する（取得する）毎に、取得した位置情報をユーザデータベース３１内の現在位置データに記録する。図１２に現在位置データの構成例を示す。図１２に示すように、現在位置データは、複数のユーザ（ユーザＩＤ）ごとに設けられている。現在位置データは、位置情報の取得日時（位置情報に含まれる測位時刻）、位置情報に含まれる緯度及び経度が、位置情報を取得する毎に記述されたデータである。そして、ＣＰＵ２１は、ユーザが選択したメニューに応じたウェブページを表示するためのＨＴＭＬデータを生成し、通信端末１０宛に送信する。

なお、上述した取得手段５３の機能の実現例では、ゲームサーバ２０のＣＰＵ２１は、図８に示すトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューが選択された場合に位置情報の送信要求メッセージを送信することとしているが、この場合に限られない。例えば、ゲームサーバ２０のＣＰＵ２１は、位置情報の送信要求メッセージを送信するためのメニューを予め設定（例えば、位置情報の送信要求メッセージを送信するのは、メニューｍ１が選択操作された場合のみ等）してもよいし、各メニューｍ１〜ｍ５の選択回数が所定回数（例えば５回）に達する毎に位置情報の送信要求メッセージを送信してもよい。また、ゲームサーバ２０のＣＰＵ２１は、例えば、図８に示すトップページを表示するためのＨＴＭＬデータの送信要求メッセージを受信した場合に、位置情報の送信要求メッセージを送信してもよいし、通信端末１０との間で所定の認証処理（例えば、ログイン認証など）を行う際に、位置情報の送信要求メッセージを送信してもよい。

判別手段５４は、ユーザの通信端末１０が、野球の試合（所定のイベント）が行われる試合時間帯（イベント期間内）に当該試合が行われるスタジアム（所定領域）内に存在するか否かを、位置情報に基づいて判別する機能を備える。ここで、「試合時間帯」には、試合開始から試合終了までの時間だけではなく、例えば、試合開始前の練習時間や試合終了後のファンサービスの時間等が含まれてもよい。また、「所定のイベント」とは、例えば、ゲームにおいて模擬された現実世界のイベントであってもよく、具体的には、野球ゲームの場合には野球の試合（イベント）であってよいし、サッカーゲームの場合にはサッカーの試合（イベント）であってよいし、音楽ゲームの場合には音楽の演奏（イベント）であってよい。さらに、「イベントが行われる所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。

判別手段５４の機能は、以下のようにして実現できる。 ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０の位置情報を取得し、取得した位置情報を現在位置データに記録すると、当該ユーザの通信端末１０が、野球の試合の試合時間帯にスタジアム内に存在するか否かを判別する。具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザのユーザＩＤに対応する現在位置データを参照する。そして、ＣＰＵ２１は、現在位置データに記録された位置情報のうち最新の位置情報の緯度及び経度がスタジアム内に含まれるか否か、及び、最新の位置情報の取得日時が野球の試合時間帯に含まれるか否かを判別する。なお、通信端末１０の現在位置がスタジアム内に存在するか否かを判別するために、スタジアムの外縁の緯度及び経度は、ゲームデータベース３２に予め記録されていてもよい。また、野球の試合時間帯などの情報（例えば、練習開始時刻、試合開始時刻、各イニングの開始及び終了時刻、試合終了時刻、試合終了後のファンサービスの開始及び終了時刻など）は、ゲームデータベース３２に逐次記録されるようにしてもよい。 最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、ＣＰＵ２１は、ユーザの通信端末１０が、試合時間帯にスタジアム内に存在すると判別する。

付与手段５５は、ユーザの通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された後、所定の時刻から第１の所定期間内に前記ユーザに対してゲーム上の特典（第１の特典）を付与する機能を備える。 ここで、「ユーザに対して特典を付与する」とは、特典（例えば、ポイント、アイテムなど）に関する情報をユーザのユーザＩＤに対応付けた状態で所定の記憶装置（例えばユーザデータベース３１など）に記憶させることであってよい。また、所定の記憶装置は、例えばゲームサーバ２０に設けられていてもよいし、ユーザの通信端末１０などに設けられていてもよい。 また、「特典」とは、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。さらに、「アイテム」とは、例えば、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。また、「アイテム」とは、通信端末１０がスタジアムに存在する場合にのみ与えられる特殊なアイテムであってもよい。さらに、「ゲーム上の有利な効果」とは、例えば、ユーザがゲーム上保有するアイテム（例えば選手カード）のパラメータを上昇させたり、キャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、「ゲーム上の有利な効果」とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作に応じて消費するゲーム上の各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の消費量を通常よりも低減させることであってもよいし、ポイントを入手できることであってもよい。なお、仲間を作ることでポイントを入手できる構成が既に設けられている場合には、そのポイントよりも多くのポイントを入手できるようにすればよい。さらに、「ゲーム上の有利な効果」とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、強化処理において選手カードの能力値が大幅に上昇する確率を上昇させることであってもよい。 また、「ゲーム上の有利な効果」とは、ユーザ毎の行動ポイント、運営ポイントの上限値を、通常の値である第１の値から、通常よりも高い第２の値まで上昇させることであってもよい。この場合、行動ポイント、運営ポイントの上限値を第２の値まで上昇させるだけでなく、すなわち、ポイントの枠を大きくするだけでなく、実際にユーザが保有している現状の行動ポイント、運営ポイントを第２の値まで上昇させてもよい。行動ポイント、運営ポイントの上限値を上昇させた場合、第１の所定期間が経過するまで上昇させた上限値を維持してもよい。例えば、３日間のみ行動ポイント、運営ポイントを第２の値まで上昇させ、その後は第１のポイントに戻すようにしてもよい。あるいは、ゲームの実行により行動ポイント、運営ポイントが第１の値またはそれ以下にまで低減したときに、上限値を元（第１の値）に戻してもよい。 例えば、通常の行動ポイントの上限値が８０（第１の値）、通常の運営ポイントの上限値が１００（第１の値）であるときに、ユーザが試合時間帯にスタジア
ムにいた場合、行動ポイントの上限値を１００（第２の値）、運営ポイントの上限値を１２０（第２の値）でまで上昇させてもよい。その際、行動ポイントや運営ポイントを消費していて、仮に両方とも１０であったとしても、行動ポイントを１００（第２の値）まで、運営ポイントを１２０（第２の値）まで上昇させてもよい。その後、行動ポイントや運営ポイントを消費し、行動ポイントが８０（第１の値）を下回ったときや、運営ポイントが１００（第１の値）を下回ったときに、上限値を元に戻してもよい。 また、「ゲーム上の有利な効果」とは、例えば、所定時間の経過により各種ポイントが付与される場合において、各種ポイントの量を所定の割合だけ増加させることであってもよい。 また、「ゲーム上の有利な効果」とは、例えば、抽選処理において、レア度の高い選手カードが出現する確率を通常よりも高くすることであってもよい。抽選処理を実行するゲーム進行手段５２は、抽選手段の一例である。

付与手段５５の機能は、以下のようにして実現できる。なお、以下では、ユーザに付与される特典が、各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の消費量を通常（つまり、ユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別されない場合）よりも低減させることである場合を一例として説明する。ここで、各種ポイントのうち少なくとも一種類のポイントの消費量が低減されるようにしてもよい。 例えば、ユーザの保有するポイントの量が所定の閾値より低い場合にゲームの進行が制限されるように構成されている場合、特典がユーザに付与されると、後述する特典付与期間内（第１の所定期間内）における１回の操作当たりのポイントの消費量が低減される。このため、ユーザは、特典付与期間において、操作回数を通常よりも増やすことができるので、ゲームの進行度を通常よりも早く上げることができるというメリットが得られる。ユーザは、このメリットを得るために、野球の試合が行われているスタジアムに積極的に出向くことが動機付けられる。

ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０が、試合時間帯にスタジアム内に存在すると判別すると、当該ユーザに対して特典を付与する処理を行う。ここで、特典を付与する処理について具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザデータベース３１内の特典付与データに所定の情報を記録する。図１３に特典付与データの構成例を示す。図１３に示すように、特典付与データは、複数のユーザ（ユーザＩＤ）ごとに設けられており、特典が付与された日時である特典付与日時と、特典が付与される期間である特典付与期間（第１の所定期間）などが含まれるデータである。特典付与期間に記述されるデータは、例えば、特典付与日時からの所定の期間（例えば、特典付与日時から２４時間など）であってもよいし、特典の付与が終了する時期（例えば、試合日の翌日の午前０時までなど）であってもよい。また、特典付与期間の終了時期は、例えば、試合時間帯以内（試合中）の所定のタイミングであってもよいし、試合時間帯以降（試合が終了してから所定時間経過後）のタイミングであってもよい。ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別すると、当該ユーザのユーザＩＤに対応する特典付与データに、特典付与日時（ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別されたときの日時）及び特典付与期間を記録する。

ＣＰＵ２１は、上述したスカウト処理、強化処理、試合処理及び抽選処理を実行する際に、ユーザのユーザＩＤに対応する特典付与データを参照し、各処理を実行するタイミングが特典付与期間内である場合には、各処理の実行によって消費される各種ポイントの消費量を通常よりも低減させる。各種ポイントの消費量を低減する割合は任意に設定してもよく、この割合は予めＲＯＭ２２やＲＡＭ２３などに記憶されてもよい。また、特典付与期間内の各種ポイントの消費量は０に設定されてもよい。 ＣＰＵ２１は、図１４に示すウェブページを表示するためのＨＴＭＬデータを生成し、通信端末１０宛に送信する。図１４に示すウェブページの例では、特典の付与が終了する時期（図の例ではＸ時）までの間の各種ポイントの消費量（図の例では０）を表す情報などが含まれる。

なお、特典としてアイテムやポイントなどをユーザに付与する場合には、ＣＰＵ２１は、特典を付与する処理において、付与対象となるユーザのユーザＩＤと、付与されるポイントやアイテムとを関連付けてユーザデータベース３１に記憶するようにしてもよい。例えば、特典として所定量の強化ポイントがユーザに付与される場合には、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（所定量のポイントを加算する処理）を行ってよい。また、特典としてアイテムやポイントなどがユーザに付与される場合には、特典付与期間内にアイテムやポイントなどが付与される回数は、１回であってもよいし、複数回であってもよい。 また、特典が、ユーザの保有する選手カードの能力値を、特典付与期間の間上昇させることである場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける保有カードの能力値を所定の割合だけ加算する処理を行ってよい。この場合、ＣＰＵ２１は、特典付与期間が終了すると、保有カードの能力値を元の値に戻す。

（６）本実施形態のゲーム制御装置の主要な処理のフロー 次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１５のフローチャートを参照して説明する。図１５のフローチャートは、主として取得手段５３、判別手段５４及び付与手段５５によって実行される処理である。

先ず、図８に示すトップページ上でメニューｍ１〜ｍ５のうち何れかのメニューを選択すると、通信端末１０のＣＰＵ１１は、ウェブページを表示するためのＨＴＭＬデータの送信要求メッセージを、通信インタフェース部１７を介してゲームサーバ２０に送信する。一方、ゲームサーバ２０のＣＰＵ２１は、ＨＴＭＬデータの送信要求メッセージを、通信インタフェース部２５を介して受信すると（ステップＳ１００：ＹＥＳ）、位置情報の送信要求メッセージを、通信インタフェース部２５を介して通信端末１０に送信する（ステップＳ１１０）。

次に、通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、ユーザＩＤと対応付けて、ゲームサーバ２０に送信する。 一方、ゲームサーバ２０のＣＰＵ２１は、位置情報を通信端末１０から受信する（取得する）と（ステップＳ１２０：ＹＥＳ）、取得した位置情報をユーザデータベース３１内の現在位置データに記録する（ステップＳ１３０）。なお、ステップＳ１２０において、通信端末１０から位置情報を受信しない状態で所定時間経過した場合には（ステップＳ１２０：ＮＯ）、ＣＰＵ２１は、処理を終了してもよい。

次に、ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０が、野球の試合の試合時間帯にスタジアム内に存在するか否かを判別する。ＣＰＵ２１は、現在位置データを参照し、最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別する。そして、ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別した場合（ステップＳ１４０：ＹＥＳ）、当該ユーザに対して特典を付与する処理を行う（ステップＳ１５０）。具体的に説明すると、ＣＰＵ２１は、ユーザデータベース３１にアクセスし、ユーザのユーザＩＤに対応する特典付与データに特典付与日時及び特典付与期間を記録する。また、ＣＰＵ２１は、特典を付与したことを通知するためのウェブページを表示させるＨＴＭＬデータを生成して、ユーザの通信端末１０に送信する（ステップＳ１６０）。この場合、ユーザの通信端末１０上には、図１４に例示したウェブページが表示される。 また、ステップＳ１４０において、ユーザの通信端末１０が試合時間帯にスタジアム内に存在しないと判別した場合（ステップＳ１４０：ＮＯ）、ＣＰＵ２１は、処理を終了してもよい。

なお、ユーザに付与される特典が、各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の消費量を通常よりも低減させることである場合、ＣＰＵ２１は、スカウト処理、強化処理、試合処理及び抽選処理を実行する際に、ユーザのユーザＩＤに対応する特典付与データを参照する。そして、各処理を実行するタイミングが特典付与期間内である場合には、各処理の実行によって消費される各種ポイントの消費量を通常よりも低減させる。

上述したように、実施形態のゲーム制御装置によれば、ユーザは、自身の通信端末１０が試合時間帯にスタジアムに存在すると判別された場合に、試合時間帯を含む特典付与期間内に特典を得ることができる。この場合、ユーザは、特典を得るために、現実に野球の試合が行われているスタジアムに積極的に出向き、野球の試合を観戦することが動機付けられる。そして、このように、野球の試合が行われているスタジアムに出向くことにより、ユーザは、野球の試合とゲームが連動しているような感覚を得ることができる。これにより、通信端末の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。また、例えば、スタジアムやイベント会場等の運営側にとっては、ユーザを来場させる誘因力あるシステムを構築することができる。

（７）変形例 （７−１）変形例１ 上記実施形態において、付与手段は、試合時間帯（イベント期間内）の第２の所定期間にユーザに対して特典（第１の特典）を付与してもよい。 ここで、「イベント期間内の第２の所定期間」とは、例えば、野球の試合（イベント）の進行が停止している期間（例えば、攻守が交替する間や、投手や打者などが交替する間など）とすることができる。また、例えば、イベントがサッカーやアメリカンフットボールなどの時間制競技の場合には、競技の進行が停止している期間（例えば、ハーフタイムなどの休憩期間）などであってもよい。 例えば、試合の進行に注目するあまり、ユーザは、試合の進行中に特典を得ることが困難になるおそれがある。その一方で、ユーザは、特典を得ることに気を取られ、野球の試合を楽しむことができない場合もある。 本変形例では、例えば、試合の進行の停止中に第２の所定期間が設定されている場合には、ユーザは、試合の進行の停止中に特典を得ることができる。このため、ユーザの利便性を考慮したゲームを実現することができる。なお、ゲームによっては、イベントの進行の停止中以外であっても、イベントの盛り上がりが比較的低いと想定される期間を第２の所定期間に設定することも考えられる。例えば、イベントが野球の試合の場合には、所定のイニング（例えば1回〜２回）を第２の所定期間として設定するようにしてもよい。

本変形例における付与手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１３に示した特典付与データの特典付与期間に試合時間帯内の所定の時間帯（第２の所定期間）を記録してもよい。ここで、前記所定の時間帯には、例えば、所定のイニング（例えば７回や１〜３回など）の時間帯が記録されてもよいし、試合の進行が停止している時間帯（例えば、攻守が交替する間や、投手や打者などが交替する間など）が記録されてもよい。

（７−２）変形例２ 上記実施形態において、判別手段５４は、試合時間帯（イベント期間内）で、通信端末１０についての判別を複数回行ってもよい。ここで、判別手段５４は、通信端末１０がスタジアム（所定領域
）に存在するか否かを、所定時間（例えば３０分や１時間など）が経過する毎に判別してもよい。 例えば、ユーザの通信端末１０が、試合時間帯にスタジアムに存在すると１回判別されると、当該ユーザに対して特典が付与されるように構成されている場合、ユーザは、特典を得るために、例えば試合の最初のみ観戦しただけで、直ちにスタジアムを去るといったことが考えられる。このような行為は、ユーザが自らの利益を得ることのみを目的として観戦することになるため、好ましくない。 本変形例によれば、通信端末１０についての判別を試合時間帯で複数回行うことにより、例えば、ユーザの通信端末１０が試合時間帯にスタジアムに存在しないと少なくとも１回判別された場合には、当該ユーザに対して特典を付与しない仕組みとすることができる。また、通信端末１０が試合時間帯にスタジアムに存在すると判別された回数に応じた特典を付与してもよい。例えば、通信端末１０が試合時間帯にスタジアムに存在すると判別された回数が多いほど、すなわち、ユーザの通信端末がより長く所定領域に存在すると判断された場合に、より多くの特典を付与してもよい。これにより、ユーザは、特典を得るために、試合時間帯においてはスタジアムに留まることが動機付けられる。したがって、上記の行為を抑制することができ、興趣性が高く、また、ユーザにイベント参加、観戦等を十分行ってもらえることにより、イベント運営側にとっても有益なゲームを実現することができる。

本変形例における判別手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、所定時間（例えば３０分や１時間など）が経過する毎に通信端末１０から受信した位置情報に基づいて、通信端末１０の現在位置が試合時間帯のスタジアムに存在するか否かを判別すればよい。

（７−３）変形例３ 上記実施形態において、ユーザ同士を関係付ける登録手段５１を備え、取得手段５３は、仲間関係にある（互いに関係付けられた）複数のユーザの通信端末１０について位置情報を取得し、付与手段５５は、当該仲間関係にある複数のユーザの通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された場合に、当該仲間関係にある複数のユーザに対してゲーム上の特典（第２の特典）を付与してもよい。ここで、「第２の特典」の内容は、「第１の特典」の内容と同じであってもよいし、異なっていてもよい。 本変形例によれば、仲間関係にある複数のユーザの通信端末１０が試合時間帯にスタジアムに存在する場合に、当該複数のユーザに対して第１の特典だけではなく第２の特典も付与される。これにより、ユーザは、第２の特典をさらに得るために、自身と関係付けられた他のユーザ（仲間のユーザ）とスタジアムに出向くことが動機付けられる。これにより、ゲーム上及び現実世界のユーザ間の交流を促進することができるため、ソーシャル性の高いゲームを実現することができる。

本変形例における各手段の機能は、以下のようにして実現される。なお、ここでは、ユーザと、当該ユーザの仲間のユーザとが、ともにログインしている状態（ゲームをプレイ中の状態）にある場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０からＨＴＭＬデータの送信要求を受信すると、位置情報の送信要求を、ユーザ及び当該ユーザの仲間のユーザの通信端末１０に送信する。なお、ＣＰＵ２１は、位置情報の送信要求の送信に先立ち、ユーザのユーザＩＤに対応する仲間のユーザＩＤをユーザデータから抽出する。ＣＰＵ２１は、各ユーザの通信端末１０から位置情報を取得すると、各ユーザの通信端末１０が試合時間帯にスタジアムに存在するか否かを判別する。そして、ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアムに存在し、且つ、当該ユーザの仲間のユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別した場合に、ユーザ及び当該ユーザの仲間のユーザ（スタジアムにいる仲間のユーザ）に対して特典を付与する処理を行う。 なお、スタジアム全域を１つの所定領域とする代わりに、複数の所定領域に分けてもよい。例えば、スタジアムの観客席を、内野席と外野席とで別の所定領域としてもよいし、チーム毎に所定領域を設定してもよいし、さらに細かい領域に分けてもよい。 また、所定領域が複数ある場合に、同一の所定領域内に存在する、互いに関係付けられた仲間のユーザの通信端末１０の数に応じて特典を付与してもよい。これにより、例えば複数の所定領域（例えば味方チーム側のスタンド、敵チーム側のスタンド）のうち、同一チームを応援している味方チーム側のスタンドにいる仲間の数が多ければ多いほど、多くの特典が付与されることになり、ユーザ同士の親近感が高まることが期待される。あるいはまた、ユーザ同士でスタジアム観戦に行こうとする動機づけを与えることができ、ゲームコミュニティの活性化を図ることができる。 あるいは、取得した位置情報から、複数のユーザの通信端末１０同士の距離を求め、求めた距離に応じて第２の特典を付与してもよい。この場合、同じゲームを行っているユーザであるという点に着目して、複数のユーザについては必ずしも仲間同士でなくてもよい。

（７−４）変形例４ 上記実施形態において、付与手段５５は、ユーザの仲間のユーザ（関係付けられた他のユーザ）のうち、通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された仲間のユーザの数に応じて、特典（第２の特典）を変動させてもよい。 例えば、通信端末１０が試合時間帯にスタジアムに存在すると判別された仲間のユーザが多いほど、ユーザと仲間のユーザ（所定領域に存在している仲間のユーザ）に対して多くの特典（例えば、多くのポイント、価値の高いアイテム、より有利なゲーム上の効果など）が付与されるように構成されてもよい。この場合、ユーザは、多くの特典を得るために、より多くの他のユーザと関係付けられる（仲間になる）こと、及び仲間のユーザとスタジアムに出向くことが動機付けられる。これにより、ソーシャル性のさらなる向上が期待できる。 また、第２の特典として、通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された仲間のユーザの数に応じて、親密度のパラメータを上昇させてもよい。また、プレゼントやメッセージの送付回数に応じてユーザに付与されるエールポイントを通常よりも増やしてもよい。

本変形例における付与手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１６に例示した設定例に基づき構成された設定用データをゲームデータベース３２に予め格納してもよい。図１６に示す設定例では、通信端末１０がスタジアム（所定領域）に存在すると判別された仲間のユーザ数が多いほど、ユーザ及び当該ユーザの仲間のユーザ（スタジアムに存在している仲間のユーザ）に対して多くの特典（図１６の例ではポイント消費量の低減する割合が増大する）が付与されるように設定されている。 ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアムに存在し、且つ、当該ユーザの仲間のユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別した場合に、通信端末１０がスタジアムに存在すると判別された仲間のユーザ数を算出する。そして、ＣＰＵ２１は、算出された仲間のユーザ数と、設定用データに設定された仲間のユーザ数とに応じて特典を決定してもよい。

例えば、図１６に示す設定例では、通信端末１０がスタジアムに存在すると判別された仲間のユーザが１名である場合、ポイント消費量が５％低減されるという特典がユーザに付与される。従って、ユーザにとっては、ゲームを有利に進めることになる。具体的に説明すると、図９に示すスカウト処理の場合、通常であれば探索を行うことで行動ポイントを消費し（例えば１回の探索で５ポイント）、探索を続けることによりユーザが保有する行動ポイントが無くなると、それ以上、探索を実行することができない。 一方、本変形例では、特典付与期間において、探索１回当たりの行動ポイントの消費量が５％低減されるので、その分、ユーザは通常よりも長く探索を実行することができる。また、通信端末１０がスタジアムに存在すると判別された仲間のユーザが２〜５名の場合、ポイントの消費量がより多く（１０％）低減される。従って、探索をさらに長く行えることになる。さらに、通信端末１０がスタジアムに存在すると判別された仲間のユーザが６〜１０名の場合、ポイントの消費量がさらに多く（５０％）低減される。このため、ユーザは通常よりもかなり長く探索を実行できることになる。 このように、スタジアム内にいるユーザの仲間が多ければ多いほど、ユーザは、ゲーム進行を有利に運ぶことができるというメリットを得ることができる。このメリットは、ユーザの仲間も同様に享受し得るため、仲間同士で一緒にスタジアム観戦に行くことが動機付けられ、ゲームの新たな遊戯性が実現される。 さらにまた、仲間の少ないユーザは、上記メリットを得るために、仲間を増やそうとする動機付けが与えられるので、ゲームにおける仲間構築が活性化される。

なお、ポイント消費量の低減率には上限を設けても良い。これは、例えば、低減率を１００％、即ち、行動ポイントの消費等が０となる状況が可能であるとした場合、スタジアムにいる間（例えば４時間程度の間）、常時、行動ポイントを消費することなく探索ができることになる。このような状況を許容した場合、あまりに有利な状況を招来させてしまい、他のユーザとの間で公平性が損なわれるおそれがある。そこで、例えば、スタジアムにいる仲間の人数が１１名以上の場合にポイント消費量の低減を６０％として、これを上限としてもよい。 また、付与される特典（例えば、付与されるポイントの量や、ポイント消費量の低減する割合など）は、所定の演算式等を用いて、仲間のユーザ数を当該演算式に当てはめることで求められてもよい。

（７−５）変形例５ 上記実施形態において、付与手段５５は、通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別されてから経過した時間に応じて、特典（第１の特典）を変動させてもよい。 例えば、ユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別されてから経過した時間が長いほど、当該ユーザに付与される特典の価値を低減（例えば、ポイントの量、アイテムの価値、又はゲーム上の効果が低減する）ように構成された場合、ユーザは、より多くのポイント、より価値の高いアイテム、より有利なゲーム上の効果を得るために、他のユーザと仲間になることを極力早めに行うことが動機付けられる。これにより、ソーシャル性のさらなる向上が期待できる。

本変形例における付与手段５５の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１７に例示した設定例に基づき構成された設定用データをゲームデータベース３２に予め格納してもよい。図１７に示す設定例では、ユーザの通信端末１０が試合時間帯にスタジアム（所定領域）に存在すると判別されてからの経過時間が長いほど、特典が少なくなる（図１７の例ではポイント消費量の低減する割合が減少する）ように設定されている。 ゲームサーバ２０のＣＰＵ２１は、ユーザの通信端末１０からのアクセス（例えば、ＨＴＭＬデータの送信要求）がある毎に、図１３に示した特典付与データを参照し、特典付与データ内の最新の特典付与日時からの経過時間を、ＣＰＵ２１に内蔵されたタイマを用いて求める。そして、ＣＰＵ２１は、求められた経過時間と、設定用データに設定された経過時間とに応じて、特典を決定してもよい。

図１７の例では、ユーザの通信端末１０がスタジアムに存在すると判別されてから１時間以内は、ポイント消費量を１００％低減する。即ち、この間はポイント消費量が０になるので、ユーザにとってはゲーム進行を非常に有利に運べることになる。具体的に説明
すると、図９に示すスカウト処理の場合、通常であれば探索を行うことで行動ポイントを消費し（例えば１回の探索で５ポイント）、探索を続けることによりユーザが保有する行動ポイントが無くなると、それ以上、探索を実行することができない。 一方、本変形例では、１時間の間、行動ポイントの消費が０になるので、ユーザは好きなだけ探索を実行できることになる。また、ユーザの通信端末１０がスタジアムに存在すると判別されてから１時間超２時間以内は、ポイント消費量を５０％低減する。この場合、行動ポイントの消費量は０にはならないが、通常に比べて半分の行動ポイントしか消費しないので、通常より２倍程度の探索を行えることになる。以下、図１７に示す通り、時間が経過するごとに、行動ポイントの低減率が低くなるので、ユーザにとっては、なるべく早く、探索を実行する方が有利なゲーム進行を行えることになる。なお、試合終了時から所定時間経過後（例えば、６時間後）には、特典付与を終了してもよい。 また、付与される特典（例えば、付与されるポイントの量や、ポイント消費量の低減する割合など）は、所定の演算式等を用いて、経過時間を当該演算式に当てはめることで求められてもよい。

以上、本発明の実施形態について詳細に説明したが、本発明は上記実施形態に限定されない。また、各実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更をしてもよいのは勿論である。 例えば、上述した実施形態では、適用されるゲームが野球形式のデジタルカードゲームである場合を想定したが、ゲームの種別は如何なるものでもよい。例えば、サッカーやアメリカンフットボールなどの競技を模したゲームや、映画やテレビドラマなどの動画作品を模したゲームや、架空のキャラクタ（例えばモンスターキャラクタなど）が登場するゲームなどであってもよい。

例えば、上述した実施形態では、ユーザと通信端末１０が１対１の関係である場合について説明したが、これに限られない。例えば、ユーザは、自身の保有する通信端末と異なる他の通信端末（例えば、複数のユーザが共有して使用する通信端末など）を用いてもよい。つまり、上述した実施形態では、現在位置データがユーザＩＤに対応付けられて管理されているので、ユーザが他の通信端末を用いた場合であっても、他の通信端末によって測位された位置情報を当該ユーザのユーザＩＤと対応付けることにより、ユーザの現在位置を認識することができる。

また、上述した実施形態では、通信端末１０のＧＰＳ測位部１８が、通信端末１０の位置情報を取得する構成例を示しているが、これに限定されるものではない。 例えば、通信端末１０が無線電話機能（携帯電話機能またはＰＨＳ（Personal Handy-phone System）機能）を備える場合には、無線電話基地局の有する基地局識別情報を、通信端末１０の位置情報として用いることもできる。すなわち、携帯電話やＰＨＳの各基地局は、所定の通信エリアを有してセル状に配置されており、各基地局から受信した基地局識別情報に基づいて、当該基地局の通信エリア内に通信端末１００が存在することを認識できる。この場合、ＧＰＳ測位部１８を用いたときと比較して、位置情報としての精度が低いものの、基地局識別情報を位置情報として利用することが可能である。

また、例えば、通信端末１０がＷｉ−Ｆｉ（wireless fidelity、登録商標）等の無線ＬＡＮ通信機能を備える場合には、無線通信親機（無線ＬＡＮアクセスポイント又はルータ等）の識別情報（例えば、ＭＡＣ（Media Access Control）アドレスまたはＩＰ（Internet Protocol）アドレス）を位置情報として用いることもできる。すなわち、所定のエリアを無線通信範囲とする無線通信親機（一つまたは複数の無線ＬＡＮアクセスポイント又はルータ等）を設置し、ユーザが、通信端末１０を無線ＬＡＮアクセスポイント等の無線通信親機にアクセスしたときに、通信端末１０が、無線通信親機の識別情報を位置情報として取得するように構成する。この場合、ゲームサーバ２０は、取得した無線通信親機の識別情報に基づいて、当該無線通信親機の通信エリア内に通信端末１０が存在することを認識できるので、無線通信親機の識別情報を位置情報として利用することが可能である。

さらに、取得手段５３は、例えば、撮像装置（カメラ）が通信端末１０に搭載されている場合、ユーザが所定の場所に存在しないと撮像することができない画像情報やバーコード情報などを位置情報として取得してもよい。また、取得手段５３は、ユーザが所定の場所に存在しないと確認することができない合言葉やパスワード等の文字・数字・記号情報等を位置情報として取得してもよい。 なお、ユーザが所定の場所に存在しないと撮像あるいは確認することができない画像情報等は、その画像情報等を取得したユーザによって他のユーザに転送される場合がある。この場合、所定の場所に存在していない他のユーザが、当該画像情報等を入手することが可能となるため、通信端末１０の正確な現在位置を取得することが困難になる。 そこで、所定の場所で撮像あるいは確認できる画像情報等を所定時間毎（例えば１分毎）に変化させて、撮像あるいは確認した画像情報等に有効期限を設けてもよい。この場合、所定時間毎に変化する画像情報等を生成する情報生成部を備えるとともに、所定の場所を含むエリアを無線通信範囲とする無線通信親機（一つまたは複数の無線ＬＡＮアクセスポイント又はルータ等）を設置し、ユーザが通信端末１０を無線ＬＡＮアクセスポイント等にアクセスすれば、無線ＬＡＮアクセスポイント等に接続された情報生成部から所定時間毎に変化する画像情報等を取得できるように構成してもよい。なお、この構成を実現するために、情報生成部とゲームサーバ２０とは時刻同期をしており、両者は同じアルゴリズムを用いて画像情報等を所定時間毎に変化させながら生成することが好ましい。

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

例えば、上述した実施形態では、ネットワーク上のゲームサーバ２０及びデータベースサーバ３０によって、取得手段５３、判別手段５４及び付与手段５５の各機能を実現する構成としたが、この構成に限られない。これらのすべての手段を通信端末１０によって実現する構成としてもよいし、例えば、図１８Ａ，図１８Ｂに示すように、少なくとも一部の手段を通信端末１０によって実現する構成としてもよい。通信端末１０とゲームサーバ２０とでは実質的に同一のハードウエア構成を採ることができるため、上記実施形態に記載したようにして通信端末１０によっても各機能を実現できる。通信端末１０は、ゲーム終了時には、ゲームの結果についてのデータをゲームサーバ２０へ送信し、ゲームサーバ２０は、受信したゲームの結果のデータをユーザと関連付けてゲームデータベース３２に記録するようにしてもよい。

１０…通信端末 １１…ＣＰＵ １２…ＲＯＭ １３…ＲＡＭ １４…画像処理部 １５…指示入力部 １６…表示部 １７…通信インタフェース部 １８…ＧＰＳ測位部 １９…バス ２０…ゲームサーバ ２１…ＣＰＵ ２２…ＲＯＭ ２３…ＲＡＭ ２４…データベースアクセス部 ２５…通信インタフェース部 ２６…バス ３０…データベースサーバ ３１…ユーザデータベース ３２…ゲームデータベース ５１…登録手段 ５２…ゲーム進行手段 ５３…取得手段 ５４…判別手段 ５５…付与手段

Claims (7)

1. ユーザ同士を関係付ける関係付け手段と、
   互いに関係付けられた複数のユーザの通信端末の各々の位置を示す位置情報を取得する取得手段と、
   前記複数のユーザの各通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、各通信端末の位置情報に基づいて判別する判別手段と、
   前記互いに関係付けられた複数のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記互いに関係付けられた複数のユーザに対してゲーム上の特典を付与する付与手段と、を備えたゲーム制御装置。
2. 前記付与手段は、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された前記互いに関係付けられた複数のユーザの数に応じて、前記互いに関係付けられた複数のユーザに付与する特典を決定することを特徴とする、請求項１に記載されたゲーム制御装置。
3. 前記付与手段は、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された前記互いに関係付けられた複数のユーザの数が多いほど、前記特典を大きくすることを特徴とする、請求項１または２に記載されたゲーム制御装置。
4. ユーザがゲーム上保有するポイントが、時間経過に応じて増加される一方、当該ユーザの操作入力に基づいて消費され、前記ポイントが所定の閾値より低い場合に前記ゲームの進行が制限されるように、前記ゲームを進行させるゲーム進行手段、をさらに備え、
   前記付与手段は、前記通信端末が前記イベント期間内に前記所定領域に存在すると判別された前記互いに関係付けられた複数のユーザの数が多いほど、前記操作入力に関する情報に基づく前記ポイントの消費量を低減させることを特徴とする、請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記付与手段は、前記操作入力に基づく前記ポイントの消費量の低減量を所定値以下に制限することを特徴とする、請求項４に記載されたゲーム制御装置。
6. ゲームの実行を制御するために、コンピュータに、
   ユーザ同士を関係付ける機能、
   互いに関係付けられた複数のユーザの通信端末の各々の位置を示す位置情報を取得する機能、
   前記複数のユーザの各通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、各通信端末の位置情報に基づいて判別する機能、
   前記互いに関係付けられた複数のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記互いに関係付けられた複数のユーザに対してゲーム上の特典を付与する機能、
   を実現させるためのプログラム。
7. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
   ユーザ同士を関係付ける関係付け手段、
   互いに関係付けられた複数のユーザの通信端末の各々の位置を示す位置情報を取得する取得手段、
   前記複数のユーザの各通信端末が、所定のイベントが行われるイベント期間内に前記イベントが行われる所定領域に存在するか否かを、各通信端末の位置情報に基づいて判別する判別手段、
   前記互いに関係付けられた複数のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記互いに関係付けられた複数のユーザに対してゲーム上の特典を付与する付与手段、
   の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
   ゲームシステム。
   

Images