特許 7581260 ナビゲート可能なネットワークに関するユーザ提供データの収集

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-01

(45)【発行日】2024-11-12

(54)【発明の名称】ナビゲート可能なネットワークに関するユーザ提供データの収集

(51)【国際特許分類】

   G08G 1/01 20060101AFI20241105BHJP

   G08G 1/13 20060101ALI20241105BHJP

   G01C 21/26 20060101ALI20241105BHJP

   G09B 29/10 20060101ALI20241105BHJP

   G09B 29/00 20060101ALI20241105BHJP

   G08G 1/137 20060101ALI20241105BHJP

【ＦＩ】

G08G1/01 A

G08G1/13

G01C21/26 A

G09B29/10 A

G09B29/00 Z

G08G1/137

【請求項の数】 15

(21)【出願番号】P 2021576407

(86)(22)【出願日】2020-07-03

(65)【公表番号】

(43)【公表日】2022-08-31

(86)【国際出願番号】 EP2020068908

(87)【国際公開番号】W WO2021001565

(87)【国際公開日】2021-01-07

【審査請求日】2023-04-07

(31)【優先権主張番号】1909556.1

(32)【優先日】2019-07-03

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】515295946

【氏名又は名称】トムトム トラフィック ベスローテン フエンノートシャップ

【氏名又は名称原語表記】ＴＯＭＴＯＭ ＴＲＡＦＦＩＣ Ｂ．Ｖ．

【住所又は居所原語表記】Ｄｅ Ｒｕｉｊｔｅｒｋａｄｅ １５４， １０１１ ＡＣ Ａｍｓｔｅｒｄａｍ Ｎｅｔｈｅｒｌａｎｄｓ

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】ヴィターレ， ヴィンツェンツォ

(72)【発明者】

【氏名】シルスビュリー， デイビット

(72)【発明者】

【氏名】シャイフ， ジシャン， アフメド

(72)【発明者】

【氏名】コロンボ， アレッシオ

(72)【発明者】

【氏名】トルニオーリ， シモーネ

(72)【発明者】

【氏名】ソネンバーグ， ソレン， スヴェン

【審査官】佐々木 佳祐

(56)【参考文献】

【文献】米国特許出願公開第２０１８／０１８８０４５（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１７／０３３２１９８（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／００－９９／００

Ｇ０１Ｃ ２１／００－２５／００

Ｇ０９Ｂ ２９／１０

Ｇ０９Ｂ ２９／００

(57)【特許請求の範囲】

【請求項1】

ナビゲート可能なネットワーク内を移動するユーザに関連付けられたデバイスから前記ナビゲート可能なネットワークに関する情報を取得する方法であって、
センサデータを取得するための要求を前記デバイスにおいて受信することであって、前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得し、前記ナビゲート可能なネットワークの１つ以上の属性に関する情報を決定又は抽出するために前記取得されたセンサデータを処理し、前記ナビゲート可能なネットワークの前記１つ以上の属性に関する前記情報を含むセンサデータレポートを出力のために提供するための１つまたは複数の命令のセットを含み、前記要求は、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガをさらに含む、ことと、
前記デバイスが前記トリガに関連付けられた前記ロケーションに到達したと判定された場合に、前記要求されたセンサデータを取得及び処理して出力のための対応するセンサデータレポートを生成するために前記要求に含まれる前記命令を自動的に動作させることと、
を含む方法。

【請求項2】

前記取得されたセンサデータを示すデータを出力のために提供することを含む、請求項１に記載の方法。

【請求項3】

前記センサデータレポートは、（ｉ）前記センサデータが取得された時間、（ｉｉ）前記センサデータが取得されたロケーション、（ｉｉｉ）デバイスおよび／またはセンサ識別子、ならびに（ｉｖ）センサデータレポートを生成した前記要求を示す要求識別子、のうちの１つまたは複数を含む他の情報だけでなく、前記取得されたセンサデータを示すデータを含む、請求項２に記載の方法。

【請求項4】

前記センサデータは、（ｉ）前記デバイスに関連付けられたカメラによって撮影された画像データおよび／またはビデオデータ、及び／又は、（ｉｉ）前記デバイスに関連付けられた１つまたは複数の加速度計から取得された加速度データを含み、前記デバイスで前記加速度データを処理することは、前記ナビゲート可能なネットワークの道路要素の状態を決定することである、請求項１乃至３の何れか１項に記載の方法。

【請求項5】

前記デバイスは、電子地図に対するそれ自体の位置を決定することができ、前記デバイスは、前記電子地図に対する前記デバイスの位置が前記ロケーションの所定の閾値距離内にあると判定された場合に、前記トリガに関連付けられた前記ロケーションに到達したと判定される、請求項１乃至４の何れか１項に記載の方法。

【請求項6】

前記トリガは方向インジケーションを含み、選択された方向から前記デバイスが前記トリガに関連付けられた前記ロケーションに接近していると判定された場合にのみ、前記センサデータが取得される、請求項１乃至５の何れか１項に記載の方法。

【請求項7】

ナビゲート可能なネットワーク内を移動するユーザにそれぞれ関連付けられた１つまたは複数のデバイスから前記ナビゲート可能なネットワークに関する情報を取得する方法であって、
サーバから前記ナビゲート可能なネットワーク内を移動する１つまたは複数のデバイスへセンサデータを取得するための要求を発行することであって、前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得し、前記ナビゲート可能なネットワークの１つ以上の属性に関する情報を決定又は抽出するために前記取得されたセンサデータを処理し、前記ナビゲート可能なネットワークの前記１つ以上の属性に関する前記情報を含むセンサデータレポートを出力のために提供するための１つまたは複数の命令のセットを含み、前記要求は、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガをさらに含み、前記トリガは、前記デバイスが、前記トリガに関連付けられた前記ロケーションに到達したと判定された場合に、前記センサデータを取得及び処理して出力のための対応するセンサデータレポートを生成するために前記デバイスに前記要求に含まれる前記命令を自動的に動作させるように構成される、発行することと、
センサデータの前記要求に応答して、前記デバイスの１つまたは複数から取得された１つ以上のセンサデータレポートを前記サーバで受信することと、
を含む方法。

【請求項8】

前記サーバで受信された前記データをさらに処理することをさらに含み、前記処理することは、前記取得されたセンサデータを検証するステップを含み、前記取得されたセンサデータを検証することは、複数の異なるデバイスから取得されたセンサデータを結合および／または比較することを含む、請求項７に記載の方法。

【請求項9】

前記受信されたデータを使用して前記ナビゲート可能なネットワークの電子地図表現を更新することを含む、請求項７または８に記載の方法。

【請求項10】

前記トリガは、前記デバイスの近傍内のトリガおよび／または前記デバイスがナビゲートされている所定のルートのトリガに対する前記デバイスからの要求に応答して発行される、請求項７乃至９の何れか１項に記載の方法。

【請求項11】

前記トリガは、前記ナビゲート可能なネットワークの電子地図表現に潜在的なエラーがあることの検出に応答して発行され、前記トリガに関連付けられた前記ロケーションは、前記潜在的なエラーが検出されたロケーションである、請求項７乃至１０の何れか１項に記載の方法。

【請求項12】

ナビゲート可能なネットワーク内を移動するユーザにそれぞれ関連付けられた１つまたは複数のデバイスから前記ナビゲート可能なネットワークに関する情報を取得する方法であって、
サーバから、前記ナビゲート可能なネットワーク内を移動する１つまたは複数のデバイスへ、センサデータを取得するための要求を発行することであって、前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得し、前記ナビゲート可能なネットワークの１つ以上の属性に関する情報を決定又は抽出するために前記取得されたセンサデータを処理し、前記ナビゲート可能なネットワークの前記１つ以上の属性に関する前記情報を含むセンサデータレポートを出力のために提供するための１つまたは複数の命令のセットを含み、前記要求は、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガをさらに含む、発行することと、
前記ナビゲート可能なネットワーク内を移動するデバイスにおいて、センサデータを取得するための前記要求を受信することと、
前記デバイスが前記トリガに関連付けられた前記ロケーションに到達したと判定された場合、前記要求されたセンサデータを取得及び処理して出力のための対応するセンサデータレポートを生成するために前記要求に含まれる前記命令を自動的に動作させることと、
前記生成されたセンサデータレポートを前記サーバへ出力のために提供することと、
を含む方法。

【請求項13】

デバイスが移動しているナビゲート可能なネットワークに関する情報を取得するように動作可能なデバイスであって、前記デバイスは１つまたは複数の関連するセンサにアクセスすることができ、前記デバイスは、
センサデータを取得するための要求を受信し、ここで前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得し、前記ナビゲート可能なネットワークの１つ以上の属性に関する情報を決定又は抽出するために前記取得されたセンサデータを処理し、前記ナビゲート可能なネットワークの前記１つ以上の属性に関する前記情報を含むセンサデータレポートを出力のために提供するための１つまたは複数の命令のセットを含み、前記要求は、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガをさらに含み、
前記デバイスが前記トリガに関連付けられた前記ロケーションに到達した時を判定し、当該判定に応答して、前記要求されたセンサデータを取得及び処理して出力のための対応するセンサデータレポートを生成するために前記要求に含まれる前記命令を自動的に動作させる
ように構成された１つまたは複数のプロセッサを備えるデバイス。

【請求項14】

ナビゲート可能なネットワーク内を移動するユーザにそれぞれ関連付けられた１つ以上のデバイスから前記ナビゲート可能なネットワークに関する情報を取得するように構成されたサーバであって、
前記ナビゲート可能なネットワーク内を移動する１つまたは複数のデバイスへ、センサデータを取得するための要求を発行し、ここで、前記要求は、前記デバイスに関連付けられたまたは前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得し、前記ナビゲート可能なネットワークの１つ以上の属性に関する情報を決定又は抽出するために前記取得されたセンサデータを処理し、前記ナビゲート可能なネットワークの前記１つ以上の属性に関する前記情報を含むセンサデータレポートを出力のために提供するための１つまたは複数の命令のセットを含み、前記要求は、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガをさらに含み、前記トリガは、前記デバイスが前記トリガに関連付けられた前記ロケーションに到達したと判定された場合に、前記センサデータを取得及び処理して出力のための対応するセンサデータレポートを生成するために前記デバイスに前記要求に含まれる前記命令を自動的に動作させるように構成されており、
センサデータの前記要求に応答して、前記デバイスの１つまたは複数から、生成されたセンサデータレポートを受信する
ように構成された１つまたは複数のプロセッサを備えるサーバ。

【請求項15】

