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

Description

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

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

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

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

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

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

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

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

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

ここで、「イベント」とは、所定期間の間開催される行事等であれば何でもよいが、例えば、ゲームにおいて模擬された現実世界のイベントであってもよい。ゲームにおいて模擬された現実世界のイベントとは、例えば、野球ゲームの場合には野球の試合であってよいし、サッカーゲームの場合にはサッカーの試合であってよいし、音楽ゲームの場合には音楽の演奏会であってよい。また、「所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。また、「所定領域」は、ゲームに関する領域であるか否かにかかわらず、例えば販売や展示等のイベントが行われる領域であれば任意に設定することができる。例えば、「所定領域」は、ゲームセンターなどの遊技施設、ゲームの販売を行う店舗あるいはゲームの展示を行う展示会場などであってもよいし、「東京都港区赤坂九丁目」などの地域の区画などであってもよい。
また、「ユーザに対してゲーム上の抽選を行う」とは、例えば、ユーザを識別するためのユーザ識別情報（ユーザＩＤ）を抽選対象としてゲーム上の抽選を行うことであってもよいし、ユーザが保有する通信端末固有の端末識別情報を抽選対象としてゲーム上の抽選を行うことであってもよい。
さらに、「第２のユーザに関する情報」とは、例えば、第２のユーザの数であってもよいし、第２のユーザに対応付けられた情報（例えば、第２のユーザがゲーム上保有するポイントの量やアイテムの数、第２のユーザにより実行されたゲーム上の対戦数、ゲーム上の対戦における第２のユーザの勝利数又は敗北数、第２のユーザのゲームの進行度あるいは第２のユーザのゲーム上の技能レベルなど）であってもよい。

さらにまた、「ゲーム上の特典」とは、例えば、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。ここで、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。例えば、アイテムは、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。なお、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。
また、ゲーム上の有利な効果とは、例えば、ユーザがゲーム上保有するアイテムのパラメータを上昇させることであってもよいし、アイテムを用いることなくキャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、ゲーム上の有利な効果とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作などに応じて消費するゲーム上のポイントの消費量を通常よりも低減させることであってもよいし、ポイントを入手できることであってもよい。さらにまた、ゲーム上の有利な効果とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、アイテムのパラメータが大幅に上昇する確率を上昇させることであってもよい。
さらに、「ゲーム上の特典」とは、ユーザが実行するゲームと同一のゲーム上の特典であってもよいし、ユーザが実行するゲームとは異なる他のゲーム上の特典であってもよい。ここで、異なる他のゲームとは、例えば一つのゲームシリーズのように、ゲームの構成やジャンルがほぼ同じであるがゲームのタイトルが異なる場合（例えば、「ゲームＡ（２０１１年度版）」と「ゲームＡ（２０１２年度版）」など）も含む。

このゲーム制御装置では、ゲーム上の抽選における第１のユーザの当選確率は、第１のユーザの通信端末がイベント期間内に所定領域に存在すると判別された場合に、第１のユーザに関係付けられた仲間ユーザ（第２のユーザ）に関する情報に基づいて変動するようになっている。これにより、第１のユーザは、例えば、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、他のユーザと関係付ける（仲間になる）ことが動機付けられる。このため、ユーザ間の交流を促進することができ、ソーシャル性の高いゲームを実現することができる。
また、第１のユーザは、例えば、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、イベント期間内に所定領域に出向く（イベントに参加する）ことが動機付けられる。この場合、イベントに参加することが抽選に当選する要因になり得ることから、第１のユーザは、イベントとゲームが連動しているような感覚を得ることができる。このため、通信端末の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。一方、イベントの運営側にとっては、ユーザをイベント会場（例えば、スタジアム、ゲームセンター、競馬場、コンサートホールなど）に来場させる誘因力あるシステムを構築することができる。

上記ゲーム制御装置において、前記抽選手段は、前記イベント期間内に前記所定領域に通信端末が存在すると判別されたユーザに対して前記抽選を行ってもよい。
このゲーム制御装置では、抽選対象となるユーザは、自身の通信端末がイベント期間内に所定領域に存在すると判別されたユーザに限定される。つまり、ユーザにとっては、イベント期間内に所定領域に出向かなければ（イベントに参加しなければ）、ゲーム上の特典が付与される機会を得ることができない。このため、第１のユーザは、ゲーム上の特典が付与される機会を得るために、イベントに参加することが動機付けられる。これにより、イベントの運営側にとっては、ユーザをイベント会場に来場させる誘因力を高めたシステムを構築することができる。

上記ゲーム制御装置において、前記抽選制御手段は、前記第２のユーザの通信端末のうち前記イベント期間内に前記所定領域に存在すると判別された通信端末に関する情報に基づいて、前記抽選における前記第１のユーザの当選確率が変動するように前記抽選手段を制御してもよい。
例えば、第１のユーザと関係付けられた仲間ユーザ（第２のユーザ）の通信端末のうち、イベント期間内に所定領域に存在すると判別された通信端末の数が多いほど、抽選における第１のユーザの当選確率が高くなるように構成されてもよい。つまり、イベントに参加する仲間ユーザの数が多いほど、第１のユーザの当選確率が高くなるように構成されてもよい。この場合、第１のユーザは、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、仲間ユーザとイベントに参加することが動機付けられる。これにより、ゲーム上及び現実世界におけるユーザ間の交流を促進することができるため、ソーシャル性をさらに高めたゲームを実現することができる。

上記ゲーム制御装置において、前記付与手段は、前記第１のユーザが前記抽選に当選し、且つ、前記第１のユーザの通信端末が前記イベント期間の終了時期に前記所定領域に存在すると判別された場合に、前記第１のユーザに対して前記特典を付与してもよい。
例えば、第１のユーザが抽選に当選すると、第１のユーザに対してゲーム上の特典が即時付与されるように構成されている場合、イベントに参加したことに基づいて抽選に当選した第１のユーザは、特典が付与されると直ちに所定領域を去ることが考えられる。このような行為は、第１のユーザが自らの利益を得ることのみを目的としてイベントに参加することになるため、イベントの運営側にとっては好ましくない。
このゲーム制御装置によれば、第１のユーザの通信端末の位置についての判別をイベント期間の終了時期に行うことにより、例えば、第１のユーザの通信端末がイベント期間の終了時期に所定領域に存在しないと判別された場合には、第１のユーザに対して特典を付与しない仕組みとすることができる。これにより、第１のユーザは、特典を得るために、イベント期間中には所定領域に留まることが動機付けられる。したがって、上記の行為を抑制することができる。また、ユーザにイベント参加、観戦等を十分行ってもらえることにより、イベント運営側にとっても有益なゲームを実現することができる。

上記ゲーム制御装置において、前記特典には、有効期間が設定されており、前記特典が第１のイベントに基づいて付与された場合に、当該特典の有効期間の終了時期は、前記特典の付与以降の時期であって、前記第１のイベント以降に行われる第２のイベントの開始以前の時期に設定されてもよい。
ここで、「第２のイベント」は、「第１のイベント」と同じイベントであってもよいし、異なるイベントであってもよい。例えば、第１のイベントが野球の試合の場合には、第２のイベントは、野球の試合であってもよいし、サッカーの試合であってもよいし、音楽の演奏会などであってもよい。
例えば、第１のユーザが第１のイベントのイベント期間内に行われた抽選に当選した場合には、第１のユーザに付与される特典の有効期間は、第２のイベントの開始以前の時期に終了することになる。この場合、第１のユーザは、特典を続けて得る可能性を高めるために、第２のイベントに参加することが動機付けられる。これにより、抽選に当選したユーザに対して第２のイベントに参加するように誘導することができるので、イベントの運営側にとっては、ユーザをイベント会場に来場させる誘因力をさらに高めたシステムを構築することができる。

上記ゲーム制御装置において、前記付与手段は、前記イベントの状況に応じて、前記特典を変動させてもよい。
ここで、「イベントの状況」とは、例えば、イベントの参加人数であってもよいし、イベントの進行度合いであってもよい。また、「イベントの状況」とは、例えば、イベントが野球やサッカーなどの競技である場合には、競技の結果（例えば試合結果）や競技時間などであってもよい。
例えば、イベントの参加人数が多いほど、抽選に当選することにより付与される特典が多くなるように構成されてもよい。この場合、抽選に当選したユーザは、付与される特典がイベントの参加人数に応じて変動することから、イベントとゲームが強く連動しているような感覚を得ることができる。このため、ゲームの興趣性をさらに高めることができる。

上記ゲーム制御装置において、前記付与手段は、前記第１のユーザ及び前記第２のユーザのそれぞれの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記第１のユーザ又は前記第２のユーザが前記抽選に当選すると、前記第１のユーザ及び前記第２のユーザに対して、ゲーム上の特典を付与してもよい。
このゲーム制御装置によれば、例えば、第１のユーザと、第１のユーザの第２のユーザ（仲間ユーザ）とがイベントに参加した場合に、第１のユーザ又は仲間ユーザが抽選に当選すれば、両者に特典が付与される。この場合、第１のユーザは、自らが抽選に当選しなくても、仲間ユーザが当選すれば特典を得ることができる。これにより、第１のユーザは、特典を得る可能性を高めるために、仲間ユーザとイベントに参加することが動機付けられる。これにより、仲間関係の構築が活性化され、ソーシャル性のさらなる向上が期待できる。

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

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

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

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

