"地球航法衛星システムのための位置検出方法であって:モバイルデバイスの、衛星の軌道及び/又はクロックデータのモデルの少なくとも1つの係数をアップデートするステップであって、前記モデルは軌道パラメータを含む、ステップと;前記モバイルデバイスによって、前記記憶された軌道パラメータから衛星軌道情報を抽出するステップと;前記モバイルデバイスによって、前記抽出された衛星軌道情報に基づいて、前記衛星の位置を決定するステップと;前記決定された衛星の位置とクロックデータとに従って、前記モバイルデバイスの位置を決定するステップと;を有する方法。請求項1記載の方法であって、前記モデルを生成するために、力モデルが利用される、方法。請求項1記載の方法であって、前記軌道パラメータは、係数を含む、方法。請求項1記載の方法であって、前記軌道パラメータは、多項式を形成する、方法。請求項1記載の方法であって、前記モデルは、天体歴又は歴の基準を参照するエラー訂正項を含む、方法。請求項1記載の方法であって、前記少なくとも1つの係数をアップデートするステップは、前記衛星軌道データの変更を反映させるために、前記少なくとも1つの前記係数を周期的にアップデートするステップ、を含む方法。請求項6記載の方法であって、前記モバイルデバイスは、アップデートされた係数を計算するステップ、を更に有する方法。請求項1記載の方法であって:特定の衛星軌道データを含む、少なくとも天体歴データのサブフレームをダウンロードするステップと;前記抽出された衛星軌道情報と、前記ダウンロードされた特定の衛星軌道データと、に基づいて前記衛星の位置を決定するステップと;を有する方法。地球航法衛星システムにおいて利用されるモバイルデバイスであって:地球航法衛星システムに従って、当該モバイルデバイスの位置を決定するための地球航法衛星システムモジュールと;前記地球航法衛星システムモジュール及びメモリに接続された中央処理ユニットと;を有し、前記メモリは:軌道パラメータを含む、衛星の軌道及び/又はクロックデータの、モデルと;コンピュータコードであって、前記中央処理ユニットで実行されたときに、前記モデルの少なくとも1つの係数をアップデートし、前記メモリに記憶された前記軌道パラメータから、衛星軌道情報を抽出し、前記抽出された衛星軌道情報に基づいて前記衛星の位置を決定し、かつ前記決定された衛星の位置に従って当該モバイルデバイスの位置を決定する、コンピュータコードと;を含む、モバイルデバイス。請求項9記載のモバイルデバイスであって、前記メモリは、コンピュータコードであって、前記中央処理ユニットで実行されたときに、前記衛星軌道データの変更を反映させるために、前記少なくとも1つの前記係数を周期的にアップデートする、コンピュータコードを更に含む、モバイルデバイス。請求項9記載のモバイルデバイスであって、前記メモリは、コンピュータコードであって、中央処理ユニットによって実行されたときに、特定の衛星軌道データを含む、天体歴データの少なくともサブフレームをダウンロードし、前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて、前記衛星の位置を決定する、コンピュータコード、を更に含む、モバイルデバイス。地球航法衛星システムのための位置検出方法であって:衛星の軌道及び/又はクロックデータのモデルを、モバイルデバイスに記憶するステップであって、前記モデルは軌道パラメータを含む、ステップと;前記記憶された軌道パラメータから、衛星軌道情報を抽出するステップと;特定の衛星軌道データを含む、天体歴データの少なくともサブフレームをダウンロードするステップと;前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて、衛星の位置を決定するステップと;前記決定された衛星の位置に従って、前記モバイルデバイスの位置を決定するステップと;を有する方法。請求項12記載の方法であって、前記サブフレームは、ナビゲーションメッセージサブフレームを含む、方法。地球航法衛星システムにおいて利用されるモバイルデバイスであって、地球航法衛星システムに従って、当該モバイルデバイスの位置を決定するための地球航法衛星システムモジュールと;前記地球航法衛星システムモジュール及びメモリに接続された中央処理ユニットと;を有し、前記メモリは:軌道パラメータを含む、衛星の軌道及び/又はクロックデータの、モデルと;コンピュータコードであって、前記中央処理ユニットで実行されたときに、前記メモリに記憶された前記軌道パラメータから、衛星軌道情報を抽出し、特定の衛星軌道データを含む、天体歴データの少なくともサブフレームをダウンロードし、前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて前記衛星の位置を決定し、かつ前記決定された衛星の位置に従って、当該モバイルデバイスの位置を決定する、コンピュータコードと;を含む、モバイルデバイス。請求項14記載のモバイルデバイスであって、前記サブフレームは、ナビゲーションメッセージサブフレームを含む、モバイルデバイス。TTFFの課題への第2の幅広いアプローチは、将来に渡り、その延長された期間におけるGNSS軌道データをモバイル受信器に連続的にサーバが提供することである。この解決案は、リモートレシーバが、サーバと、連続的に、又は少なくとも頻繁な接続を行うことを必要とし、リモートレシーバ上に十分なデータ記憶容量を持つことを必要とする。地球航法衛星システムのための位置検出方法が開示されている。衛星の軌道及び/又はクロックデータのモデルが、モバイル機器に記憶される。そして、生成されたモデルは軌道パラメータを含み、これらは変更可能であり、又はアップデートされ得る。最初の修正を取得するために、モバイル機器は、記憶された軌道モデルから衛星軌道情報を抽出し、かつ抽出された衛星軌道情報に基づいて、衛星の位置を決定する。衛星の位置を知ると、モバイル機器の位置を決定することができる。地球航法衛星システムのための位置検出方法が更に開示されている。方法は、特定の衛星軌道データを含む天体歴データの少なくともサブフレームをダウンロードするステップと、前記抽出された衛星軌道情報及び前記ダウンロードされた特定の衛星軌道データに基づいて衛星の位置を決定するステップと、を更に有する。地球航法衛星システムにおいて使用されるモバイル機器も開示される。モバイル機器は、地球航法衛星システムに従ってモバイル機器の位置を決定するための地球航法衛星システムモジュールと、地球航法衛星システムモジュール及びメモリに接続されたCPUとを含む。メモリは、衛星の軌道及び/又はクロックデータの軌道パラメータを含むモデルと、コンピュータコードとを有する。このパラメータは、変更可能であり又はアップデートされ得る。このコンピュータコードは、CPUによって実行されると、メモリに記憶された軌道パラメータから衛星軌道情報を抽出し、抽出された衛星軌道情報に基づいて衛星の位置を決定し、決定された衛星の位置及びクロックデータに従って、モバイルデバイスの最初の修正を決定する。本発明のこれらの、そしてまた他の目的は、さまざまな図及び図面において例示される以下の好ましい実施例の詳細な説明を読むことによって、当業者にとって明らかになることは明らかである。図1は、本開示の実施例に従って、衛星の信号を取得するために、軌道データを予測し、かつ、単独で延長された軌道データを用いる一般的なフローチャート10を示している。図1において、点線20特にステップ22、24、26及び28におけるステップは、速いTTFFのための軌道データを延長する1つの方法の例を示している。ステップ60に示すように、天体暦データを、システムにインポートすることができ、かつステップ55で、有効性のためのチェックがなされる。データが有効な場合、フローはステップ60へジャンプする。データがもはや有効でない場合、フローはステップ22へジャンプする。ステップ22ないし26において、衛星信号から受信される天体暦データは、短い期間の間延長することができ、かつメモリに記憶することができる。ステップ28において、記憶されたデータが抽出されチェックされる。ステップ30で、容認できる許容エラーに従って、全天体歴が利用できるか、及び有効であるかが確認される。抽出されたデータが完全ではなく、有効な場合、衛星の軌道が利用できないことを示すフラグをステップ40でセットしてもよい。抽出されたデータが完全で、かつ有効な場合、フローはステップ62、65、70、75、80及び85へジャンプする。最後に位置が決定される。図2は、本開示の一実施例に従った、軌道データ予測を示すフローチャート200を示している。この実施例において、軌道/クロックの記憶は、GNSSサーバに予め格納される。モデルは、軌道データを算出し/予測するための複数の係数を含む。モデルは、時間の関数であってもよい。位置決定が必要な場合、対応するタイミング情報が、モデルの中で代替され、予測された衛星軌道データが生成される。したがって、天体暦は、もはや位置決定のために必要な初期条件ではない。GNSSレシーバは、衛星、又は、外部サーバからの天体暦を受信することなく、記憶された軌道/クロックモデルを使用して、将来の軌道データを予測することができる。例えば、1つ以上のGNSS衛星に対して、所定の時間例えば、何ヶ月かの間、天体歴データを分析することによって、記憶された軌道/クロックモデルが、GNSSレシーバの外で確立生成される。そして、記憶された軌道/クロックモデルとして、衛星の軌道の傾向を示すことができるパラメータが、GNSSサーバにインストールされる。ステップ215における、この計算モデルは、いかなるタイプであってもよい。例えば、力モデルforcemodel、数値モデルnumericalmodelが挙げられる。そして、モデルは、必要に応じて、将来時点における、軌道及びクロックデータを取得するために利用できる。データモデルは、パワフルなサーバを使用して大量のデータ及び複雑なソフトウェアを参照することによって構築されるため、データモデルは非常に正確であり得る。データモデルは、将来の数週間、数ヶ月、或いは更に長期に渡り、エラー耐性errortolerancesがある。このようなデータモデルの1つの非限定的な例として、衛星軌道、及び/又はクロックデータは、変動次数の多項式polynomialofvaryingordersに変形reduceすることができる。各次数orderは、係数coefficientを持つ。実際の応用において、1つの及び/又はそれ以上の多項式polynomials又は、他のデータモデルが、衛星の軌道全体、及び/又は衛星の軌道の部分の各々をモデル化するために用いられてもよい例えば、ケプラーのパラメータ又は、可能であればX、Y、及びZパラメータの何れかが利用できる。そして、本発明は、これらに限定されるものではない。軌道及びクロックデータの正確な表現representationを、その衛星に提供するために、係数の大多数は、仮に決定される一部の実施例においては変更され得る。一旦受け入れられ得るデータモデルが生成されると、ステップ220に示すように、軌道パラメータはデータモデルから直接に算出することができる。これらの軌道パラメータは、適切な係数を含む多項式又は、適用された他の算出方法データモデルのためのベースを形成する。この例において、この多項式の予め定められた次数orderの一つ以上の係数の置換又は変更によって、解が得られたときに、対応した置換/変更された係数によって表現されたときに、その衛星に対する適度に正確な軌道及び/又はクロックデータを得ることができる。一旦モバイルデバイスがGNSSの機能を取得し、かつ軌道パラメータを取得しモバイルデバイス内に保存されると、FirstFix測位可能状態となるまでの時間を必要とし、適切な係数、例えば、おそらくは現在の時刻等が軌道パラメータに適用されるステップ228参照。この適切な係数の適用によって、衛星軌道データの抽出がなされ、これは、軌道パラメータによって推定されたものであり、情報を得るために、ホストシステムへのアクセス又は衛星信号を必要としないこととなる。この抽出された衛星軌道データは、ステップ230でその後チェックされる。すなわち、これが完全な天体歴データと等価なものとなっていること、及びこの抽出されたデータが依然として有効であることを確認するためにチェックされる。データの有効性は、許容できるエラー耐性、ステップ215で利用されるデータモデルのタイプ、及びその他の設計的考慮事項に従う。抽出されたデータが完全でかつ有効であるとみなされる場合、衛星の位置及び速度ステップ260は、ホストシステムからの又は衛生信号からの天体歴データの受信を待つことなく、抽出されたデータを利用することによって、決定することができる。これによって、TTFF測位可能状態となるまでの時間を非常に改善することができる。軌道パラメータは、多くの履歴データ及び、時間制約のほとんどない強力なソフトウェアを使用して算出することができるため、記憶された軌道パラメータから抽出された衛星軌道データの正確度及び有効性は、従来の方法に比して、大きく改善されることとなる。図3は、この種の抽出された衛星軌道データの単純な例を示している。図3において、6次多項式の軌道パラメータが使用されている。図示するように、この例で軌道パラメータから抽出されるデータは相応な100メートルのオーダーの誤差を発生させる。しかしながら、このレベルの誤差は受け入れられるエラー耐性の範囲内である。より長い期間の天体歴データ及び高次元の軌道パラメータは、ステップ215において生成される場合、簡単に実現でき、抽出されたデータの正確で有効な継続期間は、更に長くなり改善する。軌道/クロックモデルは、天体歴又は歴の基準referenceephemerisoralmanac、及び複数の係数を含む。そして、これは、特定の天体歴又は歴の基準を参照するエラー訂正項を記述している。換言すれば、衛星の基準天体歴及びエラーモデルは、モバイルデバイスに予め格納されてもよい。位置決定が必要な場合、推定されるエラーを計算するために、対応するタイミング情報がモデルの中で置き換えられ、推定された誤差を基準天体暦/歴と結合することによって、推定された衛星軌道データが生成される。したがって、天体暦は、位置決定のために必要な初期条件ではない。GNSSレシーバは、衛星、又は、外部サーバから天体暦を受信することなく、記憶モデルを使用して将来の軌道データを予測することができる。エラーの減少及び延長の増加を考慮し、以下の実施例は、エラーを補償するために、モバイルデバイス内に記憶された軌道パラメータを修正する能力を有する。権限を有するシステムauthoritiesにより軌道及びクロックが変更されるため、軌道の幾つかのバリエーション、及び多くの他のファクタ、軌道の裁量のパラメータでさえ、しばしば調整を行うことが必要になることがある。したがって、以下の実施例の各々では、記憶された軌道パラメータを修正する能力を有してもよい。この場合、係数をアップデートすることが好ましい。これらの新たなアップデートする係数は、適切なサーバに接続することによって取得してもよい。或いは、モバイルデバイスは、それ自身で係数をアップデートすることが可能であってもよい。係数の自己アップデートは、新たにダウンロードされた天体歴と、記憶された軌道パラメータから抽出されたデータとの差を計算することによって達成され得る。モバイルデバイスに記憶されたプログラムコード及び/又は計算規則が利用され得る。これによって、図2に示す全データモデル215を処理することを必要とせずに、周期的に、適切に係数をアップデートすることができる。1つ又は幾つかの係数だけを新たにアップデートすることも可能である。例えば、XYZパラメータが利用されていると仮定する。その午後しばらくして、X及びYの両者のパラメータは、エラー耐性の範囲内で推移しており、Zパラメータは、許容できる耐性の外に記録されると仮定する。この場合、記憶された軌道パラメータは、修正され得る。これは、置換又は修正を介して、抽出されたZパラメータが、許容できるエラーリミット内に戻される。これは、様々な方法で達成することができる。なお、Zパラメータに影響をしている適切な係数を単純に変更することでもよい。この修正アクションが採用された場合、特に、所定の衛星の軌道の変更が実行されたときに、インターネット又はワイヤレス接続を介して、新たな係数を取得し得る。或いは、モバイルデバイスは、そのようなエラーにトラッキングすることができ、そして、定義された規則又は計算に従って軌道パラメータを修正することによって、自身が修正アクションをとることができる。当業者であれば、デカルト座標系で示された上述のXYZパラメータは、天球座標システムで表現されたケプラーパラメータ、或いはその他の座標システムに拡張できることが理解できるであろう。より詳細な説明は、簡潔さを担保するために省略する。図4は、記憶された軌道パラメータを調整すること可能とする実施例のフローチャート400を示している。1つ以上の軌道パラメータから抽出されたほとんどのデータは、有効のままであるが、1つ以上の抽出されたデータが、定義されたエラー耐性を超えることがあり得る。例えば、所定の衛星のクロックが権利者によって変更された場合を想定する。抽出されたデータは、変更されたクロックとマッチしない。そして、正確な位置情報は、もはや取得することができない。この実施例において、衛星信号から現在の天体歴データがダウンロードステップ430され、その衛星に対する正確なクロックが取得される。或いは他の実施例において、クロックは知ることができるが、座標軸cordinatesがもはや有効でない場合が考えられる。このダウンロードされた天体歴信号は、必要な座標軸をも提供し得る。これらの実施例において、ダウンロードされた天体歴から得られた必要な情報ステップ440は、軌道パラメータから抽出された有効なデータとマージされるステップ415。そして、モバイルデバイスの位置情報を計算ステップ420するために、このコンビネーションが、利用される。部分的な天体歴データが、記憶された軌道パラメータを補う実施例では、ほとんどの状況で、FirstFixを生成するために、モバイルデバイスは、ブロードキャストされた天体歴の全てを受信する必要はない。理解できるように、ブロードキャストされた天体歴の全部は、独立したフレームの連続から構成される。このようなフレームは、特定の情報を含んでおり、受信に約6秒を必要とする。したがって、通常の遅延で、全ての天体歴を受信することによって、通常FirstFixを約30秒以上遅延させることとなる。しかしながら、この実施例では、特定の一部の情報のみが要求されるため、この特定の情報を含むフレームが受信されるとすぐに、モバイルデバイスは、迅速にFirstFixを生成するよう復帰returnし、ブロードキャストされた天体歴の残りの部分の受信を待たない。これによって、TIFFの平均より15秒早めることができ、そして、最大で25秒早める。これは、ユーザからみると、大いに改善していることとなる。図5は、記憶された軌道パラメータステップ515から抽出されたデータを補うために利用されるブロードキャストされた天体歴データの部分的サブフレームのフローチャート500を示している。図5において、ステップ532で、現在の天体歴データが衛星からダウンロードされる。モバイルデバイスは、既に受信した部分的サブフレームが、必要な特定のデータを含んでいるかをチェックするステップ535。もしそうであれば、ステップ520において、部分的サブフレーム内のその特定のデータ、及び記憶された軌道パラメータから軌道データを計算する。この計算されたデータは、完全性及び有効性がチェックされる。この計算されたデータが完全でなくかつ有効でもない場合、ステップ550は、ステップ532に戻る。ステップ532では、天体歴データの次の部分的サブフレームが受信される。この計算されたデータが、完全であり、かつ有効である場合、ステップ528は、ダウンロードされたデータから単独で延長されたデータ、及びステップ520で結合された軌道パラメータを抽出する。単独で延長されたデータself-extendeddataは、再び完全性及び有効性がチェックされる。何れの条件も肯定的であれば、ステップ560において、完全で有効なデータを利用して、衛星の位置を決定する。これは、その後、モバイルデバイスの位置を決定するために利用される。ステップ555は、フローチャート500への入り口entrypointとして認識することができる。ここで、単独で抽出されたデータself-extracteddataが有効である場合、位置は、迅速に決定される。しかしながら、単独で抽出されたデータが有効でない場合、ステップ528から、新たな単独で抽出されたデータが取得される。一つの実施例において、サブフレームは、ナビゲーションメッセージサブフレームを含む。これは、インターフェース制御ドキュメントInterfaceControlDocument例えば、ICD-GPS-200,GlonassICD,GalileoOSSISICD,orQZSSICD等に定義されている。図6は、本願明細書において開示される実施例の用途に適したGNSSデバイス600の例を示している。デバイス600は、衛星及び/又はモバイルデバイス位置を決定するためのGNSSモジュール610を有する。CPU620がGNSSモジュール610に接続される。CPU62は、モバイルデバイス600を制御し、かつメモリ630に記憶されたコンピュータコード640を実行する。記憶されたコンピュータコード640は、軌道パラメータを含む生成されたモデルを含んでもよい。また、本願明細書において詳述される各々の実施例に特有のコンピュータコードを含んでもよい。要約すると、TTFFの改善された方法が開示される。データモデルが構築される。そして、位置決定positionfixのためにブロードキャストされた天体暦を受信することなく、軌道データの生成を可能とする。変更され得るパラメータを含むデータモデルがモバイルデバイスに記憶される。モバイルデバイスのGNSSシステムで、位置決定が必要な場合、ブロードキャストされた天体歴へのアクセスやネットワークへの接続を要求することなく、正確な衛星軌道データモデルを迅速に生成するために、これらの軌道パラメータが利用される。これによって、有効な期間の延長を提供しつつTIFFを加速することができる。当業者であれば、本発明の説明に基づいて、デバイス及び方法についての、多くの変形例及び変更を考えることが可能であろう。したがって、上述の開示は、添付の請求項のみによって限定され得る。"