請求項１４に記載のサーバと通信する、請求項１３に記載の１つまたは複数のデバイスを備えるシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は一般に、ナビゲート可能なネットワーク内を移動しているデバイス（すなわち、ユーザ）からナビゲート可能なネットワークに関する情報を取得するための方法に関する。言い換えれば、本発明は、そのような情報を得るための「クラウドソースド」技術に関する。特に、本発明の実施形態は好ましくは最小限のエンドユーザ関与で、ナビゲート可能なネットワーク内を移動しているユーザデバイスから、様々なロケーション（場所、位置）でセンサデータを自動的に取得することを可能にする。次いで、取得されたセンサデータを処理して、例えば、ナビゲート可能なネットワークの１つまたは複数の属性を決定することができる。この情報はその後、好ましくは、例えば、ナビゲート可能なネットワークの電子地図表現を適宜更新するために、地図サービスプロバイダに報告される。しかしながら、様々な他の適用がもちろん可能であり、得られた情報は一般に、任意の適切かつ所望の目的のために使用されてもよい。

【背景技術】

【0002】

ＴｏｍＴｏｍ ＧＯ（商標）Ｓａｔ Ｎａｖシステムのような専用ナビゲーションシステムのようなＧＰＳベースのパーソナルナビゲーションデバイス、ならびにスマートフォンアプリケーション上で実行されるナビゲーションソフトウェア、および車載ナビゲーションシステムを含む電子ナビゲーションデバイスのための地図データは、典型的にはＴｏｍＴｏｍ Ｉｎｔｅｒｎａｔｉｏｎａｌ ＢＶのような専門地図サービスプロバイダから取得される。この電子地図データは、ナビゲーションデバイスがナビゲート可能なネットワークを通って所望の目的地まで移動するための最適なルートを計画するために、一般にＧＰＳモジュールからの位置データと組み合わせて、ルートガイダンスアルゴリズムによって使用されるように特に設計される。

【0003】

したがって、電子地図は、現実世界のナビゲート可能な（例えば道路）ネットワークのデジタル表現である。例えば、道路セグメントは線、すなわち、ベクトル（例えば、道路の始点、終点、方向）として記述することができ、その場合、道路は例えば、その始点／終点／方向パラメータによって各々が一意に定義される、そのようなセグメント（区分）の複数から構成される。

【0004】

次いで、電子地図は、典型的にはそのような道路セグメントのセットと、各セグメントに関連するデータ（速度制限、進行（移動）方向などのそのセグメントの「属性」を含む）と、任意の他の関心地点（ＰＯＩ）、道路名、公園境界や河川境界などの他の地理的特徴とを含み、これらもまた、望ましくは地図内で定義することができる。

【0005】

地図のすべての特徴（例えば、道路セグメント、ＰＯＩなど）は、好ましくはＧＰＳ座標系に対応するか、または関連する座標系で定義され、ＧＰＳシステムを通して決定されたデバイスのロケーションを、地図で定義されている対応する道路セグメントにマッピングすることを可能にする。

【0006】

したがって、所定のルートに沿ってユーザを誘導（案内）するためのナビゲーション命令は、デバイスの（現在の）位置を地図にマッチングさせて、次いで、デバイスが、ナビゲート可能なネットワーク内の様々な交差点または他の決定点に接近するときに、関連するナビゲーション命令を提供することによって、そのような電子地図を使用して提供することができる。例えば、ナビゲーションガイダンスは、「次のジャンクションで左折」という命令など、ユーザに表示するために生成される命令を含むことができる。しかしながら、ナビゲーション命令はまた、電子地図を使用して生成されてもよく、電子地図は次いで、例えば、高度運転者支援システム（ＡＤＡＳ）、または自律運転モジュールに提供され、それによって、ネットワークの周りで車両をナビゲートするために使用されることが理解されるであろう。

【0007】

ユーザ体験を改善し、ユーザの安全性を確保するための重要な要素は、このようなナビゲーション命令を生成する際に、ナビゲーション装デバイスユーザ／車両に、実際には許可されていない（または可能でない）動作を行わせないことである。したがって、電子地図データが、信頼性があり、ネットワーク内の任意の、例えば、法的または物理的な運転制限を正確に反映することが重要である。例えば、ナビゲーションサービスは、通常、各道路セグメントに速度情報を提供することを目的とする。そのような場合、地図情報は、ナビゲーション命令を生成するときにナビゲーションサービスが表示するか、または他の方法で使用することができる道路セグメントの最大速度を含む。もちろん、この機能は、正しい電子地図と共に提供される速度制限情報に依存する。

【0008】

電子地図を構築するために、基本的な道路インフラストラクチャ情報は、少なくとも英国の道路についてＯｒｄｎａｎｃｅ Ｓｕｒｖｅｙなどの様々なソースから得ることができる。地図サービスプロバイダはまた、典型的には、道路ネットワークの周りの画像および／またはＬＩＤＡＲデータを取得するように構成された道路を走行する車両の大型専用フリート、ならびに地図データを更新およびチェックするために他の地図および航空（衛星）写真をチェックする人員を有する。このデータは地図データベースの中核を構成し、地図データベースは新しい地理参照データで継続的に強化されている。

【0009】

道路インフラストラクチャに対する絶え間ない変化のために、正確で最新の地図データベースを維持することは、継続的な努力を必要とする。さらに、上述したように、ナビゲーションガイダンスは、好ましくは道路ネットワーク内の基本的な道路形状だけでなく、現在の交通規制（例えば、速度制限）、道路閉鎖、駐車条件、交通遅延、交通密度、関心地点なども考慮し、したがって、その情報は、通常、電子地図データに沿って（またはその一部として）提供される。この情報は典型的には道路インフラストラクチャよりも動的に変化し、したがって、信頼性があり最新のナビゲーションガイダンスを提供することができるようにするために、継続的に更新されるか、またはライブデータで補足されなければならない。

【0010】

したがって、一般に、電子地図を最新の状態に保つために、より多くの情報を、より頻繁に得ることができることが望ましい。この点に関して、様々なアプローチが考慮され得る。例えば、基本地図データは、ネットワーク内を移動するナビゲーションデバイスから取得される位置データであって、時間に応じたネットワークの周りのデバイスの移動に関する位置データ（すなわち、プローブデータ）などの他のデータ（「ライブ（生の）」データを含むことができる）によって補足することもできる。このプローブデータは「ライブ（生の）」交通条件を決定するために、また、交通規制、道路閉鎖、およびネットワーク内で少なくとも半永久的に存続する他のそのような条件を推論するために処理され得る。

【0011】

また、電子地図を更新する目的のために「クラウドソース」（すなわち、ユーザが提供した）情報を取得することも知られている。例えば、ナビゲーションサービスのエンドユーザが例えば、ユーザが適切なウェブインターフェースを介してエラーを直接報告することによって、地図またはナビゲーション命令にそのようなエラーがあることを知らせることを可能にすることは、比較的一般的である。このようなユーザレポートは地図サービスプロバイダに送信され、地図サービスプロバイダはユーザレポートを確認して検証した後、地図情報を適切に更新できる。既存のマッピングシステムは、ユーザ入力が使用される範囲と、ユーザ提供データの妥当性検証の範囲において、実質的に異なる可能性がある。妥当性検証を行わないと、地図の誤った更新によって地図エラーが発生し、以前の更新を訂正または取り消すために他のユーザからの入力を必要とすることになる。欧州特許出願公開第２３３５０２１号明細書、欧州特許出願公開第３０２９４２１号明細書および欧州特許出願公開第３０２９４２２号明細書は、ナビゲーションデバイスに地図更新要求を発行するためのナビゲーションシステムの様々な他の例を記載している。この場合も、これらのシステムでは、地図更新の必要性があるかどうかを判定するために、ユーザフィードバックが関与する。

【0012】

地図データはまた、例えば、そのエリアの写真を撮るために特定のロケーション（場所、位置）を訪れることによって、何らかの局所的な情報を得ることと引き換えに何らかの報酬を提供することによって、ユーザにインセンティブを与える報酬プラットフォーム（ギグウォークなど）から取得されてもよい。報奨プラットフォームでは、ユーザがスマートフォンなどのモバイル端末にアプリケーションをダウンロードする必要があり、当該アプリケーションは、例えばユーザの近くにおける利用可能なタスクをユーザに対して示す。次に、アプリケーションは、タスクに関連する必要な情報（画像など）を取得するために必要なステップを介してユーザをガイドする。例えば、そのような報酬プラットフォームはオフストリート駐車施設上の情報を取得するために使用され得、次いで、この情報はナビゲーションサービスによって使用するために電子地図に組み込まれ得る。

【0013】

しかしながら、これらの電子地図の更新及び検証にはかなりの資源が必要であるにもかかわらず、この点に関しては依然として改善の余地があると考えられる。したがって、ナビゲート可能なネットワークに関する情報を取得するための改善された方法を提供することが望ましい。

【発明の概要】

【0014】

本発明の第１の態様によれば、ナビゲート可能なネットワーク内を移動するユーザに関連付けられたデバイスから前記ナビゲート可能なネットワークに関する情報を取得する方法であって、
前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得するための１つまたは複数の命令のセットと、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガとを含む、センサデータを取得するための要求を前記デバイスにおいて受信することと、
前記デバイスが前記トリガに関連付けられた前記ロケーションに到達したと判定された場合に、前記要求されたセンサデータを取得するために前記命令を自動的に動作させることと、
を含む方法が提供される。

【0015】

したがって、本発明は、実施形態において、実質的なエンドユーザ対話（この機能を可能にするために、おそらく最初にデバイス／センサなどを構成（設定）すること以外）を必要とせずに、ナビゲート可能なネットワークに関する情報を自動的に取得するための方法を提供する。これは、ナビゲート可能なネットワーク内を移動するデバイス（ユーザ）にセンサデータに対する特定の要求（「データ取得要求」）を発行することによって達成される。例えば、各データ取得要求は、（「トリガ」として作用する）ロケーションと、要求で指定されたロケーションで取得されるセンサデータを詳述する命令のセット（すなわちスクリプト）と、デバイスに実行させることが好ましい他の任意の処理ステップとを含む。

【0016】

したがって、デバイスがトリガに関連付けられたネットワーク内の特定のロケーション（場所）を通過するときに、デバイスに所望のセンサデータ（要求で指定される）を自動的に収集させ、次いで、好ましくは適切なセンサデータレポートを生成して返すようにデータを処理させる「トリガ」を含むセンサデータの要求がデバイスへ発行される。例えば、トリガロケーションは一般に、ナビゲート可能ネットワークの電子地図表現、例えば、デバイス上で実行されているナビゲーションアプリケーションによって使用されている電子地図に対して定義することができる。トリガロケーションは電子地図上に効果的に重ね合わせることができ、電子地図に基づいて、デバイスがトリガロケーションに到達したと判定されると、デバイスは、要求されたセンサデータを自動的に取得する。次いで、デバイスは、好ましくは取得されたセンサデータ（またはより典型的には取得されたセンサデータを示すデータ）を出力のために提供する。

【0017】

