自己位置利用システム
【課題】 現在位置に応じた処理の内容を柔軟に設定できる自己位置利用システムを提供する。
【解決手段】 各施設に配置されたロケータ７が発信するロケータＩＤの受信範囲を区域と見なし、各施設及び各アプリケーションのために前記ロケータＩＤとロケータ情報とを関連付けるセンターサーバ１上のロケータＩＤテーブルと、ロケータＩＤテーブルを編集するＷＥＢ管理ページと、アプリケーションを実行する携帯端末５と、を備え、携帯端末５は、位置検出部４５でロケータＩＤを受信すると、受付端末３を介してセンターサーバ１からダウンロードされるロケータＩＤテーブルに基づきロケータ情報を取得し、当該ロケータ情報に応じた処理を実行する。
【解決手段】 各施設に配置されたロケータ７が発信するロケータＩＤの受信範囲を区域と見なし、各施設及び各アプリケーションのために前記ロケータＩＤとロケータ情報とを関連付けるセンターサーバ１上のロケータＩＤテーブルと、ロケータＩＤテーブルを編集するＷＥＢ管理ページと、アプリケーションを実行する携帯端末５と、を備え、携帯端末５は、位置検出部４５でロケータＩＤを受信すると、受付端末３を介してセンターサーバ１からダウンロードされるロケータＩＤテーブルに基づきロケータ情報を取得し、当該ロケータ情報に応じた処理を実行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、現在位置に応じた処理を実行するシステム及びその関連技術に関する。
【背景技術】
【０００２】
特許文献１には、携帯電話の基地局のＩＤコードに基づいて、携帯電話上でのゲーム上のイベント発生（キャラクタの発生、アイテムの発生、ゲームシナリオの分岐等）を制御することが開示されている。ユーザがＩＤコードの受信範囲まで移動すれば、ＩＤコードに応じた処理が携帯電話上で実行される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１８７２７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１では、あるエリア（基地局ＩＤコード受信圏内）とゲームデータ（キャラクタ、アイテム、ゲームシナリオの分岐を選択するためのデータ）とを結びつけたテーブルを使用してイベント処理を行っている。
しかし、基地局の位置の変更や停波があった場合、想定された処理が実行されずゲームが進行できなくなる恐れがある。
また、ゲームをプレイできるユーザは、基地局の周辺地域に住むユーザに限定される。
さらに、ゲームをプレイするユーザが、各エリア及び対応するイベントを把握し、ゲームに飽きる恐れがある。
【０００５】
そこで本発明の目的は、現在位置に応じた処理の内容を柔軟に設定できる自己位置利用システムを提供することである。
また、本発明の目的は、多くの地域・施設で同時に実行可能な自己位置利用システムを提供することである。
また、本発明の目的は、ユーザが飽き難い自己位置利用システムを提供することである。
【課題を解決するための手段】
【０００６】
本発明の観点によれば、自己位置利用システムは、実空間に区域を設定する区域設定手段と、前記区域毎にアプリケーション処理のためのパラメータを関連付ける関連付け手段と、前記関連付けを編集する編集手段と、携帯端末上でアプリケーションを実行するアプリケーション実行手段と、を備え、前記アプリケーション実行手段は、前記携帯端末の現在地がいずれの前記区域にあるかを判定する判定手段と、前記判定の結果に応じて、前記区域と関連付けられた前記パラメータを取得する取得手段と、を含み、前記パラメータに応じた処理を実行する。
【０００７】
この構成によれば、区域毎にアプリケーションのためのパラメータを設定・編集できるため、現在位置に応じた処理の内容を柔軟に設定できる。また、地域や施設等の実空間の状態に合わせてパラメータを設定・編集できるため、様々な地域に住むユーザに向けてシステムを提供することができる。
また、実空間に変化が生じた場合でも、編集手段で修正を行うことで、アプリケーションが実行できなくなるという事態を回避することができる。
さらに、アプリケーション側に変更や追加が生じた場合に、編集手段で前記パラメータを修正すれば、区域設定手段まで変更や追加をせずに済む。
【０００８】
前記アプリケーションは複数種類存在し、前記編集手段は、前記アプリケーションの種類毎に前記区域と前記パラメータとの関連付けを編集する。
【０００９】
この構成によれば、アプリケーション毎に位置に応じて取得されるパラメータを編集できるため、多様なアプリケーションを同じシステムを使用して同時に同じ場所で実行できる。
【００１０】
前記区域設定手段は、施設単位で前記区域を設定し、前記編集手段は、前記区域と前記パラメータとの関連付けを編集する。
【００１１】
この構成によれば、施設の状態に合わせて、施設内の区域毎にアプリケーションのためのパラメータを設定・編集できるため、様々な施設に向けて同時にこのシステムを提供することができる。また、ある施設において区域に変更が生じた場合でも、編集手段で当該施設の設定を再編集すれば、アプリケーションや他の施設の設定を修正する必要が無い。
【００１２】
ここで施設とは、ショッピングセンター、学校又は博物館等の建造物だけでなく、公園などの屋外施設等も含む概念である。
【００１３】
前記アプリケーション実行手段は、同一の前記パラメータが関連付けられた前記区域の中から、一つ又は複数の前記区域を選択する区域選択手段をさらに含む。
【００１４】
この構成によれば、前記アプリケーション実行手段は、前記区域選択手段が選択した区域で前記パラメータを取得した場合にのみ対応する処理を行うことができる。
また、逆に、前記アプリケーション実行手段は、前記パラメータを取得した場合でも前記区域選択手段が選択した区域である場合は対応する処理を行わないことができる。
これによって、処理の実行タイミングにバリエーションを持たすことができる。また、あるパラメータが関連付けられた区域に行けば必ず一定の処理が行われるという状態を解消できる。
また、ユーザは位置と処理の関係を簡単には把握できないため、ユーザにとって飽き難いシステムを提供することができる。
【００１５】
前記アプリケーション実行手段は、前記パラメータ取得時、何れの前記区域において前記パラメータを取得したかを記録する履歴手段をさらに含む。
【００１６】
この構成によれば、前記アプリケーション実行手段は、パラメータを取得し、かつ過去のパラメータ取得履歴が特定の条件を満たす場合に、当該パラメータに応じた処理を実行するといったことができるようになる。例えば、前記アプリケーション実行手段は、同じパラメータを複数の異なる区域で取得したときに処理を行う。
これによって、処理の実行タイミングにバリエーションを持たすことができる。また、あるパラメータが関連付けられた区域に行けば必ず一定の処理が行われるという状態を解消できる。
また、ユーザは位置と処理の関係を簡単には把握できないため、ユーザにとって飽き難いシステムを提供することができる。
【００１７】
前記アプリケーション実行手段は、前記パラメータに応じた処理について、優先順位を設定する優先順位設定手段をさらに含み、前記区域が重なる範囲において、前記パラメータ取得手段が複数の前記パラメータを取得する場合に、前記優先順位に基づいて実行する処理を選択する。
【００１８】
この構成によれば、複数の区域が重なる場所があったとしても、前記アプリケーション実行手段の処理が滞らない。また、例えば危険区域にいることを知らせる警告等、重要な処理を優先して実行させることができる。
【００１９】
前記区域は、各所に配置された発信機が発信する信号の受信可能範囲であり、前記判定手段は、前記信号に含まれる前記発信機毎に固有の情報に基づいて前記判定を行う。
【００２０】
この構成によれば前記アプリケーション実行手段は、前記発信機の信号を受信し、解読するという簡単な処理によって、現在位置がいずれの区域にあるかを判別することができる。
また、前記発信機を配置するだけで、どのような実空間であっても容易に区域の設定ができる。
さらに、同様の前記発信機を配置した地域・施設において、同じアプリケーションを提供することができる。地域・施設毎に前記発信機を配置できる場所や数は変わりうるが、前記編集手段によって、各地域・施設の状況に合わせて柔軟にシステムの調整を行うことができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施の形態におけるシステムの略図である。
【図２】（ａ）図１の携帯端末５の外観図である。（ｂ）図１の携帯端末５の電気的構成を示す図である。
【図３】本発明の実施の形態におけるセンターサーバ１、受付端末３及び携帯端末５の処理の全体的な流れを説明するフローチャート
【図４】ロケータＩＤテーブルを説明するための図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態について、図面を参照しながら説明する。なお、図中、同一または相当部分については同一の参照符号を付してその説明を援用する。
【００２３】
本実施の形態の自己位置利用システムでは、現実のフィールド（以下、「実フィールド」と呼ぶ。）に、仮想のフィールド（以下、「仮想フィールド」と呼ぶ。）を割り当てる。また、携帯端末上で仮想フィールドに応じた処理を実行する。
【００２４】
図１は、本発明に基づく自己位置利用システムの全体構成を示す略図である。
この自己位置利用システムは、センターサーバ１、受付端末３、携帯端末５、ロケータ７を含む。
センターサーバ１は、本システムを統括する業者が管理する。以下、当該業者を管理者と呼ぶ。受付端末３は本システムを導入した各施設（図中では施設Ａ、Ｂ及びＣ）に配置され、当該施設の担当者によって操作される。以下、各施設の担当者をオペレータと呼ぶ。
携帯端末５は各施設で管理され、本システムを利用するユーザに各施設利用中に貸与される。携帯端末５上では、ユーザの操作に応じて、プログラムが実行される。ロケータ７は予め各施設内の様々な場所に設置される。ロケータ７の設置場所及び設置数量は施設によって異なる。
ロケータ７は常時固有のロケータＩＤを発信する。この例においては、ロケータＩＤの受信可能範囲が上述の仮想フィールドとして扱われる。携帯端末５は、ロケータＩＤを受信し、ロケータＩＤに応じた処理に応じた実行することができる。このため、携帯端末５を持ったユーザが実フィールドを移動し、仮想フィールドが割り当てられたエリアに移動すると、その場所に応じた処理が携帯端末５上で実行される。次に、携帯端末５について詳しく説明する。
【００２５】
図２（ａ）は、図１の携帯端末５の平面図である。図２（ａ）を参照して、携帯端末５は、その表面中央付近に、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）パネル１１を備える。ＬＣＤパネル１１の左側には、上下左右の方向キー１３が配置される。ＬＣＤパネル１１の右側には、４個のスイッチ１５が配置され、その近傍にスピーカ１７が配置される。携帯端末５はメモリーカードスロットを有し、着脱可能なメモリーカード１９を装着することができる。
【００２６】
図２（ｂ）は、携帯端末５の電気的構成を示す図である。図２（ｂ）を参照して、携帯端末５は、プロセッサ４１、外部メモリ４３、位置検出部４５、状態センサ４７、スイッチ部４９、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）コントローラ５１、ＬＣＤドライバ５３、ＩＲモジュール５５、ＲＴＣ（Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）５７、ＬＣＤパネル１１、及びスピーカ１７を含む。また、図示はしないが携帯端末５は電池ボックスを有しており、そこから動作に必要な電力を得る。
【００２７】
プロセッサ４１は、外部メモリ４３と接続される。外部メモリ４３は、例えば、ＲＯＭ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ、及びフラッシュメモリ等の半導体メモリ、ＲＯＭカートリッジ、バッテリバックアップ付きのＲＡＭメモリカートリッジ、フラッシュメモリカートリッジ、並びに不揮発性ＲＡＭカートリッジ等のうち、システムの仕様に応じて必要なものを含む。なお、外部メモリ４３は記録媒体の一例である。
【００２８】
外部メモリ４３は、プログラム領域、画像データ領域、および音声データ領域を含む。プログラム領域には、各種処理をプロセッサ４１に実行させる制御プログラムが格納される。
【００２９】
外部メモリ４３には、メモリーカード１９が含まれる。アプリケーション用のメインプログラムは、このメモリーカード１９に格納されている。プログラムに変更やバージョンアップがあった場合、各施設は受付端末３からメモリーカード１９を書き換えるか、新プログラムが格納されたメモリーカード１９に差し替えることによって対応する。
【００３０】
画像データ領域には、ビデオ信号を生成するために必要な画像データが格納されている。音声データ領域には、ボイス、効果音、及び音楽等のオーディオ信号を生成するための音声データが格納されている。
【００３１】
プロセッサ４１は、プログラム領域の制御プログラムを実行して、画像データ領域の画像データ及び音声データ領域の音声データを読み出し、必要な処理を施して、ビデオ信号及びオーディオ信号を生成する。ビデオ信号及びオーディオ信号は、それぞれ、ＬＣＤドライバ５３及びスピーカ１７に与えられる。
【００３２】
ＬＣＤドライバ５３は、ＬＣＤパネル１１を駆動して、プロセッサ４１から与えられたビデオ信号に応じた映像を表示する。また、スピーカ１７は、プロセッサ４１から与えられたオーディオ信号に応じて音声を出力する。
スイッチ部４９は、方向キー１３及びスイッチ１５を含み、それらのキーステータスがプロセッサ４１に与えられる。プロセッサ４１は、受け取ったキーステータスに応じて処理を実行する。
ＵＳＢコントローラ５１は、プロセッサ４１の制御を受けて、後述する受付端末３と通信し、データの送受信を行う。なお、ＵＳＢケーブルを使った通信は一例であり、任意の通信手段を用いて構わない。
【００３３】
位置検出部４５はＲＦモジュールを使用する。位置検出部は、ロケータ７から発信されるロケータＩＤを含んだ電波を受信してデコードし、プロセッサ４１に送る。なお、位置検出部４５は、外部の機器との通信、特に複数台の携帯端末５の間で通信を行う際にも使用される。例えば、複数台の携帯端末５上で実行されるアプリケーションの進行データを相互に通信し、データをプロセッサ４１の間で共有し、通信プレイを行う。
ＩＲモジュール５５も外部の機器との通信に使用する。ＩＲモジュール５５は、外部の機器からＩＲ信号を受信すると、デコードしてプロセッサ４１に送る。
【００３４】
状態センサ４７は、三軸加速度センサと地磁気センサを組み合わせたチップを使用する。状態センサ４７は携帯端末５に加わる加速度と、地磁気センサの検出結果から算出される携帯端末５の姿勢・向きを表す情報をプロセッサ４１に送る。
プロセッサ４１は、状態センサからの加速度情報を周知の歩数計測アルゴリズムに従って処理及び解析して、ユーザのステップを検出し、歩数を算出することができる。歩数はアプリケーション処理において使用される。また、各種アプリケーションは、ある一定の間隔中、規定の歩数以上の歩数を検出すると、携帯端末５を持ったユーザが走っていると判断し、警告表示を行い、アプリケーションを一時停止するように設定されている。
また、プロセッサ４１は、状態センサからの携帯端末５の姿勢・向きを表す情報に基づいて、画面中に表示するカーソルを移動させたり、画面中の背景画像を携帯端末５の姿勢・向きに合わせてスクロールさせたりすることができる。
【００３５】
ＲＴＣ５７は、時刻情報を生成しプロセッサ４１に送信する。図示はしないが、ＲＴＣ５７は上述の電池とは別のボタン電池から電源の供給を受けており、携帯端末５の電源を切った状態でも時刻を計測し続けている。
【００３６】
なお、プロセッサ４１は、図示しないが、中央演算処理装置（以下、「ＣＰＵ」と呼ぶ。）、グラフィックスプロセシングユニット（以下、「ＧＰＵ」と呼ぶ。）、サウンドプロセシングユニット（以下、「ＳＰＵ」と呼ぶ。）、ジオメトリエンジン（以下、「ＧＥ」と呼ぶ。）、外部インタフェースブロック、メインＲＡＭ、及びＡ／Ｄコンバータ（以下、「ＡＤＣ」と呼ぶ。）等の各種機能ブロックを具備する。
【００３７】
ＣＰＵは、外部メモリ４３に格納された制御プログラムを実行して、各種演算やプロセッサ４１内の各種機能ブロックの制御を行う。グラフィックス処理に関するＣＰＵの処理として、外部メモリ４３に格納されたプログラムを実行して、各オブジェクトの拡大・縮小、回転、及び／又は平行移動のパラメータ、視点座標（カメラ座標）、並びに視線ベクトルの算出等を行う。ここで、１または複数のポリゴン又はスプライトから構成され、同じ拡大・縮小、回転、及び平行移動の変換が適用される単位を「オブジェクト」と呼ぶ。
【００３８】
ＧＰＵは、ポリゴン及びスプライトから構成される三次元イメージをリアルタイムに生成し、アナログのコンポジットビデオ信号に変換する。ＳＰＵは、ＰＣＭ（ｐｕｌｓｅ ｃｏｄｅ ｍｏｄｕｌａｔｉｏｎ）波形データ、アンプリチュードデータ、及びメインボリュームデータを生成し、これらをアナログ乗算して、アナログオーディオ信号を生成する。ＧＥは、三次元イメージを表示するための幾何演算を実行する。具体的には、ＧＥは、行列積、ベクトルアフィン変換、ベクトル直交変換、透視投影変換、頂点明度／ポリゴン明度計算（ベクトル内積）、及びポリゴン裏面カリング処理（ベクトル外積）などの演算を実行する。
【００３９】
外部インタフェースブロックは、周辺装置（本実施の形態では、ＬＣＤドライバ５３、スイッチ部４９、ＵＳＢコントローラ５１、位置検出部４５、及び状態センサ４７）とのインタフェースであり、２４チャンネルのプログラマブルなデジタル入出力（Ｉ／Ｏ）ポートを含む。ＡＤＣは、４チャンネルのアナログ入力ポートに接続され、これらを介して、アナログ入力装置から入力されたアナログ信号をデジタル信号に変換する。メインＲＡＭは、ＣＰＵのワーク領域、変数格納領域、および仮想記憶機構管理領域等として利用される。
【００４０】
次に、処理の大まかな流れについてフローチャートを用いて説明する。
図３は、本発明の実施の形態におけるセンターサーバ１、受付端末３及び携帯端末５の処理の全体的な流れを説明するフローチャートである。
ステップＳ１で、受付端末３は一台の携帯端末５とＵＳＢケーブルによって接続され、通信を開始する。この時受付端末３は携帯端末５の外部メモリ４３に格納されているアプリケーションプログラムのバージョンをチェックするプログラムを実行し、最新版のアプリケーションが使用されているかチェックする。アプリケーションが最新版ではない場合、受付端末３は、最新版のアプリケーションを使用するように注意を表示する。受付端末３を操作するオペレータは、携帯端末５の外部メモリ４３のメモリーカード１９を最新版のアプリケーションプログラムを格納したものに交換するか、受付端末３から携帯端末５の外部メモリ４３に最新版のアプリケーションをインストールする。受付端末３は、必要であれば、センターサーバ１から最新版のアプリケーションをダウンロードする。
【００４１】
ステップＳ３に進み、受付端末３はオペレータからの入力に応じて、ユーザＩＤ、アプリケーションＩＤ及びプレイ時間を決定し、センターサーバ１に送信する。ユーザＩＤは、各ユーザを特定する識別情報である。アプリケーションＩＤは、携帯端末５上で実行されるアプリケーションの種類を特定する識別情報である。プレイ時間は、ユーザが携帯端末５でゲームを実行可能な制限時間の情報である。
オペレータは、各ユーザに配布されたユーザカードのユーザＩＤを示すバーコードを読み取り、受付端末３にユーザＩＤを入力する。また、オペレータは、ユーザから希望を聞き取り、受付端末３が表示する画面上でアプリケーションＩＤとプレイ時間を選択する。
【００４２】
ステップＳ５に進み、受付端末３はセンターサーバ１に対して、施設ＩＤ、ユーザＩＤ、アプリケーションＩＤを含む情報を送信する。施設ＩＤとは、予めセンターサーバ１から受付端末３毎に割り振られる、施設を識別するためのＩＤである。
ステップＳ７に進み、センターサーバ１は、ユーザＩＤ及びアプリケーションＩＤに基づき、ユーザのセーブデータを選択する。
ステップＳ９に進み、アプリケーションＩＤ及び施設ＩＤに基づき、ロケータＩＤテーブルを選択する。ロケータＩＤテーブルは、あるアプリケーション上で、図１の各ロケータ７が発信するロケータＩＤが持つ意味を設定するためのテーブルである。ロケータＩＤテーブルについて、図を用いて説明する。
【００４３】
図４は、ロケータＩＤテーブルを説明するための図である。
図４を参照して、センターサーバ１の管理者又は各施設のオペレータは、管理者ＩＤとパスワードを入力して、ロケータＩＤテーブルのＷＥＢ管理ページにログインすることができる。センターサーバ１の管理者は全ての施設のロケータＩＤテーブルにアクセスすることができ、各施設のオペレータは自己の施設のロケータＩＤテーブルにのみアクセスすることができる。
【００４４】
図４の例では、「施設Ａ」における「昆虫採集アプリ」用のロケータＩＤテーブルを設定している。管理者又はオペレータは、それぞれのロケータＩＤに対して、仮想フィールド情報である「池」、「草地」、「川」、「林」、「山地」、警告用情報である「警告１」、「警告２」、「警告３」、及び特殊なイベントを発生させるための情報である「特殊１」を設定する。なお、何も設定を行わない場合は「無効」となり、そのロケータ７のロケータＩＤを受信しても、何も処理は行われない。以下、ロケータＩＤテーブル上で各ロケータＩＤに割り当てられる情報を、「ロケータ情報」と呼ぶ。
なお、ここでは説明のために各ロケータ情報を文字で表現するが、実際は数字等のより情報量の少ないデータとして記録される。
【００４５】
ロケータ情報に対してどのような処理を行うかについては、アプリケーション側でさらに設定される。
例えば昆虫採集アプリケーションには、さらに仮想フィールド毎に複数の昆虫データが割り当てられたテーブルが用意されている。例えば「林」であれば、「カブトムシ」、「クワガタ」、「ハチ」等が割り当てられている。昆虫採集アプリケーション実行時、プロセッサ４１は、ユーザが実フィールドを移動して「林」が割り当てられたロケータＩＤを受信すると、プロセッサ４１は、ロケータＩＤを記憶する。次に、プロセッサ４１は、ロケータＩＤテーブルによって、現在の実フィールドに対応する仮想フィールドが「林」であると判定する。そして、プロセッサ４１は、その後昆虫採集アプリケーション内に存在するイベントテーブルの「林」と関連付けられた昆虫データの中から一つ又は複数の昆虫データを選択し、当該昆虫を捕まえるための虫取りイベントを発生させる。
ユーザは実フィールドを移動し、仮想フィールドを移動することで、様々な昆虫を捕まえることができる。
また、同じ仮想フィールド内であっても、アプリケーション側のテーブル中の多数の昆虫の中から抽選によって出現する昆虫が決定されるため、様々な昆虫が出現する。
【００４６】
またプロセッサ４１は、警告用情報である「警告１」、「警告２」又は「警告３」が割り当てられたロケータＩＤを受信すると、それぞれ「この付近は危険です。」、「施設の外に出ようとしています。」、「ここに虫はいません。」という警告表示を携帯端末５上で表示し、警告音を鳴らし、ゲームの進行をストップする。そして、プロセッサ４１は、ユーザがその仮想フィールドから出るまでスイッチ部４９からの操作を受け付けない。
つまり警告用情報は、例えばエスカレーターや人通りの多い場所等、携帯端末５を見るには危険な場所や、施設職員用区域等のユーザに入って欲しくない場所、あるいはユーザが施設から外に出てしまう出入り口にロケータを配置し、その付近でユーザが遊ばないようにするための情報である。
このような警告用の情報は、全アプリケーションに共通で設定される。警告表示の内容（グラフィック、文字、音声等）は、各アプリケーション側でそれぞれの内容に合わせて用意されている。
【００４７】
ロケータ７の配置及び電波送信距離によっては、携帯端末５が複数のロケータＩＤを同時に受信することもありうる。複数のロケータＩＤを同時に受信した場合、通常アプリケーションプログラムは、受信強度を測定し、受信強度が強い方のロケータＩＤを受信した場合の処理を優先する。しかし、同時に受信したロケータＩＤの一方が、警告用情報が割り当てられたロケータＩＤであった場合は、受信強度に関係なく警告用情報が割り当てられたロケータＩＤに基づく処理が優先される。このように位置を示す情報が複数存在する場合に、ユーザの安全を優先するため、警告用の情報を最優先して処理が実行される。
【００４８】
さらにプロセッサ４１は、特殊なイベントを発生させるための情報である「特殊１」が割り当てられたロケータＩＤを受信すると、通常の仮想フィールドでは発生しない特殊な虫取りイベントを発生させる。このように、仮想フィールドではなく、特定のイベントやデータを割り当てられることもできる。ＷＥＢ管理画面にはいつでもアクセスできるため、特定の季節、日時、時間帯、現実におけるイベント（例えば夏休みやクリスマス等）においてのみ「特殊１」のようなロケータ情報を設定することもできる。
【００４９】
施設Ａでは４０個のロケータ７を配置しているため、管理者又はオペレータは、１〜４０番のロケータＩＤに対して設定を行う。管理者又はオペレータは、予めロケータ７とそのロケータＩＤの配置図を用意し、それを見ながら図４のロケータＩＤテーブルの設定を行う。管理者又はオペレータは、昆虫採集以外のアプリに対しても、同様の設定を行う。アプリケーションによって、ロケータ情報を何の処理に使うかは異なる。例えば仮想フィールドの設定、特定のイベント、アイテム、フラグ等の発生情報をとして使用される。
また、一つのロケータＩＤに対して、複数のロケータ情報を割り当てる場合もある。例えば、一つのロケータＩＤに対して、仮想フィールド情報と、特定のイベントを発生させる情報を割り当てる場合がある。
逆に、一つのロケータ情報に対して、アプリケーションプログラム側で複数の処理を実行する場合もある。例えば、プロセッサ４１が、あるロケータ情報を取得した場合に、仮想フィールドの設定と、特定のイベントを発生させる処理をそれぞれ行うようにプログラミングがなされる。
【００５０】
受付端末３からロケータＩＤテーブルを受け取った携帯端末５は、同じロケータ情報が割り当てられたロケータＩＤのグループとして識別できる。例えば、ある施設のロケータＩＤ「１」から「５」のロケータ情報「森」が割り当てられている場合、ロケータＩＤ「１」から「５」は一つのグループと識別できる。
プロセッサ４１は、あるロケータ情報を取得することだけでなく、そのロケータ情報を持つグループの内の特定のロケータＩＤを受信することをトリガとして利用できる。グループ中の特定のロケータＩＤは、例えば抽選や、ロケータＩＤの大小関係等任意のアルゴリズムで決定される。
同様に、複数の異なるロケータ７から同じロケータ情報を受信することをトリガとして利用できる。
【００５１】
例えば、仮想フィールド「森」に行けばイベントが発生するというアプリケーションの場合、単純に「森」のロケータ情報を持つ何れかのロケータＩＤ「１」から「５」を受信した場合にイベントを発生させることもできるし、アプリケーションの抽選によって選ばれた「３」を受信した場合にのみイベントを発生させることもできるし、「１」から「５」のいずれかを複数種類受信した場合にイベントを発生させることもできる。また、上記トリガをイベント発生に使用するだけでなく、通常と異なるイベントテーブルを使用するためのトリガとして使用することもできる。上記トリガを条件の一つとしつつ、歩数や時間等の他の条件を組み合わせてもよい。
ユーザは仮想フィールド「森」に行くだけでなく、「森」の中を探し回ることでイベントに遭遇するかのような演出が可能となる。また、イベントが発生する位置（ロケータ７の場所）を、ユーザに容易に特定させない効果もある。これによってユーザにとって飽き難いゲームが実現できる。
【００５２】
上述の通り、ロケータ７の設置場所及び設置数は施設により異なる。しかし、ロケータＩＤテーブルによって、アプリケーション毎にロケータＩＤの意味付け（ロケータ情報）を変更することができるので、どんな施設でも同じ機器構成でアプリケーションを実行することができる。
また、センターサーバ１側でセーブデータを管理するため、ユーザはある日は施設Ａでアプリケーションをプレイし、別の日は施設Ｂで続きをプレイするといったことも可能になる。
【００５３】
ロケータＩＤテーブルによるロケータ情報への変換を用いず、ロケータＩＤに応じて直接プロセッサ４１に処理を実行させることもできる。しかし、その場合、多くの施設で同時にシステムを運用することや、ユーザに対して複数のアプリケーションを同時に提供することが難しくなる。
例えばロケータＩＤ「５０」を受信することをアプリケーションの処理の条件の一つとすると、ロケータＩＤが「５０」のロケータが配置されていない施設ではその処理が行えない。また、施設によってロケータＩＤ「５０」に該当するフィールドにイベント用に用いたい場合と警告用に用いたい場合があり、どちらかの施設が犠牲になるおそれがある。
ロケータＩＤテーブルによる変換を利用することで、どの施設でも同じシステムでアプリケーションを実行することができる。結果多くのユーザ・施設にこのシステムを利用してもらうことができる。
【００５４】
ロケータ７を追加する場合は、管理者又はオペレータは、追加したロケータ７のロケータＩＤに対して設定を行う。
システムを運営する中で施設内に危険個所等が発覚した場合にロケータ７を追加し、警告用の情報を割り当て、当該新しく発覚した危険個所周辺でプレイがなされないようにするといった対応も柔軟に行える。
いずれかのロケータ７が故障した場合は、臨時で予備のロケータ７を故障したロケータ７と交換し、故障したロケータＩＤに設定されていた情報と同じ情報を予備のロケータ７に設定する。
基本的にロケータ７は各施設内の電源付近に固定されているが、携帯可能なロケータ７を、施設職員又は施設内を移動する移動体に持たせ、適宜移動させるようにしてもよい。この場合ロケータ７には別途電池等が必要である。また、管理者又はオペレータは、当該携帯可能なロケータ７が発信するロケータＩＤについても、それぞれのアプリケーションのためのロケータＩＤテーブルの設定を行う。
【００５５】
また、アプリケーションがバージョンアップし、仮想フィールド情報、警告情報、特殊イベント情報、その他各ロケータＩＤに割り当て可能な情報の種類が増加した場合も、ロケータＩＤテーブルの再設定を行うことで、ロケータ７の配置を変えることなくいつでも対応できる。
バージョンアップ等がなくとも、ロケータＩＤテーブルを適宜変更することで、仮想フィールドの配置を変更し、複数回プレイするユーザが飽きることを防止することができる。
【００５６】
図３に戻って、ステップＳ９からステップＳ１１に進み、センターサーバ１は、ステップＳ７及びステップＳ９で決定したユーザのセーブデータ及びロケータＩＤテーブルを含む情報を受付端末に送信する。
ステップＳ１３で、受付端末３は携帯端末５に対して、ユーザＩＤ，プレイ時間情報、セーブデータ、ロケータＩＤテーブル及びアプリケーションＩＤに対応するプログラムを起動するためのコマンドを含む情報を送信する。選択されたアプリケーションによっては、プログラムの進行に使用するための情報がさらに送信される場合がある。
ステップＳ１５に進んで、携帯端末５は、図２の外部メモリ４３に格納されているアプリケーションプログラムを起動し、ステップＳ１３で送信された情報をロードする。但し、ユーザが初めて当該アプリケーションをプレイする場合は、セーブデータは存在しない。
この時受付端末３のオペレータは、受付端末３と携帯端末５のＵＳＢケーブルを取り外し、携帯端末５をユーザに渡す。
【００５７】
ステップＳ１７で、プロセッサ４１は、第１タイマをスタートする。第１タイマは、プレイ時間を計測するタイマである。
ステップＳ１９で、プロセッサ４１は、起動したアプリケーションプログラムに従った処理を実行する。
ステップＳ２１で、第１タイマが終了、つまり、プレイ時間が終了すると、プロセッサ４１は、ゲーム終了処理に入り、ユーザに対して受付に携帯端末５を返却することを促す画面を表示し、スイッチ部４９からのユーザの操作を受け付けなくなる。但し、アプリケーションによっては、第１タイマが終了し、特定のイベント処理が終了した後に、上記の終了処理に移行する。
ユーザは受付端末３のオペレータの元に戻り、携帯端末５を返却する。
【００５８】
ステップＳ２３で、携帯端末５は、ＵＳＢケーブルを介して受付端末３と通信し、ユーザＩＤ、アプリケーションＩＤ及び今回のゲーム処理を反映したセーブデータを送信する。セーブデータの内容は、アプリケーションによって異なる。
ステップＳ２５で、受付端末３は、センターサーバ１にユーザＩＤ、アプリケーションＩＤ及びセーブデータを送信する。
ステップＳ２７でセンターサーバ１はステップＳ２５で受け取ったユーザＩＤ、アプリケーションＩＤ及びセーブデータを関連付けて保存する。
【００５９】
携帯端末５上でユーザがアプリケーションを続きから開始するために使用される他、別途システムと連動したＷＥＢアプリケーション用のセーブデータとしても利用される。
図３で説明したユーザＩＤ、アプリケーションＩＤ及びセーブデータは、各アプリケーションと連動したＷＥＢサイトでも使用される。このＷＥＢサイトはユーザが帰宅後、ユーザのパソコンや携帯電話等のＷＥＢブラウザからアクセスする。
ユーザが自己のユーザＩＤを入力してログインすると、センターサーバ１はユーザＩＤ関連付けられたセーブデータを選択する。そして、センターサーバ１は、ユーザによるアプリケーションの進行具合であるセーブデータに基づいて、ＷＥＢサイトで表示するコンテンツを変化させる。
例えば昆虫採集アプリに対応したＷＥＢサイトでは、センターサーバ１は、セーブデータに含まれるユーザが捕まえた昆虫のデータに対応する図鑑を表示する。また、センターサーバ１は、多数のユーザのセーブデータから各ユーザの昆虫採集数を比較したランキング画面を表示する。
【００６０】
また、センターサーバ１はユーザが当該ＷＥＢサイト上で行った操作に応じてセーブデータに追加を行う場合がある。例えば、ＷＥＢサイト上で行ったミニゲームの結果に応じてセーブデータ中の仮想のアイテム、お金又は経験値といったデータを増加させたり、携帯端末５側のアプリケーション情報で特定のイベントを発生させるためのフラグ情報を追加したりする。
また、センターサーバ１は、ＷＥＢサイト上で行ったミニゲームの結果に応じてパスワードを表示する。ユーザが携帯端末５上でアプリケーションを実行する際に当該パスワードを入力すると、アプリケーションプログラムの処理として、仮想のアイテム、お金又は経験値といったデータを増加したり、携帯端末５側のアプリケーション情報で特定のイベントを発生させるためのフラグ情報を発生したりする処理が、プロセッサ４１によってなされる。
【００６１】
次に、図３のステップＳ２１で実行されるアプリケーションの例について説明する。
【００６２】
（ロールプレイングアプリケーション）
このアプリケーションは、ミッションを選択し、特定の敵キャラクタの打倒や特定のアイテムの取得等、ミッションごとに設定された条件をクリアしていくロールプレイングゲームを行うアプリケーションである。
ユーザが携帯端末５を操作しながら施設内を巡回し、アプリケーションプログラムが規定する条件を満たすと、会話イベント、戦闘イベント、回復イベント、買物イベント、ミニゲームイベント等のイベントが発生する。
イベント発生の条件として、ロケータＩＤの受信、歩数、携帯端末５が特定の方向を向いていること、残り時間、特定のアイテムデータを持っていること、特定のイベントをクリアしたこと等のいずれか又はそれらの組み合わせが使用される。
アプリケーションに用意されたイベント発生の条件テーブルは、ミッション毎に用意されている。このため、ユーザはミッション毎に異なるイベントを体験することができる。
【００６３】
上述のロケータＩＤテーブルによって、各ロケータＩＤに対応して、「草原」、「森」、「氷原」、「砂漠」、「遺跡」等の仮想フィールド情報が割り当てられている。それぞれの仮想フィールドは、実フィールドにおける距離が近いロケータ７が同じ仮想フィールドを割り当てられる。このため、近接する複数のロケータ７によって、比較的広い範囲の仮想フィールドが構成される。但し、管理者又はオペレータは、各仮想フィールドを近くのロケータ７同士でまとめずに、ばらばらに配置することもできる。
ロケータＩＤテーブルは、ミッションの種類にかかわらず共通で使用される。異なるミッションを実行するユーザの携帯端末５間であっても、同じ実フィールドにいれば、同じ仮想フィールドにいると判定される。もちろん、携帯端末５毎に、同じ実フィールドにいても、違う仮想フィールドにいると判定することも可能であるが、近くにいる携帯端末５間で通信プレイを行う場合があるため、通信プレイを行うユーザが共通体験を得やすいように、このように設定されている。
プロセッサ４１は、ロケータＩＤを受信すると、ロケータＩＤテーブルを参照し、ロケータ情報を取得する。そしてアプリケーションプログラムに従い、当該ロケータ情報を取得した場合の処理を実行する。
【００６４】
ロールプレイングアプリケーションの処理を開始すると、プロセッサ４１は、ミッション選択画面を表示し、ユーザにミッションを選択させる。ミッションには難易度が設定されている。難しいミッションは、規定のミッションをクリアする等の条件がフラグとなって、選択可能になる。また、図３のステップＳ１３で受付端末３から携帯端末５に送信される情報に応じて、ミッションが選択可能になる場合もある。例えば現実のイベントに合わせてある日時において、又はそれ以降の日時からミッションが選択可能になるという処理がなされる。
【００６５】
まず、ミッションの流れについて例を用いて説明する。
上述の通り、イベントの発生条件や出現するアイテムや敵キャラクタのデータテーブルはミッション毎に異なるようにプログラミングされている。
あるミッションでは、プロセッサ４１は、ユーザが移動を開始し、ロケータ情報が「草原」であるロケータＩＤを受信すると、会話イベントを発生させる。
プロセッサ４１は、会話イベント中、ボスキャラクタが「遺跡」にいるというユーザに対する手がかりを表示し、ボスキャラクタと戦闘イベントが発生させるためのボス戦闘フラグを設定する。
その後プロセッサ４１は、再びユーザが移動し、ロケータ情報が「遺跡」のロケータＩＤを受信すると、上記のボス戦闘フラグが設定されていることを確認して、ボスキャラクタとの戦闘イベントに移行する。
プロセッサ４１は、戦闘イベント処理を実行し、ユーザが勝利条件を満たしたと判定すると、勝利演出を行い、ボスキャラクタ毎に定められた経験値、お金及びアイテム等を追加する。そして、プロセッサ４１は、ミッションクリアと判定し、再びミッション選択画面を表示する。但し、図３のステップＳ１９の第１タイマ処理において、残りプレイ時間が無い場合は、ステップＳ２１の終了表示処理を行う。
ユーザが敗北条件を満たしたと判定すると、プロセッサ４１は敗北演出を行い。戦闘イベントを終了する。そしてプロセッサ４１は、回復イベントが発生するまで、各種イベントに遷移しない。回復イベントは、回復イベント用のロケータ情報が割り当てられたロケータＩＤを受信することで発生する。
【００６６】
上記の処理の流れの途中、ロケータＩＤの受信、ロケータＩＤの累計受信回数、歩数や残り時間等の所定の条件によって一般敵キャラクタとの戦闘イベントに遷移する場合がある。この戦闘イベントにおいてもプロセッサ４１は上記と同様の処理を行う。但し、プロセッサ４１は、上記のボスキャラクタとの戦闘イベントとは異なり、勝利してもミッションクリアとは判定せず、敵キャラクタ毎に定められた経験値、お金及びアイテム等が追加するのみである。経験値が一定数量以上たまると、ユーザのゲーム中でのレベルが上昇し、一度の攻撃で敵キャラクタに与えるダメージや、敵キャラクタからの攻撃に対する耐久度等のパラメータが上昇し、敵キャラクタを倒しやすくなるため、ボスキャラクタとの戦闘イベントに敗北したユーザは、このような一般敵キャラクタとの戦闘イベントをこなすことで、レベルを上げて再度ボスキャラクタとの戦闘イベントに挑戦する。
【００６７】
（待機画面）
次に、携帯端末５に表示される画面例について説明する。
特定のイベントが発生していない場合、現在の残りプレイ時間、歩数、現在の仮想フィールド、所持アイテム、金銭、現在遂行中のミッション、次にどこに行けばゲームが進行するかの手がかり情報等の各種ゲーム状態を表示する待機画面が表示される。現在の仮想フィールドは、プロセッサ４１が最後に受信したロケータＩＤのロケータ情報から決定される。
この待機画面には、施設毎に特有のメッセージテロップも表示される。メッセージの内容は図３のステップＳ１３において、受付端末３から送信される情報に含まれている。また、当該メッセージの内容は、図４で説明したＷＥＢ管理画面上で、管理者又はオペレータによって予め編集されている。普段はメッセージを表示せず、特定のロケータＩＤを受信すること等をトリガとして、当該メッセージを携帯端末５上で表示させる場合もある。
【００６８】
（確認画面）
ロケータＩＤの受信等、イベント発生条件が満たされると、プロセッサ４１は、スピーカ１７から注意音を鳴らし、周囲が安全な場所かユーザに確認させるための確認画面を表示する。ユーザがスイッチ１５を押すことに応じて、各種イベント画面に遷移する。
【００６９】
（探索画面）
プロセッサ４１は、特定の条件が満たされることに応じて、上記確認画面を経て探索画面を表示する。
探索画面には、現在の仮想フィールドに応じて用意される背景が表示される。当該背景はＬＣＤパネル１１の解像度より大きな一枚の絵として用意されており、ＬＣＤパネル１１に表示される範囲は一部分である。
プロセッサ４１は、状態センサ４７からの出力によって、携帯端末５の向き、姿勢を判定する。そしてプロセッサ４１は、携帯端末５の向き、姿勢の変化に応じて背景の表示範囲をスクロールさせる。このため、携帯端末５を持ちＬＣＤパネル１１を見ているユーザには、自分の視線の変化に合わせて背景が変化するように見える。
背景画像は左右が切れ目なく繋がった画像であり、ユーザを中心とした３６０度の回転を行うと、背景も一周して元の表示位置が表示されるように調整されている。但し、上下方向のスクロールは、背景画像の上端又は下端までで制限される。
このように、ユーザに疑似的な３６０度の視界が提供される。なお、今回は一枚の絵を使う手法を紹介したが、ポリゴン等の３Ｄモデルで背景を構成し、状態センサ４７の出力に応じて仮想のカメラの座標及び向きを決定することによって、ユーザに疑似的な３６０度の視界を提供する手法もある。
【００７０】
なお、この実施の形態では、プロセッサ４１は、背景画像の左右方向へのスクロールを状態センサ４７の地磁気センサの出力（地磁気の方向から、携帯端末５が向いている東西南北の方位が判定できる。）から判定し、背景画像の上下方向へのスクロールを三軸加速度センサ（重力加速度の方向の変化から、携帯端末が上向きか下向きかといった向きが判定できる。）の出力から判定している。
【００７１】
アプリケーションプログラムに応じて、プロセッサ４１は背景画像上の各所にアイテム、キャラクタ、店等を表現したオブジェクトを配置する。また、背景画像の表示範囲の中央に、円形のカーソルを表示する。これらの各種オブジェクトとカーソルとが重なること、重なった状態で一定時間が経過すること、重なった状態でスイッチ１５が押されることなどをトリガとして、プロセッサ４１は各種処理を実行する。
例えば、アイテムのオブジェクトであればアイテムの取得処理が実行される。キャラクタのオブジェクトであれば会話イベント、戦闘イベント又はミニゲームイベントへの遷移処理が実行される。店オブジェクトであれば買物イベントへの遷移処理が実行される。
【００７２】
探索画面への遷移は、通常ロケータＩＤの受信によって発生する。しかし、ユーザは待機画面における選択操作によって探索画面に遷移することもできる。この場合、背景上に配置されるオブジェクトはランダムで決定される。但し、オブジェクトが配置されておらず、何もイベントが発生しない場合が多い。また、ミッションの進行に必要なイベント等へと遷移するようなオブジェクトは配置されない。ユーザがロケータ７をなかなか発見できず、イベントが発生しない場合において、ユーザが退屈しないようにするための措置である。
【００７３】
さて、上記のような視界の遷移、カーソルの移動及びオブジェクトの選択は、戦闘イベントやミニゲームイベント中でも行われる。一部のイベントにおいては、上下左右方向へのスクロールではなく、左右方向又は上下方向へのスクロールに限定し、カーソルをオブジェクトに合わせやすくする場合もある。
また、このロールプレイングアプリケーション以外の携帯端末５用のアプリケーションでも同様の処理が利用される。
【００７４】
（戦闘イベント）
次に戦闘イベントについて説明する。このゲームではターン制の戦闘システムが採用されている。
戦闘イベントへの遷移が発生すると、プロセッサ４１は出現する敵キャラクタの種類、数及び座標を決定する。ユーザが攻撃、防御、逃走、アイテムを使う等の行動コマンドを選択すると、プロセッサ４１は敵キャラクタの行動を決定し、ターンを開始する。攻撃方法には複数種類が用意され、ユーザの選択に応じて選択される。
プロセッサ４１は、１ターンごとにユーザ側と敵キャラクタ側の行動に対応したアニメーションの表示と、行動の結果の判定を行う。例えば、攻撃コマンドに応じて、相手の耐久度データが減少する。
プロセッサ４１は、行動の結果、敵キャラクタの耐久度データが０以下になれば、ユーザの勝利と判定する。逆にユーザの耐久度データが０以下になれば、ユーザの敗北と判定する。
【００７５】
ユーザが攻撃コマンド及び攻撃方法の種類を選択した後、プロセッサ４１は、探索画面と同様に背景、カーソル及び敵キャラクタのオブジェクトが表示する。カーソルが敵キャラクタオブジェクトに重なった状態でスイッチ１５が押されると、プロセッサ４１は、ユーザの当該敵キャラクタに対する攻撃を確定し、対応するアニメーション表示の後、当該敵キャラクタの耐久度を減少させる。
敵キャラクタの座標と携帯端末５の向きによっては、敵キャラクタが画面中に表示されていない場合がある。この場合ユーザは、携帯端末の向きを変えることによって敵キャラクタを探し出し、カーソルを重ねる必要がある。カーソルの表示時間には制限時間があり、制限時間が０になるまでに攻撃を確定できない場合、ユーザから敵キャラクタへの攻撃は行われず、敵キャラクタからユーザへの攻撃のみが実行される。逆に素早く攻撃を確定させる場合、敵キャラクタの耐久度の減少量が増加する等、ユーザに有利な処理が行われる。
敵キャラクタオブジェクトの位置が常に移動する場合もある。
敵キャラクタの種類によっては、「頭」、「体」、「しっぽ」等の複数の部位が存在し、カーソルを重ねた位置に応じて耐久度の減少量が異なる。
また、プロセッサ４１は、ターン終了時に「敵が移動した」と表示して、敵キャラクタの座標を変更する場合がある。
【００７６】
（通信プレイ）
次に、通信プレイについて説明する。携帯端末５は、位置検出部４５（ＲＦモジュール）を使って通信プレイを行うことができる。携帯端末５はそれぞれが識別情報を有している。通信プレイを行う場合、ゲーム開始前の受付端末３との通信時に予め設定を行い、通信を行う対象となる識別情報を持つ携帯端末５のグループが設定される。このときいずれか１台の携帯端末５が親機として設定される。また、各携帯端末５は、同一グループに属する携帯端末５の識別情報及び、どの携帯端末５が親機かを示す情報を記憶する。
【００７７】
この実施の形態では、常時携帯端末５のグループ間で通信を行うのではなく、ホストの携帯端末５で戦闘イベントや特定のイベントを開始する場合に、近くにグループに属する携帯端末５がいる場合に通信が開始され、同じイベントが同期をとりながら各携帯端末５上で実行される。
【００７８】
例えば、親機がロケータ情報を取得し、さらにその時に同一グループに属する他の携帯端末５との通信プレイ状態にあることをトリガとして、イベントが発生する。
この時、親機が当該ロケータ情報の取得後一定時間内に子機との通信が確立できたことによってイベントの成立を判定し、イベント成立情報を子機にも送信する。そして、当該イベント成立情報に応じて、親機及び子機上で同一のイベントが進行する。
また、通信プレイ状態の親機と子機とが協力してフラグを立てるイベントも存在する。例えばグループ内でのあるイベント用アイテムの所有数の合計が１０以上になることをフラグとするイベントが存在する。
まず各ユーザは離れて単独プレイ状態で行動し、ゲームをこなしてイベント用アイテムを集める。そして、当該イベントが発生するロケータ７の位置で集合する。親機が当該ロケータのロケータ情報を取得し、親機と子機とが通信プレイ状態にあるかをチェックする。通信プレイ状態にある場合、イベントが開始される。この時各携帯端末５は、親機にイベント用アイテムの所持数を送信する。親機は所持数を計算し、それが１０個以上か否かによって、イベントがクリアされたと判定し、次のイベントを表示するための情報を各子機に送信する。
【００７９】
戦闘イベントにおいても、通信プレイが可能である。上述の戦闘イベント開始時に親機は周辺の子機に対して、戦闘イベントに参加するかを確認する。
参加選択を行った子機と親機は通信プレイ状態で戦闘イベント処理を実行する。戦闘イベントは、上述のターン制バトルが採用される。各携帯端末５はコマンドを選択し、選択結果を親機に送信する。例えば攻撃コマンドを選択した場合及び攻撃の種類と攻撃の対象の敵キャラクタを示すデータを送信する。親機は、受信した味方のコマンドを集計し、敵キャラクタの行動を決定し、そのターンの結果を演算する。親機は演算結果を子機に送信し、当該演算結果に応じた戦闘演出が各携帯端末５で表示される。
【００８０】
戦闘イベント中、途中で子機のユーザが親機の通信範囲から離脱するなどして子機との通信が途絶えると、親機は当該子機のユーザが逃亡したと表示し、残りの子機と戦闘イベントを継続する。
再度離脱した子機のユーザが親機の近くに戻ってきた場合、親機と当該子機は通信を再開し、戦闘イベントが終了していない場合は、次のターンから再度子機のユーザを戦闘イベントに参加させる。例えば、戦闘イベントから一時離脱して回復イベントを経て、再度親機の元に戻り、戦闘イベントに参加するということも可能である。
【００８１】
このようにユーザはある時は離れて行動し、ある時は集まって同じイベントを同時に楽しむことができる。離れている間も各携帯端末５上では、プロセッサ４１は単独でアプリケーションを進行させ、各種イベントを発生させる。
【００８２】
（町探索アプリケーション）
次に、携帯端末５で実行されるアプリケーションの別の例として、町探索アプリケーションを説明する。このアプリケーションでは、ロケータＩＤ毎にロケータ情報として「自宅」、「学校」、「店１」、「店２」、「高原」、「広場」、「海」等の仮想エリア情報が割り当てられ、仮想の町が構成される。複数個のロケータＩＤが一つの仮想エリアを構成する場合もある。ユーザは仮想の町を探索し、アイテムの収集、ミニゲーム或いはキャラクタとの会話イベント等を楽しむ。
【００８３】
ユーザは受付端末３で携帯端末５を受け取ったのち、施設内を移動する。この移動中は、上述の待機画面と同様の、ゲーム情報を表示した画面が表示される。
ロケータＩＤを受信すると、プロセッサ４１はロケータＩＤテーブルに基づきロケータ情報を解釈し、仮想エリアを表現した画面に遷移する。
この画面は上述の探索画面と同様に、ロケータ情報に応じた背景が表示され、そこにキャラクタ等のオブジェクトが配置される。プロセッサ４１は、当該オブジェクトがユーザに選択されることで、オブジェクト毎に割り当てられた会話イベントやミニゲームイベントに遷移する。プロセッサ４１は、会話イベントやミニゲームイベントの結果に応じて、アイテムやお金等を取得する処理を行う。配置されるキャラクタ、イベント、ミニゲーム等は、仮想エリア情報毎にアプリケーション側でテーブルが用意されている。
ロケータ情報が「店」だった場合、プロセッサ４１は、買い物イベントに遷移し、アイテムの一覧と価格を表示する。プロセッサ４１は、ユーザの選択に応じてアイテムの取得及びお金の減少処理を行う。
【００８４】
「自宅」のロケータ情報を取得すると、プロセッサ４１は、自宅画面に遷移する。自宅画面では取得した家具アイテムを並べて楽しむことができる。家具データ及び家具配置データはセーブデータの一部として記憶される。
センターサーバ１はこのアプリケーションのためのＷＥＢサイトにおいて、セーブデータ中の当該家具データ及び家具配置データに基づき、ユーザの自宅画面と同様の家具を配置する。このためユーザは帰宅後も自分の取得した家具を見て楽しむことができる。
【００８５】
このアプリケーションではＩＲモジュール５５を使って、外部の機器、例えば赤外線通信を使う玩具から赤外線信号を受信し、アイテム取得等のイベントが発生する。また、携帯端末５同士で通信を行い、アイテムの交換をすることもできる。
【００８６】
さて、以上のように本実施の形態によれば、各施設のロケータ７毎にアプリケーションのためのロケータ情報を設定・編集できるため、現在位置に応じた処理の内容を柔軟に設定できる。また、施設におけるロケータ７の配置状態に合わせてロケータ情報を設定・編集できるため、様々な施設及びそのユーザに向けてシステムを提供することができる。
また、ロケータ７の配置に変更が生じた場合でも、ロケータＩＤテーブルを通じて修正を行うことで、アプリケーションが実行できなくなるという事態を回避することができる。
さらに、アプリケーション側に変更や追加が生じた場合に、ロケータＩＤテーブルでロケータ情報を修正すれば、ロケータ７の配置まで変更や追加をせずに済む。
【００８７】
アプリケーション毎にロケータＩＤに対応したロケータ情報を編集できるため、多様なアプリケーションを同じシステムを使用して同時に同じ場所で実行できる。
【００８８】
各施設のロケータ７の配置に合わせて、アプリケーションのためのロケータ情報を設定・編集できるため、様々な施設に向けて同時にこのシステムを提供することができる。また、ある施設においてロケータ７の配置状況に変更が生じた場合でも、ロケータＩＤテーブルで当該施設の設定を再編集すれば、アプリケーションや他の施設の設定を修正する必要が無い。
【００８９】
あるパラメータが関連付けられた区域に行けば必ず一定の処理が行われるということがない。また、ユーザは位置とイベント発生の関係を簡単には把握できないため、ユーザにとって飽き難いシステムを提供することができる。
【００９０】
複数のロケータＩＤが受信される場所があったとしても、プロセッサ４１の処理が滞らない。また、警告用表示等の重要な処理が優先して実行させるため安全である。
【００９１】
プロセッサ４１は、ロケータ７のロケータＩＤを受信し、解読するという簡単な処理によって、現在位置がいずれの区域にあるかを判別することができる。ロケータ７を配置するだけで、どのような実空間であっても容易に区域の設定ができる。
さらに、同様機材を配置した施設において、同じアプリケーションを提供することができる。施設毎に前記発信機を配置できる場所や数は変わりうるが、前記編集手段によって、地域・施設の状態に合わせて柔軟にシステムの調整を行うことができる。
【００９２】
（変形例）
上記の実施の形態では、位置検出部４５として、ＲＦモジュールを使用し、施設内に配置されたロケータ７から発信されるロケータＩＤによって携帯端末５の相対的な位置を検出した。また、各ロケータＩＤの受信可能範囲によって区域分けができていた。
しかし、位置検出部４５は、携帯端末５の絶対的位置又は相対的位置を検出し、当該位置がどのような区域にあるのかを判別する手段があれば、その検出方法は特に限定されない。また、そのような手段がある限り、本発明に基づくシステムを実施する場所は、屋外であっても構わない。
【００９３】
携帯端末５の絶対的位置を検出する場合、例えば、位置検出部４５としてＧＰＳ受信機を使用する。そして、プロセッサ４１は、周知の位置算出アルゴリズムに従って、ＧＰＳ受信機からの信号を処理及び解析して、携帯端末５の位置を算出する。この場合、別途区域分けが必要となる。例えば、センターサーバ１に、ある程度の範囲の位置情報毎に区域分けを行い、パラメータを割り当てたデータベースを用意する。
また、位置検出部４５として電波受信機を使用する場合においても、ロケータ７の代わりに複数の発信機（例えば、微弱電波の発信機、携帯電話機の基地局、又は無線ＬＡＮのアクセスポイントなど）を配置し、携帯端末５側に対応する受信手段を設けてもよい。発信機からはロケータＩＤに対応する固有の識別情報が送信される。そして、プロセッサ４１は、当該識別情報を受信し、それをデコードして、自己の位置を算出する。
【００９４】
上記の例では各ロケータＩＤに応じてロケータ情報を割り当てていたが、複数のロケータＩＤの組合せにより、ロケータ情報を決定する方式を採用してもよい。
【００９５】
携帯端末５の相対的位置を検出する場合、例えば、位置検出部４５としてＲＦタグを使用してもよい。この場合、複数のＲＦリーダ／ライタをプレイエリア９に配置する。そして、ＲＦリーダ／ライタにより、ＲＦタグにＲＦリーダ／ライタの位置を書き込む。また、例えば、位置検出部４５としてＲＦリーダ／ライタを使用する。この場合、複数のＲＦタグをプレイエリア９に配置する。そして、ＲＦリーダ／ライタにより、ＲＦタグが保持する位置情報を読み込む。
【００９６】
状態センサ４７は、携帯端末５の三次元空間中の状態（姿勢を含む。）を検出できるものであれば、その種類は問わない。例えば、状態センサ４７は、加速度センサ、ジャイロセンサ、方位センサ、若しくは、傾斜センサ、又は、それらの２以上の組合せである。また、歩数や方位等をプロセッサ等の処理機に直接数値として出力するモジュールも存在するため、そういったモジュールを採用してもよい。
【００９７】
上記の例では携帯端末５は施設が所有し、ユーザに貸し出していたが、携帯端末５はユーザに所有物であってもよい。また、本システムのための専用の端末ではなく、汎用のゲーム機やコンピュータであってもよい。
【００９８】
上記の例ではロケータ７は一方的にロケータＩＤを発信する機器であった。しかし、通信機能を有し、携帯端末５や受付端末３と通信し可能なロケータを採用してもよい。また、ロケータＩＤに相当する発信情報を、後から変更できる機器を採用してもよい。
【００９９】
上記の例ではネットワークを介してセンターサーバ１上で、区域（ロケータＩＤ）とパラメータ（ロケータ情報）との関連付け及びその修正処理を行った。しかし、システムはある特定の施設内に限定されるものであってもよく、例えばセンターサーバ１の処理を施設の受付端末３に相当する端末が行う構成であってもよい。さらに、携帯端末５に相当する端末が全ての処理を行う構成であってもよい。
【産業上の利用可能性】
【０１００】
本発明は、例えば、ユーザの位置に応じた処理を実行するエンターテインメントシステムや、ユーザの位置に応じてその周辺にあるものを案内するシステム等に利用可能である。
【符号の説明】
【０１０１】
１…センターサーバ、３…受付端末、５…携帯端末、７…ロケータ
【技術分野】
【０００１】
本発明は、現在位置に応じた処理を実行するシステム及びその関連技術に関する。
【背景技術】
【０００２】
特許文献１には、携帯電話の基地局のＩＤコードに基づいて、携帯電話上でのゲーム上のイベント発生（キャラクタの発生、アイテムの発生、ゲームシナリオの分岐等）を制御することが開示されている。ユーザがＩＤコードの受信範囲まで移動すれば、ＩＤコードに応じた処理が携帯電話上で実行される。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−１８７２７１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１では、あるエリア（基地局ＩＤコード受信圏内）とゲームデータ（キャラクタ、アイテム、ゲームシナリオの分岐を選択するためのデータ）とを結びつけたテーブルを使用してイベント処理を行っている。
しかし、基地局の位置の変更や停波があった場合、想定された処理が実行されずゲームが進行できなくなる恐れがある。
また、ゲームをプレイできるユーザは、基地局の周辺地域に住むユーザに限定される。
さらに、ゲームをプレイするユーザが、各エリア及び対応するイベントを把握し、ゲームに飽きる恐れがある。
【０００５】
そこで本発明の目的は、現在位置に応じた処理の内容を柔軟に設定できる自己位置利用システムを提供することである。
また、本発明の目的は、多くの地域・施設で同時に実行可能な自己位置利用システムを提供することである。
また、本発明の目的は、ユーザが飽き難い自己位置利用システムを提供することである。
【課題を解決するための手段】
【０００６】
本発明の観点によれば、自己位置利用システムは、実空間に区域を設定する区域設定手段と、前記区域毎にアプリケーション処理のためのパラメータを関連付ける関連付け手段と、前記関連付けを編集する編集手段と、携帯端末上でアプリケーションを実行するアプリケーション実行手段と、を備え、前記アプリケーション実行手段は、前記携帯端末の現在地がいずれの前記区域にあるかを判定する判定手段と、前記判定の結果に応じて、前記区域と関連付けられた前記パラメータを取得する取得手段と、を含み、前記パラメータに応じた処理を実行する。
【０００７】
この構成によれば、区域毎にアプリケーションのためのパラメータを設定・編集できるため、現在位置に応じた処理の内容を柔軟に設定できる。また、地域や施設等の実空間の状態に合わせてパラメータを設定・編集できるため、様々な地域に住むユーザに向けてシステムを提供することができる。
また、実空間に変化が生じた場合でも、編集手段で修正を行うことで、アプリケーションが実行できなくなるという事態を回避することができる。
さらに、アプリケーション側に変更や追加が生じた場合に、編集手段で前記パラメータを修正すれば、区域設定手段まで変更や追加をせずに済む。
【０００８】
前記アプリケーションは複数種類存在し、前記編集手段は、前記アプリケーションの種類毎に前記区域と前記パラメータとの関連付けを編集する。
【０００９】
この構成によれば、アプリケーション毎に位置に応じて取得されるパラメータを編集できるため、多様なアプリケーションを同じシステムを使用して同時に同じ場所で実行できる。
【００１０】
前記区域設定手段は、施設単位で前記区域を設定し、前記編集手段は、前記区域と前記パラメータとの関連付けを編集する。
【００１１】
この構成によれば、施設の状態に合わせて、施設内の区域毎にアプリケーションのためのパラメータを設定・編集できるため、様々な施設に向けて同時にこのシステムを提供することができる。また、ある施設において区域に変更が生じた場合でも、編集手段で当該施設の設定を再編集すれば、アプリケーションや他の施設の設定を修正する必要が無い。
【００１２】
ここで施設とは、ショッピングセンター、学校又は博物館等の建造物だけでなく、公園などの屋外施設等も含む概念である。
【００１３】
前記アプリケーション実行手段は、同一の前記パラメータが関連付けられた前記区域の中から、一つ又は複数の前記区域を選択する区域選択手段をさらに含む。
【００１４】
この構成によれば、前記アプリケーション実行手段は、前記区域選択手段が選択した区域で前記パラメータを取得した場合にのみ対応する処理を行うことができる。
また、逆に、前記アプリケーション実行手段は、前記パラメータを取得した場合でも前記区域選択手段が選択した区域である場合は対応する処理を行わないことができる。
これによって、処理の実行タイミングにバリエーションを持たすことができる。また、あるパラメータが関連付けられた区域に行けば必ず一定の処理が行われるという状態を解消できる。
また、ユーザは位置と処理の関係を簡単には把握できないため、ユーザにとって飽き難いシステムを提供することができる。
【００１５】
前記アプリケーション実行手段は、前記パラメータ取得時、何れの前記区域において前記パラメータを取得したかを記録する履歴手段をさらに含む。
【００１６】
この構成によれば、前記アプリケーション実行手段は、パラメータを取得し、かつ過去のパラメータ取得履歴が特定の条件を満たす場合に、当該パラメータに応じた処理を実行するといったことができるようになる。例えば、前記アプリケーション実行手段は、同じパラメータを複数の異なる区域で取得したときに処理を行う。
これによって、処理の実行タイミングにバリエーションを持たすことができる。また、あるパラメータが関連付けられた区域に行けば必ず一定の処理が行われるという状態を解消できる。
また、ユーザは位置と処理の関係を簡単には把握できないため、ユーザにとって飽き難いシステムを提供することができる。
【００１７】
前記アプリケーション実行手段は、前記パラメータに応じた処理について、優先順位を設定する優先順位設定手段をさらに含み、前記区域が重なる範囲において、前記パラメータ取得手段が複数の前記パラメータを取得する場合に、前記優先順位に基づいて実行する処理を選択する。
【００１８】
この構成によれば、複数の区域が重なる場所があったとしても、前記アプリケーション実行手段の処理が滞らない。また、例えば危険区域にいることを知らせる警告等、重要な処理を優先して実行させることができる。
【００１９】
前記区域は、各所に配置された発信機が発信する信号の受信可能範囲であり、前記判定手段は、前記信号に含まれる前記発信機毎に固有の情報に基づいて前記判定を行う。
【００２０】
この構成によれば前記アプリケーション実行手段は、前記発信機の信号を受信し、解読するという簡単な処理によって、現在位置がいずれの区域にあるかを判別することができる。
また、前記発信機を配置するだけで、どのような実空間であっても容易に区域の設定ができる。
さらに、同様の前記発信機を配置した地域・施設において、同じアプリケーションを提供することができる。地域・施設毎に前記発信機を配置できる場所や数は変わりうるが、前記編集手段によって、各地域・施設の状況に合わせて柔軟にシステムの調整を行うことができる。
【図面の簡単な説明】
【００２１】
【図１】本発明の実施の形態におけるシステムの略図である。
【図２】（ａ）図１の携帯端末５の外観図である。（ｂ）図１の携帯端末５の電気的構成を示す図である。
【図３】本発明の実施の形態におけるセンターサーバ１、受付端末３及び携帯端末５の処理の全体的な流れを説明するフローチャート
【図４】ロケータＩＤテーブルを説明するための図である。
【発明を実施するための形態】
【００２２】
以下、本発明の実施の形態について、図面を参照しながら説明する。なお、図中、同一または相当部分については同一の参照符号を付してその説明を援用する。
【００２３】
本実施の形態の自己位置利用システムでは、現実のフィールド（以下、「実フィールド」と呼ぶ。）に、仮想のフィールド（以下、「仮想フィールド」と呼ぶ。）を割り当てる。また、携帯端末上で仮想フィールドに応じた処理を実行する。
【００２４】
図１は、本発明に基づく自己位置利用システムの全体構成を示す略図である。
この自己位置利用システムは、センターサーバ１、受付端末３、携帯端末５、ロケータ７を含む。
センターサーバ１は、本システムを統括する業者が管理する。以下、当該業者を管理者と呼ぶ。受付端末３は本システムを導入した各施設（図中では施設Ａ、Ｂ及びＣ）に配置され、当該施設の担当者によって操作される。以下、各施設の担当者をオペレータと呼ぶ。
携帯端末５は各施設で管理され、本システムを利用するユーザに各施設利用中に貸与される。携帯端末５上では、ユーザの操作に応じて、プログラムが実行される。ロケータ７は予め各施設内の様々な場所に設置される。ロケータ７の設置場所及び設置数量は施設によって異なる。
ロケータ７は常時固有のロケータＩＤを発信する。この例においては、ロケータＩＤの受信可能範囲が上述の仮想フィールドとして扱われる。携帯端末５は、ロケータＩＤを受信し、ロケータＩＤに応じた処理に応じた実行することができる。このため、携帯端末５を持ったユーザが実フィールドを移動し、仮想フィールドが割り当てられたエリアに移動すると、その場所に応じた処理が携帯端末５上で実行される。次に、携帯端末５について詳しく説明する。
【００２５】
図２（ａ）は、図１の携帯端末５の平面図である。図２（ａ）を参照して、携帯端末５は、その表面中央付近に、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）パネル１１を備える。ＬＣＤパネル１１の左側には、上下左右の方向キー１３が配置される。ＬＣＤパネル１１の右側には、４個のスイッチ１５が配置され、その近傍にスピーカ１７が配置される。携帯端末５はメモリーカードスロットを有し、着脱可能なメモリーカード１９を装着することができる。
【００２６】
図２（ｂ）は、携帯端末５の電気的構成を示す図である。図２（ｂ）を参照して、携帯端末５は、プロセッサ４１、外部メモリ４３、位置検出部４５、状態センサ４７、スイッチ部４９、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）コントローラ５１、ＬＣＤドライバ５３、ＩＲモジュール５５、ＲＴＣ（Ｒｅａｌ Ｔｉｍｅ Ｃｌｏｃｋ）５７、ＬＣＤパネル１１、及びスピーカ１７を含む。また、図示はしないが携帯端末５は電池ボックスを有しており、そこから動作に必要な電力を得る。
【００２７】
プロセッサ４１は、外部メモリ４３と接続される。外部メモリ４３は、例えば、ＲＯＭ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ、及びフラッシュメモリ等の半導体メモリ、ＲＯＭカートリッジ、バッテリバックアップ付きのＲＡＭメモリカートリッジ、フラッシュメモリカートリッジ、並びに不揮発性ＲＡＭカートリッジ等のうち、システムの仕様に応じて必要なものを含む。なお、外部メモリ４３は記録媒体の一例である。
【００２８】
外部メモリ４３は、プログラム領域、画像データ領域、および音声データ領域を含む。プログラム領域には、各種処理をプロセッサ４１に実行させる制御プログラムが格納される。
【００２９】
外部メモリ４３には、メモリーカード１９が含まれる。アプリケーション用のメインプログラムは、このメモリーカード１９に格納されている。プログラムに変更やバージョンアップがあった場合、各施設は受付端末３からメモリーカード１９を書き換えるか、新プログラムが格納されたメモリーカード１９に差し替えることによって対応する。
【００３０】
画像データ領域には、ビデオ信号を生成するために必要な画像データが格納されている。音声データ領域には、ボイス、効果音、及び音楽等のオーディオ信号を生成するための音声データが格納されている。
【００３１】
プロセッサ４１は、プログラム領域の制御プログラムを実行して、画像データ領域の画像データ及び音声データ領域の音声データを読み出し、必要な処理を施して、ビデオ信号及びオーディオ信号を生成する。ビデオ信号及びオーディオ信号は、それぞれ、ＬＣＤドライバ５３及びスピーカ１７に与えられる。
【００３２】
ＬＣＤドライバ５３は、ＬＣＤパネル１１を駆動して、プロセッサ４１から与えられたビデオ信号に応じた映像を表示する。また、スピーカ１７は、プロセッサ４１から与えられたオーディオ信号に応じて音声を出力する。
スイッチ部４９は、方向キー１３及びスイッチ１５を含み、それらのキーステータスがプロセッサ４１に与えられる。プロセッサ４１は、受け取ったキーステータスに応じて処理を実行する。
ＵＳＢコントローラ５１は、プロセッサ４１の制御を受けて、後述する受付端末３と通信し、データの送受信を行う。なお、ＵＳＢケーブルを使った通信は一例であり、任意の通信手段を用いて構わない。
【００３３】
位置検出部４５はＲＦモジュールを使用する。位置検出部は、ロケータ７から発信されるロケータＩＤを含んだ電波を受信してデコードし、プロセッサ４１に送る。なお、位置検出部４５は、外部の機器との通信、特に複数台の携帯端末５の間で通信を行う際にも使用される。例えば、複数台の携帯端末５上で実行されるアプリケーションの進行データを相互に通信し、データをプロセッサ４１の間で共有し、通信プレイを行う。
ＩＲモジュール５５も外部の機器との通信に使用する。ＩＲモジュール５５は、外部の機器からＩＲ信号を受信すると、デコードしてプロセッサ４１に送る。
【００３４】
状態センサ４７は、三軸加速度センサと地磁気センサを組み合わせたチップを使用する。状態センサ４７は携帯端末５に加わる加速度と、地磁気センサの検出結果から算出される携帯端末５の姿勢・向きを表す情報をプロセッサ４１に送る。
プロセッサ４１は、状態センサからの加速度情報を周知の歩数計測アルゴリズムに従って処理及び解析して、ユーザのステップを検出し、歩数を算出することができる。歩数はアプリケーション処理において使用される。また、各種アプリケーションは、ある一定の間隔中、規定の歩数以上の歩数を検出すると、携帯端末５を持ったユーザが走っていると判断し、警告表示を行い、アプリケーションを一時停止するように設定されている。
また、プロセッサ４１は、状態センサからの携帯端末５の姿勢・向きを表す情報に基づいて、画面中に表示するカーソルを移動させたり、画面中の背景画像を携帯端末５の姿勢・向きに合わせてスクロールさせたりすることができる。
【００３５】
ＲＴＣ５７は、時刻情報を生成しプロセッサ４１に送信する。図示はしないが、ＲＴＣ５７は上述の電池とは別のボタン電池から電源の供給を受けており、携帯端末５の電源を切った状態でも時刻を計測し続けている。
【００３６】
なお、プロセッサ４１は、図示しないが、中央演算処理装置（以下、「ＣＰＵ」と呼ぶ。）、グラフィックスプロセシングユニット（以下、「ＧＰＵ」と呼ぶ。）、サウンドプロセシングユニット（以下、「ＳＰＵ」と呼ぶ。）、ジオメトリエンジン（以下、「ＧＥ」と呼ぶ。）、外部インタフェースブロック、メインＲＡＭ、及びＡ／Ｄコンバータ（以下、「ＡＤＣ」と呼ぶ。）等の各種機能ブロックを具備する。
【００３７】
ＣＰＵは、外部メモリ４３に格納された制御プログラムを実行して、各種演算やプロセッサ４１内の各種機能ブロックの制御を行う。グラフィックス処理に関するＣＰＵの処理として、外部メモリ４３に格納されたプログラムを実行して、各オブジェクトの拡大・縮小、回転、及び／又は平行移動のパラメータ、視点座標（カメラ座標）、並びに視線ベクトルの算出等を行う。ここで、１または複数のポリゴン又はスプライトから構成され、同じ拡大・縮小、回転、及び平行移動の変換が適用される単位を「オブジェクト」と呼ぶ。
【００３８】
ＧＰＵは、ポリゴン及びスプライトから構成される三次元イメージをリアルタイムに生成し、アナログのコンポジットビデオ信号に変換する。ＳＰＵは、ＰＣＭ（ｐｕｌｓｅ ｃｏｄｅ ｍｏｄｕｌａｔｉｏｎ）波形データ、アンプリチュードデータ、及びメインボリュームデータを生成し、これらをアナログ乗算して、アナログオーディオ信号を生成する。ＧＥは、三次元イメージを表示するための幾何演算を実行する。具体的には、ＧＥは、行列積、ベクトルアフィン変換、ベクトル直交変換、透視投影変換、頂点明度／ポリゴン明度計算（ベクトル内積）、及びポリゴン裏面カリング処理（ベクトル外積）などの演算を実行する。
【００３９】
外部インタフェースブロックは、周辺装置（本実施の形態では、ＬＣＤドライバ５３、スイッチ部４９、ＵＳＢコントローラ５１、位置検出部４５、及び状態センサ４７）とのインタフェースであり、２４チャンネルのプログラマブルなデジタル入出力（Ｉ／Ｏ）ポートを含む。ＡＤＣは、４チャンネルのアナログ入力ポートに接続され、これらを介して、アナログ入力装置から入力されたアナログ信号をデジタル信号に変換する。メインＲＡＭは、ＣＰＵのワーク領域、変数格納領域、および仮想記憶機構管理領域等として利用される。
【００４０】
次に、処理の大まかな流れについてフローチャートを用いて説明する。
図３は、本発明の実施の形態におけるセンターサーバ１、受付端末３及び携帯端末５の処理の全体的な流れを説明するフローチャートである。
ステップＳ１で、受付端末３は一台の携帯端末５とＵＳＢケーブルによって接続され、通信を開始する。この時受付端末３は携帯端末５の外部メモリ４３に格納されているアプリケーションプログラムのバージョンをチェックするプログラムを実行し、最新版のアプリケーションが使用されているかチェックする。アプリケーションが最新版ではない場合、受付端末３は、最新版のアプリケーションを使用するように注意を表示する。受付端末３を操作するオペレータは、携帯端末５の外部メモリ４３のメモリーカード１９を最新版のアプリケーションプログラムを格納したものに交換するか、受付端末３から携帯端末５の外部メモリ４３に最新版のアプリケーションをインストールする。受付端末３は、必要であれば、センターサーバ１から最新版のアプリケーションをダウンロードする。
【００４１】
ステップＳ３に進み、受付端末３はオペレータからの入力に応じて、ユーザＩＤ、アプリケーションＩＤ及びプレイ時間を決定し、センターサーバ１に送信する。ユーザＩＤは、各ユーザを特定する識別情報である。アプリケーションＩＤは、携帯端末５上で実行されるアプリケーションの種類を特定する識別情報である。プレイ時間は、ユーザが携帯端末５でゲームを実行可能な制限時間の情報である。
オペレータは、各ユーザに配布されたユーザカードのユーザＩＤを示すバーコードを読み取り、受付端末３にユーザＩＤを入力する。また、オペレータは、ユーザから希望を聞き取り、受付端末３が表示する画面上でアプリケーションＩＤとプレイ時間を選択する。
【００４２】
ステップＳ５に進み、受付端末３はセンターサーバ１に対して、施設ＩＤ、ユーザＩＤ、アプリケーションＩＤを含む情報を送信する。施設ＩＤとは、予めセンターサーバ１から受付端末３毎に割り振られる、施設を識別するためのＩＤである。
ステップＳ７に進み、センターサーバ１は、ユーザＩＤ及びアプリケーションＩＤに基づき、ユーザのセーブデータを選択する。
ステップＳ９に進み、アプリケーションＩＤ及び施設ＩＤに基づき、ロケータＩＤテーブルを選択する。ロケータＩＤテーブルは、あるアプリケーション上で、図１の各ロケータ７が発信するロケータＩＤが持つ意味を設定するためのテーブルである。ロケータＩＤテーブルについて、図を用いて説明する。
【００４３】
図４は、ロケータＩＤテーブルを説明するための図である。
図４を参照して、センターサーバ１の管理者又は各施設のオペレータは、管理者ＩＤとパスワードを入力して、ロケータＩＤテーブルのＷＥＢ管理ページにログインすることができる。センターサーバ１の管理者は全ての施設のロケータＩＤテーブルにアクセスすることができ、各施設のオペレータは自己の施設のロケータＩＤテーブルにのみアクセスすることができる。
【００４４】
図４の例では、「施設Ａ」における「昆虫採集アプリ」用のロケータＩＤテーブルを設定している。管理者又はオペレータは、それぞれのロケータＩＤに対して、仮想フィールド情報である「池」、「草地」、「川」、「林」、「山地」、警告用情報である「警告１」、「警告２」、「警告３」、及び特殊なイベントを発生させるための情報である「特殊１」を設定する。なお、何も設定を行わない場合は「無効」となり、そのロケータ７のロケータＩＤを受信しても、何も処理は行われない。以下、ロケータＩＤテーブル上で各ロケータＩＤに割り当てられる情報を、「ロケータ情報」と呼ぶ。
なお、ここでは説明のために各ロケータ情報を文字で表現するが、実際は数字等のより情報量の少ないデータとして記録される。
【００４５】
ロケータ情報に対してどのような処理を行うかについては、アプリケーション側でさらに設定される。
例えば昆虫採集アプリケーションには、さらに仮想フィールド毎に複数の昆虫データが割り当てられたテーブルが用意されている。例えば「林」であれば、「カブトムシ」、「クワガタ」、「ハチ」等が割り当てられている。昆虫採集アプリケーション実行時、プロセッサ４１は、ユーザが実フィールドを移動して「林」が割り当てられたロケータＩＤを受信すると、プロセッサ４１は、ロケータＩＤを記憶する。次に、プロセッサ４１は、ロケータＩＤテーブルによって、現在の実フィールドに対応する仮想フィールドが「林」であると判定する。そして、プロセッサ４１は、その後昆虫採集アプリケーション内に存在するイベントテーブルの「林」と関連付けられた昆虫データの中から一つ又は複数の昆虫データを選択し、当該昆虫を捕まえるための虫取りイベントを発生させる。
ユーザは実フィールドを移動し、仮想フィールドを移動することで、様々な昆虫を捕まえることができる。
また、同じ仮想フィールド内であっても、アプリケーション側のテーブル中の多数の昆虫の中から抽選によって出現する昆虫が決定されるため、様々な昆虫が出現する。
【００４６】
またプロセッサ４１は、警告用情報である「警告１」、「警告２」又は「警告３」が割り当てられたロケータＩＤを受信すると、それぞれ「この付近は危険です。」、「施設の外に出ようとしています。」、「ここに虫はいません。」という警告表示を携帯端末５上で表示し、警告音を鳴らし、ゲームの進行をストップする。そして、プロセッサ４１は、ユーザがその仮想フィールドから出るまでスイッチ部４９からの操作を受け付けない。
つまり警告用情報は、例えばエスカレーターや人通りの多い場所等、携帯端末５を見るには危険な場所や、施設職員用区域等のユーザに入って欲しくない場所、あるいはユーザが施設から外に出てしまう出入り口にロケータを配置し、その付近でユーザが遊ばないようにするための情報である。
このような警告用の情報は、全アプリケーションに共通で設定される。警告表示の内容（グラフィック、文字、音声等）は、各アプリケーション側でそれぞれの内容に合わせて用意されている。
【００４７】
ロケータ７の配置及び電波送信距離によっては、携帯端末５が複数のロケータＩＤを同時に受信することもありうる。複数のロケータＩＤを同時に受信した場合、通常アプリケーションプログラムは、受信強度を測定し、受信強度が強い方のロケータＩＤを受信した場合の処理を優先する。しかし、同時に受信したロケータＩＤの一方が、警告用情報が割り当てられたロケータＩＤであった場合は、受信強度に関係なく警告用情報が割り当てられたロケータＩＤに基づく処理が優先される。このように位置を示す情報が複数存在する場合に、ユーザの安全を優先するため、警告用の情報を最優先して処理が実行される。
【００４８】
さらにプロセッサ４１は、特殊なイベントを発生させるための情報である「特殊１」が割り当てられたロケータＩＤを受信すると、通常の仮想フィールドでは発生しない特殊な虫取りイベントを発生させる。このように、仮想フィールドではなく、特定のイベントやデータを割り当てられることもできる。ＷＥＢ管理画面にはいつでもアクセスできるため、特定の季節、日時、時間帯、現実におけるイベント（例えば夏休みやクリスマス等）においてのみ「特殊１」のようなロケータ情報を設定することもできる。
【００４９】
施設Ａでは４０個のロケータ７を配置しているため、管理者又はオペレータは、１〜４０番のロケータＩＤに対して設定を行う。管理者又はオペレータは、予めロケータ７とそのロケータＩＤの配置図を用意し、それを見ながら図４のロケータＩＤテーブルの設定を行う。管理者又はオペレータは、昆虫採集以外のアプリに対しても、同様の設定を行う。アプリケーションによって、ロケータ情報を何の処理に使うかは異なる。例えば仮想フィールドの設定、特定のイベント、アイテム、フラグ等の発生情報をとして使用される。
また、一つのロケータＩＤに対して、複数のロケータ情報を割り当てる場合もある。例えば、一つのロケータＩＤに対して、仮想フィールド情報と、特定のイベントを発生させる情報を割り当てる場合がある。
逆に、一つのロケータ情報に対して、アプリケーションプログラム側で複数の処理を実行する場合もある。例えば、プロセッサ４１が、あるロケータ情報を取得した場合に、仮想フィールドの設定と、特定のイベントを発生させる処理をそれぞれ行うようにプログラミングがなされる。
【００５０】
受付端末３からロケータＩＤテーブルを受け取った携帯端末５は、同じロケータ情報が割り当てられたロケータＩＤのグループとして識別できる。例えば、ある施設のロケータＩＤ「１」から「５」のロケータ情報「森」が割り当てられている場合、ロケータＩＤ「１」から「５」は一つのグループと識別できる。
プロセッサ４１は、あるロケータ情報を取得することだけでなく、そのロケータ情報を持つグループの内の特定のロケータＩＤを受信することをトリガとして利用できる。グループ中の特定のロケータＩＤは、例えば抽選や、ロケータＩＤの大小関係等任意のアルゴリズムで決定される。
同様に、複数の異なるロケータ７から同じロケータ情報を受信することをトリガとして利用できる。
【００５１】
例えば、仮想フィールド「森」に行けばイベントが発生するというアプリケーションの場合、単純に「森」のロケータ情報を持つ何れかのロケータＩＤ「１」から「５」を受信した場合にイベントを発生させることもできるし、アプリケーションの抽選によって選ばれた「３」を受信した場合にのみイベントを発生させることもできるし、「１」から「５」のいずれかを複数種類受信した場合にイベントを発生させることもできる。また、上記トリガをイベント発生に使用するだけでなく、通常と異なるイベントテーブルを使用するためのトリガとして使用することもできる。上記トリガを条件の一つとしつつ、歩数や時間等の他の条件を組み合わせてもよい。
ユーザは仮想フィールド「森」に行くだけでなく、「森」の中を探し回ることでイベントに遭遇するかのような演出が可能となる。また、イベントが発生する位置（ロケータ７の場所）を、ユーザに容易に特定させない効果もある。これによってユーザにとって飽き難いゲームが実現できる。
【００５２】
上述の通り、ロケータ７の設置場所及び設置数は施設により異なる。しかし、ロケータＩＤテーブルによって、アプリケーション毎にロケータＩＤの意味付け（ロケータ情報）を変更することができるので、どんな施設でも同じ機器構成でアプリケーションを実行することができる。
また、センターサーバ１側でセーブデータを管理するため、ユーザはある日は施設Ａでアプリケーションをプレイし、別の日は施設Ｂで続きをプレイするといったことも可能になる。
【００５３】
ロケータＩＤテーブルによるロケータ情報への変換を用いず、ロケータＩＤに応じて直接プロセッサ４１に処理を実行させることもできる。しかし、その場合、多くの施設で同時にシステムを運用することや、ユーザに対して複数のアプリケーションを同時に提供することが難しくなる。
例えばロケータＩＤ「５０」を受信することをアプリケーションの処理の条件の一つとすると、ロケータＩＤが「５０」のロケータが配置されていない施設ではその処理が行えない。また、施設によってロケータＩＤ「５０」に該当するフィールドにイベント用に用いたい場合と警告用に用いたい場合があり、どちらかの施設が犠牲になるおそれがある。
ロケータＩＤテーブルによる変換を利用することで、どの施設でも同じシステムでアプリケーションを実行することができる。結果多くのユーザ・施設にこのシステムを利用してもらうことができる。
【００５４】
ロケータ７を追加する場合は、管理者又はオペレータは、追加したロケータ７のロケータＩＤに対して設定を行う。
システムを運営する中で施設内に危険個所等が発覚した場合にロケータ７を追加し、警告用の情報を割り当て、当該新しく発覚した危険個所周辺でプレイがなされないようにするといった対応も柔軟に行える。
いずれかのロケータ７が故障した場合は、臨時で予備のロケータ７を故障したロケータ７と交換し、故障したロケータＩＤに設定されていた情報と同じ情報を予備のロケータ７に設定する。
基本的にロケータ７は各施設内の電源付近に固定されているが、携帯可能なロケータ７を、施設職員又は施設内を移動する移動体に持たせ、適宜移動させるようにしてもよい。この場合ロケータ７には別途電池等が必要である。また、管理者又はオペレータは、当該携帯可能なロケータ７が発信するロケータＩＤについても、それぞれのアプリケーションのためのロケータＩＤテーブルの設定を行う。
【００５５】
また、アプリケーションがバージョンアップし、仮想フィールド情報、警告情報、特殊イベント情報、その他各ロケータＩＤに割り当て可能な情報の種類が増加した場合も、ロケータＩＤテーブルの再設定を行うことで、ロケータ７の配置を変えることなくいつでも対応できる。
バージョンアップ等がなくとも、ロケータＩＤテーブルを適宜変更することで、仮想フィールドの配置を変更し、複数回プレイするユーザが飽きることを防止することができる。
【００５６】
図３に戻って、ステップＳ９からステップＳ１１に進み、センターサーバ１は、ステップＳ７及びステップＳ９で決定したユーザのセーブデータ及びロケータＩＤテーブルを含む情報を受付端末に送信する。
ステップＳ１３で、受付端末３は携帯端末５に対して、ユーザＩＤ，プレイ時間情報、セーブデータ、ロケータＩＤテーブル及びアプリケーションＩＤに対応するプログラムを起動するためのコマンドを含む情報を送信する。選択されたアプリケーションによっては、プログラムの進行に使用するための情報がさらに送信される場合がある。
ステップＳ１５に進んで、携帯端末５は、図２の外部メモリ４３に格納されているアプリケーションプログラムを起動し、ステップＳ１３で送信された情報をロードする。但し、ユーザが初めて当該アプリケーションをプレイする場合は、セーブデータは存在しない。
この時受付端末３のオペレータは、受付端末３と携帯端末５のＵＳＢケーブルを取り外し、携帯端末５をユーザに渡す。
【００５７】
ステップＳ１７で、プロセッサ４１は、第１タイマをスタートする。第１タイマは、プレイ時間を計測するタイマである。
ステップＳ１９で、プロセッサ４１は、起動したアプリケーションプログラムに従った処理を実行する。
ステップＳ２１で、第１タイマが終了、つまり、プレイ時間が終了すると、プロセッサ４１は、ゲーム終了処理に入り、ユーザに対して受付に携帯端末５を返却することを促す画面を表示し、スイッチ部４９からのユーザの操作を受け付けなくなる。但し、アプリケーションによっては、第１タイマが終了し、特定のイベント処理が終了した後に、上記の終了処理に移行する。
ユーザは受付端末３のオペレータの元に戻り、携帯端末５を返却する。
【００５８】
ステップＳ２３で、携帯端末５は、ＵＳＢケーブルを介して受付端末３と通信し、ユーザＩＤ、アプリケーションＩＤ及び今回のゲーム処理を反映したセーブデータを送信する。セーブデータの内容は、アプリケーションによって異なる。
ステップＳ２５で、受付端末３は、センターサーバ１にユーザＩＤ、アプリケーションＩＤ及びセーブデータを送信する。
ステップＳ２７でセンターサーバ１はステップＳ２５で受け取ったユーザＩＤ、アプリケーションＩＤ及びセーブデータを関連付けて保存する。
【００５９】
携帯端末５上でユーザがアプリケーションを続きから開始するために使用される他、別途システムと連動したＷＥＢアプリケーション用のセーブデータとしても利用される。
図３で説明したユーザＩＤ、アプリケーションＩＤ及びセーブデータは、各アプリケーションと連動したＷＥＢサイトでも使用される。このＷＥＢサイトはユーザが帰宅後、ユーザのパソコンや携帯電話等のＷＥＢブラウザからアクセスする。
ユーザが自己のユーザＩＤを入力してログインすると、センターサーバ１はユーザＩＤ関連付けられたセーブデータを選択する。そして、センターサーバ１は、ユーザによるアプリケーションの進行具合であるセーブデータに基づいて、ＷＥＢサイトで表示するコンテンツを変化させる。
例えば昆虫採集アプリに対応したＷＥＢサイトでは、センターサーバ１は、セーブデータに含まれるユーザが捕まえた昆虫のデータに対応する図鑑を表示する。また、センターサーバ１は、多数のユーザのセーブデータから各ユーザの昆虫採集数を比較したランキング画面を表示する。
【００６０】
また、センターサーバ１はユーザが当該ＷＥＢサイト上で行った操作に応じてセーブデータに追加を行う場合がある。例えば、ＷＥＢサイト上で行ったミニゲームの結果に応じてセーブデータ中の仮想のアイテム、お金又は経験値といったデータを増加させたり、携帯端末５側のアプリケーション情報で特定のイベントを発生させるためのフラグ情報を追加したりする。
また、センターサーバ１は、ＷＥＢサイト上で行ったミニゲームの結果に応じてパスワードを表示する。ユーザが携帯端末５上でアプリケーションを実行する際に当該パスワードを入力すると、アプリケーションプログラムの処理として、仮想のアイテム、お金又は経験値といったデータを増加したり、携帯端末５側のアプリケーション情報で特定のイベントを発生させるためのフラグ情報を発生したりする処理が、プロセッサ４１によってなされる。
【００６１】
次に、図３のステップＳ２１で実行されるアプリケーションの例について説明する。
【００６２】
（ロールプレイングアプリケーション）
このアプリケーションは、ミッションを選択し、特定の敵キャラクタの打倒や特定のアイテムの取得等、ミッションごとに設定された条件をクリアしていくロールプレイングゲームを行うアプリケーションである。
ユーザが携帯端末５を操作しながら施設内を巡回し、アプリケーションプログラムが規定する条件を満たすと、会話イベント、戦闘イベント、回復イベント、買物イベント、ミニゲームイベント等のイベントが発生する。
イベント発生の条件として、ロケータＩＤの受信、歩数、携帯端末５が特定の方向を向いていること、残り時間、特定のアイテムデータを持っていること、特定のイベントをクリアしたこと等のいずれか又はそれらの組み合わせが使用される。
アプリケーションに用意されたイベント発生の条件テーブルは、ミッション毎に用意されている。このため、ユーザはミッション毎に異なるイベントを体験することができる。
【００６３】
上述のロケータＩＤテーブルによって、各ロケータＩＤに対応して、「草原」、「森」、「氷原」、「砂漠」、「遺跡」等の仮想フィールド情報が割り当てられている。それぞれの仮想フィールドは、実フィールドにおける距離が近いロケータ７が同じ仮想フィールドを割り当てられる。このため、近接する複数のロケータ７によって、比較的広い範囲の仮想フィールドが構成される。但し、管理者又はオペレータは、各仮想フィールドを近くのロケータ７同士でまとめずに、ばらばらに配置することもできる。
ロケータＩＤテーブルは、ミッションの種類にかかわらず共通で使用される。異なるミッションを実行するユーザの携帯端末５間であっても、同じ実フィールドにいれば、同じ仮想フィールドにいると判定される。もちろん、携帯端末５毎に、同じ実フィールドにいても、違う仮想フィールドにいると判定することも可能であるが、近くにいる携帯端末５間で通信プレイを行う場合があるため、通信プレイを行うユーザが共通体験を得やすいように、このように設定されている。
プロセッサ４１は、ロケータＩＤを受信すると、ロケータＩＤテーブルを参照し、ロケータ情報を取得する。そしてアプリケーションプログラムに従い、当該ロケータ情報を取得した場合の処理を実行する。
【００６４】
ロールプレイングアプリケーションの処理を開始すると、プロセッサ４１は、ミッション選択画面を表示し、ユーザにミッションを選択させる。ミッションには難易度が設定されている。難しいミッションは、規定のミッションをクリアする等の条件がフラグとなって、選択可能になる。また、図３のステップＳ１３で受付端末３から携帯端末５に送信される情報に応じて、ミッションが選択可能になる場合もある。例えば現実のイベントに合わせてある日時において、又はそれ以降の日時からミッションが選択可能になるという処理がなされる。
【００６５】
まず、ミッションの流れについて例を用いて説明する。
上述の通り、イベントの発生条件や出現するアイテムや敵キャラクタのデータテーブルはミッション毎に異なるようにプログラミングされている。
あるミッションでは、プロセッサ４１は、ユーザが移動を開始し、ロケータ情報が「草原」であるロケータＩＤを受信すると、会話イベントを発生させる。
プロセッサ４１は、会話イベント中、ボスキャラクタが「遺跡」にいるというユーザに対する手がかりを表示し、ボスキャラクタと戦闘イベントが発生させるためのボス戦闘フラグを設定する。
その後プロセッサ４１は、再びユーザが移動し、ロケータ情報が「遺跡」のロケータＩＤを受信すると、上記のボス戦闘フラグが設定されていることを確認して、ボスキャラクタとの戦闘イベントに移行する。
プロセッサ４１は、戦闘イベント処理を実行し、ユーザが勝利条件を満たしたと判定すると、勝利演出を行い、ボスキャラクタ毎に定められた経験値、お金及びアイテム等を追加する。そして、プロセッサ４１は、ミッションクリアと判定し、再びミッション選択画面を表示する。但し、図３のステップＳ１９の第１タイマ処理において、残りプレイ時間が無い場合は、ステップＳ２１の終了表示処理を行う。
ユーザが敗北条件を満たしたと判定すると、プロセッサ４１は敗北演出を行い。戦闘イベントを終了する。そしてプロセッサ４１は、回復イベントが発生するまで、各種イベントに遷移しない。回復イベントは、回復イベント用のロケータ情報が割り当てられたロケータＩＤを受信することで発生する。
【００６６】
上記の処理の流れの途中、ロケータＩＤの受信、ロケータＩＤの累計受信回数、歩数や残り時間等の所定の条件によって一般敵キャラクタとの戦闘イベントに遷移する場合がある。この戦闘イベントにおいてもプロセッサ４１は上記と同様の処理を行う。但し、プロセッサ４１は、上記のボスキャラクタとの戦闘イベントとは異なり、勝利してもミッションクリアとは判定せず、敵キャラクタ毎に定められた経験値、お金及びアイテム等が追加するのみである。経験値が一定数量以上たまると、ユーザのゲーム中でのレベルが上昇し、一度の攻撃で敵キャラクタに与えるダメージや、敵キャラクタからの攻撃に対する耐久度等のパラメータが上昇し、敵キャラクタを倒しやすくなるため、ボスキャラクタとの戦闘イベントに敗北したユーザは、このような一般敵キャラクタとの戦闘イベントをこなすことで、レベルを上げて再度ボスキャラクタとの戦闘イベントに挑戦する。
【００６７】
（待機画面）
次に、携帯端末５に表示される画面例について説明する。
特定のイベントが発生していない場合、現在の残りプレイ時間、歩数、現在の仮想フィールド、所持アイテム、金銭、現在遂行中のミッション、次にどこに行けばゲームが進行するかの手がかり情報等の各種ゲーム状態を表示する待機画面が表示される。現在の仮想フィールドは、プロセッサ４１が最後に受信したロケータＩＤのロケータ情報から決定される。
この待機画面には、施設毎に特有のメッセージテロップも表示される。メッセージの内容は図３のステップＳ１３において、受付端末３から送信される情報に含まれている。また、当該メッセージの内容は、図４で説明したＷＥＢ管理画面上で、管理者又はオペレータによって予め編集されている。普段はメッセージを表示せず、特定のロケータＩＤを受信すること等をトリガとして、当該メッセージを携帯端末５上で表示させる場合もある。
【００６８】
（確認画面）
ロケータＩＤの受信等、イベント発生条件が満たされると、プロセッサ４１は、スピーカ１７から注意音を鳴らし、周囲が安全な場所かユーザに確認させるための確認画面を表示する。ユーザがスイッチ１５を押すことに応じて、各種イベント画面に遷移する。
【００６９】
（探索画面）
プロセッサ４１は、特定の条件が満たされることに応じて、上記確認画面を経て探索画面を表示する。
探索画面には、現在の仮想フィールドに応じて用意される背景が表示される。当該背景はＬＣＤパネル１１の解像度より大きな一枚の絵として用意されており、ＬＣＤパネル１１に表示される範囲は一部分である。
プロセッサ４１は、状態センサ４７からの出力によって、携帯端末５の向き、姿勢を判定する。そしてプロセッサ４１は、携帯端末５の向き、姿勢の変化に応じて背景の表示範囲をスクロールさせる。このため、携帯端末５を持ちＬＣＤパネル１１を見ているユーザには、自分の視線の変化に合わせて背景が変化するように見える。
背景画像は左右が切れ目なく繋がった画像であり、ユーザを中心とした３６０度の回転を行うと、背景も一周して元の表示位置が表示されるように調整されている。但し、上下方向のスクロールは、背景画像の上端又は下端までで制限される。
このように、ユーザに疑似的な３６０度の視界が提供される。なお、今回は一枚の絵を使う手法を紹介したが、ポリゴン等の３Ｄモデルで背景を構成し、状態センサ４７の出力に応じて仮想のカメラの座標及び向きを決定することによって、ユーザに疑似的な３６０度の視界を提供する手法もある。
【００７０】
なお、この実施の形態では、プロセッサ４１は、背景画像の左右方向へのスクロールを状態センサ４７の地磁気センサの出力（地磁気の方向から、携帯端末５が向いている東西南北の方位が判定できる。）から判定し、背景画像の上下方向へのスクロールを三軸加速度センサ（重力加速度の方向の変化から、携帯端末が上向きか下向きかといった向きが判定できる。）の出力から判定している。
【００７１】
アプリケーションプログラムに応じて、プロセッサ４１は背景画像上の各所にアイテム、キャラクタ、店等を表現したオブジェクトを配置する。また、背景画像の表示範囲の中央に、円形のカーソルを表示する。これらの各種オブジェクトとカーソルとが重なること、重なった状態で一定時間が経過すること、重なった状態でスイッチ１５が押されることなどをトリガとして、プロセッサ４１は各種処理を実行する。
例えば、アイテムのオブジェクトであればアイテムの取得処理が実行される。キャラクタのオブジェクトであれば会話イベント、戦闘イベント又はミニゲームイベントへの遷移処理が実行される。店オブジェクトであれば買物イベントへの遷移処理が実行される。
【００７２】
探索画面への遷移は、通常ロケータＩＤの受信によって発生する。しかし、ユーザは待機画面における選択操作によって探索画面に遷移することもできる。この場合、背景上に配置されるオブジェクトはランダムで決定される。但し、オブジェクトが配置されておらず、何もイベントが発生しない場合が多い。また、ミッションの進行に必要なイベント等へと遷移するようなオブジェクトは配置されない。ユーザがロケータ７をなかなか発見できず、イベントが発生しない場合において、ユーザが退屈しないようにするための措置である。
【００７３】
さて、上記のような視界の遷移、カーソルの移動及びオブジェクトの選択は、戦闘イベントやミニゲームイベント中でも行われる。一部のイベントにおいては、上下左右方向へのスクロールではなく、左右方向又は上下方向へのスクロールに限定し、カーソルをオブジェクトに合わせやすくする場合もある。
また、このロールプレイングアプリケーション以外の携帯端末５用のアプリケーションでも同様の処理が利用される。
【００７４】
（戦闘イベント）
次に戦闘イベントについて説明する。このゲームではターン制の戦闘システムが採用されている。
戦闘イベントへの遷移が発生すると、プロセッサ４１は出現する敵キャラクタの種類、数及び座標を決定する。ユーザが攻撃、防御、逃走、アイテムを使う等の行動コマンドを選択すると、プロセッサ４１は敵キャラクタの行動を決定し、ターンを開始する。攻撃方法には複数種類が用意され、ユーザの選択に応じて選択される。
プロセッサ４１は、１ターンごとにユーザ側と敵キャラクタ側の行動に対応したアニメーションの表示と、行動の結果の判定を行う。例えば、攻撃コマンドに応じて、相手の耐久度データが減少する。
プロセッサ４１は、行動の結果、敵キャラクタの耐久度データが０以下になれば、ユーザの勝利と判定する。逆にユーザの耐久度データが０以下になれば、ユーザの敗北と判定する。
【００７５】
ユーザが攻撃コマンド及び攻撃方法の種類を選択した後、プロセッサ４１は、探索画面と同様に背景、カーソル及び敵キャラクタのオブジェクトが表示する。カーソルが敵キャラクタオブジェクトに重なった状態でスイッチ１５が押されると、プロセッサ４１は、ユーザの当該敵キャラクタに対する攻撃を確定し、対応するアニメーション表示の後、当該敵キャラクタの耐久度を減少させる。
敵キャラクタの座標と携帯端末５の向きによっては、敵キャラクタが画面中に表示されていない場合がある。この場合ユーザは、携帯端末の向きを変えることによって敵キャラクタを探し出し、カーソルを重ねる必要がある。カーソルの表示時間には制限時間があり、制限時間が０になるまでに攻撃を確定できない場合、ユーザから敵キャラクタへの攻撃は行われず、敵キャラクタからユーザへの攻撃のみが実行される。逆に素早く攻撃を確定させる場合、敵キャラクタの耐久度の減少量が増加する等、ユーザに有利な処理が行われる。
敵キャラクタオブジェクトの位置が常に移動する場合もある。
敵キャラクタの種類によっては、「頭」、「体」、「しっぽ」等の複数の部位が存在し、カーソルを重ねた位置に応じて耐久度の減少量が異なる。
また、プロセッサ４１は、ターン終了時に「敵が移動した」と表示して、敵キャラクタの座標を変更する場合がある。
【００７６】
（通信プレイ）
次に、通信プレイについて説明する。携帯端末５は、位置検出部４５（ＲＦモジュール）を使って通信プレイを行うことができる。携帯端末５はそれぞれが識別情報を有している。通信プレイを行う場合、ゲーム開始前の受付端末３との通信時に予め設定を行い、通信を行う対象となる識別情報を持つ携帯端末５のグループが設定される。このときいずれか１台の携帯端末５が親機として設定される。また、各携帯端末５は、同一グループに属する携帯端末５の識別情報及び、どの携帯端末５が親機かを示す情報を記憶する。
【００７７】
この実施の形態では、常時携帯端末５のグループ間で通信を行うのではなく、ホストの携帯端末５で戦闘イベントや特定のイベントを開始する場合に、近くにグループに属する携帯端末５がいる場合に通信が開始され、同じイベントが同期をとりながら各携帯端末５上で実行される。
【００７８】
例えば、親機がロケータ情報を取得し、さらにその時に同一グループに属する他の携帯端末５との通信プレイ状態にあることをトリガとして、イベントが発生する。
この時、親機が当該ロケータ情報の取得後一定時間内に子機との通信が確立できたことによってイベントの成立を判定し、イベント成立情報を子機にも送信する。そして、当該イベント成立情報に応じて、親機及び子機上で同一のイベントが進行する。
また、通信プレイ状態の親機と子機とが協力してフラグを立てるイベントも存在する。例えばグループ内でのあるイベント用アイテムの所有数の合計が１０以上になることをフラグとするイベントが存在する。
まず各ユーザは離れて単独プレイ状態で行動し、ゲームをこなしてイベント用アイテムを集める。そして、当該イベントが発生するロケータ７の位置で集合する。親機が当該ロケータのロケータ情報を取得し、親機と子機とが通信プレイ状態にあるかをチェックする。通信プレイ状態にある場合、イベントが開始される。この時各携帯端末５は、親機にイベント用アイテムの所持数を送信する。親機は所持数を計算し、それが１０個以上か否かによって、イベントがクリアされたと判定し、次のイベントを表示するための情報を各子機に送信する。
【００７９】
戦闘イベントにおいても、通信プレイが可能である。上述の戦闘イベント開始時に親機は周辺の子機に対して、戦闘イベントに参加するかを確認する。
参加選択を行った子機と親機は通信プレイ状態で戦闘イベント処理を実行する。戦闘イベントは、上述のターン制バトルが採用される。各携帯端末５はコマンドを選択し、選択結果を親機に送信する。例えば攻撃コマンドを選択した場合及び攻撃の種類と攻撃の対象の敵キャラクタを示すデータを送信する。親機は、受信した味方のコマンドを集計し、敵キャラクタの行動を決定し、そのターンの結果を演算する。親機は演算結果を子機に送信し、当該演算結果に応じた戦闘演出が各携帯端末５で表示される。
【００８０】
戦闘イベント中、途中で子機のユーザが親機の通信範囲から離脱するなどして子機との通信が途絶えると、親機は当該子機のユーザが逃亡したと表示し、残りの子機と戦闘イベントを継続する。
再度離脱した子機のユーザが親機の近くに戻ってきた場合、親機と当該子機は通信を再開し、戦闘イベントが終了していない場合は、次のターンから再度子機のユーザを戦闘イベントに参加させる。例えば、戦闘イベントから一時離脱して回復イベントを経て、再度親機の元に戻り、戦闘イベントに参加するということも可能である。
【００８１】
このようにユーザはある時は離れて行動し、ある時は集まって同じイベントを同時に楽しむことができる。離れている間も各携帯端末５上では、プロセッサ４１は単独でアプリケーションを進行させ、各種イベントを発生させる。
【００８２】
（町探索アプリケーション）
次に、携帯端末５で実行されるアプリケーションの別の例として、町探索アプリケーションを説明する。このアプリケーションでは、ロケータＩＤ毎にロケータ情報として「自宅」、「学校」、「店１」、「店２」、「高原」、「広場」、「海」等の仮想エリア情報が割り当てられ、仮想の町が構成される。複数個のロケータＩＤが一つの仮想エリアを構成する場合もある。ユーザは仮想の町を探索し、アイテムの収集、ミニゲーム或いはキャラクタとの会話イベント等を楽しむ。
【００８３】
ユーザは受付端末３で携帯端末５を受け取ったのち、施設内を移動する。この移動中は、上述の待機画面と同様の、ゲーム情報を表示した画面が表示される。
ロケータＩＤを受信すると、プロセッサ４１はロケータＩＤテーブルに基づきロケータ情報を解釈し、仮想エリアを表現した画面に遷移する。
この画面は上述の探索画面と同様に、ロケータ情報に応じた背景が表示され、そこにキャラクタ等のオブジェクトが配置される。プロセッサ４１は、当該オブジェクトがユーザに選択されることで、オブジェクト毎に割り当てられた会話イベントやミニゲームイベントに遷移する。プロセッサ４１は、会話イベントやミニゲームイベントの結果に応じて、アイテムやお金等を取得する処理を行う。配置されるキャラクタ、イベント、ミニゲーム等は、仮想エリア情報毎にアプリケーション側でテーブルが用意されている。
ロケータ情報が「店」だった場合、プロセッサ４１は、買い物イベントに遷移し、アイテムの一覧と価格を表示する。プロセッサ４１は、ユーザの選択に応じてアイテムの取得及びお金の減少処理を行う。
【００８４】
「自宅」のロケータ情報を取得すると、プロセッサ４１は、自宅画面に遷移する。自宅画面では取得した家具アイテムを並べて楽しむことができる。家具データ及び家具配置データはセーブデータの一部として記憶される。
センターサーバ１はこのアプリケーションのためのＷＥＢサイトにおいて、セーブデータ中の当該家具データ及び家具配置データに基づき、ユーザの自宅画面と同様の家具を配置する。このためユーザは帰宅後も自分の取得した家具を見て楽しむことができる。
【００８５】
このアプリケーションではＩＲモジュール５５を使って、外部の機器、例えば赤外線通信を使う玩具から赤外線信号を受信し、アイテム取得等のイベントが発生する。また、携帯端末５同士で通信を行い、アイテムの交換をすることもできる。
【００８６】
さて、以上のように本実施の形態によれば、各施設のロケータ７毎にアプリケーションのためのロケータ情報を設定・編集できるため、現在位置に応じた処理の内容を柔軟に設定できる。また、施設におけるロケータ７の配置状態に合わせてロケータ情報を設定・編集できるため、様々な施設及びそのユーザに向けてシステムを提供することができる。
また、ロケータ７の配置に変更が生じた場合でも、ロケータＩＤテーブルを通じて修正を行うことで、アプリケーションが実行できなくなるという事態を回避することができる。
さらに、アプリケーション側に変更や追加が生じた場合に、ロケータＩＤテーブルでロケータ情報を修正すれば、ロケータ７の配置まで変更や追加をせずに済む。
【００８７】
アプリケーション毎にロケータＩＤに対応したロケータ情報を編集できるため、多様なアプリケーションを同じシステムを使用して同時に同じ場所で実行できる。
【００８８】
各施設のロケータ７の配置に合わせて、アプリケーションのためのロケータ情報を設定・編集できるため、様々な施設に向けて同時にこのシステムを提供することができる。また、ある施設においてロケータ７の配置状況に変更が生じた場合でも、ロケータＩＤテーブルで当該施設の設定を再編集すれば、アプリケーションや他の施設の設定を修正する必要が無い。
【００８９】
あるパラメータが関連付けられた区域に行けば必ず一定の処理が行われるということがない。また、ユーザは位置とイベント発生の関係を簡単には把握できないため、ユーザにとって飽き難いシステムを提供することができる。
【００９０】
複数のロケータＩＤが受信される場所があったとしても、プロセッサ４１の処理が滞らない。また、警告用表示等の重要な処理が優先して実行させるため安全である。
【００９１】
プロセッサ４１は、ロケータ７のロケータＩＤを受信し、解読するという簡単な処理によって、現在位置がいずれの区域にあるかを判別することができる。ロケータ７を配置するだけで、どのような実空間であっても容易に区域の設定ができる。
さらに、同様機材を配置した施設において、同じアプリケーションを提供することができる。施設毎に前記発信機を配置できる場所や数は変わりうるが、前記編集手段によって、地域・施設の状態に合わせて柔軟にシステムの調整を行うことができる。
【００９２】
（変形例）
上記の実施の形態では、位置検出部４５として、ＲＦモジュールを使用し、施設内に配置されたロケータ７から発信されるロケータＩＤによって携帯端末５の相対的な位置を検出した。また、各ロケータＩＤの受信可能範囲によって区域分けができていた。
しかし、位置検出部４５は、携帯端末５の絶対的位置又は相対的位置を検出し、当該位置がどのような区域にあるのかを判別する手段があれば、その検出方法は特に限定されない。また、そのような手段がある限り、本発明に基づくシステムを実施する場所は、屋外であっても構わない。
【００９３】
携帯端末５の絶対的位置を検出する場合、例えば、位置検出部４５としてＧＰＳ受信機を使用する。そして、プロセッサ４１は、周知の位置算出アルゴリズムに従って、ＧＰＳ受信機からの信号を処理及び解析して、携帯端末５の位置を算出する。この場合、別途区域分けが必要となる。例えば、センターサーバ１に、ある程度の範囲の位置情報毎に区域分けを行い、パラメータを割り当てたデータベースを用意する。
また、位置検出部４５として電波受信機を使用する場合においても、ロケータ７の代わりに複数の発信機（例えば、微弱電波の発信機、携帯電話機の基地局、又は無線ＬＡＮのアクセスポイントなど）を配置し、携帯端末５側に対応する受信手段を設けてもよい。発信機からはロケータＩＤに対応する固有の識別情報が送信される。そして、プロセッサ４１は、当該識別情報を受信し、それをデコードして、自己の位置を算出する。
【００９４】
上記の例では各ロケータＩＤに応じてロケータ情報を割り当てていたが、複数のロケータＩＤの組合せにより、ロケータ情報を決定する方式を採用してもよい。
【００９５】
携帯端末５の相対的位置を検出する場合、例えば、位置検出部４５としてＲＦタグを使用してもよい。この場合、複数のＲＦリーダ／ライタをプレイエリア９に配置する。そして、ＲＦリーダ／ライタにより、ＲＦタグにＲＦリーダ／ライタの位置を書き込む。また、例えば、位置検出部４５としてＲＦリーダ／ライタを使用する。この場合、複数のＲＦタグをプレイエリア９に配置する。そして、ＲＦリーダ／ライタにより、ＲＦタグが保持する位置情報を読み込む。
【００９６】
状態センサ４７は、携帯端末５の三次元空間中の状態（姿勢を含む。）を検出できるものであれば、その種類は問わない。例えば、状態センサ４７は、加速度センサ、ジャイロセンサ、方位センサ、若しくは、傾斜センサ、又は、それらの２以上の組合せである。また、歩数や方位等をプロセッサ等の処理機に直接数値として出力するモジュールも存在するため、そういったモジュールを採用してもよい。
【００９７】
上記の例では携帯端末５は施設が所有し、ユーザに貸し出していたが、携帯端末５はユーザに所有物であってもよい。また、本システムのための専用の端末ではなく、汎用のゲーム機やコンピュータであってもよい。
【００９８】
上記の例ではロケータ７は一方的にロケータＩＤを発信する機器であった。しかし、通信機能を有し、携帯端末５や受付端末３と通信し可能なロケータを採用してもよい。また、ロケータＩＤに相当する発信情報を、後から変更できる機器を採用してもよい。
【００９９】
上記の例ではネットワークを介してセンターサーバ１上で、区域（ロケータＩＤ）とパラメータ（ロケータ情報）との関連付け及びその修正処理を行った。しかし、システムはある特定の施設内に限定されるものであってもよく、例えばセンターサーバ１の処理を施設の受付端末３に相当する端末が行う構成であってもよい。さらに、携帯端末５に相当する端末が全ての処理を行う構成であってもよい。
【産業上の利用可能性】
【０１００】
本発明は、例えば、ユーザの位置に応じた処理を実行するエンターテインメントシステムや、ユーザの位置に応じてその周辺にあるものを案内するシステム等に利用可能である。
【符号の説明】
【０１０１】
１…センターサーバ、３…受付端末、５…携帯端末、７…ロケータ
【特許請求の範囲】
【請求項１】
実空間に区域を設定する区域設定手段と、
前記区域毎にアプリケーション処理のためのパラメータを関連付ける関連付け手段と、
前記関連付けを編集する編集手段と、
携帯端末上でアプリケーションを実行するアプリケーション実行手段と、を備え、
前記アプリケーション実行手段は、
前記携帯端末の現在地がいずれの前記区域にあるかを判定する判定手段と、
前記判定の結果に応じて、前記区域と関連付けられた前記パラメータを取得する取得手段と、を含み、前記パラメータに応じた処理を実行する、自己位置利用システム。
【請求項２】
前記アプリケーションは複数種類存在し、
前記編集手段は、前記アプリケーションの種類毎に前記区域と前記パラメータとの関連付けを編集する、請求項１記載の自己位置利用システム。
【請求項３】
前記区域設定手段は、施設単位で前記区域を設定し、
前記編集手段は、前記区域と前記パラメータとの関連付けを編集する、請求項１又は２に記載の自己位置利用システム。
【請求項４】
前記アプリケーション実行手段は、
同一の前記パラメータが関連付けられた前記区域の中から、一つ又は複数の前記区域を選択する区域選択手段をさらに含む。
【請求項５】
前記アプリケーション実行手段は、
前記パラメータ取得時、何れの前記区域において前記パラメータを取得したかを記録する履歴手段をさらに含む、請求項１から４の何れかに記載の自己位置利用システム。
【請求項６】
前記アプリケーション実行手段は、
前記パラメータに応じた処理について、優先順位を設定する優先順位設定手段をさらに含み、
前記区域が重なる範囲において、前記パラメータ取得手段が複数の前記パラメータを取得する場合に、前記優先順位に基づいて実行する処理を選択する、請求項１から５の何れかに記載の自己位置利用システム。
【請求項７】
前記区域は、各所に配置された発信機が発信する信号の受信可能範囲であり、
前記判定手段は、前記信号に含まれる前記発信機毎に固有の情報に基づいて前記判定を行う、請求項１から６の何れかに記載の自己位置利用システム。
【請求項１】
実空間に区域を設定する区域設定手段と、
前記区域毎にアプリケーション処理のためのパラメータを関連付ける関連付け手段と、
前記関連付けを編集する編集手段と、
携帯端末上でアプリケーションを実行するアプリケーション実行手段と、を備え、
前記アプリケーション実行手段は、
前記携帯端末の現在地がいずれの前記区域にあるかを判定する判定手段と、
前記判定の結果に応じて、前記区域と関連付けられた前記パラメータを取得する取得手段と、を含み、前記パラメータに応じた処理を実行する、自己位置利用システム。
【請求項２】
前記アプリケーションは複数種類存在し、
前記編集手段は、前記アプリケーションの種類毎に前記区域と前記パラメータとの関連付けを編集する、請求項１記載の自己位置利用システム。
【請求項３】
前記区域設定手段は、施設単位で前記区域を設定し、
前記編集手段は、前記区域と前記パラメータとの関連付けを編集する、請求項１又は２に記載の自己位置利用システム。
【請求項４】
前記アプリケーション実行手段は、
同一の前記パラメータが関連付けられた前記区域の中から、一つ又は複数の前記区域を選択する区域選択手段をさらに含む。
【請求項５】
前記アプリケーション実行手段は、
前記パラメータ取得時、何れの前記区域において前記パラメータを取得したかを記録する履歴手段をさらに含む、請求項１から４の何れかに記載の自己位置利用システム。
【請求項６】
前記アプリケーション実行手段は、
前記パラメータに応じた処理について、優先順位を設定する優先順位設定手段をさらに含み、
前記区域が重なる範囲において、前記パラメータ取得手段が複数の前記パラメータを取得する場合に、前記優先順位に基づいて実行する処理を選択する、請求項１から５の何れかに記載の自己位置利用システム。
【請求項７】
前記区域は、各所に配置された発信機が発信する信号の受信可能範囲であり、
前記判定手段は、前記信号に含まれる前記発信機毎に固有の情報に基づいて前記判定を行う、請求項１から６の何れかに記載の自己位置利用システム。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−１９４９４（Ｐ２０１２−１９４９４Ａ）
【公開日】平成２４年１月２６日（２０１２．１．２６）
【国際特許分類】
【出願番号】特願２０１０−１５７３４６（Ｐ２０１０−１５７３４６）
【出願日】平成２２年７月９日（２０１０．７．９）
【出願人】（３９６０２５８６１）新世代株式会社 (138)
【Ｆターム（参考）】
【公開日】平成２４年１月２６日（２０１２．１．２６）
【国際特許分類】
【出願日】平成２２年７月９日（２０１０．７．９）
【出願人】（３９６０２５８６１）新世代株式会社 (138)
【Ｆターム（参考）】
[ Back to top ]