(57)【要約】  軌道パラメータを含むデータモデルは、モバイルデバイスに記憶される。モバイルデバイスのＧＮＳＳシステムによってＦｉｒｓｔ  Ｆｉｘが要求された場合、これらの記憶された軌道パラメータが利用され、迅速に正確な衛星軌道データモデルが生成される。この記憶された軌道パラメータは、部分的に又は全部について、記憶されたパラメータの係数の変更によって修正されてもよい。
2013522607.tif 000002
【特許請求の範囲】
【請求項１】
地球航法衛星システムのための位置検出方法であって：
モバイルデバイスの、衛星の軌道及び／又はクロックデータのモデルの少なくとも１つの係数をアップデートするステップであって、前記モデルは軌道パラメータを含む、ステップと；
前記モバイルデバイスによって、前記記憶された軌道パラメータから衛星軌道情報を抽出するステップと；
前記モバイルデバイスによって、前記抽出された衛星軌道情報に基づいて、前記衛星の位置を決定するステップと；
前記決定された衛星の位置とクロックデータとに従って、前記モバイルデバイスの位置を決定するステップと；
を有する方法。
【請求項２】
請求項１記載の方法であって、前記モデルを生成するために、力モデルが利用される、方法。
【請求項３】
請求項１記載の方法であって、前記軌道パラメータは、係数を含む、方法。
【請求項４】
請求項１記載の方法であって、前記軌道パラメータは、多項式を形成する、方法。
【請求項５】
請求項１記載の方法であって、前記モデルは、天体歴又は歴の基準を参照するエラー訂正項を含む、方法。
【請求項６】
請求項１記載の方法であって、前記少なくとも１つの係数をアップデートするステップは、前記衛星軌道データの変更を反映させるために、前記少なくとも１つの前記係数を周期的にアップデートするステップ、を含む方法。
【請求項７】
請求項６記載の方法であって、前記モバイルデバイスは、アップデートされた係数を計算するステップ、を更に有する方法。
【請求項８】
請求項１記載の方法であって：
特定の衛星軌道データを含む、少なくとも天体歴データのサブフレームをダウンロードするステップと；
前記抽出された衛星軌道情報と、前記ダウンロードされた特定の衛星軌道データと、に基づいて前記衛星の位置を決定するステップと；
を有する方法。
【請求項９】
地球航法衛星システムにおいて利用されるモバイルデバイスであって：
地球航法衛星システムに従って、当該モバイルデバイスの位置を決定するための地球航法衛星システムモジュールと；
前記地球航法衛星システムモジュール及びメモリに接続された中央処理ユニットと；
を有し、前記メモリは：
軌道パラメータを含む、衛星の軌道及び／又はクロックデータの、モデルと；
コンピュータコードであって、前記中央処理ユニットで実行されたときに、前記モデルの少なくとも１つの係数をアップデートし、前記メモリに記憶された前記軌道パラメータから、衛星軌道情報を抽出し、前記抽出された衛星軌道情報に基づいて前記衛星の位置を決定し、かつ前記決定された衛星の位置に従って当該モバイルデバイスの位置を決定する、コンピュータコードと；
を含む、モバイルデバイス。
【請求項１０】
請求項９記載のモバイルデバイスであって、前記メモリは、
コンピュータコードであって、前記中央処理ユニットで実行されたときに、前記衛星軌道データの変更を反映させるために、前記少なくとも１つの前記係数を周期的にアップデートする、コンピュータコードを更に含む、
モバイルデバイス。
【請求項１１】
請求項９記載のモバイルデバイスであって、前記メモリは、
コンピュータコードであって、中央処理ユニットによって実行されたときに、特定の衛星軌道データを含む、天体歴データの少なくともサブフレームをダウンロードし、前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて、前記衛星の位置を決定する、コンピュータコード、
を更に含む、モバイルデバイス。
【請求項１２】
地球航法衛星システムのための位置検出方法であって：
衛星の軌道及び／又はクロックデータのモデルを、モバイルデバイスに記憶するステップであって、前記モデルは軌道パラメータを含む、ステップと；
前記記憶された軌道パラメータから、衛星軌道情報を抽出するステップと；
特定の衛星軌道データを含む、天体歴データの少なくともサブフレームをダウンロードするステップと；
前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて、衛星の位置を決定するステップと；
前記決定された衛星の位置に従って、前記モバイルデバイスの位置を決定するステップと；
を有する方法。
【請求項１３】
請求項１２記載の方法であって、前記サブフレームは、ナビゲーションメッセージサブフレームを含む、方法。
【請求項１４】
地球航法衛星システムにおいて利用されるモバイルデバイスであって、地球航法衛星システムに従って、当該モバイルデバイスの位置を決定するための地球航法衛星システムモジュールと；
前記地球航法衛星システムモジュール及びメモリに接続された中央処理ユニットと；
を有し、前記メモリは：
軌道パラメータを含む、衛星の軌道及び／又はクロックデータの、モデルと；
コンピュータコードであって、前記中央処理ユニットで実行されたときに、前記メモリに記憶された前記軌道パラメータから、衛星軌道情報を抽出し、特定の衛星軌道データを含む、天体歴データの少なくともサブフレームをダウンロードし、前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて前記衛星の位置を決定し、かつ前記決定された衛星の位置に従って、当該モバイルデバイスの位置を決定する、コンピュータコードと；
を含む、モバイルデバイス。
【請求項１５】
請求項１４記載のモバイルデバイスであって、前記サブフレームは、ナビゲーションメッセージサブフレームを含む、モバイルデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、地球航法衛星システム（ＧＮＳＳ：Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）軌道予測に関する。
【背景技術】
【０００２】
２０１０年５月６日に出願された米国特許仮出願第６１／３３１，８６５号、及び２０１１年５月５日に出願された米国特許出願第１３／１０１，１５８号は、米国特許法第１１条（ｅ）に基づき、本明細書に引用され完全に組み込まれる。
【０００３】
正確にリモート受信器の位置を算出するためには、３ないし４個の各々のＧＮＳＳ衛星のクロック及び軌道情報についての非常に正確な情報（ｋｎｏｗｌｅｄｇｅ）が必要となる。リモート受信器は、通常は３０秒ごとに、各々の衛星によって繰り返しブロードキャストされる天体暦情報から、この情報を取得することができる。しかしながら、衛星の軌道に影響を及ぼす多くの要因のために、このブロードキャストされたＧＮＳＳ天体暦情報は、通常は将来において、わずか２ないし４時間程度有効なだけである。
【０００４】
したがって、リモート受信器は長期の期間に亘って、この更新された天体暦情報を受信することができず、例えばスイッチオフ、又は、受信不能であった場合、リモート受信器が再度起動（ｒｅａｃｔｉｖａｔｅ）するときに、前に記憶されたいかなる天体暦情報も無効である。そして、リモート受信器がその現在の位置を算出し始める前に、更新された情報が衛星から読み出される必要がある。リモート受信器がオンにされてから、現在の位置を算出することができるようになるまでの間の遅れは、測位可能となるまでの時間（ＴＴＦＦ：Ｔｉｍｅ  Ｔｏ  Ｆｉｒｓｔ  Ｆｉｘ）として知られている。あらゆる遅延がユーザを苛立たせることになるため、ＧＮＳＳ（例えばＧＰＳ）で最も重要なタスクのうちの１つは、リモート受信器のための軌道天体暦を延長（ｅｘｔｅｎｄ）し、又は、予測することによってＴＴＦＦの速度を上げることである。
【０００５】
この課題への１つの幅広いアプローチは、サーバが、天体暦情報を収集し、かつ将来に向かって多数の日に亘って拡張した衛星軌道及びクロック情報を算出することである。軌道算出の複雑度及び必要な精度のために、受信された天体暦情報にしばしば摂動力モデル（ｐｅｒｔｕｒｂｅｄ  Ｆｏｒｃｅｄ−ｍｏｄｅｌ）を使用する。許容できる誤差の範囲に収まるように、将来の多くの日に対して延長された推定を行うには、パワーのあるセントラルサーバにおいて特殊なソフトウェアを使用することが必要とされる。リモートサーバが、再起動するたびに、リモートレシーバのＴＴＦＦは、この延長された情報を直接インターネット又はワイヤレス通信システムを介してセントラルサーバから直ちに受信することにより、衛星からのブロードキャストを繰り返すのを待っているよりも、かなり短くなる。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＴＴＦＦの課題への第２の幅広いアプローチは、将来に渡り、その延長された期間におけるＧＮＳＳ軌道データをモバイル受信器に連続的にサーバが提供することである。この解決案は、リモートレシーバが、サーバと、連続的に、又は少なくとも頻繁な接続を行うことを必要とし、リモートレシーバ上に十分なデータ記憶容量を持つことを必要とする。
【課題を解決するための手段】
【０００７】
地球航法衛星システムのための位置検出方法が開示されている。衛星の軌道及び／又はクロックデータのモデルが、モバイル機器に記憶される。そして、生成されたモデルは軌道パラメータを含み、これらは変更可能であり、又はアップデートされ得る。最初の修正を取得するために、モバイル機器は、記憶された軌道モデルから衛星軌道情報を抽出し、かつ抽出された衛星軌道情報に基づいて、衛星の位置を決定する。衛星の位置を知ると、モバイル機器の位置を決定することができる。
【０００８】
地球航法衛星システムのための位置検出方法が更に開示されている。方法は、特定の衛星軌道データを含む天体歴データの少なくともサブフレームをダウンロードするステップと、前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて衛星の位置を決定するステップと、を更に有する。
【０００９】
地球航法衛星システムにおいて使用されるモバイル機器も開示される。モバイル機器は、地球航法衛星システムに従ってモバイル機器の位置を決定するための地球航法衛星システムモジュールと、地球航法衛星システムモジュール及びメモリに接続されたＣＰＵとを含む。メモリは、衛星の軌道及び／又はクロックデータの（軌道パラメータを含む）モデルと、コンピュータコードとを有する。このパラメータは、変更可能であり又はアップデートされ得る。このコンピュータコードは、ＣＰＵによって実行されると、メモリに記憶された軌道パラメータから衛星軌道情報を抽出し、抽出された衛星軌道情報に基づいて衛星の位置を決定し、決定された衛星の位置及びクロックデータに従って、モバイルデバイスの最初の修正を決定する。
【００１０】
本発明のこれらの、そしてまた他の目的は、さまざまな図及び図面において例示される以下の好ましい実施例の詳細な説明を読むことによって、当業者にとって明らかになることは明らかである。
【図面の簡単な説明】
【００１１】
【図１】軌道データを予測し、かつ衛星信号を得るために単独で延長された（ｓｅｌｆ−ｅｘｔｅｎｄｅｄ）軌道データを使用したブロック図である。
【図２】開示の一実施例に従って軌道データを予測するフローチャートである。
【図３】開示の一実施例に従って、補償されたエラー訂正を示すグラフである。
【図４】開示の一実施例に従って軌道データを予測することを示すフローチャートである。
【図５】開示の一実施例に従って軌道データを予測することを示すフローチャートである。
【図６】本明細書に詳細に記述した実施例を使用したＧＮＳＳを用いたデバイスの例を示す図である。
【発明を実施するための形態】
【００１２】
図１は、本開示の実施例に従って、衛星の信号を取得するために、軌道データを予測し、かつ、単独で延長された軌道データを用いる一般的なフローチャート１０を示している。図１において、点線２０（特にステップ２２、２４、２６及び２８）におけるステップは、速いＴＴＦＦのための軌道データを延長する１つの方法の例を示している。ステップ６０に示すように、天体暦データを、システムにインポートすることができ、かつステップ５５で、有効性のためのチェックがなされる。データが有効な場合、フローはステップ６０へジャンプする。データがもはや有効でない場合、フローはステップ２２へジャンプする。ステップ２２ないし２６において、衛星信号から受信される天体暦データは、短い期間の間延長することができ、かつメモリに記憶することができる。ステップ２８において、記憶されたデータが抽出されチェックされる。ステップ３０で、容認できる許容エラーに従って、全天体歴が利用できるか、及び有効であるかが確認される。抽出されたデータが完全ではなく、有効な場合、衛星の軌道が利用できないことを示すフラグをステップ４０でセットしてもよい。抽出されたデータが完全で、かつ有効な場合、フローはステップ６２、６５、７０、７５、８０及び８５へジャンプする。最後に位置が決定される。
【実施例】
【００１３】
図２は、本開示の一実施例に従った、軌道データ予測を示すフローチャート２００を示している。この実施例において、軌道／クロックの記憶は、ＧＮＳＳサーバに予め格納される。モデルは、軌道データを算出し／予測するための複数の係数を含む。モデルは、時間の関数であってもよい。位置決定が必要な場合、対応するタイミング情報が、モデルの中で代替され、予測された衛星軌道データが生成される。したがって、天体暦は、もはや位置決定のために必要な初期条件ではない。ＧＮＳＳレシーバは、衛星、又は、外部サーバからの天体暦を受信することなく、記憶された軌道／クロックモデルを使用して、将来の軌道データを予測することができる。例えば、１つ以上のＧＮＳＳ衛星に対して、所定の時間（例えば、何ヶ月かの間）、天体歴データを分析することによって、記憶された軌道／クロックモデルが、ＧＮＳＳレシーバの外で確立（生成）される。そして、記憶された軌道／クロックモデルとして、衛星の軌道の傾向を示すことができるパラメータが、ＧＮＳＳサーバにインストールされる。ステップ２１５における、この計算モデルは、いかなるタイプであってもよい。例えば、力モデル（ｆｏｒｃｅ  ｍｏｄｅｌ）、数値モデル（ｎｕｍｅｒｉｃａｌ  ｍｏｄｅｌ）が挙げられる。そして、モデルは、必要に応じて、将来時点における、軌道及びクロックデータを取得するために利用できる。データモデルは、パワフルなサーバを使用して大量のデータ及び複雑なソフトウェアを参照することによって構築されるため、データモデルは非常に正確であり得る。データモデルは、将来の数週間、数ヶ月、或いは更に長期に渡り、エラー耐性（ｅｒｒｏｒ  ｔｏｌｅｒａｎｃｅｓ）がある。
【００１４】
このようなデータモデルの１つの非限定的な例として、衛星軌道、及び／又はクロックデータは、変動次数の多項式（ｐｏｌｙｎｏｍｉａｌ  ｏｆ  ｖａｒｙｉｎｇ  ｏｒｄｅｒｓ）に変形（ｒｅｄｕｃｅ）することができる。各次数（ｏｒｄｅｒ）は、係数（ｃｏｅｆｆｉｃｉｅｎｔ）を持つ。実際の応用において、１つの及び／又はそれ以上の多項式（ｐｏｌｙｎｏｍｉａｌｓ）（又は、他のデータモデル）が、衛星の軌道全体、及び／又は衛星の軌道の部分の各々をモデル化するために用いられてもよい（例えば、ケプラーのパラメータ又は、可能であればＸ、Ｙ、及びＺパラメータの何れかが利用できる。そして、本発明は、これらに限定されるものではない）。軌道及びクロックデータの正確な表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を、その衛星に提供するために、係数の大多数は、仮に決定される（一部の実施例においては変更され得る）。一旦受け入れられ得るデータモデルが生成されると、ステップ２２０に示すように、軌道パラメータはデータモデルから直接に算出することができる。これらの軌道パラメータは、適切な係数を含む多項式（又は、適用された他の算出方法）データモデルのためのベースを形成する。この例において、この多項式の予め定められた次数（ｏｒｄｅｒ）の一つ以上の係数の置換又は変更によって、解が得られたときに、対応した置換／変更された係数によって表現されたときに、その衛星に対する適度に正確な軌道及び／又はクロックデータを得ることができる。
【００１５】
一旦モバイルデバイスがＧＮＳＳの機能を取得し、かつ軌道パラメータを取得しモバイルデバイス内に保存されると、Ｆｉｒｓｔ  Ｆｉｘ（測位可能状態となるまでの時間）を必要とし、適切な係数、例えば、おそらくは現在の時刻等が軌道パラメータに適用される（ステップ２２８参照）。この適切な係数の適用によって、衛星軌道データの抽出がなされ、これは、軌道パラメータによって推定されたものであり、情報を得るために、ホストシステムへのアクセス又は衛星信号を必要としないこととなる。この抽出された衛星軌道データは、ステップ２３０でその後チェックされる。すなわち、これが完全な天体歴データと等価なものとなっていること、及びこの抽出されたデータが依然として有効であることを確認するためにチェックされる。データの有効性は、許容できるエラー耐性、ステップ２１５で利用されるデータモデルのタイプ、及びその他の設計的考慮事項に従う。
【００１６】
抽出されたデータが完全でかつ有効であるとみなされる場合、衛星の位置及び速度（ステップ２６０）は、ホストシステムからの又は衛生信号からの天体歴データの受信を待つことなく、抽出されたデータを利用することによって、決定することができる。これによって、ＴＴＦＦ（測位可能状態となるまでの時間）を非常に改善することができる。軌道パラメータは、多くの履歴データ及び、時間制約のほとんどない強力なソフトウェアを使用して算出することができるため、記憶された軌道パラメータから抽出された衛星軌道データの正確度及び有効性は、従来の方法に比して、大きく改善されることとなる。
【００１７】
図３は、この種の抽出された衛星軌道データの単純な例を示している。図３において、６次多項式の軌道パラメータが使用されている。
【００１８】
図示するように、この例で軌道パラメータから抽出されるデータは相応な１００メートルのオーダーの誤差を発生させる。しかしながら、このレベルの誤差は受け入れられるエラー耐性の範囲内である。より長い期間の天体歴データ及び高次元の軌道パラメータは、ステップ２１５において生成される場合、簡単に実現でき、抽出されたデータの正確で有効な継続期間は、更に長くなり改善する。
【００１９】
軌道／クロックモデルは、天体歴又は歴の基準（ｒｅｆｅｒｅｎｃｅ  ｅｐｈｅｍｅｒｉｓ  ｏｒ  ａｌｍａｎａｃ）、及び複数の係数を含む。そして、これは、特定の天体歴又は歴の基準を参照するエラー訂正項を記述している。換言すれば、衛星の基準天体歴及びエラーモデルは、モバイルデバイスに予め格納されてもよい。位置決定が必要な場合、推定されるエラーを計算するために、対応するタイミング情報がモデルの中で置き換えられ、推定された誤差を基準天体暦／歴と結合することによって、推定された衛星軌道データが生成される。したがって、天体暦は、位置決定のために必要な初期条件ではない。ＧＮＳＳレシーバは、衛星、又は、外部サーバから天体暦を受信することなく、記憶モデルを使用して将来の軌道データを予測することができる。
【００２０】
エラーの減少及び延長の増加を考慮し、以下の実施例は、エラーを補償するために、モバイルデバイス内に記憶された軌道パラメータを修正する能力を有する。
【００２１】
権限を有するシステム（ａｕｔｈｏｒｉｔｉｅｓ）により軌道及びクロックが変更されるため、軌道の幾つかのバリエーション、及び多くの他のファクタ、軌道の裁量のパラメータでさえ、しばしば調整を行うことが必要になることがある。したがって、以下の実施例の各々では、記憶された軌道パラメータを修正する能力を有してもよい。この場合、係数をアップデートすることが好ましい。これらの新たなアップデートする係数は、適切なサーバに接続することによって取得してもよい。或いは、モバイルデバイスは、それ自身で係数をアップデートすることが可能であってもよい。係数の自己アップデートは、新たにダウンロードされた天体歴と、記憶された軌道パラメータから抽出されたデータとの差を計算することによって達成され得る。モバイルデバイスに記憶されたプログラムコード及び／又は計算規則が利用され得る。これによって、図２に示す全データモデル２１５を処理することを必要とせずに、周期的に、適切に係数をアップデートすることができる。
【００２２】
１つ又は幾つかの係数だけを新たにアップデートすることも可能である。例えば、ＸＹＺパラメータが利用されていると仮定する。その午後しばらくして、Ｘ及びＹの両者のパラメータは、エラー耐性の範囲内で推移しており、Ｚパラメータは、許容できる耐性の外に記録されると仮定する。この場合、記憶された軌道パラメータは、修正され得る。これは、置換又は修正を介して、抽出されたＺパラメータが、許容できるエラーリミット内に戻される。これは、様々な方法で達成することができる。なお、Ｚパラメータに影響をしている適切な係数を単純に変更することでもよい。この修正アクションが採用された場合、特に、所定の衛星の軌道の変更が実行されたときに、インターネット又はワイヤレス接続を介して、新たな係数を取得し得る。或いは、モバイルデバイスは、そのようなエラーにトラッキングすることができ、そして、定義された規則又は計算に従って軌道パラメータを修正することによって、自身が修正アクションをとることができる。当業者であれば、デカルト座標系で示された上述のＸＹＺパラメータは、天球座標システムで表現されたケプラーパラメータ、或いはその他の座標システムに拡張できることが理解できるであろう。より詳細な説明は、簡潔さを担保するために省略する。
【００２３】
図４は、記憶された軌道パラメータを調整すること可能とする実施例のフローチャート４００を示している。１つ以上の軌道パラメータから抽出されたほとんどのデータは、有効のままであるが、１つ以上の抽出されたデータが、定義されたエラー耐性を超えることがあり得る。例えば、所定の衛星のクロックが権利者によって変更された場合を想定する。抽出されたデータは、変更されたクロックとマッチしない。そして、正確な位置情報は、もはや取得することができない。この実施例において、衛星信号から現在の天体歴データがダウンロード（ステップ４３０）され、その衛星に対する正確なクロックが取得される。或いは他の実施例において、クロックは知ることができるが、座標軸（ｃｏｒｄｉｎａｔｅｓ）がもはや有効でない場合が考えられる。このダウンロードされた天体歴信号は、必要な座標軸をも提供し得る。これらの実施例において、ダウンロードされた天体歴から得られた必要な情報（ステップ４４０）は、軌道パラメータから抽出された有効なデータとマージされる（ステップ４１５）。そして、モバイルデバイスの位置情報を計算（ステップ４２０）するために、このコンビネーションが、利用される。
【００２４】
部分的な天体歴データが、記憶された軌道パラメータを補う実施例では、ほとんどの状況で、Ｆｉｒｓｔ  Ｆｉｘを生成するために、モバイルデバイスは、ブロードキャストされた天体歴の全てを受信する必要はない。理解できるように、ブロードキャストされた天体歴の全部は、独立したフレームの連続から構成される。このようなフレームは、特定の情報を含んでおり、受信に約６秒を必要とする。したがって、通常の遅延で、全ての天体歴を受信することによって、通常Ｆｉｒｓｔ  Ｆｉｘを約３０秒以上遅延させることとなる。しかしながら、この実施例では、特定の一部の情報のみが要求されるため、この特定の情報を含むフレームが受信されるとすぐに、モバイルデバイスは、迅速にＦｉｒｓｔ  Ｆｉｘを生成するよう復帰（ｒｅｔｕｒｎ）し、ブロードキャストされた天体歴の残りの部分の受信を待たない。これによって、ＴＩＦＦの平均より１５秒早めることができ、そして、最大で２５秒早める。これは、ユーザからみると、大いに改善していることとなる。
【００２５】
図５は、記憶された軌道パラメータ（ステップ５１５）から抽出されたデータを補うために利用されるブロードキャストされた天体歴データの部分的サブフレームのフローチャート５００を示している。図５において、ステップ５３２で、現在の天体歴データが衛星からダウンロードされる。モバイルデバイスは、既に受信した部分的サブフレームが、必要な特定のデータを含んでいるかをチェックする（ステップ５３５）。もしそうであれば、ステップ５２０において、部分的サブフレーム内のその特定のデータ、及び記憶された軌道パラメータから軌道データを計算する。この計算されたデータは、完全性及び有効性がチェックされる。この計算されたデータが完全でなくかつ有効でもない場合、ステップ５５０は、ステップ５３２に戻る。ステップ５３２では、天体歴データの次の部分的サブフレームが受信される。この計算されたデータが、完全であり、かつ有効である場合、ステップ５２８は、ダウンロードされたデータから単独で延長されたデータ、及びステップ５２０で結合された軌道パラメータを抽出する。単独で延長されたデータ（ｓｅｌｆ−ｅｘｔｅｎｄｅｄ  ｄａｔａ）は、再び完全性及び有効性がチェックされる。何れの条件も肯定的であれば、ステップ５６０において、完全で有効なデータを利用して、衛星の位置を決定する。これは、その後、モバイルデバイスの位置を決定するために利用される。ステップ５５５は、フローチャート５００への入り口（ｅｎｔｒｙ  ｐｏｉｎｔ）として認識することができる。ここで、単独で抽出されたデータ（ｓｅｌｆ−ｅｘｔｒａｃｔｅｄ  ｄａｔａ）が有効である場合、位置は、迅速に決定される。しかしながら、単独で抽出されたデータが有効でない場合、ステップ５２８から、新たな単独で抽出されたデータが取得される。一つの実施例において、サブフレームは、ナビゲーションメッセージサブフレームを含む。これは、インターフェース制御ドキュメント（Ｉｎｔｅｒｆａｃｅ  Ｃｏｎｔｒｏｌ  Ｄｏｃｕｍｅｎｔ）（例えば、ＩＣＤ−ＧＰＳ−２００，  Ｇｌｏｎａｓｓ  ＩＣＤ，  Ｇａｌｉｌｅｏ  ＯＳ  ＳＩＳ  ＩＣＤ，  ｏｒ  ＱＺＳＳ  ＩＣＤ等）に定義されている。
【００２６】
図６は、本願明細書において開示される実施例の用途に適したＧＮＳＳデバイス６００の例を示している。デバイス６００は、衛星及び／又はモバイルデバイス位置を決定するためのＧＮＳＳモジュール６１０を有する。ＣＰＵ  ６２０がＧＮＳＳモジュール６１０に接続される。ＣＰＵ６２は、モバイルデバイス６００を制御し、かつメモリ６３０に記憶されたコンピュータコード６４０を実行する。記憶されたコンピュータコード６４０は、軌道パラメータを含む生成されたモデルを含んでもよい。また、本願明細書において詳述される各々の実施例に特有のコンピュータコードを含んでもよい。
【００２７】
要約すると、ＴＴＦＦの改善された方法が開示される。データモデルが構築される。そして、位置決定（ｐｏｓｉｔｉｏｎ  ｆｉｘ）のためにブロードキャストされた天体暦を受信することなく、軌道データの生成を可能とする。変更され得るパラメータを含むデータモデルがモバイルデバイスに記憶される。モバイルデバイスのＧＮＳＳシステムで、位置決定が必要な場合、ブロードキャストされた天体歴へのアクセスやネットワークへの接続を要求することなく、正確な衛星軌道データモデルを迅速に生成するために、これらの軌道パラメータが利用される。これによって、有効な期間の延長を提供しつつＴＩＦＦを加速することができる。
【００２８】
当業者であれば、本発明の説明に基づいて、デバイス及び方法についての、多くの変形例及び変更を考えることが可能であろう。したがって、上述の開示は、添付の請求項のみによって限定され得る。
【図１】
2013522607.tif 000003
【図２】
2013522607.tif 000004
【図３】
2013522607.tif 000005
【図４】
2013522607.tif 000006
【図５】
2013522607.tif 000007
【図６】
2013522607.tif 000008
【国際調査報告】
2013522607.tif 000009
2013522607.tif 000010