このようにして、適切なトリガを含む要求を発行することによって、ネットワーク内を現在移動しているデバイスから、ナビゲート可能なネットワーク内の任意の所望のロケーション（場所）でそのような情報を遠隔的に収集することが可能である。したがって、本発明は専用のマッピング車両群を必要とすることなく、また、デバイスユーザからの有意な入力を必要とすることなく（すなわち、有意なエンドユーザ入力を必要とすることなく）、情報（すなわち、センサデータ）を取得することができるので、ナビゲート可能なネットワークに関するそのような情報の改善された収集を容易にすることが理解されよう。

【0018】

例えば、特定のトリガに応答して取得されるセンサデータは、トリガに関連付けられたロケーションにおけるナビゲート可能なネットワークの１つまたは複数の属性を決定するために使用可能であり得る。すなわち、センサデータは、取得されると、ナビゲート可能なネットワークに関する１つまたは複数の属性を決定するために（好ましくは、以下でさらに説明されるように、デバイスにおいて少なくとも部分的に）処理され得る。次いで、センサデータおよび／または決定された属性（複数可）は、それに応じてデバイスからの出力のために提供されてもよい。

【0019】

例えば、いくつかの好ましい実施形態では、センサデータの要求は、例えば地図サービスプロバイダに属するサーバから発行され、次いで、情報が地図サービスプロバイダに返され、地図サービスプロバイダはそれに応じて（好ましくはネットワーク内を移動する１つまたは複数のデバイスから受信される任意のデータを検証した後に）、決定された属性に基づいて電子地図を更新することができる。

【0020】

この例は、例えば、その道路セグメント（区分）上を移動するデバイスに関連付けられたカメラに、速度制限標識の画像（又は一連の画像、例えばビデオ）を撮影させることによって、特定の道路セグメント上の速度制限を決定（判定）することであり、この画像は次に、速度制限値を決定するために処理されることができ、次いで、この値は、報告され、必要に応じて、電子地図を更新するために使用される。

【0021】

しかしながら、様々な他の用途が考えられ、本発明は一般に、任意の適切なセンサデータを取得するために、および／またはナビゲート可能なネットワークの任意の属性を決定するために使用されてもよく、その後、任意の所望の目的のために使用されてもよいことが理解されるのであろう。

【0022】

したがって、実施形態では、デバイスは、センサデータに対するそのような要求を処理することができるナビゲーションアプリケーションを実行していてもよい。いくつかの好ましい実施形態では、本発明は、ロケーショントリガを受信し、ロケーショントリガを処理してロケーショントリガおよびアクション要求を抽出し、デバイスがそのロケーションに到達するのを待ち、そのロケーションにおいてアクション要求を処理してセンサデータを取得し、アクション要求が完了した後にセンサデータを地図情報更新システムに送信することによって、センサデータを取得するためのナビゲーションアプリケーションに関することができる。しかしながら、他の構成も勿論可能である。

【0023】

したがって、本発明は、最小限のエンドユーザ入力を必要とするナビゲート可能なネットワークに関する情報を取得するための改善された技法を提供し、この情報は、例えば、ナビゲート可能なネットワークを表す電子地図を更新するために適切に使用することができる（もちろん、他の構成も可能である）。

【0024】

例えば、ユーザがナビゲーションサービス（ルート計画だけでなく高度／自動運転機能も含む）のための地図情報にますます依存しているので、電子地図データを正確かつ最新のものに保つことは、地図サービスプロバイダにとって重要である。地図情報を更新／提供するための現在のアプローチは、典型的には比較的コストがかかり、エネルギー効率が悪く、実質的なスケジューリング及び処理遅延を導入することができる専用のマッピング車両のフリートに依存している。

【0025】

「クラウドソース」地図更新にも知られているが、クラウドソース入力から地図情報を更新することは、特にユーザ入力が必要とされる場合に、潜在的に信頼できないデータを使用することを含むことが理解されるのであろう。例えば、クラウドソーシング地図更新のための既知の技法は、典型的にはユーザがフィードバックを提供するために、更新を信号で伝えるために、または地図更新に関する詳細を提供するために、地図システムと対話することを必要とする。そのようなユーザ対話は、ユーザ参加に対する障壁を提供することができ、また、エラーももたらしうる。

【0026】

対照的に、上記で説明したように、本明細書で提示される技術は、少なくともその好ましい実施形態において、有意なエンドユーザ入力を伴うことなく、要求に応じて、エンドユーザデバイス（すなわち、クラウドソース）から情報を取得することを可能にする。すなわち、デバイスおよびセンサが最初にセットアップされ、関連するアクセス許可が付与される等すると、必要に応じて、ネットワーク内を移動するデバイスに関連するセンサを使用して、ナビゲート可能なネットワーク内の任意の所望のロケーションで情報を取得することができる。

【0027】

したがって、所望の情報は、サーバからの要求に応じて、本質的に、ナビゲート可能なネットワーク内を移動するデバイスに関連付けられた、または当該デバイスによってアクセス可能な１つまたは複数のセンサへのリモートアクセスを可能にすることによって、自動的に（すなわち、エンドユーザの介入なしに）収集することができる。特に、（１つまたは複数の）センサは、（例えば、中央地図サービスプロバイダから）特定のセンサデータを取得するための要求をデバイスに発行することによって制御されてもよく、その要求は、（１つまたは複数の）センサに、トリガによって規定されるようなネットワーク内の特定のロケーションでデータを取得させるためのロケーション固有トリガを含んでもよい。

【0028】

また、少なくとも好ましい実施形態では、以下でさらに説明されるように、そのようなデータの収集および報告は、好ましくは少なくともいくつかの実施形態では、利用可能な通信リンクがある限り、取得されたセンサデータを出力のために提供し、実質的に取得時に、すなわちオンザフライで報告することができるように、データを取得するために使用されるデバイスのバッテリおよび／またはデータ許容量の消耗を回避するために、任意のセンサデータを格納するためのローカルストレージを通常使用するいくつかの既存の構成よりも比較的少ない処理および／または電力帯域幅を含む。

【0029】

本明細書で説明される様々な実施形態は、電子地図を更新する際に使用するための情報を取得することに関するが、本発明はこの用途に限定されず、本発明の実施形態に従って取得され得る情報は様々な用途において有用性を見出し得ることが理解されるのであろう。例えば、地図を更新するために直接使用されるのではなく、情報は、特定のロケーションにマッピングリソースをフォーカス（集中）するために使用されてもよい。同様に、ネットワークに関する情報は、高速道路の保守、交通管理などの目的のために使用することができ、マッピング目的のための使用に限定されない。このような情報はまた、自動車製造業者、貨物会社などにとっても興味深い。したがって、一般に、ナビゲート可能なネットワークに関して取得された情報は、任意の適切な用途に使用することができる。

【0030】

本発明は、第１の態様の方法を実行するためのシステムにも及ぶ。好ましくは、第１の態様が専用のポータブルナビゲーションデバイス（ＰＮＤ）、オンボードコンピュータ、またはスマートフォンまたは他のポータブル電子デバイス（モバイル端末）上で実行されるアプリケーションのいずれかを備えることができるナビゲーションデバイスなどのデバイス上で実行される。

【0031】

したがって、第２の態様から、デバイスが移動しているナビゲート可能なネットワークに関する情報を取得するように動作可能なデバイスであって、前記デバイスは１つまたは複数の関連するセンサにアクセスすることができ、前記デバイスは、
前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得するための１つまたは複数の命令のセットと、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガとを含む、センサデータを取得するための要求を受信し、
前記デバイスが前記トリガに関連付けられた前記ロケーション到達した時を判定し、当該判定に応答して、前記要求されたセンサデータを取得するために前記命令を自動的に動作させる
ように構成された１つまたは複数のプロセッサを備えるデバイスが提供される。

【0032】

本発明のこの第２の態様は適宜、その実施形態のいずれかにおける第１の態様に関して本明細書に記載される本発明の好ましい特徴および選択的な特徴のいずれか１つ以上またはすべてを含むことができ、好ましくは含む。例えば、たとえ明示的に記載されていなくても、実施形態においては、デバイスはその態様または実施形態のいずれかにおいて、本明細書の方法に関連して記載された任意のステップまたは複数ステップを実行するための手段を含むことができ、その逆もまた同様である。

【0033】

第１および第２の態様のステップは、好ましくは例えば、デバイスに関連する１つまたは複数のプロセッサおよびセンサを使用して、デバイスにおいて局所的に実行される。しかしながら、デバイスは、好ましくは中央サーバから発行される要求（トリガ）を使用してセンサデータを取得するように制御される。本明細書で使用されるように、「サーバ」は一般に、１つまたは複数のサーバのクラスタのセットを指すことができることを理解されたい。特に、サーバは（単一の）物理データサーバである必要はなく、例えばクラウドコンピューティング環境を実行する仮想サーバを含んでもよいことが理解されるのであろう。したがって、サーバはクラウドサーバであってもよい。もちろん、様々な他の構成が可能である。

【0034】

したがって、デバイスは、好ましくはサーバからセンサデータを取得するための要求を受信し、その要求は、デバイスによって適切に処理され得る。デバイスが要求されたセンサデータを取得すると、このデータ（または、より典型的にはこのセンサデータの処理から取得された情報または他のデータ）は、したがって、サーバに報告されて戻され得る。

【0035】

したがって、別の態様から、ナビゲート可能なネットワーク内を移動するユーザにそれぞれ関連付けられた１つまたは複数のデバイスから前記ナビゲート可能なネットワークに関する情報を取得する方法であって、
サーバから前記ナビゲート可能なネットワーク内を移動する１つまたは複数のデバイスへセンサデータを取得するための要求を発行することであって、前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得するための１つまたは複数の命令のセットと、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガとを含み、前記トリガは、前記デバイスが、前記トリガに関連付けられた前記ロケーションに到達したと判定された場合に、前記センサデータを取得するために前記デバイスに前記命令を自動的に動作させるように構成される、発行することと、
センサデータの前記要求に応答して、前記デバイスの１つまたは複数から取得された前記センサデータを示すデータを前記サーバで受信することと、
を含む方法が提供される。

【0036】

さらなる態様から、ナビゲート可能なネットワーク内を移動するユーザにそれぞれ関連付けられた１つ以上のデバイスから前記ナビゲート可能なネットワークに関する情報を取得するように構成されたサーバであって、
前記ナビゲート可能なネットワーク内を移動する１つまたは複数のデバイスへ、センサデータを取得するための要求を発行し、前記要求は、前記デバイスに関連付けられたまたは前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得するための１つまたは複数の命令のセットを含み、前記トリガは、前記デバイスが前記トリガに関連付けられた前記ロケーションに到達したと判定された場合に、前記デバイスに前記命令を自動的に動作させるように構成されており、
センサデータの前記要求に応答して、前記デバイスの１つまたは複数から取得された前記センサデータを示すデータを受信する
ように構成された１つまたは複数のプロセッサを備えるサーバが提供される。