通信端末は、例えば携帯端末、スマートフォン、ＰＤＡ(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）等の形態の記憶装置等、汎用ストレージで実現できる。データベースサーバ３０内の各データベースは、ゲームサーバ２０のデータベースアクセス部２４を介してＣＰＵ２１からのデータの読み書きが可能となるように構成されている。
図５に、データベースサーバ３０の構成の一例を示す。図５に示すように、データベースサーバ３０は、ユーザデータベース３１と、ゲームデータベース３２とを備える。

本実施形態のゲームサーバ２０によって実行制御されるゲームのタイプは特に限定されるものではないが、以下では、実施形態の説明の便宜上、本実施形態のゲームの一例として、野球形式のデジタルカードゲーム（以下適宜、単に「ゲーム」あるいは「本実施形態のゲーム」という。）を採り上げる。
本実施形態のゲームは、ユーザが野球選手に対応する選手カードを収集することによって自らのチームを作り上げ、他のユーザのチームと野球の対戦を行うように構成されているゲームである。このゲームは、ユーザの実行対象となる以下の処理を含む。
・スカウト処理：
自らのチームを作り上げていくために選手カードを探索する処理である。スカウトを実行することで行動ポイント（後述する）は消費するが、強化ポイント（後述する）は増加する。
・強化処理：
強化ポイントを消費することで、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる処理である。この場合、特定の選手カードの能力は上昇するが、一体化に用いられた選手カードは消失する。つまり、一体化に用いられた選手カードの数だけ選手数が減少する。
・試合処理：
他のユーザのチームと野球の試合を行う処理である。試合を行うことで運営ポイント（後述する）は消費するが、試合に勝利すれば強化ポイントが増加する。
・オーダー処理：
ユーザが選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行するための処理である。
・アイテム抽選処理：
エールポイント（後述する）を消費して、抽選によってゲーム上のアイテム（例えば選手カード）を入手する処理である。
・抽選登録処理：
ゲーム上で行われる抽選（上記アイテム抽選処理で行われるアイテムの抽選とは異なる抽選）にユーザが登録（エントリー）するための処理である。抽選は、抽選登録処理を行ったユーザを対象に行われ、抽選に当選したユーザには、ゲーム上の特典が付与されるようになっている。なお、抽選は、定期的に行われてもよいし、任意に設定されたタイミングで行われてもよい。

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

以下の説明では、ユーザデータベース３１に含まれるユーザＩＤごとのデータを総称してユーザデータという。ユーザデータを構成する各項目のデータは、以下のとおりである。
・ユーザ名／表示画像
ユーザ名は、ユーザを特定するために、ゲームの実行時に通信端末１０に表示される名称である。ユーザ名はユーザによって予め指定される所定長以下のテキストである。また、ユーザ名は、ゲームサーバ２０によって提供されるネットワーク環境（あるいはゲームコミュニティ）上でユーザを特定する名称である。表示画像は、ユーザを特定するために、ゲームの実行時に通信端末１０に表示される画像である。表示画像は、例えばユーザによって予め選択されるアバタ画像である。
・技能レベル
ゲーム上のユーザの技能レベル示すデータである。例えばＬｖ１（レベル１）からＬｖ１００（レベル１００）までの範囲のレベル値であり、例えば、上述したスカウト処理が継続的に実行されることで、順次技能レベルが上がるように構成されてもよい。
・行動ポイント
本実施形態のゲームにおいて、スカウト処理を実行する上で必要となるポイントである。行動ポイントは、スカウト処理において探索を行うことで例えば一定量減少し、所定の時間が経過する毎に回復（増加）する値である。
・運営ポイント
本実施形態のゲームにおいて、試合処理を行う上で必要となるポイントである。運営ポイントは、他のユーザと試合を行うことによって低減し、所定の時間が経過する毎に回復（増加）する値である。
・強化ポイント
本実施形態のゲームにおいて、強化処理を行う上で必要となるポイントである。強化ポイントは、選手カードの強化を行うことで低減し、他のユーザとの試合で勝利するか、あるいはスカウト処理において探索を行うことで増加する値である。
・エールポイント
本実施形態のゲームにおいて、他のユーザ（例えば、ユーザと関係付けられた仲間ユーザ）へ応援メッセージを送信することでユーザが取得するポイントである。
・選手数
ユーザが保有する選手カードの数である。選手数は、スカウト処理や強化処理の実行によって増減する。選手数の最大値（例えば、６０）は予め規定されている。
・仲間のユーザＩＤ
ユーザと関係付けられた仲間ユーザのユーザＩＤのデータである。
・保有カードのデータ
ユーザが保有する選手カードごとに、例えば、選手の画像データや、選手の能力を示すパラメータ（例えば、野手であれば打力、走力、守備力を示す値、投手であれば球速、制球力、スタミナを示す値）等のデータが含まれる。例えば、パラメータに含まれる能力の値が大きいほど能力が高いことを示すように設定されてもよい。なお、選手カードのデータには、「レア度」が含まれてもよい。ここで、「レア度」とは、選手カードの希少価値の度合を示す値であり、その値が高いほどゲーム内で出現する確率が非常に低く設定されてもよい。例えば、レア度を１〜５の５段階で表した場合、技術能力の際立った選手や人気のある選手に対応する選手カードのレア度は高く（例えば、４あるいは５など）設定されてもよい。
また、選手カードのデータには、選手の所属チーム、ポジション（投手、捕手、一塁手、左翼手など）、選手カードがゲームに及ぼす影響度（典型的にはポジティブな影響度）等が含まれてもよい。

図５に戻り、ゲームデータベース３２は、ゲームサーバ２０からのアクセスに基づき、ゲームサーバ２０によって実行されたゲームの進行に関する情報を記憶、更新する。ゲームの進行に関する情報は、ゲームの性質によって多様な情報を含みうる。本実施形態のゲームの場合を例に挙げれば、ゲームの進行に関する情報は、ユーザ毎のスカウト処理の進行状況を示す情報や、ユーザ間の試合の結果（スコア等）などを含む。

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

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

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

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

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

ゲーム実行手段５２は、ゲームで実行される複数の処理が各々割り当てられた複数のメニューを通信端末１０に表示させる。具体的には、ＣＰＵ２１は、複数のメニューを含むウェブページを表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。そして、ＣＰＵ２１は、通信端末１０においてウェブページ上のメニューが選択されたときに、選択されたメニューについての情報を通信端末１０から受信し、受信した情報に基づいて、選択されたメニューに割り当てられた処理を実行する。

ゲーム実行手段５２によって通信端末１０に表示されるゲームのトップページの例を図８に示す。このトップページは、個々のユーザＩＤに応じたウェブページで構成される。図８に例示されるトップページは、ユーザデータ表示領域、選手画像表示領域及びメニュー表示領域を含む。
ユーザデータ表示領域は、対象となるユーザＩＤのユーザデータに含まれる、技能レベル、行動ポイント、運営ポイント、強化ポイント、エールポイント、選手数、仲間の各項目のデータ（図６参照）が表示される領域である。なお、ユーザデータ表示領域に表示される項目で、Ｘ／Ｙの形式で表記されているポイントまたは数は、Ｘがユーザの保有するポイントまたは数であり、Ｙがそのポイントまたは数の最大値であることを示す。例えば、選手数が「４０／６０」と表記されていれば、ユーザが保有する選手数が４０人であり、最大で保有可能な選手数が６０人であることを示す。
選手画像表示領域は、ユーザによって予め選択された選手カードの画像データが表示される領域である。
メニュー表示領域は、本実施形態のゲームに設けられる複数の処理（スカウト処理、強化処理、試合処理、オーダー処理、アイテム抽選処理、抽選処理）に対応した基本メニューとして、「スカウト」、「強化」、「試合」、「オーダー」、「アイテム抽選」、「抽選登録」の各メニューｍ１〜ｍ６が表示される領域である。つまり、ゲームで実行される複数の処理が各々割り当てられた複数のメニューが、通信端末１０に表示されるウェブページの所定の位置にそれぞれ配置される。なお、オーダー処理は、ユーザの指示の下、選手カードのオーダーの入れ替え、控えの選手カードとの交替等を実行する処理である。
ゲーム実行手段５２は、通信端末１０に表示されたメニューに対するユーザの選択操作に応じた処理を実行する。好ましくは、各処理が実行された場合、処理ごとに細分化された複数のメニューを含む新たなウェブページが表示されるようにして、階層的に各処理が実行される。

例えば、図８に示すトップページをユーザの通信端末１０に表示する場合について、ゲーム実行手段５２の機能は以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、データベースアクセス部２４を介してユーザデータベース３１にアクセスし、ユーザデータ表示領域に含まれる各項目のデータと、選手画像表示領域に表示すべき選手カードの画像データを読み出す。次にＣＰＵ２１は、図８に示したトップページが構成されるようにＨＴＭＬデータを生成し、通信端末１０宛に送信する。生成されるＨＴＭＬデータは、ユーザごと（つまり、ユーザＩＤごと）に異なるものとなる。通信端末１０は、受信したＨＴＭＬデータを解釈してトップページの画像を表示部１６（表示画面１６ａ）に表示する。

［スカウト処理］
ゲーム実行手段５２は、ユーザが自らのチームを作り上げていくために選手カードを探索できるようにするスカウト処理を実行する。
図９は、スカウト処理が実行された場合に通信端末１０に表示されるウェブページの例を示す。図９は、トップページにおいてスカウトメニュー（図８のメニューｍ１）が選択操作されたときのウェブページの表示例である。

図９に例示するウェブページでは、表示領域１００において、複数の地域（エリア）に分けられた日本地図が、探索の対象となるエリアが強調表示された状態で表示される。
このスカウト処理では、ユーザは、探索の対象となるエリア（図９の例では、エリア９（サブエリア９−１，９−２，…））ごとに設けられる「探索する」と表記されたメニューｍ１０を選択操作する。この操作を契機として、探索の対象となるエリアについての探索が行われ、選手が発掘された場合に表示領域１０２にその選手の選手カードが表示される仕組みになっている。このとき、メニューｍ１０が選択操作されて探索が行われる度に、表示領域１０１に表示されている「探索率」（％）の値が増加する。また、表示領域１０１には、１回の探索に要する行動力の値（図９の例では「５」）、１回の探索で得られる強化ポイントの値（図９の例では「１０」）が表示される。１回の探索につき、表示されている行動力の値だけ行動ポイントが減少し、表示されている量の強化ポイントが増加するように構成されている。ゲーム実行手段５２では、探索を行う度（メニューｍ１０が選択される度）に、ＣＰＵ２１がユーザデータベース３１にアクセスし、対象となるユーザＩＤの行動ポイント及び強化ポイントの値を更新する。

スカウト処理において、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１０に対する選択操作を認識すると、スカウト用に予め設けられた複数の選手の中から所定の、あるいはランダムな確率で抽選を行う。ＣＰＵ２１は、抽選により選手を得た（発掘した）場合には、ユーザデータベース３１にアクセスし、対象となるユーザＩＤのデータに対して、発掘された新たな選手のデータを追加して、選手数の値を１だけ増加させる。さらにＣＰＵ２１は、発掘された選手の選手カードを表示領域１０２に表示するためのＨＴＭＬデータを生成して通信端末１０宛に送信する。なお、このＨＴＭＬデータは、表示領域１０１の探索率のデータが更新されるようにして構成されている。ユーザによるメニューｍ１０に対する選択操作が繰返し行われ、図９においてサブエリア９−１，９−２，…のすべてのエリアの探索率が１００％に達すると、エリア９についての探索は終了し、探索対象は次のエリア（この場合、エリア１０）に移る。なお、後述するように、探索率が１００％に達したとしても、表示領域１０２に表示可能な最大の枚数（図９のサブエリア９−１では、４枚）に相当する数の選手が発掘できたとは限らない。

スカウト処理では、探索対象となるエリアごとに、１回の探索に要する行動ポイントが異なってもよい。つまり、探索対象となるエリアごとに、１回の探索で減少する（消費される）行動ポイントの量が異なってもよい。例えば、ユーザの技能レベルが上がるごとに、消費される行動ポイントの量を多くしてもよい。
スカウト処理では、メニューｍ１０に対する選択操作を行う度に行動ポイントが減少していくため、スカウト処理が実行された直後にトップページが表示される場合には、そのトップページに表示される行動ポイントがスカウト処理の実行前よりも減少されて表示されることになる。ユーザが保有する行動ポイントが０になれば、それ以上、探索を実行することはできない。但し、行動ポイントは、例えば所定時間（例えば３分）が経過する度に１ポイントずつ回復（増加）するので、所定時間経過すれば、再び、探索を行うことが可能になる。

［強化処理］
ゲーム実行手段５２は、２枚以上の選手カードを一体化して特定の選手カードの能力を上昇させる強化処理を実行する。このゲームでは、ユーザが強化処理を実行するには一定量の強化ポイントが必要となる。
この一体化の処理は、例えば以下のように行われてよい。強化対象となる選手カード（ユーザによって指定された、残留する選手カード）を選手Ａの選手カードとし、選手Ａの選手カードに一体化させられて消失する選手カードを選手Ｂの選手カードとする。この場合、一体化の処理では、ＣＰＵ２１が選手Ａの選手カードの「打力」，「走力」，「守備力」の能力値を示すパラメータに対して、選手Ｂの選手カードの「打力」，「走力」，「守備力」の能力値を示すパラメータの一定比率をそれぞれ加算することで、新たな選手Ａの選手カードのパラメータを算出するようにしてもよい。この強化処理によって、選手Ｂの選手カードの能力上の特徴が選手Ａの選手カードに反映されることになる。
強化処理後には、ＣＰＵ２１は、強化処理の後にユーザデータベース３１にアクセスし、対象となるユーザＩＤのユーザデータから選手Ｂの選手カードのデータを削除し、選手数の値を１だけ減少させ、選手Ａの選手カードのパラメータを書き換え、対象となるユーザＩＤの強化ポイントを所定量減少させる。なお、強化ポイントは、上記スカウト処理を実行したり、以下に説明する試合処理を実行したりすることによって増加する。

［試合処理］
ゲーム実行手段５２は、ユーザによる通信端末１０の操作入力を契機として、他のユーザのチームと野球の試合を行う試合処理を実行する機能を有する。
このゲームでは、試合処理を実行するには運営ポイントを必要とし、試合に勝利することで強化ポイントを得ることができる。つまり、試合処理の実行によって、ユーザＩＤに対応する運営ポイント、強化ポイントの値が変化し得る。１回の試合で必要となる（消費する）運営ポイントは、ユーザのチームで組まれるオーダーによって定まる値である。ユーザは、ユーザが保有する選手カードの中から試合に出場させたい選手カードをオーダー処理によって組み替えることができるが、試合に出場させたい所定数の選手カードによって、運営ポイントの消費量が決定される。例えば、選手カードごとに１回の試合で必要となるコスト（必要ポイント）が予め割り当てられており、試合に出場させたい所定数の選手の必要ポイントの合計が運営ポイントとなる。運営ポイントは、例えば所定時間（例えば1分）が経過する度に１ポイントずつ回復（増加）する。

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

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

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

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

［抽選登録処理］
ゲーム実行手段５２は、ゲーム上で行われる抽選にユーザが登録（エントリー）するための抽選登録処理を実行する。なお、この抽選は、上述したアイテム抽選処理と異なるものである。
ゲーム実行手段５２が抽選登録処理を実行する機能は、例えば以下のとおり実現される。ユーザの通信端末１０のトップページ上で、「抽選登録」と表記されたメニューｍ６（図８参照）の選択操作がなされ、その選択結果を受信すると、ゲームサーバ２０のＣＰＵ２１は、図１０に例示するウェブページを表示するためのＨＴＭＬデータを生成して、当該ユーザの通信端末１０宛に送信する。この場合、ユーザの通信端末１０には、図１０に示すウェブページが表示される。図１０のウェブページの例には、抽選に当選するとゲーム上の特典（図の例ではプレゼント）が得られることを通知するためのメッセージと、抽選に登録するための「エントリーする」と表記されたメニューｍ１１などが含まれる。ユーザがメニューｍ１１の選択操作を行うと、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１１の選択操作を行ったユーザのユーザＩＤを、ゲームデータベース３２内のエントリーデータに記録する。図１１にエントリーデータの構成例を示す。図１１に示すように、エントリーデータは、抽選登録処理を行った（メニューｍ１１の選択操作を行った）ユーザのユーザＩＤと、当該ユーザＩＤに対応付けられた当選確率とが記述されたデータである。
なお、ユーザＩＤがエントリーデータに記録される時点では、当該ユーザＩＤに対応する当選確率にはデフォルトの値（図の例では３０％）が記録される。また、後述する抽選制御手段５７の機能によってユーザの当選確率が変動する場合には、当該ユーザの当選確率の調整値（図の例では、３０％増加、あるいは７０％増加）によって調整された当選確率の値が、エントリーデータ内の当該ユーザのユーザＩＤに対応する当選確率の項目に記録される。
なお、エントリーデータに記録されたユーザＩＤ及び当選確率は、例えば、１回の抽選が行われるごとに全て更新されてもよいし、所定回数の抽選が行われるごとに全て更新されてもよい。
また、本実施形態のゲームでは、抽選登録処理において登録（エントリー）したユーザを対象として抽選を行うように構成されているが、抽選登録処理は必須の機能ではない。つまり、ゲームを実行可能なユーザ（ゲームの登録処理を行ったユーザ）の全てが抽選対象として自動的に設定されるように構成されてもよい。この場合、図８に示したトップページには、「抽選登録」と表記されたメニューｍ６を設けなくてもよい。また、例えば、後述する変形例１に関連して、野球の試合（イベント）が行われる試合時間帯（イベント期間内）に当該試合が行われるスタジアム（所定領域）に存在する通信端末１０を保有するユーザを対象として抽選を行う場合には、「スタジアム観戦ありがとうございます。本日スタジアムにお越しの皆様のみを対象とするプレゼント抽選が行われます。お楽しみに。」などのように、抽選が行われることを通知するテキストなどがトップページに表示されてもよい。

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

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

抽選手段５４は、ユーザに対してゲーム上の抽選を行う機能を備える。
ここで、「ユーザに対してゲーム上の抽選を行う」とは、例えば、ユーザを識別するためのユーザ識別情報（ユーザＩＤ）を抽選対象としてゲーム上の抽選を行うことであってもよいし、ユーザが保有する通信端末固有の端末識別情報を抽選対象としてゲーム上の抽選を行うことであってもよい。
抽選手段５４の機能は、例えば以下のようにして実現できる。ゲームサーバ２０のＣＰＵ２１は、例えばＣＰＵ２１に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると、図１１に例示したエントリーデータに記録されたユーザＩＤに対応するユーザを対象とした抽選処理を行う。ここで、抽選時刻は任意に設定されてもよく、例えば、後述する試合時間帯（イベント期間内）の所定時刻に設定されてもよい。
また、抽選方法は、周知の方法が用いられてもよい。例えば、ユーザの当選確率が３０％となるように抽選を行う場合には、ＣＰＵ２１は、図１１に示したエントリーデータのユーザＩＤごとに、０．１〜１．０の範囲内で０．１間隔の乱数を発生させ、発生した数が０．３以下のユーザＩＤに対応するユーザを当選者として決定するようにしてもよい。また、ＣＰＵ２１は、エントリーデータのユーザＩＤに対応する当選確率にデフォルト値（図１１の例では３０％）以外の値が設定されている場合には、記録された値に基づいて当選確率を調整した上で抽選処理を行う。図１１に示す例を参照して説明すると、例えば、当選確率のデフォルト値が予め３０％に設定されている場合に、ＣＰＵ２１は、ユーザＩＤが「１１２２３３」のユーザの当選確率を３０％増加、すなわち当該ユーザの当選確率が６０％となるように調整した上で抽選処理を実行する。この場合、ＣＰＵ２１は、０．１〜１．０の範囲内で０．１間隔の乱数を発生させ、発生した数が０．６以下の場合に、ユーザＩＤが「１１２２３３」のユーザを抽選の当選者として決定するようにしてもよい。また、ＣＰＵ２１は、ユーザＩＤが「０００１２３」のユーザに対する抽選を行う場合、当該ユーザの当選確率を７０％増加、すなわち当該ユーザの当選確率が１００％となるように調整した上で抽選処理を実行する。この場合、ＣＰＵ２１は、ユーザＩＤが「０００１２３」のユーザを抽選の当選者として決定するようにしてもよい。
なお、本実施形態では、所定の抽選時刻が到来すると自動的に抽選が実行されるように構成されているが、例えば、抽選登録処理において抽選に登録したユーザが所定数に達したことを契機として抽選が実行されてもよい。

ここで、本実施形態のゲームでは、ユーザの通信端末１０が、野球の試合（イベント）が行われる試合時間帯（イベント期間内）に当該試合が行われるスタジアム（所定領域）に存在する場合に、当該ユーザに関係付けられた仲間ユーザに関する情報に基づいて、抽選における当該ユーザの当選確率を変動する処理を行うようになっている。この処理は、取得手段５５、判別手段５６及び抽選制御手段５７によって実行される。以降では、各手段の詳細について説明する。

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

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

判別手段５６は、ユーザの通信端末１０が、野球の試合（所定のイベント）が行われる試合時間帯（イベント期間内）に当該試合が行われるスタジアム（所定領域）に存在するか否かを、位置情報に基づいて判別する機能を備える。
ここで、試合時間帯には、試合開始から試合終了までの時間だけではなく、例えば、試合開始前の練習時間や試合終了後のファンサービスの時間等が含まれてもよい。また、「所定のイベント」とは、所定期間の間開催される行事等であれば何でもよいが、例えば、ゲームにおいて模擬された現実世界のイベントであってもよい。ゲームにおいて模擬された現実世界のイベントとは、例えば、野球ゲームの場合には野球の試合であってよいし、サッカーゲームの場合にはサッカーの試合であってよいし、音楽ゲームの場合には音楽の演奏会であってよい。さらに、「所定領域」とは、例えば、野球やサッカー、アメリカンフットボールの試合等が行われるスタジアムであってもよいし、ゲームセンター、競馬場、コンサートホールやその他所定のイベントが行われる会場であってもよい。また、「所定領域」は、ゲームに関する領域であるか否かにかかわらず、例えば販売や展示等のイベントが行われる領域であれば任意に設定することができる。例えば、「所定領域」は、ゲームセンターなどの遊技施設、ゲームの販売を行う店舗あるいはゲームの展示を行う展示会場などであってもよいし、「東京都港区赤坂九丁目」などの地域の区画などであってもよい。

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

抽選制御手段５７は、ユーザ（第１のユーザ）の通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された場合に、当該ユーザに関係付けられた仲間ユーザ（第２のユーザ）に関する情報に基づいて、抽選における当該ユーザ（第１のユーザ）の当選確率が変動するように抽選手段５４を制御する機能を備える。
ここで、仲間ユーザに関する情報とは、例えば、仲間ユーザの数であってもよいし、仲間ユーザに対応付けられた情報（例えば、仲間ユーザがゲーム上保有するポイントの量やアイテムなどの数、仲間ユーザにより実行されたゲーム上の対戦数、ゲーム上の対戦における仲間ユーザの勝利数又は敗北数、仲間ユーザのゲームの進行度あるいは仲間ユーザのゲーム上の技能レベルなど）であってもよい。

抽選制御手段５７の機能は、以下のように実現される。なお、ここでは、ユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別された場合に、当該ユーザの仲間ユーザの数が多いほど（仲間ユーザに関する情報に基づいて）、抽選における当該ユーザの当選確率が高くなる（変動する）場合を一例として説明する。
ゲームサーバ２０のＣＰＵ２１は、例えば、図１３に例示した抽選制御データをゲームデータベース３２に予め格納してもよい。図１３に抽選制御データの構成例を示す。図１３に示すように、抽選制御データには、仲間ユーザの数（仲間の人数）に応じた当選確率の調整値が含まれる。ここで、当選確率の調整値は、例えば、仲間ユーザの数が多くなるほど、当選確率が高くなるように設定されてもよい。図１３を参照して説明すると、例えば、ユーザの仲間ユーザの数が１名の場合には、抽選における当該ユーザの当選確率が３０％増加することになる。また、ユーザの仲間ユーザの数が２〜５名の場合には、抽選における当該ユーザの当選確率が４０％増加し、当該ユーザの仲間ユーザの数が６〜１０名の場合には、抽選における当該ユーザの当選確率が５０％増加することになる。さらに、当該ユーザの仲間ユーザの数が１０名以上の場合には、抽選における当該ユーザの当選確率が７０％増加することになる。つまり、抽選における当選確率のデフォルト値が３０％に設定されている場合には、仲間ユーザの数が１０名以上のユーザの抽選における当選確率は１００％になる。なお、当選確率の調整値は、所定の演算式等を用いて、仲間ユーザの数を当該演算式に当てはめることで求められてもよい。
ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別された場合に、当該ユーザの仲間ユーザの数をユーザデータベース３１から取得し、抽選制御データを参照して当選確率の調整値を決定する。そして、ＣＰＵ２１は、決定した当選確率の調整値を、エントリーデータ内の当該ユーザのユーザＩＤに対応する当選確率の値に加算する。上述したように、抽選手段５４は、エントリーデータ内の当選確率を参照して当選確率を調整した上で抽選処理を行うように構成されている。このため、抽選手段５４は、抽選制御手段５７の機能によってエントリーデータ内の当選確率の値が更新されることによって、抽選におけるユーザの当選確率が変動するように制御されることになる。

なお、上述した例では、ユーザの仲間ユーザの数が多いほど、抽選における当該ユーザの当選確率が高くなる場合について説明したが、当選確率の変動パターンは、この場合に限られない。例えば、ユーザの仲間ユーザの数が所定の閾値以上になった場合、仲間ユーザの数が多いほど、抽選における当該ユーザの当選確率が低減するように構成されてもよい。この構成によれば、仲間ユーザの数の増加に伴ってユーザの当選確率が極めて高くなることに起因して、他のユーザとの間で公平性を損なうことのない仕組みとすることができる。
また、抽選におけるユーザの当選確率は、例えば、当該ユーザの仲間ユーザがゲーム上保有するポイントの量やアイテムなどの数が多いほど、高く又は低くなるように設定されてもよいし、当該ユーザの仲間ユーザによって実行されたゲーム上の対戦数やゲーム上の対戦における仲間ユーザの勝利数又は敗北数が多いほど、高く又は低くなるように設定されてもよい。
さらに、ＣＰＵ２１は、抽選にエントリーしたユーザが当該抽選に当選しなかった場合には、当該ユーザが次回の抽選にエントリーし、且つ、当該ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別されたときに、当選確率を高めるように調整してもよい。例えば、１回目の抽選におけるユーザの当選確率がデフォルト値（例えば３０％）であり、且つ、当該ユーザが１回目の抽選に当選しなかった場合には、ＣＰＵ２１は、当該ユーザが２回目の抽選にエントリーし、且つ、２回目の抽選において当該ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別されたときに、当該ユーザの当選確率を例えば６０％に設定してもよい。また、ＣＰＵ２１は、当該ユーザが２回目の抽選に当選しなかった場合には、当該ユーザが３回目の抽選にエントリーし、且つ、３回目の抽選において当該ユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別されたときに、当該ユーザの当選確率を例えば１００％に設定してもよい。なお、ＣＰＵ２１は、当該ユーザが抽選に当選した場合には、当該ユーザの抽選確率をデフォルト値に戻す。

付与手段５８は、ユーザ（第１のユーザ）が抽選に当選した場合に、当該ユーザに対してゲーム上の特典を付与する機能を備える。
ここで、「ユーザに対してゲーム上の特典を付与する」とは、特典（例えば、ポイント、アイテムなど）に関する情報をユーザのユーザＩＤに対応付けた状態で所定の記憶装置（例えばユーザデータベース３１が構成された記憶装置など）に記憶させることであってよい。また、所定の記憶装置は、例えばゲームサーバ２０に設けられていてもよいし、ユーザの通信端末１０などに設けられていてもよい。
また、「ゲーム上の特典」とは、例えば、ゲーム上のポイント若しくはアイテム、又はゲーム上の有利な効果などであってよい。ここで、アイテムとは、例えば、ユーザがゲーム上保有することができるものであってもよいし、ユーザがゲーム上で収集する必要があるものであってもよいし、ユーザがゲーム上で有利な効果を得られるものなどであってもよい。例えば、アイテムは、キャラクタのパラメータやポイントなどを回復する回復薬や、キャラクタの能力を上昇させる薬品などであってもよいし、キャラクタが使用する武器や防具などであってもよい。なお、キャラクタとは、例えばゲーム上の仮想的な人物や生物、若しくはモンスター等であり、それらがカード等に表示されているものをも含む。
なお、ゲーム上のポイントやアイテムが特典として付与される場合には、当該ポイントやアイテムは、ゲーム上の通常のプレイにおいて入手可能なものと比べて、多量のものあるいは希少価値の高いものであることが好ましい。例えば、アイテムの一例として選手カードが付与される場合には、上述したアイテム抽選処理では入手困難なレアカードが付与されるようにしてもよい。あるいは、例えば、アイテム抽選処理において、レアカードを必ず入手できるようにゲーム上の設定を調整するアイテム（例えば、特殊な抽選チケット）が付与されるようにしてもよい。この場合、特殊な抽選チケットが付与されたユーザは、任意のタイミングで当該抽選チケットをゲーム上使用することにより、レアカードを入手することが可能となる。
さらに、ゲーム上の有利な効果とは、例えば、ユーザがゲーム上保有するアイテム（例えば選手カード）のパラメータを上昇させることであってもよいし、アイテムを用いることなくキャラクタの能力を向上させることであってもよいし、ユーザが特殊なアイテムを入手できることであってもよい。また、ゲーム上の有利な効果とは、ゲームにおけるシナリオの進行を進め易くするように設定を調整することであってもよく、例えば、ユーザの操作に応じて消費するゲーム上の各種ポイント（例えば、行動ポイント、運営ポイント、強化ポイントなど）の消費量を通常よりも低減させることであってもよいし、ユーザが上記の各種ポイントを入手できることであってもよい。なお、仲間を作ることでポイントを入手できる構成が既に設けられている場合には、そのポイントよりも多くのポイントを入手できるようにすればよい。さらに、ゲーム上の有利な効果とは、間接的にゲームを有利に進められるようにゲーム上の設定を調整することであってもよく、例えば、ユーザが特殊なアイテムを取得可能なイベントを発生させることでもよいし、強化処理において選手カードの能力値が大幅に上昇する確率を上昇させることであってもよい。
さらにまた、「ゲーム上の特典」とは、ユーザが実行するゲームと同一のゲーム上の特典であってもよいし、ユーザが実行するゲームとは異なる他のゲーム上の特典であってもよい。ここで、異なる他のゲームとは、例えば一つのゲームシリーズのように、ゲームの構成やジャンルがほぼ同じであるがゲームのタイトルが異なる場合（例えば、「ゲームＡ（２０１１年度版）」と「ゲームＡ（２０１２年度版）」など）も含む。

付与手段５８の機能は、以下のようにして実現できる。なお、ユーザに対して付与される特典の内容については、予めＲＯＭ２２に記録されているものとする。ゲームサーバ２０のＣＰＵ２１は、ユーザが抽選に当選した場合、当該ユーザに対して特典を付与する処理を行う。なお、特典を付与する処理とは、特典の付与対象となるユーザのユーザＩＤと、付与される特典（例えばポイントやアイテムなど）とを関連付ける処理であってよい。例えば、所定量の強化ポイントが特典として付与される場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（所定量の強化ポイントを加算する処理）を行ってよい。また、特典としてアイテムやポイントなどがユーザに付与される場合には、アイテムやポイントなどは、所定の特典付与期間内に複数回付与されてもよい。

なお、ユーザに付与される特典は、各種ポイント（行動ポイント、運営ポイント、強化ポイント、エールポイント）の付与量を、所定の特典付与期間の間、通常（つまり、特典が付与されない状態）よりも増加させることであってもよい。ここで、各種ポイントのうち少なくとも一種類のポイントの付与量が増加するようにしてもよい。
この場合、ユーザは、特典を得ることにより、ゲームを有利に進めることができる。例えば、特典が、行動ポイントの付与量を増加させることである場合、通常であれば所定時間（例えば３分）が経過する度に行動ポイントが１ポイントずつ回復（増加）するのに対し、特典付与期間内では、行動ポイントが３ポイントずつ回復（増加）してもよい。この場合、ユーザは、スカウト処理を実行する際に、１回の探索を行うために必要な行動ポイントを通常よりも早期に得ることができるので、ゲームの進行度を通常よりも早く上げることができるというメリットが得られる。

また、特典が、ユーザの保有する選手カードのパラメータを、特典付与期間の間上昇させることである場合、ＣＰＵ２１は、特典を付与する処理として、特典付与期間の間、付与対象となるユーザの保有カードのパラメータを所定の割合だけ加算するようにしてもよい。例えば、試合処理における試合の結果が選手カードのパラメータに基づいて決定される場合には、ユーザは、特典付与期間内の試合処理において、他のユーザとの試合に勝利する可能性を高めることができるので、他のユーザと比べてゲームをより優位に進められるようになる。なお、ＣＰＵ２１は、特典付与期間が終了すると、保有カードのパラメータを元の値に戻す。
さらに、特典が、本実施形態のゲームと異なる他のゲーム上の特典である場合、ＣＰＵ２１は、特典の付与対象となるユーザのユーザＩＤと、特典を付与することを通知するためのメッセージ等とを、他のゲームの実行を制御するゲームサーバに送信すればよい。この場合、他のゲームの実行を制御するゲームサーバは、本実施形態におけるゲームサーバ２０と同様に構成されてもよい。例えば、他のゲームの実行を制御するゲームサーバでは、上記のユーザＩＤ及びメッセージ等を受信すると、当該ユーザＩＤに対応するユーザに対して特典が付与される処理を実行するように構成されてもよい。

なお、付与手段５８は、抽選に当選しなかったユーザに対して、所定量のポイントやアイテムなどを付与してもよい。ここで、抽選に当選しなかったユーザに付与されるポイントやアイテムなどは、上記特典よりも小さいことが好ましい。例えば、特典としてポイントやアイテムが付与される場合には、特典のポイント量（例えば、１００００強化ポイント）よりも少ないポイント（例えば、１０００強化ポイント）が付与されてもよいし、特典のアイテム（例えば、レア度が４あるいは５の選手カード）よりも希少価値の少ないアイテム（例えば、レア度が１あるいは２の選手カード）が付与されてもよい。この場合、ＣＰＵ２１は、上述した特典を付与する処理と同様の処理を行えばよい。

（６）本実施形態のゲーム制御装置の主要な処理のフロー
次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１４のフローチャートを参照して説明する。図１４は、本実施形態のゲームの抽選登録処理における処理内容の一例を示すフローチャートである。

先ず、図８に示すトップページ上でユーザの通信端末１０のトップページ上でメニュー
ｍ６の選択操作がなされ（ステップＳ１００：ＹＥＳ）、その選択結果を受信すると、ゲ
ームサーバ２０のＣＰＵ２１は、図１０に例示するウェブページを表示するためのＨＴＭ
Ｌデータを生成して、当該ユーザの通信端末１０宛に送信する。この場合、ユーザの通信端末１０には、図１０に示すウェブページが表示される（ステップＳ１１０）。次に、ユーザがメニューｍ１１の選択操作を行うと（ステップＳ１２０：ＹＥＳ）、ゲームサーバ２０のＣＰＵ２１は、メニューｍ１１の選択操作を行ったユーザのユーザＩＤを、ゲームデータベース３２内のエントリーデータに記録する（ステップＳ１３０）。このとき、ＣＰＵ２１は、記録したユーザＩＤに対応する当選確率の項目にＮＵＬＬデータを記録する。つまり、ユーザが抽選にエントリーした時点では、抽選における当選確率は、デフォルトの値（例えば３０％）に設定されている。
なお、ステップＳ１２０の処理において、メニューｍ１１の選択操作が行われることな
く所定時間が経過した場合（ステップＳ１２０：ＮＯ）、ＣＰＵ２１は、抽選登録処理を
終了してもよい。この場合、ＣＰＵ２１は、図８に示すトップページを表示するためのＨ
ＴＭＬデータを生成して、ユーザの通信端末１０宛に送信してもよい。

次に、本実施形態のゲーム制御装置により行われる主要な処理のフローの一例について、図１５のフローチャートを参照して説明する。図１５は、本実施形態のゲームにおいて抽選が行われるときの処理内容の一例を示すフローチャートである。なお、ここでは、野球の試合時間帯（イベント期間）の所定時刻（抽選時刻）に抽選が行われる場合を一例として説明する。

ゲームサーバ２０のＣＰＵ２１は、例えばＣＰＵ２１に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると（ステップＳ２００：ＹＥＳ）、図１１に例示したエントリーデータに記録されたユーザＩＤに対応するユーザを対象とした抽選処理を開始する。また、ＣＰＵ２１は、抽選処理の開始に当たって、位置情報の送信要求メッセージを、エントリーデータに記録されたユーザＩＤに対応するユーザの通信端末１０宛に送信する（ステップＳ２１０）。なお、ユーザの通信端末１０固有の端末識別情報は、例えば登録処理（ユーザ登録）の際に、ユーザＩＤに対応付けられた状態でユーザデータに記録されてもよい。

次に、通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、ユーザＩＤと対応付けて、ゲームサーバ２０に送信する。
一方、ゲームサーバ２０のＣＰＵ２１は、位置情報を通信端末１０から受信する（取得する）と、取得した位置情報をゲームデータベース３２内の現在位置データに記録する（ステップＳ２２０）。

次に、ゲームサーバ２０のＣＰＵ２１は、エントリーデータに記録されたユーザＩＤに対応するユーザのうち、通信端末１０が、野球の試合（イベント）の試合時間帯（イベント期間内）にスタジアム（所定領域）に存在するユーザを抽出する（ステップＳ２３０）。具体的に説明すると、ＣＰＵ２１は、エントリーデータに記録されたユーザＩＤごとに、現在位置データ内の当該ユーザＩＤに対応する最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、当該ユーザＩＤに対応する最新の位置情報の取得日時が野球の試合時間帯に含まれるか否かを判別する。ここで、ＣＰＵ２１は、最新の位置情報の緯度及び経度がスタジアム内に含まれ、且つ、最新の位置情報の取得日時が野球の試合時間帯に含まれる場合、当該ユーザＩＤに対応するユーザの通信端末１０が試合時間帯にスタジアム内に存在すると判別する。そして、ＣＰＵ２１は、試合時間帯にスタジアム内に存在すると判別された通信端末１０に対応するユーザＩＤをエントリーデータから抽出する。

次いで、ＣＰＵ２１は、抽出したユーザの仲間の数に応じて、当選確率を変動する（ステップＳ２４０）。具体的に説明すると、ＣＰＵ２１は、ステップＳ２３０にて抽出したユーザＩＤのユーザデータを参照し、当該ユーザＩＤに対応する仲間ユーザの数を取得する。そして、ＣＰＵ２１は、抽選制御データを参照して当該ユーザＩＤに対応するユーザの当選確率の調整値を決定する。そして、ＣＰＵ２１は、決定した当選確率の調整値を、エントリーデータ内の当該ユーザＩＤに対応する当選確率の値に加算する。

次に、ＣＰＵ２１は、エントリーデータに記録されたユーザＩＤに対応するユーザごとに、抽選処理を行う（ステップＳ２５０）。なお、抽選処理における抽選方法は、上述したとおりである。この場合、ＣＰＵ２１は、エントリーデータのユーザＩＤに対応する当選確率にデフォルト値（図１１の例では３０％）以外の値が設定されている場合には、記録された値に基づいて当選確率を調整した上で抽選処理を行う。

そして、ＣＰＵ２１は、抽選に当選したユーザに対して特典を付与する（ステップＳ２６０）。例えば、所定量の強化ポイントが特典として付与される場合、ＣＰＵ２１は、付与対象となるユーザのユーザＩＤのユーザデータにおける強化ポイントを書き換える処理（所定量の強化ポイントを加算する処理）を行ってよい。
また、ＣＰＵ２１は、抽選にエントリーしたユーザに抽選結果を通知するためのウェブページを表示するためのＨＴＭＬデータを生成し、抽選にエントリーした全てのユーザの通信端末１０宛に送信する（ステップＳ２７０）。ここで、ＣＰＵ２１は、抽選に当選したユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「おめでとうございます。抽選に当選しましたので、プレゼントを贈ります。」などのメッセージが含まれてもよい。一方、ＣＰＵ２１は、抽選に当選しなかったユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「ごめんなさい。残念ですが抽選に外れてしまいました。」などのメッセージが含まれてもよい。また、ＣＰＵ２１は、例えば抽選にエントリーしたことに対する報酬として、抽選に当選しなかったユーザに対して所定量のポイントやアイテムなどを付与してもよい。

上述したように、実施形態のゲーム制御装置によれば、ゲーム上の抽選におけるユーザの当選確率は、当該ユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別された場合に、当該ユーザの仲間ユーザに関する情報に基づいて変動するようになっている。これにより、ユーザは、例えば、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、他のユーザと関係付ける（仲間になる）ことが動機付けられる。このため、ユーザ間の交流を促進することができ、ソーシャル性の高いゲームを実現することができる。
また、ユーザは、例えば、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、試合時間帯にスタジアムに出向く（野球の試合を観戦する）ことが動機付けられる。この場合、スタジアムで野球の試合を観戦することが抽選に当選する要因になり得ることから、ユーザは、野球の試合とゲームが連動しているような感覚を得ることができる。このため、通信端末１０の位置情報を利用する従来のゲームでは実現することができない興趣性の高いゲームを実現することができる。一方、イベントの運営側にとっては、ユーザをイベント会場（例えば、スタジアム、ゲームセンター、競馬場、コンサートホールなど）に来場させる誘因力あるシステムを構築することができる。

（７）変形例
以下、上述した実施形態の変形例について説明する。

（７−１）変形例１
上記実施形態において、抽選手段５４は、試合時間帯（イベント期間内）にスタジアム（所定領域）に通信端末１０が存在すると判別されたユーザに対して抽選を行ってもよい。
本変形例では、抽選対象となるユーザは、自身の通信端末１０が試合時間帯にスタジアムに存在すると判別されたユーザに限定される。つまり、ユーザにとっては、試合時間帯にスタジアムに出向かなければ（スタジアムで野球の試合を観戦しなければ）、ゲーム上の特典が付与される機会を得ることができない。このため、ユーザは、ゲーム上の特典が付与される機会を得るために、スタジアムで野球の試合を観戦することが動機付けられる。これにより、野球の試合の運営側にとっては、ユーザをスタジアムに来場させる誘因力を高めたシステムを構築することができる。

本変形例における抽選手段５４の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１５に示したフローのステップＳ２５０において、エントリーデータに記録されたユーザＩＤのうち、図１５に示したフローのステップＳ２３０にて抽出されたユーザＩＤに対応するユーザのみに対して抽選処理を行ってもよい。この場合、ＣＰＵ２１は、エントリーデータに記録されたユーザＩＤのうち、ステップＳ２３０にて抽出されなかったユーザＩＤに対応するユーザに対する抽選処理を行わない。
また、ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアムに存在する場合に、当該ユーザによる抽選登録処理が実行されるように構成してもよい。具体的に説明すると、ＣＰＵ２１は、図１４に示したフローのステップＳ１２０においてメニューｍ１１が選択操作されたことを認識すると、位置情報の送信要求メッセージを、メニューｍ１１の選択操作を行ったユーザの通信端末１０宛に送信する。そして、ＣＰＵ２１は、位置情報を通信端末１０から受信すると、位置情報の緯度及び経度と、位置情報の取得日時とに基づいて、通信端末１０が試合時間帯にスタジアムに存在するか否かを判別する。ＣＰＵ２１は、通信端末１０が試合時間帯にスタジアムに存在すると判別した場合に、当該ユーザのユーザＩＤをエントリーデータに記録する。一方、ＣＰＵ２１は、通信端末１０が試合時間帯にスタジアムに存在しないと判別した場合に、当該ユーザのユーザＩＤをエントリーデータに記録しない。この場合、ＣＰＵ２１は、エントリーデータに記録されたユーザＩＤに対応するユーザを対象として抽選を行うようにすればよい。

（７−２）変形例２
上記実施形態において、抽選制御手段５７は、仲間ユーザ（第２のユーザ）の通信端末１０のうち試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された通信端末１０に関する情報に基づいて、抽選におけるユーザ（第１のユーザ）の当選確率が変動するように抽選手段５４を制御してもよい。
例えば、ユーザと関係付けられた仲間ユーザの通信端末１０のうち、試合時間帯にスタジアムに存在すると判別された通信端末１０の数が多いほど、抽選におけるユーザの当選確率が高くなるように構成されてもよい。つまり、スタジアムにおいて野球を観戦する仲間ユーザの数が多いほど、ユーザの当選確率が高くなるように構成されてもよい。この場合、ユーザは、抽選に当選する可能性、すなわちゲーム上の特典を得る可能性を高めるために、仲間ユーザとスタジアムで野球を観戦することが動機付けられる。これにより、ゲーム上及び現実世界におけるユーザ間の交流を促進することができるため、ソーシャル性をさらに高めたゲームを実現することができる。

本変形例における抽選制御手段５７の機能は、以下のようにして実現される。なお、ここでは、スタジアムにおいて野球を観戦する仲間ユーザの数が多いほど、ユーザの当選確率が高くなる場合を一例として説明する。
ゲームサーバ２０のＣＰＵ２１は、例えば、図１６に例示した抽選制御データをユーザデータベース３１に予め格納してもよい。図１６に本変形例における抽選制御データの構成例を示す。図１６に例示した抽選制御データの構成が図１３に示した抽選制御データの構成と異なる点は、ユーザの仲間ユーザのうち、試合時間帯（イベント期間内）にスタジアム（所定領域）に存在する仲間ユーザの数に応じて、ユーザの当選確率の調整値が設定されている点にある。図１６を参照して説明すると、例えば、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が１名の場合には、抽選におけるユーザの当選確率が３０％増加することになる。また、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が２〜５名の場合には、抽選における当該ユーザの当選確率が４０％増加する。さらに、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が６〜１０名の場合には、抽選における当該ユーザの当選確率が５０％増加する。さらにまた、仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が１０名以上の場合には、抽選における当該ユーザの当選確率が７０％増加する。なお、当選確率の調整値は、所定の演算式等を用いて、仲間ユーザのうち試合時間帯にスタジアムに存在する仲間ユーザの数を当該演算式に当てはめることで求められてもよい。
ＣＰＵ２１は、ユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別された場合に、当該ユーザの仲間ユーザの通信端末１０に対して、位置情報の送信要求メッセージを送信する。そして、ＣＰＵ２１は、当該ユーザの仲間ユーザの通信端末１０のうち、試合時間帯にスタジアムに存在すると判別された通信端末１０の数を集計し、抽選制御データを参照して当該ユーザの当選確率の調整値を決定する。そして、ＣＰＵ２１は、決定した当選確率の調整値を、エントリーデータ内の当該ユーザのユーザＩＤに対応する当選確率の項目に記録する。

なお、上述した例では、ユーザの仲間ユーザのうち、試合時間帯にスタジアムに存在する仲間ユーザの数が多いほど、抽選における当該ユーザの当選確率が高くなる場合について説明したが、当選確率の変動パターンは、この場合に限られない。例えば、試合時間帯にスタジアムに存在する仲間ユーザの数が所定の閾値以上になった場合、試合時間帯にスタジアムに存在する仲間ユーザの数が多いほど、抽選におけるユーザの当選確率が低減するように構成されてもよい。この構成によれば、試合時間帯にスタジアムに存在する仲間ユーザの数の増加に伴ってユーザの当選確率が極めて高くなることに起因して、他のユーザとの間で公平性を損なうことのない仕組みとすることができる。
また、抽選におけるユーザの当選確率は、例えば、試合時間帯にスタジアムに存在する仲間ユーザがゲーム上保有するポイントの量やアイテムなどの数の合計が多いほど、高く又は低くなるように設定されてもよいし、試合時間帯にスタジアムに存在する仲間ユーザによって実行されたゲーム上の対戦数やゲーム上の対戦における仲間ユーザの勝利数又は敗北数の合計が多いほど、高く又は低くなるように設定されてもよい。

（７−３）変形例３
上記実施形態において、付与手段５８は、ユーザ（第１のユーザ）が抽選に当選し、且つ、当該ユーザの通信端末１０が試合時間帯（イベント期間）の終了時期にスタジアム（所定領域）に存在すると判別された場合に、当該ユーザに対して特典を付与してもよい。
例えば、ユーザが抽選に当選すると、当該ユーザに対してゲーム上の特典が即時付与されるように構成されている場合、スタジアムで野球の試合を観戦したことに基づいて抽選に当選したユーザは、特典が付与されると直ちにスタジアムを去ることが考えられる。このような行為は、ユーザが自らの利益を得ることのみを目的としてスタジアムで野球の試合を観戦することになるため、野球の試合の運営側にとっては好ましくない。
本変形例によれば、ユーザの通信端末１０の位置についての判別を試合時間帯の終了時期に行うことにより、例えば、ユーザの通信端末１０が試合時間帯の終了時期にスタジアムに存在しないと判別された場合には、当該ユーザに対して特典を付与しない仕組みとすることができる。これにより、ユーザは、特典を得るために、試合時間帯にスタジアムに留まることが動機付けられる。したがって、上記の行為を抑制することができる。また、ユーザにイベント参加、観戦等を十分行ってもらえることにより、イベント運営側にとっても有益なゲームを実現することができる。

本変形例における付与手段５８の機能は、以下のようにして実現される。
ゲームサーバ２０のＣＰＵ２１は、例えば、図１５に示すフローのステップＳ２４０において当選確率が変動したユーザが抽選に当選した場合、試合時間帯の終了時期が到来するまでの間、当該ユーザに対して特典を付与する処理を行わなくてもよい。そして、ＣＰＵ２１は、試合時間帯の終了時期が到来したときに、当該ユーザの通信端末１０に対して、位置情報の送信要求メッセージを送信する。そして、ＣＰＵ２１は、当該ユーザの通信端末１０がスタジアムに存在すると判別した場合に、当該ユーザに対して特典を付与する処理を行う。なお、試合時間帯の終了時期に関する情報（例えば、試合の終了時刻や試合終了後のファンサービスの終了時刻など）は、ゲームデータベース３２に逐次記録されるようにしてもよい。

（７−４）変形例４
上記実施形態において、特典には、有効期間が設定されており、前記特典が野球の試合Ａ（第１のイベント）に基づいて付与された場合に、当該特典の有効期間の終了時期は、前記特典の付与以降の時期であって、試合Ａ以降に行われる野球の試合Ｂ（第２のイベント）の開始以前の時期に設定されてもよい。
ここで、「第２のイベント」は、「第１のイベント」と同じイベントであってもよいし、異なるイベントであってもよい。例えば、第１のイベントが野球の試合の場合には、第２のイベントは、野球の試合であってもよいし、サッカーの試合であってもよいし、音楽の演奏会などであってもよい。
例えば、ユーザ（第１のユーザ）が試合Ａの試合時間帯に行われた抽選に当選した場合には、当該ユーザに付与される特典の有効期間は、試合Ｂの開始以前の時期に終了することになる。この場合、ユーザは、特典を続けて得る可能性を高めるために、スタジアムで試合Ｂを観戦することが動機付けられる。これにより、抽選に当選したユーザに対してスタジアムで試合Ｂを観戦するように誘導することができるので、イベントの運営側にとっては、ユーザをイベント会場に来場させる誘因力をさらに高めたシステムを構築することができる。

本変形例において、ゲームサーバ２０のＣＰＵ２１は、例えば、図１７に例示した特典付与データをゲームデータベース３２に予め格納してもよい。図１７に特典付与データの構成例を示す。図１７に示すように、特典付与データは、特典の付与対象となるユーザ（抽選に当選したユーザ）のユーザＩＤごとに、特典の有効期間などが含まれるデータである。有効期間に記述されるデータは、例えば、特典が付与された日時を有効期間の開始時期とし、試合Ｂの開始日時を有効期間の終了時期としてもよい。図１７を参照して説明すると、例えば、「０００００１」というユーザＩＤに対応するユーザが試合Ａの試合時間帯に行われた抽選に当選し、且つ、当選に基づく特典が試合Ａの終了時期に付与される場合、試合Ａの終了時期（図の例では、２０１２年４月１日２１時００分）が有効期間の開始時期として特典付与データに記録される。また、試合Ａ以降に開催される試合Ｂの開始時期（図の例では、２０１２年４月２日１８時００分）が有効期間の終了時期として特典付与データに記録される。
ＣＰＵ２１は、図１５に示すフローのステップＳ２６０において、抽選に当選したユーザに特典を付与する処理を行うとともに、当該ユーザのユーザＩＤと、特典の有効期間とを特典付与データに記録する。ここで、アイテム又はポイントが特典として付与された場合を一例として説明すると、ＣＰＵ２１は、ユーザが、特典として付与されたアイテム又はポイントをゲーム上で使用する際に、特典付与データを参照して、使用対象のアイテム又はポイントが当該ユーザのユーザＩＤに対応する有効期間の範囲内か否かを判別する。そして、ＣＰＵ２１は、有効期間の範囲内であると判別した場合に、当該アイテム又はポイントを使用する処理を行ってもよい。一方、ＣＰＵ２１は、有効期間の範囲外であると判別した場合、当該アイテム又はポイントを使用する処理を行わなくてもよい。また、ＣＰＵ２１は、例えば、所定時間（例えば１分）が経過するごとに特典付与データを参照し、有効期間が終了したアイテム又はポイントを消去する処理を行ってもよい。

（７−５）変形例５
上記実施形態において、付与手段５８は、野球の試合（イベント）の状況に応じて、特典を変動させてもよい。
ここで、「イベントの状況」とは、例えば、イベントの参加人数であってもよいし、イベントの進行度合いであってもよい。また、「イベントの状況」とは、例えば、イベントが野球やサッカーなどの競技である場合には、競技の結果（例えば試合結果）や競技時間などであってもよい。
例えば、スタジアムの来場者数（イベントの参加人数）が多いほど、抽選に当選することにより付与される特典が多くなるように構成されてもよい。この場合、抽選に当選したユーザは、付与される特典がスタジアムの来場者数に応じて変動することから、野球の試合とゲームが強く連動しているような感覚を得ることができる。このため、ゲームの興趣性をさらに高めることができる。

本変形例における付与手段５８の機能は、以下のようにして実現される。なお、ここでは、ユーザが来場したスタジアムを本拠地とするチーム（以降、ホームチームという。）の試合結果（イベントの状況）に応じて、特典が変動する場合を一例として説明する。ゲームサーバ２０のＣＰＵ２１は、例えば、図１８に示す設定例に基づき構成された設定用データをゲームデータベース３２に予め格納してもよい。図１８に示す設定例では、ホームチームの試合結果（ホームチームが敗北、引き分け、勝利）に応じて、異なる特典（図の例では強化ポイントの量）が付与されるように設定されている。図１８を参照して説明すると、特典は、例えば、ホームチームが大差（図の例では５点差以上）で敗北した場合を最小（図の例では５０００強化ポイント）として、ホームチームが小差（図の例では１〜４点差）で敗北した場合、ホームチームが引き分けた場合、ホームチームが小差（図の例では１〜４点差）で勝利した場合、ホームチームが大差（図の例では５点差以上）で勝利した場合の順に大きくなっていくように設定されている。この場合、より大きな特典（より多くの強化ポイント）が付与されることにより、ユーザにとってはゲームをより有利に進行させることができる。具体的に説明すると、付与される強化ポイントの量が多いほど、強化処理において選手カードを強化する回数を増やすことが可能となる。これにより、選手カードのパラメータを早めに上昇させることができるので、例えば、試合処理における試合の結果が選手カードのパラメータに基づいて決定される場合には、ユーザは、他のユーザとの試合に勝利する可能性を高めることができる。
なお、上述した設定例では、ホームチームが勝利した場合に大きな特典が付与されるように設定されているが、例えば、ホームチームが敗北した場合に大きな特典が付与されるように設定されてもよい。また、イベントの来場者が多いほど、大きな又は小さな特典が付与されるように設定されてもよい。さらに、イベント期間が長いほど、大きな又は小さな特典が付与されるように設定されてもよい。

（７−６）変形例６
上記実施形態において、付与手段５８は、ユーザ（第１のユーザ）及び仲間ユーザ（第２のユーザ）のそれぞれの通信端末１０が試合時間帯（イベント期間内）にスタジアム（所定領域）に存在すると判別された場合に、ユーザ又は仲間ユーザが抽選に当選すると、ユーザ及び仲間ユーザに対して、ゲーム上の特典を付与してもよい。
本変形例によれば、例えば、ユーザと、仲間ユーザとがスタジアムで野球の試合を観戦している場合に、ユーザ又は仲間ユーザが抽選に当選すれば、両者に特典が付与される。この場合、ユーザは、自らが抽選に当選しなくても、仲間ユーザが当選すれば特典を得ることができる。これにより、ユーザは、特典を得る可能性を高めるために、仲間ユーザとスタジアムで野球の試合を観戦することが動機付けられる。これにより、仲間関係の構築が活性化され、ソーシャル性のさらなる向上が期待できる。

本変形例における付与手段５８の機能は、以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、図１５に示すフローのステップＳ２６０において、当選したユーザに特典を付与する処理を行うとともに、当選したユーザのユーザＩＤに対応する仲間ユーザのユーザＩＤのうち、エントリーデータに記録されている（つまり、抽選登録処理を行った）仲間のユーザＩＤをユーザデータから抽出する。そして、ＣＰＵ２１は、抽出したユーザＩＤに対応する仲間ユーザの通信端末１０宛に、位置情報の送信要求メッセージを送信する。次に、ＣＰＵ２１は、位置情報を仲間ユーザの通信端末１０から受信すると、位置情報の緯度及び経度と、位置情報の取得日時とに基づいて、仲間ユーザの通信端末１０が試合時間帯にスタジアムに存在するか否かを判別する。ＣＰＵ２１は、仲間ユーザの通信端末１０が試合時間帯にスタジアムに存在すると判別した場合に、当該仲間ユーザに対して特典を付与する処理を行う。

（７−７）変形例７
上記実施形態のゲーム制御装置の変形例７の機能ブロック図を図１９に示す。図１９に示すように、この機能ブロック図は、図７に示したものとは、抽選制御手段５７を設けていない点で異なる。
本変形例において、抽選手段５４は、試合時間帯（イベント期間内）にスタジアム（所定領域）に通信端末１０が存在すると判別されたユーザ（第１のユーザ）と、当該ユーザに関係付けられた仲間ユーザ（第２のユーザ）とを対象としてゲーム上の抽選を行う機能を備える。ここで、仲間ユーザ（第２のユーザ）はスタジアムにいる必要はなく、その所在がどこであるかは問わない。本変形例の構成では、１回の抽選における抽選対象のユーザ数が、抽選にエントリーしたユーザの仲間ユーザ数に応じて実質的に増えることになるので、言わば、１回の抽選に対する抽選券の枚数を多くすることを擬似的に実現していることになる。
また、本変形例において、付与手段５８は、抽選に当選した当選ユーザ及び当該当選ユーザに関係付けられたユーザ（仲間ユーザ）のうち、試合時間帯（イベント期間内）にスタジアム（所定領域）に通信端末１０が存在すると判別されたユーザに対してゲーム上の特典を付与する機能を備える。
本変形例では、抽選対象となるユーザは、試合時間帯にスタジアムに通信端末１０が存在すると判別されたユーザだけでなく、当該ユーザに関係付けられた仲間ユーザをも服務ことになる。そして、当選ユーザ及び当該当選ユーザの仲間ユーザのうち、試合時間帯にスタジアムに通信端末１０が存在すると判別されたユーザに対してゲーム上の特典が付与される。この場合、試合時間帯にスタジアムに出向いたユーザは、自身が抽選に当選しなくても、仲間ユーザが抽選に当選すれば、その仲間ユーザがスタジアムにいなくてもゲーム上の特典を得ることができる。つまり、試合時間帯にスタジアムに出向いたユーザにとっては、仲間ユーザの数が多いほど、自身及び仲間ユーザの少なくとも何れかが抽選に当選する可能性を高めることができ、ひいてはゲーム上の特典を得る可能性を高めることができる。このため、ユーザは、ゲーム上の特典を得る可能性を高めるために、スタジアムで野球の試合を観戦すること及び多くの他のユーザと仲間になることが動機付けられる。

本変形例における抽選手段５４の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、例えば、図１１に例示したエントリーデータの代わりに、図２０に示すエントリーデータをゲームデータベース３２に記憶してもよい。図２０に示すエントリーデータは、抽選登録処理を行った（メニューｍ１１の選択操作を行った）ユーザのユーザＩＤと、当該ユーザＩＤに対応付けられた仲間のユーザＩＤとが記述されたデータである。ＣＰＵ２１は、例えば、ユーザがメニューｍ１１の選択操作を行うと、メニューｍ１１の選択操作を行ったユーザのユーザＩＤと、当該ユーザＩＤに対応する仲間のユーザＩＤとを、エントリーデータに記録する。
また、ＣＰＵ２１は、例えばＣＰＵ２１に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると、図２０に例示したエントリーデータに記録されたユーザＩＤに対応するユーザと、当該ユーザＩＤに対応する仲間のユーザＩＤに対応する仲間ユーザを対象とした抽選処理を行う。ここで、ＣＰＵ２１は、エントリーデータに記録されたユーザＩＤに対応するユーザのうち、試合時間帯にスタジアムに通信端末１０が存在しないと判別されたユーザ及び当該ユーザの仲間ユーザを抽選対象から除いてもよい。また、抽選処理は、例えば、エントリーデータに記録されたユーザＩＤ及び当該ユーザＩＤに対応する仲間のユーザＩＤから所定数のユーザＩＤをランダム、あるいは所定の規則に基づいて抽出することにより行われてもよい。この抽選処理の結果、抽出された所定数のユーザＩＤユーザのそれぞれに対応するユーザが、当選ユーザとなる。
なお、ユーザの仲間ユーザについて、抽選対象となるための条件を設けてもよい。例えば、ユーザの仲間ユーザのうち、当該ユーザとの関係度を示す親密度が所定の閾値以上の仲間ユーザを抽選対象としてもよい。ここで、親密度とは、仲間のユーザ間の関係性の高さを一定の基準で数値化したものであってもよく、例えば、ユーザ間の応援メッセージの送信あるいは受信の頻度（応援頻度）、ゲーム上で使用可能なアイテムなどのプレゼントを送信あるいは受信した回数（プレゼント回数）などに基づいて設定されてもよい。例えば、応援頻度やプレゼント回数が多いほど、親密度が高く設定されてもよい。この場合、ユーザは、抽選に当選する可能性を高めるために、抽選対象となり得る（つまり、親密度の高い）仲間ユーザの数を増やすことが動機付けられる。これにより、ユーザ間の交流をさらに促進することができるので、ソーシャル性を高めることができる。

次に、本変形例における付与手段５８の機能は、例えば以下のようにして実現される。ゲームサーバ２０のＣＰＵ２１は、当選ユーザ及び当該当選ユーザの仲間ユーザの通信端末１０に対して、位置情報の送信要求メッセージを送信する。そして、ＣＰＵ２１は、当選ユーザ及び当該当選ユーザの仲間ユーザのうち、通信端末１０がスタジアムに存在すると判別されたユーザに対して特典を付与する処理を行う。ここで、当選ユーザと、特典が付与されるユーザとの関係について、図２０のエントリーデータを参照して説明する。例えば、ユーザＩＤが「００２２４４」のユーザが、試合時間帯にスタジアムに出向いている場合、当該ユーザ及び当該ユーザの仲間ユーザ（ユーザＩＤは「１２１２１２，…」）のうち少なくとも一人のユーザが当選ユーザになると、ユーザＩＤが「００２２４４」のユーザに対して特典が付与される。なお、この場合、仲間ユーザが当選ユーザになったとしても、当該仲間ユーザが試合時間帯にスタジアムに出向いていなければ、当該仲間ユーザに対して特典が付与されない。

次に、本変形例のゲーム制御装置により行われる主要な処理のフローの一例について、図２１のフローチャートを参照して説明する。図２１は、ゲーム上の抽選が行われるときの処理内容の一例を示すフローチャートである。なお、ここでは、野球の試合時間帯（イベント期間）の所定時刻（抽選時刻）に抽選が行われる場合を一例として説明する。

ゲームサーバ２０のＣＰＵ２１は、例えばＣＰＵ２１に内蔵されたタイマによって所定の抽選時刻が到来したことを認識すると（ステップＳ３００：ＹＥＳ）、図２０に例示したエントリーデータに記録されたユーザＩＤに対応するユーザ及び当該ユーザの仲間ユーザを対象とした抽選処理を開始する。また、ＣＰＵ２１は、抽選処理の開始に当たって、位置情報の送信要求メッセージを、エントリーデータに記録されたユーザＩＤに対応するユーザの通信端末１０宛に送信する（ステップＳ３１０）。なお、ユーザの通信端末１０固有の端末識別情報は、例えば登録処理（ユーザ登録）の際に、ユーザＩＤに対応付けられた状態でユーザデータに記録されてもよい。

次に、通信端末１０のＣＰＵ１１は、位置情報の送信要求メッセージを受信すると、通信端末１０の現在位置をＧＰＳ測位部１８に測位させる。そして、ＣＰＵ１１は、ＧＰＳ測位部１８の測位によって得られた位置情報を、ユーザＩＤと対応付けて、ゲームサーバ２０に送信する。
一方、ゲームサーバ２０のＣＰＵ２１は、位置情報を通信端末１０から受信する（取得する）と、取得した位置情報をゲームデータベース３２内の現在位置データに記録する（ステップＳ３２０）。

次に、ゲームサーバ２０のＣＰＵ２１は、エントリーデータに記録されたユーザＩＤに対応するユーザのうち、試合時間帯（イベント期間内）にスタジアム（所定領域）に通信端末１０が存在すると判別されたユーザと、当該ユーザの仲間ユーザとを対象としてゲーム上の抽選処理を行う（ステップＳ３３０）。抽選処理の結果、例えば所定数のユーザが当選ユーザとなる。

次いで、ＣＰＵ２１は、当選ユーザ及び当該当選ユーザの仲間ユーザのうち、試合時間帯（イベント期間内）にスタジアム（所定領域）に通信端末１０が存在すると判別されたユーザに対して特典を付与する処理を行う（ステップＳ３４０）。

また、ＣＰＵ２１は、抽選にエントリーしたユーザに抽選結果を通知するためのウェブページを表示するためのＨＴＭＬデータを生成し、抽選にエントリーした全てのユーザの通信端末１０宛に送信する（ステップＳ３５０）。ここで、ＣＰＵ２１は、抽選に当選して特典が付与されたユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「おめでとうございます。あなたは抽選に当選しましたので、プレゼントを贈ります。」などのメッセージが含まれてもよい。また、ＣＰＵ２１は、ユーザ自身は抽選には当選しなかったが仲間ユーザが抽選に当選したことにより特典が付与されたユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「おめでとうございます。あなたの仲間が抽選に当選しましたので、あなたにプレゼントを贈ります。」などのメッセージが含まれてもよい。一方、ＣＰＵ２１は、自身及び仲間が抽選に当選しなかったユーザに対して抽選結果を通知する場合、通知用のウェブページには、例えば「ごめんなさい。残念ですが抽選に外れてしまいました。」などのメッセージが含まれてもよい。また、ＣＰＵ２１は、例えば抽選にエントリーしたことに対する報酬として、自身及び仲間が抽選に当選しなかったユーザに対して所定量のポイントやアイテムなどを付与してもよい。

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

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

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

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

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

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

上述した実施形態では、実行対象のゲームがデジタルカードゲームである場合の例について説明したが、本発明のゲームはこれに限られず、任意のゲームに適用することができる。例えば、ロールプレイングゲーム、テーブルゲーム、パズルゲーム、スポーツゲーム、レースゲーム、シューティングゲーム、アクションゲーム、アドベンチャーゲーム、シミュレーションゲームなどの各種ジャンルのゲームにおいてゲーム上の抽選が行われる場合には、本発明を好適に適用することができる。

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

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

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

Claims (10)

1. ユーザと他のユーザとを対応付けて第１記憶領域に記録することによって、ユーザ同士を関係付ける関係付け手段と、
   ユーザの通信端末の位置を示す位置情報を取得し、取得した位置情報を前記ユーザに対応付けて第２記憶領域に記録する取得手段と、
   前記第２記憶領域にアクセスしてユーザに対応する位置情報を取得し、当該位置情報に基づいて、前記ユーザの通信端末が、所定のイベントが行われるイベント期間内に、前記イベントが行われる所定領域に存在するか否かを判別する判別手段と、
   ユーザに対してゲーム上の抽選を行う抽選手段と、
   第１のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記第１のユーザに関係付けられた第２のユーザに関する情報を前記第１記憶領域にアクセスして取得し、当該情報に基づいて、前記抽選における前記第１のユーザの当選確率が変動するように前記抽選手段を制御する抽選制御手段と、
   前記第１のユーザが前記抽選に当選した場合に、前記第１のユーザに対してゲーム上の特典を付与する付与手段と、
   を備えた、ゲーム制御装置。
2. 前記抽選手段は、前記イベント期間内に前記所定領域に通信端末が存在すると判別されたユーザに対して前記抽選を行うことを特徴とする、
   請求項１に記載されたゲーム制御装置。
3. 前記抽選制御手段は、前記第２のユーザの通信端末のうち前記イベント期間内に前記所定領域に存在すると判別された通信端末に関する情報に基づいて、前記抽選における前記第１のユーザの当選確率が変動するように前記抽選手段を制御することを特徴とする、
   請求項１または２に記載されたゲーム制御装置。
4. 前記付与手段は、前記第１のユーザが前記抽選に当選し、且つ、前記第１のユーザの通信端末が前記イベント期間の終了時期に前記所定領域に存在すると判別された場合に、前記第１のユーザに対して前記特典を付与することを特徴とする、
   請求項１〜３のいずれかに記載されたゲーム制御装置。
5. 前記特典には、有効期間が設定されており、
   前記特典が第１のイベントに基づいて付与された場合に、当該特典の有効期間の終了時期は、前記特典の付与以降の時期であって、前記第１のイベント以降に行われる第２のイベントの開始以前の時期に設定されていることを特徴とする、
   請求項１〜４のいずれかに記載されたゲーム制御装置。
6. 前記付与手段は、前記イベントの状況に応じて、前記特典を変動させることを特徴とする、
   請求項１〜５のいずれかに記載されたゲーム制御装置。
7. 前記付与手段は、前記第１のユーザ及び前記第２のユーザのそれぞれの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記第１のユーザ又は前記第２のユーザが前記抽選に当選すると、前記第１のユーザ及び前記第２のユーザに対して、ゲーム上の特典を付与することを特徴とする、
   請求項１〜６のいずれかに記載されたゲーム制御装置。
8. ユーザと他のユーザとを対応付けて第１記憶領域に記録することによって、ユーザ同士を関係付けるステップと、
   ユーザの通信端末の位置を示す位置情報を取得し、取得した位置情報を前記ユーザに対応付けて第２記憶領域に記録するステップと、
   前記第２記憶領域にアクセスしてユーザに対応する位置情報を取得し、当該位置情報に基づいて、前記ユーザの通信端末が、所定のイベントが行われるイベント期間内に、前記イベントが行われる所定領域に存在するか否かを判別するステップと、
   ユーザに対してゲーム上の抽選を行うステップと、
   第１のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記第１のユーザに関係付けられた第２のユーザに関する情報を前記第１記憶領域にアクセスして取得し、当該情報に基づいて、前記抽選における前記第１のユーザの当選確率が変動するように前記抽選手段を制御するステップと、
   前記第１のユーザが前記抽選に当選した場合に、前記第１のユーザに対してゲーム上の特典を付与するステップと、
   を備えた、ゲーム制御方法。
9. ゲームの実行を制御するために、コンピュータに、
   ユーザと他のユーザとを対応付けて第１記憶領域に記録することによって、ユーザ同士を関係付ける機能、
   ユーザの通信端末の位置を示す位置情報を取得し、取得した位置情報を前記ユーザに対応付けて第２記憶領域に記録する機能、
   前記第２記憶領域にアクセスしてユーザに対応する位置情報を取得し、当該位置情報に基づいて、前記ユーザの通信端末が、所定のイベントが行われるイベント期間内に、前記イベントが行われる所定領域に存在するか否かを判別する機能、
   ユーザに対してゲーム上の抽選を行う機能、
   第１のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記第１のユーザに関係付けられた第２のユーザに関する情報を前記第１記憶領域にアクセスして取得し、当該情報に基づいて、前記抽選における前記第１のユーザの当選確率が変動するように前記抽選手段を制御する機能、及び
   前記第１のユーザが前記抽選に当選した場合に、前記第１のユーザに対してゲーム上の特典を付与する機能、
   を実現させるためのプログラム。
10. 通信端末と、当該通信端末からアクセスされるサーバとを含むゲームシステムであって、
    ユーザと他のユーザとを対応付けて第１記憶領域に記録することによって、ユーザ同士を関係付ける関係付け手段、
    ユーザの通信端末の位置を示す位置情報を取得し、取得した位置情報を前記ユーザに対応付けて第２記憶領域に記録する取得手段、
    前記第２記憶領域にアクセスしてユーザに対応する位置情報を取得し、当該位置情報に基づいて、前記ユーザの通信端末が、所定のイベントが行われるイベント期間内に、前記イベントが行われる所定領域に存在するか否かを判別する判別手段、
    ユーザに対してゲーム上の抽選を行う抽選手段、
    第１のユーザの通信端末が前記イベント期間内に前記所定領域に存在すると判別された場合に、前記第１のユーザに関係付けられた第２のユーザに関する情報を前記第１記憶領域にアクセスして取得し、当該情報に基づいて、前記抽選における前記第１のユーザの当選確率が変動するように前記抽選手段を制御する抽選制御手段、
    前記第１のユーザが前記抽選に当選した場合に、前記第１のユーザに対してゲーム上の特典を付与する付与手段、
    の各手段を、前記通信端末又は前記サーバのいずれか一方が備えた、
    を備えた、ゲームシステム。

Images