(57)【要約】地理的位置を求める受信装置１３０が開示される。受信装置１３０は、装置内の他のコンポーネントがローカル・ポートを使用して接続および通信することができるローカル・データ・サーバを提供するアプリケーション・レベル・プログラム２００を有する。ローカル・データ・サーバは、位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記ローカル・ポートを使用して装置内で提供するために前記データを第２の所定のフォーマットへと変換するよう構成されている。装置はさらに、衛星測位受信機と、前記受信機に関連した受信機プロトコル・モジュールであって、位置補助データを前記受信機に提供することのリクエストに応答して、前記ローカル・ポートを使用してローカル・データ・サーバに接続し、ローカル・データ・サーバからの前記位置補助データをリクエストし、前記位置補助データを第２の所定のフォーマットで受信し、前記位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換するよう構成された、受信機プロトコル・モジュールとを有する。 【選択図】図３
2016509672.tif 000002
【特許請求の範囲】
【請求項１】
装置であって、
位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを前記装置内での提供のために第２の所定のフォーマットへと変換するよう構成されたローカル・データ・サーバと；
衛星測位受信機と；
前記受信機に関連した受信機プロトコル・モジュールであって、位置補助データを前記受信機に提供することのリクエストに応答して、前記ローカル・データ・サーバからの前記位置補助データをリクエストし、前記位置補助データを前記第２の所定のフォーマットで受信し、前記位置補助データを前記衛星測位受信機に適した第３の所定のフォーマットへと変換するよう構成された、前記受信機プロトコル・モジュールと；
を有する装置。
【請求項２】
前記ローカル・データ・サーバは、位置補助データの、異なる複数の外部ソースに接続して、前記第２の所定のフォーマットへと変換される位置補助データのそれぞれ異なるセットを受信するよう構成される、請求項１に記載の装置。
【請求項３】
前記ローカル・データ・サーバは、例えばＴＣＰ／ＩＰなどのパケット交換接続を使用して、位置補助データの前記または各外部ソースに接続するよう構成される、請求項１または請求項２に記載の装置。
【請求項４】
前記ローカル・データ・サーバは、セルラ通信ネットワークを介して位置補助データの前記または各外部ソースに接続するよう構成される、請求項１から３のいずれかに記載の装置。
【請求項５】
前記ローカル・データ・サーバは、前記受信機プロトコル・モジュールから受信されたリクエストに応答して、前記位置補助データを取得するために、位置補助データの前記または各外部ソースに接続するよう構成される、請求項１から４のいずれかに記載の装置。
【請求項６】
前記ローカル・データ・サーバは、前記位置補助データを、記憶して後の時点で前記受信機プロトコル・モジュールに提供するために取得するべく、位置補助データの前記または各外部ソースに自動的かつ周期的に接続するよう構成される、請求項１から５のいずれかに記載の装置。
【請求項７】
前記ローカル・データ・サーバは、前記第２の所定のフォーマットへと変換される位置補助データの新規セットをもたらすために、位置補助データの前記異なるセットからのデータを組み合わせるよう構成される、請求項２または請求項２に従属するいずれかの請求項に記載の装置。
【請求項８】
前記ローカル・データ・サーバは、アプリケーション・レベル・プログラムとして提供される、請求項１から７のいずれかに記載の装置。
【請求項９】
前記ローカル・データ・サーバは、通信ネットワークを介して外部の位置から再構成可能または置き換え可能なように構成される、請求項８に記載の装置。
【請求項１０】
前記ローカル・データ・サーバは、位置補助データをリクエストするために前記受信機プロトコル・モジュールが接続するよう構成された関連するローカル・ポート・アドレスを有する、請求項１から９のいずれかに記載の装置。
【請求項１１】
前記ローカル・ポート・アドレスは、ローカルＩＰアドレスである、請求項１０に記載の装置。
【請求項１２】
前記ローカル・データ・サーバは、１つ以上の情報要素の形の前記位置補助データを非バイナリ符号化フォーマットで受信して前記要素（単数または複数）をバイナリ符号化フォーマットへと変換するよう構成される、請求項１から１１のいずれかに記載の装置。
【請求項１３】
前記非バイナリ符号化フォーマットは、例えばＸＭＬなどのマークアップ言語フォーマットである、請求項１２に記載の装置。
【請求項１４】
前記バイナリ符号化フォーマットは、例えばＡＳＮ．１などのＡＳＮフォーマットである、請求項１２または請求項１３に記載の装置。
【請求項１５】
前記ローカル・データ・サーバは、第１のスキーマに準拠する１つ以上の情報要素の形の位置補助データを受信して前記１つ以上の情報要素を第２のスキーマへと変換するよう構成される、請求項１から１４のいずれかに記載の装置。
【請求項１６】
前記ローカル・データ・サーバは、第１の事前定義済み通信プロトコルを使用して、位置補助データの前記または各外部ソースからの位置補助データをリクエストおよび受信するよう構成される、請求項１から１５のいずれかに記載の装置。
【請求項１７】
前記第１の事前定義済み通信プロトコルは、位置補助データの前記交換のための非標準の通信プロトコルである、請求項１６に記載の装置。
【請求項１８】
前記受信機プロトコル・モジュールは、前記第１の通信プロトコルとは異なる第２の事前定義済み通信プロトコルを使用して、前記ローカル・データ・サーバからの位置補助データをリクエストおよび受信するよう構成される、請求項１６または請求項１７に記載の装置。
【請求項１９】
前記第２の事前定義済み通信プロトコルは、位置補助データの前記交換のための標準の通信プロトコルである、請求項１８に記載の装置。
【請求項２０】
前記第２の事前定義済み通信プロトコルは、３ＧＰＰ  ＴＳ４４．０３１、３ＧＰＰ  ＴＳ２５．３３１、もしくは３ＧＰＰ  ＴＳ３６．３５５などの公開された３ＧＰＰ標準のうちの１つに準拠し、または前記第２の事前定義済み通信プロトコルは、ＯＭＡ  ＳＵＰＬ１．０もしくはＯＭＡ  ＬＰＰｅ  ｖ．１．０などの公開されたＯＭＡ標準のうちの１つに準拠する、請求項１９に記載の装置。
【請求項２１】
前記受信機プロトコル・モジュールは、前記位置補助データを、例えばＵＡＲＴ、Ｉ２Ｃ、またはＳＰＩインターフェースなどの物理インターフェースを介して前記衛星測位受信機に転送するために、下位信号へと変換するよう構成される、請求項１から２０のいずれかに記載の装置。
【請求項２２】
前記ローカル・データ・サーバは、第１のセキュリティ方法またはプロトコルを使用して位置補助データの前記または各外部ソースと通信し、別の第２のセキュリティ方法またはプロトコルを内部的に使用して前記受信機プロトコル・モジュールと通信するよう構成される、請求項１から２１のいずれかに記載の装置。
【請求項２３】
前記ローカル・データ・サーバは、前記組み合わされたセットを前記装置内で提供するために、前記外部ソースから受信された前記データには存在しない位置補助データのセットをローカルで生成するようさらに構成される、請求項１から２２のいずれかに記載の装置。
【請求項２４】
装置であって、
前記装置内の他のコンポーネントがローカル・ポートを使用して接続および通信することができるローカル・データ・サーバを提供するアプリケーション・レベル・プログラムであって、前記ローカル・データ・サーバは、位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記ローカル・ポートを使用して前記装置内で提供するために前記データを第２の所定のフォーマットへと変換するよう構成されている、前記アプリケーション・レベル・プログラムと；
衛星測位受信機と；
前記受信機に関連した受信機プロトコル・モジュールであって、位置補助データを前記受信機に提供することのリクエストに応答して、前記ローカル・ポートを使用して前記ローカル・データ・サーバに接続し、前記ローカル・データ・サーバからの前記位置補助データをリクエストし、前記位置補助データを前記第２の所定のフォーマットで受信し、前記位置補助データを前記衛星測位受信機に適した第３の所定のフォーマットへと変換するよう構成された、前記受信機プロトコル・モジュールと
を有する装置。
【請求項２５】
データ処理装置において、
（ｉ）位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを第２の所定のフォーマットへと変換することと；
（ｉｉ）位置補助データのリクエストに応答して、前記ローカル・データ・サーバからの位置補助データを前記第２の所定のフォーマットでリクエストおよび受信し、前記位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換し、前記変換された位置補助データを衛星測位受信機に提供することと
を含む方法。
【請求項２６】
（ｉ）は、位置補助データの、異なる複数の外部ソースに接続して、前記第２の所定のフォーマットへと変換される位置補助データのそれぞれ異なるセットを受信することをさらに含む、請求項２５に記載の方法。
【請求項２７】
（ｉ）は、ＴＣＰ／ＩＰ接続を使用して実行される、請求項２５または請求項２６に記載の方法。
【請求項２８】
（ｉ）は、セルラ通信ネットワークを介して実行される、請求項２５〜２７のいずれかに記載の方法。
【請求項２９】
（ｉ）は、後の時点で（ｉｉ）において使用する前記位置補助データを取得するために自動的かつ周期的に実行される、請求項２５〜２８のいずれかに記載の方法。
【請求項３０】
（ｉ）は、前記第２の所定のフォーマットへと変換される位置補助データの新規セットをもたらすために、位置補助データの前記異なるセットからのデータを組み合わせることをさらに含む、請求項２６または請求項２６に従属するいずれかの請求項に記載の方法。
【請求項３１】
（ｉ）は、ローカル・データ・サーバを提供するアプリケーション・レベル・プログラムによって実行される、請求項２５〜３０のいずれかに記載の方法。
【請求項３２】
通信ネットワークを介して外部の位置から前記ローカル・データ・サーバを配信、インストール、再構成し、かつ／または置き換えることをさらに含む、請求項３１に記載の方法。
【請求項３３】
（ｉｉ）は、例えばローカルＩＰアドレスなどの所定のローカル・ポート・アドレスを介して前記位置補助データをリクエストおよび受信することを含む、請求項２５〜３２のいずれかに記載の方法。
【請求項３４】
（ｉ）は、１つ以上の情報要素の形の前記位置補助データを非バイナリ符号化フォーマットで受信して前記要素（単数または複数）をバイナリ符号化フォーマットへと変換することを含む、請求項２５〜３３のいずれかに記載の方法。
【請求項３５】
前記非バイナリ符号化フォーマットは、例えばＸＭＬなどのマークアップ言語フォーマットである、請求項３４に記載の方法。
【請求項３６】
前記バイナリ符号化フォーマットは、例えばＡＳＮ．１などのＡＳＮフォーマットである、請求項３４または請求項３５に記載の方法。
【請求項３７】
（ｉ）は、第１のスキーマに準拠する１つ以上の情報要素の形の前記位置補助データを受信して前記要素（単数または複数）を第２のスキーマへと変換することを含む、請求項２５〜３６のいずれかに記載の方法。
【請求項３８】
（ｉ）は、第１の事前定義済み通信プロトコルを使用して、位置補助データの前記または各外部ソースからの位置補助データをリクエストおよび受信することを含む、請求項２５〜３７のいずれかに記載の方法。
【請求項３９】
前記第１の事前定義済み通信プロトコルは、位置補助データの前記交換のための非標準の通信プロトコルである、請求項３８に記載の方法。
【請求項４０】
（ｉｉ）は、前記第１の通信プロトコルとは異なる第２の事前定義済み通信プロトコルを使用して、前記ローカル・データ・サーバからの位置補助データをリクエストおよび受信することを含む、請求項３８または請求項３９に記載の方法。
【請求項４１】
前記第２の事前定義済み通信プロトコルは、位置補助データの前記交換のための標準の通信プロトコルである、請求項４０に記載の方法。
【請求項４２】
前記第２の事前定義済み通信プロトコルは、３ＧＰＰ  ＴＳ４４．０３１、３ＧＰＰ  ＴＳ２５．３３１、または３ＧＰＰ  ＴＳ３６．３５５などの公開された３ＧＰＰ標準のうちの１つに準拠する、請求項４１に記載の方法。
【請求項４３】
前記第２の事前定義済み通信プロトコルは、ＯＭＡ  ＳＵＰＬ１．０またはＯＭＡ  ＬＰＰｅ  ｖ．１．０などの公開されたＯＭＡ標準のうちの１つに準拠する、請求項４１に記載の方法。
【請求項４４】
（ｉｉ）は、前記位置補助データを、例えばＵＡＲＴ、Ｉ２Ｃ、またはＳＰＩインターフェースなどの物理インターフェースを介して前記衛星測位受信機に転送するために、下位信号へと変換することを含む、請求項２５〜４３のいずれかに記載の方法。
【請求項４５】
データの前記受信または提供は、ステップ（ｉ）において第１のセキュリティ方法またはプロトコルを使用して実行され、ステップ（ｉｉ）において別の第２のセキュリティ方法またはプロトコルを使用して実行される、請求項２５〜４４のいずれか１項に記載の方法。
【請求項４６】
ステップ（ｉ）は、前記外部ソースから受信された前記データには存在しない位置補助データのセットを前記ローカル・データ・サーバにてローカルで生成することをさらに含み、ステップ（ｉｉ）は、前記組み合わされたセットを前記ローカル・データ・サーバから受信することをさらに含む、請求項２５〜４５のいずれか１項に記載の方法。
【請求項４７】
コンピュータ装置によって実行されると請求項２５〜４６のいずれかに記載の方法を実行するよう前記コンピュータ装置を制御する命令を含む、コンピュータ・プログラム。
【請求項４８】
コンピュータ可読コードが記憶されている非一時的なコンピュータ可読記憶媒体であって、前記コンピュータ可読コードは、コンピューティング装置によって実行されると、前記コンピューティング装置に、
（ｉ）位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを第２の所定のフォーマットへと変換することと；
（ｉｉ）位置補助データのリクエストに応答して、前記ローカル・データ・サーバからの位置補助データを前記第２の所定のフォーマットでリクエストおよび受信し、前記位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換し、前記変換された位置補助データを衛星測位受信機に提供することと
を含む方法を実行させる、コンピュータ可読記憶媒体。
【請求項４９】
少なくとも１つのプロセッサと、コンピュータ可読コードが記憶されている少なくとも１つのメモリとを有する装置であって、前記コンピュータ可読コードは、実行されると、
位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを第２の所定のフォーマットへと変換し、さらに、
位置補助データのリクエストに応答して、前記ローカル・データ・サーバからの位置補助データを前記第２の所定のフォーマットでリクエストおよび受信し、前記位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換し、前記変換された位置補助データを衛星測位受信機に提供する、
ように前記少なくとも１つのプロセッサを制御する、前記装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、グローバル・ポジショニングのための補助データを処理することに関する。
【発明の背景】
【０００２】
補助データは、グローバル・ポジショニング・システム（ＧＰＳ：Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）または全地球航法衛星システム（ＧＮＳＳ：Ｇｌｏｂａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ）受信機などの衛星測位受信機が起動後に位置測定（ｌｏｃａｔｉｏｎ  ｆｉｘ）を迅速に提供するためには不可欠である。
【０００３】
典型的には、補助データは、基準位置（ｒｅｆｅｒｅｎｃｅ  ｌｏｃａｔｉｏｎ）、基準時刻（ｒｅｆｅｒｅｎｃｅ  ｔｉｍｅ）、ならびに衛星時計および軌道データを伝達する情報要素（ＩＥ：ｉｎｆｏｒｍａｔｉｏｎ  ｅｌｅｍｅｎｔ）のセットからなる。典型的には、衛星時計および軌道データを合わせてエフェメリス・データと呼ぶ。エフェメリス・データは、移動電話で利用可能な他の支援手段（セルラモデムからの基準周波数など）とともに、統合型ＧＰＳ受信機のパフォーマンスを増強・加速し、通常は、５メートル精度で５〜１０秒の初期位置算出時間（ＴＴＦＦ：ｔｉｍｅ  ｔｏ  ｆｉｒｓｔ  ｆｉｘ）を提供することができる。これと比較して、補助を用いないＧＰＳ受信機は、最適受信条件にあっても、３０〜４０秒未満で初期位置算出を提供することができない。
【０００４】
今日では、補助データおよびその配信メカニズムは、公開されたセルラ標準の一部を構成し、ＧＰＳおよびＧＮＳＳデータ要素のため、さらに結果としてはパフォーマンス改善のために、業界全体で承認されたフォーマットおよび方法を提供する。そのような公開された標準としては、３ＧＰＰ  ＴＳ４４．０３１、３ＧＰＰ  ＴＳ２５．３３１、ＯＭＡ  ＳＵＰＬ１．０が挙げられ、さらに近い将来、業界ではＯＭＡ  ＳＵＰＬ２．０、３ＧＰＰ  ＴＳ３６．３５５、およびＯＭＡ  ＬＰＰｅ  ｖ１．０が使用されるであろう。
【０００５】
さらに、独自の（ｐｒｏｐｒｉｅｔａｒｙ）補助データ・サービスおよびプロトコルも数多く存在する。典型的には、これらは特定の製造業者の、または特定の位置ベースサービスを伴うハードウェアにより提供され、かつ／またはそれと併せた使用に制限される。一例は、ノキアのＡ−ＧＮＳＳプロトコルである。こうしたサービスおよびプロトコルは、公開された標準のフォーマットおよびプロトコルに必ずしも従わないが、ＴＴＦＦおよび受信機感度の点で大幅なパフォーマンス改善をもたらすことができる。そのような独自サービスは現在、受信機の下位機能性に密接にリンクされているが、それが原因で、独自サービスに対する変更（または新たなものの開発）を行うには、一般に、ファームウェアに対するドライバ・レベルの変更および／または追加を要する。最悪の場合、受信機のアーキテクチャにより、新規サービスの統合が妨げられることも、新規サービスを使用した場合に深刻なパフォーマンス劣化を生じることもある。このことは、受信機のファームウェアまたはアーキテクチャに変更または新規機能性の一方または両方が必要な場合に、商品化までの時間を相当に引き延ばす原因となる。
【発明の概要】
【０００６】
本発明の第１の側面は、
位置補助データ（ｐｏｓｉｔｉｏｎ  ａｓｓｉｓｔａｎｃｅ  ｄａｔａ）の外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを装置内での提供のために第２の所定のフォーマットへと変換するよう構成されたローカル・データ・サーバと；
衛星測位受信機と；
前記受信機に関連した受信機プロトコル・モジュールであって、位置補助データを前記受信機に提供することのリクエストに応答して、ローカル・データ・サーバからの前記位置補助データをリクエストし、前記位置補助データを第２の所定のフォーマットで受信し、前記位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換するよう構成された、受信機プロトコル・モジュールと
を有する装置を提供する。
【０００７】
この意味での補助データは、次に限定はされないが、基準位置、基準時刻、ならびに衛星時計および軌道データのうちの１つ以上を含むことができる。後で説明するように、ローカル・データ・サーバは、外部ソース（単数または複数）から１つ以上のＩＥ（単数または複数）を受信するとともに、他の補助データをローカルで生成してもよい。例えば、ローカル・データ・サーバは、組み合わされた補助データを受信機プロトコル・モジュールに提供するために、外部ソースから軌道モデル・データをフェッチし、かつ基準位置をローカルで生成することができる。
【０００８】
ローカル・データ・サーバは、位置補助データの、異なる複数の外部ソースに接続して、第２の所定のフォーマットへと変換される位置補助データのそれぞれ異なるセットを受信するよう構成されてもよい。
【０００９】
ローカル・データ・サーバは、パケット交換接続を使用して位置補助データの該または各外部ソースに接続するよう構成されてもよい。この接続は、ＴＣＰ／ＩＰ接続であってもよい。
【００１０】
ローカル・データ・サーバは、受信機プロトコル・モジュールから受信されたリクエストに応答して、位置補助データを取得するために、位置補助データの該または各外部ソースに接続するよう構成されてもよい。
【００１１】
ローカル・データ・サーバは、セルラ通信ネットワークを介して位置補助データの該または各外部ソースに接続するよう構成されてもよい。
【００１２】
ローカル・データ・サーバは、位置補助データを、記憶して後の時点で受信機プロトコル・モジュールに提供するために取得するべく、位置補助データの該または各外部ソースに自動的かつ周期的に接続するよう構成されてもよい。
【００１３】
位置補助データの異なるセットが受信される場合、ローカル・データ・サーバは、第２の所定のフォーマットへと変換される位置補助データの新規セットをもたらすために、異なるセットからのデータを組み合わせるよう構成されてもよい。
【００１４】
ローカル・データ・サーバは、アプリケーション・レベル・プログラムとして提供されてもよい。ローカル・データ・サーバは、通信ネットワークを介して外部の位置からインストールされるよう、再構成可能なよう、かつ／または置き換え可能なように構成されてもよい。
【００１５】
ローカル・データ・サーバは、位置補助データをリクエストするために受信機プロトコル・モジュールが接続するよう構成された関連するローカル・ポート・アドレスを提供してもよい。ローカル・ポート・アドレスは、ローカルＩＰアドレスとすることもできる。
【００１６】
ローカル・データ・サーバは、１つ以上の情報要素の形の位置補助データを非バイナリ符号化フォーマットで受信してその要素（単数または複数）をバイナリ符号化フォーマットへと変換するよう構成されてもよい。非バイナリ符号化フォーマットは、例えば拡張可能なマークアップ言語（ＸＭＬ：ｅｘｔｅｎｓｉｂｌｅ  ｍａｒｋ−ｕｐ  ｌａｎｇｕａｇｅ）などのマークアップ言語フォーマットとすることもできる。バイナリ符号化フォーマットは、例えばＡＳＮ．１などのＡＳＮフォーマットとすることもできる。
【００１７】
ローカル・データ・サーバは、第１のスキーマに準拠する１つ以上の情報要素の形の位置補助データを受信して、その要素（単数または複数）を第２のスキーマへと変換するよう構成されてもよい。スキーマの例としては、次に限定はされないが、スケールファクタ、ワード長、およびデータ型が挙げられる。例えば、一方のスキーマは「ｉｎｔ１６」であるが、他方のスキーマは「ｉｎｔ３２」を定義してもよく、さらに／または一方のスキーマは「ｆｌｏａｔ」であるが、他方のスキーマは「ｄｏｕｂｌｅ」を定義してもよい。
【００１８】
ローカル・データ・サーバは、第１の事前定義済み通信プロトコルを使用して、位置補助データの該または各外部ソースからの位置補助データをリクエストおよび受信するよう構成されてもよい。第１の事前定義済み通信プロトコルは、位置補助データの交換のための非標準の通信プロトコルであってもよい。
【００１９】
受信機プロトコル・モジュールは、第１の通信プロトコルとは異なる第２の事前定義済み通信プロトコルを使用して、ローカル・データ・サーバからの位置補助データをリクエストおよび受信するよう構成されてもよい。第２の事前定義済み通信プロトコルは、位置補助データの交換のための標準の通信プロトコルであってもよい。例えば、第２の事前定義済み通信プロトコルは、３ＧＰＰ  ＴＳ４４．０３１、３ＧＰＰ  ＴＳ２５．３３１、もしくは３ＧＰＰ  ＴＳ３６．３５５などの公開された３ＧＰＰ標準のうちの１つに準拠してもよく、またはＯＭＡ  ＳＵＰＬ１．０もしくはＯＭＡ  ＬＰＰｅ  ｖ．１．０などの公開されたＯＭＡ標準のうちの１つに準拠してもよい。
【００２０】
受信機プロトコル・モジュールは、位置補助データを、例えばＵＡＲＴ、Ｉ２Ｃ、またはＳＰＩインターフェースなどの物理インターフェースを介して衛星測位受信機に転送するために、下位信号へと変換するよう構成されてもよい。
【００２１】
ローカル・データ・サーバは、第１のセキュリティ方法またはプロトコルを使用して位置補助データの該または各外部ソースと通信し、別の第２のセキュリティ方法またはプロトコルを内部的に使用して受信機プロトコル・モジュールと通信するよう構成されてもよい。
【００２２】
ローカル・データ・サーバは、組み合わされたセットを装置内で提供するために、外部ソースから受信されたデータには存在しない位置補助データのセットをローカルで生成するようさらに構成されてもよい。
【００２３】
本発明の第２の側面は、
装置内の他のコンポーネントがローカル・ポートを使用して接続および通信することができるローカル・データ・サーバを提供するアプリケーション・レベル・プログラムであって、ローカル・データ・サーバは、位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記ローカル・ポートを使用して装置内で提供するために前記データを第２の所定のフォーマットへと変換するよう構成されている、アプリケーション・レベル・プログラムと；
衛星測位受信機と；
前記受信機に関連した受信機プロトコル・モジュールであって、位置補助データを前記受信機に提供することのリクエストに応答して、前記ローカル・ポートを使用してローカル・データ・サーバに接続し、ローカル・データ・サーバからの前記位置補助データをリクエストし、前記位置補助データを第２の所定のフォーマットで受信し、前記位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換するよう構成された、受信機プロトコル・モジュールと
を有する装置を提供する。
【００２４】
本発明の第３の側面は、データ処理装置において、
（ｉ）位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを第２の所定のフォーマットへと変換することと；
（ｉｉ）位置補助データのリクエストに応答して、ローカル・データ・サーバからの位置補助データを第２の所定のフォーマットでリクエストおよび受信し、位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換し、変換された位置補助データを衛星測位受信機に提供することと
を含む方法を提供する。
【００２５】
（ｉ）は、位置補助データの、異なる複数の外部ソースに接続して、第２の所定のフォーマットへと変換される位置補助データのそれぞれ異なるセットを受信することをさらに含んでもよい。
【００２６】
（ｉ）は、ＴＣＰ／ＩＰ接続を使用して実行されてもよい。
【００２７】
（ｉ）は、セルラ通信ネットワークを介して実行されてもよい。
【００２８】
（ｉ）は、後の時点で（ｉｉ）において使用する位置補助データを取得するために自動的かつ周期的に実行されてもよい。
【００２９】
（ｉ）は、第２の所定のフォーマットへと変換される位置補助データの新規セットをもたらすために、位置補助データの異なるセットからのデータを組み合わせることをさらに含んでもよい。
【００３０】
（ｉ）は、ローカル・データ・サーバを提供するアプリケーション・レベル・プログラムによって実行されてもよい。
【００３１】
本方法は、通信ネットワークを介して外部の位置からローカル・データ・サーバを配信、インストール、再構成し、かつ／または置き換えることをさらに含んでもよい。
【００３２】
（ｉｉ）は、例えばローカルＩＰアドレスなどの所定のローカル・ポート・アドレスを介して位置補助データをリクエストおよび受信することを含んでもよい。
【００３３】
（ｉ）は、１つ以上の情報要素の形の位置補助データを非バイナリ符号化フォーマットで受信してその要素（単数または複数）をバイナリ符号化フォーマットへと変換することを含んでもよい。
【００３４】
非バイナリ符号化フォーマットは、例えばＸＭＬなどのマークアップ言語フォーマットとすることもできる。
【００３５】
バイナリ符号化フォーマットは、例えばＡＳＮ．１などのＡＳＮフォーマットとすることもできる。
【００３６】
（ｉ）は、第１のスキーマに準拠する１つ以上の情報要素の形の位置補助データを受信してその要素（単数または複数）を第２のスキーマへと変換することを含んでもよい。
【００３７】
（ｉ）は、第１の事前定義済み通信プロトコルを使用して、位置補助データの該または各外部ソースからの位置補助データをリクエストおよび受信することを含んでもよい。
【００３８】
第１の事前定義済み通信プロトコルは、位置補助データの交換のための非標準の通信プロトコルであってもよい。
【００３９】
（ｉｉ）は、第１の通信プロトコルとは異なる第２の事前定義済み通信プロトコルを使用して、ローカル・データ・サーバからの位置補助データをリクエストおよび受信することを含んでもよい。
【００４０】
第２の事前定義済み通信プロトコルは、位置補助データの交換のための標準の通信プロトコルであってもよい。
【００４１】
第２の事前定義済み通信プロトコルは、３ＧＰＰ  ＴＳ４４．０３１、３ＧＰＰ  ＴＳ２５．３３１、または３ＧＰＰ  ＴＳ３６．３５５などの公開された３ＧＰＰ標準のうちの１つに準拠してもよい。
【００４２】
第２の事前定義済み通信プロトコルは、ＯＭＡ  ＳＵＰＬ１．０またはＯＭＡ  ＬＰＰｅ  ｖ．１．０など、公開されたＯＭＡ標準のうちの１つに準拠する。
【００４３】
（ｉｉ）は、位置補助データを、例えばＵＡＲＴ、Ｉ２Ｃ、またはＳＰＩインターフェースなどの物理インターフェースを介して衛星測位受信機に転送するために、下位信号へと変換することを含んでもよい。
【００４４】
データの受信または提供は、ステップ（ｉ）において第１のセキュリティ方法またはプロトコルを使用して実行されてもよく、ステップ（ｉｉ）において別の第２のセキュリティ方法またはプロトコルを使用して実行されてもよい。
【００４５】
ステップ（ｉ）は、外部ソースから受信されたデータには存在しない位置補助データのセットをローカル・データ・サーバにてローカルで生成することをさらに含んでもよく、ステップ（ｉｉ）は、組み合わされたセットをローカル・データ・サーバから受信することをさらに含んでもよい。
【００４６】
本発明の第４の側面は、コンピュータ装置によって実行されると上記で定義した方法を実行するようコンピュータ装置を制御する命令を含むコンピュータ・プログラムを提供する。
【００４７】
本発明の第５の側面は、コンピュータ可読コードが記憶されている非一時的なコンピュータ可読記憶媒体を提供し、コンピュータ可読コードは、コンピューティング装置によって実行されると、コンピューティング装置に、
（ｉ）位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを第２の所定のフォーマットへと変換することと；
（ｉｉ）位置補助データのリクエストに応答して、ローカル・データ・サーバからの位置補助データを第２の所定のフォーマットでリクエストおよび受信し、位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換し、変換された位置補助データを衛星測位受信機に提供することと
を含む方法を実行させる。
【００４８】
本発明の第６の側面は、装置を提供し、装置は、少なくとも１つのプロセッサと、コンピュータ可読コードが記憶されている少なくとも１つのメモリとを有し、コンピュータ可読コードは、実行されると、
位置補助データの外部ソースに接続し、前記データを第１の所定のフォーマットで受信し、前記データを第２の所定のフォーマットへと変換し；さらに、
位置補助データのリクエストに応答して、ローカル・データ・サーバからの位置補助データを第２の所定のフォーマットでリクエストおよび受信し、位置補助データを衛星測位受信機に適した第３の所定のフォーマットへと変換し、変換された位置補助データを衛星測位受信機に提供するように該少なくとも１つのプロセッサを制御する。
【００４９】
以下、添付の図面を参照しながら、非限定的な例として本発明について記載する。
【図面の簡単な説明】
【００５０】
【図１】衛星測位システムである。
【図２】補助データを受信機に提供する従来技術のシステムの概要を示すブロック図である。
【図３】補助データを受信機に提供する第１の実施形態のシステムの概要を示すブロック図である。
【図４】補助データを受信機に提供する第２の実施形態のシステムを示すブロック図である。
【図５】図４に示した受信機内の特定の機能モジュールを示す概略図である。
【図６】図４および図５に示した受信機内のローカル・サーバの機能サブモジュールを示す概略図である。
【図７】図４〜図６の受信機内で発生する処理を示すフローチャートである。
【実施形態の詳細説明】
【００５１】
図１は、本発明の実施形態を理解するのに有用な衛星測位システム１の概要を示す。システム１は、地球を周回する衛星２、４、６のコンステレーションと、１つ以上の受信機１０と、サーバ１２の形の補助データ・ソースとを有する。
【００５２】
システム１は、グローバル・ポジショニング・システム（ＧＰＳ）、ＧＬＯＮＡＳＳ、ＧＡＬＩＬＥＯ、ＣＯＭＰＡＳＳ、ＳＢＡＳ（Ｓａｔｅｌｌｉｔｅ  Ｂａｓｅｄ  Ａｕｇｍｅｎｔａｔｉｏｎ  Ｓｙｓｔｅｍ：静止衛星型衛星航法補強システム）、ＱＺＳＳ（Ｑｕａｓｉ−Ｚｅｎｉｔｈ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ（準天頂衛星システム）、日本）、ＩＲＮＳＳ（Ｉｎｄｉａｎ  Ｒｅｇｉｏｎａｌ  Ｎａｖｉｇａｔｉｏｎ  Ｓａｔｅｌｌｉｔｅ  Ｓｙｓｔｅｍ（インド地域航法衛星システム）、インド）、またはその他衛星システムなど、世界的または地域的無線航法衛星システムであってもよい。これらシステムはそれぞれ、独立した衛星コンステレーションを有し、各衛星は、管理された軌道を有する。維持管理または軌道修正のための調整は、個々の衛星ごとに実施されることが多いが、必要に応じてコンステレーションの所有者または管理者により実施される。
【００５３】
序文で論じたように、受信機１０にて迅速なＴＴＦＦを実現するために、サーバ（単数または複数）１２では、衛星２、４、６から受信される情報を使用して補助データが生成される。補助データは、受信機１０によりリクエストされると、データ・ネットワーク１４を介して受信機へ送信される。典型的には、補助データは、基準位置、基準時刻、ならびにエフェメリス・データ、すなわち衛星時計および軌道データを伝達する情報要素（ＩＥ）の形をとる。説明を容易にするために、以下、補助データＩＥを単にＩＥと呼ぶ。
【００５４】
図２は、標準のプロトコルを使用してＩＥを交換する従来技術のシステムを示す概略図である。受信機２０は、例えば受信機２０で実行されるナビゲーション・アプリケーションがオンにされると、ＴＣＰ／ＩＰを使用してＧＰＲＳ、３Ｇ、または４Ｇネットワークなどのセルラ通信ネットワークを介して、サーバ２２からのＩＥをリクエストおよび受信するよう構成される。ＩＥのフォーマット、およびＩＥの交換に用いられるプロトコルは、公開された標準に準拠し、標準とはこの事例ではＳＵＰＬ１．０  Ａ−ＧＰＳ（ＳＵＰＬ１．０）である。
【００５５】
受信機２０には、ＳＵＰＬプロトコル・モジュール２４およびＧＰＳ／ＧＮＳＳ受信機モジュール２６が提供される。受信機モジュール２６は、ＧＰＳ受信機アンテナ、チップセット、およびファームウェアを有する。ＳＵＰＬプロトコル・モジュール２４は、通常、受信機のオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ）に組み込まれ、アプリケーション・プログラミング・インターフェース（ＡＰＩ：Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を提供し、それにより、ＵＡＲＴ、Ｉ２Ｃ、またはＳＰＩなどの物理インターフェースを使用して受信機モジュールとの間でデータを下位信号として転送することができる。ＳＵＰＬプロトコル・モジュール２４は、ＳＵＰＬ標準を使用してサーバ２２から受信されたＩＥを、受信機モジュール２６に入力（ｉｎｊｅｃｔｉｏｎ）するために要求される下位信号に変換するよう構成される。実際には、両モジュール２４、２６は同じベンダにより提供される。
【００５６】
図３は、本発明の第１の実施形態による、補助データＩＥを受信するシステムを示す概略図である。図２と同様に、受信機３０と、ＩＥを生成して受信機へ送信するサーバ３２とがある。しかし、本事例では、サーバ３２は、独自の補助データ・サービスを生成し提供するベンダＡに関連しており、該データ・サービスには、標準のものであるＳＵＰＬ１．０とは諸側面が異なる独自のフォーマットおよび／または通信プロトコルを使用したＩＥの伝播が含まれる。独自フォーマットの一例は、ノキアのＡ−ＧＮＳＳプロトコルである。ほかに、クアルコム社（Ｑｕａｌｃｏｍｍ  Ｉｎｃ．）のｇｐｓＯｎｅＸＴＲＡおよびＲｘネットワーク社（Ｒｘ  Ｎｅｔｗｏｒｋ  Ｉｎｃ．）のＰＧＰＳサービスがある。
【００５７】
ＳＵＰＬプロトコル・モジュール３４およびＧＰＳ／ＧＮＳＳ受信機モジュール３６が受信機３０内に提供される。これらは、図２を参照して説明したものと同じものとすることができ、したがって、標準のプロトコルを使用してＩＥをリクエストおよび受信するのに適している。一方、図３の実施形態ではさらに、ローカルＳＵＰＬサーバおよび独自プロトコル・モジュール３８（以下、単に「ローカル・サーバ」）が提供される。これは、ハードウェア、ファームウェア、またはＯＳ内のＳＵＰＬプロトコル・モジュール３４に（ポート・アドレスの軽微な変更以外には）何らの変更もせずにアップロード、インストール、および更新することができるアプリケーション・レベルのプログラムとすることが好ましい。ローカル・サーバ３８は、独自プロトコルを使用してベンダＡのサーバ３２からのＩＥをリクエストし、ＩＥを独自フォーマットで受信し、そのＩＥを、例えばＳＵＰＬ１．０標準など、適切な別フォーマットに変換するよう構成される。
【００５８】
ＳＵＰＬプロトコル・モジュール３４は、図２の場合のように補助データの外部ソースと通信はせずに、ローカルＩＰポートまたはＵＲＬアドレスを介してローカル・サーバ３８と通信するよう、単純なソフトウェア修正により構成される。ＳＵＰＬプロトコル・モジュール３４は、受信機モジュール３６に転送するために、通常の方法で、ＳＵＰＬ１．０プロトコルを使用してＳＵＰＬ１．０フォーマットのＩＥを受信する。
【００５９】
有利なことに、ファームウェアおよび／またはＡＰＩ構成の点で相互に密接に関連し合う傾向にあるＳＵＰＬプロトコルおよび受信機モジュール３４、３６は、新規の独自プロトコルおよび／またはデータ・フォーマットに応じるために修正される必要がない。ＳＵＰＬプロトコル・モジュール３４とＩＥの外部ソース３２との間に位置するローカル・サーバ３８を提供することによって、アーキテクチャの変更、ファームウェアの変更、および／またはそのような変更の実装に伴う大量のテストを要さずに、新規のプロトコルおよびフォーマットを容易に実装することができる。必要とされるのは、外部サーバではなくローカル・サーバ３８に接続するようにＯＳ内のＳＵＰＬプロトコル・モジュール３４のポート設定を変更することのみである。
【００６０】
他の実施形態では、受信機３０は、補助データの異なる複数の外部ソース（サーバ）からのＩＥをリクエストするよう構成される。これら外部ソースには、独自ナビゲーション・サービスおよび／または異なる独自および標準サービスの組み合わせの、複数のベンダが含まれ得る。受信機３０は、ローカル・サーバ３８を使用して、種々のソースから受信されたデータを組み合わせて、標準の、例えばＳＵＰＬ１．０プロトコルおよび／またはフォーマットに準拠するＩＥを作成するよう構成可能である。
【００６１】
ローカル・サーバ３８と標準のプロトコル・モジュール３４との間で使用される標準のフォーマットおよびプロトコルの例としてＳＵＰＬ１．０を挙げたが、当然のことながら、後のプロトコルおよび受信機段階３４、３６により使用される標準次第で、序文で列挙したものを含む他の標準のフォーマットおよびプロトコルがローカル・サーバ３８において規定され得る。
【００６２】
以下、システム１００のブロック図である図４を参照して、より詳細な第２の実施形態について記載する。システム１００は、補助データを収集、作成、配送、および使用する能力を備える。
【００６３】
システム１００は、衛星システム１０４を備える。図１を参照して上述したように、衛星システム１０４は、任意のタイプの衛星システムとすることができる。
【００６４】
衛星システム１０４は、ナビゲーション・データ（エフェメリス・データ、アルマナック・データ、電離層モデル、ＵＴＣモデル）またはその他の衛星測位データを、衛星リンクを介して提供する。このナビゲーション・データは、衛星システム１０４から独立して作成されたエフェメリス拡張データ・ファイルと組み合わされ、受信機と呼ばれることもあるワイヤレス受信デバイス１３０のパフォーマンスを向上させるために使用することができる。一部の実施形態では、例えば劣悪な信号条件が理由で受信機が衛星からナビゲーション・データを受信できない場合などに、エフェメリス拡張データ・ファイルをそれ自体として測位目的に使用して、完全にブロードキャスト・エフェメリスの代わりとすることもできる。
【００６５】
以下の開示は、例示のシステムとしてＧＰＳを使用するが、当業者には、他の衛星測位システムおよびそのコンステレーションに関連して本発明を実践する方法が分かるであろう。
【００６６】
ＧＰＳ追跡局のネットワーク１０２が、エフェメリス・データＩＥなど、受信機におけるパフォーマンス向上に関連した必要なあらゆるＩＥを含むデータを、軌道を周回するＧＰＳ衛星１０４から収集するために使用される。ネットワーク１０２は、地理的に離れたいくつかの追跡局を有してもよく、この追跡局それぞれが、コンステレーション中の複数の衛星から衛星データおよび測定値を収集する。
【００６７】
サーバ１０８がネットワーク１０２に接続される。サーバ１０８は、独自のデータ・フォーマットおよび／または方法を使用して、ネットワーク１０２により提供されるデータおよび測定値を収集して処理する。
【００６８】
衛星測定値は、サポートされる信号および周波数それぞれについて、コード位相測定値、搬送波位相測定値、およびドップラー測定値を含むことができる。衛星データは、エフェメリス・データ（時計および軌道の両方）と、アルマナック・データと、電離層モデルと、ＵＴＣモデルと、衛星ヘルス情報と、電離層および／または対流圏の地域モデルと、生ナビゲーション・データ・ブロードキャストと、衛星信号、ペイロード、またはサービスの完全性に関するデータとを含むことができる。一部の実施形態では、衛星測定値およびデータは、ＧＰＳ衛星１０４が送信を行うＬ１およびＬ２の両周波数ならびにすべての関連信号（例えばＬ１ＣＡ、Ｌ１Ｃ、Ｌ２Ｃ）から取得される。他の実施形態は、これら周波数のうちの１つのみ、および／または他の衛星システムもしくは将来のバージョンのＧＰＳシステムにより使用される他の周波数を使用してもよい。
【００６９】
サーバ１０８は、プロセッサ１１０およびメモリ１１２を含むいくつかのコンポーネントを有する。プロセッサ１１０は、メモリ１１２と双方向接続される。メモリ１１２は、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ  ｏｎｌｙ  ｍｅｍｏｒｙ）、ハードディスク・ドライブ（ＨＤＤ：ｈａｒｄ  ｄｉｓｋ  ｄｒｉｖｅ）、またはソリッド・ステート・ドライブ（ＳＳＤ：ｓｏｌｉｄ  ｓｔａｔｅ  ｄｒｉｖｅ）などの不揮発性メモリとしてもよい。メモリ１１２は、特に、オペレーティング・システム１２２、独自符号化モジュール１２４、補助データ計算ソフトウェア１２６、および例えばエフェメリス・データセットなどのデータセットが記憶される補助データＩＥデータベース１２８を記憶する。サーバ１０８は、ネットワーク１１８と通信するためのインターフェース１１６を備える。インターフェース１１６は、ＲＦインターフェース、別のワイヤレス・インターフェース、または有線インターフェースとされてもよい。ネットワーク１１８は、インターネット、ローカル・エリア・ネットワーク、または電話ネットワークなどのパケット・ネットワークとされてもよい。ランダム・アクセス・メモリ（ＲＡＭ：Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１２０の形の揮発性メモリが、プロセッサ１１０に接続される。ＲＡＭ１２０は、メモリ１１２に記憶されたソフトウェアの実行時、データの一時記憶のためにプロセッサ１１０によって使用される。オペレーティング・システム１２２は、ＲＡＭ１２０と連携してプロセッサ１１０により実行されるとサーバ１０８の各ハードウェア・コンポーネントの動作を制御する、コードを含む。
【００７０】
補助データ計算モジュール１２６は、例えば物理データを使用して７日間もしくは１４日間またはさらに長期のエフェメリス拡張ファイルを生成することにより、必要に応じて補助データを収集および計算するよう構成される。独自符号化モジュール１２４は、ＩＥを独自フォーマットに符号化するよう構成され、この独自フォーマットは、例えばＸＭＬなどのマークアップ・フォーマットなど、補助データに関する特定のスキーマおよびファイル・フォーマットを指定する。このモジュール１２４はさらに、独自ＩＥがインターフェース１１４を使用して転送される独自プロトコルを指定する。これは、例えば、データ転送速度の指定を含んでもよい。
【００７１】
独自フォーマットのＩＥは、インターフェース１１４を介した伝播のためにＩＥデータベース１２８に記憶され、メモリ１１２内の制御ソフトウェアにより命令されると、そのとおりに更新され、かつ／または置き換えられる。
【００７２】
システム１００はさらに、受信機１３０を備える。受信機１３０は、移動電話、ハンドヘルド・ナビゲーション・システム、デジタル・カメラ、または自動車安全システムなどの組み込み型ナビゲーション・システムとすることもできる。ＧＰＳ信号は、ＧＰＳデコーダ／受信機１４８を用いて復号される。受信機１３０は、そのＧＰＳアンテナ１３２およびＧＰＳデコーダ／受信機１４８を介して、ライブテレメトリ、エフェメリス・データ、およびアルマナック・データを衛星システム１０４から受信することができる。受信機１３０はさらに、例えば組み込み型システムにおいて受信機に提供されるそのＲＦインターフェースまたは通信ポート１３４を介して、ネットワーク１１８上でサーバ・リクエストを送信すること、およびサーバ１０８のＩＥデータベース１２８に記憶されているエフェメリス拡張ファイルなどの補助データＩＥを受信することができる。
【００７３】
受信機１３０は、ディスプレイ１３６、プロセッサ１３８、およびメモリ１４０を備える。プロセッサ１３８は、ＲＡＭ１４２の形の揮発性メモリに接続される。プロセッサ１３８は、メモリ１４０と双方向接続される。メモリ１４０内には、特に、オペレーティング・システム１４２、ソフトウェア１４４、衛星捕捉／追跡ソフトウェア１４６（例えばＧＰＳナビゲーション・システム）、およびサーバ１０８から受信された補助データＩＥ１５０が記憶されている。オペレーティング・システム１４２は、ＲＡＭ１４２と連携してプロセッサ１３８により実行されると受信機１３０の各ハードウェア・コンポーネントの動作を制御する、コードを含む。
【００７４】
ＧＰＳデコーダ／受信機１４８は、衛星１０４からＧＰＳ信号を受信して位置計算を行うためのハードウェア・チップセットおよび関連ファームウェア／ソフトウェアを有し、この位置計算は、補助データＩＥの使用を伴うこともある。
【００７５】
ＧＰＳデコーダ／受信機１４８に関連するＳＵＰＬ１．０プロトコル・モジュールは、ＯＳ１４２に統合され、下位信号を使用し物理インターフェースを介してデコーダ／受信機と通信する。
【００７６】
ソフトウェア１４４は、ローカルＳＵＰＬサーバおよび独自プロトコル・モジュール（以下単に「ローカルＳＵＰＬサーバ」）であるアプリケーション・レベルのプログラムを含む。
【００７７】
図５は、外部サーバ１０８からのＩＥをリクエストおよび受信するのに関与する受信機１３０内の様々なモジュールの論理構成を示すブロック図である。ＧＰＳデコーダ／受信機１４８は、ＳＵＰＬ１．０プロトコル１９８を使用してサーバに対して行われたリクエストに基づき、例えばＵＡＲＴ、Ｉ２Ｃ、またはＳＰＩを使用し物理ポートを介してＩＥを交換するためのハードウェアおよびファームウェアを備える。ここでのこの「サーバ」とは、外部サーバではなく、メモリ１４０に記憶され、例えば１２７．０．０．１（ローカルホスト）などのローカル・ポート・アドレスを有する、ローカルＳＵＰＬサーバ２００である。ＯＳ１４２に組み込まれたＳＵＰＬプロトコル・モジュール１９８は、このローカル・ポート・アドレスに接続するよう構成されており、その後、ＳＵＰＬ１．０プロトコルおよびデータ・フォーマットを使用しＴＣＰ／ＩＰリンクを介してリクエストが行われ、データが受信される。
【００７８】
図６を参照する。ローカルＳＵＰＬサーバ２００は、上述のローカル・ポート２０２、独自−ＳＵＰＬ変換モジュール２０４、および制御モジュール２０６を有する。制御モジュール２０６は、データ転送の論理順序と、例えばサーバ１０８および／またはその他独自サーバのアドレスなど、ＩＥのリクエスト先であり、ＩＥを送信する外部サーバのアドレス（単数または複数）とを制御するためのソフトウェアを有する。独自−ＳＵＰＬ変換モジュール２０４は、サーバ１０８から受信されたデータをＳＵＰＬ１．０フォーマットに変換またはマッピングし、それを、ＳＵＰＬ１．０プロトコルを使用してＳＵＰＬプロトコル・モジュール１９８へ転送する。同じく、ＳＵＰＬプロトコル・モジュール１９８からＳＵＰＬ１．０標準で行われるＩＥのリクエストは、解釈されて独自フォーマットに変換される。
【００７９】
一例を挙げれば、サーバ１０８は、拡張エフェメリスＩＥを含む補助データＩＥを、ノキアのＡ−ＧＮＳＳプロトコルを使用して生成してもよい。これは、ＳＵＰＬ１．０の使用する厳密な定義とは異なる特定のスキーマに従ったＸＭＬファイル（例えば、定義済みのスケールファクタ、ワード長、およびデータ型を有する）を生成する。
【００８０】
図７を参照する。図７は、ＳＵＰＬプロトコル・モジュール１９８と、ローカルＳＵＰＬサーバ２００との間の処理ステップの典型的な順序を示す。この処理は、ステップ７．１および７．２で、ＳＵＰＬプロトコル・モジュール１９８にて位置リクエストが受信または開始されると開始する。ステップ７．３において、ＳＵＰＬプロトコル・モジュール１９８は、ＳＵＰＬ１．０を使用して、ローカルＳＵＰＬサーバ２００に接続しＩＥのリクエストを渡す。
【００８１】
ステップ７．４において、ローカルＳＵＰＬサーバ２００は（必要なＩＥがまだローカルに記憶されていない場合）、ノキアＡ−ＧＮＳＳサーバ１０８のアドレスに対するリモートＴＣＰ／ＩＰ接続を確立する。ステップ７．５において、ローカルＳＵＰＬサーバ２００は、ノキアサーバ１０８からのＩＥをその独自プロトコルを使用してリクエストし、ステップ７．６において、ノキアのスキーマに準拠したＩＥを受信する。ステップ７．７において、ローカルＳＵＰＬサーバ２００は、そのＩＥをＳＵＰＬ１．０フォーマットに変換し、ステップ７．８において、変換されたＩＥが、ＳＵＰＬ１．０を使用してＳＵＰＬプロトコル・モジュール１９８へ転送される。
【００８２】
ステップ７．９において、ＳＵＰＬプロトコル・モジュール１９８は、ＩＥをＳＵＰＬ１．０フォーマットで受信する。ステップ７．１０において、ＩＥが復号され、下位信号としてＧＰＳ受信機のＡＰＩおよびファームウェアにマッピングされる。ステップ７．１１において、この信号がＧＰＳ受信機へ、そのＡＰＩを介して転送され、その結果、位置を求めることができる。
【００８３】
上記の例における、典型的なＩＥのフォーマット変換は、以下のとおりである。
【００８４】
外部サーバ１０８にて、ＩＥがＸＭＬで符号化される。ＸＭＬは、ローカルＳＵＰＬサーバ２００で受信されると復号されて、例えばＳＵＰＬ１．０により使用されるフォーマットであるＡＳＮ．１などのバイナリ・フォーマットに収められる。ＳＵＰＬプロトコル・モジュール１９８では、バイナリＡＳＮ．１が復号および変換され、かつ／または特定の受信機のチップセットのＡＰＩおよびファームウェアにマッピングされる。結果として生じる信号が、物理ＵＡＲＴ／Ｉ２Ｃ／ＳＰＩインターフェースを介して転送される。
【００８５】
注目すべきは、フォーマット間のファイル・サイズの差である。ローカルＳＵＰＬサーバ２００にて受信されるＸＭＬ  ＩＥは、内容は同じままでも、ＳＵＰＬプロトコル・モジュール１９８に対して提供されるバイナリ変換バージョンに比べ大きいのが通常である。バイナリ・バージョンは、非バイナリ・バージョンに比べ極めてコンパクトである。すなわち、必要なときにＳＵＰＬプロトコル・モジュール１９８により使用されるよう、ＳＵＰＬサーバ２００には、コンパクトかつ標準のＩＥが記憶される。
【００８６】
信号およびデータ変換の逆の処理も発生し得る。
【００８７】
単なるフォーマット変更のみならず、他のスキーマ変更も適用可能である。これらは、ワード長、スケールファクタ、補助データの有効期間などに関係してもよい。
【００８８】
図７に記載されたステップは、ＳＵＰＬプロトコル・モジュール１９８がＩＥのリクエストを開始する場合に関する。なお、ステップ７．４〜７．７は、位置算出（ｆｉｘ）が必要なときに受信機１３０が即時に使用できる更新済みＩＥを取得するために、時折、例えば自動的かつ周期的に、ＳＵＰＬプロトコル・モジュール１９８とは独立して実施することができる。当該ＩＥは、新たな自動更新が必要となるまで最長７日間または１４日間存続することができるエフェメリス拡張ファイルとすることもできる。
【００８９】
さらに、前述したように、ＳＵＰＬプロトコル・モジュール１９８からの特定のリクエストから要求されるＩＥが既にローカルＳＵＰＬサーバ２００に存在していて、その時点では外部接続が必要ないという可能性もある。
【００９０】
ローカル（ＳＵＰＬ）サーバ２００と（ＳＵＰＬ）プロトコル・モジュール３４との間で使用される標準のフォーマットおよびプロトコルの例としてＳＵＰＬ１．０を挙げたが、当然のことながら、序文で列挙したものを含む他のフォーマットおよびプロトコルを規定することも可能であり、これには３ＧＰＰ  ＴＳ４４．０３１、３ＧＰＰ  ＴＳ２５．３３１、ＯＭＡ  ＳＵＰＬ１．０、ＯＭＡ  ＳＵＰＬ２．０、３ＧＰＰ  ＴＳ３６．３５５、およびＯＭＡ  ＬＰＰｅ  ｖ１．０が含まれるが、これらに限定はされない。
【００９１】
上記の実施形態では、外部サーバ３２、１０８と、受信機３０、１３０のローカル・サーバ３８、２００との間で交換される補助データＩＥは、次のうちいずれかまたはすべてを含むことができる。
【００９２】
ナビゲーション・モデル。このＩＥは、測位および信号捕捉処理のための衛星軌道および時計モデル・パラメータを含む。このデータは、エフェメリス・データとも呼ばれる。このデータに対する拡張、例えば７日もしくは１４日、またはさらに長い拡張も提供可能である。
【００９３】
基準時刻。このＩＥは、測位および信号捕捉処理のための基準ＧＰＳ（またはＧＮＳＳ）時刻を含み、最適にはこれを、実現しうる最良の時刻精度のためにセルラ・システム時刻に関連付けることが可能であろう。後者の場合、基準時刻を感度改善に直接使用することができ、信号捕捉が３〜６ｄＢ改善される可能性がある。
【００９４】
基準位置。このＩＥは、受信機の推定位置を含み、これを、測位における初期位置として使用すること、および／または信号捕捉処理においても使用して弱信号条件の中で感度を改善することが可能である。基準位置は、例えば、サービス中のセルラ・セルタワーのアイデンティティ（Ｃｅｌｌ−ＩＤ）または近傍のＷＬＡＮアクセス・ポイントのアイデンティティ（通常はＭＡＣアドレス）から求めることができるであろう。
【００９５】
一部の実施形態において、ローカル・サーバは、これらＩＥのうちの１つまたはサブセットのみを外部サーバから受信し、標準のプロトコルを使用して送信される他の１つ以上のＩＥをローカルで生成してもよい。例えば、ローカル・データ・サーバは、組み合わされたデータを内部的に提供するために、外部ソースから軌道モデル・データをフェッチし、かつ基準位置をローカルで生成することができる。
【００９６】
上記の実施形態におけるローカル・サーバ３８、２００は、以下の、独自のＩＥフォーマットおよびプロトコルから標準のＩＥへの変換のうちのいずれかまたはすべてをサポートすることができる。このリストは例示であり、網羅的なものではない。
【００９７】
ＧＰＳ、ＧＬＯＮＡＳＳ、またはＧａｌｉｌｅｏのエフェメリス・データ。７／１４日（またはさらに長期の）拡張エフェメリスＩＥを、例えば３ＧＰＰ  ＴＳ４４．０３１ｖ．８．０以降などの標準のナビゲーション・モデルＩＥにマッピングすることができる。
【００９８】
基準位置。独自Ｃｅｌｌ−ＩＤおよびＷｉＦｉ測位サービスを、標準の基準位置ＩＥにマッピングすることができる。さらに、受信機デバイスがセル・タワーまたはＷｉＦｉアクセス・ポイント位置のローカル・データベースを有する場合、ローカルで生成した位置データをその受信機デバイスで使用することも可能である。
【００９９】
基準時刻。例えばＮＴＰサービスなどの独自の時刻サービスを、標準の基準時刻ＩＥに変換することができる。これは、ＧＰＳ／ＧＮＳＳ受信機モジュールに極めて正確な時刻補助を提供することを可能にする。さらに、受信機デバイス内にあるリソースを使用して正確な時刻を維持し、これを時刻補助のソースとして使用することも可能である。
【０１００】
ディファレンシャル補正。電離層モデルのための独自のサービスおよびデータを、標準のディファレンシャルＧＰＳ（ＤＧＰＳ：Ｄｉｆｆｅｒｅｎｔｉａｌ  ＧＰＳ）またはＤＧＮＳＳ補正に変換することができる。これは、サブメートルレベルにまで、局所的に測位精度を改善することを可能にする。さらに、ＳＢＡＳからの電離層モデルおよびサービスを、ローカル・サーバにおいてＳＵＰＬフォーマットに変換することができる。
【０１０１】
エフェメリス拡張。独自のエフェメリス拡張サービスを、標準のエフェメリス・データ情報要素へとマッピングすることができる。これは、例えばローミングの場合などに、サーバへの接続を削減し、受信機を自律的に動作させることを可能にする。
【０１０２】
上記は、ローカル・サーバ３８、２００が受信機のソフトウェア・スタックのアプリケーション層に存在すると想定するが、下位層に実装することもできる。ローカル・サーバ３８、２００がアプリケーション層にあると、無線でインストールおよび／またはアップグレードできるという点で際だった技術的利点がもたらされる。
【０１０３】
上記の実施形態によりもたらされる技術的利点には、以下が含まれる：
−  デバイスのアーキテクチャまたはファームウェアを修正する必要なく、既知の標準をサポートする任意の受信機デバイスをインストール、アップグレード、および修正することができること；
−  長期エフェメリス・データに関するサービス、測位に関するサービス（Ｃｅｌｌ−ＩＤ、エンハンスドＣｅｌｌ−ＩＤ、Ｗｉｆｉなど）、基準時刻に関するサービス（ＮＴＰなど）、およびディファレンシャルＧＰＳ／ＧＮＳＳなどＡ−ＧＰＳ／Ａ−ＧＮＳＳ精度向上のためのサービスを含む、１つ以上の独自のＡ−ＧＰＳ／Ａ−ＧＮＳＳサービスまたはソースをサポートすることができること。
−  ローカル・サーバ３８、２００がアプリケーション層においてインストールおよび実行されれば、バージョン制御が容易である。
−  ローカル・サーバ３８、２００がプロトコルおよび受信機モジュールとは異なる層に存在できることを理由とする、アーキテクチャ面での柔軟なモジュール性。
−  独自のフォーマットおよびプロトコルをＩＥに使用することで、感度およびＴＴＦＦの点で標準の手法に比べパフォーマンス改善が可能となり、さらにそのほか、ＴＴＦＦの短縮による省電力化、および例えばローミング時のデータ接続使用の最小化などの諸効果が生じ得る。例えば、長期エフェメリス・サービスは、デバイス内で補助データを生成できるようにする。したがって、リクエストにローカルで応じることができるため、外部サーバへのデータ接続を確立する必要がない。
−  上位ソフトウェアのアップグレード、すなわちローカル・サーバ３８、２００の更新のみにより、レガシー受信機をアップグレードすることが可能である。通常は実施が非常に難しい下位ハードウェアまたはファームウェアの変更は、不要である。
【０１０４】
セキュリティに関しては、外部サーバ（単数または複数）３２、１０８とローカルＳＵＰＬサーバ３８、２００との間のインターフェースと、ローカルＳＵＰＬサーバとプロトコル・モジュール３４との間のインターフェース（および実際は、内部的にその他任意の通信インターフェース）とは、異なるセキュリティ・レベル、プロトコル、または方法を使用することができる。例えば、ローカルＳＵＰＬサーバ３８、２００と外部サーバ（単数または複数）３２、１０８との間の接続は、セキュアシェル（ＳＳＨ：ｓｅｃｕｒｅ  ｓｈｅｌｌ）型セキュリティを使用することができ、これに対して、プロトコル・モジュール３４およびその他任意の内部インターフェースへの接続には、ローカルＳＵＰＬサーバ３８、２００によりトランスポート層セキュリティ（ＴＬＳ：ｔｒａｎｓｐｏｒｔ  ｌａｙｅｒ  ｓｅｃｕｒｉｔｙ）セキュア接続を使用可能である。あるいは、オペレーティング・システム・レベルの隠し／制限ＡＰＩを、別のセキュリティ手段として内部的に使用することができる。これの１つの利点は、独自プロトコルが、ＳＵＰＬよりも優れたセキュリティ、さらには認証をももたらし得るということである。これによって、デバイスが偽の補助データまたはスプーフィングされた補助データをサーバから受信する危険性が低減され得るであろう。
【０１０５】
要約すれば、諸側面が異なるであろう独自の方法またはサービスと標準のものとの間の（ＩＥフォーマットおよび／または通信プロトコルに関する）変換を行うよう構成されたローカル・サーバ・モジュールを受信機デバイスに提供することによって、既存および新規の受信機デバイスを用いて、既存および新規の独自補助データ・サービスを実装することができる。補助データが必要なときにプロトコル・モジュールが接続するアドレス（またはＵＲＬ）を変更すること以外に、既存の受信機およびその関連するプロトコル・モジュールに必要な変更は最小限である。
【０１０６】
当然のことながら、上述の実施形態は、単に例示であり、本発明の範囲に対する限定ではない。本願を読めば、当業者には他の変形および変更が明らかであろう。
【０１０７】
さらに、本願の開示は、本願明細書で明示的または黙示的に開示された任意の新規特徴もしくは特徴の任意の新規組み合わせ、またはその任意の一般化を含むものと理解されるべきであり、本願またはそこから派生する任意の出願の手続遂行中に、任意のそのような特徴および／またはそのような特徴の組み合わせを対象とする新たな請求項が作成され得る。
【図１】
2016509672.tif 000003
【図２】
2016509672.tif 000004
【図３】
2016509672.tif 000005
【図４】
2016509672.tif 000006
【図５】
2016509672.tif 000007
【図６】
2016509672.tif 000008
【図７】
2016509672.tif 000009
【国際調査報告】
2016509672.tif 000010
2016509672.tif 000011
2016509672.tif 000012
2016509672.tif 000013