【0037】

本発明は、そのような情報を収集するためのシステムおよび方法全体にも及ぶことが理解されるのであろう。例えば、好ましくはこれらのさらなる態様によるサーバによって実行されるステップが、好ましくは第１および第２の態様によるデバイスによって実行されるステップと組み合わせて使用され、したがって、実施形態では、適切なワイヤレス通信ネットワークを介して通信するそのようなサーバおよびデバイスを含むシステムが提供される。

【0038】

したがって、別の態様から、ナビゲート可能なネットワーク内を移動するユーザにそれぞれ関連付けられた１つまたは複数のデバイスから前記ナビゲート可能なネットワークに関する情報を取得する方法であって、
サーバから、前記ナビゲート可能なネットワーク内を移動する１つまたは複数のデバイスへ、センサデータを取得するための要求を発行することであって、前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得するための１つまたは複数の命令のセットと、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガとを含む、発行することと、
前記ナビゲート可能なネットワーク内を移動するデバイスにおいて、センサデータを取得するための前記要求を受信することと、
前記デバイスが前記トリガに関連付けられた前記ロケーションに到達したと判定された場合、前記要求されたセンサデータを取得するために前記命令を自動的に動作させることと、
前記取得されたセンサデータを示すデータを前記サーバへ出力のために提供することと、
を含む方法が提供される。

【0039】

これに対応して、さらに別の態様から、ナビゲート可能なネットワーク内を移動するデバイスにそれぞれ関連付けられた１つまたは複数のデバイスから前記ナビゲート可能なネットワークに関する情報を取得するシステムであって、前記システムは、サーバと、１つまたは複数のデバイスとを備え、
前記サーバは、前記ナビゲート可能なネットワーク内を移動する前記デバイスのうちの１つまたは複数へ、センサデータを取得するための要求を発行するように構成され、前記要求は、前記デバイスによってアクセス可能な１つまたは複数のセンサからセンサデータを取得するための１つまたは複数の命令のセットと、前記ナビゲート可能なネットワーク内のロケーションに関連付けられたロケーション固有トリガとを含み、
前記デバイスは、前記要求を受信した後、前記デバイスが前記トリガに関連付けられた前記ロケーションに到達した時を判定し、当該判定に応答して、前記要求されたセンサデータを取得するために前記命令を自動的に動作させ、前記取得されたセンサデータを示すデータを前記サーバへ出力のために提供するように構成される、サーバが提供される。

【0040】

再び、これらのさらなる態様の方法およびシステムは一般に、先の態様および実施形態に関連して説明したようなデバイスおよびサーバを含んでもよく、好ましくは含み、したがって、これらの態様の任意選択の／好ましい特徴の任意の組合せを含むことができることが理解されるのであろう。

【0041】

本発明による方法またはデバイスに関連して説明したステップのいずれかをその態様または実施形態のいずれかで実行するための手段は、１つまたは複数のプロセッサおよび／または適切な処理回路または回路のセットを含むことができる。したがって、本発明は、好ましくはコンピュータで実施される発明であり、本発明の態様または実施形態のいずれかに関連して説明されるステップのいずれかは、１つまたは複数のプロセッサおよび／または適切な処理回路／回路のセットの制御下で実行され得る。処理回路／回路は一般に、必要に応じて、ハードウェアまたはソフトウェアのいずれかで実装することができる。例えば、限定はしないが、本発明の方法またはシステムに関連して本明細書で説明されるステップのいずれかを実行するための手段または処理回路／回路は、所望の方法で動作するようにプログラムすることができる適切な専用のハードウェア要素（処理回路／回路）および／またはプログラマブルハードウェア要素（処理回路／回路）など、様々なステップまたは機能などを実行するように動作可能な、１つまたは複数の適切なプロセッサ、１つのコントローラまたは複数のコントローラ、機能ユニット、複数の回路／回路、処理論理、マイクロプロセッサ構成などを備えることができる。

【0042】

本発明は、任意の種類のナビゲート可能な要素に関連して実施することができる。好ましくはナビゲート可能な要素が（道路ネットワークの）道路要素であるが、本技法は、情報（例えば属性）を取得することが望まれる任意の種類の道路要素、または実際に他のタイプのナビゲート可能な要素に適用可能であることが理解されよう。従って、例示的な実施形態は、道路ネットワークの道路要素を指すが、ここで提示される技術は、経路、河川、運河、サイクル経路、曳航経路、鉄道ライン等の要素を含む任意の形態のナビゲート可能な要素に、より一般的に適用可能であることが理解されよう。

【0043】

ナビゲート可能なネットワークは例えば、当技術分野で一般に知られている方法で、電子地図によって表すことができる。したがって、電子地図は、現実世界のナビゲート可能なネットワークのデジタル表現である。したがって、電子地図は、ネットワーク内のナビゲート可能な要素（例えば、道路）の構成を表すことができる。さらに、電子地図はナビゲート可能な要素に関連する特定の属性（例えば、速度制限、進行方向）を含むこともできる（および典型的には含む）。また、電子地図は、地図に望ましく表され得る、関心地点（ＰＯＩ）などの任意の他の特徴を定義してもよい。例えば、ナビゲーション目的のための、そのような地図の使用および生成は、一般によく理解されている。電子地図は、通常、ＴｏｍＴｏｍ Ｉｎｔｅｒｎａｔｉｏｎａｌ ＢＶなどの地図サービスプロバイダによって維持（更新）され、ユーザに提供される。

【0044】

１つまたは複数のデバイスは、通常、ユーザに関連付けられる（したがって、「ユーザデバイス」と呼ばれることがある）。すなわち、デバイスは、（例えば）そのような情報の収集を制御するナビゲーションアプリケーションを使用することによって、ナビゲート可能なネットワークの既存のユーザに関連付けられることが好ましい。言い換えれば、デバイスはそのような情報を収集するために特に使用されるマッピング車両の専用フリートとは対照的に、ナビゲート可能なネットワークの既存のユーザに関連付けられることが好ましい。

【0045】

好ましくは、デバイス（または各デバイス）は、車両にも関連付けられる。したがって、そのような実施形態では、デバイスから取得されたセンサデータなどのデータへの参照が車両から取得されたデータへの参照によって置き換えることができ、１つまたは複数のデバイスの移動への参照は明示的に言及されていなくても、車両の移動への参照などによって置き換えることができる。デバイスは車両と一体化されてもよく、または、例えば、車両に搭載されるか、または車両内に搭載される、ポータブルナビゲーションデバイスまたはスマートフォンまたは他のモバイルデバイスなど、他の方法で車両と関連付けられる別個のデバイスであってもよい。

【0046】

しかしながら、これは必ずしもそう必要はなく、デバイスは歩行者によって携帯され、徒歩によってナビゲート可能なネットワークに関する情報を取得するために使用されてもよい。もちろん、他の構成も可能である。

【0047】

勿論、センサデータは、異なるデバイスの組み合わせ、又は単一のタイプのデバイスから取得することができる。

【0048】

また、デバイス（または各デバイス）は、１つまたは複数のセンサ（１つまたは複数）にアクセスすることもできる。１つまたは複数のセンサは例えば、デバイスおよびセンサの性質に応じて、任意の適切な方法でデバイスに関連付けられ、したがって、デバイスによってアクセス可能であってもよい。例えば、センサはデバイスのセンサであってもよく、この場合、デバイスは所望のセンサデータを得るために、センサに直接アクセスし、制御することができる。したがって、（１つまたは複数の）センサ（の少なくともいくつか）は、デバイスがそのような（１つまたは複数の）センサを備えるように、デバイスに組み込まれ得る。例えば、実施形態では、デバイスは、スマートフォンまたは他のそのようなモバイル端末を含むことができ、（１つまたは複数の）センサは、デバイスのカメラ、ＧＰＳモジュール、加速度計などを含むことができる。しかしながら、デバイスは例えば、適切な無線（例えば、Ｂｌｕｅｔｏｏｔｈ）接続を介して、センサと通信することによって、センサに単にアクセスすることができることも考えられる。その場合、（１つまたは複数の）センサは、要求を処理しているデバイスと相互接続された無線通信ネットワークの一部を形成する（同じ車両内の）別のデバイスの一部として提供されるセンサとすることができる。例えば、実施形態において、デバイスは、車載ナビゲーションシステムを備えることができ、その場合、デバイスは、車両のセンサにアクセスすることができる。

【0049】

例えば、スマートフォンまたは他のモバイルデバイスが車両の搭載センサにもアクセスする場合、上記で提示された２つの例の組合せを含む、様々な他の構成が当然可能である。例えば、一般に、デバイスおよびセンサは、例えば「物のインターネット」タイプの環境内の相互接続された無線ネットワークの一部を含むことができる。したがって、デバイスは、好ましくは異なるタイプの複数のセンサにアクセスすることができる（および好ましくはアクセスする）。好ましくは、デバイスおよびセンサは、同じ車両またはユーザに関連付けられる。

【0050】

センサは、任意の適切なタイプであってもよい。これにはカメラ、加速度計、方位検出器、走行距離計（オドメータ）、マイクロフォンなど、または実際に、デバイスによって通常アクセス可能であり得る任意の他のタイプのセンサが含まれ得るが、これらに限定されない。

【0051】

例えば、自動車および他の車両は、車載カメラ、および他のセンサ（例えば、距離検出センサ）をますます装備していることが理解されるのであろう。いくつかのハイエンド車両は、道路標識を絶えず探索（すなわち、「交通標識認識」）するために、これらのカメラをすでに使用している。次いで、道路標識を検出した後、車載プロセッサが画像を処理し、車両が走行している道路セグメント上の制限速度を決定する。この機能は、通常、「速度制限アシスト」と呼ばれる。同様の技法を、地図に対して車両の位置を特定するために使用することもできる。例えば、国際公開第２０１８／１０４５６３号は、道路ネットワーク内を走行する車両に関連付けられた１つまたは複数のカメラから取得された画像データが取得され、次いで、車両の位置を特定するために基準地図のセクションと比較することができるローカル地図表現を生成するために使用される方法を記載している。このような技法は、「誤ってマッピングされた特徴、または、あるべき所にない特徴」などの「誤り（エラー）」が基準地図で識別される場合、この情報を地図サービスプロバイダに伝達し、電子地図を更新するために使用されるように拡張することもできる。これは、車載システムが取得されたセンサデータと、基準（参照）に使用される電子地図との間の不一致を検出することができ、したがって、地図を更新するために、取得されたセンサデータを地図サービスプロバイダへ送信することができることを意味する。

【0052】

