携帯端末
【課題】 携帯端末においてアプリケーションに位置情報を効率的に受け渡す。
【解決手段】 携帯電話１００には、位置情報を利用する種々のアプリケーションがインストールされている。携帯電話１００は、位置情報取得部を複数備えており、これらの位置情報取得部１３１を用いて位置情報を取得するとともに、アプリケーションに位置情報を受け渡すための位置情報管理部１２０を備えている。位置情報管理部１２０は、取得した位置情報を複数の形式で位置ログ１２１に蓄えている。アプリケーションから位置情報の要求が来ると、位置情報管理部は、位置ログ１２１に蓄えられた情報を受け渡す方法、新たに位置情報取得部のいずれかを利用して位置情報を取得する方法を比較し、要求された精度に適合した位置情報を最小の消費電力で取得可能な方法を選択して、位置情報の取得および受け渡しを行う。
【解決手段】 携帯電話１００には、位置情報を利用する種々のアプリケーションがインストールされている。携帯電話１００は、位置情報取得部を複数備えており、これらの位置情報取得部１３１を用いて位置情報を取得するとともに、アプリケーションに位置情報を受け渡すための位置情報管理部１２０を備えている。位置情報管理部１２０は、取得した位置情報を複数の形式で位置ログ１２１に蓄えている。アプリケーションから位置情報の要求が来ると、位置情報管理部は、位置ログ１２１に蓄えられた情報を受け渡す方法、新たに位置情報取得部のいずれかを利用して位置情報を取得する方法を比較し、要求された精度に適合した位置情報を最小の消費電力で取得可能な方法を選択して、位置情報の取得および受け渡しを行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，位置情報の取得機能を有する携帯端末に関し、詳しくは携帯端末にインストールされた種々のアプリケーションからの要求に適合した位置情報を取得、提供する技術に関する。
【背景技術】
【０００２】
携帯電話その他の携帯端末は、近年、種々のアプリケーションをインストールして稼働することができる。中には、次に示すように、位置情報を利用するアプリケーションもある。例えば、現在位置を地図上で表示する位置探知、地図に目的地までの経路を案内するナビゲーション、現在位置を住所、建物等の名称などの文字情報で提供する地点案内、現在位置に近いレストランなどを案内する周辺情報提供、携帯端末を所持して予め設定された複数の地域を全て訪問することを目的とするゲーム（以下、「国盗りゲーム」という）などである。
このように位置情報を利用するアプリケーションが複数稼働している場合、従来は、各アプリケーションが個別に位置情報を取得していたため、非効率であった。かかる点の解決を図った先行技術としては、次の文献が挙げられる。
【０００３】
特許文献１は、携帯端末において、あるアプリケーションから位置情報が要求された場合、直近の測位結果を参照し、その測位結果よりも低い精度で位置情報が要求されている場合や、直近の測位から比較的短時間しか経過していないような場合には、改めて位置情報の測位を行うのではなく、取得済みの測位結果を活用する技術を開示する。
特許文献２は、ＧＰＳ（Global Positioning System）で測位した位置情報を、ネットワーク上のサーバに送信し、携帯端末よりも処理能力の高いサーバを利用することによって精度向上を図る技術を開示する。
特許文献３は、ロケーションマネージャなる概念を開示する。インストールされた各アプリケーションは、個別にＧＰＳ等を用いて位置情報を取得するのではなく、ロケーションマネージャに位置情報を要求するのである。ロケーションマネージャが、位置情報を取得する機能を一元的に管理することにより、アプリケーションとの間で効率的な位置情報の授受が可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１０１７８５号公報
【特許文献２】特開２００６−６４４６０号公報
【特許文献３】特開２００６−１５３８６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
位置情報を要求するアプリケーションの種類は多様であり、各アプリケーションが要求する位置情報の形式も多様である。ナビゲーションのように位置情報を座標形式で取得し、地図上に現在位置として表示するアプリケーションもあれば、国盗りゲームのように、特定の地域に訪れたか否かが確認できれば足り、位置情報が行政界などの住所や建物等の名称で取得できればよいアプリケーションもある。
従来技術では、アプリケーションによる位置情報の形式の相違は考慮されていなかった。従って、あるアプリケーションからの要求によって座標形式で位置情報が取得されている場合でも、他のアプリケーションから住所形式で位置情報が要求されれば、改めて位置情報を取得する必要があった。
このように座標形式が異なるだけで改めて位置情報を取得するのは、処理時間の面でも、携帯端末の消費電力の面でも非効率的であった。本発明は、かかる課題を解決し、携帯端末において、種々の形式での位置情報の取得の効率化を図ることを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、位置情報を利用したアプリケーションを稼働可能な携帯端末として構成することができる。本発明の携帯端末は、アプリケーションを保存するアプリケーション保存部、携帯端末の位置情報を取得する複数種類の位置情報取得部、および位置情報管理部を備える。位置情報管理部は、位置情報取得部による位置情報の取得および取得された位置情報の管理を行い、この位置情報をアプリケーションに対して受け渡す。管理とは、位置情報取得部を利用した位置情報取得の制御、取得された位置情報の記憶、データ変換、削除、アプリケーションへの受け渡しなどの処理を含む。
位置情報取得部は、複数種類備えられている。位置情報取得部としては、例えば、ＧＰＳ、ジャイロや地磁気センサを利用したもの、携帯端末と基地局との通信を利用するもの、いわゆる電子マネーや駅の改札口など基地局以外の通信端末と携帯端末との通信を利用するもの、無線ＬＡＮ（Local Area Network）の基地局との通信を利用するもの、ＲＦＩＤタグと呼ばれる通信施設との通信を利用するもの、マップマッチングなど種々の態様で構成することができる。取得できる位置情報の表現形式は、例えば、緯度経度などの座標系、住所、建物や路線などの名称、マップコードなど種々の形式をとることができ、位置情報取得部ごとに異なっている。一つの位置情報取得部で複数の形式で位置情報の取得が可能なものが含まれていても良い。また、ネットワーク上の特定のサーバにアクセスして、取得された位置情報の表現形式を他の形式に変換する機能を奏する部分を位置情報取得部の一つとして構成することもできる。位置情報取得部の種類とは、位置情報の取得方法、表現形式に基づいて考えることができ、例えば、通信端末を利用した位置情報取得部を複数備えている場合であっても、それぞれの通信端末で取得し得る位置情報の形式が異なるのであれば、複数種類の位置情報取得部を搭載していると言うことができる。
【０００７】
本発明の位置情報管理部は、次の機能を実現する。
位置情報を取得した場合、その位置情報が、予め設定された複数の形式のうち一部の形式のみで取得されている場合には、不足する形式に位置情報を変換する。
例えば、該携帯端末で利用する位置情報の形式として、座標、名称、住所の３形式が設定されている場合、座標形式でのみ位置情報が取得されているときは、名称、住所の形式が不足するから、座標から、名称、住所に変換するのである。
位置情報の変換は種々の方法をとることができる。例えば、携帯端末内に変換に要するデータベースを蓄積しておく方法をとってもよい。また、ネットワーク上のサーバにアクセスして形式の変換を行うようにしてもよい。
位置情報管理部は、こうして得られた複数の形式で位置情報を記憶している。取得した位置情報が複数の形式を満たす場合には、上述した変換を行うまでなく、これらの形式で位置情報を記憶すればよい。
アプリケーションから位置情報を要求されたときには、位置情報管理部は、記憶されている位置情報を優先的に用いて、位置情報を受け渡す。
【０００８】
本発明の携帯端末によれば、位置情報管理部が、上述の通り、複数の形式で位置情報を記憶しておくことにより、複数のアプリケーションから異なる形式で位置情報が要求された場合でも、既に取得済みの位置情報を有効活用することが可能となる。この結果、位置情報を取得する頻度を抑制でき、位置情報の受け渡しの効率化、および位置情報取得に伴う消費電力の抑制を図ることができる。
【０００９】
上述した複数の形式は、携帯端末で稼働するアプリケーションの種類とは無関係に広汎に設定しておくことも可能であるが、アプリケーションに基づいて設定することが好ましい。
例えば、位置情報管理部が、アプリケーションについて、位置情報の形式に関する仕様（以下、「形式仕様」ということもある）を記憶しておき、複数のアプリケーションの形式仕様に対応する形式の論理和によって、複数の形式を設定する方法をとることができる。携帯端末に登録されている第１のアプリケーションの形式仕様が座標、第２のアプリケーションの形式仕様が座標または名称である場合には、双方の論理和をとり、座標と名称の２つの形式を、位置情報取得および変換の際に対象とする複数の形式として設定するのである。このようにアプリケーションの形式仕様に基づいて形式を設定しておけば、利用される可能性のない形式での位置情報取得を抑制することができ、位置情報取得の処理負荷および消費電力の更なる軽減を図ることができる。
上述のようにアプリケーションに基づいて位置情報を取得すべき形式を設定する場合、アプリケーション保存部に保存されている全アプリケーションを対象として設定してもよい。また、現実に稼働しているアプリケーションのみを対象として設定してもよい。後者の態様によれば、新たなアプリケーションが起動した直後は、該アプリケーションに対応する形式での取得済みの位置情報が存在しないといった支障が生じるおそれがあるものの、取得対象とする形式をより絞り込むことができる点で効率化を図ることができる。
【００１０】
本発明においては、アプリケーションは位置情報の精度に関する仕様（以下、「精度仕様」ということもあり、形式仕様と精度仕様を「アプリケーション仕様」と総称することもある。）も設定可能としてもよい。精度仕様は、位置情報の許容誤差をメートル等の長さ、市町村などの行政界などの形式で表したものであり、アプリケーションによって異なる。
精度仕様が設定されている場合、位置情報管理部は、精度仕様を満たす位置情報を受け渡す。この場合、位置情報管理部は、取得済みの位置情報の精度を、取得後の経過時間に基づいて補正した上で、仕様に適合するか否かを判断するようにしてもよい。携帯端末は所有者の移動に伴って時間とともに移動する場合があり、位置情報の精度は取得後の時間経過に伴って劣化する傾向にある。このように経過時間を考慮して精度を補正することにより、アプリケーションの要求する精度に合致した位置情報を受け渡すことができる。
位置情報の精度補正は、種々の方法をとることができる。例えば、経過時間によって定まる補正係数を予め設定しておき、これを位置精度に乗じる方法をとってもよい。位置情報を繰り返し取得している場合には、過去の位置情報の履歴から携帯端末の移動速度を推定し、移動速度に応じた補正係数を設定するようにしてもよい。取得後の経過時間が所定値以上となった場合には、その位置情報は利用不能と考え、位置情報の精度が極端に悪化するような補正係数を設定してもよい。
また、補正係数は、位置情報取得部に応じて異なる設定としてもよい。取得時の位置情報の精度が高い場合には、精度が低い場合に比べて、携帯端末のわずかな移動でも精度に与える影響は大きいと考えられるからである。
位置情報管理部は、精度の仕様に適合する位置情報が存在しない場合には、位置情報取得部を用いてアプリケーション仕様に適合する位置情報を取得し、アプリケーションに位置情報を受け渡す。
かかる態様により、位置情報管理部は、取得後の精度劣化も考慮した上で、アプリケーション仕様に適合した位置情報を受け渡すことが可能となる。
【００１１】
位置情報を新たに取得する場合、位置情報管理部は、位置情報の取得に要する消費電力および取得された位置情報を複数の形式に変換するために要する消費電力が最小と評価される位置情報取得部を利用して位置情報の取得を行うようにしてもよい。
こうすることにより、携帯端末の電力消費を抑制することができる。この際、位置情報の取得に要する消費電力だけでなく、他の形式への変換に要する消費電力も併せて考慮することにより、それぞれの位置情報取得部を用いる場合の消費電力を適正に評価することが可能となる。
なお、位置情報取得部の選択は、全ての位置情報取得部の中から真に消費電力が最小となるものを選択するものに限定されるものではない。消費電力を所定の評価方法で推定し、その範囲で最小と評価されるものを選択するのである。例えば、位置情報の取得に要する電力は必ずしも一定とは限らず、電波環境などによって変化することもある。そこで、予め位置情報取得部ごとに設定された電力値を用いて消費電力を評価する方法をとることができる。また、複数のアプリケーションから位置情報が要求されている場合には、各アプリケーションごとに個別に電力最小の位置情報取得部を選択してもよいし、位置情報を要求している全アプリケーションを総合的に考慮して電力最小となる位置情報取得部を選択してもよい。
【００１２】
本発明は、上述した携帯端末としての構成の他、携帯端末において位置情報を取得する位置情報取得方法として構成してもよい。この方法は、携帯端末に搭載されたコンピュータが、上述の各機能を実行することによって実現することができる。
また、本発明は，上述の位置情報取得方法を、コンピュータに実行させるためのコンピュータプログラム、または、このコンピュータプログラムを記録したコンピュータが読み取り可能な記録媒体として構成してもよい。記録媒体としては，フレキシブルディスクやＣＤ−ＲＯＭ，光磁気ディスク，ＩＣカード，ＲＯＭカートリッジ，パンチカード，バーコードなどの符号が印刷された印刷物，コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等，コンピュータが読取り可能な種々の媒体を利用できる。
【図面の簡単な説明】
【００１３】
【図１】位置情報を利用する携帯電話のシステム構成を示す説明図である。
【図２】位置ログの内容を例示する説明図である。
【図３】位置情報要求イベント、出力イベントの内容を示す説明図である。
【図４】位置情報管理処理のフローチャートである。
【図５】出力イベント生成処理のフローチャートである。
【図６】位置情報取得手段の選択方法を示す説明図である。
【図７】位置情報取得処理のフローチャートである。
【図８】第２実施例における位置情報管理処理のフローチャートである。
【図９】第２実施例における位置情報取得処理のフローチャートである。
【発明を実施するための形態】
【実施例１】
【００１４】
＜＜ システム構成 ＞＞
図１は、位置情報を利用する携帯電話のシステム構成を示す説明図である。
実施例における携帯電話１００には、図示する種々の機能ブロックが備えられている。これらの機能ブロックは、携帯電話に搭載されたＣＰＵ、ＲＡＭ、ＲＯＭなどのコンピュータによってソフトウェア的に構成されている。機能ブロックの一部または全部は、ハードウェア的に構成してもよい。
アプリケーション保存部１１１は、複数のアプリケーション１、アプリケーション２、アプリケーション３等を保存している。本実施例では、各アプリケーションは位置情報を利用するものとして説明する。位置情報を利用するアプリケーションとしては、現在位置を地図上で表示する位置探知、地図に目的地までの経路を案内するナビゲーション、現在位置を住所、建物等の名称などの文字情報で提供する地点案内、現在位置に近いレストランなどを案内する周辺情報提供、国盗りゲームなどが挙げられる。
【００１５】
携帯電話１００には、位置情報を取得するための複数の位置情報取得部１３１が備えられている。
位置情報取得部１３１［１］は、携帯電話１００に備えられたアンテナ１０２で衛星からの電波を受信して携帯電話１００の位置情報を取得するＧＰＳである。位置情報は、緯度経度の座標値の形式で得られる。
【００１６】
位置情報取得部１３１［２］は、基地局２００を利用して位置情報を取得する。携帯電話１００は、着信を受けるため基地局２００と定期的に通信している。携帯電話１００が通信する基地局は、携帯電話１００の位置に応じて異なり、基地局の位置は既知であるから、いずれの基地局と通信しているかが分かれば携帯電話１００の位置情報を得ることができる。例えば、単一の基地局２００との通信電波の強弱によって基地局からの距離を推定し、携帯電話１００の位置を算出する方法、複数の基地局２００との通信電波の強弱によっていわゆる三角測量と同じ原理で携帯電話の位置を精度良く算出する方法などが知られている。いずれにおいても、基地局２００に接続された位置情報送信部２０２で、携帯電話１００の位置情報を解析し、携帯電話１００に送信する。位置情報は緯度経度の座標形式で得られる。
【００１７】
位置情報取得部１３１［３］は、通信端末を利用して位置情報を取得する。図の例では、コンビニエンスストアに設置されているレジ３００を利用する例を示した。レジ３００には、その位置情報を緯度経度、店舗名称、住所、マップコードなど種々の形式で登録した位置情報送信部３０２が備えられている。位置情報送信部３０２は、複数のレジ３００の情報を提供するネットワーク上のサーバとして構成してもよいし、レジ３００に内蔵してもよい。レジにおいて携帯電話１００を用いて電子マネーでの支払いを行うと、レジ３００と携帯電話１００が通信する際に、位置情報送信部３０２から得られる位置情報を携帯電話１００に送信する。本実施例では、上述した種々の形式の位置情報を一括して送信するものとしたが、携帯電話１００からの要求に応じて、いずれかの位置情報のみを送信してもよい。
【００１８】
位置情報取得部１３１［１］〜１３１［３］は例示である。携帯電話１００には、この一部のみを備えるようにしてもよいし、他の種類の位置情報取得部を備えても良い。位置情報取得部としては、例えば、無線ＬＡＮの基地局との通信を利用するもの、ＲＦＩＤタグと呼ばれる通信施設との通信を利用するもの、マップマッチングを利用するものなどを備えることができる。
なお、以下の説明では、位置情報取得部を「センサ」と称することもある。
【００１９】
位置情報管理部１２０は、各アプリケーションから位置情報の取得要求を受け付け、位置情報取得部１３１を利用して位置情報を取得して、この位置情報をアプリケーションに受け渡す機能を奏する。取得した位置情報は位置ログ１２１に記憶される。このように、各アプリケーションが、直接に位置情報取得部１３１を利用して位置情報を取得するのではなく、位置情報管理部１２０から位置情報を受け取る構成とした点が本実施例の特長の一つである。こうすることにより、複数のアプリケーションが稼働している場合であっても、位置情報管理部１２０が、位置情報の取得を一元的に制御し、得られた位置情報を一元的に管理して、アプリケーションに受け渡すことが可能となるのである。
本実施例では、位置情報管理部１２０は、アプリケーションからの位置情報の取得要求を受け付けると、直ちに位置情報の取得を行うのではなく、まず位置ログ１２１に蓄積された取得済みの位置情報得を参照し、この中にアプリケーションが要求するアプリケーション仕様に合致する位置情報があれば、それを受け渡す。かかる位置情報がない場合には、位置情報管理部１２０は、複数種類の位置情報取得部１３１の中から消費電力が最小となるものを選択して、位置情報を取得する。こうすることによって、効率的に位置情報を受け渡すことが可能となるのである。
【００２０】
本実施例では、位置情報管理部１２０は、イベントドリブン方式で稼働するものとした。つまり、各アプリケーションは、位置情報を必要とする場合には、「位置情報要求イベント」と称する定型のオブジェクトまたはデータを生成し、位置情報管理部１２０に受け渡す。種々のアプリケーションが位置情報を必要とするごとに個別の位置情報要求イベントが生成されるから、位置情報管理部１２０には、複数の位置情報要求イベントが蓄積されることになる。位置情報管理部１２０は、これらの位置情報要求イベントを監視することによって、どのアプリケーションから、どのような位置情報が要求されているかを知ることができる。
一方、位置情報要求イベントに合致した位置情報が取得されると、位置情報管理部１２０は、「出力イベント」と称する定型のオブジェクトまたはデータを生成し、出力イベントを各アプリケーションに受け渡すことによって位置情報を伝達する。
位置情報要求イベントおよび出力イベントの内容は後述する。
【００２１】
携帯電話１００は、基地局２００を介してインターネットＩＮＴに接続することができ、インターネットＩＮＴ上に接続された地図サーバ４００にアクセスすることができる。地図サーバ４００には、地図データが登録されている他、位置情報変換部４０２が設けられている。位置情報変換部４０２は、緯度経度、建物等の名称、住所、マップコードなど位置情報の形式を相互に対応づけるデータを有しており、このデータを参照することによって位置情報の形式を相互に変換する。
位置情報変換部４０２のデータベースを携帯電話１００内に保有し、位置情報の形式を携帯電話１００自身で実行できるようにしてもよい。
【００２２】
図２は、位置ログ１２１の内容を例示する説明図である。位置ログ１２１は、位置情報管理部１２０が取得済みの位置情報を蓄積するメモリ内の領域である。ここではテーブル形式を例示したが、位置情報の格納は、種々の形式をとることができる。なお、図中の左側に示したＳ１、Ｓ２、Ｓ３は各ログの内容を示す便宜上の符号である。
位置ログ１２１には、位置情報を取得したセンサ種別つまり位置情報取得部の種別、位置情報の取得時刻、位置情報および精度などの情報が格納されている。
位置情報は、座標、建物等の名称（以下、単に「名称」と呼ぶこともある）、住所の形式で格納する例を示した。位置情報を格納する形式は、携帯電話１００に登録されているアプリケーションの種類に応じて決定される。図２の例では、登録された複数のアプリケーションから要求される種々の形式の論理和が、座標、名称、住所の３通りであることを意味している。位置情報の形式は、稼働中のアプリケーションから要求され得る形式に基づいて設定してもよいし、稼働中か否かを問わず、携帯電話１００に登録されている全アプリケーションから要求され得る形式に基づいて設定してもよい。
精度は、それぞれの位置情報の誤差範囲を距離で表したものである。この距離が短いほど、精度が高いことを意味する。
【００２３】
例えば、図２において、ログＳ１の位置情報は、基地局との通信（図１の位置情報取得部１３１［２］）によって取得された位置情報を示している。位置情報は、（ＬＡＴ１、ＬＯＮ１）という緯度経度の座標系で格納されている。名称、住所の形式では得られていない。計測精度は１ｋｍである。
ログＳ２の位置情報は、通信端末との通信（図１の位置情報取得部１３１［３］）によって取得された位置情報である。通信端末との通信では、種々の形式での位置情報が取得可能であるため、座標、名称、住所の各形式で格納されている。精度は５ｍである。
ログＳ３の位置情報は、ＧＰＳ（図１の位置情報取得部１３１［１］）によって取得された位置情報である。ＧＰＳとの通信では、座標（ＬＡＴ３、ＬＯＮ３）が取得可能であり、その精度は５０ｍである。ただし、座標形式で取得された位置情報であっても、地図サーバ４００を利用することにより、他の形式に変換可能である。図２の例では、座標形式から矢印ＴＦに示すように住所の形式に変換を行った結果も併せて格納している例を示した。ここに示した変換は一例に過ぎず、住所への変換の際に、名称への変換を同時に行うものとしてもよい。
【００２４】
＜＜ イベントによる位置情報授受の制御 ＞＞
本実施例では、位置情報管理部１２０は、イベントドリブン方式で稼働する。各アプリケーションは、「位置情報要求イベント」を生成することによって位置情報管理部１２０に位置情報を要求し、位置情報管理部１２０は「出力イベント」を生成することによってアプリケーションへの位置情報受け渡しを行う。位置情報管理部１２０は、位置情報要求イベントの有無およびその内容を常時監視するよう構成されており、位置情報要求イベントを受け取ると、それに応じて位置情報の取得等の処理を行う。また、位置情報の取得が完了すると、それに応じた出力イベントを生成する機能、および出力イベントの有無を常時監視する出力機能も有している。出力機能は、出力イベントの生成を検出すると、その内容に応じて位置情報をアプリケーションに受け渡す。
位置情報管理部１２０の動作には、他のイベントも用いられるが、これらについては、後でフローチャートに基づいて位置情報管理部１２０の動作を説明する際に必要に応じて説明する。
【００２５】
図３は、位置情報要求イベント、出力イベントの内容を示す説明図である。図の上方に位置情報要求イベントＥＶ０１、ＥＶ０２、ＥＶ０３を示し、下方に出力イベントＯＰ０１、ＯＰ０２、ＯＰ０３を示した。３つずつのイベントを例示しているが、位置情報要求イベントＥＶ０１〜ＥＶ０３と、出力イベントＯＰ０１〜ＯＰ０３がそれぞれ対応している訳ではない。
位置情報要求イベントＥＶ０１は、アプリケーションによって生成されるものであり、次に示す各情報を格納している。
「発生時刻」は位置情報要求イベントＥＶ０１が生成された時刻である。
「要求元」は、当該イベントを生成したアプリケーションの名称である。図の例では、「アプリＡ」という名称のアプリケーションによって位置情報要求イベントＥＶ０１が生成されたことを表している。
「精度」は、アプリケーションが位置情報の誤差範囲について求める精度仕様である。図の例では、誤差範囲が１０ｍ以下の精度で位置情報を求めていることを表している。
「形式」はアプリケーションが位置情報の表現形式について求める形式仕様である。図の例では、緯度経度などの座標で位置情報を求めていることを表している。座標について緯度経度の他、Ｘ−Ｙ座標系など複数種類の座標系を取扱可能である場合には、「緯度経度」など更に詳細な形式で指定可能としてもよい。
「要求時間」はアプリケーションが位置情報を受け取るまでの待ち時間の許容値である。図の例では、「００：０１：３５」であるから、あと１分３５秒が経過するまでの間に位置情報の受け取りを求めていることを表している。本実施例では、要求時間は時々刻々変化するものとした。つまり、現在時刻から受け渡しが行われるまでの許容時間を表している。これに対し、要求時間には、要求イベントが生成されてから受け渡しが行われるまでの許容時間を固定値で設定するようにしてもよい。
「繰り返し」は位置情報要求イベントの生成を自動的に繰り返すか否かを指定する。図の例では、「無し」と指定されているため、位置情報要求イベントＥＶ０１に基づいて位置情報が生成されると、当該イベントは消去される。これに対し、「有り」で指定されている場合には、位置情報要求イベントＥＶ０１に基づいて位置情報が生成されると、一旦は、当該イベントが消去されるものの、同時に、同じ内容の新たな位置情報要求イベントＥＶ０１が生成される。こうすることによって、例えば、ナビゲーションのように、繰り返し現在位置を検出する必要があるアプリケーションの場合、毎回、位置情報要求イベントを生成する負荷から軽減される。
「出力条件」は位置情報を出力するための条件を指定する。指定される例としては、アプリケーションが、所定の位置に到達した時に位置情報の受け渡しを求める場合があげられる。ナビゲーションのアプリケーションにおいて目的地（所定の緯度経度）に到着したら位置情報の受け渡しを求める場合や、時刻表を表示するアプリケーションにおいて、所定の駅（名称または座標）に到着したら位置情報の受け渡しを求める場合などである。国盗りゲームにおいて、以前に訪れたことがない地名または領域に到着したら位置情報の取得を求める場合にも用いることができる。出力条件は、このように位置に基づく条件の他、所定の時刻になった時に位置情報の受け渡しを求める態様で用いても良い。かかる条件は、タクシーなどの運行管理を行うアプリケーションが、所定時刻ごとに位置を記録する場合などに利用可能である。
「出力先」は、位置情報を受け渡すべきアプリケーションを表している。図の例では、「アプリＡ」に位置情報を受け渡すことになる。通常は、位置情報要求イベントを生成したアプリケーションと、位置情報を受け渡すべきアプリケーションは同一であることが多いため、「要求元」と「出力先」は共通としてもよい。ただし、図３の例のように両者を分けておくと、例えば、スケジュール帳のアプリケーションがスケジュールに従って、現在位置や次の目的地の位置情報取得要求イベントを生成するとともに、ナビゲーションのアプリケーションを出力先と指定することによって、現在位置から目的地までの経路案内を開始させるという態様で利用することもできる。
「位置情報」は、取得された位置情報自体を表している。「位置情報」は、位置情報要求イベントの生成時には、当然にブランクであり、位置情報が取得されると値が設定される。従って、「位置情報」は位置情報を出力するたえの「出力イベント」を生成するか否かの判断基準として用いることができる。
【００２６】
図の下方の出力イベントについて説明する。出力イベントは、位置情報要求イベントに指定された精度、形式、出力条件などのアプリケーション仕様に合致した位置情報が取得されると、位置情報管理部１２０によって生成されるものであり、次に示す各情報を格納している。
「発生時刻」は出力イベントが生成された時刻である。
「出力先」は位置情報要求イベントの出力先に対応する情報であり、出力イベントに格納された位置情報を受け渡すべきアプリケーションを指定する。
「形式」は位置情報の表現形式を表し、「位置情報」は該形式で取得された位置情報を表す。
【００２７】
図３に示した位置情報要求イベントおよび出力イベントの内容は例示に過ぎず、図示した情報の一部のみを備えるようにしてもよいし、更に、この他の情報を格納するようにしてもよい。
また、全ての位置情報要求イベント、出力イベントにおいて、格納すべき情報を統一しておく必要もない。例えば、図３の位置情報要求イベントＥＶ０１において、「出力条件」の指定がない場合には、この項目自体を削除した形でイベントを生成するようにしてもよい。
【００２８】
＜＜ 位置情報管理処理 ＞＞
図４は、位置情報管理処理のフローチャートである。位置情報管理部１２０が実行する処理であり、ハードウェア的には、携帯電話１００のＣＰＵが実行する処理である。この例では、説明の便宜上、一連の処理をフローチャートとして示したが、実際には、位置情報管理部１２０はイベントドリブンで稼働しているため、フローチャート中に示す種々の処理をイベントに基づいて独立に処理するサブプログラムの集合体として構成されている。
処理を開始すると、携帯電話１００は位置情報更新イベントの有無を確認する（ステップＳ１０）。先に説明した通り、携帯電話１００には複数種類の位置情報取得部１３１が備えられている。この中には、基地局との通信による位置情報取得部１３１［２］や、通信端末との通信による位置情報取得部１３１［３］のように、アプリケーションからの位置情報の取得要求の有無を問わず、所定のタイミングで位置情報を取得するものがある。このようなセンサを、自律的位置情報取得部と称するものとする。自律的位置情報取得部が位置情報を取得するタイミングは、それぞれの構成に応じて決まっている。例えば、位置情報取得部１３１［２］のように一定の時間経過ごととしてもよいし、位置情報取得部１３１［３］のように通信端末との通信が行われたタイミングとしてもよい。この他、位置情報取得部の構成によっては、携帯電話１００で位置情報取得要求以外の所定の操作を行ったタイミングとしてもよいし、以上で述べた種々のタイミングの組合せとしてもよい。
位置情報更新イベントとは、これらの自律的位置情報取得部による位置情報の取得が行われた時に生成されるイベントである。位置情報の取得時刻、位置情報を生成した自律的位置情報取得部を特定する情報、取得された位置情報の形式、位置情報、精度などを格納することができる。このように自律的位置情報取得部が位置情報更新イベントを生成することにより、位置情報管理部１２０が、自律的位置情報取得部に対して位置情報の取得を行ったか否かを常時監視する必要がなくなる利点がある。
位置情報更新イベントが生成されている場合、携帯電話１００は、位置情報テーブルを更新する(ステップＳ１２)。位置情報テーブルとは、位置ログ１２１に格納されているテーブル（図２参照）である。つまり、携帯電話１００は、ステップＳ１２の処理では、図２の各ログに位置情報更新イベントに格納されたセンサ種別、取得時刻、位置情報、精度などを格納して、ログを追加する。
次に、携帯電話１００は出力イベント生成処理を実行する（ステップＳ１４）。出力イベント生成処理は、図３で説明した通り、位置情報要求イベントのアプリケーション仕様に合致した位置情報が取得された場合に、その取得結果に基づいて生成されるイベントである。自律的位置情報取得部によって位置情報が取得されたことを受けて、いずれかの位置情報要求イベントのアプリケーション仕様に合致している可能性が生じるため、可能であれば出力イベントを生成するのである。詳細な処理内容については、後述する。
【００２９】
携帯電話１００は、これらの処理が完了すると、次に、位置情報要求イベントの要求時間を更新する（ステップＳ１６）。位置情報更新イベントが生成されていない場合（ステップＳ１０）も同様に、ステップＳ１６の処理を行う。
図３で説明した通り、本実施例では、現在時刻から位置情報の受け渡しが行われるまでの許容時間を、「要求時間」として位置情報要求イベントに格納している。従って、この「要求時間」は時々刻々と減少していく数値である。そこで、携帯電話１００は、位置情報管理処理を実行するたびに、経過時間分だけ、それぞれの位置情報要求イベントの「要求時間」から減じることによって、要求時間を更新するのである。
【００３０】
更新の結果、要求時間が０よりも小さくなる位置情報要求イベントがある場合（ステップＳ１８）、携帯電話１００は、位置情報取得処理（ステップＳ２０）、および出力イベント生成処理（ステップＳ２２）を行う。位置情報取得処理(ステップＳ２０)は、位置情報取得部１３１を用いて位置情報を得るための処理である。要求時間が０より小さいということは、その位置情報要求イベントに対しては、ただちに位置情報の受け渡しを行う必要があることを意味している。従って、携帯電話１００は、自律的位置情報取得部による位置情報の更新（ステップＳ１２）を待つのではなく、位置情報取得部１３１を積極的に活用して位置情報を取得するのである。出力イベント生成処理（ステップＳ２２）は、ステップＳ１４と同じ処理であり、取得された位置情報に基づいて出力イベント（図３参照）を生成する処理である。
位置情報取得処理（ステップＳ２０）、出力イベント生成処理（ステップＳ２２）の内容は後述する。
【００３１】
以上の処理が完了すると、携帯電話１００は、位置情報を出力し、出力イベントを更新する（ステップＳ２４）。位置情報は出力イベントが生成されている場合に、その内容を出力イベントで指定されたアプリケーションに受け渡す処理である。ステップＳ１４、Ｓ２２のいずれにおいても出力イベントが生成されていない場合には、位置情報の出力は行われない。
出力イベントの更新とは、位置情報の受け渡しが完了した出力イベントを消去する処理である。本実施例では、消去するものとしたが、無効化した上で位置情報の受け渡しの履歴として保存しておいてもよい。
携帯電話１００は、以上の処理を繰り返し実行することによって、位置情報取得部１３１を利用して位置情報を取得し、アプリケーションに受け渡すことができる。
【００３２】
＜＜ 出力イベント生成処理 ＞＞
次に、上述のステップＳ１４，Ｓ２２の出力イベント生成処理についてそれぞれ説明する。
図５は、出力イベント生成処理のフローチャートである。位置情報要求イベントに合致する位置情報を位置情報テーブルから抽出し、出力イベントを生成する処理である。本実施例では、自律的位置情報取得部によって取得された位置情報（図４のステップＳ１２）、および位置情報取得処理によって取得された位置情報（図４のステップＳ２０）は、それぞれ位置ログ１２１に保持されている位置情報テーブルに格納される。従って、出力イベントを生成するためには、改めて位置情報を取得する必要性を考慮することなく、単に、この位置情報テーブルを参照するだけで済むのである。
【００３３】
出力イベント生成処理を開始すると、携帯電話１００は、位置情報テーブルの精度を補正する（ステップＳ１００）。携帯端末は、所有者の移動に伴って時間とともに移動する場合があり、位置情報の取得後の経過時間に応じて精度は低下していくことがあるからである。本実施例では、図中に示す通り、取得後の経過時間に応じて設定された補正係数を、取得時点での精度に乗じることによって補正精度を得る。補正係数は、位置情報取得部ごとに設定されている。例えば、通信端末を利用した位置情報取得部は、精度が非常に高いため（図２）、わずかな時間経過でも、精度に及ぼす影響が大きい。従って、比較的、急激に補正係数が増大する、つまり精度が低下する曲線となっている。これに対し、取得時の精度が低い基地局については、比較的緩やかに補正係数が増大する曲線となっている。
補正係数は、携帯電話１００の平均的な移動速度を考慮して設定することができる。これに対し、移動速度に応じて、複数の補正曲線を用意しておいてもよい。例えば、図中のＧＰＳ［１］、ＧＰＳ［２］で表した補正曲線は、いずれもＧＰＳによる位置情報に対応するものである。ＧＰＳ［１］は移動速度が速い場合、ＧＰＳ［２］は移動速度が遅い場合を表している。ここでは、２本だけを例示したが、さらに多くの曲線を設定しておいてもよい。
精度補正の算出方法は、このように補正係数を用いる方法に限らない。例えば、位置情報の履歴を参照して、携帯電話１００の移動速度を推定し、取得時から現時点までの移動距離を推定して、取得時の誤差精度に加える方法をとってもよい。取得時から現時点までの移動距離が１００ｍと推定される場合には、取得時の精度に対して１００ｍを加えた値を補正精度とするのである。この他、種々の方法で補正精度を求めることが可能である。
【００３４】
補正精度を求めると、携帯電話１００は、位置情報管理部１２０に保持されている位置情報要求イベントの中から処理対象となるべき位置情報要求イベントを抽出する（ステップＳ１０２）。そして、抽出した位置情報要求イベントにおける位置情報に対するアプリケーション仕様、つまり位置情報の形式、精度、出力条件が合致する位置情報を、位置情報テーブルから検索する(ステップＳ１０４)。図３に示した位置情報要求イベントＥＶ０１の場合、出力条件は設定されていないから、位置情報の形式が「座標」であり、精度が「１０ｍ」以下である位置情報を検索することになる。
このようにアプリケーション仕様に合致する位置情報が存在しない場合（図５のステップＳ１０４）、携帯電話１００は、次の位置情報要求イベントを抽出する（ステップＳ１０２）。
一方、アプリケーション仕様に合致する位置情報がある場合（ステップＳ１０４）、携帯電話１００は、この位置情報を用いて出力イベントを生成する（ステップＳ１０６）。ここで、アプリケーション仕様に合致する位置情報が複数検索された場合には、精度が高い方を採用する。他の条件で採否を決定しても構わない。
【００３５】
出力イベントを生成した後（ステップＳ１０６）、位置情報要求イベントが「繰り返し」イベントである場合、つまり「繰り返し」に「有り」と設定されたイベントである場合（ステップＳ１０８）、携帯電話１００は、位置情報要求イベントを再生成する（ステップＳ１１０）。こうすることで、アプリケーションが繰り返し位置情報要求イベントを生成するまでなく、比較的容易に、位置情報を繰り返し取得することが可能となる。
一方、「繰り返し」イベントでない場合には（ステップＳ１０８）、位置情報要求イベントを消去する（ステップＳ１１２）。
以上の処理を携帯電話１００は、全ての位置情報要求イベントに対する処理が終了するまで（ステップＳ１１４）、繰り返し実行する。なお、この処理において、ステップＳ１１０で再生成された位置情報要求イベントは、従前から保持されている位置情報要求イベントと区別しておく必要がある。区別しておかないと、「繰り返し」イベントが含まれている場合には、出力イベントを生成した途端に、新たな位置情報要求イベントが生成され、無限に処理が続いてしまうからである。
こうして生成された出力イベントは、位置情報管理処理（図４）の位置情報出力（ステップＳ２４）においてアプリケーションに受け渡される。
【００３６】
＜＜ 位置情報取得処理 ＞＞
次に、位置情報管理処理（図４）のステップＳ２０における位置情報取得処理について説明する。この処理は、位置情報要求イベントに合致する位置情報が取得されないまま、「要求時間」（図３参照）が経過した場合に、位置情報取得部１３１を積極的に活用して位置情報を取得するための処理である。本実施例では、以下に説明する通り、位置情報取得部１３１の中から、位置情報要求イベントにおける位置情報のアプリケーション仕様に合致し、かつ、携帯電話１００の消費電力が最小となるものを選択して、位置情報を取得するようにした。
【００３７】
図６は、位置情報取得手段の選択方法を示す説明図である。位置情報取得部を選択するために、携帯電話１００は、まず位置情報要求イベントごとに、その仕様に合致する位置情報を取得するための方法を列挙する。図６は、位置情報の取得方法を列挙した結果を示したものである。以下では、図６のテーブルを「消費電力テーブル」と呼ぶ。図６では、取得方法を列挙した結果をテーブル形式で示しているが、実際の処理においては、これらの情報が列挙されていれば足り、必ずしもテーブル形式で整理する必要はない。
図６では、位置情報要求イベントＥＶ１１、ＥＶ１２の２つが処理対象となる例を示した。位置情報要求イベントＥＶ１１は住所の形式で位置情報が要求されているものとする。
第１の取得方法として、「変換」、つまり位置情報テーブルに取得されている座標（ＬＡＴ１１，ＬＯＮ１１）を矢印Ａ１１のように変換する方法が挙げられる。この時の消費電力をＷ０１とする。これはインターネットＩＮＴ上の位置情報変換部４０２にアクセスするために要する電力である。
第２の取得手段としては、同様に「変換」、つまり取得済みの名称「○○駅」という位置情報を、矢印Ａ１２のように変換する方法である。この場合の消費電力もインターネットＩＮＴ上の位置情報変換部４０２にアクセスするために要する電力でありＷ０１である。
第３の取得手段としては、通信端末を利用して、住所の形式で位置情報Ｄ１を取得する方法である。この場合の消費電力をＷ０２とする。
【００３８】
携帯電話１００は、位置情報要求イベントＥＶ１２についても、同様に位置情報の取得方法を列挙する。位置情報要求イベントＥＶ１２は、「名称」の形式で位置情報が要求されているものとする。
第１の取得方法として、「変換」、つまり位置情報テーブルに取得されている座標（ＬＡＴ１１，ＬＯＮ１１）を矢印Ａ１３のように変換する方法が挙げられる。この場合の消費電力もインターネットＩＮＴ上の位置情報変換部４０２にアクセスするために要する電力でありＷ０１である。
第２の取得手段としては、通信端末を利用して、名称の形式で位置情報Ｄ２を取得する方法である。この場合の消費電力はＷ０２となる。
第３の取得手段としては、「ＧＰＳ＋変換」、つまりＧＰＳによって座標Ｄ３を取得した後、矢印Ａ１４のように「名称」の形式に変換する方法である。この場合の消費電力をＷ０３とする。この電力は、ＧＰＳによって座標を取得するための電力と、位置情報変換部４０２にアクセスして形式を変換するための消費電力（Ｗ０１に相当する）の和である。
【００３９】
携帯電話１００は、このように位置情報要求イベントごとに、仕様に合致する位置情報の取得方法を列挙すると、この中から消費電力が最小となるものを選択する。この選択を実現するための評価方法は、種々の考え方に基づいて設定することができる。
第１の方法は、単純な総和で求める方法である。つまり、位置情報要求イベントＥＶ１１の中から電力最小となる方法を選択し、位置情報要求イベントＥＶ１２の中から電力最小となる方法を個別に選択するのである。選択結果によっては２通りの方法で位置情報を取得する必要が生じるが、選択のための処理が簡易であるため、種々の状況に汎用的に利用することが可能となる利点がある。
第２の方法は、要求時間が０となっている位置情報要求イベントを優先的に選択する方法である。例えば、図６において、「位置情報要求イベントＥＶ１１の要求時間＝０、位置情報要求イベントＥＶ１２の要求時間＞０」という状態であったとすると、位置情報要求イベントＥＶ１１の中から電力最小の方法を選択する。この選択された方法で得られた位置情報が、位置情報要求イベントＥＶ１２の仕様にも合致する場合には、位置情報要求イベントＥＶ１２についても出力イベントが生成されることになるし、仕様に合致しない場合には、位置情報要求イベントＥＶ１２は、未処理のまま残されることになる。
第３の方法は、全ての位置情報要求イベントを総合的に考慮する方法である。図６の例では、位置情報要求イベントＥＶ１１、ＥＶ１２を個別に扱っているが、この段階で、両者の仕様に合致する位置情報を取得するための方法を列挙するのである。つまり、位置情報要求イベントＥＶ１１の「住所」と、位置情報要求イベントＥＶ１２の「名称」の双方の形式で位置情報を得るための方法を列挙する。この場合、第１の方法として、既に取得済みの座標（ＬＡＴ１１、ＬＯＮ１１）を矢印Ａ１１、Ａ１３のように変換する方法が挙げられる。いずれも同一の位置情報変換部４０２にアクセスすれば足りるから、消費電力はＷ０１である。第２の方法として、取得済みの名称「○○駅」を矢印Ａ１２のように変換する方法が挙げられる。この場合も消費電力はＷ０１である。このように、名称、住所の双方で位置情報が得られる方法を列挙した上で、その消費電力が最小となる方法を選択すればよい。第３の方法によれば、全ての位置情報要求イベントの仕様に合致する位置情報を最小の消費電力で得ることができる。
このように消費電力が最小となる方法の選択には、種々の評価方法を適用することができる。上述の３通り以外の方法を適用してもよい。また、評価方法１で位置情報の取得方法が決まらない場合には、評価方法２を適用するという具合に、複数の評価方法を段階的に用いても良い。
【００４０】
図７は、位置情報取得処理のフローチャートである。図６で説明した考え方に基づき、位置情報取得部を選択して、位置情報を取得するための処理である。
携帯電話１００は、まず処理対象となる位置情報要求イベントを抽出する（ステップＳ２００）。そして、位置情報テーブルから取得済みの位置情報を検索し、消費電力テーブル（図６）に追加する（ステップＳ２０２）。この際、補正精度が位置情報要求イベントにおける精度の仕様を満たすこと、および要求された形式に変換可能であることを検索条件とする（ステップＳ２０２）。位置情報要求イベントにおいて「出力条件」が設定されている場合には、更に、この出力条件を満たすことも条件に加える必要がある。
【００４１】
次に、携帯電話１００は、利用可能な取得方法を消費電力テーブル（図６）に追加する（ステップＳ２０４）。図６の位置情報要求イベントＥＶ１１に対する「通信端末」や、位置情報要求イベントＥＶ１２に対する「通信端末」、「ＧＰＳ＋変換」が、ステップＳ２０４で追加された方法に相当する。
取得可能な方法の選択は、図中の右側に示したテーブルを参照することにより可能である。このテーブルは、縦に位置情報取得部、横に位置情報の形式をとり、それぞれの形式の位置情報を、各位置情報取得部で直接「取得」することができるか、形式の「変換」が必要かを表したものである。例えば、「基地局」および「ＧＰＳ」を利用すると、「座標」は直接取得可能であるが、「名称」「住所」は取得後に変換が必要になることが分かる。「通信端末」を利用すれば、いずれの形式も直接に「取得」できることが分かる。
ステップＳ２０４では、位置情報要求イベントにおける「精度」仕様に合致する位置情報取得部を選択し、その上で図中のテーブルを参照して、「形式」仕様に合致する位置情報を得るために「変換」が必要か否かを判断すればよい。こうして「精度」「形式」仕様を満足する位置情報取得部が存在すれば、消費電力テーブルに追加することができる。
【００４２】
消費電力テーブルを生成すると、携帯電話１００は、総消費電力が最小となる方法で位置情報を取得し、位置情報テーブルを更新する（ステップＳ２０６）。位置情報を取得する方法の選択については、図６で説明した通りである。この処理によって位置情報テーブルを更新することにより、位置情報管理処理の出力イベント生成処理（図４のステップＳ２２）によって出力イベントが生成されるようになる。
【００４３】
以上で説明した実施例１の携帯電話１００によれば、位置情報管理部１２０が、位置情報の仕様および位置情報取得に要する消費電力を考慮して、位置情報をアプリケーションに受け渡すことができる。従って、各アプリケーションの仕様に合致した位置情報を、電力の消費を抑えて効率的に受け渡すことが可能となる。
【実施例２】
【００４４】
本発明の実施例２における携帯電話１００について説明する。システム構成は実施例１と同様である（図１〜３参照）。実施例２では、位置ログ１２１に記憶されている位置情報テーブル（図２）に、全ての形式で位置情報を蓄えておく点で実施例１と相違する。位置情報の形式は、座標、名称、住所に限られず、携帯電話１００に登録されているアプリケーション、または稼働中のアプリケーションに応じて決めることができる。
このように各形式で位置情報を取得するため、実施例２では、位置情報管理処理（図４）および位置情報取得処理（図７）が実施例１と相違する。
【００４５】
図８は、第２実施例における位置情報管理処理のフローチャートである。処理を開始すると、携帯電話１００は、位置情報として要求される形式を、登録されているアプリケーションに基づき特定する（ステップＳ０８）。稼働中のアプリケーションに基づいて特定してもよい。
図中には、アプリ１は「座標」、アプリ２は「名称」「住所」、アプリ３は「住所」を要求している例を示した。この状態であれば、これらの論理和により、要求される形式として、「座標」「名称」「住所」が特定されることになる。
【００４６】
次に、実施例１と同様、携帯電話１００は、位置情報更新イベントの有無を確認する（ステップＳ１０）。位置情報更新イベントが有る場合には、その位置情報更新イベントに基づいて位置情報を取得し（ステップＳ１２ａ）、他形式への変換を行う（ステップＳ１２ｂ）。例えば、ＧＰＳで「座標」が取得されている場合には、位置情報変換部４０２にアクセスして、「名称」「住所」の情報を取得するのである。「通信端末」を用いた場合のように、全形式で位置情報が取得されている場合は、変換は不要である。
携帯電話１００は、こうして得られた位置情報により、位置情報テーブルを更新する（ステップＳ１２ｃ）。実施例２では、ステップＳ０８で特定された全形式で位置情報が得られているから、位置情報テーブル（図２）の全ての欄に値が格納されることになる。
その後、携帯電話１００は、出力イベント生成処理を行う（ステップＳ１４）。この処理の内容は実施例１と同様である（図６参照）。
一方、位置情報更新イベントが無い場合は（ステップＳ１０）、これらの処理をスキップする点も実施例１と同様である。
【００４７】
図９は、第２実施例における位置情報取得処理のフローチャートである。位置情報テーブルに、全形式で位置情報が格納されているため、位置情報テーブルにおいて「精度」および「出力条件」のアプリケーション仕様に合致する位置情報が存在すれば、出力イベント生成処理で処理されているはずである。つまり、位置情報取得処理では、取得済みの位置情報の「変換」を考慮する必要がなく、新たに位置情報を取得することだけを考慮すれば足りる点が実施例１と相違する。
携帯電話１００は、位置情報取得処理を開始すると、処理対象となる位置情報要求イベントを抽出する（ステップＳ２００）。そして、利用可能な取得方法を消費電力テーブルに追加する（ステップＳ２０４Ａ）。実施例２では、全ての形式で位置情報を取得するものとしているから、消費電力も、これに要する消費電力を算出する。例えば、ＧＰＳを利用する場合には、ＧＰＳによって位置情報を取得するための消費電力と、それで得られた座標を、名称、住所に変換するための消費電力との和が、消費電力テーブルに格納されることになる。
携帯電話１００は、こうして消費電力テーブルを生成すると、この中から総消費電力が最小となる方法を選択し、位置情報を取得して、位置情報テーブルを更新する（ステップＳ２０６）。この処理は、実施例１と同様である。
実施例２によれば、常に全ての形式で位置情報を取得するため、取得済みの位置情報を容易に有効活用することができる。
【００４８】
以上で説明した各実施例のシステムによれば、携帯電話１００は位置情報を利用する種々のアプリケーションに対して、消費電力を抑制しつつ、効率的に位置情報を受け渡すことが可能となる。
実施例では、特定の位置情報取得部や位置情報の形式を対象として説明したが、本実施例は、これらに限定されず、種々の位置情報取得部、位置情報の形式に対して適用可能である。また、実施例では、イベントドリブン方式での処理方法を例示したが、ソフトウェアのプログラミングも種々の方法で行うことが可能である。
【産業上の利用可能性】
【００４９】
本発明は，携帯端末における位置情報の取得および管理に利用可能である。
【符号の説明】
【００５０】
１００…携帯電話
１０２…アンテナ
１１１…アプリケーション保存部
１２０…位置情報管理部
１２１…位置ログ
１３１…位置情報取得部
２００…基地局
２０２…位置情報送信部
３００…レジ
３０２…位置情報送信部
４００…地図サーバ
４０２…位置情報変換部
【技術分野】
【０００１】
本発明は，位置情報の取得機能を有する携帯端末に関し、詳しくは携帯端末にインストールされた種々のアプリケーションからの要求に適合した位置情報を取得、提供する技術に関する。
【背景技術】
【０００２】
携帯電話その他の携帯端末は、近年、種々のアプリケーションをインストールして稼働することができる。中には、次に示すように、位置情報を利用するアプリケーションもある。例えば、現在位置を地図上で表示する位置探知、地図に目的地までの経路を案内するナビゲーション、現在位置を住所、建物等の名称などの文字情報で提供する地点案内、現在位置に近いレストランなどを案内する周辺情報提供、携帯端末を所持して予め設定された複数の地域を全て訪問することを目的とするゲーム（以下、「国盗りゲーム」という）などである。
このように位置情報を利用するアプリケーションが複数稼働している場合、従来は、各アプリケーションが個別に位置情報を取得していたため、非効率であった。かかる点の解決を図った先行技術としては、次の文献が挙げられる。
【０００３】
特許文献１は、携帯端末において、あるアプリケーションから位置情報が要求された場合、直近の測位結果を参照し、その測位結果よりも低い精度で位置情報が要求されている場合や、直近の測位から比較的短時間しか経過していないような場合には、改めて位置情報の測位を行うのではなく、取得済みの測位結果を活用する技術を開示する。
特許文献２は、ＧＰＳ（Global Positioning System）で測位した位置情報を、ネットワーク上のサーバに送信し、携帯端末よりも処理能力の高いサーバを利用することによって精度向上を図る技術を開示する。
特許文献３は、ロケーションマネージャなる概念を開示する。インストールされた各アプリケーションは、個別にＧＰＳ等を用いて位置情報を取得するのではなく、ロケーションマネージャに位置情報を要求するのである。ロケーションマネージャが、位置情報を取得する機能を一元的に管理することにより、アプリケーションとの間で効率的な位置情報の授受が可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１０１７８５号公報
【特許文献２】特開２００６−６４４６０号公報
【特許文献３】特開２００６−１５３８６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
位置情報を要求するアプリケーションの種類は多様であり、各アプリケーションが要求する位置情報の形式も多様である。ナビゲーションのように位置情報を座標形式で取得し、地図上に現在位置として表示するアプリケーションもあれば、国盗りゲームのように、特定の地域に訪れたか否かが確認できれば足り、位置情報が行政界などの住所や建物等の名称で取得できればよいアプリケーションもある。
従来技術では、アプリケーションによる位置情報の形式の相違は考慮されていなかった。従って、あるアプリケーションからの要求によって座標形式で位置情報が取得されている場合でも、他のアプリケーションから住所形式で位置情報が要求されれば、改めて位置情報を取得する必要があった。
このように座標形式が異なるだけで改めて位置情報を取得するのは、処理時間の面でも、携帯端末の消費電力の面でも非効率的であった。本発明は、かかる課題を解決し、携帯端末において、種々の形式での位置情報の取得の効率化を図ることを目的とする。
【課題を解決するための手段】
【０００６】
本発明は、位置情報を利用したアプリケーションを稼働可能な携帯端末として構成することができる。本発明の携帯端末は、アプリケーションを保存するアプリケーション保存部、携帯端末の位置情報を取得する複数種類の位置情報取得部、および位置情報管理部を備える。位置情報管理部は、位置情報取得部による位置情報の取得および取得された位置情報の管理を行い、この位置情報をアプリケーションに対して受け渡す。管理とは、位置情報取得部を利用した位置情報取得の制御、取得された位置情報の記憶、データ変換、削除、アプリケーションへの受け渡しなどの処理を含む。
位置情報取得部は、複数種類備えられている。位置情報取得部としては、例えば、ＧＰＳ、ジャイロや地磁気センサを利用したもの、携帯端末と基地局との通信を利用するもの、いわゆる電子マネーや駅の改札口など基地局以外の通信端末と携帯端末との通信を利用するもの、無線ＬＡＮ（Local Area Network）の基地局との通信を利用するもの、ＲＦＩＤタグと呼ばれる通信施設との通信を利用するもの、マップマッチングなど種々の態様で構成することができる。取得できる位置情報の表現形式は、例えば、緯度経度などの座標系、住所、建物や路線などの名称、マップコードなど種々の形式をとることができ、位置情報取得部ごとに異なっている。一つの位置情報取得部で複数の形式で位置情報の取得が可能なものが含まれていても良い。また、ネットワーク上の特定のサーバにアクセスして、取得された位置情報の表現形式を他の形式に変換する機能を奏する部分を位置情報取得部の一つとして構成することもできる。位置情報取得部の種類とは、位置情報の取得方法、表現形式に基づいて考えることができ、例えば、通信端末を利用した位置情報取得部を複数備えている場合であっても、それぞれの通信端末で取得し得る位置情報の形式が異なるのであれば、複数種類の位置情報取得部を搭載していると言うことができる。
【０００７】
本発明の位置情報管理部は、次の機能を実現する。
位置情報を取得した場合、その位置情報が、予め設定された複数の形式のうち一部の形式のみで取得されている場合には、不足する形式に位置情報を変換する。
例えば、該携帯端末で利用する位置情報の形式として、座標、名称、住所の３形式が設定されている場合、座標形式でのみ位置情報が取得されているときは、名称、住所の形式が不足するから、座標から、名称、住所に変換するのである。
位置情報の変換は種々の方法をとることができる。例えば、携帯端末内に変換に要するデータベースを蓄積しておく方法をとってもよい。また、ネットワーク上のサーバにアクセスして形式の変換を行うようにしてもよい。
位置情報管理部は、こうして得られた複数の形式で位置情報を記憶している。取得した位置情報が複数の形式を満たす場合には、上述した変換を行うまでなく、これらの形式で位置情報を記憶すればよい。
アプリケーションから位置情報を要求されたときには、位置情報管理部は、記憶されている位置情報を優先的に用いて、位置情報を受け渡す。
【０００８】
本発明の携帯端末によれば、位置情報管理部が、上述の通り、複数の形式で位置情報を記憶しておくことにより、複数のアプリケーションから異なる形式で位置情報が要求された場合でも、既に取得済みの位置情報を有効活用することが可能となる。この結果、位置情報を取得する頻度を抑制でき、位置情報の受け渡しの効率化、および位置情報取得に伴う消費電力の抑制を図ることができる。
【０００９】
上述した複数の形式は、携帯端末で稼働するアプリケーションの種類とは無関係に広汎に設定しておくことも可能であるが、アプリケーションに基づいて設定することが好ましい。
例えば、位置情報管理部が、アプリケーションについて、位置情報の形式に関する仕様（以下、「形式仕様」ということもある）を記憶しておき、複数のアプリケーションの形式仕様に対応する形式の論理和によって、複数の形式を設定する方法をとることができる。携帯端末に登録されている第１のアプリケーションの形式仕様が座標、第２のアプリケーションの形式仕様が座標または名称である場合には、双方の論理和をとり、座標と名称の２つの形式を、位置情報取得および変換の際に対象とする複数の形式として設定するのである。このようにアプリケーションの形式仕様に基づいて形式を設定しておけば、利用される可能性のない形式での位置情報取得を抑制することができ、位置情報取得の処理負荷および消費電力の更なる軽減を図ることができる。
上述のようにアプリケーションに基づいて位置情報を取得すべき形式を設定する場合、アプリケーション保存部に保存されている全アプリケーションを対象として設定してもよい。また、現実に稼働しているアプリケーションのみを対象として設定してもよい。後者の態様によれば、新たなアプリケーションが起動した直後は、該アプリケーションに対応する形式での取得済みの位置情報が存在しないといった支障が生じるおそれがあるものの、取得対象とする形式をより絞り込むことができる点で効率化を図ることができる。
【００１０】
本発明においては、アプリケーションは位置情報の精度に関する仕様（以下、「精度仕様」ということもあり、形式仕様と精度仕様を「アプリケーション仕様」と総称することもある。）も設定可能としてもよい。精度仕様は、位置情報の許容誤差をメートル等の長さ、市町村などの行政界などの形式で表したものであり、アプリケーションによって異なる。
精度仕様が設定されている場合、位置情報管理部は、精度仕様を満たす位置情報を受け渡す。この場合、位置情報管理部は、取得済みの位置情報の精度を、取得後の経過時間に基づいて補正した上で、仕様に適合するか否かを判断するようにしてもよい。携帯端末は所有者の移動に伴って時間とともに移動する場合があり、位置情報の精度は取得後の時間経過に伴って劣化する傾向にある。このように経過時間を考慮して精度を補正することにより、アプリケーションの要求する精度に合致した位置情報を受け渡すことができる。
位置情報の精度補正は、種々の方法をとることができる。例えば、経過時間によって定まる補正係数を予め設定しておき、これを位置精度に乗じる方法をとってもよい。位置情報を繰り返し取得している場合には、過去の位置情報の履歴から携帯端末の移動速度を推定し、移動速度に応じた補正係数を設定するようにしてもよい。取得後の経過時間が所定値以上となった場合には、その位置情報は利用不能と考え、位置情報の精度が極端に悪化するような補正係数を設定してもよい。
また、補正係数は、位置情報取得部に応じて異なる設定としてもよい。取得時の位置情報の精度が高い場合には、精度が低い場合に比べて、携帯端末のわずかな移動でも精度に与える影響は大きいと考えられるからである。
位置情報管理部は、精度の仕様に適合する位置情報が存在しない場合には、位置情報取得部を用いてアプリケーション仕様に適合する位置情報を取得し、アプリケーションに位置情報を受け渡す。
かかる態様により、位置情報管理部は、取得後の精度劣化も考慮した上で、アプリケーション仕様に適合した位置情報を受け渡すことが可能となる。
【００１１】
位置情報を新たに取得する場合、位置情報管理部は、位置情報の取得に要する消費電力および取得された位置情報を複数の形式に変換するために要する消費電力が最小と評価される位置情報取得部を利用して位置情報の取得を行うようにしてもよい。
こうすることにより、携帯端末の電力消費を抑制することができる。この際、位置情報の取得に要する消費電力だけでなく、他の形式への変換に要する消費電力も併せて考慮することにより、それぞれの位置情報取得部を用いる場合の消費電力を適正に評価することが可能となる。
なお、位置情報取得部の選択は、全ての位置情報取得部の中から真に消費電力が最小となるものを選択するものに限定されるものではない。消費電力を所定の評価方法で推定し、その範囲で最小と評価されるものを選択するのである。例えば、位置情報の取得に要する電力は必ずしも一定とは限らず、電波環境などによって変化することもある。そこで、予め位置情報取得部ごとに設定された電力値を用いて消費電力を評価する方法をとることができる。また、複数のアプリケーションから位置情報が要求されている場合には、各アプリケーションごとに個別に電力最小の位置情報取得部を選択してもよいし、位置情報を要求している全アプリケーションを総合的に考慮して電力最小となる位置情報取得部を選択してもよい。
【００１２】
本発明は、上述した携帯端末としての構成の他、携帯端末において位置情報を取得する位置情報取得方法として構成してもよい。この方法は、携帯端末に搭載されたコンピュータが、上述の各機能を実行することによって実現することができる。
また、本発明は，上述の位置情報取得方法を、コンピュータに実行させるためのコンピュータプログラム、または、このコンピュータプログラムを記録したコンピュータが読み取り可能な記録媒体として構成してもよい。記録媒体としては，フレキシブルディスクやＣＤ−ＲＯＭ，光磁気ディスク，ＩＣカード，ＲＯＭカートリッジ，パンチカード，バーコードなどの符号が印刷された印刷物，コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等，コンピュータが読取り可能な種々の媒体を利用できる。
【図面の簡単な説明】
【００１３】
【図１】位置情報を利用する携帯電話のシステム構成を示す説明図である。
【図２】位置ログの内容を例示する説明図である。
【図３】位置情報要求イベント、出力イベントの内容を示す説明図である。
【図４】位置情報管理処理のフローチャートである。
【図５】出力イベント生成処理のフローチャートである。
【図６】位置情報取得手段の選択方法を示す説明図である。
【図７】位置情報取得処理のフローチャートである。
【図８】第２実施例における位置情報管理処理のフローチャートである。
【図９】第２実施例における位置情報取得処理のフローチャートである。
【発明を実施するための形態】
【実施例１】
【００１４】
＜＜ システム構成 ＞＞
図１は、位置情報を利用する携帯電話のシステム構成を示す説明図である。
実施例における携帯電話１００には、図示する種々の機能ブロックが備えられている。これらの機能ブロックは、携帯電話に搭載されたＣＰＵ、ＲＡＭ、ＲＯＭなどのコンピュータによってソフトウェア的に構成されている。機能ブロックの一部または全部は、ハードウェア的に構成してもよい。
アプリケーション保存部１１１は、複数のアプリケーション１、アプリケーション２、アプリケーション３等を保存している。本実施例では、各アプリケーションは位置情報を利用するものとして説明する。位置情報を利用するアプリケーションとしては、現在位置を地図上で表示する位置探知、地図に目的地までの経路を案内するナビゲーション、現在位置を住所、建物等の名称などの文字情報で提供する地点案内、現在位置に近いレストランなどを案内する周辺情報提供、国盗りゲームなどが挙げられる。
【００１５】
携帯電話１００には、位置情報を取得するための複数の位置情報取得部１３１が備えられている。
位置情報取得部１３１［１］は、携帯電話１００に備えられたアンテナ１０２で衛星からの電波を受信して携帯電話１００の位置情報を取得するＧＰＳである。位置情報は、緯度経度の座標値の形式で得られる。
【００１６】
位置情報取得部１３１［２］は、基地局２００を利用して位置情報を取得する。携帯電話１００は、着信を受けるため基地局２００と定期的に通信している。携帯電話１００が通信する基地局は、携帯電話１００の位置に応じて異なり、基地局の位置は既知であるから、いずれの基地局と通信しているかが分かれば携帯電話１００の位置情報を得ることができる。例えば、単一の基地局２００との通信電波の強弱によって基地局からの距離を推定し、携帯電話１００の位置を算出する方法、複数の基地局２００との通信電波の強弱によっていわゆる三角測量と同じ原理で携帯電話の位置を精度良く算出する方法などが知られている。いずれにおいても、基地局２００に接続された位置情報送信部２０２で、携帯電話１００の位置情報を解析し、携帯電話１００に送信する。位置情報は緯度経度の座標形式で得られる。
【００１７】
位置情報取得部１３１［３］は、通信端末を利用して位置情報を取得する。図の例では、コンビニエンスストアに設置されているレジ３００を利用する例を示した。レジ３００には、その位置情報を緯度経度、店舗名称、住所、マップコードなど種々の形式で登録した位置情報送信部３０２が備えられている。位置情報送信部３０２は、複数のレジ３００の情報を提供するネットワーク上のサーバとして構成してもよいし、レジ３００に内蔵してもよい。レジにおいて携帯電話１００を用いて電子マネーでの支払いを行うと、レジ３００と携帯電話１００が通信する際に、位置情報送信部３０２から得られる位置情報を携帯電話１００に送信する。本実施例では、上述した種々の形式の位置情報を一括して送信するものとしたが、携帯電話１００からの要求に応じて、いずれかの位置情報のみを送信してもよい。
【００１８】
位置情報取得部１３１［１］〜１３１［３］は例示である。携帯電話１００には、この一部のみを備えるようにしてもよいし、他の種類の位置情報取得部を備えても良い。位置情報取得部としては、例えば、無線ＬＡＮの基地局との通信を利用するもの、ＲＦＩＤタグと呼ばれる通信施設との通信を利用するもの、マップマッチングを利用するものなどを備えることができる。
なお、以下の説明では、位置情報取得部を「センサ」と称することもある。
【００１９】
位置情報管理部１２０は、各アプリケーションから位置情報の取得要求を受け付け、位置情報取得部１３１を利用して位置情報を取得して、この位置情報をアプリケーションに受け渡す機能を奏する。取得した位置情報は位置ログ１２１に記憶される。このように、各アプリケーションが、直接に位置情報取得部１３１を利用して位置情報を取得するのではなく、位置情報管理部１２０から位置情報を受け取る構成とした点が本実施例の特長の一つである。こうすることにより、複数のアプリケーションが稼働している場合であっても、位置情報管理部１２０が、位置情報の取得を一元的に制御し、得られた位置情報を一元的に管理して、アプリケーションに受け渡すことが可能となるのである。
本実施例では、位置情報管理部１２０は、アプリケーションからの位置情報の取得要求を受け付けると、直ちに位置情報の取得を行うのではなく、まず位置ログ１２１に蓄積された取得済みの位置情報得を参照し、この中にアプリケーションが要求するアプリケーション仕様に合致する位置情報があれば、それを受け渡す。かかる位置情報がない場合には、位置情報管理部１２０は、複数種類の位置情報取得部１３１の中から消費電力が最小となるものを選択して、位置情報を取得する。こうすることによって、効率的に位置情報を受け渡すことが可能となるのである。
【００２０】
本実施例では、位置情報管理部１２０は、イベントドリブン方式で稼働するものとした。つまり、各アプリケーションは、位置情報を必要とする場合には、「位置情報要求イベント」と称する定型のオブジェクトまたはデータを生成し、位置情報管理部１２０に受け渡す。種々のアプリケーションが位置情報を必要とするごとに個別の位置情報要求イベントが生成されるから、位置情報管理部１２０には、複数の位置情報要求イベントが蓄積されることになる。位置情報管理部１２０は、これらの位置情報要求イベントを監視することによって、どのアプリケーションから、どのような位置情報が要求されているかを知ることができる。
一方、位置情報要求イベントに合致した位置情報が取得されると、位置情報管理部１２０は、「出力イベント」と称する定型のオブジェクトまたはデータを生成し、出力イベントを各アプリケーションに受け渡すことによって位置情報を伝達する。
位置情報要求イベントおよび出力イベントの内容は後述する。
【００２１】
携帯電話１００は、基地局２００を介してインターネットＩＮＴに接続することができ、インターネットＩＮＴ上に接続された地図サーバ４００にアクセスすることができる。地図サーバ４００には、地図データが登録されている他、位置情報変換部４０２が設けられている。位置情報変換部４０２は、緯度経度、建物等の名称、住所、マップコードなど位置情報の形式を相互に対応づけるデータを有しており、このデータを参照することによって位置情報の形式を相互に変換する。
位置情報変換部４０２のデータベースを携帯電話１００内に保有し、位置情報の形式を携帯電話１００自身で実行できるようにしてもよい。
【００２２】
図２は、位置ログ１２１の内容を例示する説明図である。位置ログ１２１は、位置情報管理部１２０が取得済みの位置情報を蓄積するメモリ内の領域である。ここではテーブル形式を例示したが、位置情報の格納は、種々の形式をとることができる。なお、図中の左側に示したＳ１、Ｓ２、Ｓ３は各ログの内容を示す便宜上の符号である。
位置ログ１２１には、位置情報を取得したセンサ種別つまり位置情報取得部の種別、位置情報の取得時刻、位置情報および精度などの情報が格納されている。
位置情報は、座標、建物等の名称（以下、単に「名称」と呼ぶこともある）、住所の形式で格納する例を示した。位置情報を格納する形式は、携帯電話１００に登録されているアプリケーションの種類に応じて決定される。図２の例では、登録された複数のアプリケーションから要求される種々の形式の論理和が、座標、名称、住所の３通りであることを意味している。位置情報の形式は、稼働中のアプリケーションから要求され得る形式に基づいて設定してもよいし、稼働中か否かを問わず、携帯電話１００に登録されている全アプリケーションから要求され得る形式に基づいて設定してもよい。
精度は、それぞれの位置情報の誤差範囲を距離で表したものである。この距離が短いほど、精度が高いことを意味する。
【００２３】
例えば、図２において、ログＳ１の位置情報は、基地局との通信（図１の位置情報取得部１３１［２］）によって取得された位置情報を示している。位置情報は、（ＬＡＴ１、ＬＯＮ１）という緯度経度の座標系で格納されている。名称、住所の形式では得られていない。計測精度は１ｋｍである。
ログＳ２の位置情報は、通信端末との通信（図１の位置情報取得部１３１［３］）によって取得された位置情報である。通信端末との通信では、種々の形式での位置情報が取得可能であるため、座標、名称、住所の各形式で格納されている。精度は５ｍである。
ログＳ３の位置情報は、ＧＰＳ（図１の位置情報取得部１３１［１］）によって取得された位置情報である。ＧＰＳとの通信では、座標（ＬＡＴ３、ＬＯＮ３）が取得可能であり、その精度は５０ｍである。ただし、座標形式で取得された位置情報であっても、地図サーバ４００を利用することにより、他の形式に変換可能である。図２の例では、座標形式から矢印ＴＦに示すように住所の形式に変換を行った結果も併せて格納している例を示した。ここに示した変換は一例に過ぎず、住所への変換の際に、名称への変換を同時に行うものとしてもよい。
【００２４】
＜＜ イベントによる位置情報授受の制御 ＞＞
本実施例では、位置情報管理部１２０は、イベントドリブン方式で稼働する。各アプリケーションは、「位置情報要求イベント」を生成することによって位置情報管理部１２０に位置情報を要求し、位置情報管理部１２０は「出力イベント」を生成することによってアプリケーションへの位置情報受け渡しを行う。位置情報管理部１２０は、位置情報要求イベントの有無およびその内容を常時監視するよう構成されており、位置情報要求イベントを受け取ると、それに応じて位置情報の取得等の処理を行う。また、位置情報の取得が完了すると、それに応じた出力イベントを生成する機能、および出力イベントの有無を常時監視する出力機能も有している。出力機能は、出力イベントの生成を検出すると、その内容に応じて位置情報をアプリケーションに受け渡す。
位置情報管理部１２０の動作には、他のイベントも用いられるが、これらについては、後でフローチャートに基づいて位置情報管理部１２０の動作を説明する際に必要に応じて説明する。
【００２５】
図３は、位置情報要求イベント、出力イベントの内容を示す説明図である。図の上方に位置情報要求イベントＥＶ０１、ＥＶ０２、ＥＶ０３を示し、下方に出力イベントＯＰ０１、ＯＰ０２、ＯＰ０３を示した。３つずつのイベントを例示しているが、位置情報要求イベントＥＶ０１〜ＥＶ０３と、出力イベントＯＰ０１〜ＯＰ０３がそれぞれ対応している訳ではない。
位置情報要求イベントＥＶ０１は、アプリケーションによって生成されるものであり、次に示す各情報を格納している。
「発生時刻」は位置情報要求イベントＥＶ０１が生成された時刻である。
「要求元」は、当該イベントを生成したアプリケーションの名称である。図の例では、「アプリＡ」という名称のアプリケーションによって位置情報要求イベントＥＶ０１が生成されたことを表している。
「精度」は、アプリケーションが位置情報の誤差範囲について求める精度仕様である。図の例では、誤差範囲が１０ｍ以下の精度で位置情報を求めていることを表している。
「形式」はアプリケーションが位置情報の表現形式について求める形式仕様である。図の例では、緯度経度などの座標で位置情報を求めていることを表している。座標について緯度経度の他、Ｘ−Ｙ座標系など複数種類の座標系を取扱可能である場合には、「緯度経度」など更に詳細な形式で指定可能としてもよい。
「要求時間」はアプリケーションが位置情報を受け取るまでの待ち時間の許容値である。図の例では、「００：０１：３５」であるから、あと１分３５秒が経過するまでの間に位置情報の受け取りを求めていることを表している。本実施例では、要求時間は時々刻々変化するものとした。つまり、現在時刻から受け渡しが行われるまでの許容時間を表している。これに対し、要求時間には、要求イベントが生成されてから受け渡しが行われるまでの許容時間を固定値で設定するようにしてもよい。
「繰り返し」は位置情報要求イベントの生成を自動的に繰り返すか否かを指定する。図の例では、「無し」と指定されているため、位置情報要求イベントＥＶ０１に基づいて位置情報が生成されると、当該イベントは消去される。これに対し、「有り」で指定されている場合には、位置情報要求イベントＥＶ０１に基づいて位置情報が生成されると、一旦は、当該イベントが消去されるものの、同時に、同じ内容の新たな位置情報要求イベントＥＶ０１が生成される。こうすることによって、例えば、ナビゲーションのように、繰り返し現在位置を検出する必要があるアプリケーションの場合、毎回、位置情報要求イベントを生成する負荷から軽減される。
「出力条件」は位置情報を出力するための条件を指定する。指定される例としては、アプリケーションが、所定の位置に到達した時に位置情報の受け渡しを求める場合があげられる。ナビゲーションのアプリケーションにおいて目的地（所定の緯度経度）に到着したら位置情報の受け渡しを求める場合や、時刻表を表示するアプリケーションにおいて、所定の駅（名称または座標）に到着したら位置情報の受け渡しを求める場合などである。国盗りゲームにおいて、以前に訪れたことがない地名または領域に到着したら位置情報の取得を求める場合にも用いることができる。出力条件は、このように位置に基づく条件の他、所定の時刻になった時に位置情報の受け渡しを求める態様で用いても良い。かかる条件は、タクシーなどの運行管理を行うアプリケーションが、所定時刻ごとに位置を記録する場合などに利用可能である。
「出力先」は、位置情報を受け渡すべきアプリケーションを表している。図の例では、「アプリＡ」に位置情報を受け渡すことになる。通常は、位置情報要求イベントを生成したアプリケーションと、位置情報を受け渡すべきアプリケーションは同一であることが多いため、「要求元」と「出力先」は共通としてもよい。ただし、図３の例のように両者を分けておくと、例えば、スケジュール帳のアプリケーションがスケジュールに従って、現在位置や次の目的地の位置情報取得要求イベントを生成するとともに、ナビゲーションのアプリケーションを出力先と指定することによって、現在位置から目的地までの経路案内を開始させるという態様で利用することもできる。
「位置情報」は、取得された位置情報自体を表している。「位置情報」は、位置情報要求イベントの生成時には、当然にブランクであり、位置情報が取得されると値が設定される。従って、「位置情報」は位置情報を出力するたえの「出力イベント」を生成するか否かの判断基準として用いることができる。
【００２６】
図の下方の出力イベントについて説明する。出力イベントは、位置情報要求イベントに指定された精度、形式、出力条件などのアプリケーション仕様に合致した位置情報が取得されると、位置情報管理部１２０によって生成されるものであり、次に示す各情報を格納している。
「発生時刻」は出力イベントが生成された時刻である。
「出力先」は位置情報要求イベントの出力先に対応する情報であり、出力イベントに格納された位置情報を受け渡すべきアプリケーションを指定する。
「形式」は位置情報の表現形式を表し、「位置情報」は該形式で取得された位置情報を表す。
【００２７】
図３に示した位置情報要求イベントおよび出力イベントの内容は例示に過ぎず、図示した情報の一部のみを備えるようにしてもよいし、更に、この他の情報を格納するようにしてもよい。
また、全ての位置情報要求イベント、出力イベントにおいて、格納すべき情報を統一しておく必要もない。例えば、図３の位置情報要求イベントＥＶ０１において、「出力条件」の指定がない場合には、この項目自体を削除した形でイベントを生成するようにしてもよい。
【００２８】
＜＜ 位置情報管理処理 ＞＞
図４は、位置情報管理処理のフローチャートである。位置情報管理部１２０が実行する処理であり、ハードウェア的には、携帯電話１００のＣＰＵが実行する処理である。この例では、説明の便宜上、一連の処理をフローチャートとして示したが、実際には、位置情報管理部１２０はイベントドリブンで稼働しているため、フローチャート中に示す種々の処理をイベントに基づいて独立に処理するサブプログラムの集合体として構成されている。
処理を開始すると、携帯電話１００は位置情報更新イベントの有無を確認する（ステップＳ１０）。先に説明した通り、携帯電話１００には複数種類の位置情報取得部１３１が備えられている。この中には、基地局との通信による位置情報取得部１３１［２］や、通信端末との通信による位置情報取得部１３１［３］のように、アプリケーションからの位置情報の取得要求の有無を問わず、所定のタイミングで位置情報を取得するものがある。このようなセンサを、自律的位置情報取得部と称するものとする。自律的位置情報取得部が位置情報を取得するタイミングは、それぞれの構成に応じて決まっている。例えば、位置情報取得部１３１［２］のように一定の時間経過ごととしてもよいし、位置情報取得部１３１［３］のように通信端末との通信が行われたタイミングとしてもよい。この他、位置情報取得部の構成によっては、携帯電話１００で位置情報取得要求以外の所定の操作を行ったタイミングとしてもよいし、以上で述べた種々のタイミングの組合せとしてもよい。
位置情報更新イベントとは、これらの自律的位置情報取得部による位置情報の取得が行われた時に生成されるイベントである。位置情報の取得時刻、位置情報を生成した自律的位置情報取得部を特定する情報、取得された位置情報の形式、位置情報、精度などを格納することができる。このように自律的位置情報取得部が位置情報更新イベントを生成することにより、位置情報管理部１２０が、自律的位置情報取得部に対して位置情報の取得を行ったか否かを常時監視する必要がなくなる利点がある。
位置情報更新イベントが生成されている場合、携帯電話１００は、位置情報テーブルを更新する(ステップＳ１２)。位置情報テーブルとは、位置ログ１２１に格納されているテーブル（図２参照）である。つまり、携帯電話１００は、ステップＳ１２の処理では、図２の各ログに位置情報更新イベントに格納されたセンサ種別、取得時刻、位置情報、精度などを格納して、ログを追加する。
次に、携帯電話１００は出力イベント生成処理を実行する（ステップＳ１４）。出力イベント生成処理は、図３で説明した通り、位置情報要求イベントのアプリケーション仕様に合致した位置情報が取得された場合に、その取得結果に基づいて生成されるイベントである。自律的位置情報取得部によって位置情報が取得されたことを受けて、いずれかの位置情報要求イベントのアプリケーション仕様に合致している可能性が生じるため、可能であれば出力イベントを生成するのである。詳細な処理内容については、後述する。
【００２９】
携帯電話１００は、これらの処理が完了すると、次に、位置情報要求イベントの要求時間を更新する（ステップＳ１６）。位置情報更新イベントが生成されていない場合（ステップＳ１０）も同様に、ステップＳ１６の処理を行う。
図３で説明した通り、本実施例では、現在時刻から位置情報の受け渡しが行われるまでの許容時間を、「要求時間」として位置情報要求イベントに格納している。従って、この「要求時間」は時々刻々と減少していく数値である。そこで、携帯電話１００は、位置情報管理処理を実行するたびに、経過時間分だけ、それぞれの位置情報要求イベントの「要求時間」から減じることによって、要求時間を更新するのである。
【００３０】
更新の結果、要求時間が０よりも小さくなる位置情報要求イベントがある場合（ステップＳ１８）、携帯電話１００は、位置情報取得処理（ステップＳ２０）、および出力イベント生成処理（ステップＳ２２）を行う。位置情報取得処理(ステップＳ２０)は、位置情報取得部１３１を用いて位置情報を得るための処理である。要求時間が０より小さいということは、その位置情報要求イベントに対しては、ただちに位置情報の受け渡しを行う必要があることを意味している。従って、携帯電話１００は、自律的位置情報取得部による位置情報の更新（ステップＳ１２）を待つのではなく、位置情報取得部１３１を積極的に活用して位置情報を取得するのである。出力イベント生成処理（ステップＳ２２）は、ステップＳ１４と同じ処理であり、取得された位置情報に基づいて出力イベント（図３参照）を生成する処理である。
位置情報取得処理（ステップＳ２０）、出力イベント生成処理（ステップＳ２２）の内容は後述する。
【００３１】
以上の処理が完了すると、携帯電話１００は、位置情報を出力し、出力イベントを更新する（ステップＳ２４）。位置情報は出力イベントが生成されている場合に、その内容を出力イベントで指定されたアプリケーションに受け渡す処理である。ステップＳ１４、Ｓ２２のいずれにおいても出力イベントが生成されていない場合には、位置情報の出力は行われない。
出力イベントの更新とは、位置情報の受け渡しが完了した出力イベントを消去する処理である。本実施例では、消去するものとしたが、無効化した上で位置情報の受け渡しの履歴として保存しておいてもよい。
携帯電話１００は、以上の処理を繰り返し実行することによって、位置情報取得部１３１を利用して位置情報を取得し、アプリケーションに受け渡すことができる。
【００３２】
＜＜ 出力イベント生成処理 ＞＞
次に、上述のステップＳ１４，Ｓ２２の出力イベント生成処理についてそれぞれ説明する。
図５は、出力イベント生成処理のフローチャートである。位置情報要求イベントに合致する位置情報を位置情報テーブルから抽出し、出力イベントを生成する処理である。本実施例では、自律的位置情報取得部によって取得された位置情報（図４のステップＳ１２）、および位置情報取得処理によって取得された位置情報（図４のステップＳ２０）は、それぞれ位置ログ１２１に保持されている位置情報テーブルに格納される。従って、出力イベントを生成するためには、改めて位置情報を取得する必要性を考慮することなく、単に、この位置情報テーブルを参照するだけで済むのである。
【００３３】
出力イベント生成処理を開始すると、携帯電話１００は、位置情報テーブルの精度を補正する（ステップＳ１００）。携帯端末は、所有者の移動に伴って時間とともに移動する場合があり、位置情報の取得後の経過時間に応じて精度は低下していくことがあるからである。本実施例では、図中に示す通り、取得後の経過時間に応じて設定された補正係数を、取得時点での精度に乗じることによって補正精度を得る。補正係数は、位置情報取得部ごとに設定されている。例えば、通信端末を利用した位置情報取得部は、精度が非常に高いため（図２）、わずかな時間経過でも、精度に及ぼす影響が大きい。従って、比較的、急激に補正係数が増大する、つまり精度が低下する曲線となっている。これに対し、取得時の精度が低い基地局については、比較的緩やかに補正係数が増大する曲線となっている。
補正係数は、携帯電話１００の平均的な移動速度を考慮して設定することができる。これに対し、移動速度に応じて、複数の補正曲線を用意しておいてもよい。例えば、図中のＧＰＳ［１］、ＧＰＳ［２］で表した補正曲線は、いずれもＧＰＳによる位置情報に対応するものである。ＧＰＳ［１］は移動速度が速い場合、ＧＰＳ［２］は移動速度が遅い場合を表している。ここでは、２本だけを例示したが、さらに多くの曲線を設定しておいてもよい。
精度補正の算出方法は、このように補正係数を用いる方法に限らない。例えば、位置情報の履歴を参照して、携帯電話１００の移動速度を推定し、取得時から現時点までの移動距離を推定して、取得時の誤差精度に加える方法をとってもよい。取得時から現時点までの移動距離が１００ｍと推定される場合には、取得時の精度に対して１００ｍを加えた値を補正精度とするのである。この他、種々の方法で補正精度を求めることが可能である。
【００３４】
補正精度を求めると、携帯電話１００は、位置情報管理部１２０に保持されている位置情報要求イベントの中から処理対象となるべき位置情報要求イベントを抽出する（ステップＳ１０２）。そして、抽出した位置情報要求イベントにおける位置情報に対するアプリケーション仕様、つまり位置情報の形式、精度、出力条件が合致する位置情報を、位置情報テーブルから検索する(ステップＳ１０４)。図３に示した位置情報要求イベントＥＶ０１の場合、出力条件は設定されていないから、位置情報の形式が「座標」であり、精度が「１０ｍ」以下である位置情報を検索することになる。
このようにアプリケーション仕様に合致する位置情報が存在しない場合（図５のステップＳ１０４）、携帯電話１００は、次の位置情報要求イベントを抽出する（ステップＳ１０２）。
一方、アプリケーション仕様に合致する位置情報がある場合（ステップＳ１０４）、携帯電話１００は、この位置情報を用いて出力イベントを生成する（ステップＳ１０６）。ここで、アプリケーション仕様に合致する位置情報が複数検索された場合には、精度が高い方を採用する。他の条件で採否を決定しても構わない。
【００３５】
出力イベントを生成した後（ステップＳ１０６）、位置情報要求イベントが「繰り返し」イベントである場合、つまり「繰り返し」に「有り」と設定されたイベントである場合（ステップＳ１０８）、携帯電話１００は、位置情報要求イベントを再生成する（ステップＳ１１０）。こうすることで、アプリケーションが繰り返し位置情報要求イベントを生成するまでなく、比較的容易に、位置情報を繰り返し取得することが可能となる。
一方、「繰り返し」イベントでない場合には（ステップＳ１０８）、位置情報要求イベントを消去する（ステップＳ１１２）。
以上の処理を携帯電話１００は、全ての位置情報要求イベントに対する処理が終了するまで（ステップＳ１１４）、繰り返し実行する。なお、この処理において、ステップＳ１１０で再生成された位置情報要求イベントは、従前から保持されている位置情報要求イベントと区別しておく必要がある。区別しておかないと、「繰り返し」イベントが含まれている場合には、出力イベントを生成した途端に、新たな位置情報要求イベントが生成され、無限に処理が続いてしまうからである。
こうして生成された出力イベントは、位置情報管理処理（図４）の位置情報出力（ステップＳ２４）においてアプリケーションに受け渡される。
【００３６】
＜＜ 位置情報取得処理 ＞＞
次に、位置情報管理処理（図４）のステップＳ２０における位置情報取得処理について説明する。この処理は、位置情報要求イベントに合致する位置情報が取得されないまま、「要求時間」（図３参照）が経過した場合に、位置情報取得部１３１を積極的に活用して位置情報を取得するための処理である。本実施例では、以下に説明する通り、位置情報取得部１３１の中から、位置情報要求イベントにおける位置情報のアプリケーション仕様に合致し、かつ、携帯電話１００の消費電力が最小となるものを選択して、位置情報を取得するようにした。
【００３７】
図６は、位置情報取得手段の選択方法を示す説明図である。位置情報取得部を選択するために、携帯電話１００は、まず位置情報要求イベントごとに、その仕様に合致する位置情報を取得するための方法を列挙する。図６は、位置情報の取得方法を列挙した結果を示したものである。以下では、図６のテーブルを「消費電力テーブル」と呼ぶ。図６では、取得方法を列挙した結果をテーブル形式で示しているが、実際の処理においては、これらの情報が列挙されていれば足り、必ずしもテーブル形式で整理する必要はない。
図６では、位置情報要求イベントＥＶ１１、ＥＶ１２の２つが処理対象となる例を示した。位置情報要求イベントＥＶ１１は住所の形式で位置情報が要求されているものとする。
第１の取得方法として、「変換」、つまり位置情報テーブルに取得されている座標（ＬＡＴ１１，ＬＯＮ１１）を矢印Ａ１１のように変換する方法が挙げられる。この時の消費電力をＷ０１とする。これはインターネットＩＮＴ上の位置情報変換部４０２にアクセスするために要する電力である。
第２の取得手段としては、同様に「変換」、つまり取得済みの名称「○○駅」という位置情報を、矢印Ａ１２のように変換する方法である。この場合の消費電力もインターネットＩＮＴ上の位置情報変換部４０２にアクセスするために要する電力でありＷ０１である。
第３の取得手段としては、通信端末を利用して、住所の形式で位置情報Ｄ１を取得する方法である。この場合の消費電力をＷ０２とする。
【００３８】
携帯電話１００は、位置情報要求イベントＥＶ１２についても、同様に位置情報の取得方法を列挙する。位置情報要求イベントＥＶ１２は、「名称」の形式で位置情報が要求されているものとする。
第１の取得方法として、「変換」、つまり位置情報テーブルに取得されている座標（ＬＡＴ１１，ＬＯＮ１１）を矢印Ａ１３のように変換する方法が挙げられる。この場合の消費電力もインターネットＩＮＴ上の位置情報変換部４０２にアクセスするために要する電力でありＷ０１である。
第２の取得手段としては、通信端末を利用して、名称の形式で位置情報Ｄ２を取得する方法である。この場合の消費電力はＷ０２となる。
第３の取得手段としては、「ＧＰＳ＋変換」、つまりＧＰＳによって座標Ｄ３を取得した後、矢印Ａ１４のように「名称」の形式に変換する方法である。この場合の消費電力をＷ０３とする。この電力は、ＧＰＳによって座標を取得するための電力と、位置情報変換部４０２にアクセスして形式を変換するための消費電力（Ｗ０１に相当する）の和である。
【００３９】
携帯電話１００は、このように位置情報要求イベントごとに、仕様に合致する位置情報の取得方法を列挙すると、この中から消費電力が最小となるものを選択する。この選択を実現するための評価方法は、種々の考え方に基づいて設定することができる。
第１の方法は、単純な総和で求める方法である。つまり、位置情報要求イベントＥＶ１１の中から電力最小となる方法を選択し、位置情報要求イベントＥＶ１２の中から電力最小となる方法を個別に選択するのである。選択結果によっては２通りの方法で位置情報を取得する必要が生じるが、選択のための処理が簡易であるため、種々の状況に汎用的に利用することが可能となる利点がある。
第２の方法は、要求時間が０となっている位置情報要求イベントを優先的に選択する方法である。例えば、図６において、「位置情報要求イベントＥＶ１１の要求時間＝０、位置情報要求イベントＥＶ１２の要求時間＞０」という状態であったとすると、位置情報要求イベントＥＶ１１の中から電力最小の方法を選択する。この選択された方法で得られた位置情報が、位置情報要求イベントＥＶ１２の仕様にも合致する場合には、位置情報要求イベントＥＶ１２についても出力イベントが生成されることになるし、仕様に合致しない場合には、位置情報要求イベントＥＶ１２は、未処理のまま残されることになる。
第３の方法は、全ての位置情報要求イベントを総合的に考慮する方法である。図６の例では、位置情報要求イベントＥＶ１１、ＥＶ１２を個別に扱っているが、この段階で、両者の仕様に合致する位置情報を取得するための方法を列挙するのである。つまり、位置情報要求イベントＥＶ１１の「住所」と、位置情報要求イベントＥＶ１２の「名称」の双方の形式で位置情報を得るための方法を列挙する。この場合、第１の方法として、既に取得済みの座標（ＬＡＴ１１、ＬＯＮ１１）を矢印Ａ１１、Ａ１３のように変換する方法が挙げられる。いずれも同一の位置情報変換部４０２にアクセスすれば足りるから、消費電力はＷ０１である。第２の方法として、取得済みの名称「○○駅」を矢印Ａ１２のように変換する方法が挙げられる。この場合も消費電力はＷ０１である。このように、名称、住所の双方で位置情報が得られる方法を列挙した上で、その消費電力が最小となる方法を選択すればよい。第３の方法によれば、全ての位置情報要求イベントの仕様に合致する位置情報を最小の消費電力で得ることができる。
このように消費電力が最小となる方法の選択には、種々の評価方法を適用することができる。上述の３通り以外の方法を適用してもよい。また、評価方法１で位置情報の取得方法が決まらない場合には、評価方法２を適用するという具合に、複数の評価方法を段階的に用いても良い。
【００４０】
図７は、位置情報取得処理のフローチャートである。図６で説明した考え方に基づき、位置情報取得部を選択して、位置情報を取得するための処理である。
携帯電話１００は、まず処理対象となる位置情報要求イベントを抽出する（ステップＳ２００）。そして、位置情報テーブルから取得済みの位置情報を検索し、消費電力テーブル（図６）に追加する（ステップＳ２０２）。この際、補正精度が位置情報要求イベントにおける精度の仕様を満たすこと、および要求された形式に変換可能であることを検索条件とする（ステップＳ２０２）。位置情報要求イベントにおいて「出力条件」が設定されている場合には、更に、この出力条件を満たすことも条件に加える必要がある。
【００４１】
次に、携帯電話１００は、利用可能な取得方法を消費電力テーブル（図６）に追加する（ステップＳ２０４）。図６の位置情報要求イベントＥＶ１１に対する「通信端末」や、位置情報要求イベントＥＶ１２に対する「通信端末」、「ＧＰＳ＋変換」が、ステップＳ２０４で追加された方法に相当する。
取得可能な方法の選択は、図中の右側に示したテーブルを参照することにより可能である。このテーブルは、縦に位置情報取得部、横に位置情報の形式をとり、それぞれの形式の位置情報を、各位置情報取得部で直接「取得」することができるか、形式の「変換」が必要かを表したものである。例えば、「基地局」および「ＧＰＳ」を利用すると、「座標」は直接取得可能であるが、「名称」「住所」は取得後に変換が必要になることが分かる。「通信端末」を利用すれば、いずれの形式も直接に「取得」できることが分かる。
ステップＳ２０４では、位置情報要求イベントにおける「精度」仕様に合致する位置情報取得部を選択し、その上で図中のテーブルを参照して、「形式」仕様に合致する位置情報を得るために「変換」が必要か否かを判断すればよい。こうして「精度」「形式」仕様を満足する位置情報取得部が存在すれば、消費電力テーブルに追加することができる。
【００４２】
消費電力テーブルを生成すると、携帯電話１００は、総消費電力が最小となる方法で位置情報を取得し、位置情報テーブルを更新する（ステップＳ２０６）。位置情報を取得する方法の選択については、図６で説明した通りである。この処理によって位置情報テーブルを更新することにより、位置情報管理処理の出力イベント生成処理（図４のステップＳ２２）によって出力イベントが生成されるようになる。
【００４３】
以上で説明した実施例１の携帯電話１００によれば、位置情報管理部１２０が、位置情報の仕様および位置情報取得に要する消費電力を考慮して、位置情報をアプリケーションに受け渡すことができる。従って、各アプリケーションの仕様に合致した位置情報を、電力の消費を抑えて効率的に受け渡すことが可能となる。
【実施例２】
【００４４】
本発明の実施例２における携帯電話１００について説明する。システム構成は実施例１と同様である（図１〜３参照）。実施例２では、位置ログ１２１に記憶されている位置情報テーブル（図２）に、全ての形式で位置情報を蓄えておく点で実施例１と相違する。位置情報の形式は、座標、名称、住所に限られず、携帯電話１００に登録されているアプリケーション、または稼働中のアプリケーションに応じて決めることができる。
このように各形式で位置情報を取得するため、実施例２では、位置情報管理処理（図４）および位置情報取得処理（図７）が実施例１と相違する。
【００４５】
図８は、第２実施例における位置情報管理処理のフローチャートである。処理を開始すると、携帯電話１００は、位置情報として要求される形式を、登録されているアプリケーションに基づき特定する（ステップＳ０８）。稼働中のアプリケーションに基づいて特定してもよい。
図中には、アプリ１は「座標」、アプリ２は「名称」「住所」、アプリ３は「住所」を要求している例を示した。この状態であれば、これらの論理和により、要求される形式として、「座標」「名称」「住所」が特定されることになる。
【００４６】
次に、実施例１と同様、携帯電話１００は、位置情報更新イベントの有無を確認する（ステップＳ１０）。位置情報更新イベントが有る場合には、その位置情報更新イベントに基づいて位置情報を取得し（ステップＳ１２ａ）、他形式への変換を行う（ステップＳ１２ｂ）。例えば、ＧＰＳで「座標」が取得されている場合には、位置情報変換部４０２にアクセスして、「名称」「住所」の情報を取得するのである。「通信端末」を用いた場合のように、全形式で位置情報が取得されている場合は、変換は不要である。
携帯電話１００は、こうして得られた位置情報により、位置情報テーブルを更新する（ステップＳ１２ｃ）。実施例２では、ステップＳ０８で特定された全形式で位置情報が得られているから、位置情報テーブル（図２）の全ての欄に値が格納されることになる。
その後、携帯電話１００は、出力イベント生成処理を行う（ステップＳ１４）。この処理の内容は実施例１と同様である（図６参照）。
一方、位置情報更新イベントが無い場合は（ステップＳ１０）、これらの処理をスキップする点も実施例１と同様である。
【００４７】
図９は、第２実施例における位置情報取得処理のフローチャートである。位置情報テーブルに、全形式で位置情報が格納されているため、位置情報テーブルにおいて「精度」および「出力条件」のアプリケーション仕様に合致する位置情報が存在すれば、出力イベント生成処理で処理されているはずである。つまり、位置情報取得処理では、取得済みの位置情報の「変換」を考慮する必要がなく、新たに位置情報を取得することだけを考慮すれば足りる点が実施例１と相違する。
携帯電話１００は、位置情報取得処理を開始すると、処理対象となる位置情報要求イベントを抽出する（ステップＳ２００）。そして、利用可能な取得方法を消費電力テーブルに追加する（ステップＳ２０４Ａ）。実施例２では、全ての形式で位置情報を取得するものとしているから、消費電力も、これに要する消費電力を算出する。例えば、ＧＰＳを利用する場合には、ＧＰＳによって位置情報を取得するための消費電力と、それで得られた座標を、名称、住所に変換するための消費電力との和が、消費電力テーブルに格納されることになる。
携帯電話１００は、こうして消費電力テーブルを生成すると、この中から総消費電力が最小となる方法を選択し、位置情報を取得して、位置情報テーブルを更新する（ステップＳ２０６）。この処理は、実施例１と同様である。
実施例２によれば、常に全ての形式で位置情報を取得するため、取得済みの位置情報を容易に有効活用することができる。
【００４８】
以上で説明した各実施例のシステムによれば、携帯電話１００は位置情報を利用する種々のアプリケーションに対して、消費電力を抑制しつつ、効率的に位置情報を受け渡すことが可能となる。
実施例では、特定の位置情報取得部や位置情報の形式を対象として説明したが、本実施例は、これらに限定されず、種々の位置情報取得部、位置情報の形式に対して適用可能である。また、実施例では、イベントドリブン方式での処理方法を例示したが、ソフトウェアのプログラミングも種々の方法で行うことが可能である。
【産業上の利用可能性】
【００４９】
本発明は，携帯端末における位置情報の取得および管理に利用可能である。
【符号の説明】
【００５０】
１００…携帯電話
１０２…アンテナ
１１１…アプリケーション保存部
１２０…位置情報管理部
１２１…位置ログ
１３１…位置情報取得部
２００…基地局
２０２…位置情報送信部
３００…レジ
３０２…位置情報送信部
４００…地図サーバ
４０２…位置情報変換部
【特許請求の範囲】
【請求項１】
位置情報を利用した複数のアプリケーションを稼働可能な携帯端末であって、
前記アプリケーションを保存するアプリケーション保存部と、
前記携帯端末の位置情報を取得するための複数種類の位置情報取得部と、
前記位置情報取得部による位置情報の取得および取得された位置情報の管理を行い、該位置情報を前記アプリケーションに対して受け渡す位置情報管理部とを備え、
前記位置情報管理部は、
前記位置情報が、予め設定された複数の形式のうち一部の形式のみで取得されている場合には、不足する形式に前記位置情報を変換することによって、前記複数の形式で位置情報を記憶し、
前記アプリケーションから位置情報を要求されたときには、前記記憶されている位置情報を優先的に用いて、位置情報を受け渡す携帯端末。
【請求項２】
請求項１記載の携帯端末であって、
前記位置情報管理部は、
前記アプリケーションについての位置情報の形式に関する仕様である形式仕様を記憶し、
前記複数のアプリケーションの形式仕様に対応する形式の論理和によって、前記複数の形式を設定する携帯端末。
【請求項３】
請求項１または２記載の携帯端末であって、
前記アプリケーション仕様には位置情報の精度に関する精度仕様が含まれており、
前記位置情報管理部は、
取得済みの位置情報の精度を、取得後の経過時間に基づいて補正した上で、前記精度仕様に適合するか否かを判断し、
前記精度仕様に適合する位置情報が存在しない場合には、前記位置情報取得部を用いて前記アプリケーションからの形式および精度仕様に適合する位置情報を取得し、該アプリケーションに位置情報を受け渡す携帯端末。
【請求項４】
請求項３記載の携帯端末であって、
前記位置情報管理部は、位置情報を新たに取得する場合には、該位置情報の取得に要する消費電力および取得された位置情報を前記複数の形式に変換するために要する消費電力が最小と評価される位置情報取得部を利用して位置情報の取得を行う携帯端末。
【請求項１】
位置情報を利用した複数のアプリケーションを稼働可能な携帯端末であって、
前記アプリケーションを保存するアプリケーション保存部と、
前記携帯端末の位置情報を取得するための複数種類の位置情報取得部と、
前記位置情報取得部による位置情報の取得および取得された位置情報の管理を行い、該位置情報を前記アプリケーションに対して受け渡す位置情報管理部とを備え、
前記位置情報管理部は、
前記位置情報が、予め設定された複数の形式のうち一部の形式のみで取得されている場合には、不足する形式に前記位置情報を変換することによって、前記複数の形式で位置情報を記憶し、
前記アプリケーションから位置情報を要求されたときには、前記記憶されている位置情報を優先的に用いて、位置情報を受け渡す携帯端末。
【請求項２】
請求項１記載の携帯端末であって、
前記位置情報管理部は、
前記アプリケーションについての位置情報の形式に関する仕様である形式仕様を記憶し、
前記複数のアプリケーションの形式仕様に対応する形式の論理和によって、前記複数の形式を設定する携帯端末。
【請求項３】
請求項１または２記載の携帯端末であって、
前記アプリケーション仕様には位置情報の精度に関する精度仕様が含まれており、
前記位置情報管理部は、
取得済みの位置情報の精度を、取得後の経過時間に基づいて補正した上で、前記精度仕様に適合するか否かを判断し、
前記精度仕様に適合する位置情報が存在しない場合には、前記位置情報取得部を用いて前記アプリケーションからの形式および精度仕様に適合する位置情報を取得し、該アプリケーションに位置情報を受け渡す携帯端末。
【請求項４】
請求項３記載の携帯端末であって、
前記位置情報管理部は、位置情報を新たに取得する場合には、該位置情報の取得に要する消費電力および取得された位置情報を前記複数の形式に変換するために要する消費電力が最小と評価される位置情報取得部を利用して位置情報の取得を行う携帯端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１２−１１８４１１（Ｐ２０１２−１１８４１１Ａ）
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願番号】特願２０１０−２６９７８７（Ｐ２０１０−２６９７８７）
【出願日】平成２２年１２月２日（２０１０．１２．２）
【出願人】（５９７１５１５６３）株式会社ゼンリン (155)
【Ｆターム（参考）】
【公開日】平成２４年６月２１日（２０１２．６．２１）
【国際特許分類】
【出願日】平成２２年１２月２日（２０１０．１２．２）
【出願人】（５９７１５１５６３）株式会社ゼンリン (155)
【Ｆターム（参考）】
[ Back to top ]