同様に、モバイルデバイス上のモバイルナビゲーションデバイスまたはナビゲーションアプリケーションは、カメラおよび他のセンサ（加速度計、マイクロフォン、方位検出器）へのアクセスをますます有し、これらはまた、このような情報のソースとして使用され得る。車両内のソフトウェアシステムは、携帯電話、タブレット、スマートウォッチなどのモバイル端末との情報交換をますます提供するようになっている。この接続性（コネクティビティ）は、いわゆる「物のインターネット」環境内で、自動車内のワイヤレスネットワークとモバイルデバイスのネットワークに依存する。

【0053】

したがって、本発明は、これらの既存のセンサが、例えば地図サービスプロバイダから、著しいユーザ対話を必要とせずに、要求に応じて所望のセンサデータを取得するために、遠隔制御されることを可能にする。

【0054】

センサデータは、取得されると、ナビゲート可能なネットワークの１つまたは複数の属性を決定するために処理されることが好ましい。したがって、センサデータは、ナビゲート可能なネットワークの任意の属性を決定するために望ましく使用され得る任意の適切なデータを含み得る。必要な処理は、もちろんセンサデータの性質に依存する。例えば、実施形態では、センサデータは、デバイスに関連付けられた１つまたは複数のカメラから取得された画像データを含むことができる。この例は、その道路セグメントの速度制限値を抽出するために処理される速度制限標識の画像であってもよい。その場合、適切な画像処理ソフトウェアを使用して、そのような情報を抽出することができる。しかしながら、様々な他の画像データが、ネットワーク内の現在の交通条件を評価することを含むが、これらに限定されない様々な用途のために取得されてもよい。

【0055】

センサデータが画像データを含む場合、例えば、画像の性質及び決定されるべき属性に応じて、所望の属性を決定するために画像データを処理するために、任意の適切な画像処理技術が使用されてもよい。例えば、画像処理は一般に、適切な分類アルゴリズム（「分類器」）を使用して実行することができ、この分類アルゴリズムは例えば、ニューラルネットワーク、または所望の特徴を抽出することができるように前の画像データに基づいてトレーニングされた他の適切にトレーニングされたアルゴリズムを含むことができる。例えば、交通制限標識を含む画像のセットを含むトレーニングデータに基づいて速度制限値を識別するようにトレーニングされた分類器（例えば、ニューラルネットワーク）を提供することができる。次いで、得られた画像データを処理し、速度制限情報を抽出するために、分類器を、好ましくはデバイス上で実行することができる。

【0056】

しかしながら、センサデータは画像データを含む必要はない。例えば、別の実施形態では、センサデータは、デバイスに関連付けられた１つまたは複数の加速度計から取得された加速度データを含むことができる。次いで、加速度データは例えば、道路要素の状態を決定するために、例えばポットホール、速度バンプ等を識別するために、処理され得る。別の例は、例えばマイクロフォンから得られる周囲雑音データであろう。もちろん、様々な他の構成が可能である。

【0057】

したがって、決定される属性は、好ましくは電子地図に組み込まれるか、または電子地図と一緒に組み込まれる好適な情報を含むことができる。属性は、速度制限等のような道路ネットワークの半永久的な特徴であってもよく、典型的には比較的まれに（例えば、数週間、数ヶ月、又は数年）しか変更されないか、又は現在の交通状態のようなネットワークのより動的な状態を反映してもよい。属性は一般に、時間に依存する可能性がある。例えば、センサデータはタイムスタンプと共に出力のために提供されてもよく、タイムスタンプは、ネットワークにおける時間的変動を決定するために使用されてもよい。例えば、速度制限および運転制限は１日のある時間にのみ設けてもよい（例えば、運転制限は週末にのみ、またはラッシュアワー中にのみ設けてもよい、等）。この時間的な挙動を捕捉し、好ましくは電子地図に組み込むことができる。同様に、属性がネットワーク内の動的または「ライブ」状態に関連する場合、データは（例えば、現在の状態をもはや反映しないことがあり、したがって、利用可能な場合、新しいデータで置き換えられるべきであるので）ある期間が経過した後に、廃棄されるか、またはより少ない重み付けが与えられることがある。

【0058】

好ましくは、取得されたセンサデータのこの処理の少なくとも一部は、例えば、サーバに無駄な又は冗長な情報を送信しなければならないことを回避するために、デバイス上で実行される（従って、帯域幅を節約する）。しかしながら、他の構成も勿論可能である。例えば、サーバのみで処理を行ってもよい。その場合、取得されたセンサデータは出力のために提供され、本質的にその生のフォーマットで送信されてもよい（ただし、デバイスは送信されるデータパケットのサイズを低減するために、少なくともデータ圧縮ステップを実行することが好ましい）。そして、サーバによって受信されるデータは所望の属性を決定するために、サーバで適切に処理されてもよい。処理がサーバで実行される場合、これは、サーバ上で実行される適切なアルゴリズムを使用して、あるいは手動処理によってさえ、行われる可能性がある。

【0059】

しかしながら、上述したように、好ましくは、センサデータの処理の少なくとも一部がデバイスにおいて実行される。したがって、好ましくは、取得されたセンサデータをその生のフォーマットで出力するために提供するのではなく、デバイスは最初に、取得されたセンサデータを処理して、サーバに送信することができるセンサデータレポートを生成する。したがって、実施形態において、出力のために得られたセンサデータを示すデータを提供するステップは、得られたセンサデータを処理してセンサデータレポートを生成し、そのようなセンサデータレポートを出力のために提供するステップを含む。

【0060】

例えば、好ましい実施形態では、デバイスが取得されたセンサデータを処理して、ナビゲート可能なネットワークの１つまたは複数の属性に関する情報を、例えば上述の方法で決定または抽出する。このようにして、生のセンサデータ（例えば、画像又は画像シーケンス）ではなく、決定された属性の値（例えば、速度限界値）を示すデータを送信することのみが必要であるので、デバイスから送信される必要があるデータの量を更に低減することができる。さらに、デバイスにおいて取得されたセンサデータを処理することにより、デバイスは、無関係または冗長な任意のデータを廃棄する（したがって、報告しない）ことが可能になる。ここでも、このようなデータをサーバに送り返す必要はなく、再び帯域幅要件が減少する可能性があることを意味する。

【0061】

言い換えると、デバイスは、地図サービスプロバイダに送信される情報の信頼性および情報密度を高めるために、センサデータを局所的（ローカル）に処理することができる。ローカル処理は、センサデータを取得するための要求にも含まれることが好ましい適切なスクリプト（すなわち、命令のセット）を介して制御することができる。すなわち、取得されたセンサデータのローカル処理は、サーバの命令の下で実行されてもよく、当該命令は要求内に含まれる。すなわち、デバイスは、トリガロケーションに到達したときに、要求されたセンサデータを自動的に取得して処理するようにさせられることが好ましい。

【0062】

センサデータの処理から得られた決定された属性および／または情報と同様に、センサデータレポートは、典型的には、好ましくは（ｉ）センサデータが得られた時間、（ｉｉ）センサデータが得られたロケーション（場所）、および（ｉｉｉ）デバイスおよび／またはセンサ識別子、のうちの１つまたは複数を含む他の情報を含むことができる。取得されたセンサデータを示すデータ（例えば、センサデータレポート）はまた、サーバが、受信されたデータを、そのデータを取得させた要求（トリガ）に関連付けることができるように、タグ付けされるか、さそうでなければ符号化されることが好ましい。すなわち、センサデータレポートは、サーバがセンサデータレポートを、データを生成したそれぞれの要求に関連付けることを可能にする「要求識別子」も含むことが好ましい。したがって、センサデータレポートは、センサデータレポートを生成した要求を示す要求識別子も含むことが好ましい。これにより、サーバは、受信したデータを、発行された要求（トリガ）と相関させることができる。

【0063】

したがって、サーバは、好ましくは取得されたセンサデータを示すデータ（センサデータ自体がデバイスから送信される必要がないように、センサデータの処理から決定された１つまたは複数の属性を含むことが好ましい）だけでなく、センサデータに関する任意の他の所望の情報、またはセンサデータを提供したデバイスも含むセンサデータレポートをデバイスから受信する。好ましくは、サーバがナビゲート可能なネットワーク内を移動する複数の異なるデバイスから複数のそのようなセンサデータレポートを受信する。次いで、受信されたセンサデータレポートは、ナビゲート可能なネットワークに関する所望の情報（例えば、属性）を抽出するために、サーバによって適切に処理され得る。

【0064】

いくつかの好ましい実施形態では、デバイス出力（例えば、決定された属性および／またはセンサデータ）は、地図サービスプロバイダに提供され、それによって電子地図を更新するために使用される。したがって、地図サービスプロバイダは、収集された情報を使用して電子地図を更新することができ、その後、適当な地図更新が周期的に、またはより動的に（例えば、実質的にリアルタイムで）、例えば情報の性質に応じてリリースされる。

【0065】

好ましくは、取得されたセンサデータ、または少なくともそれを示すデータは、取得されたときにサーバに直接提供される。例えば、適切に利用可能なデータコネクションがある限り、取得されたセンサデータは、実質的にオンザフライでサーバ（またはサーバ、例えば、地図更新サービスがクラウドサーバに基づく場合）に送信されてもよい。しかしながら、あまり好ましくない実施形態では、デバイスによって収集されたデータは、データを地図更新サービスに送信することが望まれる時間まで、デバイスに記憶されてもよいことも企図される。データはインターネットアクセスを提供する無線通信ネットワーク（例えば、ＧＳＭ １Ｇ-４Ｇ、５Ｇ、Ｎａｒｒｏｗｂａｎｄ-ＩｏＴ、ＬｏＲａ等）を使用してサーバに送信されることが好ましい。もちろん、この点に関して、様々な構成が可能であろう。

【0066】

当然のことながら、デバイスから得られたデータは潜在的に信頼できない可能性があり、例えば、センサに故障がある場合、またはセンサが誤って取り付けられている場合、またはデバイスの位置決定機能に故障がある場合である。したがって、この情報が使用される前に、デバイスから受信されたデータは、好ましくは例えば、データの品質および内容（コンテンツ）を保証するために、サーバで検証される。得られたデータを検証するための様々なアプローチが考えられる。

【0067】

例えば、好ましくは、得られたセンサデータは、複数の異なるデバイスから得られたセンサデータを組み合わせること、及び／又は比較すること（例えば、一定の時間枠（タイムウィンドウ）内で実質的に同時に、又は、データを過去の（履歴の）センサデータと比較すること）によって検証される。したがって、実施形態では、サーバで受信されるデータを処理することは、取得されたセンサデータを検証するステップを含み、取得されたセンサデータを検証することは、複数の異なるデバイスから取得されたセンサデータを組み合わせるおよび／または比較することを含む。受信されたデータの検証はまた、データに関連付けられた認証および機密性信用証明をチェックすることができ、この情報はまた、センサデータレポート内で規定することができる。

【0068】

本発明によれば、センサデータは、センサデータを取得するための要求の一部としてサーバからデバイスに発行することができる１つまたは複数のロケーション固有「トリガ」を使用して制御されるセンサデータの取得を用いて、デバイス（およびそれらの関連するセンサ）から遠隔で取得される。

【0069】

サーバは例えば、サーバ側で何らかの情報が必要であると判定されたときに、センサデータ自体を求める要求を発行することができる。例えば、地図サービスプロバイダがあるロケーションで情報を取得したい場合、地図サービスプロバイダはサーバを介して、ナビゲート可能なネットワーク内を現在移動している１つまたは特定の（および潜在的にすべての利用可能である）デバイスに、そのロケーションでのセンサデータを求める要求を発行することができる。しかしながら、他の構成も勿論可能である。

【0070】

したがって、実施形態では、センサデータの要求が電子地図および関連データと共にデバイスに発行されてもよい。その場合、トリガは例えば、関心地点、または電子地図に重ね合わせることができる他の特徴に類似した方法で、電子地図に効果的に追加することができる。電子地図を使用するデバイスがナビゲート可能なネットワークの周りを移動するとき、要求されたセンサデータは自動的に取得され、デバイスがトリガに到達する（または通過する）ときはいつでもサーバに報告されてもよい。すなわち、デバイスがトリガに達したと判定された場合、デバイスは、要求されたセンサデータを自動的に取得するようにされる。

【0071】

したがって、センサデータの要求は、（「トリガ」として作用する）ロケーションと、取得されるセンサデータを詳述する命令のセット（例えばスクリプト）と、好ましくはセンサデータを取得するためにデバイスが実行すべきステップとを含む。したがって、デバイスが、トリガによって指定されたロケーションに到達したと判定した場合、デバイスは次いで、命令で指定された動作を実行することによって、センサに、そのロケーションでのデータの取得を開始させることができる。

【0072】

したがって、命令のセットは、次の命令（例えば、センサデータの取得を開始する命令であってもよい）に移動する前に、指定されたロケーションまでデバイスを待たせる「待機（ＷＡＩＴ）」命令を含んでもよい。または、指定されたロケーションに到達したと判定された場合にのみスクリプトをロードすることもできる。もちろん、様々な他の構成が可能である。

【0073】

命令はまた、要求されたデータを取得するためにセンサを機動させて、センサ動作を制御するための命令を含む。例えば、センサがカメラである場合、命令は、特定の道路セグメントに沿って（時間／空間で）ある間隔で画像のシーケンスを得る命令を含むことができる。同様に、命令は、道路セグメントに沿ったある持続時間の間、ビデオシーケンスを取得することであってもよい。この例は上述したように、速度制限情報を決定する場合である。その場合、要求を発行するサーバは，速度制限標識の正確なロケーションを知ることはできないが、道路セグメントに沿ったある地点に位置することを知ることができる。したがって、道路セグメントの開始に到着するデバイスに、実質的に道路セグメント全体（または少なくとも速度制限標識が検出されるまで）の画像／ビデオデータを撮影させるように要求を発行することができる。次いで、この画像シーケンスは、好ましくはデバイスで処理されて、速度制限値を抽出し、次いで、この速度制限値は、（好ましくは画像シーケンス全体を報告することなく）報告して戻すことができ、それによって、帯域幅が節約される。

【0074】

データを取得するためにセンサを起動させるための命令と同様に、命令のセットは例えば、デバイスおよび／またはセンサを事前構成するため、および／または取得されたセンサデータを処理するための、任意の他の所望の命令を含んでもよい。例えば、命令はまた、上述したように、出力のためのセンサデータレポートを生成するためのデバイスの命令を含んでもよい。

【0075】

したがって、命令は、データ取得要求を完了するために使用されるセンサのタイプ、センサの所望の向き（例えば、センサが不正確に取り付けられていると判定された場合、スクリプトはセンサデータを取得することなくその時点で中止することができる）、データ収集の持続時間、繰り返される収集ステップ、および／またはセンサデータを取得し、出力のためにこれを準備するときに実行されるべき任意のさらなる処理ステップを詳述することができる。

【0076】

これらの命令のすべては、要求内に含めることができ（および好ましくは含め）、したがって、要求を処理する際のエンドユーザの関与を本質的に排除することができる。

【0077】

したがって、センサデータの要求は、センサデータを取得する命令、例えば、センサデータを取得し、取得したセンサデータを処理（または前処理）し、取得したセンサデータを示すデータを含む適切なセンサデータレポートを、任意の他の所望の属性とともに生成するための命令だけでなく、指定されたロケーション（例えば、電子地図に対して定義することができる）でセンサデータを取得させるためのロケーション固有トリガを含むデータパッケージである。したがって、そのような要求を受信したデバイスは、ロケーション固有トリガを抽出し、センサデータを取得および／または処理するために必要とされる任意の命令などを読み取るために、パッケージ（要求）をアンパックすることができる。

【0078】

いくつかの実施形態では、サーバは、電子地図の現在のバージョンに対してナビゲート可能なネットワーク内で何かが変化したと判定された場合に、そのようなトリガを含むセンサデータの要求を自動的に発行することができる。例えば、実施形態では、ナビゲート可能なネットワーク内のデバイスの観察された挙動が電子地図に基づいて予想される挙動と一致しないロケーションを検出し、次いで、そのロケーションにおけるセンサデータのトリガを含む要求を自動的に発行するように構成された地図更新システムが提供される。いくつかの実施形態では、システムは、電子地図に対する時間に応じた１つまたは複数のデバイスの移動に関する位置データを取得し、取得された位置データを処理して、観察された挙動が電子地図の現在のバージョンに基づいて期待される挙動と一致しないインスタンスを識別するように構成することができる。このようなインスタンスが識別されると、明らかな不一致を解決しようとするためのセンサデータを取得するための適切なトリガを含む要求を生成することができる。したがって、実施形態では、要求（トリガ）は、地図サービスプロバイダによって生成されてもよい（その後、それに応じて複数のデバイスに発行されてもよい）。

【0079】

代替的に、トリガは、デバイスから要求されてもよい。例えば、デバイスが（例えば、ナビゲーションデバイス／ソフトウェアに典型的に見られるような既知の経路計画アルゴリズムを使用して）従うべき経路を決定した後、デバイスは次に、サーバから、その経路に沿って位置するトリガを要求することができる。次に、そのようなトリガを含むセンサデータの要求を発行することができ、トリガは、関連するロケーションでルート（経路）に追加される。つまり、サーバが要求（トリガ）をデバイスにプッシュするのではなく、デバイス（クライアント）がトリガをプルしてもよい。

【0080】

このように、トリガは、デバイスがトリガに関連付けられたロケーションに到達したと判定された場合に、デバイスにセンサデータを取得させる。したがって、本明細書で説明する技法は、デバイスがトリガによって指定されたロケーションに到達した時を判定するステップを含むことができる。この判定は、様々な方法で実行することができる。例えば、デバイスは一般に、（例えば、ＧＰＳ、または当技術分野で知られている他の同様の位置決定能力を使用して）それ自体のロケーションを決定することができ、したがって、デバイスは、それがトリガロケーションに近づいている時を判定することができることが理解されるのであろう。したがって、好ましい実施形態では、トリガによって指定されたロケーションにデバイスが到達した時の判定は、デバイスによって、例えば、デバイスに関連付けられた適切な位置決めモジュールによって行われる。好ましくは、この判定は、ナビゲート可能なネットワークの電子地図表現に関連して行われる。例えば、デバイスの位置は、デバイスの位置を、好ましくは電子地図に定義される（マッピングされる）トリガロケーションと比較するために、（例えば、既知の地図マッチング技術を使用して）地図上にマッチングされてもよい。しかしながら、他の構成も可能である。

【0081】

デバイスがトリガによって指定されたロケーションに到達した時の判定は、デバイスがロケーショントリガの所定の閾値距離内にあると判定された時に行うことができる（その時点で、センサ（１つまたは複数）を起動し、上述の方法でデータの取得を開始させることができるなど）。閾値距離は「ゼロ」であってもよく、すなわち、デバイスがトリガロケーションを通過するときにデータが取得されるようになっている。ある場合には、トリガは、選択された方向からトリガに関連付けられたロケーションにデバイスが近づいていると判定された場合にのみセンサデータが得られるように、方向インディケーション（指示）を含むこともできる。もちろん、この点に関して、様々な他の構成が可能である。

【0082】

したがって、要求されたセンサデータは、自動的に、すなわち、（この機能を可能にし、センサへのアクセスを可能にするようにデバイスを最初に構成するために保存して）エンドユーザ対話なしに、取得され、サーバに報告されてもよいことが理解されるのであろう。したがって、本発明は、少なくともその好ましい実施形態では、最小限のユーザ対話しか必要としないクラウドソース更新ループを可能にする。例えば、本明細書で提示する技術を使用して、より最新の速度制限情報を含む高品質の電子地図を提供することができる。しかしながら、本発明は、もちろん、速度制限を決定することに限定されない。例えば、本発明は速度制限、信号機、車線数、速度カメラ、新しい道路、旋回制限、道路工事、閉鎖道路、道路標示のタイプ（例えば追い越しが許可されていることを示す破線など）、ＰＯＩ確認などを含むがこれらに限定されない、様々な静的および動的な地図属性のためのクラウドソース地図更新をサポートすることもできる。

【0083】

いくつかの好ましい実施形態では、この技術は例えば、スマートフォンなどのモバイルデバイスが車両内に搭載されるモバイルプラットフォーム上で実施される。しかしながら、本発明は一般に、任意の適切なデバイスおよびセンサを使用して実装されてもよく、それらは、モバイルデバイスに関連付けられてもよく、オンボードセンサであってもよく、または何らかの組合せであってもよい。

【0084】

したがって、その好ましい実施形態では、本発明は、地図コンテンツプロバイダが車両内で実行され、車載ネットワークを介して１組のコンピューティングデバイスおよび関連するセンサに接続されたナビゲーションアプリケーションにデータ収集要求を送信することを可能にする。（アクセス権を設定するための初期設定以外に）ユーザの関与はないため、システムはユーザにとって手間がかからず、より信頼性の高い情報を提供し、地図情報を更新するためのより高速なフィードバックループを可能にする。

【0085】

本発明による方法は、その態様または実施形態のいずれにおいても、ソフトウェアを少なくとも部分的に使用して実装され得ることが理解されるのであろう。したがって、さらなる態様およびさらなる実施形態から見た場合、本発明は、適切なデータ処理手段（データプロセッサ）上で実行されたときに本明細書で説明される方法のいずれかまたはすべてを実行するように構成されたコンピュータ可読命令を含むコンピュータプログラム製品に拡張されることが理解されよう。本発明はまた、そのようなソフトウェアを含むコンピュータソフトウェアキャリアにも及ぶ。そのようなソフトウェアキャリアは物理的な（または非一時的である）記憶媒体であってもよく、あるいはワイヤ（有線）を介した電気信号、光信号、または衛星などへの無線信号などの信号であってもよい。

【0086】

したがって、本明細書に記載する技術をさらに別の実施形態から見ると、本明細書に記載する技術は、データプロセッサにインストールされる場合に、本明細書に記載する方法を実行するように特に構成されたコンピュータソフトウェアと、プログラム要素がデータプロセッサ上で実行される場合に、本明細書に記載する方法を実行するためのコンピュータソフトウェアコード部分を含むコンピュータプログラム要素と、プログラムがデータプロセッサ上で実行される場合に、本明細書に記載する方法の何れかまたは方法のすべてのステップを実行するように構成されたコードを含むコンピュータプログラムとを含むことがわかる。データプロセッサは、マイクロプロセッサシステム、プログラマブルＦＰＧＡ(フィールドプログラマブルゲートアレイ）などとすることができる。

【0087】

したがって、本明細書で説明する技術は、コンピュータシステムと共に使用するためのコンピュータプログラム製品として適切に実施することができる。このような実装は例えば、ディスケット、ＣＤ－ＲＯＭ、ＲＯＭ、ＲＡＭ、フラッシュメモリ、またはハードディスクのような、有形の一時的でない媒体上に固定された一連のコンピュータ可読命令を含むことができる。これはまた、モデムまたは他のインターフェースデバイスを介して、光またはアナログ通信回線を含むがこれらに限定されない有形媒体を介して、またはマイクロ波、赤外線または他の送信技術を含むがこれらに限定されない無線技術を無形に使用して、コンピュータシステムに送信可能な一連のコンピュータ可読命令を含むこともできる。一連のコンピュータ可読命令は、本明細書に先に説明した機能の全部または一部を具体化する。

【0088】

当業者であれば、そのようなコンピュータ可読命令は、多くのコンピュータアーキテクチャまたはオペレーティングシステムと共に使用するために、いくつかのプログラミング言語で書くことができることを理解するのであろう。さらに、そのような命令は、半導体、磁気、または光を含むがこれらに限定されない、現在または将来の任意のメモリ技術を使用して格納されてもよく、または光、赤外線、またはマイクロ波を含むがこれらに限定されない、現在または将来の任意の通信技術を使用して送信されてもよい。このようなコンピュータプログラム製品は、例えば、収縮包装されたソフトウェア、コンピュータシステム、例えば、システムＲＯＭまたは固定ディスクに予めロードされたもの、またはネットワーク、例えば、インターネットまたはワールドワイドウェブ上のサーバまたは電子掲示板から配布されたものなど、付属の印刷文書または電子文書を有する取り外し可能媒体として配布することが考えられる。

【0089】

そのさらなる態様または実施形態のいずれかによる本発明は、相互に矛盾しない範囲で、本発明の他の態様または実施形態を参照して説明した特徴のいずれかを含むことができる。

【0090】

本明細書において、デバイスのロケーション、又はナビゲート可能なネットワーク／地図等のロケーションへの言及は、文脈が別段の要求をしない限り、これらを示すデータを指すものと理解されるべきであることに留意されたい。データは任意の方法で関連パラメータを示すことができ、それを直接的または間接的に示すことができる。したがって、ロケーション、属性などへの任意の言及は、それを示すデータ、すなわち、ロケーションデータ、または属性データなどへの言及によって置き換えることができる。また、「関連付けられた」という語句は、データ記憶ロケーションに何らかの特定の制限を必要とすると解釈されるべきではないことにも留意されたい。この語句は、特徴が識別可能に関連していることのみを必要とする。

【0091】

本発明の実施形態の様々な特徴を、以下でさらに詳細に説明する。

【図面の簡単な説明】

【0092】

本発明の教示の様々な態様、およびそれらの教示を具体化する構成は、添付の図面を参照して、例示的な例として以下に記載される。

【図1】図１は、本明細書で提示される技術の実施形態を実施することができるシステムを概略的に示す。

【図2】図２は、一実施形態による、ロケーショントリガを受信するときにデバイスによって実行される処理ステップを示す。

【図3】図３は、実施形態に係る地図情報更新システムの高水準アーキテクチャ図である。

【図4】図４は、道路ネットワークの電子地図表現にロケーショントリガをどのように組み込むことができるかを示す。

【図5】図５は、速度制限が変化したことが道路ネットワーク内のプローブデータの観測からどのように検出され得るかを示す。

【図6】図６は、一実施形態による速度制限が変化したかどうかを確認するためにロケーショントリガをどのように使用することができるかを示す。

【図7】図７は、道路ネットワーク内のあるロケーションにおける時間の関数としての速度記録の例を示す。

【図8】図８は、２つの異なる時間における図７の例におけるロケーションについての速度記録の分布を示す。

【発明を実施するための形態】

【0093】

本発明の実施形態は、ネットワーク内を現在移動しているユーザデバイスからナビゲート可能なネットワークに関する情報（例えば、地図情報）を収集する方法に関する。言い換えれば、実施形態は、そのような情報を「クラウドソーシング」するための技法に関する。好ましくは、ナビゲート可能なネットワークは道路ネットワークであり、情報はネットワーク内を移動する車両に関連するデバイスから収集される。例えば、情報は車両内で、および／または車載システムから、携帯または搭載されるスマートフォンなどのユーザデバイスから収集されてもよい。

【0094】

図１は、本発明の実施形態を実行することができるシステムの一例を示す。図示するように、車両１０は、車載ネットワーク１４を介して互いに通信することができる相互接続された一組のデバイス１２を含む。デバイス１２のいくつかは、例えばサーバ１８を介して、１つまたは複数のインターネットサービスへのアクセスを提供する長距離ワイヤレスネットワーク１６（携帯電話ネットワーク、GSM G１～Ｇ４、Ｇ５、Ｎａｒｒｏｗｂａｎｄ-ＩｏＴ、ＬｏＲａなど）にも接続される。

【0095】

図１は、車載ネットワークに取り付けられたいくつかのデバイス１２を示す。各デバイス１２は、典型的にはプロセッサ、何らかのメモリおよびネットワークインターフェースを含む。デバイス１２の少なくともいくつかはまた、１つ以上のセンサ１３、例えば、マイクロフォン、カメラ、加速度計、位置決めセンサ、近接センサ、レーダ、レーザレンジファインダ、周囲光検出器などを含む。デバイス１２のいくつかは、それらのセンサ１３が固定された向きを有するように、車両に埋め込まれてもよい。しかしながら、デバイス１２のいくつかは、ユーザのスマートフォンのようなユーザに属することができ、したがって、それらを確実に使用する前に、所定の位置に取り付ける必要があるかもしれない。

【0096】

車載ネットワーク１４に接続された任意のデバイス１２は、それらのリソース（例えば、センサ１３）をネットワーク１４内の他のデバイス１２と共有するように構成することができる。例えば、モバイルデバイスは、車両に埋め込まれたデバイスに埋め込まれたビデオセンサにアクセスすることを可能にすることができる。同様に、組み込みデバイスで実行されているアプリケーションは、モバイルデバイスの長距離ワイヤレスネットワークにアクセスできるようにすることができる。したがって、デバイス１２は、リソースを共有することを可能にする「物のインターネット」タイプのインフラストラクチャ内で通信することができる。

【0097】

デバイス１２のうちの少なくとも１つは、ナビゲーションアプリケーションを実行していてもよい。一般に知られているように、ナビゲーションアプリケーションは、ユーザを新しい目的地にナビゲートするのを支援することができ、または、一般に使用される目的地（ホーム、仕事など）にナビゲートするための関連情報を単に提供することができる。どちらのモードでも、ナビゲーションアプリケーションは、ローカルに記憶された地図情報を使用し、長距離ワイヤレスネットワーク１６を使用して地図コンテンツプロバイダから地図情報を受信することができる。

【0098】

地図コンテンツプロバイダは、広範な地図情報を提供する。道路ネットワークに関連する地図情報は比較的静的であり、道路工事が完了するのに数ヶ月から数年を要する可能性があるので、地図更新を事前に十分にスケジュールすることができることを理解されたい。しかしながら、交通密度、事故、道路閉鎖、更新された道路標識、関心地点などの他の地図情報は、より動的であり得る。地図コンテンツプロバイダは、ナビゲーションアプリケーションから位置データポイントを観察して、履歴ナビゲーションデータと最近のナビゲーションデータとの違い（差異）を検出することができる。このような差異は、地図情報の変化を示すことがある。このタイプおよびその他のタイプのレポートは、地図更新システムによって処理される。

【0099】

ロケーショントリガ処理
実施形態は、地図更新システムが地図更新決定を支援するローカル情報を迅速に得ることを可能にする。これは、図２に示すように、ロケーショントリガの処理を支援することができる車載ネットワーク１４内のナビゲーションアプリケーションを含む。

【0100】

図２は、ロケーションポイントおよびアクション要求を含むロケーショントリガの受信（ステップ２０）から始まるナビゲーションアプリケーションの処理ステップを示す。ロケーションポイントは例えば、経度及び緯度値ペアを用いて表現される地図上のポイントの仕様である。ロケーションポイントは、通常、道路セグメント上または新しい道路セグメント上に位置する。ロケーションポイントは、方向インジケーション（方向指標）を含むこともできる。アクション要求は、関連付けられたロケーションポイントでの地図作成目的でのデータ収集要求を記述する。アクション要求は、アクセス可能なカメラによって１つまたは複数の画像を撮ること、または短いビデオシーケンスを記録することを規定することができる。アクション要求はまた、時間セグメントにわたる記録加速度計の読み出しを規定してもよい。したがって、ナビゲーションアプリケーションにアクセス可能な任意のセンサをアクション要求に含めることができる。アクション要求を受信した後、ナビゲーションアプリケーションは、車両ロケーションデータが、ロケーショントリガ内で提供されたロケーションポイントのあるマージン内にあることを示すことを待つ（ステップ２１）。

【0101】

ロケーショントリガポイントで、ナビゲーションアプリケーションは、ローカルセンサから、またはアクション要求に示されている車載ネットワーク内の別のデバイスのアクセス可能なセンサから、センサデータを収集する（ステップ２２）。任意選択で、ナビゲーションアプリケーションは、収集されたセンサデータを処理することができる（ステップ２３）。処理は、ロケーショントリガメッセージに含まれるコード（スクリプト、バイトコードのセット、バイナリコード）を使用するか、またはナビゲーションアプリケーションによってサポートされる所定のセンサデータ処理機能を使用することができる。

【0102】

センサデータ処理の一例は、画像内の特徴の探索又はデータ圧縮動作である。この処理は、冗長な又は関連しない情報を検出して除去することにより、センサデータのサイズを小さくすることができる。処理ステップはまた、収集されたセンサデータを、時間、日付、ロケーション、デバイスＩＤ、センサＩＤ等の他のセンサ情報と組み合わせて、センサデータレポートとすることもできる。センサデータレポートは、好ましくは認証及び機密性技術を使用する。センサデータレポートは、受信されたロケーショントリガに対する応答として送信される（ステップ２４）。

【0103】

一方、車両位置データが所定のマージン内のロケーションポイントに到達しない場合、ナビゲーションアプリケーションは、タイムアウトウィンドウの満了後にエラーメッセージを返す。

【0104】

地図更新システム
上述のようにナビゲーションアプリケーションで具体化された特徴は、地図情報更新システムで有益に使用され得る。図３は、実施形態に係る地図情報更新システムの高水準アーキテクチャ図を含む。

【0105】

したがって、図３は、ロケーショントリガメッセージを生成するための地図情報コントローラ３５を備えた地図情報更新システムを示す。ロケーショントリガのロケーションポイントが道路セグメントのある範囲内にある場合、道路セグメントをロケーショントリガに関連付ける参照またはロケーショントリガ識別子が道路セグメントに追加される。したがって、そのような関連付けは、電子地図内の関心地点（ＰＯＩ）または道路セグメント属性に類似し得ることが理解されるのであろう。次に、ロケーショントリガが、スケジューラ３０を介してネットワーク内を移動する車両に関連付けられたナビゲーションアプリケーション３１に発行される。オプションとして、スケジューラ３０はまた、ナビゲーションアプリケーション３１から位置データを収集し、次いで、どのナビゲーションアプリケーション３１がロケーショントリガを発行するかをプローブデータに基づいて決定してもよい。例えば、スケジューラ３０は、関連するロケーションの近傍にあるナビゲーションアプリケーション３１に対してのみロケーショントリガを選択的に発行することができる。あるいは、スケジューラ３０は、道路ネットワーク内で現在動作しているすべてのナビゲーションアプリケーション３１にロケーショントリガを発行することができる。

【0106】

例えば、ナビゲーションアプリケーション３１は、地図データの一部として関連情報を受信してもよい。これは、道路ネットワークの電子地図表現に重ね合わされた２つのロケーショントリガ４０を示す図４に示されている。あるいは、ナビゲーションアプリケーション３１は、現在のロケーションの近く、計画されたルートの近く、または頻繁に移動するルートの近くに、任意のそのような関連付けを要求することができる。例えば、ナビゲーションアプリケーション３１は、関連情報（参照、識別子）を用いて、ロケーショントリガの送信を要求してもよい。

【0107】

上述した実施例の各々は、長距離通信ネットワーク１６を介してロケーショントリガの送信をもたらす。次いで、ロケーショントリガを受信するナビゲーションアプリケーション３１は、車載ネットワーク１４内の関連付けられたセンサ３２から、要求されたセンサデータを収集し、次いで、センサデータレポートを生成して返すために、前のセクションで説明したように、適切なセンサデータ処理ソフトウェア３３を使用してロケーショントリガを処理することができる。

【0108】

そして、地図情報コントローラ３５は、センサデータレポートを用いて地図情報３６を適宜更新してもよい。この段階で、更新プロセスは一般に、公知の地図更新メカニズムまたは地図作成メカニズムに匹敵し得る。

【0109】

センサデータレポートは、信頼できないユーザデータとみなすことができるので、地図情報更新システムは、メッセージ検証モジュール３４を採用して、センサデータレポートの信頼レベルを検証した後に、それを地図情報コントローラ内で使用することができる。検証動作は、センサデータレポートで使用される認証および機密性技術をチェックすることができる。また、センサデータと他のソースからのセンサデータ履歴とを比較することもできる。別の検証技法は、同じロケーショントリガについて異なるナビゲーションアプリケーションによって生成されたセンサデータレポートを比較し、より信頼性の高いセンサデータ報告へと組み合わせる（結合する）ことであろう。

【0110】

ユースケース － 速度変更の更新
クラウドソース地図更新は、速度制限の変化をライブ方式で報告しようと試みる地図製品において、速度制限情報を常に最新に保つために使用することができる。

【0111】

この場合、電子地図を更新するために連携する４つのシステムがある：
・関連する道路ネットワークを監視し、例えばＧＰＳデータからの変化を検出する変化検出器（クラウド内のサーバ上で実行される）。
・フロントガラスの背後などのモバイルプラットフォーム上で実行されるアプリ
・モバイルプラットフォーム上で実行されているＡＩベースのオブジェクト検出アルゴリズム
・地図サービス

【0112】

道路ネットワーク全体は、例えば速度の変化について監視されている。これは、道路セグメント（図７に示す）を通過するときの車の速度（または他の属性）を測定することによって行うことができる。その後、道路セグメントの速度分布が、一定の持続（継続）時間（１週間または１日など）にわたって計算される（図８に図示）。次に、例えばＫｕｌｌｂａｃｋ－Ｌｅｉｂｌｅｒ発散

【数1】

または任意の他の適切な分布類似度測度を使用することによって、速度分布の類似度が測定される。類似度がある閾値未満である場合、セグメント属性は変更を受けた可能性が高く、このセグメントは検証のためにモバイルプラットフォームに送信される。

【0113】

例えば、図５は、２つの設定された間隔の間で速度分布に変化がある例を示す。分布の変化は、道路セグメントでデータを収集する要求を発行するための基礎を形成する。

【0114】

モバイルアプリはスマートフォン上で実行することができ、スマートフォンは、そのカメラが道路を向くように適切に取り付けられている。しかしながら、このアプリは、デバイスの車載ネットワークの一部として、車両のカメラ、または実際にはスマートフォンカメラへのアクセスが提供される、専用のナビゲーションデバイス、または車両に内蔵されたナビゲーションシステム上で実行されてもよいことも企図される。図６に示すように、ナビゲーションアプリケーションは、地図サーバによって提供される静的地図コンテンツに基づいてユーザを関与させる速度制限などの道路属性を表示する。したがって、ディスプレイは、電子地図４２に対するユーザの現在のロケーション４１を示すが、ローカル速度制限を示すパネルディスプレイ（図６の画面の下部）も提供する。

【0115】

図６に示す例では、制限速度が１２０ｋｍ／ｈであることが示されている。ただし、図５の分布は、制限速度が（８０ｋｍ／ｈに）変化した可能性を示している。この場合、モバイルアプリは、道路セグメント上の潜在的な属性変化を確認する要求を受信する。この要求に応答して、モバイルアプリケーションは、カメラを自動的にオンにして、（図６に示されるパネル７３に示されるように）速度制限標識の画像を撮影する。好ましくは、カメラが道路に沿って一連の画像（すなわち、ビデオストリーム）を取得するために使用される。例えば、速度制限標識の正確なロケーションが分からない場合がある。カメラは、速度制限標識がこれらの画像の少なくとも一部に撮影されることを知って、道路の全セグメントについての画像を得るために使用することができる。

【0116】

次いで、モバイルアプリは、適切なオブジェクト検出アルゴリズムを実行して、画像７３を処理し、速度制限値を抽出する。この値は、地図を更新するために地図サービスに送信することができ、次いで、補正された速度制限値６０をユーザに表示することができる。デバイス上で画像データを処理することは、大きな帯域幅を節約するのに役立つことが理解されるのであろう。対照的に、いくつかの以前のアプローチでは、画像シーケンス全体が解析のためにクラウドサーバに渡されていたであろう。従って、典型的には、これは例えば、ユーザが自宅（ホーム）に戻って自宅のインターネット接続に接続されたときの旅行（移動）の終了後のような、後の時間にのみ行われた（過剰なデータ帯域幅の使用を回避するため）。したがって、記載された実施形態はまた、より規則的に、および／またはより低い帯域幅コストで、データが報告されて戻され、使用されることを可能にする。

【0117】

その他のユースケース例
速度制限情報を取得することに関する例を上記で提示したが、そのようなロケーショントリガは、道路ネットワークに関する任意の所望の情報を取得するために使用され得ることが理解されるのであろう。たとえば、その他のロケーショントリガの例を以下に示す：
・道路セグメントに沿ったロケーション間隔でおよび／または時間隔で（例えば、交通密度を推定するために、道路セグメント内の交通の数秒間隔当たり１つの画像のレートで）一連の画像を取得する要求を伴うロケーショントリガ
・ジャンクション遅延の変化に応答して道路ジャンクションの画像を撮影する要求を伴うロケーショントリガ
・（例えば、ポットホール検出のための）路面状態を決定するために、道路セグメントに沿って加速度計データおよび／または周囲雑音状態を記録する要求を伴うロケーショントリガ
・道路セグメントに沿ったロケーション間隔で一連の画像を作成する要求を伴うロケーショントリガ

【0118】

取得された情報は、地図サービスプロバイダに提供される必要はなく、（電子地図を更新することに限定されない）他の用途の範囲で有用性を見出すことができることも理解されるのであろう。例えば、情報は、交通管理、都市計画に使用されてもよく、または自動車製造業者、または道路ネットワークの他のユーザに提供されてもよい。

【0119】

したがって、本発明の様々な態様および実施形態がこれまでに説明されてきたが、本発明の範囲は本明細書に記載された特定の構成に限定されず、代わりに、添付の特許請求の範囲内にあるすべての構成、ならびにそれらの修正および変更を包含するように拡張されることが理解されるのであろう。

【0120】

本発明の実施形態は、コンピュータシステムと共に使用するためのコンピュータプログラム製品として実施することができ、このコンピュータプログラム製品は例えば、有形データ記録媒体上に格納された、またはコンピュータデータ信号内で具体化された一連のコンピュータ命令である。一連のコンピュータ命令は上述の機能の全部または一部を構成することができ、半導体、磁気、光学、または他の記憶デバイスなどの揮発性または不揮発性の任意の記憶デバイスに格納することもできる。

【0121】

また、当業者であれば、好ましい実施形態は、ソフトウェアによって特定の機能を実施するが、その機能はハードウェアにおいてのみ（例えば、１つまたは複数のＡＳＩＣ（特定用途向け集積回路）によって）、または実際にはハードウェアとソフトウェアとの混合によって、等しく実施することができることもよく理解されよう。したがって、本発明の範囲は、ソフトウェアで実施されることのみに限定されるものと解釈されるべきではない。

【0122】

最後に、添付の特許請求の範囲は本明細書に記載された特徴の特定の組合せを記載しているが、本発明の範囲は以下に特許請求される特定の組合せに限定されず、その代わりに、その特定の組合せが、添付の特許請求の範囲において現時点で具体的に列挙されているかどうかにかかわらず、本明細書に開示された特徴または実施形態の任意の組合せを包含するように拡張されることにも留意されたい。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】